Dit kun je allemaal googlen of bingen op het internet.

In het kort:

Wat doet de reset functie in je BIOS
Die zet alles in de UEFI BIOS (behalve het ingestelde wachtwoord) terug naar de fabrieks instellingen.


Wat voor zin heeft het verlopen van het KEK certificaat als je de datum en tijd in je BIOS niet kan vertrouwen?
Omdat het verlopen van het KEK certificaat niet te maken heeft met de EUFI BIOS datum/tijd, maar met de certificaat keten.
"Het is een gepande crytopgafische rotatie" zoals het zo mooi omschreven wordt.

Het gebruikt geen tijd, maar een update proces. Het controleert of de ondertekening van het certificaat nog geldig is adhv oa de keten informatie in de DB/DBX. Want de datum/tijd van de UEF BIOS kan gemanipuleerd worden of door andere onreglmatigheden niet op tijd lopen. Dus wordt de UEFI BIOS datum/tijd niet vertrouwt en niet gebruikt.

Vervallen betekent eigenlijk:
- Microsoft stopt met het ondertekenen van nieuwe DB/DBX-updates met die sleutel
- Nieuwe firmware-updates introduceren een nieuwe KEK
- DBX updates maken oude certificaten ongeldig


Waarom is het KEK certificaat niet eeuwig geldig?
Omdat certificaten die nooit verlopen, een kwetsbaarheid worden.
- de uitgevende instantie kan verdwijnen (opgaan in, failliet gaan, etc)
- encryptie veroudert, wordt vervangen door nieuwe sterkere versies
- aanvalstechnieken ontwikkelen zich in de tijd
etc

Nog simpeler:
Met het vernieuwen van je certificaat, wordt opnieuw de identiteit en veiligheid bevestigd.


Wat gebeurt er als mijn CMOS batterij leeg raakt. Zijn de KEK, DB en DBX dan nog bewaard gebleven of zijn die verloren gegaan net als de datum/tijd instelling van je moederbord
Nee want die staan in het "permanente" flash-geheugen op het moederbord. Niet in de CMOS-RAM.

In heel oude termen: ROM vs RAM.


PS.
In vindt het lastig in te schatten wat voor achtergrond je hebt. Dus hoe complex de antwoorden mogen worden. Ik heb het nu maar zoveel mogelijk in jip-en-janneke taal gedaan.
De antwoorden op je vragen zijn zo makkelijk op het internet te vinden, dat ik verbaasd ben dat je dat niet zelf eerst opgezocht hebt.

RTFM.
Daar leer je het meeste van.

Linux

https://mjg59.dreamwidth.org/72892.html

Volgens mij zitten al die keys en certificaten in een mini-flash chipje (spi flash), en niet in de handvol bytes die door de batterij in leven gehouden worden.

Je bent ze dus niet kwijt als de batterij leeg raakt.

Ik heb niet alle stappen van secure boot paraat, maar ik denk dat een stel oude keys installeren waarschijnlijk niet zal helpen om een OS / bootloader die de nieuwere keys nodig heeft (cq : daarop controleert) aan te vallen.

Ik denk dat https://neodyme.io/en/blog/bitlocker_why_no_fix/ her en der wel nuttige informatie bevat .

Er zijn veel lagen van security en pas als die allemaal helemaal aan staan in de BIOS configuratie, dan kan het misschien een issue worden. Meestal staan niet alle lagen aan of zijn bepaalde lagen eenvoudig te omzeilen.

Consumenten moederborden doen meestal niet echt 100% enforcen. MSI bijvoorbeeld bypassed het standaard.
Zakelijke moederborden hebben functies dat het oude certificaat gebruikt kan worden. HP bijvoorbeeld heeft een optie om oude MS keys te gebruiken.
En bij de sommige software kun je gewoon een eigen certificaat (laten) installeren. Bijvoorbeeld Ventoy.

Leuk passief agressief dat je dat zo stelt, maar als dit jou "jip-en-janneke taal" is dan begrijp ik er nog steeds niets van, laat staan dat je begrijpelijke uitleg via Internet gaat vinden (dan moet je al goed engels kunnen lezen).

Het begint al met het onbegrijpelijke idee van een BIOS die tegenwoordig UEFI wordt genoemd als oplossing voor een probleem dat daardoor alleen maar ingewikkelder is geworden en achteraf mogelijk een onnodige oplossing...

Ik heb eenzelfde issue gehad.

Oplossing:
Voer je laptop type in bij een Grok of dergelijke AI, beschrijf je 'uitdaging' en kijk wat er terug komt.

In mijn geval een key combinatie die NERGENS was beschreven. ;O))

Ik schreef ook: "in het kort"
Ik ben geen leraar (geen bevoegdheid daarvoor), en ga je niet alle ins-en-outs van UEFI doceren.
Daar zijn andere media voor.

Zoals ik vroeger zelf al te horen kreeg:

RTFM: read the fucking manual (Lees de f*ing handleiding)
En ja, die "handleiding" zal in het engels zijn :-)

Vwb passief-aggressief:
Ik ben techneut, mijn customer relations skills (klantgerichte sociale vaardigheden?) zijn beperkt.
(Vraag je moeder maar je een aai over je bolletje te geven, als dit allemaal te direct is.)


ICT is over het algemeen engels georienteerd. Dat is bijna een vereiste om je weg te vinden in die materie.
Is je engels te beperkt, dan is een vertaal-assistent zoals Google translate mischien een optie.

https://translate.google.com/?sl=auto&tl=nl&op=translate
Plak de url van de website die je wilt vertalen in het linker vak, en volg de link die in het rechter vak verschijnt.
De webpagina is dan vertaald naar het Nederlands.
Je kind kan de was doen.


Vwb het nut en onnut van UEFI.
Dat is weer een heel andere discussie.
Richt je daarvoor tot de bedenkers ervan. (oa. IBM en Intel)
Wij werken er alleen maar mee ;-)

"meer dan classic BIOS" in de ene of andere vorm was hoe dan ook nodig naarmate systemen groter werden en de hardware diverser.
Booten van extreem grote storage, andere partitie indelingen dan MBR, niet meer beperkt tot 16 bit etc etc.

Als je simpelweg "BIOS vs UEFI" in google gooit vind je enorm veel links met uitleg over de verschillen/voordelen.

UEFI betekent niet vanzelf "secure boot" , dat kan wel maar hoeft niet.

Dat UEFI in principe open is, en meerdere CU architecturen ondersteund zou juist dit forum toch moeten aanspreken.

Er zijn wat verwantschappen met "openfirmware / openboot" , wat afkomstig was van Sun als boot systeem voor hun servers.

Voor de 'gewone' gebruiker is UEFI een BIOS met graphische mogelijkheden. dwz. dat je je muis kunt gebruiken.

Het nodeloos ingewikkelde begint dus al met de naamgeving:
in plaats van UEFI hadden ze het gewoon BIOS moeten noemen of desnoods BIOS+ o.i.d.
zoals eigenlijk al gebeurt doordat je BIOS updates krijgt op je computer en geen UEFI updates.

Verder is het verplichten van een EFI System Partition (ESP) in het zeer beperkte FAT format niet bepaald een technish hoogstandje en inherent onveilig door het ontbreken van goede permissie instellingen.

Kortom UEFI is een lapmiddel dat door zijn gecompliceerdheid niet bepaald gebruiksvriendelijk te noemen is en daar helpt geen RTFM tegen...

Hallo, hier TS,

Ik ben de fucking manual gaan lezen. In mijn herinnering zat die achter een paywall maar dat zal iets anders geweest zijn (TPM of WiFi of zo, wat ook met crypto werkt). https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html. Hiermee kan ik mijn eigen vragen beantwoorden.


Dus PK en KEK zitten in non-volatile memory. Die overleven dus een CMOS reset. Verderop staat:
Ze kunnen echter nog steeds gereset worden in de UEFI/BIOS! Dit moet je nooit doen is mijn inschatting omdat je dan je OS niet meer kan starten met Secure Boot (De DB is immers terug gezet naar fabriekstoestand dan, zonder de nieuwe aanpassingen op bijvoorbeeld de BlackLotus malware). Zie https://github.com/microsoft/secureboot_objects/wiki/Secure-Boot-Objects.

En er zijn TimeOfRevocation variabelen:

KEK 2011 wordt dus automatisch 'ingetrokken' na juni dit jaar. Daarom kan je geen nieuwe DB en DBX entries meer toevoegen. Voor de veiligheid. Tenzij je je datum dus terug zet om DB en DBX wel te kunnen updaten. Je kan je Secure Boot instellingen altijd terug zetten naar de versie uit je laatste UEFI/BIOS flash. Als die recent genoeg is om te kunnen werken.

Windows 11 verplicht Secure Boot. Dat is een van de hardware vereisten. Voor mij is het net zoiets als het Y2K probleem. Dat was ook met een datum waar niet goed over nadacht was. Het kan meevallen of het kan niet meevallen. Over een maand weten we het.

TS

Goed zo.



Klopt ook. Het zogenaamde "permanente" flash-geheugen op het moederbord



Het klopt dat een factory reset ook de DB en DBX terug zet naar default.
Maar ... het OS zal zo snel mogelijk erna de nieuwst updates daarvoor naar je UEFI BIOS pushen.

"Windows Update distributes Microsoft’s Secure Boot DBX updates."
(Idem voor linux via fwupd)



Als een KEK verloopt dan heeft UEFI BIOS een aantal opties om de DB en DBX te updaten:
- Updates signed by another valid KEK (een vervangend KEK certificaat dat langer geldig is dan je huidige KEK cerificaat dat binnenkort afloopt)
- Updates signed by the Platform Key (PK) (Dit is de root van je secure boot certificaat keten)

En ja, je kunt in noodgevallen ook nog terug vallen op de factory reset. Zodat het bestaande (eerder verlopen) KEK cerificaat eventjes weer bruikbaar is. Maar de eerstvolgende BIOS update kan dat weer revoken. Dus je moet in die update dan wel een vervangend KEK-cerificaat hebben zitten. Voor de toekomst.

En als allerlaatste optie: je moederbord flashen. Maar dan kun je met een baksteen blijven zitten. (bricked)


Alleen nodig als de eerste twee opties die ik noemde niet werken.


Y2K viel ook heel erg mee. Uiteindelijk was het paniek om niets.
Ook dit zal met een sisser aflopen.

Andere cerrtificaten verlopen ook. Dat gaat meestal ook goed.
De kennis en ervaring is er binnen de IT wereld (oa bij de OS boeren zoals MS) om dit goed te doen.

Als je er niks van wilt snappen moet je er gewoon van af blijven en de defaults van je geinstalleerde OS gebruiken.
of het aan je neefje, buurjongen of de student aan huis overlaten.

Als je zo nodig slim wilt zijn en denkt dat je moet gaan zitten tweaken leer je ook maar wat nieuwe termen.

Het hele concept "BIOS" is niet 'gebruikersvriendelijk' , dat is gewoon "afblijven als je niet weet waarom je het nodig hebt' .

Inderdaad, en daar helpt dus geen RTFM bij maar een hele studie.

Waar precies stored? Want de SPI flash (op het moederbord) is niet read-only...

Het was niet helemaal niets. Er waren een aantal dingen die gewoon kapot gegaan zouden zijn als ze niet op tijd opgelost waren.
Waar ik werkte hebben we destijds ook een paar apparaten moeten uitfaseren of software updaten van dingen die niet Y2K-compliant waren en een probleem gegeven zouden hebben na 1-1-2000 .


Mw, ik heb iets minder vertrouwen in de firmware boeren - er zal her en der echt wel wat misgaan.
De link die ik eerder gaf https://neodyme.io/en/blog/bitlocker_why_no_fix/ plus vervolg linken zegt wat meer.

Eh, misschien in "non-volatile storage which is tamper and delete resistant"?

Die formulering geeft niet aan welke specifieke technologie toegepast moet worden door de fabrikant om dat te bereiken, die geeft alleen aan wat ermee bereikt moet worden. En het woord "storage" hoeft niet alleen maar op de geheugenchips (of wat ze ook gebruiken) zelf te slaan, het kan ook slaan op een storage-subsysteem dat aan de eisen voldoet. Dus geheugen dat op zichzelf niet "tamper and delete resistant" is met een schakeling plus firmware ervoor die de toegang bewaakt en die restrictie implementeert kan samen zomaar aan de eisen voldoen.

Waren dat levensbedreigende dingen?
Want de paniek was dat de hele samenleveing tot stilstand zou komen.
Dat mensen dood verklaard zouden worden door systemen
Dat medische apparatuur zou stoppen met werken

Voor zover ik het toen kon overzien, was met name zeer oude en weinig onderhouden en slecht gedocumenteerde code (oa. cobol op mainframes) een serieus aandachtspunt.
Vanwege ruimtegebrek werd "vroeger" maar 2 posities voor het jaar gebruikt. Maar in nieuwere systemen was dat allang opgelost.
En niet alle systemen die met 2 posities voor een jaar werkten, hadden een probleem met de overgang van 99 naar 00.

PCs met windows OS hadden geen problemen. Unix had geen probleem.
Relationele databases zoals Oracle hadden dat probleem ook allang opgelost voor het datum-type. (als programmeurs dat niet gebruikten...)

En het testen was relatief simple. Verzet voor een testopzet (als je die kon opbouwen) de datum van de systemen naar 31-12-1999, en wacht 2 dagen. En kijk wat er omvalt of hapert.

Maar de paniek was echt overdreven opgeblazen.
Er waren echt mensen die dachten dat hun vertrouwde wereld zou eindigen op 1-1-2000.
Dat alle electronica het niet meer zou doen. (Ik heb wat geld gewonnen in weddenschappen met kennissen die echt niet van die overtuiging afgebracht konden/wilden worden)

Hoe start je je Operating System als de opstart software daarvoor niet in de goedgekeurde DB staat?

Het kunnen terugzetten van je Secure Boot data op je moederbord is een faal. De bedenkers van Secure Boot hebben er nooit bij stil gestaan dat de DBX werkelijk gebruikt zou worden. En dat is meerdere malen gebeurd nu. Alle software van een bepaalde grootte is lek. En Microsoft is vrij strikt in wat er dan gedaan moet worden. Mijn DBX heeft 482 entries volgens mijn UEFI/BIOS. Die dus geblokkeerd zullen worden als je daarmee probeert op te starten.

Als je meerdere Secure Boot updates hebt gemist, succes met je computer dan weer draaiend krijgen.

TS

Ik zat in de telecom business. Ik herinner me sommige leased-line apparatuur , en "usenet" (INN) .


Zo werd het verhaal in de media verteld . Hoeveel daarvan dus op tijd gefixed is, geen idee.
Je moet je trouwens niet blind staren op "is nieuw" .

De apparatuur kan dat zijn, dataformaten leven _heel lang_ .

Ik had een manager toen die "in zijn tijd" hack patches voor het "miljardenprobleem" zitten maken.
Ook Cobol in bancaire systemen , met een veld-lengte tot 999 miljoen. "genoeg voor iedereen" , totdat de overheid rekeningen ging consolideren en saldi van meer dan een miljard moesten passen.
Een "ongebruikt ander veld" erbij plakken was de workaround aimgh.



Je moet echt leren coden , want dit is gewoon dom gelul.

INN "op Unix" had wel een probleem.
Je kunt niet zeggen "OS heeft geen probleem" . Dit is allemaal 'de applicatie' - en de dataformaten, en soms de on-wire representatie .

Ik kan tzt vast een leuke pensioenaanvulling gaan maken met consultancy op het Y 2038 probleem.
time_t , 32 bit signed int seconden sinds 1970 overflowed. Dat is behoorlijk bezig ge-upgrade te worden, maar ingebakken dataformaten - en alle processing erop kunnen gewoon extreem lang leven.
Lezend op lkml zie je nog steeds hoekjes waarin dingen (eindelijk) 64 bit worden - en het nadenken over backwards compatible . Denk aan velden in filesystems . Je kunt niet zomaar coden als je greenfield bezig met en er een 64 bit datatype in knallen .



Tsja, nu dus "alles in je landschap" zo testen , eventjes. Inclusief allerlei koppelingen of feeds van "elders" waarin iets gestuurd wordt waar een datum in zit.
Het kwam op zich wel daarop neer, maar het is gewoon veel werk als je dat voor "alles" moet doen.
En allerlei fabrikanten porren om hun Y2K compliancy declaration.

"Unix" bestaat - zoals je hopelijk weet - uit een kernel plus een ENORM AANTAL utilities en libraries.
Je kunt best de datum verschuiven - maar weet je dan of je echt niks gemist hebt als ie "gewoon boot" ?
Oh, had je wel een cron op de datum-grens gedraaid ? Oh, en at ? En wat doet de datetime module van perl ?
En je eigen AWK script ?
Het ding is er niet om te booten, maar om iets nuttigs te doen , en dan is een complete test of "alles" nog werkt niet eens zo simpel .



Tsja, op dat nivo was het overdreven. In de telecom hoek kan ik zeggen dat er zeker een paar dingen een storing/uitval gegeven zouden hebben als we die boel niet uitgezocht en gepatched of vervangen hadden.

En aimgh kregen we van Sun ook een bepaalde minimum versie Solaris waarvoor ze instonden. Geen idee hoe hard iets ouders gecrashed zou zijn, veel , weinig, of dat ze alleen maar geen capaciteit hadden om dat uit te zoeken.

Hoeveel "oef, goed dat we op tijd getest hebben" verhalen er uit andere hoeken (cobol/financial, embedded etc) zijn weet ik niet .

Hobby bob die z'n BIOS klok verzet en kijkt dat z'n PC boot is een beginnetje maar niet representatief.

Oké, stored in non-volatile storage which is tamper and delete resistant. Gewoon geloven dat het goed zit.

Welke boot code maakt gebruik van die public key? Als die boot code niet tamper resistant is en dus mogelijk tampered with zou kunnen zijn, dan kan de tampered with code die public key in non-volatile storage which is tamper and delete resistant gewoon negeren en vrolijk verder booten.

En we gaan nog dieper het rabbit hole in.

Waarom zou je OS niet in de DB/DBXvan UEFI BIOS staan.
Is je beestje dan zo oud en brak, en is in de tussentijd je DBdefault / DBXdefault op geen enkel moment bijgewerkt?

"DBdefault (Allowed Signature Database) and DBXdefault (Forbidden Signature Database) in UEFI BIOS are automatically updated during Windows Updates, specifically when Microsoft releases security updates to address Secure Boot vulnerabilities or when updating expiring certificates.These updates are designed to happen automatically without user intervention, particularly for the 2023 Secure Boot CA updates scheduled between 2024 and June 2026."

En met een factory reset van je UEFI BIOS worden de DBdefault en DBXdefault gebruikt om je EUFI DB en DBX te "resetten".

Dus waarom zou secure boot niet willen staraten na een factory reset.
Wat voor aparte situatie heb jij dan?


Ga maar terug naar de boeken.

Misschien heb je een computer van voor 2023 die geen BIOS updates meer heeft gehad? Dit gaat van de fabrikant uit en Microsoft doet dit niet bij alle merken. Bij Dell heb ik wel BIOS updates gezien. Bij mijn Asus van voor 2023 heb ik nooit een BIOS update gehad, terwijl die er wel zijn. Ik ben april 2025 definitief naar Xubuntu over gestapt. Dus vanaf die datum geen updates van Windows (10) meer gehad. Ben niet gek op BIOS updates omdat die een goed werkend systeem om zeep kunnen helpen. Don't fix it if it is not broken.

Een bedrijf kan ook in het magazijn extra laptops hebben liggen. Voor als die nodig zijn. Zijn die allemaal up-to-date met de laatste KEK, DB en DBX? Waarom denk je dat de update van KEK 2023 zo'n drama is bij Microsoft? Het wordt heel langzaam uitgerold met veel telemetrie omdat het zo makkelijk mis kan gaan.

En ja, Xubuntu heeft ook DB en DBX updates. Daarom heb ik hier voor gekozen. In mijn BIOS kan ik Secure Boot niet uit zetten los van UEFI.

TS

Nee, het kan zin hebben als een specificatie aangeeft dat een bepaald doel bereikt moet worden zonder aan te geven hoe. Als ze er in een specificatie geen nadere invulling aan geven wil dat niet zeggen dat het niet geldt.

Dat soort dingen komen vaker voor, binnen de IT en erbuiten. De AVG vult bijvoorbeeld bewust niet alle eisen voor het beschermen van persoonsgegevens in alle technische details in omdat wat nu aan de eisen zou voldoen dat al behoorlijk snel waarschijnlijk niet meer doet. Dus geeft de AVG aan wat de bedoeling is zonder uit te werken hoe je dat precies bereikt, dat is je eigen verantwoordelijkheid als je persoonsgegevens verwerkt. En neem de verkeersregel die zegt dat je niet dronken achter het stuur mag zitten: die werkt niet uit hoe je dan nuchter blijft, en toch vervalt die regel daarmee niet. Dat er een specificatie (of een regel) is wil niet zeggen dat die ene tekst alles bevat. Degenen die dingen maken waar die regels voor gelden worden verondersteld er intelligent mee om te gaan, zelf na te denken en zelf verstand van zaken te hebben.

Als er andere specificaties bestaan die beschrijven hoe je iets "tamper and delete resistant" maakt kan het zo zijn dat in deze specificatie volstaan wordt met aangeven dat het aan die eis moet voldoen. En wie weet volstaat het zelfs als de fabrikant van een moederbord het helemaal zelf uitwerkt, zonder aan een specifieke standaard te voldoen daarbij.

Voor de duidelijkheid: ik heb me niet in deze specificatie verdiept en dan kunnen er dingen in staan die ik nu over het hoofd zie. Het verbaast me alleen volstrekt niet als ik zoiets als "tamper and delete resistant" zie staan zonder dat in detail wordt voorgekauwd hoe je dat dan bereikt, en ik kan me zelfs goed voorstellen dat dat bewust wordt weggelaten omdat van elke invulling daarvoor die je nu specificeert elk moment kan blijken dat die niet meer voldoet. Door het open te laten in de specificatie blijft die geldig, terwijl specifieke implementaties als die achterhaald raken dan vanzelf niet meer aan de specificatie voldoen. Dat betekent niet dat er geen eis meer aan gesteld wordt, het betekent dat die eis altijd aan de actuele stand van zaken refereert.

En ja, dat maakt het lastiger om die eis te interpreteren. Het betekent dat er actuele kennis van zaken nodig is om dat goed te doen. En dat is maar goed ook, anders weet je zeker dat implementaties achter de feiten aanlopen.

Dan zou ik me maar niet aan Oracle wagen. Dan ga je namelijk niets verdienen als extraatje voor je pensioen. (en dan heb je niet voldoende verdiend terwijl je werkte als je dat dan echt nodig hebt)


Oracle slaat haar datum als volgt op:




https://oraclesniplets.tumblr.com/post/1179958393/my-oracle-support-oracle-database-690281


Oracle heeft dus geen probleem met 2038.

Mmm. Asus is wel vaker onbetrouwbaar.
Niet een merk dat ik zou gebruiken. Ik heb meerdere keren slechte ASUS apparatuur uitgereikt gekregen van mijn werkgever.
Maar dat terzijde.


Alles wat je opsomt:
- leveranciers die geen bios updates mee uitbrengen voor hun apparaten (zie ook een heel scala aan android telefoons)
- bedrijven die laptops in de kast leggen, en niet regelmatig updaten (en testen)

En is dit dan allemaal MS / UEFI's schuld?
Die snap ik weer niet.


En als je sinds een jaar op Linux zit en bios updates krijgt, waar maak je je nog dan druk om?
Waarom ben je deze hele thread begonnen?

Mooi hoor dat je oracle kent . Ook mooi dat je het probleem niet snapt .

Het is misschien niet de schuld van Oracle, maar nogal wat programmeurs zijn niet de beste database experts , en plempen gewoon hun interne datastructuur 1:1 in een database , zonder te weten of dat optimaal werkt met die database.
Met , soms, ook nog een heel slecht query model .
(Een hoop database engine magie is analoog aan compiler en CPU magie : dingen die niet perfect geschreven zijn toch snel uitvoeren.)

Je hebt er wat aan als de applicatie gekozen heeft om een datum in dat oracle propietary formaat op te slaan.
Maar niks weerhoud de applicate programmeur ervan om een gewoon INT veld te gebruiken en daar time_t in op te slaan.

Kun je boos worden dat de programmeur niet goed programmeert . Wat else is new.
Waarom ? tsja, data format van versie 1.0, en sindsdien compatibel gebleven .

Er is (zelfs) wel iets voor te zeggen als programmeur, om vooral GEEN database specifieke velden of functies te gebruiken, maar alles op dezelfde manier - dat maakt het supporten van andere databases wat veiliger - het schema is dan voor iedere database hetzelfde .

Kan het goed in Oracle (of welke andere serieuze database dan ook) - natuurlijk.
DOEN de applicaties die "op een database werken" het ook allemaal goed - vast niet allemaal .

Zo te zien hoef ik niet al te bang te zijn voor concurrentie , om een leuk zakcentje bij te verdienen tegen die tijd.

Zo simpel was dat niet. Wij hadden een systeem die files aanmaakte met de datum als een deel van de naam. De 100-tallen van het jaar was niet opgenomen in de naam. De files werden op onregelmatige momenten aangemaakt. Je voelt de bui al hangen. Na het jaar 2000 was na een sorteeractie van die files een rommeltje. Verzetten van de datum om te testen levert sowieso foute files op. Nadat de fout gevonden was werd aan de filenaam ook de honderdtallen van het jaar toegevoegd.Dat wel.

Zoals ik al zei: "Ben niet gek op BIOS updates omdat die een goed werkend systeem om zeep kunnen helpen.".

En ik heb op Xubuntu 24.04 LTS nog geen updates voor KEK gehad. Gisteren heb ik een USB stick met Ubuntu 26.04 LTS gemaakt, en die bood wel na een tijdje KEK en een nieuwe DB(X) aan. De DB(X) is ietsje nieuwer als wat ik nu heb.

Het leek mij niet verstandig om mijn UEFI/BIOS te gaan updaten vanuit een LiveCD omgeving. Hoewel er vast een AI te vinden is die dat een goed plan vindt. Als KEK niet op tijd komt ga ik Ubuntu 26.04 LTS schoon installeren. Ik kan er wel mee werken denk ik als ik de knoppenbalk automatisch laat verbergen.

TS

BIOS updates worden ondanks de risico's ook wel heel lastig gemaakt voor de gebruiker.
Waarom daar geen simpele methode voor is, ontgaat mij dan ook:
dwz. update bestand op een usb disk, inpluggen en opnieuw opstarten met bijvoorbeeld F12 ingedrukt
lijkt mij de beste methode maar blijkbaar moet dat per se via een OS met alle complicaties vandien ???

Met andere woorden:

Een standaard data-type dat al meer dan 30 jaar bestaat, en programmeurs (zeker de jongere generaties) gaan dan een integer gebruiken en daar omheen programmeren. Want dat is makkelijker en sneller. Vooral als er ook datum berekeningen gemaakt moeten worden.
Ondanks alle bestaande datum-functies die ook dat allemaal makkelijker maken dan zelf bedenken.

Natuurlijk. Droom door.


Ik kan me wel itzonderlijke situaties voorstellen waarbij een integer nodig is. Maar dan heb je het over datums in het GBA waarbij de werkelijke datums niet bekend zijn en 00 gebruikt wordt voor dag en maand. Denk aan vluchtelingen die naturaliseren en geen papieren bewijs hebben van hun geboorte- of huwelijksdatum.


Maar massaal een interger voor datums overal en nergens gebruiken, is zo jaren pre-2000. En zeer inefficient.

En dat gaat een n00b snappen en kunnen. Om nog te zwijgen dat je met zo'n usb-stick potentieel malware je BIOS in sluist. Vooral als je niet weet wat je doet. (1)
Niet jij. De rest van de normale wereld daarbuiten. En daar is de update via OS voor bedacht. "Om de gebruiker te ontlasten."


Maar ik ben het in zo verre met je eens, dat gebruikers hun apparatuur, OS en software behoren te snappen en zelf kunnen beheren. Maar zelfs de jonge generaties (op individuele uitzonderingen na) hebben dat nooit geleerd.

Over een verdienmodel gesproken. Daar kun je als ITer tot je dood geld mee blijven verdienen. Het onderhouden en repareren van IT-meuk van normale gebruikers / n00bs.


(1) UEFI BIOS root kits:
LoJax (2018): The first UEFI rootkit discovered in the wild, used by the Sednit APT group.
CosmicStrand (2016-2022): A rootkit that targeted consumer-grade motherboards, likely to infect users remotely.
MoonBounce (2022): A complex rootkit that could hide in SPI flash memory and survive firmware updates.
BlackLotus (2022): The first known UEFI bootkit capable of bypassing Secure Boot.

Ach, iemand uit een safe space, of met alleen theoretische kennis , die nog werkelijk denkt "zo dom wordt er helemaal niet geprogrammeerd" .

Dat is toch echt dromenland hoor , geloven dat iets wat technisch beter is ook altijd gedaan wordt.
SQL zit gewoon niet bij iedere programmeur in de mentale toolkit .

Wist je dat er hele frameworks bestaan die "vanzelf" je database schema en queries maken aan de hand van je objecten ?
Ooit in de buurt van (natuurlijk) een Java developer gezeten die zoiets gebruikte (aimgh hibernate ? ) - natuurlijk was het resultaat en de queries niet om aan te zien en performde voor geen meter .

En een integer van time_t komt vaak genoeg als bron - en is het zeer wel mogelijk dat die rechtstreeks in de database gestopt wordt.
Het _is_ uiteindelijk één van de mogelijke datum formaten (from_unixtime() )

Je praat als iemand die database schema's en tables echt zou ontwerpen. Goed zo, zo hoort dat.
Het is alleen maar dat het niet overal gedaan wordt .

Als je wel eens wat low-level debugging moet doen op iets waar een database onder ligt komt je echt wel dingen tegen waarbij je denkt "ah duh. Dat had ook anders gekund" .


Ik zeg niet dat het een _goed_ idee is, alleen dat je dit soort bevroren formaten of ge-erfd mis-design (of gewoon - niet-design) best kunt tegenkomen. En de kans heel reeel is dat medio 2038 die ergens onder water ook nog wel leven.

Ik ben Orace DBA. Al meer dan een kwart eeuw. Ik heb ook datamodellen ontworpen, gebouwd en ervoor geprogrammeerd. En blijkbaar goede leermeesters gehad.

Als een "programameur" dat in een van mijn databases flikt, dan krijgt hij de wind van voren.
En een lesje goed programmeren cq. datamodelleren erbij.

Gzd werk ik bij een werkgever die zijn mensen wel ordentelijk traint als ze de bagage niet hebben.

Helaas heb ik twee computers (Toshiba en ASUS) waarbij geen enkel OS daarop dat deed en ik dat dus echt zelf moest doen.

Was het hele idee van secure boot niet dat dat soort gesjoemel door aanvallers wordt afgevangen? Een firmware-upgrade die niet met de juiste sleutel van de leverancier ondertekend is zou niet eens geïnstalleerd moeten kunnen worden, je kan het upgrade-proces zo opzetten dat de handtekening op de nieuwe UEFI-firmware door de oude wordt geverifieerd. Als dat zo eenvoudig onderuit te halen is, waarom hebben we dan secure boot? Omdat het goed staat?

Dacht ik al.
Het vertekent je beeld hoeveel shitwerk er her en der gedaan wordt.


Niet alles is in-house en in samenspraak met jou , waarschijnlijk.
Wordt je nooit gevraagd voor niks anders dan een DB beschikbaar maken waar de ene of andere gekochte appliance of applicatie dan bovenop draait ?
(Of leuker,die komt gewoon mee met aankoop en draait lokaal op die appliance)

De opstart software van Secure Boot is digitaal ondertekend (door Microsoft) en wordt gecontroleerd door de UEFI/BIOS. Het is ook legitieme software. Maar er kunnen fouten in zitten waardoor de software ook door een aanvaller misbruikt kan worden. Fouten die digitaal ondertekend zijn door Microsoft. Zie https://www.security.nl/posting/750530/Microsoft+komt+halverwege+2022+met+update+voor+lek+in+Grub2-bootloader. Grub2 kan nu aan een PC worden toegevoegd om Secure Boot te omzeilen. Totdat er een DBX op het moederbord wordt gezet die deze versie van Grub2 blokkeert bij het starten van de PC. Linux start dan ook niet meer op andere PC's met deze bijgewerkte DBX.

In UEFI/BIOS-en zijn ook lekken ontdekt. Bijvoorbeeld dat een afbeelding in een standaard formaat wordt afgebeeld tijdens het opstarten van de PC. Maar in de library die daarvoor gebruikt wordt zit een fout waardoor een aanvaller met een aangepaste afbeelding de PC kan overnemen, zodra het plaatje wordt getoond.

Het enige wat echt helpt volgens mij is dat het aantal code regels met een factor 1000 omlaag gaat. Want dan gaat ook het aantal fouten met een factor 1000 omlaag is mijn theorie. Programmeurs zijn niet onfeilbaar. Code schrijvende AI is zeker ook niet onfeilbaar. Een goed ontwerp en veel debuggen helpt fouten te voorkomen. Iets als Secure Boot helpt niet om het aantal regels code omlaag te brengen. Windows 95 was geschikt om te gamen, browsen, tekstverwerken en het paste op 1 CD-ROM. Wat zou je nog meer met een computer willen doen? Ik heb Windows 95 gedraaid op een computer met 8 MB RAM. Niet de 4 GB RAM die tegenwoordig nodig is.

Ik kom overigens uit een tijd dat je BIOS een chipje op je moederbord was. Als je een BIOS update wilde doen dan moest dat chipje eruit en een andere moest er voor in de plaats. Je had ook speciaal gereedschap om dat chipje eruit te kunnen trekken en het chipje (ROM) was niet beschrijfbaar door de computer. Je had wel chipjes die je met UV licht kon wissen. Zogenaamde EPROMS.

TS

Ook de tijd dat de code in dat chipje "alle harddisk typen die kunnen bestaan" dacht te kennen, de CPUs nog moesten leven met CPU bugs omdat microcode-patches niet bestonden , en booten van iets anders dan ingebouwde harddisk of ingebouwde floppy drive niet bestond.

Oja - en het chipje was specifiek voor CPU (die ook vastgesoldeerd zat) en moederbord.
Allemaal dingen die ook in de "BIOSen" van nu zitten.

Ik heb ooit nog tijdelijk een PII processor (?) moeten kopen om de BIOS te kunnen updaten zodat de Celeron die ik wilde ook herkend zou worden .

Ik mocht de andere CPU gelukkig wel retour brengen (maar het risico dat er iets mis zou gaan lag bij mij) .

Met microcode updates, een gigantische variatie aan boot-devices (pxe, iscsi, FC etc etc) , een BIOS dat potentieel verschillende CPUs (sinds ze die dingen in een socket stopten) moet kennen, en natuurlijk een hele serie moederborden die door 'ongeveer dezelfde bios' gesupport worden is echt hard ROM geen optie meer.

Dan ben je nog jong .......
ik kom uit de tijd, dat de bios op de system track van de disk stond (meestal floppy).

Alle complexiteit is attack surface. Waar een aanvaller wat mee kan. En een ROM die niet beschreven kan worden, kan ook niet geïnfecteerd raken met malware. Oude rotzooi is veilig in dat perspectief.

TS

Inderdaad, en dat kun je niet afdoen met een RTFM als je het blijkbaar zelf niet simpel kunt uitleggen,
zoals sommigen hier doen, want dan snap je het zelf blijkbaar niet -- ook al denk je van wel omdat je wat termen onthouden hebt.

wat ik mis uit de 'goede oude PC tijd' is een jumper bij elke flash rom om die read-only te maken
totdat ik handmatig een flash update wil uitvoeren.

Ook USB sticks en solid state disks zouden standaard met een hard-wired write-protect schakelaar geleverd moeten worden.

Immutable file systems zijn veruit te verkiezen voor een stabiele productie omgeving;
periodiek kan een systeembeheerder de boel dan updaten met een known-good update.

Hangt allemaal van je threat model af.

Het hele secure boot concept richt zich op het probleem dat zo'n mini-rom niet kan oplossen : zorgen dat alleen "trusted" software gestart kan worden.

"boot van flop en pas gewoon alles op de harddisk aan" was precies het onpatchbare security lek in die statische rom tijd.

Zo'n mini-rom kan dat in beginsel prima oplossen als die een digitale handtekening kan controleren op een BIOS/UEFI-blob die die van schijf inleest. Die weg is de industrie duidelijk niet ingeslagen, maar ik zie geen enkele reden waarom dat niet net zo goed had gekund.

Sterker nog, de Raspberry Pi ondersteunt dat vanaf versie 4. Die bevat one-time programmable (OTP) memory, en daarin kan secure boot worden aangezet. Een RPi heeft een boot-medium nodig met daarop een FAT-partitie die onder meer de firmware bevat, dus zeg maar de BIOS. Die partitie wordt in zijn geheel in geheugen gelezen, een digitale handtekening op die hele partitie wordt geverifieerd, en als dat goed is wordt de ingelezen partitie als ramdisk gemount en van daaraf wordt het bootproces voortgezet.

Dit wist ik zojuist nog niet, trouwens, ik keek even naar de RPi als systeem dat vandaag de dag met wat jij als mini-rom bestempelt werkt, en ik kwam tegen dat die tegenwoordig secure boot ondersteunt:
https://pip.raspberrypi.com/categories/1260-security/documents/RP-004651-WP/Raspberry-Pi-4-Boot-Security.pdf

Geen systeem waar je een datacenter op gaat baseren, natuurlijk, maar het illustreert dat secure boot met een mini-rom inderdaad tot de mogelijkheden behoort.