REPLY: INT 13H

[Zoran Stojsavljevic]

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