Dit soort situaties is precies waarom je bij de introductie van secure boot zoveel negatieve geluiden uit de FOSS hoek kwamen. Het is natuurlijk van de gekke dat MS wel even kan bepalen of anderen iets moeten updaten, en dat andere afhankelijk zijn van de goodwill van MS om te zorgen dat ze kunnen (blijven) booten. Alsof MS de autoriteit is op het gebied van secure booten ;-)

" Alsof MS de autoriteit is op het gebied van secure booten ;-)"

In het land der blinden, is een oog koning. En pak dan die macht nog maar eens af.
Open source is een hartstikke positief uitgangsprincipe, maar de realiteit is dat het soms alsnog gewoon een bende is; en daar waar geld regeert, zijn organisaties al helemaal niet bereid te investeren in (de kwaliteit / verbetering van) 'gratis spul', zeker niet als de concurrent(en) daar mogelijk ook hun voordeel mee doen; hoe kortzichtig dat dan ook wel of niet is ...

https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_timing

Ik vind het doodeng. Ik ga nog liever mijn BIOS updaten met een 3 1/2" floppy zoals dat vroeger ging. Die floppy kan je tenminste goed testen voor je naar de firmware schrijft. Ik voel dat ik hier helemaal geen controle over heb.

TS

P.S. KB5034441 komt nog steeds met een Download error - 0x80070643. Deze moet ook een Secure Boot update krijgen om te kunnen werken maar mijn partitie is te klein om de update te kunnen bevatten. Misschien denkt Microsoft dat het vanzelf een keertje lukt als je maar vaak genoeg probeert.

Hallo, hier TS,

Ik ben tot de ontdekking gekomen dat er bij Ubuntu updates voor Secure Boot zijn gekomen voor Mantic Minotaur en Noble Numbat: https://packages.ubuntu.com/noble/shim-signed -> Ubuntu Changelog:

Debian Sid lijkt echter tijdelijk gestopt te zijn met Secure Boot, de laatste changelog is:

De melding dat ze geen secureboot-db hebben is onheilspellend. shim-signed voor Ubuntu wordt onderhouden door Canonical zelf, dus dat zit wel goed. Dit geldt waarschijnlijk ook voor Linux Mint.

Ik zag bij Ubuntu dat er twee signed shims zijn in de shim-signed package. Dus eentje ondertekend met Microsoft Windows Production PCA 2011 (deze gaat over een half jaar verdwijnen door toedoen van Microsoft). En eentje ondertekend met Windows UEFI CA 2023 vermoed ik.

Het is mij niet helemaal duidelijk of Microsoft aparte sleutels gebruikt voor het ondertekenen van Windows en het ondertekenen van Linux en andere third parties.

TS

Volgens mij wel, maar dat was al genoemd in de voorgaande thread over dit onderwerp.

Bijvoorbeeld
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/updating-microsoft-secure-boot-keys/ba-p/4055324

hieruit

en

Vrij duidelijk dus dat ze een aparte CA gebruiken voor het signen van third-party OS loaders.

Deze link is helemaal achterhaald sinds een week geleden. Er is op patchdinsdag echt heel veel veranderd. En de informatie die er in staat moet ook ergens anders officieel aanwezig zijn op de site van microsoft.

Ik kom uit op https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-10
Omdat Microsoft Windows Production CA 2011 en Windows UEFI CA 2023 verplicht zijn voor alle windows computers, worden deze gebruik door linux om de shim te ondertekenen.

Microsoft Corporation UEFI CA 2011 en Microsoft UEFI CA 2023 zijn niet verplicht door Microsoft en daardoor minder geschikt voor linux (omdat linux dan niet op alle PC's zou kunnen draaien).

De KEK keys zijn helemaal off-limit voor linux omdat daarmee de db en dbx databases gemanipuleerd kunnen worden. Als die lekken dan is het game over voor Microsoft en Secure Boot. Een aanvaller kan daarin dan zetten wat die wilt.

Ik beantwoord hiermee ook eigenlijk mijn eigen vraag al.

TS

P.S. Ik vind de naamgeving van Microsoft voor de db sleutels heel onduidelijk.

Hallo, hier TS,

Er zit een nog niet opgeloste bug in Ubuntu 24.04 LTS waarbij je computer niet meer opstart. https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/2061551. Dit vindt plaats bij een Asus Tablet met Windows 10 en een Intel Atom processor.

Het probleem lijkt op het probleem met de MOK table in shim-signed 1.48

Het lijkt erop, als je de LP's leest, dat de 64 kB ruimte voor Secure Boot sleutels op het moederbord vol raakt. Omdat Microsoft deze sleutels vast kan zetten in dit geheugen, kan dit tot problemen leiden. Zelf heb ik een Asus moederbord, maar dan een OEM voor AMD dus ik hoop dat deze dit probleem niet heeft.

Ik ben wel bang om Xubuntu 24.04 LTS nog te booten op mijn machine. Ook omdat er nog geen oplossing voor is en ik dus opnieuw een moederbord kan kopen met te veel fabrikant sleutels erop of gewoon te weinig geheugen voor de plannen van Microsoft en Canonical.

Als je geheugen ergens vol loopt (wat hier het geval lijkt) dan krijg je allerlei onvoorspelbare problemen. Minix (de voorloper van Linux) ging dan willekeurig processen killen om een voorbeeld te geven. Als je harde schijf vol loopt kan er ook van alles mis gaan. Je wilt dus absoluut voorkomen dat dit gebeurt.

Nog een voorbeeld van wat voor een ramp Secure Boot is geworden en dit was allemaal te voorzien.

TS

Goed nieuws! De definitieve blokkade van Windows Production PCA 2011 in de DBX van je moederbord is nu uitgesteld naar januari 2025 of later. Dit was oktober dit jaar. Dit betekent dat linuxen meer tijd hebben om hun bootmedia geschikt te maken voor Windows UEFI CA 2023.

Verder zijn er ook veel andere wijzigingen. Zie https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d.

Misschien komt van uitstel zelfs afstel (dat zou mooi zijn).

TS

FOSS heeft geen oplossing....

Microsoft wel, met TPM en keys in UEFI ben je gegarandeerd malware free in je bootsequence (anders boot ie niet)

De enige alternatieven met secure boot zijn Google producten (telefoons , tablets)

Of je moet gaan klooien met Coreboot, Dasharo en plugins zoals HEADS, wat maar op een paar moederborden werkt... Als je wil klooien met eeprom programmers that is...

Welke andere oplossing is er?

Microsoft en Google bieden verified boot, en FOSS loopt jaren achter (sinds 2017 ongeveer)

Als Secure Boot zo veilig is, waarom moeten dan de encryptie sleutels hiervan worden vervangen?

Vroeger had je een real-time virusscanner ter preventie, en een rootkit scanner voor detectie. Malwarebytes Anti-Malware heeft nog steeds een rootkit scanner die ik wekelijks gebruik op een MBR partitie.

TS

Het is duidelijk dat je niet voor ogen heb dat de rootkit al actief kan zijn voordat jij met mailware bytes kan scannen. Kortom.... dat wordt hem dus niet... Met MBR had je dat niet als je boot vanaf een bootable device, maar met de UEFI is dat anders...

Verified Boot controleert je bootsector en kernel voordat deze geladen worden... Daarom is antivirus in ring2 overbodig

Antivirus checkt achteraf...

Dat is een fundamenteel andere aanpak

Linux heeft hiervoor geen oplossing...


Windows heeft dit sinds ca 2017 als reactie op de vele cryptolockers toen. Nu zie je alleen cryptolocker infecties bij mensen die hun Windows niet hebben gesealed met Verified Boot in de TPM na installatie.... Dus je kunt stellen dat dit een heel goede oplossing was.

Als je een AV zou gebruiken bij bepaalde type malware, zou het kwaad al geschied zijn nog voordat je aan scannnen toekomt....
Bij de Verified Boot methode zie je dan een error, zodat je op tijd je harddisk content kunt redden voordat deze AES versleuteld is door criminalski software.

Maar als Secure Boot zo veilig is, waarom moeten alle cryptografische sleutels dan vervangen worden door Microsoft?

Wat ik zie is een hoop ongemak bij gebruikers van andere systemen als Windows en een extra aanvalsoppervlak door de buggy code die Secure Boot implementeert. Is het het waard dat je een theoretische beveiligingslaag hebt toegevoegd?

Misschien zijn de ransomware bendes zich gaan richten op servers van grote instanties in plaats van op burgers. Dat is ook een mogelijke verklaring. Als alles in de cloud zit, waarom zou je dan nog burgers aanvallen met ransomware? Val meteen de cloud aan voor een veel groter effect.

TS

Debian begon met het controleren van digitaal ondertekende checksums van geïnstalleerde bestanden (binaries, scripts en configuratie) 20 jaar voor secure boot werd geïntroduceerd. Wat dan wel weer jammer is dat ze voor die checksums nog steeds MD5 gebruiken, wat prima is om lees- en schrijffouten op te vangen maar niet meer voor gerichte aanvallen. Wet van de remmende voorsprong, maar ze liepen wel 20 jaar voor op Microsoft.

Nee, er wordt niet op malware maar op digitale handtekeningen gecontroleerd. Als een leverancier zelf gecompromitteerd raakt en er malware in ondertekende bootsequence-binaries belandt dan worden die vrolijk uitgevoerd.

Ook is de bootsequence lang niet alles. Het is niet voor niets dat je nog steeds antivirussoftware op Windows nodig hebt, terwijl dat op een goede Linux-distro praktisch gesproken typisch geen donder toevoegt. De belangrijkste beveiligingsmaatregel is dat het een distributie is: een gecontroleerde verzameling op elkaar afgestemde software die je uit maar een of enkele bronnen haalt. Dat verkleint de kans op ellende substantieel. Al geeft het net als secure boot geen 100% garantie, het werkt in de praktijk heel goed.

Er is iets grappigs met die boot sequence. Wist je dat de term BIOS (Basic Input/Output System) van CP/M afkomstig is, en daar niet iets in een geheugenchip op het moederbord was maar gewoon een onderdeel van het besturingssysteem dat (toen typisch) van een floppy werd geladen? Het is de IBM-pc geweest waar de BIOS naar een geheugenchip op het moederbord verhuisde, eerst ROM (die je uit de socket kon wippen om hem te vervangen), toen EPROM, later flash.

Het kan dus anders, en het gebeurt ook nog steeds. Bij de Raspberry Pi zit er geen BIOS op het moederbord, daar moet de eerste partitie op het micro-sd-kaartje (even uit mijn hoofd) FAT32 zijn, en daarop staat een generiek bestand met bootcode dat wordt geladen, en een hele reeks modelspecifieke bestanden waarvan de juiste daarna wordt geladen.

De eerste floppy disks zijn door IBM ontwikkeld, voor mainframes. Die dienden om tijdens het booten de microcode van de processoren te laden, de instructieset van de processoren werd dus van floppy geladen tijdens het opstarten. Dat zegt iets over hoe weinig er in de hardware zelf moet zitten om toch te kunnen starten. In een latere ontwikkeling kreeg je mainframes waar een laptop in zat die het bootproces aanstuurde. En voor de duidelijkheid: dat zijn uitermate betrouwbare systemen. Iets te, misschien, malware is (met zeer grote moeite) mogelijk, en de kans erop wordt vergroot omdat veel gebruikers ervan denken dat dat toch niet lukt.

De grap is dat je prima computers kan hebben zonder BIOS/UEFI-code op het moederbord, maar niet meer dan het minimum om iets te kunnen laden om verder mee op te starten. Dat minimum hoeft maar heel basaal en niet overschrijfbaar te zijn, zodat het moederbord zelf niet aangetast kan worden door malware. De rest van de code staat op een extern opslagmedium, en dat laat zich altijd controleren met code die weer van een ander opslagmedium komt.

Op basis daarvan zijn wel degelijk ook robuuste oplossingen te maken.

Jaren voor juist, tientallen zelfs, met bij Debian wel weer de wet van de remmende voorsprong. In hoe dat bij RedHat en SuSe zit heb ik me nooit verdiept.

Maar hoe dan ook, besef dat secure boot vooral nodig is omdat het OS kennelijk toestaat dat het bootproces wordt aangepast. Kennelijk wordt niet die zwakte zelf maar een consequentie ervan aangepakt. Je kan je dan afvragen of secure boot niet een pleister op de verkeerde plaats is.

Er zijn vast wel weer aanmerkingen te maken op hoe ik het nu neerzet, maar het punt is dat er niet maar één manier is waarop je robuuste systemen kan maken, er zijn ook andere benaderingen mogelijk. Een fundamenteel bezwaar dat ik heb tegen secure boot is dat het een leverancier in een machtspositie plaatst ten opzichte van andere leveranciers. Microsoft heeft die machtspositie nooit misbruikt, maar de hele situatie zou niet moeten bestaan, en er zijn wel degelijk alternatieven voor mogelijk. Denk niet alleen aan wat nu de dominante opzet is, denk ook aan wat er kan.

Het is gebeurd: https://support.microsoft.com/en-us/topic/august-13-2024-kb5041580-os-builds-19044-4780-and-19045-4780-2ef55b0d-bb01-41c8-8629-4146929792ad


Als mijn Xubuntu 24.04 LTS DVD niet meer op kan starten, dan laat ik het wel weten.

Met de hitte in het land heb ik daar nu geen zin meer in vandaag.

Dual Boot systemen lijken nu gespaard te worden, maar als je de computer gewoon onder Windows blijft gebruiken zal SBAT toch geïnstalleerd worden. Dit is onvermijdelijk. De nieuwe certificaten zijn ook nodig als je ooit weer van Linux naar Windows terug zou willen, dus ik kies er voor alle Secure Boot certificaten lijdzaam te installeren zodat mijn hardware met alle operating systemen overweg kan.

TS

Ja en nee.
Op de IBM-PC was het inderdaad het BIOS dat ook na het starten van MS-DOS bepaalde functies ter beschikking stelde die door DOS aangeroepen werden (lees sector, schrijf karakter etc etc).
Dat gold ook voor de 8 bit homecomputers (Commodore 64, sinclair spectrum) , en ook de Amiga - er was een ROM met 'systeemfuncties' (kernal (sic) op de C64) die door een applicatie (zoals de basic rom, of gebruikersprogramma's) aangeroepen konden worden.
Ook de Amiga (na de Amiga 1000) had dat soort basis functies in een ROM - Kickstart.

Inderdaad werden dergelijke basis functies, en hardware aansturing door andere OSen als deel van het te laden OS gezien.

Echter - 'BIOS' in de betekenis van "initialisatie van de hardware en laden van het OS' - ook een CP/M systeem moet geinitialiseerd worden, en er moet code zijn die de juiste parameters naar wat chips stuurt om sectoren van een floppy te laden, en het filesysteem ervan te interpreteren .


Ook de rPI moet hebben - en heeft - een stukje ROM dat de het bord initialiseert, en en de hardware aansturing doet om uberhaupt blokken van de SD-kaart , in de volgorde aangeduid door een FAT32 gestructureerd filesysteem , op een bepaalde plaats in het geheugen te krijgen en daarna uit te voeren.

De term in Pi land is , zo te zien, ROM Bootloader . Geen 'BIOS' in de CP/M betekenis, maar wel BIOS in de gebruikelijke x86 betekenis - rom code die systeem initialiseert, een OS laadt en start, en daarna niks meer doet .

Zo te lezen is de Pi bootloader ongedocumenteerd, geen open source, en is een pi-equivalent 'libre boot'

De bootrom zit intern in de SOC zo lees ik .

Dat is wat overrated, denk ik.
Mainframes zijn _hardwarematig_ heel erg betrouwbaar, en waanzinnig redundant .
En obscuur genoeg dat relatief weinig 'hackers' gelegenheid krijgen om ermee te spelen en dingen te ontdekken.

Ik denk dat 'betrouwbaar in staat om heel hoge uptimes te halen' niet verward moet worden met 'bestand tegen malicious gebruikers' .

FWIW, de eerste PDP/11 minicomputers hadden dus zelfs _geen_ bootrom, maar de 'boot sequence' , een minimaal stukje assembler om iets van disk te lezen, moest door een operator ingetoggled worden .


https://gunkies.org/wiki/PDP-11_Bootstrap_Loader

discrete diodes als (boot)rom : https://www.cca.org/blog/20120222-Diode-Matrix.shtml



De betekenis van 'bootloader rom' en 'bios' is wat door elkaar geschoven, hoewel BIOS voor bijna geen enkel OS meer een rol speelt nadat het OS geladen is.

Het nadeel van een absoluut minimaal 'bootrom' is dat het mogelijke boot-media, filesystemen nogal beperkt .
Om te netwerk booten moet het 'bootrom' een NIC kunnen initialiseren (success als dat er tig verschillende kunnen zijn in een pci-e slot), en een basale IP stack hebbben (dhcp + tftp minimaal, maar liefst meer) .
Booten van iSCSI storage is ook wel mooi in bepaalde omgevingen . Oeps - bootrom moet iSCSI (of FC) spreken , plus liefst een gepresenteerd partitielayout en daarna filesysteem snappen .


Ook de basale rPI bootloader heeft de crypto checks aan boord om vergelijkbare 'secure boot' scenario's te maken voordat controle over het hoogste priv level weggegeven wordt.

Ik denk niet dat je een robuust _kunt_ bouwen als de bootloader de volgende stap in de keten niet valideert.


https://pip.raspberrypi.com/categories/685-whitepapers-app-notes/documents/RP-004651-WP/Raspberry-Pi-4-Boot-Security.pdf

Jaren voor juist, tientallen zelfs, met bij Debian wel weer de wet van de remmende voorsprong. In hoe dat bij RedHat en SuSe zit heb ik me nooit verdiept.

Maar hoe dan ook, besef dat secure boot vooral nodig is omdat het OS kennelijk toestaat dat het bootproces wordt aangepast. Kennelijk wordt niet die zwakte zelf maar een consequentie ervan aangepakt. Je kan je dan afvragen of secure boot niet een pleister op de verkeerde plaats is.
[/quote]
Nee , secure boot _is_ een noodzakelijke stap om de keten vanaf power-on safe te houden tot dat de volgende trusted component het stokje over krijgt.
Daarna is het aan de volgende stap in de security keten om de access niet onbedoeld weg te geven.

_bedoeld_ weggeven, door gewoon een linux kernel te booten met root password = root . dat kan.


De hele keten _begint_ met een hardware boer die een trusted key ter verificatie in de bootloader rom stopt.
Niet verbazingwekkend dat dat in PC land een Microsoft key is.

(wie anders - ibm/redhat levert de trusted global key - dan zit DIE in de stoel met de mogelijkheid van misbruik .)

Wat dat betreft ben ik erg fan van hoe het booten is aangepakt op enkele RISC-V computers (in mijn geval een HIFive Unmachted maar dat is zeker niet de enige):
- Een rommetje op het board zelf heeft net genoeg code om een partitite op een SD kaart te vinden en in het geheugen te laden
- In die partitie staat de OpenSBI (komt qua functie dichtbij een BIOS)
- De OpenSBI is deels generiek, deels systeem specifiek en kan een bootloader (u-boot, grub) laden
- Bootloader zorgt dat het OS gestart wordt

Wat ik hier vooral fijn aan vind is dat een "BIOS update" (OpenSBI update dus) geheel risicoloos is. Gaat het mis? Dan zet je de oude inhoud van de partitie weer terug, of als je dat makkelijker vind gebruik je afwisselend twee SD kaartjes zodat je simpelweg kan wisselen als het mis gaat. Dat is stukken makkelijker dan de gemiddelde BIOS update op een x86 systeem met specifieke tooltjes om te updaten (die soms weer aan specifieke OS'en gebonden zijn), het risico van een systeem wat niets meer doet als het mis gaat, enz.

Had je dit gelezen?
https://www.security.nl/posting/851702/%27Secure+Boot+op+honderden+systemen+Acer%2C+Dell%2C+Intel+en+Lenovo+te+omzeilen%27
Als de keten niet van begin tot eind aan serieus hoge kwaliteitseisen voldoet, denk aan hoe een CA zijn root-certificaat beheert, dan is het niet meer dan theater.

Secure Boot is onderdeel van UEFI wat weer bedacht is door Intel.
Microsoft is daar op ingestapt en heeft het volledige geadopteerd terwijl de Open Source vrienden stonden toe te kijken.

Natuurlijk heb ik dat gelezen. En ja, dat is een fuckup waarmee een hoop veiligheid wegvalt .
maar imo niet anders dan andere security bugs , of vendoren die van voor naar achter plat gehacked worden.

"firewalls zijn theater" , heb je gelezen van netscreen en palo alto, en en en.

Ik heb zelf nog niet geprobeerd een LiveCD op mijn Windows 10 systeem te starten, maar het eerste slachtoffer van de augustus update van Microsoft heeft zich al gemeld. We weten helaas niet welke versie van Ubuntu hij gebruikt dus dat kan ook een jaren oude zijn, waarvan het logisch is dat die niet opstart met de nieuwste shim:

https://askubuntu.com/questions/1523353/windows-aug-13-update-broke-my-ubuntu-system

TS

Nou, die verkwistten hun energie met luid rondroepen dat een dergelijk systeem er toe zou kunnen leiden dat je op den duur geen Linux meer kon booten op een standaard PC omdat ie alleen nog gesigned code zou willen booten en Linux geen kans zou krijgen op een certificaat...

Dat is niet zomaar een fuckup en dit is wel degelijk anders dan typische securitybugs. Ik zou het meer vergelijken met een systeem van CA's waar blijkt dat diverse CA's testsleutels uitwisselen, die per abuis als root-certificaat gebruiken en in een publieke github-repository doen belanden met een wachtwoord erop van slechts vier tekens, en dat niemand ooit heeft gecontroleerd of die CA's eigenlijk wel functioneren.

Je lijkt niet te beseffen dat hier CA-achtige betrouwbaarheids- en degelijkheidseisen gesteld moet worden wil dit systeem vertrouwd kunnen worden, om zeer vergelijkbare redenen. Je hebt nu de situatie dat je secure boot als systeem niet kan toevertrouwen dat de boot secure is.

Als niemand op het lumineuze idee is gekomen om de betrouwbaarheid te bewaken van een systeem dat de betrouwbaarheid moet bewaken en diverse fabrikanten er totaal met de pet naar gooien dan denk ik inderdaad dat het erop neerkomt dat secure boot door de mand is gevallen als security theatre.

Ik weet niet wat je als norm hebt voor 'typische' security bugs.

Maar die komen toch met een zekere regelmaat langs in categorie 'hoe kun je DAT nou fout doen en ook nog missen bij test/validatie' .
Routertjes met hardcoded debug password ?
Juniper netscreen, die DRIE onafhankelijke backdoors geimplanteerd kreeg ?


Dat laatste is het kenmerk van elke security bug - dat je een bepaalde garantie die je verwacht van het systeem toch NIET krijgt.
Het _is_ een fuckup , niet precies trouwens van een CA , meer van een operator die een dummy test cert op een belangrijke (?) site installeert .
Maar waarom is secure boot met een test cert voor jou anders dan een systeem waarin het geven van bepaalde input leidt tot remote code execution ?
Ook dat is een situatie die niet mag voorkomen en waarom allemaal garanties en verwachtingen die afhangen van 'dat kan niet' opeens niet meer kloppen .

Als ik eerlijk ben - het threat model waarin je afhankelijk bent van een goed functionerende secure boot is imo nogal wat zeldzamer dan het threat model waarin je "afhankelijk" bent een kernel die geen code gaat uitvoeren als ie rare IPv6 packets binnen krijgt, om maar een recent geval te noemen.

En firewalls, en AV software , en en en...

Ik bedoel dat hier iets grondig fout zit, niet in een specifieke implementatie, niet in een specifiek geval, maar in hoe een wereldwijd gebruikt systeem is ingericht. En met systeem bedoel ik niet een computersysteem maar een georganiseerde manier van werken. Het woord systeem betekent stelsel of methode:
https://www.etymologiebank.nl/trefwoord/systeem

Bij een bug in bijvoorbeeld de Linux-kernel of in een tekstverwerker wordt die bug gerepareerd en een nieuwe versie uitgerold. Om deze "bug" te verhelpen moeten meerdere hardwarefabrikanten wezenlijk anders gaan werken dan ze doen, op een manier die nu kennelijk volslagen afwezig is in hun bedrijfscultuur (anders hadden ze het allang gedaan), en moet om erop te kunnen vertrouwen wereldwijd een systeem (in de betekenis van stelsel) van audits worden opgezet waar iedereen aan mee moet doen. Dat gaat niet om een technisch foutje wegwerken, testen en de oplossing uitrollen maar om iets op een wezenlijk ander niveau goed af te spreken en te organiseren, een stelsel van afspraken en bijbehorende organisatie die nu domweg ontbreekt. Dat is echt iets wezenlijk anders dan wat je typisch aanduidt met een security bug.

Je schreef eerder dit:
Jij neemt kennelijk blind aan dat die key van die hardware boer trusted is. Ik heb het over wat nodig is om daarop te kunnen vertrouwen. Dat is geen kleinigheid, en dat ontbreekt. Je negeert iets heel groots.

Ik heb bij mijzelf getest met de nieuwste Xubuntu 24.04 LTS DVD uit april dit jaar op een AMD Asus moederbord en ik krijg een halve seconde een foutmelding als ik de computer boot met de DVD en daarna gaat die uit. Ik heb deze DVD eerder getest op hetzelfde systeem.

Gelukkig heb ik bij Advanced Mode -> Boot -> Secure Boot -> OS Type de mogelijkheid Other OS gevonden. Deze staat nu op Microsoft Windows en daarbij kan Secure Boot niet uitgezet worden. Ik ben hoopvol.

Anders moet ik een oude PC optuigen met Xubuntu tot er een nieuwe Shim op de LiveCD staat. Dit moet een systeem met SSE2 zijn omdat Firefox dat nodig heeft, maar dat gaat lukken.

Ik had een beetje verwacht dat Microsoft linux distributies langer de tijd zou geven om compliant te worden met Windows UEFI CA 2023. Dit is echt machtsmisbruik en monopoliegedrag van Microsoft. Alles zonder TPM 2.0 mag zeker geen tweede leven als linux computer gaan genieten.

Boe Microsoft,
TS

Hmm, https://www.heise.de/en/news/Windows-update-paralyzes-Linuxes-again-9838334.html heeft een artikel over de vele linux distributies die niet meer booten na afgelopen patch-dinsdag. SBAT is iets van Linux en niet van je moederbord, om de DBX database op je moederbord te ontlasten. Zie https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996. SBAT is al een jaar of meer oud.

Het is echter zeker dat de SBAT problemen zijn ontstaan na de Augustus 2024 update van Microsoft. Microsoft zal het dus moeten oplossen door snel nieuwe Shims voor linux te ondertekenen.

Bij linux dual boot systemen is het gebruikelijk dat eerst linux geladen wordt bij het booten van de UEFI. Omdat linux windows-aware is en andersom niet. Je kan dus niet eerst windows laden en daarna linux met grub. Grub moet eerst geladen worden en daarin staat eventueel een bootoptie voor Windows. Door het SBAT probleem wordt Grub niet geladen omdat die afhankelijk is van Shim.

TS

Je ziet geloof ik niet helemaal goed hoe Grub werkt. Grub wordt gestart voordat Linux of Windows wordt gestart, en het is Grub dat vervolgens het besturingssysteem opstart dat je kiest of dat de default is. Dus als je in Grub voor Windows kiest dan wordt Linux in het geheel niet opgestart.

Wel is het zo dat je Grub typisch vanuit Linux bijwerkt en het ook als een pakket daar zichtbaar is. Maar bij het opstarten van het systeem is Grub geen pakket onder Linux maar iets dat gestart wordt voordat Linux, Windows of wat je er verder ook op hebt staan wordt opgestart.

Wat mij verbaast is dat niemand eist dat er op alle mainboards de hard-wired write-protect jumper terugkomt.

Dan kan een firmware update alleen als je eerst de computer opent, een jumper switch omzet,
dan de update doet, en de read-only hardware jumper weer activeert.

Op die manier weet je in ieder geval zeker dat een systeem blijft booten zoals het ooit geïnstalleerd was.

Ik probeer het op een manier te verwoorden die klopt terwijl ik het ook zelf probeer te snappen :-D

Er zijn nieuwe ontwikkelingen van het team dat shim-signed maakt. En die zeggen dat 24.04.1 en 22.04.5 een oplossing zullen hebben. https://packages.ubuntu.com/noble/shim-signed -> https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/2077083/comments/2. Deze twee versies komen waarschijnlijk spoedig (binnen een maand?) uit.

In de tussentijd kunnen getroffen gebruikers secure boot uitschakelen in de UEFI BIOS of tijdelijk een ander systeem gebruiken als secure boot niet uit kan. Het is ook mogelijk je BIOS om te zetten naar CSM mode als de hard disk kleiner is als 2 TB.

Er gaat een oplossing rond op onder andere askubuntu.com, maar deze wordt sterk afgeraden op launchpad.

TS

Hardstikke leuk.... ik raad je af secure boot uit te zetten, je krijgt daarna bitlocker voor je kiezen. Mij is dat overkomen omdat blijkbaar na 15 augustus 2024 op deze Windows pc mijn secure boot van Debian 12 niet geaccepteerd werd. Ik had hem uitgezet om van stick te booten wat toen wel ging, na het maken van een image, bleek dat men geen microfot account had, maar altijd met een gmail adres ingelogd heeft. Er lijkt een aliasses te zijn, maar ook daarvan is het recovery niet van ingevult en andere zaken en ik zit met de handen in het haar. Wat een rotzooi is het... Vanaf vandaag eindigd mijn hulp voor Windows gebruikers en doe ik er helemaal niks meer aan... einde windows support dus !

Microsoft heeft een mitigation voor Dual Boot systemen met Linux die niet meer op willen starten. Helaas is daarvoor vereist dat je nog niet opnieuw hebt opgestart of dat je Secure Boot uit kan zetten. Het eerste wat je doet na het installeren van Windows updates is opnieuw opstarten. Handmatig of 's nachts op de ingestelde tijd in Settings.

https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-22h2#3377msgdesc


Als je Secure Boot uit kan zetten in je UEFI/BIOS zonder nadelige gevolgen dan zou ik dat gewoon doen. Je kan dan Linux en/of Windows opstarten en alles werkt zoals het decennia lang tot de introductie in Windows 8 veilig tot ieders tevredenheid heeft gewerkt.

Er is ook een mitigation voor Windows 11, maar als je Windows 11 kan draaien op je hardware dan is Linux minder interessant voor je. Je computer hardware is dan namelijk al geschikt voor Windows 11. Wat lang niet voor alle Windows 10 hardware geldt die er nu nog is.

Het is mij ook niet helemaal duidelijk hoe je mokutil start onder Linux als je de SBAT foutmelding krijgt en je Secure Boot niet uit kan zetten in je UEFI/BIOS. Niet alle UEFI/BIOSen hebben die mogelijkheid. Volgens mij start Windows ook niet meer als je Dual Boot hebt en de shim-signed blokkeert je opstartproces met GRUB2. Waar SBAT voor ontworpen is. Voor het blokkeren van malware wat Linux kennelijk is.

TS

Dat kwam volgens mij door de Juli update van Microsoft. Zie https://www.askwoody.com/newsletter/ms-defcon-3-secure-boot-triggers-recovery-keys/.

Dit heeft dus niets te maken met het SBAT probleem van Augustus. De mitigation voor SBAT van Microsoft adviseert zelfs om Secure Boot uit te zetten. Dus je kan het wel uitzetten.

TS

Weet je, officieel intresseerd het me niet hoe het komt. Het is belachelijk dat je het voor je kiezen krijgt en ook steeds verplicht ben om een microsoft account aan te maken voor Windows omdat bitlocker zo nodig de key daarin wil bewaren bij consumenten. Ik vind het buitensporig !

Over twee dagen komt er waarschijnlijk een Ubuntu versie die weer werkt met de Secure Boot fratsen van Microsoft. Ik heb ook geen Microsoft Account en wil om dit zo te kunnen houden overstappen op Xubuntu 24.04.1 LTS, of in ieder geval wil ik de Boot Media daarvoor klaar hebben liggen. https://wiki.ubuntu.com/Releases

Hoe Debian dit oplost weet ik niet. Ik heb altijd Xubuntu gebruikt in het verleden omdat iemand dat mij begin deze eeuw had aangeraden op een feestje. Daarvoor heb ik nog SuSE gehad eind vorige eeuw (Het was SuSE of Redhat toen) en ik heb met Minix gewerkt tijdens mijn studie. Dat is Linux met een heel andere licentie.

Vroeger heb ik ook geëxperimenteerd met Scramdisk (de voorloper van Truecrypt) en ik vind het bizar dat je je sleutels voor lokale toegang in de cloud moet bewaren bij Microsoft. Waar iedere westerse politieambtenaar ze op kan vragen.

Ik vind de cloud als enige backup gebruiken ook bizar omdat het nooit een offline backup zal evenaren. De backups waar ik op vertrouw zijn op DVD of USB bij mij. Ik weet nog niet welke daarvan het langst houdbaar is.

TS

Hier TS,

Ik tiep dit vanuit de LiveDVD van Xubuntu 24.04.1 LTS. Alles lijkt goed te werken (YouTube ook) en de problemen met SBAT zijn over met deze nieuwe versie.

Zoals gebruikelijk stond de tijd 2 uur te vroeg. En als ik weer naar Windows ga dan staat die dus twee uur te laat. Dat zijn bekende problemen die je ook bij Dual Boot hebt. Windows gebruikt de lokale tijd in het BIOS. Linux gebruikt UTC/GMT tijd.

Nog een algemene tip voor LiveCDs met Ubuntu: Daarmee haal je het grootste aanvalsoppervlak weg bij een wat oudere ISO.

Vandaag ga ik lekker in Xubuntu werken maar alles lijkt prima in orde.

TS