Intel schrapt bios-compatibiliteit uefi in 2020

Intel schrapt de ondersteuning voor het traditionele bios voor zijn producten in 2020. Vanaf dat moment ondersteunen alle platformen van Intel alleen nog uefi class 3 en is booten via de Compatibility Support Module niet meer mogelijk.

Intel neemt de last mile-barrière weg om zich te ontdoen van het traditionele bios, luidt het in de woorden van Brian Richardson, developer evangelist bij Intel. Hij hield onlangs een presentatie over het onderwerp tijdens het Uefi Plugfest in Taiwan. Volgens Richardson is de compatibiliteit er nog omdat mensen nog steeds software gebruiken die afhankelijk is van 16bit-bios en er mensen zijn die secure boot willen omzeilen of multi-OS-booting instellen.

Volgens de Intel-evangelist is het voordeel van het schrappen van bios-ondersteuning dat de omvang van de uefi-code afneemt, de validatie eenvoudiger wordt aangezien die niet meer nodig is voor de modi met csm aan en uit, en dat zo het gebruik van nieuwe technologie aangemoedigd wordt.

Hoewel vanaf 2020 uefi class 3 standaard wordt bij Intel-producten en niet 'class 3+' met secure boot ingeschakeld, wijst Intel wel op de beveiligingsvoordelen van die techniek. Intel roept fabrikanten op de validatie van tools bij secure boot ingeschakeld te verbeteren, zodat gebruikers niet meer op Compatibility Support Module terug hoeven te vallen bij bijvoorbeeld herstelproblemen. Op secure boot was en is veel kritiek, met name vanuit de opensourcecommunity. Als secure boot is geactiveerd, bemoeilijkt dat de installatie van Linux op systemen.

Reacties (174)

[dmantione]

Ik vermoed dat dit iets te maken heeft met Tiger Lake: De nieuwe "lean x86"-architectuur die Intel aan het ontwikkelen is. Wat we weten is dat Intel minder relevante onderdelen van de x86-architectuur wil verwijderen. In het tijdperk na de Wet van Moore moet je namelijk dingen schrappen om dingen toe te kunnen voegen wil je de chip niet onbetaalbaar maken.

Een zeer voor de hand liggende functionaliteit om dan te schrappen zijn de 16-bit modes van de processor (real/protected). Maar als je de 16-bit functionaliteit schrapt, dan wordt het lastig om het BIOS te handhaven, het is eigenlijk het enige stuk 16-bit software dat nog massaal gebruikt wordt.

[--Andre--]

Real Mode schrappen, dat zie ik wel zitten, maar protected mode? Zo ver ik weet is de 32 bit protected mode een uitbreiding op de 16 bit protected mode, en 32 bit protected mode schrappen? En binnen de 32 bit protected mode, zou ik de Virtual86 mode misschien nog even laten zitten.

[dmantione]

Ik heb het inderdaad over de 16-bit protected mode. AMD heeft denk ik mooi voorwerk verricht: Als de processor in 64-bit mode draait, dan ondersteunt hij wel 32-bit protected mode applicaties, maar geen 16-bit protected mode en ook geen virtual86-mode. Je hebt gelijk dat 16- en 32-bit protected mode eigenlijk één zijn en de 32-bit protected mode als de processor in 64-mode draait is inderdaad niet 100% compatibel op dit punt: Je kunt geen 16-bit selectors alloceren. De mode is evenwel wel compatibel met de 32-bit omgeving waarin Windows en Linux programma's draaien, waardoor 32-bit applicaties op een 64-bit besturingssysteem kunnen draaien.

Doordat de 16-bit mode als de processor een 64-bits besturingssysteem draait geblokkeerd is, gok ik dat dit nu een relatief makkelijke kandidaat is om te verwijderen en met de aankondiging van Intel dat ze functies gaan verwijderen, denk ik dat ze dit gaan doen.

[flippy]

vertaald: je mag uitsluitend nog windows installeren op intel systemen.

[MikeyV]

vertaald: je mag uitsluitend nog windows installeren op intel systemen.

Sorry dat ik zo bot uit de hoek kom, maar dit is dus echt de grootst mogelijke onzin!

De UEFI-specifiacties zijn juist gebaseerd op het feit dat UEFI niet processor-afhankelijk is en zeker niet OS-afhankelijk. Nu zou dat met Secure Boot wel omzeild kunnen worden, ware het niet dat je als gevorderde gebruiker echt wel in staat bent een UEFI te flashen die Secure Boot weer OS-onafhankelijk maakt. Ook Intel heeft zich daaraan te houden en is een vendor lock-in gewoon not done.

Dat Linux zich daardoor juist moeilijk (om niet te zeggen niet) laat installeren op Intel Secure Boot systemen zegt dan meer over de al dan niet correct gecompileerde Linux-kernels dan over de Secure Boot in UEFI. Het is al een bekend feit dat Linux toch enigszins achterloopt op ontwikkelingen op dit punt:

The Linux kernel has been able to use EFI at boot time since early 2000,[75] using the elilo EFI boot loader or, more recently, EFI versions of GRUB. (bron: https://en.wikipedia.org/...nsible_Firmware_Interface)

terwijl EFI einde jaren '90 al zijn intrede deed.

Als toegift: Microsoft heeft trouwens altijd ontkend zich schuldig te maken of mee te werken aan een zogenaamde vendor lock-in vwb Linux: https://www.theregister.c...3/ms_denies_uefi_lock_in/.

[SomerenV]

Of Linux-distro's zorgen ervoor dat ze compatible zijn met Secure Boot. Dat moet in 3 jaar tijd wel op te lossen zijn lijkt me.

[Blokker_1999]

Compatibel zijn is op zich geen groot probleem. De documentatie van hoe je alles moet opzetten is er. Het grote probleem is je sleutels ondertekend krijgen. Er is op dit moment maar 1 root CA die universeel vertrouwd wordt in een Secure Boot omgeving en dat is Microsoft. Je moet je bootcode dus telkens laten ondertekenen door Microsoft. En probeer dan maar eens je eigen kernel te compileren. Dan hang je er aan voor de moeite. Mag je zelf heel de infrastructuur gaan opzetten om alles te ondertekenen en de nodige info in je eigen EUFI te installeren.

[rbr320]

Net als dat we nu Let's Encrypt hebben zou het hele ondertekeningsgedeelte van UEFI Secure Boot onder een non-profit organisatie moeten vallen. Persoonlijk vind ik de EFF daarvoor een goede kandidaat, maar daar zijn de grote jongens zoals Intel en Microsoft het vast niet mee eens, ze willen vast niet graag deze macht uit handen geven.

[flippy]

secure boot heeft de provisie in het bios uefi dat men kan vendor locken op OS. dus uitsluitend het goedgekeurde OS mag dan erop. 1x raden wat de keuze gaat zijn.

[downtime]

Waarom? Zover ik weet wil Intel helemaal niet afhankelijk worden van die ene grote OS-leverancier. Hoe belangrijker Microsoft is, hoe minder belangrijk Intel wordt. En dus zijn ze blij met Linux.

[!GN!T!ON]

Niet intel, maar bijvoorbeeld Acer of Asus, HP. OEM's dus. Er zijn volgens mij al laptops met secure boot aan geleverd die inderdaad die instelling in UEFI aan hadden staan waardoor je alleen windows kon installeren.

[NanoSector]

Windows is dus niet het enige OS wat op systemen met Secure Boot geïnstalleerd kan worden. Ubuntu en fedora hebben hier ook geen problemen mee. Dat je dus gelimiteerd bent tot Windows is onzin.

[Cilph]

Canonical en Red Hat laten hun images ondertekenen door Microsoft(!). Vermoedelijk met betaling.

[MadEgg]

Ja, maar dat is slechts een shim. Een kleine blob die vervolgens weer code naar keuze inlaadt en dus eigenlijk de vrijheid geeft om te booten wat je maar wilt. Microsoft is daar niet continu bij betrokken, die shim kan keer op keer opnieuw gebruikt worden. En haalt daarmee feitelijk het secure boot principe onderuit.

[sympa]

Maar je moet die shim maar krijgen. En Microsoft heeft de macht daarvoor. En Microsoft heeft macht over de hardware vendors via 'kortingen'.
Deze technologie is op zich prachtig voor de security, maar geeft ook een machtsconcentratie en daarmee de kans op misbruik.
Stel je voor dat er geen hardware meer is waar je een eigen OS op kan installeren. Dan kan de hele computing wereld net zo gesloten worden als die van de iPhone, waar je moet betalen om je software op het platform te krijgen, waar alleen specifieke codecs en webbrowsers ondersteund worden, waar je geen bestand kan opslaan tenzij je een 'pro' versie koopt...

[MadEgg]

Die heb ik toch? Staat op mijn Ubuntu partitie. Ik kan zelf mijn eigen kernel bouwen en die daarmee booten. Heb ik Microsoft niet voor nodig.

[StefanJanssen]

Aangezien Microsoft zelf ook veel bijdraagt aande open source community, zowel met donaties als er zelf aan werken en ze een goede partner zijn van canonical verwacht ik niet dat ze hiervoor betalen.

[sympa]

Ze betalen nu denk ik inderdaad niet. Zou ook peanuts zijn qua geld en alleen maar een rel geven.

[Steyn_E]

Ik denk niet dat ze daarvoor hoeven te betalen. Microsoft kijkt denk ik wel uit voor antitrust rechtszaken. Canonical en Red Hat zitten achter de enige échte concurrenten op desktop-OS gebied. Als Microsoft het dan ook nog eens onmogelijk of duur zou maken om hun image te laten ondertekenen krijgen ze vast een mededingingszaak aan hun broek.

[Reactie gewijzigd door Steyn_E op 22 juli 2024 18:02]

[84hannes]

Ik denk niet dat ze daarvoor hoeven te betalen. Microsoft kijkt denk ik wel uit voor antitrust rechtszaken.

Ik denk niet dat een rechter moeilijk zou doen over een schappelijke vergoeding. Bij antitrustzaken gaat het altijd over "misbruik van een monopoliepositie". Dat er voor een dienst geld wordt gevraagd lijkt me geen misbruik: er is iemand van Microsoft een paar uur bezig met deze ondertekening, die loonkosten kunnen doorgerekend worden. Pas als het bedrag onredelijk hoog wordt en een kunstmatige barrière vormt lijkt me hier sprake van. Nu kan ik niet beoordelen wat een schappelijke vergoeding is (geen idee of dat tientallen dollars of tienduizenden dollars is) maar daar kan een rechter of expert zich over buigen.

[Reactie gewijzigd door 84hannes op 22 juli 2024 18:02]

[rbr320]

Dat kan allemaal wel zijn, maar feit blijft dat er open source desktop projecten bestaan, al dan niet gebaseerd op Linux, die volledig afhankelijk zijn van hun communitie en dus helemaal geen geld hebben om hun bootloader te laten tekenen door Microsoft, hoe schappelijk de vergoeding ook is. Bovendien, maar dat is in deze discussie al een paar keer genoemd, is het hele secure boot een wassen neus onder Linux omdat het slechts een kleine pre-bootloader/shim is die ondertekend is en door de UEFI wordt aangeroepen. Deze laad vervolgens GRUB en die vervolgens de Linux kernel, maar dat is allemaal niet ondertekend en kan dus net zo goed willekeurige code zijn.

De meeste mensen hier weten over SSL/TLS wel dat digitale handtekeningen werken op basis van een keten van vertrouwen en een keten is zo zwak als de zwakste schakel. Secure boot op Linux houdt op ver voordat de gebruiker zijn desktop ziet en kan dus net zo goed worden uitgeschakeld.

[84hannes]

Ik heb geen reden om het met je oneens te zijn. Maar mensen die niet weten hoe ze secure boot uit moeten zetten installeren hooguit Ubuntu, Fedora of heel misschien Debian. Die gaan geen kleine distributie installeren, dus het probleem dat je schetst is volgens mij verwaarloosbaar. Zolang secure boot uit te zetten is/fatsoenlijk te omzeilen is. En volgens mij kun je met shimx wel degelijk een signed kernel verifiëren, dus je kunt de keten van verificatie nog wat verlengen.

[goarilla]

De grote jongens hebben het al op orde maar wat met de kleinere distro's of nieuwe opstartende distro's ?
Dit is weer een drempel extra.

[84hannes]

Ik snap de details niet, maar als Grub eenmaal draait voor Ubuntu, dan is secure boot toch al omzeilt? Kan je diezelfde Grub-installatie dan niet gebruiken om een andere distributie te starten?

Van wikipedia:

developers believed that the practice of signing only the bootloader is more feasible, since a trusted kernel is effective at securing only the user space, and not the pre-boot state for which secure boot is designed to add protection. That also allows users to build their own kernels

Als eindgebruikers hun eigen linux kernel kunnen compileren en opstarten met (een oude versie van) shim, dan moet een kleien distributie dat ook kunnen.

[Reactie gewijzigd door 84hannes op 22 juli 2024 18:02]

[gertvdijk]

Ik heb op Ubuntu ook kernel images gesigned staan, bijv.: /boot/vmlinuz-4.4.0-98-generic.efi.signed.

Bovendien kan ik met secure boot geen zelfgecompileerde kernel modules meer laden. Het eerste waar ik dat mee merkte is VirtualBox. De host kernel modules kunnen niet worden geladen totdat ik in niet-secure mode boot.

Oftewel, het lijkt erop dat er een chain of trust is. UEFI -> shimx -> Grub -> Linux -> initramfs -> modules.

[blinchik]

Ik draai de Xanmod kernelbuild op Mint, dus zoiets zal in de toekomst moeilijk worden ?

[Aeternum]

Ik volg het niet helemaal. Als partij XYZ de code ondersteuning levert aan de opensource community dan is die functionaliteit toch beschikbaar en kunnen de distro's hier gebruik van maken? Of hangt dit nu echt vast op het signen van images?

[mder]

Tja, dan sign je de virtualbox modules toch zelf.....
Klik hier voor een handleiding.

[theduke1989]

Denk het niet. De meerderheid is nu eenmaal Windows geworden. Dit is niet makkelijk terug te draaien dus blijf Windows de belangrijkste in hun portfolio.

Is net als met smartphones. Android en iOS zijn de belangrijkste. En wordt moeilijk voor andere.

[SG]

De grote OEM A merken hebben ook te maken met hoe groot hun helpdesk afdeling moet zijn.
Dus het is niet alleen maar valideren maar je moet voor elk supportende OS ook de kennis binnen halen of bijspijkeren voor de helpdesk.

[Titan_Fox]

Dat lijkt mij ietwat onzinnig. Je kunt als OEM prima toestaan dat een eindgebruiker een ander OS installeert en duidelijk aangeven dat daar geen technische ondersteuning voor geleverd wordt. De meeste Linux gebruikers zijn capabel genoeg om zelf problemen op te lossen.

[indigo79]

Ik heb niet heel veel ervaring met helpdesks voor Windows ondersteuning, maar het enige antwoord dat ik van zowel Lenovo als Dell al gehad heb, is om alles opnieuw te installeren naar fabrieksinstellingen en te kijken of het probleem daarmee opgelost is. Zo ja, dan was het een softwareprobleem, zo nee, dan is het een hardwareprobleem. Mits een behoorlijke Linux installer (en die van Ubuntu is dat volgens mij wel en kan in elk geval de basis zijn voor een nog meer geautomatiseerde) moet dat echt niet zo'n probleem zijn.

[Anoniem: 105188]

De grote merken hebben tegenwoordig producten welke standaard met Ubuntu worden geleverd. Als je een product koopt, dan koop je het als geheel. Als je echt Linux wil draaien stel dan zelf iets samen of koop iets welke wel open staat.

[Nha]

Dus als je in de toekomst Linux op je laptop wil moet je ofwel de duurdere varianten met lichtere hardware kopen die met Linux (en dan meestal nog Ubuntu, bah) geleverd worden, of dan maar geen laptop hebben?

[Anoniem: 105188]

Kijk maar eens naar de Dell XPS 13 en 15... Ik snap even niet waarom je aan het klagen bent over Ubuntu. Het hele idee was toch dat jezelf er iets op wilde zetten?

[Reactie gewijzigd door Anoniem: 105188 op 22 juli 2024 18:02]

[Nha]

Precies wat ik bedoel, dan moet je een duurder model gaan kopen. Bij de XPS 13 krijg je voor zo'n 100 40 euro meer een dual core van vorige generatie terwijl de Windows versie een quadcore van deze generatie krijgt. Duurder voor lichtere hardware.

[Reactie gewijzigd door Nha op 22 juli 2024 18:02]

[Anoniem: 105188]

Waar heb jij het over?

http://www.dell.com/en-us...13/spd/xps-13-9360-laptop

En volgens mij kijk jij verkeerd op de Nederlandse site, de i5 modellen zijn misschien wel goedkoper, maar het zijn nog steeds i5 CPU's tov 7de generatie i7's in de developer edition. De reden waarom ze zich niet wagen aan 8ste generatie CPU's voor Linux ligt niet aan Dell overigens, dat ligt aan Linux, dus je commentaar slaat daarom al helemaal nergens op.

[Nha]

Want van de US site bestellen is normaal?
Je krijgt alsnog 4GB ram minder maar de prijs is daar idd goedkoper vergeleken met de Windows versie. In veel gevallen blijft het andersom.

While the Coffee Lake graphics are basically unchanged from Kabylake, currently they are marked as "alpha support" and thus will not be enabled by default on newer distributions unless booting with the i915.alpha_support=1 kernel parameter (or building your kernel with the Intel Alpha Kconfig switch). So silly that right now Ubuntu 17.10 and others don't have out-of-the-box accelerated graphics for Coffee Lake considering that I have yet to run into any problems and the graphics is basically unchanged since Kabylake.

Het ligt aan Ubuntu, wat er al meteen af zou vliegen zowiezo, dus het kan wel degelijk.

[Anoniem: 105188]

Het ligt aan Ubuntu, wat er al meteen af zou vliegen zowiezo, dus het kan wel degelijk.

Dus wat je nu zegt is dat Dell ook nog eens zijn eigen distro moet maken, ondersteunen en in die distro ook nog een drivers gebruiken die nog alpha zijn? Ik vind het sowieso raar dat je het Dell kwalijk gaat nemen dat ze een LTS versie meeleveren, er is geen enkele LTS distro met 4.15 en niemand gaat dev kernels leveren. Je draait oorzaak en gevolg om, als de Linux ondersteuning er was dan kon Dell de hardware leveren, niet andersom. Niemand gaat hardware bouwen voor software die niet bestaat.

[Reactie gewijzigd door Anoniem: 105188 op 22 juli 2024 18:02]

[Nha]

Nee ze moeten niet hun eigen distro maken, is al erg genoeg met wat ze nu offeren.
Ze leveren toch ook geen laptops met de LTS versie van Windows? Of met een oude versie van Windows tenzij je er misschien specifiek naar vraagt.
De hardware is volgens Phoronix een rebranded previous gen igpu (dus de software bestaat wel al), dus even een kernel parameter in grub zetten kan geen probleem zijn wanneer ze wel dingen toevoegen aan Windows.
Waarom niet gewoon een laptop zonder OS aanbieden? Als ik linux op mijn laptop wil gebruiken ga ik zowiezo niet de installatie van de OEM gebruiken, zelfs als ik dan alsnog Ubuntu zou installeren. De OEM versie van Windows blijft er ook nooit op.

[Anoniem: 105188]

Nee ze moeten niet hun eigen distro maken, is al erg genoeg met wat ze nu offeren.
Ze leveren toch ook geen laptops met de LTS versie van Windows? Of met een oude versie van Windows tenzij je er misschien specifiek naar vraagt.

Ja maar ze leveren ook geen laptops met Windows 10 Insider. De huidige Windows 10 release kan je zien als LTS. Windows LTSB kan je alleen als Corporate klant kopen, sowieso niet de bedoeling dat je dat spul op een desktop gaat draaien.

De hardware is volgens Phoronix een rebranded previous gen igpu (dus de software bestaat wel al), dus even een kernel parameter in grub zetten kan geen probleem zijn wanneer ze wel dingen toevoegen aan Windows.

Ik vraag me echt af of jij wel weet waar jij het over hebt?

https://lists.freedesktop...017-September/153059.html
https://lists.freedesktop.../2017-October/154486.html

Waarom niet gewoon een laptop zonder OS aanbieden? Als ik linux op mijn laptop wil gebruiken ga ik zowiezo niet de installatie van de OEM gebruiken, zelfs als ik dan alsnog Ubuntu zou installeren. De OEM versie van Windows blijft er ook nooit op.

Ach zit niet zo te zeuren, kijk bij Clevo, kijk op kickstarter. Genoeg aanbod. Jij bent een niks beduidende stukje van de markt (zeker als je wil dat ze alpha software gaan ondersteunen ook) en niemand gaat moeite nemen voor jou. Jammer voor je, maar dat is de realiteit.

[Reactie gewijzigd door Anoniem: 105188 op 22 juli 2024 18:02]

[Nha]

Ik weet dat het Phoronix artikel waar jijzelf naar linkte zegt dat het gewoon werkt en dat ze niet begrijpen waarom het nog alpha is (omdat ze er zelf nog geen problemen mee gehad hebben), en dat het simpel te enablen valt met een boot parameter. Dus wat is het probleem dan?

Ach zit niet zo te zeuren, kijk bij Clevo, kijk op kickstarter. Genoeg aanbod. Jij bent een niks beduidende stukje van de markt (zeker als je wil dat ze alpha software gaan ondersteunen ook) en niemand gaat moeite nemen voor jou. Jammer voor je, maar dat is de realiteit.

Klopt, en daarom willen we ook niet dat secure boot (mogelijks) enforced wordt. En dit is iets wat heel gemakkelijk kan vermeden worden door het niet als enige mogelijkheid te houden. Momenteel is dit nog niet het geval maar Intel lijkt er wel naartoe te neigen.
Als we kunnen blijven Windows laptops kopen en er zelf Linux op zetten is er geen probleem.

[Anoniem: 105188]

Ik weet dat het Phoronix artikel waar jijzelf naar linkte zegt dat het gewoon werkt en dat ze niet begrijpen waarom het nog alpha is (omdat ze er zelf nog geen problemen mee gehad hebben), en dat het simpel te enablen valt met een boot parameter. Dus wat is het probleem dan?

Ik weet niet waar jij dat leest, maar dat staat er absoluut niet (psssssst 11 October 2017).

Klopt, en daarom willen we ook niet dat secure boot (mogelijks) enforced wordt. En dit is iets wat heel gemakkelijk kan vermeden worden door het niet als enige mogelijkheid te houden. Momenteel is dit nog niet het geval maar Intel lijkt er wel naartoe te neigen.
Als we kunnen blijven Windows laptops kopen en er zelf Linux op zetten is er geen probleem.

Nou ik wil dat wel want ik wil betere hardwarematige beveiliging, en samen met mij de huis, tuin en keuken gebruiker. Dat jij je daarmee benadeelt voelt en dat jij daar een samenzwering in zit. Tja, jammer.

[Reactie gewijzigd door Anoniem: 105188 op 22 juli 2024 18:02]

[Nha]

Dus je hebt het artikel niet eens gelezen en mijn post ook maar half, heb het zelfs gequote voor je maar als je er gewoon wil langs lezen omdat het je ongelijk geeft, ga je gang. Maar ja, het werkte op 11 oktober al zonder problemen.

Wat is het probleem als jij secure boot aanzet en ik niet? Jij kan lekker je beveiliging hebben en ik kan lekker mijn vrijheid hebben. Waarom moet dat gelimiteerd worden?

[Anoniem: 105188]

Jongen zit niet zo slap te zeveren, dr staat "basically unchanged" (11 October 2017, voor het geval dat je het nog niet snapt... wanneer was de laatste hardware refresh bij Dell?). Dat wil niet zeggen dat de driver niet is veranderd (weet je nog die twee links?) of dat de driver tested werkt met de nieuwe hardware. De driver is al langer in alpha, dat wil niet zeggen dat je hem ook moet gebruiken. Die dingen ga je pas in productie gebruiken als ze daadwerkelijk worden ondersteunt (4.15). Je bent aan het mierenneuken alleen om een punt te maken wat er niet is.

Ga lekker naar Clevo en koop bij hun een laptop en hou die onzin voor jezelf. Eerst zat je te zeuren over dat je geen Linux hardware krijgt terwijl je dat wel hebt. Nu zit je te zeuren over dat je mindere hardware krijgt terwijl nieuwe hardware niet supported is onder Linux. Nu zit je te zeuren over dat hardware vendors jou moeten leveren wat jij wil omdat jij dat wil. Als dan blijkt dat het allemaal niet werkt dan zal het niet aan jou onzin eisen liggen, maar aan de hardware fabrikant, oh garantie periode dus ik zal hem maar terug sturen want het werkt allemaal niet.

Dat je iets aan/uit kan zetten betekent ook da malware het aan uit kan zetten. Zoek maar eens een paar defcon talks op over hoe ze dat allemaal misbruiken. Je commentaar slaat echt helemaal nergens op, je enige argument is dat jij het wil, jammer voor je want je krijgt het niet.

[Reactie gewijzigd door Anoniem: 105188 op 22 juli 2024 18:02]

[teacup]

Zouden die twee zaken van elkaar ontkoppeld worden dan kan dit dus de acceptatie van secure boot helpen. Anders gezegd neemt dit vendor lock mechanisme de goede aspecten van secure boot onnodig in gijzeling.

[KopjeThee]

Dat zou volgens mij ook een juridisch aspect hebben. Ik ben geen jurist, maar dan wordt het een echte koppelverkoop (voor zover het dat nu nog niet is). https://nl.m.wikipedia.org/wiki/Koppelverkoop

[flippy]

dat heeft apple toch ook met IOS/OSX?

[KopjeThee]

Ja.

[vSchooten]

Mijn laptop had secureboot aan staan, maar dat kun je prima uit zetten.

[flippy]

nog wel.

[vSchooten]

ik hoop dat dat niet zal veranderen
Anders zullen mensen hun bios/uefi nooit meer updaten en/of hun uefi firmware downgraden/hacken om dat toch te kunnen doen.

[ard1998]

niet aleen linux distros, maar ook de hobby besturingssystemen zullen hier zwaar onder te lijden hebben. hierbij zoals mike os http://mikeos.sourceforge.net/ en menuetOS http://menuetos.net/

[InsanelyHack]

Ja volgens mij ook voor het draaien van een hackintosh is het een vereiste als ik me niet vergis.

Oh jawel. Kan wel al moet je zelf keys opvoeren.

[Reactie gewijzigd door InsanelyHack op 22 juli 2024 18:02]

[Musical_Tweaker]

Enig idee hoe dit straks gaat met zaken als pfsense ?
Het laatste wat ik er van gehoord heb is dat dit nog steeds niet 100% stabiel draait met secure boot

[jimzz]

Mij lijkt het eerlijk gezegd dat hobby osjes in vmware gedraaid worden of iets dergelijks. En vaak met hobby besturingssystemen wil je dit niet op je daily driver doen en gebruik je waarschijnlijk een oudere pc om dit te doen. Maar ik snap je punt. Naar mijn weten kun je zelf keys importeren en volgens mij is het ook mogelijk om keys te genereren al zou ik geen flauw idee hebben hoe dat werkt.

[Terracotta]

Die spiksplinternieuwe pc met secure boot zal ooit de oude rommel zijn waar je mee experimenteert...

[jimzz]

Maar ik neem aan dat we dan ook zelf keys kunnen genereren en importeren (wat volgens mij al mogelijk is hoor) maar goed zouden we tegen die tijd anders geen omzeilingen hebben in de zin van custom uefi flashen? Er zal vast wel iets komen waardoor we het wel kunnen. Nogmaals ben er niet zo in thuis, het is me onlangs gelukt secure boot in te schakelen na een hoop errors gehad te hebben.

[sympa]

Het idee van security is dat je dus geen custom BIOS kan flashen. De CPU start alleen op als de bootloader klopt. Die laadt alleen de UEFI als de UEFI klopt. Enzovoorts.
Als je een van die stappen kan veranderen zonder dat de gebruiker het ziet kan je zijn systeem compromitteren.
Google had/heeft dat bij de Chromebooks opgelost door 'decurity off' te koppelen aan een waarschuwing die je moet wegdrukken als je het systeem start. Misschien is dat nog de beste oplossing, al is ie niet helemaal gebruiksvriendelijk en bovendien moet je het systeem dan wel opstarten om het te zien.

[_Thanatos_]

Je kunt Secure Boot ook gewoon uitzetten.

[NanoSector]

Volgens mij is dit proces zo simpel nog niet. Dit artikel laat een paar van de stappen zien waar fedora doorheen moest: https://www.pcworld.com/a...fi_secure_boot_plans.html

[Geekomatic]

Hmm, dus alternatieve (Linux) OS makers kunnen *nu* zelf nog hun OS maken en secure laten booten.
Ze hebben hiervoor alleen wel de medewerking van Microsoft nodig voor het signen.
Als zodirect alle nieuwe PC's alleen nog maar secure kunnen booten,
kan Microsoft de stekker uit deze "signing" hulp trekken,
En "poof", no more Linux...
.
Erg zorgelijk dit.
Ik hoop dat er alternatieve hardware aanbieders blijven.
Die zal ik kopen.

[NanoSector]

Je kan het altijd nog uitzetten, niets wat je stopt. De nieuwe PCs gaan dus niet alleen maar met secure boot opstarten.

Linux zal altijd blijven want het word ontzettend veel gebruikt op servers, met processors die uiteindelijk toch van dezelfde fabrikanten af komen.

[119961]

Vrij vertaald doom scenario: Thuis is een serverboard de enigste optie om Linux te draaien.

[StefanJanssen]

Of ARM linux.

[NanoSector]

Dat is dus precies het omgekeerde van wat ik zeg.

[Geekomatic]

Het doel van de presentatie lijkt wel degelijk om alles naar UEFI Class 3+ te krijgen,
waarbij Secure Boot altijd aan staat, en CSM (legacy boot) gaat verdwijnen.
Zie bijvoorbeeld pagina 11.
.
De houders van de sleutels, die EUFI van de PC herkent, hebben dan de macht
over wat er *wel* en wat er *niet* opgestart mag worden.
Zij moeten die code namelijk eerst signen.
.
De eigenaar van de PC kan dan dus niet meer volledig beschikken over zijn PC.
Brrrr, dat wil ik niet...

[Reactie gewijzigd door Geekomatic op 22 juli 2024 18:02]

[NanoSector]

Misschien uiteindelijk wel. Maar zelfs dan nog is er niks aan de hand omdat de UEFI specificatie niet voorschrijft wie er wel en niet keys mogen opslaan; je bent dus vrij om je eigen keys toe te voegen. Ik las laatst een artikel waarin het vergeleken wordt met de package manager op veel Linux distros; je hebt daar ook een keyring in waar standaard alleen de keys van je distro's makers in staan.

[Xeon_1]

Het moet uitzetbaar zijn.
Heb op school tablet van medion waar dit niet gaat.
Enkel de bijgeleverde win8 is te installeren zelfs win10 ISO,s werden niet aanvaard (stick of dvd)
In die kak uefi kon je enkel de klok goed zetten

Na die ervaring geen medion voor mij.

Heelndar secure boot gedoe is een kanker .
Vega geen buis mod meer door secure boot vereiste.

[Reactie gewijzigd door Xeon_1 op 22 juli 2024 18:02]

[oja]

http://www.spatiegebruik.nl/regels.html

[Xeon_1]

ik heb geen respect voor mensen die mij wat uitschelden voor een vraag te stellen.

[psychicist]

Of Intel doet gewoon zijn werk en zorgt er zelf voor dat Secure Boot ondersteuning in de Linux kernel zit. Intel lijkt de afgelopen jaren zijn verantwoordelijkheid weer meer uit de weg te gaan en daardoor verschijnt goede ondersteuning voor nieuwe features vaak veel later in de Linux kernel en distributies.

Het maakt mij niet zoveel meer uit, ik wacht op een degelijke ARM laptop waarop ik gewoon Linux zonder Secure Boot en soortgelijke kan draaien. Mijn huidige met Skylake houdt het nog wel een aantal jaar vol, alleen daar zitten ook al wat haken en ogen aan voor Linux gebruikers.

[SuperDre]

nee dat klopt niet, ook Linux ondersteund gewoon secure boot. En als gebruiker kun je secure boot gewoon uitschakelen wanneer je een ander OS wilt installeren. Het is gewoon weer panisch gedrag om niets.

[flippy]

dat is een veel te kleine stap voor de fabrikanten om weg te laten. helemaal als microsoft nog eens wat geld neerlegt of extra korting op hun OS geeft ervoor.

[oef!]

Waarschijnlijk draait meer dan de helft van de servers ter wereld op linux, intel is echt niet zo gek om hun eigen glazen in te gooien.

[flippy]

dit gaat om consumentenspul, niet servers.

[oef!]

Nope, in het laatste plaatje staat ook data center platforms.

[Blokker_1999]

En wie zijn hulp heb je nodig om je distributie vlot installeerbaar te maken met SB aan?

[SuperDre]

niemands hulp anders dan een simple google search te doen van hoe je het uitschakeld.

[HKLM_]

Is dat niet alleen van toepassing bij de 3+ met secure boot ? Zonder kan je toch gewoon Linux installeren.

[Reactie gewijzigd door HKLM_ op 22 juli 2024 18:02]

[UPPERKEES]

Fedora en Ubuntu hebben support voor Secure Boot, kan prima aanstaan op die systemen.

[dmantione]

Dan moet je wel het volledige verhaal vertellen: Met een sleutel van Microsoft. Linux is dus voor secure boot van de concurrent afhankelijk om te draaien... geen situatie die je wilt.

[CR2032]

Je kunt in Linux anders ook je eigen keys aanmaken voor Secure Boot.

[Cilph]

En wat als je die niet kan importeren in je UEFI?

[Dennism]

Klagen bij je mobo / device fabrikant dat ze een UEFI release uitbrengen die dit wel kan.

[dmantione]

Dan is het kwaad al geschied: Het staat vaak niet in de technische specificaties vermeld, dus in veel gevallen zal de laptop al gekocht zijn. Soms wordt ook pas later in de levensduur besloten Linux te installeren. UIteraard moet je klagen, maar feit is wel dat Linux met zijn marktaandeel nog weinig macht heeft en fabrikanten eenvoudig geneigd kunnen zijn in ruil voor 1 euro korting op de WIndows-licentie deze functie uit hun BIOS te halen.

[SECURITEH]

_{Moet een gebruiker dit doen of kan de partij die een distro maakt dit doen voor al hun installaties?}

[jimzz]

Ik heb nog een oud moederbord en daarbij kan ik handmatig keys importeren. Dit heb ik niet geprobeerd en durf eerlijk gezegd niet te zeggen of die distro’s het erbij geven of dat je het zelf moet genereren (ik gok helaas het laatste). Maar het is dus wel mogelijk.

[CR2032]

Als de distro het heeft hoeft de gebruiker niets extra te doen. Tenzij je uit principe geen Microsoft keys wilt gebruiken.

Meer info: https://wiki.archlinux.org/index.php/Secure_Boot

Ook als je geen Arch als distro gebruikt is deze wiki een aanrader.

[Anoniem: 105188]

Shim en GRUB2 ondersteunen Secure Boot en de grote distro's ondersteunen het ook in hun major releases. Het is een probleem voor de kleinere distro's, alternative OS'en en als jezelf je eigen kernel gaat compile.

[InsanelyHack]

Je kan natuurlijk altijd nog virtualiseren.

[flippy]

dus linux draaien bovenop je windows? beetje zonde van de ram die je kwijtbent en de problemen die VM's met zich meebrengen, nog maar te zwijgen over de toegang tot de ssd.

[InsanelyHack]

Hoe kom je daarbij? Nooit van Azure en Amazon Web Services gehoord? Die draaien al meer Linux dan Windows in hun Cloud stacks. En toegang tot de Ssd is ook niet echt een probleem.

[Reactie gewijzigd door InsanelyHack op 22 juli 2024 18:02]

[Nha]

Wat heeft dit te maken met je eigen hardware?

[InsanelyHack]

Er wordt aangegeven dat VMs problemen met zich meenemen. Ik geef als tegenargument weinig want zelfs zakelijk draaien gigantische hoeveelheden op basis van dit princiepe in de publieke Cloud. Dit werkt zo goed als probleemloos op vrijwel iedere hardware. Inderdaad er is wat performance verlies en ja je verliest wat resources zoals geheugen van de host die dit aan de guest aanbiedt. Maar in moderne pc’s met tegenwoordig al minimaal 16GB instap en dadelijk in 2020 wellicht 32GB als mainstream instaphoeveelheid zie ik niet in dat een host tijdelijk 4-8GB kan missen om een Linux vm te draaien. Ik snap dat een doorgewinterde Linux liefhebber liever geen Windows als hostOS wil draaien maar wellicht is een mac dan wat ;-) of een hackintosh.

[Nha]

Want een datacenter aan hardware is hetzelfde als de gemiddelde consumentenlaptop?

[InsanelyHack]

Het is gewoon x86 verder niks fancy aan. Juist Cloud providers gebruiken commodity spul wat nauwelijks verschilt van een gemiddelde pc thuis. Meer geheugen, meer vCPU’s, meer PCIe lanes, andere chipsets. Zo goed als iedere hypervisor is te installeren op een laptop alhoewel de netwerkkaart meestal wat moeilijker is als er een realtec inzit.

[Nha]

"nauwelijks verschilt" "meer, meer, en andere" lekker jezelf tegenspreken. Ik wil het eerste datacenter nog zien dat VM's draait op een dualcore i5 die je in de gemiddelde consumentenlaptop tegenkomt. Met dan nogg eens Windows 10 als host OS. Dat wordt simpelweg niet gedaan. Omdat het dom is.

[Nha]

Ik leg je helemaal geen woorden in de mond. Je zei zelf dat het nauwelijks verschilt. Dat het dezelfde architectuur heeft betekent niet dat er nauwelijks verschil in zit. Ik zeg alleen dat een datacenter geen hardware gebruikt die nauwelijks verschilt, want dat is belachelijk. Zelfs tussen de consumenten hardware zit er een ton aan verschil. Anders waren benchmarks nogal nutteloos als het allemaal toch zowat hetzelfde zou zijn.

[firest0rm]

Dit is appels en peren vergelijken. Het systeem wat Amazon en azure gebruiken is natuurlijk totaal anders dan Windows gebruikers die vmware draaien

[InsanelyHack]

Nee. Azure b.v. gebruikt hyper-v wat gewoon al in je Windows > 8.1 zit. Amazon gebruikt Xen van citrix als onderlaag waar idd geen desktop equivalent van bestaat. Qua hardware is het juist ook erg commodity.

[firest0rm]

Wrong, datacenter hardware is vaak speciaal en anders ingericht dan consumenten hardware.
Er zit een verschil tussen een i5/i7 cpu en xeon server apparatuur het een is gemaakt voor 24/7 stabiel gebruik het ander kan en heeft vaker minder stabiliteit. Fyi, zelfs bij X86 cpus van het zelfde model zijn er microscopische verschillen die veel invloed kunnen hebben op hoe stabiel een systeem zal draaien

[Reactie gewijzigd door firest0rm op 22 juli 2024 18:02]

[NanoSector]

Linux ondersteund ook prima UEFI en veel distro's als Ubuntu en Fedora ondersteunen ook Secure Boot. Ik geloof dus niet dat dit echt een probleem gaat vormen.

Bovendien zoals al vaker aangemerkt in het artikel en de reacties, het gaat om class 3 en niet 3+, 3+ vereist dat Secure Boot standaard aan staat.

Edit: Nederlands is moeilijk

[Reactie gewijzigd door NanoSector op 22 juli 2024 18:02]

[NanoSector]

Dat zijn twee voorbeelden en toch wel van de meest prominente. Je hebt ook Debian, openSUSE, CentOS, RHEL, SUSE, Linux Mint, ...
Je kan zo nog wel even doorgaan. Als ik van alle distros een lijstje moet maken ben ik nog wel even bezig

[jbhc]

Ok, my bad

Ik, als Linux gebruiker, heb al heel lang een slecht gevoel over UEFI.
Je reactie heeft me aan het googlen gebracht om nu toch eindelijk maar eens uit te zoeken wat UEFI (onder andere voor linux) eigenlijk inhoud en uiteindelijk kwam ik hier uit:

https://www.happyassassin...-that-actually-work-then/

Een goed leesbaar stuk en het heeft mijn mening over UEFI veranderd; Zoals ik het nu zie is er met UEFI eigenlijk niks mis en is het zelfs een goede zaak. Zelfs met Secure boot is er niks mis.

De slechte naam die UEFI bij veel mensen heeft komt niet zozeer door UEFI maar door bepaalde bedrijven die de UEFI standaard proberen te "misbruiken" door anderen uit te sluiten en er zelf beter van te worden.

[Anoniem: 62011]

Chrome OS is Linux en Android is Linux en draaien op intel systemen..
Daar kun je geen Windows op installeren.
Koop gewoon wat je nodig hebt en stop met zeuren over wat er niet mogelijk is.

[Nha]

En sommige mensen willen de keuze hebben. En dat moet gewoon kunnen, we worden al genoeg afgezet.

[Anoniem: 62011]

Je hebt de keuze ook maar het heeft ook geen zin om achteraf te klagen dat je Battlefield 1 niet kunt spelen op een Chromebook.

[Nha]

Nu heb je de keuze nog, als dit zo blijft doorgaan kan dit wel eens anders zijn. Kunnen kiezen wat OS je gebruikt heeft ook helemaal niks te maken met of de hardware krachtig genoeg is voor iets waar het nooit voor bedoeld was.

[Anoniem: 62011]

Maar het is hetzelfde principe. Wil je Linux op je PC/laptop dan informeer je van tevoren of dit mogelijk is.

[Nha]

Behalve dat die mogelijkheid altijd al bestond en mogelijks binnenkort actief gesloopt wordt. Dus neen, het is helemaal niet hetzelfde principe.

[jpsch]

Nu wil je misschien geen Linux, maar over 8 jaar misschien wel, of een heel ander OS.
Het is alsof je je vastlegt bij Shell te tanken met je nieuwe auto.

[Xeon_1]

Leuk als je daar het geld voor hebt
Maar we hebben niet allemaal zo en diepe zaken

[Gymnasiast]

Zoals _duidelijk_ in het artikel staat, wordt Secure Boot niet verplicht.

[Terrestrial]

psies het wordt steeds gekker, fabrikanten die straks gaan bepalen wat ik op mijn pc hardware mag draaien. Straks zeggen ze bijv... wil je windows server dan moet je maar server hardware kopen of je mag die alleen nog virtueel draaien. Op zich is secure boot geen probleem maar de macht komt bij de fabrikanten te liggen ipv bij de koper van de hardware.

[Bench]

Ooit gehoord van Ubuntu ??
Klakkeloos iets roepen en denken dat je daarmee scoort is wel heel erg ....

[flippy]

en jij ziet de doorsneel gebruiker dit doen? of als (een bedrijf) een oudere versie van windows of zo zou willen installeren vanwege compabilliteitsissues met hun bedrijfssoftware en dat mag niet van het bios/uefi omdat er een deal is gesloten tussen intel en MS hierover? graag iets verder denken wat deze mogelijkheid bied aan bedrijven zoals microsoft en apple (geen bootcamp meer).

[Bench]

Ja dat zie ik inderdaad gebeuren.
En oude software? Die tijd zijn we al voorbij.

[flippy]

dan ben je kennelijk nog nooit in een industrieel bedrijf geweest. meeste aparatuur draaien xp op zijn best.

[Bench]

Ik ontwerp machines voor staalbuiging.. Als er iemand in een industrieel bedrijven komt ben ik dat wel. En PLC's waar de meeste machines op draaien lopen niet op XP zoals jij zegt.

[Rakkachi]

Als AMD dat niet volgt krijg je dan straks 2 kampen ? 1 met oude bios en 1 met uefi ? Of kan AMD niet anders dan volgen ?

[supersnathan94]

Ik denk het eerlijk gezegd niet. Voor AMD is dit een uitgelezen kans om juist meer linux systemen mogelijk te maken. Iemand die multiboot wil zal dan eerder AMD kiezen wegens de vrijheid van OS die dat dan meebrengt.

[Arokh]

Dat is geen enorm grote markt. En heeft AMD baat bij het promoten van Linux?

[nelizmastr]

Iedereen heeft baat bij het promoten van Linux. Hoe meer keuze voor de consument hoe beter. De hele wereld in de greep hebben van Microsoft is geen wenselijke situatie.

[Arokh]

Nee, maar als AMD Linux actief promoot kan het natuurlijk wel zo zijn dat Microsoft minder toeschietelijk is bij AMD met fixes, ondersteuning etc... Voor de consument nog steeds op de lange termijn slecht, maar voor de korte termijn (aandeelhouders) slecht...

[nelizmastr]

Maar dat zou machtsmisbruik zijn en dat is illegaal indien aantoonbaar

[Arokh]

Klopt. Maar ik denk dat wij beiden weten dat dat soort dingen wel meespelen.

[Joostlek]

Toevoegen kan altijd, de normale gebruiker merkt dit nagenoeg niet. Laat ik daarbij aannemen dat deze BIOS software al jaren wordt gebruikt, dus dan neem ik aan dat het veilig (genoeg) is. (Dus dat het ook nog meerdere jaren gebruikt kan worden)

Voor de normale gebruiker is dit niet van belang. Voor de poweruser is dit een pluspunt en misschien wel de druppel voor een beslissing van welke processor

[Bench]

Natuurlijk hebben ze daar baat bij. Stel je koopt een systeem waarmee je beperkt bent tot 1 of 2 besturingssystemen en het andere merk blijft ondersteuning bieden voor alle soorten besturingsstystemen dan lijkt het me heel duidelijk waar men voor gaat kiezen lijkt mij. En linux is geen grote markt ? Geloof niet dat je weet wat je zegt.

[Arokh]

Ik geloof er niks van. Intel gaat natuurlijk haar serverchips niet ontdoen van Linux installatiemogelijkheid.

Als er al een echte onmogelijkheid wordt geschapen door Intel om nonMS te installeren dan zal dat hooguit gelden voor de OEMlaptopbordjes etc waar het voor bijna niemand relevant is. De sectoren waar Linux groot is, gaan hier echt geen last van hebben.

[svennd]

Precies of de OS wereld daar geen workaround voor gaat vinden ... hoewel consumenten computers vrijwel geen Linux gebruiken is voor servers een groot deel Linux. Die gaan niet allemaal AMD draaien, alsook Intel gaat dat niet laten gebeuren

[lonaowna]

Er is maar 1 kamp: UEFI. AMD ondersteunt dit ook al vele jaren. Zij zullen op termijn ook wel stoppen met legacy BIOS compatibiliteit.

[dmantione]

Zeker, alleen moet AMD wel voorzichtiger zijn dan Intel, omdat ze de underdog zijn, kan incompatibiliteit zich snel tegen hun keren. AMD past daarom een afwachtende houding, pas als er op grote schaal computers zonder BIOS in de markt gezet zijn, kan AMD overwegen te volgen.

[--Andre--]

Nou ik heb in principe niks tegen UEFI, maar Secure Boot daar heb ik wel een probleem mee. Mijn machines booten, zover mogelijk, allemaal Linux via UEFI.
Ik bedoel maar, booten op zijn jaren '80, compleet met gate A20, nee dat is niet meer van deze tijd.

[ArcticWolf]

Hoewel vanaf 2020 uefi class 3 standaard wordt bij Intel-producten en niet 'class 3+' met secure boot ingeschakeld, wijst Intel wel op de beveiligingsvoordelen van die techniek.

Geen probleem dus

[darkfader]

Ik vind het ook prima zolang dingen maar blijven werken. Had nu toch een keer last na een Windows update dat het systeem niet meer opstartte totdat ik secure boot had uitgezet.
En A20, IDE mode, MBR etc. allemaal weg. Ik snapte de UEFI,GPT,AHCI instellingen/vereisten op oude systemen ook niet helemaal. DELL enzo. AHCI hacks... yuck.
En een optie om die ME uit te zetten zou ook niet verkeerd zijn.

[Reactie gewijzigd door darkfader op 22 juli 2024 18:02]

[robkorv]

Je kan nu toch ook al Linux toevoegen aan secure boot en installeren via eufi?

Lijkt me dat dit nog steeds kan in 2020.

[MeMoRy]

Voor een dual-boot (windows 10/ubuntu 17.10) installatie moest ik (paar weken geleden) toch secure boot uitzetten, volgens een tutorial.

[Reactie gewijzigd door MeMoRy op 22 juli 2024 18:02]

[InsanelyHack]

Volgens mijnis er geen echte noodzaak om secureboot uit te zetten. Dat het vaak wordt gezegd dat je het maar moet uitzetten komt omdat de alternatieve boot.efi de juiste keys moet hebben in de uefi bios. Dit gaat veel mensen te ver. Het is zelfs mogelijk een hackintosh met een alternatieve boot.efi die word gebruikt door de bootloader toch te laten booten middels secureboot als de keys kloppen.

[Armin]

Klopt, maar als je geen key-verificatie hebt is er toch weinig bescherming in het gebruik van secure boot. Dus dan kan het net zo goed uit.

Voor Linux zie ik dus weinig bezwaren. Voor de professionele markt zullen die systemen met een Ubuntu etc key geleverd worden, en voor de thuis-gebruikers zullen die net als nu gewoon secure boot uitzetten of een Microsoft key gebruiken.

[InsanelyHack]

Ja maar ik gaf het aan dat wanneer in 2020 ieder os met secureboot gestart moet worden er een mogelijkheid is je je eigen boot.efi kan signeren als de boot.efi dus komt van een os die standaard dit niet ondersteunt. Of eigenlijk een OS die dit gemakshalve skipped omdat het makkelijker is je klanten secureboot uit te laten zetten.

[Armin]

Ja maar ik gaf het aan dat wanneer in 2020 ieder os met secureboot gestart moet worden

Maar dat zegt Intel dus niet Integendeel!

Of eigenlijk een OS die dit gemakshalve skipped omdat het makkelijker is je klanten secureboot uit te laten zetten.

Als Linux een significant marktaandeel heeft zullen OEM's vanzelf deze feature uit laten zetten in de UEFI configuratie. Zo niet kan het inderdaad een probleem worden, en zullen Linux fabrikanten net als nu bij Microsoft hun eigen loader laten ondertekenen.

[InsanelyHack]

Je hebt gelijk. Ze ondersteunen ook 3 tov 3+ waar het wel verplicht is.

[Legosteen11]

Eh, dan moet je bootloader wel gesigned zijn met een private key van Microsoft...

[Armin]

Of een eigen key toegevoegd zijn. Bij af-fabriek Linux systemen voor de professionele markt is dat soms al zo. Alleen de thuis-gebruiker OEM's doen dat doorgaans niet.

[MeMoRy]

"en dat zo het gebruik van nieuwe technologie aangemoedigd wordt."
Betekent dat dat ze hiermee willen stimuleren dat we meer nieuwe producten kopen, door de oude (die het vaak nog goed doen) niet meer te supporten?

[--Andre--]

Doorgaan met legacy stuff zoals Gate A20, om geheugen voorbij 1 Megabyte aan te speken, in een tijd waarin er Gigabytes aan geheugen in een PC zitten... terwijl niemand meer zijn oude doos met 5¼" floppies boot en software draait die ooit voor een 8088 geschreven is, op zijn gloednieuwe i7.

[RoffaboyS]

Over monopoly gesproken ze beginnen op Apple te lijken alles op slot. Maar je weet het sloten worden altijd gebroken.

[InsanelyHack]

Ja inderdaad door Unit 8200 uit Israël zodat ze een rootkit kunnen planten. Misschien een beetje "to obvious" voorbeeld maar vandaag de dag beveiligingsmaatregelen wegwimpelen onder het mom van "ze willen alles op slot zetten" en "ze beginnen op Apple te lijken" is wel erg zielig gesteld.

[mashell]

Een slot dat open gebroken kan worden is nog altijd een betere beveiliging dan geen slot.

[Tennie]

Oh god, na al die computers die ik in elkaar heb gezet/Windows 10 heb geïnstalleerd op de meest recente chipsets, weet ik inmiddels wel dat er af en toe nog componenten zijn die samen met de drivers nog niet echt lekker werken met die uefi(bsod's enz), dan stel ik het in de bios toch echt nog weer in op legacy-installaties, maar dat kan dan vanaf 2020 niet meer.

[MadEgg]

Wat voor systemen heb je dan in elkaar gezet? Met antieke componenten? Ik ben nog niets tegengekomen wat met BIOS wel werkt en UEFI niet. Ook niet zo raar, anders dan het moederbord en de videokaart heeft er niet zo veel mee te maken hoe het systeem gestart wordt.

Mocht je echt een modern component tegenkomen dat niet met UEFI samenwerkt zou ik het linea recta terugsturen naar de fabrikant.

[Tennie]

Nou ik heb onlangs een paar keer gehad dat notabele de grafische onboard drivers van Intel niet lekker werkte (vastlopers), na legacy geen probleem. Daarnaast heb ik inderdaad bij het gebruik van (wat jij antiek noemt), normale oudere geluidskaarten (die dingen gebruik je gewoon 5+ jaar), vastlopers gehad na het installeren van de drivers, legacy was nodig. En zo heeft mijn eigen PC (MSI Z68) het jaren lang op UEFI niet gedaan (tot Windows 10 op een miraculeuze manier). Dus om te zeggen dat het altijd maar perfect werkt en we direct maar over moeten stappen vind ik nog een beetje lastig.

[PanaLover]

In het laatste plaatje staat alleen client en datacenter platforms, daaruit maak ik op dat het voor de pc van Jan met de pet het nog wel kan.

[maescool]

Deze video heeft mogelijks relevantie, secure boot kan ook niet bepaald aanzien worden als secure
https://www.youtube.com/watch?v=iffTJ1vPCSo

[cdwave]

Je was me voor (ik zat linksachter in de wel heel erg volle zaal, wat al een teken was hoe hot dit topic was).
Jep, de UEFI zooi is een groot bugnest vol met exploit gaten. En helemaal nergens voor nodig.