Ubuntu zet beveiligingsmaatregelen Intel-drivers uit om prestaties te verbeteren

Ubuntu heeft besloten om enkele beveiligingsmaatregelen in de Intel Compute Runtime-drivers uit te schakelen. Het gaat om maatregelen tegen de Spectre-kwetsbaarheid op gpu-niveau. Door het uitschakelen van de maatregelen moeten de systeemprestaties verbeteren.

De beveiligingsteams van Ubuntu-moederbedrijf Canonical en Intel hebben na gesprekken met elkaar besloten dat beveiligingsmaatregelen tegen Spectre niet meer nodig zijn op gpu-niveau in de Intel Compute Runtime-drivers, zo valt te lezen in een bugrapport. Spectre is volgens Canonical al gemitigeerd op kernelniveau en daarom is de beveiligingsimpact van de maatregelen in de drivers niet meer groot genoeg om de prestatievermindering te rechtvaardigen. Gebruikers kunnen naar verluidt een prestatieverbetering tot twintig procent verwachten door de aanpassing.

Canonical beseft dat de mogelijkheid bestaat dat een onbekende aanvalsroute ontstaat door het weghalen van de maatregelen. Intel distribueert via GitHub zijn Compute Runtime-drivers al zonder de maatregelen, wat tot nu toe niet heeft geleid tot bekende exploits. Canonical merkt echter op dat Intel zijn builds statisch linkt: het bedrijf bouwt bepaalde library's direct in in het uiteindelijke programma, in plaats van deze dynamisch te laten laden vanuit gedeelde bibliotheken van het besturingssysteem tijdens het uitvoeren van het programma. Ook de packaging van de software is anders.

De Spectre-kwetsbaarheid kwam begin 2018 aan het licht en zorgt ervoor dat hackers geheugen van de kernel en andere processen kunnen uitlezen. Tweakers schreef destijds ook een achtergrond over zowel het Spectre- als het Meltdown-lek. In 2022 werd door securityonderzoekers van de Vrije Universiteit in Amsterdam een nieuwe Spectre-lek ontdekt.

Reacties (51)

[Heaget]

Canonical merkt echter op dat Intel zijn builds statisch linkt

Dit is juist positief toch, hiermee voorkom je DLL-sideloading. Of zijn hier ook weer nadelen aan? Naar mijn idee is het leunen op dynamisch linken toch een kwetsbaarheid opzich. Ik noem een Log4J als voorbeeld waar het faliekant fout ging.

[deadinspace]

Naar mijn idee is het leunen op dynamisch linken toch een kwetsbaarheid opzich. Ik noem een Log4J als voorbeeld waar het faliekant fout ging.

Hoe dan? Dynamic linking maakte Log4Shell (ik neem aan dat je het daar over hebt) juist makkelijker op te lossen.

Als applicaties dynamisch gelinkt zijn tegen Log4j dan hoef je alleen de system-wide Log4j te updaten om de kwetsbaarheid te fixen.

Als applicaties statisch gelinkt zijn tegen Log4j dan moet elke applicatie individueel een update ontvangen om de kwetsbaarheid volledig te dichten. Dat is een veel ernstigere situatie dan met dynamic linking.

Dit is een belangrijk voordeel van dynamic linking in security context, niet alleen voor Log4j.

[Reactie gewijzigd door deadinspace op 23 juni 2025 16:29]

[latka]

Ik snap je niet helemaal Sideloaden van dlls op Linux is toch niet echt een ding (op windows wel, omdat de cwd daar voorang heeft bij het resolven van libraries). Static linken is een tijdbom onder je software: je weet niet eens dat een library in gebruik is (want zit in de binary) en als er al een security fix komt, dan moet je maar hopen dat die ook komt voor jouw applicaties (zelfde probleem met docker). En log4j had als onderliggend probleem dat externe data niet gevalideerd werd. Dat is nooit verstandig.

[Pep7777]

Static linking hoeft geen tijdbom te zijn en kan een hoop andere ellende voorkomen. Met dynamische libraries is het weer makkelijk om de dynamische library te vervangen door een andere en je executable weet eigenlijk van niks en dat is ook weer een potentiele bom. Statische libraries kunnen een hoop build afhankelijkheden intern houden waardoor deployment (en development) weer makkelijker wordt. Dus of je het wel of niet doet is uiteindelijk een engineering trade-off.

[GertMenkel]

Het gaat hier om open source code, als je je DLL kan vervangen, kun je ook je statisch gecompileerde binary vervangen.

[latka]

Dat betekent dat je versiebeheer slecht is. Dat is altijd een probleem en static linking verhult dat. En ik schaal het onder 'lui engineeren', maar dat is een mening die slechts onderbouwd is met 30+ jaar software ontwikkeling.

[Pep7777]

Haha mijn mening is ook onderbouwd op basis van dezelfde 30+ ervaring.
Ik moet het denk ik ook net wat beter samenvatten.

Ja ik deploy veel dll's (maar niet op shared locaties, gewoon bij de binary die ze nodig heeft).
Deze dll's zelf zijn dan weer statisch gelinkt met andere libraries (alles is C++).
Dit geeft juist een hele beheersbare en schaalbare oplossing wanneer je met heel veel teams code moet ontwikkelen en deployen (voorkomt dat alle teams op hetzelfde moment naar dezelfde library versies moet)

[divvid]

welkom in de dependency hell. Static linking is soms een noodzaak. Superhandige tools uit 1990 era die never nooit gaan draaien onder een moderne GCC, maar prima werken als static binary of andersom, libraries die niet meer onderhouden worden, maar noodzakelijk zijn. Nog los van hele pipelines aan tools die elk een andere versie van dezelfde lib willen gebruiken.

Van dit soort dingen ga je de code niet meer fixen (soms leeft zelfs de developer niet meer) en een budget krijg je er niet voor als het door 3 man gebruikt wordt.

Van enkele simpele tools hebben we een rust versie weten te maken via een aantal AI tools, maar dat is zeker niet altijd mogelijk en de tijd is er ook niet altijd voor, want toch een hoop getest en gepruts

[latka]

Ik heb niet de luxe om tools te gebruiken die geen onderhoud meer kennen (security...) dus alles is bekend en geversioneerd (desnoods worden er meerdere versies concurrent geinstalleerd om alles te laten draaien lang leve Unix!)

[vide]

Het is dubbel: je linkt geen kwetsbare systeembibliotheek, maar je kan dus ook niet door een system level update een kwetsbaarheid in een gebruikte bibliotheek oplossen.

Statisch gelinkte binaries zijn groter en bevatten dus mogelijk oude versies van gebruikte libraries, anderzijds hang je niet af of het systeem die library al dan niet heeft.

[SuperDre]

Ik vraag me af of Spectre en Meltdown ook daadwerkelijk in het wild gebruikt werden of dat het altijd puur bij, het is mogelijk om...., is gebleven.

[Martinspire]

Ik denk dat dit typisch zo'n ding is wat ze op de plank laten liggen tot ze het een keer nodig hebben om een netwerk plat te leggen. Op een cruciaal moment de infrastructuur van je tegenstanders plat leggen, is nog altijd een prima oorlogstactiek.

[Faifz]

Met die Spectre/Meltdown vulnerabilities kun je weinig mee, hoor. Het is vrij hopeloos om het te proberen. Het zijn alleen maar memory read vulnerabilities, je kunt er geen code mee uitvoeren zoals een command injection waarbij een VPN gebruiker zonder authenticatie commands als root kon uitvoeren door bv gewoon een URL te gebruiken.

https://security.paloaltonetworks.com/CVE-2024-3400

Palo Alto Networks wou zelf niet eens een fix uitbrengen voor Spectre/Meltdown voor hun firewalls. Om daar iets mee te doen, heb je root access nodig en wanneer ze root access hebben - is het sowieso al voorbij (ongeacht of er een vulnerability is of niet).

https://live.paloaltonetw...78?utm_source=chatgpt.com

[groene henk]

Ik begrijp dat er verschillende varianten (15) zijn die degelijk wel wat fouts kunnen. Daarom is het advies nu ook om container systemen (Kubernetes/OpenShift) niet meer bare metal te draaien, maar op een virtualisatie laag. Anders kun je zo Spectre uitzetten in het bios.

Virtualisatie zorgt dat het bios niet direct meer door een foute container gehackt kan worden en ook nog voor meer performance (2 tot 5 keer zoveel containers op 1 server).

[B_FORCE]

Dat vraag ik bij mij heel veel van dit soort "beveiligingsmaatregelen" af.

Een groot deel lijkt namelijk vrij academisch.

Als je ze praktisch gaat uitdenken, blijft er niet heel veel van over of is het zo ingewikkeld of omslachtig dat het daardoor wel heel erg veel moeite kost.

Ben ik de enige die denkt dat het soms meer naar emotie voelt?

"Stel je voor dat", is nou niet bepaald een goed gedegen wetenschappelijke manier om problemen op te lossen.
Daar hoort toch echt wel een degelijk onderbouwde kansberekening bij.

Als bv kwaadwillende fysiek toegang moeten hebben en ze dat lukt, is er een heel ander en groter probleem aan de hand.

Het komt nu namelijk wel heel vaak over als seks hebben met een condoom, de pil, een spiraal, voor zingen de kerk uit en morning-after-pill, allemaal tegelijk gebruiken.

[SoftwareGert]

Ik vermoed dat het vooral gaat om Amerikaanse rechtszaken voorkomen.

Stel dat een bedrijf via spectre gehackt zou worden, dan is er heel veel ander wat mis is gegaan, maar neemt niet weg dat ze Intel verantwoordelijk kunnen houden.

Meeste security incidenten zijn een afweging tussen theoretisch en praktische toepasbaarheid, in combinatie met welke kosten risico’s er aan vast hangen.

En ja, een rubber kan scheuren, anti-conceptie is niet 100% effectief, naast alle bijwerkingen. Dus ook daar kan het slim zijn im beveiliging te stapelen.

[Digimann]

Dit zit gewoon in CVSS ingebouwd. Stel je hebt een vulnerability met een score 10. Door alleen een aanpassing te doen door te zeggen je hebt fysiek toegang nodig dan zakt de score naar 7.6.

(Gebruikte CVSS calculator is versie 3.0)

[Room42]

Beveiliging doe je niet op 1 laag, maar is een doolhof van hordes en barricades die alleen samen de vesting veilig houden.

Je kunt dingen roepen als "Als bv kwaadwillende fysiek toegang moeten hebben en ze dat lukt, is er een heel ander en groter probleem aan de hand.", maar dan vergeet je dat ook daar een hele rits aan beveiligingsmaatregelen genomen zijn waar jij je afvraagt wat ze nou toevoegen omdat ze 'academisch lijken'.

Als je analyses van geslaagde aanvallen bekijkt, zijn dit altijd een hele rits van kwetsbaarheden en toevalligheden die het samen mogelijk maakte om precies de juiste ingangen te vinden tot het doel.

Dus ik deel niet helemaal de mening dat het allemaal maar overdreven is. Je kunt soms ook gewoon geen risico nemen.

Vergeet ook niet dat de systemen waar het hier over gaat, vaak juist wel toegankelijk zijn. Het kan nét dat gaatje zijn die een aanval mogelijk maken. Maar goed, dat is allemaal theoretisch.

[The Zep Man]

Het is dus afhankelijk van context.

Een shared host in een datacentrum? Je wilt alles (tot in het redelijke) doen om zaken geïsoleerd te houden.

Een game-PC thuis die door een enkele gebruiker wordt gebruikt en enkel voor gaming? De prestatiewinst is het vaak waard ten opzichte van het risico van het uitschakelen van beveiligingsmiddelen die daar significant invloed op hebben.

Zelf heb ik een game-PC voor game streaming en niets anders. Die logt de enige gebruiker ("User") automatisch in en start Steam. Zelfs als iemand zou inbreken en de PC zou meenemen is het risico beperkt dankzij 2FA op Steam. Boeiend dat iemand dan even mijn (met name offline) spellen kan spelen. In dit geval is minder beveiliging het mij waard om op afstand gemakkelijk die PC vanuit niets naar een volledige ingelogde sessie op te starten met enkel WoL.

Authenticatie op afstand is uiteraard wel op orde.

[Reactie gewijzigd door The Zep Man op 23 juni 2025 13:09]

[goarilla]

Zelf heb ik een game-PC voor game streaming en niets anders. Die logt de enige gebruiker ("User") automatisch in en start Steam. Zelfs als iemand zou inbreken en de PC zou meenemen is het risico beperkt dankzij 2FA op Steam. Boeiend dat iemand dan even mijn (met name offline) spellen kan spelen. In dit geval is minder beveiliging het mij waard om op afstand gemakkelijk die PC vanuit niets naar een volledige ingelogde sessie op te starten met enkel WoL.

Heheheh dat deed ik vroeger ook om Rocket League te spelen op de sofa. Mijn game-PC automatisch laten inloggen en dan streamen naar een qotom dual core celeron dat ooit de firewall ging vervangen. Ik dacht dat eerst "veilig" te doen door in te loggen met RDP maar een RDP (detached) sessie heeft geen toegang tot de GPU ofzo. Dus heb ik het maar "onveilig gedaan" en autologin enabled. Werkte redelijk goed alhoewel er soms wel flickering en tearing was waardoor ik moest rebooten.

[B_FORCE]

Dat lijkt mij allemaal nogal evident.

Echter moet een kwaadwillende sowieso eerst van mijn bestaan afweten, daarna weten OF er überhaupt iets van waarde te halen valt en daarna OF het de tijd/moeite/geld en risico waard is.

Als we vanuit overheidsinstanties kijken, ben ik het helemaal eens met je verhaal.
Hoe betrekt zich dit alleen tot gewone burgers of andere situaties?
Jij hebt neem ik aan ook niet een enorm hek, met camera's en prikkeldraad om je huis heen?

Ik heb overigens nergens beweert dat het overdreven bij?
De context mist nu alleen enorm, waardoor alles op dezelfde "belangrijk" stapel wordt gegooid.
Dat kan per definitie gewoon nooit waar zijn.
Zo lijkt er echter wel mee te worden omgegaan door veel mensen.
Zelfs de context of hoe veel/vaak en succesvol de desbetreffende kwetsbaarheid nu daadwerkelijk misbruikt is, is niet duidelijk bijvoorbeeld.

Uiteraard is het speculeren, maar het idee van @SoftwareGert vind ik niet eens zo heel er gezocht.

[tedades]

Volgens mij komen dingen ook uit doordat ze zo gepresenteerd worden. Als iemand een aanval gaat voorbereiden zal hij kijken naar kwetsbaarheden en de proof-of-concept exploit. Daar kan dan een echte aanval uit gaan komen.
Zo kun je puzzelstukjes maken die je later aan elkaar knoopt om een volledige aanval uit te voeren.
Ik denk dat dit soort aanvallen alleen gedaan worden door een kleine clubje hackers, daar horen we waarschijnlijk ook nooit iets van. Als iemand wilt inbreken zal dat altijd wel kunnen.
Het gros van de hacks zullen de simpelere hacks zijn die je op grote schaal kunt uitvoeren.

[Blokker_1999]

We zien elke dag voorbeelden van bugs die misbruikt worden omdat mensen met slechte bedoelingen ze eerst gevonden hebben. Er is dus geen enkele reden om aan te nemen dat ook dit soort van fouten niet misbruikt zouden worden als men daar de kans toe krijgt.

Dit komt bij mij zo een beetje over alsof heel het Y2K gegeven overroepen was eind jaren '90 want uiteindelijk is er toch niet veel misgegaan.

[B_FORCE]

Dat is wel een vorm van engineeren en denken die absoluut niet overal wordt toegepast.

Normaliter maak je een goede kansberekening om in te schatten wanneer en hoe het fout zou kunnen gaan.
100% veilig (in welke vorm dan ook) bestaat namelijk per definitie niet.
Zodra dingen te overzien zijn, is het simpelweg een kwestie van een weloverwogen risico nemen,

Dat er dus "geen enkele reden is om aan te nemen dat iets niet misbruikt zal worden" ben ik niet met je eens.
Het gaat namelijk niet om OF er een reden is, maar HOE GROOT de kans is.
Een andere aanpak is om bv extra aandacht en onderhoud te bieden op bepaalde kwetsbaarheden, maar er zijn tal van andere manieren.

[the_stickie]

Het probleem is dat de mogelijke impact van kwetsbaarheden ongelofelijk is. Zelfs een dure, bijzonder lastig uit te voeren aanval, gebaseerd op de samenloop van de meest exotische kwetsbaarheden en toevalligheden, wordt plots interssant als dat miljoenen kan opleveren of vijanden kan uitschakelen.
De kans op grootschalig misbruik kan héél klein zijn, maar dat zegt niet veel over de impact.

Spectre bijvoorbeeld zou met de juiste mitsen en maren het mogelijk kunnen maken private keys uit het geheugen te lekken met een welgemikte targetted attack en het nodige geduld- dat is een ongelofelijke impact als je systeem bijvoorbeeld betalingen verwerkt...
Als je wil zien hoe dat aan de security kant geevalueerd wordt, kan je een kijkje nemen bij de verschillende 'Spectre' CVE's. Let dan naast de CVSS score ('maar' medium), ook op de vector die het mogelijk maakt een gedetailleerdere resico-analyse te maken.

[Reactie gewijzigd door the_stickie op 23 juni 2025 14:54]

[Faifz]

Toen met Spectre/Meltdown had Palo Alto een artikel gepost waar ze zeiden dat het geen zin heeft om dit te fixen op hun firewalls want je hebt root access nodig om gebruik te kunnen maken van de kwetsbaarheid. Root access heeft niemand behalve Palo Alto zelf.

En een ander feit, als ze root level access hebben - is het sowieso al voorbij. Dus die hardware vulnerabilities maken echt niks meer uit.

"PAN-OS/Panorama platforms are not directly impacted by these vulnerabilities, as successful exploitation on PAN-OS devices requires an attacker to have already compromised the PAN-OS operating system. We treat any vulnerability that compromises PAN-OS to allow the execution of unsigned code as a critical one. Any such vulnerability would be urgently updated and made available in a PAN-OS maintenance update for all supported versions of PAN-OS software.


Because of the low risk of the issue and the relatively high risk around code changes, the risk and impact must be carefully considered and thoroughly understood. We will continue to monitor the situation as it evolves, and to evaluate update options available from our partner vendors as they become available. We will update this bulletin with updates regarding software updates or other mitigations as they become available."

https://live.paloaltonetw...78?utm_source=chatgpt.com

[beerse]

Gezien de snelheid en de kracht waarmee de wereld heeft gereageerd op deze issues. is de mogelijkheid voor misbruik al heel snel vervlogen. Voor zover ik weet was de meest simpele oplossing HyperThreading uit zetten en dat kan zo ongeveer iedereen. Sinds dien is het advies voor veel virtualisatie systemen om HT uit te laten en de cpu zo op een hogere snelheid en met grotere cache te laten draaien.

Ondertussen zijn de gevoelige systemen meer dan 5 jaar oud en vaak al uitgefaseerd. Dus de kans dat er nog iemand iets ontwikkelt ten aanzien van Spectr/meltdown acht ik zeer klein.

Maar als er iemand iets doet aan spear-fishing en die merkt dat jij nog vatbaar bent voor spectr-meltdown dan zal het mij niet verbazen dat ze er nog iets mee doen.

[CAPSLOCK2000]

Lastige keuze zeg.
Het is sowieso al moeilijk om vast te stellen wie er verantwoordelijk is voor het oplossen/voorkomen van security bugs. Uiteraard is dat in de eerste plaats de fabrikant/auteur (in dit geval Intel) maar tegelijkertijd ontslaat dat anderen niet van hun verplichting om zo goed mogelijk voor hun klanten te zorgen. En bij goede zorg hoort ook dat je beveiligingsproblemen oplost, zelfs als strict genomen niet jouw verantwoordelijkheid is.

Eigenlijk is het alleen maar goed dat zo'n groot beveiligingsprobleem op verschillende niveaus tegelijk wordt aangepakt. Niks is perfect en security is dat dus ook niet, daarom is het advies altijd al om security op te bouwen uit overlappende lagen.

Maar uiteraard heeft alles z'n prijs, in geld en tijd, peformance en gemak. Ook daarin heb je een zorgplicht naar je klanten toe. Maximaal op security inzetten zorgt voor onbruikbare systemen.

Het voelt een beetje bijzonder om fixes op kernel niveau te accepteren als de juiste oplossing, in plaats van het Intel op hardware/firmware-niveau op te laten lossen. Maar ja, Intel kan dat blijkbaar niet zonder enorme veel performanceverlies.

Het is misschien goed om er even op te wijzen dat als je nog een hele oude kernel draait (zonder die security patches) dat je waarschijnlijk toch al niet veilig bent. Ook in de kernel zitten wel eens security problemen en waarschijnlijk is de rest van de software op zo'n systeem dan ook al wat ouder en lekker.

Misschien zou je zelfs kunnen stellen dat het verbeteren van de performance het mogelijk maakt om een nieuwere versie van het OS/de applicaties te draaien waardoor het hele systeem netto veiliger wordt, maar dat is een beetje gezocht want dat heb ik praktijk nog nooit zo zien gaan.

[Martinspire]

Iemand enig idee heeft wat het verschil in performance is?

Verder zou ik liever zien dat ze het mogelijk maken voor gebruikers om dit zelf wel of niet in te schakelen. Genoeg mensen die veiligheid prefereren.

[xorpd]

Staat in het artikel, tot 20% snelheidswinst.

[Bruin Poeper]

Kan Microsoft nu ook een aantal afgewezen Intel processors alsnog geschikt verklaren Windows 11?

[sprankel]

Die zijn afgewezen omdat ze bepaalde technieken missen of omdat Intel ze niet meer wenst te ondersteunen.

MS wil net zoals Android en iOS geen private keys en security tokens meer opslaan in het OS maar in een aparte security chip, die noemt anders op elk platform maar het komt erop neer dat de software een trust moet hebben met het platform.

Als die trust verbroken word, of het nu is vanwege een jailbreak of omdat secure boot niet meer intact is, en je dus geen garantie hebt dat je er een 3de partij tussen zit, dan zegt de software zoals je bank, hier doen we niet meer aan mee.

Probleem hier is dat Intel hun CPU's maar rond de 5 jaar wenst te ondersteunen, zonder support geen micro code updates, zonder die updates valt heel de trust in elkaar.

AMD had een vergelijkbare support tot Zen/Ryzen waarop ze die nu veel langer ondersteunen gelet de huidige ontwikkelingen.

Probleem is, als Intel een reeks CPU's stopt met de supporteren zijn er geen nieuwsberichten en geen reacties.

Als MS vervolgens verkondigt deze CPU's ondersteunen we bijgevolg ook niet meer dan zijn de berichten en de verontwaardigende reacties daar wel.

[Wouterie]

Probleem hier is dat Intel hun CPU's maar rond de 5 jaar wenst te ondersteunen, zonder support geen micro code updates, zonder die updates valt heel de trust in elkaar.

Dat zou betekenen dat de ondersteuningslijst van Microsoft langzaam zou opschuiven. Echter wordt de Coffee Lake nog steeds ondersteund, dus dat weerspreekt jouw hypothese.
Er is technisch geen enkel argument te verzinnen waarom bijvoorbeeld een i7-7700 niet en een i7-8700 wel in aanmerking zou komen voor Windows 11. En ik draai al geruime tijd Windows 11 zonder enige problemen op die processor.
Het zijn, naar mijn mening, puur economische overwegingen geweest. Om mensen te bewegen tot het aanschaffen van een nieuw systeem bijvoorbeeld.

Maar we dwalen af. Microsoft is een commercieel bedrijf dus geld verdienen is dé drijfveer achter elke beslissing. De keuze die nu wordt gemaakt in Ubuntu staat daar op zich los van.

[DeTeraarist]

De lijst met ondersteunde processors wordt dan ook onderhouden, volgens mij zijn er met 24h2 zelfs processors van de lijst gehaald.

[Wouterie]

Nou, niet helemaal, ze hebben de Intel CPU’s van de 8e, 9e en 10e generatie van de lijst voor nieuwe Windows 11-apparaten verwijderd. Dat wil zeggen dat fabrikanten ze niet meer mogen verkopen als nieuwe Windows 11 24H2 systemen. (raakt vooral de OEM-markt) Maar je mag/kan nog altijd de processors gebruiken voor een nieuwe installatie.

[DaHoot]

Wij hebben op het werk laptops met een i5-6200 met tpm 2.0 en daar wordt windows 11 officieel wel ondersteund. zonder modificaties heb ik gewoon windows 11 op kunnen instaleren. geen gezeik over wordt niet ondersteund of wat dan ook.

[Wouterie]

Niet volgens Microsoft: https://learn.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-intel-processors De i5-6200 staat niet op de lijst.

Je kunt het heel makkelijk controleren door de PC Heath Check app te openen en te kijken naar de Windows 11 compatibiliteit. Op mijn laptop een prachtig groen vinkje; op mijn desktop een keurig rood kruisje. Zelfs al staat Windows 11 erop dan houdt dat niet in dat MS het officieel ondersteunt.

[sprankel]

Het is vrij snel te controleren of Intel deze 2 CPU's nog ondersteund

I7-7700 tot 31/03/2024
i7-8700 tot 30/06/2025

Waarom Intel dat doet moet je bij Intel voor zijn. Dit houd in dat de oa de 8700 uit support gaat tijdens de support cycle van 24h2.

Om op je opmerking te komen dan zou de lijst met gesupporteerde CPU'S toch moeten opschuiven? Dat doet ze ook waarbij de 8700 geschrapt was voor de 24h2 release

https://www.neowin.net/ne...-9th-10th-gen-intel-cpus/

Omdat er kritiek kwam dat MS CPU's schrapte terwijl die nog in support waren bij de release van 24h2 (maar dus niet voor de volledige lifecycle) heeft MS die beslissing terug gedraaid, de 8700 is dus nog ondersteund in 24h2 maar bij de volgende release niet meer.

De meningen over de motivatie kan verschillen maar het is een vrij basis beginsel in security dat als er geen security updates meer uitkomen dat we dan moeten vernieuwen, los of het nu over software of hardware gaat. En de CPU maakt nu onderdeel uit van het security verhaal.

Echter het punt dat ik wil onderstepen, het is Intel die beslist, niet Microsoft.

[Digimann]

Probleem hier is dat Intel hun CPU's maar rond de 5 jaar wenst te ondersteunen, zonder support geen micro code updates, zonder die updates valt heel de trust in elkaar.

Probleem is, als Intel een reeks CPU's stopt met de supporteren zijn er geen nieuwsberichten en geen reacties.

Eigenlijk is het best wel raar dat Telefoons door de DMA(? of die andere) een minimum aantal jaar ondersteuning moeten krijgen. Terwijl Intel er mee weg komt om het niet te doen.
Tegelijk vraag ik mezelf adf of microsoft hun markmacht meer had kunnen inzetten om Intel onder druk te zetten om meer support te leveren.

[latka]

Die TPM zit soms in de CPU of soms (voornamelijk laptops) los op het systeem. De CPU support staat hier verder los van. Microcode updates, hoewel zinnig, staan verder los van de gesupporte CPUs. Dus zelfs met een TPM2.0 chip kan het zijn dat je CPU om magische redenen afgewezen wordt (staat los van de gesupporte instructies of het wel of niet aanwezig zijn van spectre achtige microcode updates). Het is voornamelijk een marketing gedreven excercitie ondersteunt met halfzachte technische termen.

[Deem]

Nee. Het feit dat Windows11 niet op oude hardware wordt ondersteunt,heeft niets met Spectre-kwetsbaarheid te maken, maar met het missen van TPM-functionaliteit.

[Bruin Poeper]

Nee. Het feit dat Windows11 niet op oude hardware wordt ondersteunt,heeft niets met Spectre-kwetsbaarheid te maken, maar met het missen van TPM-functionaliteit.

O,is dat zo?
Mijn laptop heeft een TPM 2.
Er zit in: Intel(R) Core(TM) i5-6300HQ CPU. Daarom wil MS er geen Windows 11 op.

(En beste slechte minnaar, waarom krijg ik -1 voor een onschuldige vraag??? -1 betekent dit. Ik heb toch niemand beledigd?)

[Reactie gewijzigd door Bruin Poeper op 23 juni 2025 12:07]

[Wouterie]

Correct. Er zit een keiharde grens op de processor die verder niet wordt onderbouwd. Het werkt overigens prima, dus er is technisch ook helemaal niets aan de hand. Het heeft puur te maken met geld. Oude systemen niet meer ondersteunen = meer nieuwe systemen verkopen.
Maar eerlijk is eerlijk; heft heeft niets met Spectre te maken.

[latka]

Die grens is zo zacht als boter: er is een lijst van CPUs beschikbaar, maar een paar apparaten van MS hadden een oude CPU en dus die mocht ineens wel weer mee. Het heeft niets te maken met security, maar wel een hoop security theater.

[Deem]

Microsoft heeft gewoon een lijn getrokken wetende dat vanaf de 7de generatie 100% gegarandeerd kan worden dat er aan de TPM vereisten kan worden voldaan. Hoe dan ook, het heeft niets met de prestaties, of Spectre-kwetsbaarheid te maken.

[CivLord]

Negatief uitlaten over tal van bedrijven zonder enige onderbouwing geeft een grote kans om gedown-mod te worden door medegebruikers die op deze manier proberen het forum leesbaar te houden.


Dus alsjeblieft, trek je er wat van aan en probeer je kritiek in ieder geval te onderbouwen.

[wiseger]

Lees de vraag van Bruin Poeperd nog eens een keertje. Hij wil graag Windows 11 op zijn laptop maar komt niet door de CPU eisen. Enige wat hij vraagt in minder CPU restricties.

Werd gedown vote naar -1. Leg mij dan maar eens uit waar de flame of belediging zit in deze vraag?

[CivLord]

Zijn eerste opmerking was een off-topic losse flodder richting Microsoft:

Kan Microsoft nu ook een aantal afgewezen Intel processors alsnog geschikt verklaren Windows 11?

Dat gaat aardig richting flame-bait.

[Tjolk]

Linux heeft het op kernel niveau gemitigeerd. Daar heb je voor Windows 11 natuurlijk helemaal niets aan.

Waarmee ik niet wil zeggen dat Windows daar geen maatregelen voor heeft geïmplementeerd, maar dat blijkt iig niet uit dit artikel.

-edit-
Dit was bedoeld als reactie op @Bruin Poeper

[Reactie gewijzigd door Tjolk op 23 juni 2025 11:47]

[HollowGamer]

Dit is toch niet de kernel laag? Volgens mij is dit de mesa (rendering) laag van Intel.

Er is ook een voor de kernel, die blijft dacht ik gewoon in takt. Het gaat hier enkel om de GPU power.