Hello Vincenzo,
Since you replied only to me, I would like to write my reply also to the whole list, in order to draw some more experienced people with INT 13H knowledge.
Explicitly, I do not know with 100% certainty if OSes direct via INT 13H some data to be written to the USB and/or SATA. It is entirely possible, either by maliciously created part of the OS (especially Closed Source, such as WIN), either by malicious virus somehow inserted. Since I know more about INT10H and INT 15H, I googled to find some data about INT 13H, to get familiar
The immediate what I thought about is, since I know that these INT are, after all, part of Lecacy BIOSes, to see if UEFI BIOS can somehow resolve this situation (since UEFI BIOSes suppose NOT to use these INT, since these are legacy mechanisms after all).
But I found the following reading the pointer: Modern computers come with both BIOS int 0x13 and UEFI functionality that provides the same services and more. Typically, UEFI drivers generally use LBA-addressing instead of CHS.
LBA -> Logical Block Addressing
For me, to avoid legacy INTs I'll use 64b UEFI BIOS (all 64b BIOSes are UEFI BIOSes, but vice versa is NOT true - there are 32b UEFI BIOSes also), with the modern INTEL/AMD/x86 CPUs and SoCs, which somehow guarantees that such mechanisms are NOT present in the FW anymore.
> If i'm not wronging it seems to me that the INTEL architecture (x86 based) is not a good choise to solve this question.
BIOSes are primary and ONLY created to serve x86 and x86_64/AMD64 architectures (there are beasts on their own, with UEFI ones more than 2 million lines of code). I guess, there are NO such things as BIOSes for ARM, PPC, MIPS and similar architectures. There are boot loaders serving as minimal BIOSes, such as Coreboot and U-Boot. They usually do NOT have HDD/SDD drivers included.
For the further info, maybe Black Hat members, as well as GOOGLE designers, usual members of this Coreboot list can help you (and also extend my knowledge) to understand more about your questions.
> And excellent is also the YOKTO project you are devoting your time. Embedded linux is a very big opportunity.
I am not going to deepen YOCTO story. But whoever would like to understand YOCTO, I warmly suggest this pointer for the beginners:
NOT the official YOCTO Project web pointer, since it is really lot of stuff in not a systematized manner (usually top engineers are writing horrible documents, and this always repeats as pattern recognition during decades) and tough stuff for immediate understanding. It will introduce more confusion and dead brain spirals... ;-)
Zoran
_______
Dear Zoran,
thanks very much for your reply. Excellent.
And excellent is also the YOKTO project you are devoting your time. Embedded linux is a very big opportunity.
Sorry if I take advantage of it to pose a question that is not easy to solve. I've just posed this question to coreboot list, but probably the solution is in a linux embedded distribution that avoid the INTEL architecture and the related problems about real/protected/long .... modes.
Briefly the question:
I' intersting into know if BIOS/UEFI can implicitly (that is without an explicit command from a user) write to a suspect drive attached to a computer (in particular USB stick and SATA hard disk).
It seems that there are edge cases for which this happens. If i have well understood, it seems that there are cases for which the O.S. can call BIOS'es interrupts, like the INT 13 H and execute writing operations to a USB/SATA drive.
If this is true, is the possibility to deactivate this action at boot level and avoid writing operations, without an explicit command from a user, to a USB/SATA drive attached to a computer ?
If i'm not wronging it seems to me that the INTEL architecture (x86 based) is not a good choise to solve this question.
Thanks very much.
Best Regards.
Vincenzo