a mester2004-ben nem biztos, hogy gondoltak a mai processzorok privilegium szintjeire és hogy lesznek olyan oprendszerek, amik (maximálisan) ki is használják ezeket.
Ha jól tudom jelenleg legalább 8 féle cpu mód létezik x86-oson/amd-n. (valós, virtuálix x86, SMM, védett stb.)
Ha a kernel olyan szinten kezelte le az esetleges BIOS védelmet(esetleg hibának tekintve), amire BIOS megírásakor a programozók nem számíthattak, akkor talán "lenyelheti" a védelmi riasztást. Nem mondom, hogy így van, de azt sem, hogy nem lehetséges.
Az is kérdés, hogy a BIOS, amikor a telepítő (telepítés közben) felírta a boot szektort, milyen módon értesítette (volna) a usert az eseményről azaz miképpen írt volna ki üzenetet és hogyan kezelte (volna) le a billentyűzet portját a user válaszáért.
Ha ez mind a kernelbe futott be a konzolok helyett, akkor a linux bármit megtehetett. Még ha nem is szándékosan. Mert bug az még sajnos rengeteg van. A kernelt tesztelők pedig nem biztos, hogy ezt a verziót is próbálták. Ezzel a BIOS-al.
És mondjuk az sem mindegy, hogy a BIOS simán I/O szinten ellenörzi-e a szektor számát (0-ás) íráskor vagy valmi más módon.
Mert védett módban például az I/O térkép az összes hozzáférési vezérléssel együtt a kernelnél van linuxon. Akkor pedig lehet, hogy a BIOS tudomást sem szerez az írási kisérletről.
Szerk: + ha a hiba a már telepített rendszer indításakor jelentkezik, akkor el tudom képzelni, hogy maga a grub(ha az váltja ki a hibát) ebben a fázisban int 0x13-al akar valamit visszaírni a boot szektorba. Akkor pedig a BIOS természetesen érzékeli és riaszthat.
De az is lehet, hogy egyszerűen csak a user kapcsolta be a telepítés után a BIOS-ban a védelmet.
Vagy nem is akarta bekapcsolni csak behívta a defaultokat egy esetleges elem-lemerülés/csere után.
De akár a BIOS maga is visszaállíthatta default értékekre magát egy esetleges CMOS checksum error után, amit meg akár egy szoftver is félkézzel elő tud idézni. Meg a vindóz is.