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
with that said, most x86 machines apply some baseline level of microcode patch in firmware, so the linux-libre folks are just eliminating one route of harm reduction.
Alexandre Klein@ariadne (except the ones that run Canoeboot, but those are beyond saving)
Kevin Karhan 
@TheyCallMeHacked @ariadne well, #canoeboot is a #shitpost by @libreleah so that's acceptable...
- granted I do have some hardware that has reached the 20+ year age soon and even that has #microcode updates because everything more modern than a C3 or Geode LX800 needs those...
Leah Rowe ist kein Roweboter@kkarhan @TheyCallMeHacked @ariadne canoeboot is certainly *not* a shitpost. it is a response to one.
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
@kate those folks literally believe that you can make a microcoded CPU run an entirely different ISA just by changing the microcode
Longhorn
Natomic
Rairii (bootloader unlocked, MSR_LE set)
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)
@kate @ariadne generally yes, if you take a known blob that's already out there for years and known to fix particular issues, then I see no issues.
But some systems make it a habit of blindly fetching and applying each microcode blob that's made available. Such a habit where new blobs are regularly introduced into a system without going through any kind of scrutiny first is not something that should happen for granted I think.
I would feel more comfortable with some control over that.
@kate @ariadne exactly, this is too difficult or they might even be encrypted. One could analyze them by looking at their behavior, but essentially we don't know what's really happening. Maybe new bugs or performance regressions come along.
While a particular group of attack scenarios may be addressed by an update, if those scenarios are not applicable, there are reasons to stick with a particular version that's already been around for some time over continuously updating.
Alexandre Oliva (moved to @thanks for opposing software enshittification
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.
@ariadne @jschwart @kate the problem is that fixing hardware design fuckups with microcode crutches is wrong in its root.
and the most problems they discover and try to patch are hardware architecture related ones.
sometimes they have to go down to software level and "fix" compilers code generation, etc to skip buggy instructions. and this is perfectly wrong way.
and the most problems they discover and try to patch are hardware architecture related ones.
sometimes they have to go down to software level and "fix" compilers code generation, etc to skip buggy instructions. and this is perfectly wrong way.
@ariadne @jschwart @kate theoretically :)
the devil is in the details.
I think it's not the problem of development per se. it's the problem of the system that pushes the unfinished projects to the market. they impose impossible deadlines to developers and then get botched production. the thing that changed is not the complexity of technologies. but the process of normal development, that implies designing, testing and debugging. the past two may repeat again and again, until it works stable and fine. but nobody is interested in stable and fine hardware. they sell BS because they get more money from selling BS. they push new and more bugggy chips on market and make more profit from every bug they cannot fix.
the devil is in the details.
I think it's not the problem of development per se. it's the problem of the system that pushes the unfinished projects to the market. they impose impossible deadlines to developers and then get botched production. the thing that changed is not the complexity of technologies. but the process of normal development, that implies designing, testing and debugging. the past two may repeat again and again, until it works stable and fine. but nobody is interested in stable and fine hardware. they sell BS because they get more money from selling BS. they push new and more bugggy chips on market and make more profit from every bug they cannot fix.
@ariadne @jschwart @kate and RISC chips are totally different from general CPU. they have their niche in RTOS and embedded devices. but barely can substitute the robust processors that are used on high load tasks. and this world has really many heavy computational tasks that cannot be performed with simple and light processors.
we're in a dead end of a kind. we need a mighty single cores. instead, we get hundreds of tiny weak cores with dim and errors prone bus sychronization. and the very orgranization of modern development process is absolutely sick and is not intended for quality output.
we're in a dead end of a kind. we need a mighty single cores. instead, we get hundreds of tiny weak cores with dim and errors prone bus sychronization. and the very orgranization of modern development process is absolutely sick and is not intended for quality output.
@ariadne @jschwart @kate when I hear "Apple" I get an allergy. I don't trust those cons that sell BS that is overpriced like 5-10 times. no way. but they can sell a dead rat to their fanatics, I swear. they will buy any BS because it's Apple.
as a software and electrinics developer I never buy anything from Apple. and I use open source for 20+ years. no proprietary software. so Apple is out of my hardware list in all ways.
as a software and electrinics developer I never buy anything from Apple. and I use open source for 20+ years. no proprietary software. so Apple is out of my hardware list in all ways.
@ariadne @jschwart @kate I had seen many things. Intel and IBM mainframes, Fujitsu, EMC, Hitachi data storages, etc, etc. I had seen Cisco, HP, Juniper switches, Ericsson telecommunication equipment. even original old SUN servers with Solaris, but no Apple. I think they have never did anything serious. all they did was PR or their very mediocre end-user gadgets and selling them majorly overpriced.
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.
Lightning Bjornsson* 
@ariadne CPUs are frigging daft
SpaceLifeFormThe fix is to slow down.