Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

The Linux Foundation kondigt LinuxBoot aan

The Linux Foundation introduceert LinuxBoot. De software moet sommige firmwarefunctionaliteit vervangen door een Linux-kernel en -runtime. Het opensourceproject heeft de steun van onder andere Facebook en Google.

De reden om het project voor LinuxBoot op te zetten is volgens de stichting dat het bij het booten van firmware vaak om verborgen code gaat die traag is en gevoelig voor fouten. Door de code te vervangen door een Linux-kernel zouden prestaties en de betrouwbaarheid worden verbeterd.

De verbeteringen zouden in datacenters, met vaak tienduizenden servers, van pas komen en LinuxBoot zou hier ook het beheer gemakkelijker kunnen maken, met aanvullende debugging- en opstartopties. Waarschijnlijk is dit waarom Google en Facebook bij het project betrokken zijn. Maar ook bij consumentenapparaten en internet-of-things-onderdelen moet LinuxBoot bruikbaar worden, schrijft de organisatie.

Details over de software zijn er nog niet veel, maar Phoronix constateert dat LinuxBoot de rom-stap van Coreboot en vervolgens U-Boot met de Pre-EFI Initialization-stap van uefi initialiseert en met name de Driver Execution Environment van uefi vervangt. Op dit moment zou het alleen nog werken op een R630-server van Dell.

In oktober vorig jaar werd bekend dat Google aan non-extensible reduced firmware, kortweg nerf, op basis van een compacte Linux-kernel werkt. LinuxBoot lijkt daar in ieder geval deels op gebaseerd.

Door

Nieuwscoördinator

105 Linkedin Google+

Reacties (105)

Wijzig sortering
Misschien iets te kort door de bocht, maar kunnen UEFI een mislukking noemen? Het is inderdaad erg snel en genoeg verbetering zijn er t.o.v. BIOS, maar er zijn genoeg dingen om aan te merken op deze standaard. Het feit dat de grote spelers dit nu willen vervangen, de nogal vele issues (bricks, veiligsheidsgaten vanaf dag één, secure boot fiasco/vendor locking, etc.) en het gesloten karakter - maken het er allemaal niet beter op.

Het zou allemaal zo simpel moeten zijn. Ik kan nog de eerste artikels herinneren met een browser die je kon openen in UEFI (mini OS). Nee, ik hoop dat deze nieuwe standaard echt teruggaat naar de core (het verzorgen van een werkende boot/init voor devices), al het andere kan prima met een liveusb en dus door het OS.

[Reactie gewijzigd door archie2012 op 26 januari 2018 22:37]

Misschien iets te kort door de bocht, maar kunnen UEFI een mislukking noemen?
Dat is maar net hoe je het bekijkt, of liever, vanuit wiens perspectief je het bekijkt. Aangezien er hoegenaamd geen peecee zonder UEFI wordt verkocht, zou je best kunnen zeggen dat het een groot succes is. Maar als je kijkt naar het gedonder en wat de eindgebruiker er uiteindelijk aan heeft, tsja, ander verhaal.

Het vanaf het begin een vrij naakte power grab geweest. Zie "secure boot" (wie zit er ookalweer op de sleutels?) maar merk bijvoorbeeld ook op dat nu ineens iedereen inclusief linux "dan maar" fat32 support nodig had om alleen maar te kunnen booten. Opgelegd door UEFI. Wat bijvoorbeeld de deur opent voor royalty claims. "Jullie ondersteunen FAT32, en dat is van ons, dus betalen." Zoals het geval is met android.

Wat dat betreft zijn deze anderen nu rijkelijk laat met hun "alternatief", waarvan we nog maar moeten zien in hoeverre iemand anders er wat aan heeft. Het is overigens niet het eerste, zoals al opgemerkt. Het bouwt zelf bijvoorbeeld ook al op coreboot. Waarmee dit initiatief een soortement van firmware-level versie van het fenomeen "linux distributie" is. Dat is een zwak punt, want er is maar een windows (de laatste, isgelijk de beste ooit, zegt de marketing), en een hele hoop linux distributies, wat toch voor verwarring en dus een barriere zorgt bij niet-experts.

En coreboot zou iig in theorie al allerlei verschillende payloads moeten ondersteunen. Zorg dat het makkelijk te installeren is, kies je payload, gaan. Maar zo werkt coreboot nou eenmaal niet, of minstens zijn ze daar nog lang niet in de buurt. Daarnaast is coreboot zelf op sterven na dood, zelfs voordat je iME/PSP-gedonder meerekent. Dus hoe levensvatbaar dit initiatief gaat zijn?

Ik moet nog zien dat ze serieus een gat gaan slaan in de UEFI-markt- en mindshare. Ik denk ook niet dat ze het zelfs maar proberen: Ze willen gewoon hun eigen datacentra in eigen hand houden en wat er op de desktop gebeurt is een ander feest. (google lost dat op door een eigen device met een eigen os, en facebook probeert maar gelijk het hele interweb te bezitten met hun "internet.org basics".) Dus ik zie niet dat er voor eindgebruikers zo snel veel zal veranderen. Hoezeer ik UEFI ook kwijt zou zijn.
FAT32 is hier gratis voor te gebruiken.
Microsoft Extensible Firmware Initiative FAT32 File System Specification
a) Provided that you comply with all terms and conditions of this Agreement and subject to the limitations in Sections 1(c) - (f) below, Microsoft grants to you the following non-exclusive, worldwide, royalty-free, non-transferable, non-sublicenseable license under any copyrights owned or licensable by Microsoft without payment of consideration to unaffiliated third parties, to reproduce the Specification solely for the purposes of creating portions of products which comply with the Specification in unmodified form.
https://download.microsof...0CBF082286A/fatgen103.doc

Dat moederbord fabrikanten enkel MS als authoriteit zien voor secure boot signatures, is niet de schuld van MS. MS is de FOSS wereld al tegemoet gekomen om gratis en voor niets de hele FOSS wereld -op aanvraag- secure boot certificaten te leveren.

Op een beetje fatsoenlijk moederbord ben je als eigenaar gewoon zelf de authoriteit die de certificaten kan berehen en die MS of andere kan goedkeuren, MS wordt hier alleen standaard in neer gezet omdat de systemen doorgaans toch met Windows eindigen. Dit was de eerste 1-2 jaar toen UEFI de standaard van het BIOS overnam wel een puinhoop omdat veel fabrikanten UEFI maar half geimplementeerd hadden.
[...]
Microsof: "Jullie ondersteunen FAT32, en dat is van ons, dus betalen."
Microsoft heeft een patent voor het maken van lange filenames in FAT32. Dat is niet relevant als je alleen de opstartcode hoeft te lezen.

Afgezien daarvan is er tenminste 1 alternatieve manier die niet door Microsoft gepatenteerd is.
De gui van menig uefi is veel slechter dan de beste oude klassieke biossen die je eenvoudig en snel met keyboard kon bedienen. Bij uefi strompelt de miis door langzame menus die tig klikken nodig hebben. Oftewel de gui is verslechterd. Als het daar al fout gaat...
Bij uefi strompelt de miis door langzame menus die tig klikken nodig hebben.
En dan moet ik ook nog een bedrade muis gebruiken want de draadloze bluetoeter doet het dan nog niet. Maar dat kan aan mij liggen.
Geheel mee eens. Een bios, efi of niet, is er om je systeem te starten en om wat basisinstellingen te doen. Snel en simpel, cursortoetsen en pg up pg dn. Nu zit ik met muisbediening, enorm kleurige menu's waardoor alles slechter te vinden is, ik kan een klein spelletje doen, wat internetten. Dit slaat nergens meer op.

Wat er niet in zit kan niet kapot, en bij efi zit er veel in, complete tcp/ip stack. Als ze dat nog gebruiken voor iets zinnigs. Neuh, voor remote management mag je drievoudige ophoesten voor een mobo met ecc, sas controllers en weet ik wat meer.
Kan die TCP/IP stack niet gebruikt worden voor netboot?
Voor PXE ja. Maar dat is makkelijk voor bedrijven. Op de desktop heb je daar doorgaans niets aan.
Al zal ik het waarschijnlijk niet zelf gebruiken, noem ik dit wel iets zinnigs.
Dat kon ook al in het oude bios, mits je een PXE geschikte netwerkkaart heb/had.

Maar okay, nu dus geheel via EFI. Dan nog, gebruik dan alleen het minimale wat je nodig heb voor PXE, niet een hele stack met allerlei bende erin die niet nodig is. Alles wat er meer in zit biedt meer mogelijkheden voor gaten en bugs. Maar het moet met kleur en animaties en een browser en de lijst gaat door. Dat is niet waar een bios voor is.
Dat was een bios-extentie die in de rom van de netwerkkaart zit. En daar kunnen we ook over discussiëren of een willekeurige insteekkaart tijdens het booten code mag uitvoeren wel zo'n goed idee is.

Kleur en animaties en zo, heeft niks met de API van de firmware te maken. Of deze firmware nu BIOS of (U)EFI implementeert staat los van wat voor gebruikersinterface deze voert. Google eens naar "AMI WinBIOS", een BIOS firmware uit 1994, met een GUI.
Maar om dit nou op UEFI af te wenden? Er zijn ook een aantal firmwares geweest die BIOS implementeren die een GUI als gebruikersinterface. Alhoewel veel firmwares die UEFI implementeren een GUI gebruikersinterface aanbieden, is dit niet onlosmakelijk verbonden. Ik ben ook firmwares die UEFI implementeren met een text interface tegengekomen.
IK haat die acer laptops die geen legacy mode hebben. Daar kun je dus alleen windows 10 goed op installeren. Je moet via windows 10 een bios update doen om legacy mode te krijgen.

Ik snap echt het punt van UEFI met secure boot niet goed, okay dus nu kun je alleen een OS installeren dat de keys heeft die in je BIOS staan. Hoe beschermt mij dat nu? Een rootkit zorgt er dan gewoon voor dat ik mijn computer niet meer kan opstarten.

Maar het is echt super irritant voor computer fixers zoals mij zelf wanneer het niet zo makkelijk is om secure boot en UEFI uit te zetten zodat je een PC kunt herinstalleren met iets anders dan de keys in de BIOS.
Jaren '80 BIOS stijl booten, in x86 Real Mode, compleet met het hele gate A20 gedoe. Moeten we die bijna 30 jaar aan legacy meuk nog meeslepen. Ik zeg niet dat (U)EFI ideaal is, maar dat is die legacy meuk al helemaal niet.
Hey voor mij moet het gewoon werken. Als ik niet meer de vrijheid heb om whatever OS van mijn USB stick of SSD over USB of SSD over esata te booten dan houdt het op voor mij.

Maar die bedrijven die het mij express lastig maken om in legacy mode te booten, die moeten echt oprotten. Om alles UEFI compatible te maken, en dan dat gedoe met keys en zo. Veel te lastig voor mij. Veel te veel werk. Legacy mode werkt voor mij. Als ze UEFI nu gewoon ook laten werken zoals Legacy mode is het voor mij prima. Maar ik wil geen laptops met voor geinstalleerde keys die het mij zo moeilijk mogelijk maken om iets anders te booten dan windows 8 of windows 10.

Dat is slavernij en geen vrijheid.
Ik heb een USB stick met een Linux installatie. Deze kan ik op mijn werk in de pc daar stoppen, boot opties kiezen, en deze dan als UEFI booten. Dat werkt gewoon hoor.

Jij hebt het over keys, dan neem ik aan dat je het over het zogenaamde "Secure Boot" hebt. Ja, dat is een irritant ding, waar Microsoft het inderdaad lastig maakt om een concurrerend OS te booten. Als je dit "Secure Boot" uit zet, kan je met UEFI ieder OS (dat UEFI support heeft) booten. Ja, als je het keys aan de slag gaat, wordt het ingewikkelder, maak de optie "Secure Boot" op "disabled" te zetten lijkt me niet overdreven veel werk.
Een groot probleem dat ik heb met UEFI is dat het zo slecht aansluit met Linux dat een dergelijke bootloader als GRUB benodigd is, terwijl Windows alles in één keer doet.

Ik krijg soms het gevoel dat UEFI ontworpen en aangepast is op Windows.

Daarom denk ik wel dat het veel correcties nodig heeft voor meer brede en algemene ondersteuning.
Maar de grafische interface vind ik een goed idee.
Een groot probleem dat ik heb met UEFI is dat het zo slecht aansluit met Linux dat een dergelijke bootloader als GRUB benodigd is, terwijl Windows alles in één keer doet.
Kan gemakkelijk zonder GRUB hoor :)
Windows heeft ook een bootloader ;)
Ik ben al langer tegen firmware zoals UEFI, welke geen duidelijk doel dient (omdat moderne operating systems geen BIOS nodig hebben, alleen een simpele bootloader) en miljoenen regels code bevat welke vaak kwetsbaarheden bevat. Daarnaast is het ook 'closed source' waardoor er achterdeurtjes (in de vorm van opzettelijke fouten) in kunnen zitten.

Als er toch van dit soort firmware moet zijn, dan liever gebaseerd op open-source, zoals Linux.

[Reactie gewijzigd door ArtGod op 26 januari 2018 12:20]

Ik ben al langer tegen firmware zoals UEFI, welke geen duidelijk doel dient (omdat moderne operating systems geen BIOS nodig hebben, alleen een simpele bootloader
De firmware zal toch in staat moeten zijn een bootloader van je OS in te kunnen lezen van een storage medium. Als je wilt booten van iets waar je BIOS geen out of the box support voor hebt, dan zul je daar dus een UEFI driver voor moeten hebben.
Dit is een argument van de vorm "We hebben toch iets nodig. Dit is iets. Dus moeten we dit hebben."

Zoals Mr. Hollywood het uitdrukt, "Aww, isn't that cute. But it's wrong."

In dit scenario is het doel van de firmware om te booten, en al het andere is simpelweg niet essentieel. UEFI is vrij veel complexer dan die essentie nodig maakt. We zouden ook heel goed kunnen booten met iets dat simpeler opgezet is. We zouden er zelfs beter af mee zijn. Zelfs het aloude, ondertussen toch wel erg afgetrapte, en nooit echt lekker werkende BIOS. Maar denk aan OpenBOOT, waar je vanalles mee kon wat zelfs UEFI nu nog niet zomaar kan, en toch een stukje simpeler inelkaar zat. Dit als tegenvoorbeeld.

Maargoed, simpliciteit heb ik nooit aan UEFI kunnen bespeuren, niet in doel en niet in uitvoering.
Dit is een argument van de vorm "We hebben toch iets nodig. Dit is iets. Dus moeten we dit hebben."
Ik had het daarentegen niet specifiek over UEFI, en ArtGod ook niet. Hij stelt dat het OS het prima allemaal zelf kan. Ik stel dat het enige wat het OS niet kan is de eerste paar instructies van zichzelf inladen - daar heb je echt firmware voor nodig.

Dat UEFI ontzettend convoluted is ben ik het helemaal mee eens. Maar punt is dat dat wel de standaard is, en dus zul je UEFI drivers nodig hebben.
Ik had het daarentegen niet specifiek over UEFI, en ArtGod ook niet.
Hij niet, jij wel, want:
Maar punt is dat dat wel de standaard is, en dus zul je UEFI drivers nodig hebben.
Dat is alleen maar zo precies zolang als en niet langer dan dat je UEFI gebruikt. Zodra je daar afstapt is het gedaan met UEFI drivers nodig hebben. Het is valide om te vragen of je dat in onderhavige geval ook kan, maar als je het "niet specifiek over UEFI" hebt, dan is het geen aan te nemen gegeven.

Waar we dus tegenaanlopen is dat je wel denkt dat je het niet specifiek over UEFI had, maar in je aannames komt een ander beeld naar boven. Dat is het soort denkfout waarmee we in allerlei monopolies vast blijven zitten, want mensen geloven onterecht dat ze niet zonder kunnen en proberen niet eens meer wat anders.

Dit is makkelijk en niet onterecht mierenneuken te noemen, ware het niet dat het toch cruciaal belangrijk is in een discussie waar we het over alternatieven hebben: Niet stiekem aannemen dat we niet zonder "de standaard" kunnen.
Dat is alleen maar zo precies zolang als en niet langer dan dat je UEFI gebruikt. Zodra je daar afstapt is het gedaan met UEFI drivers nodig hebben
Eens, maar niet gedaan met drivers nodig hebben in het algemeen. En dát is de kern van mijn punt. Dat jij dat punt zo naar UEFI toetrekt ligt louter aan jezelf. Ik wil ook helemaal niet de discussie voeren die jij wenst te voeren, dus bij deze haak ik af :)

Username checks out

[Reactie gewijzigd door .oisyn op 26 januari 2018 13:55]

Waar wil je dan je basis systeem instellingen doen als je geen BIOS wil ? Alleen in een ROM zal niet helpen.
Dat hoeft helemaal niet in een BIOS, dat kan het OS ook.
Je kunt beter stellen, je kunt het in het doen als deze het ondersteunt of er tools voor beschikbaar zijn.

Je hebt alleen geen goede fallback.
Het OS doet het toch al.. De BIOS zet wat defaults, maar die worden zodra de kernel van je OS start overschreven met wat je in je OS doet. Je kan dus net zo goed gewoon tijdens PEI voor dat DXE start de defaults gewoon er in rammen en de rest vergeten en door gaan naar het OS.

Vroeger was het nog spannend om dat een OS gewoon niks kon en dus afhankelijk was van de platform-specifieke firmware. Dat is al heel erg lang niet meer zo.
Mijn OS wijzigt echt niets in mijn BIOS hoor, zou niet gekker moeten worden!
Weet je überhaupt hoe x86 werkt? Je "BIOS" doet helemaal niks na wat interrupt vectors in te stellen, DDR init, wat PCI registers enz. Je hebt wat SMM code voor het geval de vendor dat nodig vond (basically backdoors) en that's it.

Zodra je kernel start gaat die zelf alle PCI registers aan de hand van de drivers opnieuw langs enz. Wat je in je BIOS of UEFI kan instellen gaat alleen maar effect hebben op het moment dat het configuratie is die alleen na een reset gewijzigd kan worden. Neem ASPM bijvoorbeeld, als je dat in je BIOS force-off zet, en een kernel of OS call daar wat mee probeert te doen, dan faalt dat om dat je die alleen nog na een reset kan aanpassen. Als die op 'off' staat maar je OS denkt dat 'on' beter is, dan gaat die na het opstarten gewoon op on.

Neem datum en tijd bijvoorbeeld, dat is een wat meer universele instelling. Die kan je in je OS instellen en ook in je BIOS/UEFI. Tijdens het opstarten leest je OS de HRTC en bij het afsluiten schrijft die de huidige tijd terug naar de hardware klok. Als jij dan in je BIOS wat anders geschreven had dan de 'echte' tijd, en je OS aan NTP doet, dan is de klok daarna dus gewoon gewijzigd.

Wat er voornamelijk nog praktisch pre-boot ingesteld kan worden zijn initiële configuratie van DRAM, CPU en functies die je OS misschien niet kan. Die 99% andere 'features' kunnen dus beter gewoon verdwijnen.
Jij vindt dat die kunnen verdwijnen omdat jij er wellicht geen usecase voor hebt, dat kan voor anderen anders zijn.
Nee, ik en nagenoeg iedereen in de OS-wereld vind dat de controle van het hardware platform niet aan de vendor en zijn black-box firmware is.

Waarom zou je features dubbel implementeren, waarbij een versie (die in de UEFI en de BIOS) slecht onderhouden wordt, slecht werkt, vatbaar is voor malware en niet zelf te bewerken is.

Stel dat je als eindgebruiker toch nog graag het gevoel wil hebben zonder kennis aan de knoppen te kunnen draaien, dan kan je nog steeds iets als SeaBIOS tussen je init en je kernel zetten, dan heb je net als nu toch nog het idee dat je een vorm van firmware controle hebt, ook al is dat net zo'n wassen neus als nu.
Yep en dit heet handover. Bios/uefi moet alleen maar handover doen naar het OS. Legacy mode is handig voor hele oude OSen die dit allemaal niet kunnen.

En UEFI met miljoenen regels code die niet opensource zijn is voornamelijk handig voor de software monopolisten zoals Microsoft die het graag iedereen zo lastig mogelijk willen maken om iets anders dan windows 8 of 10 te draaien. En natuurlijk de NSA en andere spionage giganten die graag heel erg veel controle willen hebben. En via TPM modules en zo de mogelijkheid hebben om bijna al je security te bypassen. Dus open hardware is ook hard nodig.

[Reactie gewijzigd door Kain_niaK op 28 januari 2018 03:21]

Om welke firmware gaat het hier? Kan je hier bijvoorbeeld Intel's Management Engine mee 'herschrijven'?
Helaas niet. Intel ME draait op een apparte processor en start van een andere ROM.

De firmware waar hier over gesproken wordt is de UEFI firmware (van AMI/Phoenix/Insyde/...). Dit is het deel dat de meeste gebruikers nog steeds de "BIOS" noemen.
Beetje off-topic vraag: 'BIOS' is een naam van een softwareprogramma dat jaren gebruikt werd en nu door UEFI opgevolgd is. Maar als BIOS een naam is en niet de term voor dit soort software, wat is dan wel de generieke term? Bootloader? Of komt dat erna pas?
Het BIOS van zeg, 5 jaar geleden, is al lang niet meer het BIOS zoals IBM dat oorspronkelijk in de PC 5150 uit 1981 gebruikte. Opeens zijn we ger na toevoeging van een nieuw bootproces UEFI gaan noemen, doch feitelijk is er sprake van wederom toevoeging van functionaliteit zoals dat al meer dan 3 decennia gaat. Het gaat niet opeens om een totaal ander programma: De firma's Phoenix en AMI werken nog altijd vanuit dezelfde broncode.

Wat mij betreft is het dan ook zeker niet plots helemaal fout om het nog BIOS te noemen, zelfs als we het over een systeem hebben waarbij de oorspronkelijke int13 functionaliteit niet meer aanwezig is: De overige functionaliteit, zoals hardwareinitialisatie, setupscherm e.d. zijn nog steeds doorontwikkelingen.
En daar moet ik je tegenspreken. UEFI is vanaf de grond opnieuw omgebouwd en bevat geen legacy uit het BIOS tijdperk. De oude BIOS was enorm traag door de manier van werken en dat kan je niet zomaar ammenderen. Alles gebeurd vandaag anders en op een vlotte manier zodat een systeem in enkele seconden kan opstarten ipv een halve minuut nodig te hebben om alleen al maar het geheugen te controleren.
Dat klopt gewoon niet: Aan broncode die AMI en Phoenix aan moederbordfabrikanten aanleveren is gewoon UEFI toegevoegd, de moederbordfabrikanten kunnen vanuit diezelfde broncode zowel BIOS'en voor oude moederborden als moderne "UEFI+BIOS" bouwen voor nieuwe moederborden. Bepaalde delen zoals hardwareinitialisatie worden gewoon gedeeld onafhankelijk wat je doet.

Ik denk dat je iets teveel beïnvloed bent door marketingpraatjes van Intel dat UEFI helemaal nieuw is. De specificatie van UEFI-bootproces en BIOS-bootproces hebben inderdaad niets gemeen, maar specificatie van Intel heeft niets te maken met hoe BIOS-producenten als AMI en Phoenix het kwa broncode aanpakken. Die hebben gewoon UEFI aan hun broncode toegevoegd. Voor hen is het doorontwikkeling van hetzelfde stuk software.

[Reactie gewijzigd door dmantione op 26 januari 2018 11:46]

Volgens mij is er in veel UEFI implementaties support voor legacy BIOS services ingebakken. Maar zijn er ook UEFI implementaties zonder die support. Dit betekent echter niet dat er BIOS code in UEFI implementaties gebruikt is. Zover ik het begrijp hebben ze niet UEFI toegevoegd aan een bestaande BIOS broncode, maar hebben ze een nieuwe UEFI gebouwd die ook met de BIOS broncode kan werken indien deze legacy support nodig is.

Mijn bron: https://en.wikipedia.org/...nsible_Firmware_Interface
Ik kan het natuurlijk fout hebben, maar dan zie ik graag een bron :)

[Reactie gewijzigd door job_h op 26 januari 2018 12:33]

Het uitschakelen van BIOS-support zorgt dat er geen int13 meer aanwezig is en geen BIOS-bootproces meer uitgevoerd wordt. Die code kun je de gebruiker aan/uit laten zetten of geheel niet meecompileren, of beter gezegd, mee-assembleren, want de boel is in machinetaal geschreven.

Dat heeft geen enkele invloed op de code die bijvoorbeeld de processor initialiseert of de code die de PCI-bus gaat scannen op de aanwezigheid van kaarten. De int13-API was al lang nog maar een klein deel van het programma dat in zijn totaliteit "BIOS" werd genoemd.
Wat is hier zo anders aan als bv game development waar men OpenGL en DirectX ondersteund. Dat de broncode niet herschreven hoeft te worden om een andere of nieuwe standaard te ondersteunen, zegt niets over dat de standaard niet van de grond af aan opnieuw opgebouwd is.

Soms is er voor een bepaald process, maar 1 enkele manier om dit uit te voeren. Dat dit vrijwel hetzelfde onder BIOS of UEFI is, zegt vrij weinig. MS heeft de BSD netcode jarenlang gebruikt om dezelfde reden "Als we het zelf zouden moeten maken, zouden we exact hetzelfde hebben gebouwd". UWP is ook nieuw, van de grond af opgebouwd, een groot deel hiervan is -kwa functionaliteit- gewoon 1 op 1 overgenomen van Win32. Dat maakt UWP niet een andere vorm van Win32.
Ik denk dat de vergelijking met een spelengine die DirectX danwel OpenGL ondersteunt een hele goede is. Het is denk ik een kwestie van terminologie: Heb je het over BIOS danwel UEFI als standaard, dan is dat prima, alleen moet je dan wel bedenken dat het stukje van de firmware dat de oude BIOS int13 implementeert, slechts een heel klein deel van de huidige firmware is.

We noemen evenwel het geheel aan firmware dat de moederbordfabrikant aanlevert "de BIOS" van het moederbord. De fabrikanten noemen benoemen hun totale firmware ook als een "BIOS". En daarom vind ik het dus ook niet per definitie fout om over een BIOS-update te blijven spreken.
Goed punt, in de volksmond is een UEFI ook nog een BIOS. BIOS is synoniem geworden voor het boot process denk ik. Net als dat andere 'merk' namen gewoon termen voor een bepaald iets zijn geworden. Pijnstillers bv :)
Ga maar eens een beetje een UEFI server booten, dat is pas traag. Onze ESX dozen zijn zo een minuut bezig om door de bios te komen, ESX is daarentegen met een paar seconden geboot.

Lijkt wel of de bios eerst koffie gaat halen. :)
Servers doen eerst toch ook een volledige geheugencontrole, in plaats van die snelle controle die desktops doen?

Zoiets meen ik me te herinneren, maar ik kan er naast zitten.
Oh I know, vroeg me alleen af hoe hij erbij kwam dat ze snel waren met UEFI.
De meeste server moerderborden doen een hele reeks controles die gewone PC's niet doen, zoals een hoop temperatuursensoren controleren, voedingswaarden controleren, out-of-band-management systemen (zoals iDRAC en iLO) configureren, en dan ook nog SAS controllers met bijhorende schijven initialiseren.

Dat zorgt voor veel vertraging.
Zo traag waren mijn niet-UEFI BIOSsen uit '07 en '09 nou ook weer niet.[1] Wel op m'n oude laptop, maar zelfs op mijn nieuwe laptop is het UEFI BIOS nog steeds véél trager dan op m'n desktop.

Een halve minuut op het geheugen te controleren klinkt me meer in de oren als een gepimpte 486 o.i.d. :P

Zie bv. https://youtu.be/jlQXS1VrFUQ?t=11m11s

[1] Een beetje afhankelijk van de instellingen. Met een floppy drive erin plus floppy boot check zit je zo aan een extra 5 seconden bv. Ze hadden er ook een handje van om standaard een POST computer summary (o.i.d.) weer te geven met een timeout van 5-10 seconden die je gewoon uit kon zetten.

Op m'n oude BIOS Gigabyte moederbord was m'n scherm fatsoenlijk aan om nog even een POST info-scherm weer te geven en dan Grub. Tegenwoordig kan het soms zijn dat m'n scherm pas fatsoenlijk aan is tegen de tijd dat de vijf seconde timeout in Grub bijna voorbij is. Ik heb het net getimet en m'n scherm doet er zo'n 6 seconden over om aan te gaan.

Conclusie: het was vroeger ~8 seconden en nu ~2 seconden. Procentueel een gigantisch verschil, in de praktijk bijna eerder een ongemak. Wat wel leuk is, is dat m'n computer zelf verder in <10 seconden boot (in Linux bedoel ik; Windows doet er uren over) maar dat is allemaal lang voorbij de bootloader en geheel gerelateerd aan de snellere CPU, en ondanks alles systemd.
BIOS is niet zomaar een naam:
Het BIOS, wat een acroniem is voor Basic Input/Output System, is een bibliotheek met een set basisinstructies voor de eerste communicatie tussen het besturingssysteem en de hardware. Tijdens het opstarten van een pc, wanneer het besturingssysteem nog niet geladen is, is dit ook de enige software die beschikbaar is.

Het UEFI gedeelte kan gewoon nog steeds BIOS worden genoemd. Het is wel meer uitgebreid en met meer beveiligingen ingebouwd, maar het blijft nog steeds "een" BIOS.
BIOS is niet de naam van het programma - het is de naam van de interface die verwacht wordt door het moederbord aangeboden te worden aan de processor en/of het besturingssysteem.

UEFI is net hetzelfde, gewoon een nieuwe interface met meer moderne mogelijkheden en minder legacy restjes (die worden aangeboden via een optionele BIOS emulatie/compatibiliteitsmodule binnen UEFI).

Als je een algemene, generieke term zoekt, kan ik je enkel 'firmware' aanbieden. Soms wordt er ook wel van boot-ROM gesproken, maar ik weet niet of die term goed gedefinieerd is.

De term bootloader kan voor verschillende dingen gebruikt worden. In de x86 wereld slaat het typisch op dingen die na/bovenop UEFI draaien (Windows Boot Manager, GRUB2, uboot). In embedded systemen worden daar soms wat vroegere stappen bijgeteld.
Volgens mij is er geen officiële term voor. Het heeft gewoon altijd BIOS geheten tot dat UEFI op de proppen kwam. Nu moeten we nog een term gaan verzinnen.

Bootloader is weer niet echt een juiste term want dat is meer voor GRUB (GRand Unified Bootloader) achtige software. Ik zou dan meer iets als firmware kernel als term gebruiken.
Volgens mij is er geen officiële term voor. Het heeft gewoon altijd BIOS geheten tot dat UEFI op de proppen kwam. Nu moeten we nog een term gaan verzinnen.
Wacht, ik heb een goeie naam: 'UEFI'! :)
Ik noem het firmware.
Helaas niet. Intel ME draait op een apparte processor en start van een andere ROM.

De firmware waar hier over gesproken wordt is de UEFI firmware (van AMI/Phoenix/Insyde/...). Dit is het deel dat de meeste gebruikers nog steeds de "BIOS" noemen.
Intel ME kan je uischakelen met https://www.youtube.com/watch?v=MujjuTWpQJk
De NSA wil zelf veilig zijn! dus kan het uit :)
NSA
Ik zag net op RT dat de NSA de termen 'honesty' en 'truth' uit haar mission statement op haar website heeft verwijderd. |:(

Edit: work in progress

[Reactie gewijzigd door ajolla op 26 januari 2018 13:55]

[...]

Ik zag net op RT dat de NSA de termen 'honesty' en 'truth' uit haar mission statement op haar website heeft verwijderd. |:(

Edit: work in progress
k
Ze willen geen nieuwe snowden die terugdenkende wel eens dit zou kunnen hebben gebruikt om
info ongemerkt uit de NSA systemen te krijgen!
Dus moet het ook uit kunnen , dit wapen is ook TEGEN de NSA te gebruiken.
Volgens mij is IME niet alleen software, ook hardware. Herschrijven dus niet, overschrijven wellicht, maar dan wel met risico dat je jouw moederbord bricked.
Wel raar dat ze speciaal voor Amerikaanse overheden wel de IME uitschakelen en dat ze daar deze lek dus niet in hebben. Beetje naaier streek toch?
Zover ik begrepen heb kan IME niet volledig uitgeschakeld worden.
Nee, bijna goed :)

Hiermee is het tot op heden slechts mogelijk delen hiervan (iME) uit te schakelen. Ik schat dat we nu op 85% zitten. UEFI vervangen is van een andere categorie en erg hard nodig, samen met BIOS/Extended bios en OPROM. Deze laatste kan prima overruled worden samen met BIOS in de linux boot.

Voordelen: Performance, Security (voor de eindgebruiker), Snellere boottijden (heel veel sneller) en niet te vergeten energiebesparing! (Jawel).

Noot: Het is voor slechts één corporatie ondoenlijk geworden om met de immer groeiende complexiteit nog closed source te blijven werken als het gaat om Cores, IP-cores en Firmware zoals gebruikt in hybride systemen, mixed CPU/FPGA en softroms. Dit zou wel eens de eerste (meest noodzakelijke stap) kunnen zijn. In ieder geval een opmaat die het momentum meeheeft ;)

Mijn 2 centen
Zou goed zijn als dit een standaard wordt voor IoT apparaten. Zo moeten developers zich minder zorgen maken om dit process en kan het makkelijk verbeterd/gepatched worden door een grote community.
Natuurlijk een groot voordeel maar met het risico dat er altijd maar een matig product op de markt gezet wordt "want de community fixed het wel".
Er worden op dit moment veel matige producten op de markt gebracht door gebrek aan resources/kennis bij IoT product development. Dus ik vind het sowieso al een grote stap. Maar ideaal gesproken moeten ze steeds hun best doen bij elke implementatie.
Wellicht kan er bij dit soort systemen juist een soort automatische update functie worden aangezet, zodat de eindgebruiker dat niet hoeft te doen. Zou mooi zijn, dan zou het tóch een iets-meer-dan-niet-patchen verantwoorde oplossing zijn.
De community is vaak niet een stel programmeurs op een zolderkamer maar grote bedrijven als Google, Facebook en IBM voor wie kwaliteit gewoon heel belangrijk is. LinuxBoot moet zaken versnellen en veiliger maken, als je dat niet meteen goed doet kan je het net zo goed niet doen.
Wat een negatieve instelling. De huidige BIOS/UEFI firmware wordt al jaren bekritiseerd vanwege hun slechte kwaliteit en gebrek aan transparantie. En het vervelende ervan is: je kan niet of nauwelijks kiezen.

Nu wordt er de optie voor een opensource variant aangekondigd en het eerste waar jij aan denkt is dat het fout kan gaan. Ben toch eens blij met extra keuze opties man! Het zou zomaar de beste van alle opties kunnen worden!
Wat is dit nu weer voor een opmerking? In plaats van het gebrek en gevaar van de community zou het een goed ding zijn als er eerder gesproken wordt over 'de kracht van de community'
Ik loop al vele jaren rond in diverse (opensource) communities en de serieuze projecten zijn al lang van het 'vrijheid, blijheid' gedrag af. Zeer serieus wordt er werk gemaakt van QA zodat er een degelijk product geleverd wordt. Het klopt dat niet iedereen even actief is. Maar dat hoeft ook niet en wordt ook niet verwacht. Wat wel verwacht wordt, is als je een taak op je neemt, je deze naar eer en geweten uitvoert. Dat je activiteiten worden teruggekoppeld naar de rest van het project.
De meeste rommel komt toch echt vanuit China, waar de 10e kloon van een gare 'slimme' thermostaat op de markt wordt gespammed zonder enige vorm van support en patch garantie.
Dan toch 100 keer liever een apparaat waar een degelijke boot omgeving in geimplementeerd wordt.
Het was ook niet zo negatief bedoeld. Meer als met het risico dat het kan gaan gebeuren. Niet dat het gedoemd is om te falen.

Een standaard met een goede basis is niets mis mee en kan ik alleen maar toejuichen.

[Reactie gewijzigd door sanscorp op 26 januari 2018 17:47]

Een standaard is een abstracte omschrijving van hoe iets moet reageren, niet een softwarepakket. Als dit de enige optie zou zijn gaat het alleen maar bergaf.
Aan wat voor firmwarefunctionaliteit moeten we hier denken dan? Zoals ik de beschrijving interpreteer neemt linuxboot dit werk op zich zonder de firmware/hardware/drivers aan te spreken, en veel firmwarefunctionaliteit is toch diep verweven met de specifieke hardware waar ze op draaien.

En hoe werkt het "vervangen van verborgen code"?
Op basis van de titel hoopte ik te gaan lezen dat ze firmware gingen maken die je huidige Phoenix/AMI/Insyde of Nanjing bios kon vervangen...
Zou toch mooi zijn als je je huidige bios firmware kon flashen naar een open source "linux bios".
Als coreboot het kan zouden de linux kernel ontwikkelaars het ook moeten kunnen.
Misschien eens op https://libreboot.org gaan kijken?
De verbeteringen zouden in datacenters, met vaak tienduizenden servers, van pas komen en LinuxBoot zou hier ook het beheer gemakkelijker kunnen maken, met aanvullende debugging- en opstartopties. Waarschijnlijk is dit waarom Google en Facebook bij het project betrokken zijn. Maar ook bij consumentenapparaten en internet-of-things-onderdelen moet LinuxBoot bruikbaar worden, schrijft de organisatie.

Beheer gemakkelijk in combi met IoT?
Kunnen ze straks dat de software op afstand van mijn koelkast gaan vervangen zonder dat ik het weet?
Ik ken weinig tot niets van OS'n. Maar gaat de kernel zo niet bloated worden?
Er zijn in principe 2 soorten kernels (ok, hybride bestaat inmiddels ook, maar dat gaat nu even te ver)
- monolithic kernel
- micro kernel

Een voorbeeld van een monolithic is de Linux Kernel. Deze zorgt voor zaken als:
- Process management
- Device management
- Memory management
- Interrupt handling
- I/O communication
- File system...etc..

Door al deze zaken in de kernel te integreren spreken we over een monolithic kernel. Het grote voordeel van deze aanpak is dat dit soort zaken niet op gebruiker niveau worden afgehandeld.

Microkernels handelen slechts een minimaal aantal zaken af:
- Managing memory protection
- Process scheduling
- Inter Process communication (IPC)
Alle andere zaken worden _wel_ in 'userspace' afgehandeld en kunnen dus in feite door bijv een server afgehandeld worden. Dit maakt de kernel natuurlijk veel kleiner dan een monolithische kernel.

Voor meer info: https://github.com/nu11se...20Types%20of%20kernels.md
Interessant. Bedenk me dit nu pas eigenlijk; maar heeft iemand uberhaupt gekeken naar de impact van de meltdown / spectre 'patches' in het geval van een micro kernel?

Ik betwijfel of minix is aangepast om deze issues te patchen maar ik neem aan dat de increased swaps die je nodig hebt met een micro kernel nu juist nog veel meer een impact zullen hebben, op zaken waar dat nu in de 'mainstream' zooi voornamelijk bij IO etc. het geval is.
Op zich zou een microkernel er meer last van kunnen hebben, maar je moet je afvragen waar deze 'patches' voor nodig zijn en of je die ook nodig hebt voor een microkernel en bijbehorende 'services' of alleen voor de 'boze buitenwereld'.
"Het grote voordeel van deze aanpak is dat dit soort zaken niet op gebruiker niveau worden afgehandeld."
Dat is eigenlijk het grote nadeel.

Het is veel robuuster niet "kritische" zaken in userspace af te handelen en de kernel zo immuun te maken voor problemen hierin (stabiliteit en veiligheid). Een voordeel van alles in de kernel is dat dit het aantal context-switches beperkt (van kernel naar user en weer terug).

Kortom robuustheid versus performance (in het kort)
Je kan een kernel zo groot en zo klein maken als je wilt. Dat is de hele essentie. De source code van de linux kernel is enorm en als je alles erin compileert krijg je een grote kernel. Als je er alleen instopt wat je nodig hebt wordt 'ie klein. Daarnaast kun je ervoor kiezen om bepaalde kernel functionaliteit als modules te laden - alleen als je detecteert dat je die module nodig hebt... voor bepaalde hardware bijvoorbeeld. De meeste distro's komen met een standaard 'tussenweg' kernel, maar het staat jou vrij je eigen kernel te compileren uit de kernel sources - je mag daar zelfs dingen aan veranderen!

De kernel die ze hiervoor maken is heel klein en afhankelijk van de hardware ook steeds iets verschillend, terwijl de basis hetzelfde blijft.

[Reactie gewijzigd door Jack Flushell op 26 januari 2018 11:10]

Ik zie dat je een aantal minnetjes hebt op het moment dat ik dit schrijf, waarom snap ik niet helemaal.

Je zegt dat je weinig tot niets weet van OS'n maar toch het toch al over de kernel hebt, Volgens mij heb je dan al meer kennis dan de gemiddelde gebruiker maar ik zal mijn beperkte kennis gebruiken om het hopelijk wat duidelijker voor je te maken.

De kernel van linux is super uitgebreid, dit om het op zo veel mogelijk verschillende hardware configuraties te laten draaien. Dit zou je als bloated kunnen noemen, maar het neemt bijna geen extra opslag in gebuik in het algemeen. Ook gebruikt het geen extra ram of processingpower omdat linux niet start wat hij niet nodig heeft. Ik denk dus niet dat het heel erg bloated zal worden
De kernel is universeel, op elk denkbaar apparaat kun je de kernel in principe nu al draaien. Echt bloated is het dus niet te noemen, omdat het erg universeel gemaakt is, om juist op zoveel mogelijk apparaten te kunnen draaien. Zo is Android bijvoorbeeld eigenlijk ook een verkapte Linux distributie (kort door de bocht genomen).
Ik ben erg benieuwd: houdt dit in dat google heel veel machines zonder opslag kan/wil gaan gebruiken? Gewoon de linux boot rom gebruiken om een bepaalde share te mounten en daarvandaan al je programmatuur draaien?
In principe kan dat al, sommige Uefi's kunnen van Iscsi booten.
Ja, misschien was ik wat onduidelijk. Natuurlijk kan dat, veel BIOSsen kunnen dat met PXE boot ook al. Waar ik het over heb is het OS in rom gebruiken als werkomgeving in plaats van verder te booten naar een ander OS, zoal UEFI en BIOS doen.
Mooi, is dit op aandringen van Intel/AMD zodat de performance hits van de Spectre/Meltdown patches minder merkbaar zijn? :+

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ LG W7 Samsung Galaxy S9 Dual Sim OnePlus 6 Battlefield 5 Microsoft Xbox One X Apple iPhone 8

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*