Kevés komplexebb probléma van a számítógépek piacán annál, minthogy a cégek megteremtsék a kapcsolatot a hardverek, illetve a telepített operációs rendszer közötti. Ez pusztán azért nem tűnik nagy gondnak, mert a felhasználó már a kompatibilitás úgymond természetes folyamatát látja, de az addig vezető utat buktatók tucatjai tarkítják.
Bármilyen PC-s hardvert is veszünk, illetve akármilyen operációs rendszert telepítünk, a kettő között két további rétegre van szükség. Az egyik a host, a másik pedig a szilícium inicializáló firmware. Utóbbit platform inicializáló firmware-ként is szokás emlegetni, de a megnevezés most nem fontos, a lényeg annyi, hogy az adott processzor gyártója biztosítja a megfelelő kódot a hardver optimális kezeléséhez. Ilyen például az Intel FSP (Firmware Support Package) vagy az AMD AGESA (AMD Generic Encapsulated Software Architecture), de utóbbi cég a jövőben érkező rendszereknél át fog térni a nyílt forráskódú openSIL-re (Open Silicon Initialization Library).
Hirdetés
A szilícium inicializáló firmware nem lehet teljesen gyártófüggetlen, mert alapvetően kötődik a hardverhez, ugyanakkor a host firmware esetében ez már nem igaz. Az ide szánt, elterjedtnek számító alternatívák, gondolva az UEFI-re vagy a corebootra, már nem gyártóspecifikusak, ugyanis a piacra dobott gépek tekintetében a processzor rendszerint eltérő lehet, de a kapcsolódó egyéb komponensek nem feltétlenül. Gondoljunk csak bele, az AMD és az Intel ugyan eltérő platformokat fejleszt, de nagyrészt ugyanazok a memóriaszabványokat használják, és ugyanazokra a tipikus interfészekre lehet kötni az egyéb hardvereket.
Az aktuálisan alkalmazható, nehezen kezelhető implementációk [+]
A jelenlegi működést tekintve azonban a host és a szilícium inicializáló firmware között minden egyes platformarchitektúra eltérő interfészt használ, annak ellenére, hogy a hardver szempontjából ott vannak a közös pontok. Ez azt jelenti, hogy a rendszerintegrátorok kénytelenek gyártóspecifikus bootfolyamatokat létrehozni, az ezekhez írt kódok sokszor nem is újrahasznosíthatók, és mindez megdobja a validációs költségeket, arról nem is beszélve, hogy a megírt kódokban gyártóspecifikus hibák maradhatnak, amelyek támadhatóvá teszik az adott rendszert. Mostanra mindez túl bonyolulttá vált, így nem ritka, hogy csak azért jönnek új firmware-ek, mert valami biztonsági rést kell foltozni bennük, ami nem túl szerencsés helyzet.
Az openSFI (Open Silicon Firmware Interface) erre a problémára próbál megoldást kínálni azzal, hogy definiál egy egységes interfészréteget a host és a szilícium inicializáló firmware-ek között. Ez rendkívüli segítség a rendszerintegrátorok számára, hiszen egy ilyen modellel teljesen lényegtelen a host firmware számára, hogy a szilícium inicializáló firmware hogyan valósítja meg a platform inicializálását. Ez növeli a kód-újrahasznosítását, elvégre az alkalmazott hardverelemek egy jó része szabványos, vagyis gyártótól függetlenül azonosak, így a bootfolyamatnak sem kell annyira eltérőnek lennie. Az egységesítésnek hála a biztonsági auditok is hatékonyabban elvégezhetők, ezáltal pedig csökken az esélye annak, hogy a firmware-ekben valami biztonsági rés lesz. Utóbbi kiemelten hasznos, ki ne szeretne ezen a piacon biztonságosabb firmware-eket?
Az openSFI megoldása a problémára [+]
A nyílt openSFI specifikáció egyelőre a 0.3-as verziónál jár, vagyis még aktívan készül, viszont nagyon jó hír, hogy széleskörű az iparági támogatás mögötte. A fejlesztésért az Open Compute Project felel, amelynek tagjai között szerepel a 3mdeb, a 9elements, az AMD, az AMI, az ARM, a ByteDance, a Google, a HPE, az Insyde, az Intel, a Microsoft, a MiTAC és az OSFF. A rendszer szorosan kapcsolódik az openSIL projekthez, amellyel garantálható a host firmware alatti teljes munkafolyamat nyíltsága és ellenőrizhetősége, nagymértékben növelve az openSFI és openSIL projektekre épülő rendszerek biztonságát.
