hanem inkább alaplap-vendoronként volna eltérő
Szerintem is erről van szó; én rögtön így értelmeztem.
miért nem az AGESA firmware blob csinálja [...] az alaplapgyártók nem piszkálhatnak bele
Ez nagyon jó kérdés; én nem is gondoltam rá. Ezzel kapcsolatban kevés infóm van, mert zárt forrású ill. fizikai (nem virtuális) firmware-rel alig dolgoztam. Csak annyit tudok (hallomásból), hogy mire az x86_64 firmware végül rákerül az alaplapra, egy nagyon hosszú "supply chain" végén áll, és egy csomó minden félrecsúszhat. Az ellátási lánc hosszával kapcsolatban két közvetett bizonyítékom van:
- Amikor találtam olyan biztonsági hibákat az edk2-ben, amiből CVE lett, és fizikai firmware-eket is érintett, akkor irtózatosan hosszú ideig kellett várni az embargó feloldására, mert a fizikai firmware vendoroknál minimum fél évig, de inkább egy évig tart a javítás beépítése, tesztelése, és leszállítása. Ja és többnyire nem is hajlandóak egyeztetni, amikor az elején az ember az embargóról tárgyalni próbál.
- Mind a Microsoft, mind az Intel ellene van a git monorepo-nak (amit pl. a Linux-nál megszokhattunk, illetve open source fejlesztőként magunk is kedvelhetünk), fizikai firmware-ek tekintetében. Mindkét cég (de a Microsoft különösen) azt szereti, amikor több külön repo van, és abból "cherry pick"-elnek feature-öket, chipset ill. device driver-eket stb; a verziózást pedig külön python infrastruktúrával végzik, nem bízzák a git-re. Linuxos háttérrel ez észveszejtően körülményes (mi nyilván azt akarjuk, hogy minden legyen egy repo-ban; például a git-bisect így tud jól működni); ott viszont, ahol 15 proprietary beszállító bináris komponenseit kell integrálni, ennek valószínűleg van létjogosultsága.
El tudom képzelni, hogy adott platformon simán rossz verziójú AGESA-t építettek be. Vagy hogy valamilyen oknál fogva nem az AGESA állítja be a CPU-t, és a platform chipset kódjában egyszerűen elvétették a (nem is feltétlenül nyilvános) CPU manual-ból ezt a részt.
Én arra lennék kíváncsi, hogy a linuxos patch végül pontosan azokon a CPU-kon tiltja-e le az L1 VMLOAD/VMSAVE-et, ahol a firmware-nek is kellett volna. A patch a "cpuinfo_x86.x86_model" mezőt vizsgálja; elépzelhetőnek tartom, hogy a firmware-nek ennél "kifinomultabb" (részletesebb) vizsgálatot kellett volna végeznie. Vajon a linuxos patch letiltja a CPU-k egy olyan részhalmazán is a feature-t (az egyszerűség nevében), ahol nem kellene? Sosem fogjuk megtudni, gondolom :)