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
And I found the following link: https://en/wikipedia.org/wiki/INT_13H
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 https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface functionality that provides the same services and more. Typically, UEFI drivers generally use LBA https://en.wikipedia.org/wiki/Logical_block_addressing-addressing instead of CHS.*
*LBA -> Logical Block Addressing*
Now, in the conjunction with this explanation, you can read the following: https://en.wikipedia.org/wiki/Logical_block_addressing pointer.
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: www.aosabook.org/en/yocto.html
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