Ariadne Conill 🐰
AMD is the only x86 CPU vendor I will remotely bother with at this point, but folks shouldn't use x86 anyway if they can avoid it: https://www.theverge.com/2024/6/14/24178751/intel-raptor-lake-crash-fix-etvb-not-yet
and for the love of all things, apply CPU microcode updates on your machines, *especially* with x86, where basically *zero* x86 cores have been taped out in the past 20 years that did not immediately need bugfixing in microcode
KATastrophE@ariadne and then you have the gnu libre people who remove any microcode blobs, even though there is one running on there cpu anyway... might as well update it to get security fixes
Julius Schwartzenberg - Юліус@kate @ariadne if you're only running free software and you have all the sources, the security fixes are not that relevant given one really does curation of all the software they end up running :)
Security fixes would be relevant if you do end up running untrusted code (for instance in a JavaScript sandbox). But then you're letting non-free software in without curation.
I would say the main reason for the microcode updates would be to solve bugs, stability issues for this group.
@jschwart @ariadne but all open-source software is basically untrusted code, or do you really read through all the billions of lines of code that run on your machine? you might have a feeling of security, but i think it's wrong to think you automatically have security if you only run open-source software (see the xz exploits)
Iron Bug@ariadne @jschwart @kate updating microcode is a big thing. it may
- introduce new vulnerabilities
- significantly slow down performance
- have inlaid backdoors for vendor
and not all vulnerabilities are exploitable in every particular case. sometimes the use case of CPU excludes the possible attacks and performance is more important than some fast and dirty fix.
of course, this all does not lift the fact that CPU must be designed and tested more carefully to avoid such BS we see more and more often nowadays. the problem is aggressive and idiotic management that forces engineers to throw semi-raw products to the market. nobody cares for quality and security. users pay for some cat in a bag that may have absolutely broken performance after a serie of skew firmware workarounds for CPU architecture errors.
- introduce new vulnerabilities
- significantly slow down performance
- have inlaid backdoors for vendor
and not all vulnerabilities are exploitable in every particular case. sometimes the use case of CPU excludes the possible attacks and performance is more important than some fast and dirty fix.
of course, this all does not lift the fact that CPU must be designed and tested more carefully to avoid such BS we see more and more often nowadays. the problem is aggressive and idiotic management that forces engineers to throw semi-raw products to the market. nobody cares for quality and security. users pay for some cat in a bag that may have absolutely broken performance after a serie of skew firmware workarounds for CPU architecture errors.
Alexandre Oliva (moved to @if a cpu is found to be defective and endangering to users' safety, it should undergo a recall list most everything else. if a recommended microcode update patches a defect at the expense of slowing down the cpu or otherwise making it unable to do things it was purchased for, without the possibility of a proper recall fix, the sale should be considered fraudulent
@lxo yes, this is what I'm talking about.
@lxo and yes, they try to impose SaaS even to CPU! they want users to pay to them endlessly. for "unlocking" CPU features. but why, the hell, features of CPU might be locked from an user that has bought it and have already paid? that's really weird. and that what should be stopped by all means.