Intel gets worse, but Power11 might get better
talospace.com
talospace.com
The increased attack surface that all this brings, implemented in a way that's opaque and non-removable, makes me incredibly nervous. You think cars and IoT devices are insecure? We're going to end up with that level of danger baked into every PC on the planet.
Tolerance for that among business customers may have just decreased substantially due to the current war.
Secure Boot at least can be disabled most of the time and that is one of the most locked down features.
Random tangent: I really wish we had a better way to customize code signing and verification. For very sensitive environments, you should be able to only trust certain certs/roots for particular binaries. I'd like to enforce that for some particular python script, it has been signed by one of *my* CI servers. Obviously this is possible, but I think you would need to roll your own code.
Microsoft wants OEMs that manufacture Windows on ARM devices to not allow a user to disable secure boot and not allow a user to add CAs or trust individual certificates. In essence, they want secure boot to not be subvertible.
This is both good and bad: for the generic end-user, not being able to 'accidentally' disable root-of-trust via secure boot and not being able to have 'tech savvy nephews' try to 'help' them (and not overseeing the long term consequences) is a net win. It's going to be pretty hard to rootkit a system that has a secured root-of-trust. On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. They also completely control all features, so even if it would be hardware-capable of doing something you simply aren't going to be able to do it.
There is a third aspect and that is that it is very hard to inspect the device as a researcher. Knowing that closed chassis debugging is a point of vulnerability, it would be great if it was still possible to boot a research OS and check the device. At this point, you can only do that with reverse-engineered drivers and a shim loader and hoping the CA in the firmware is up-to-date enough to contain a trust relation for the intermediate CA used to sign the shim certificate...
Heh, no, it's useless from the factory assuming you don't want to run windows.
Windows on Arm64 devices are regular Windows desktop devices, just running on a different CPU architecture. As such, they share the same security policies.
You can disable UEFI Secure Boot just fine on a Surface Pro X, and use custom keys there too. This also applies for devices from other OEMs.
So ... theoretically I could put a linux distro or android build on a Surface Pro X?
There are certain consumer Android ARM tablets/phones that for whatever reason, do not have secure boot enabled (which are not devkits from Aliexpress). So not all of them. But they are indeed quite rare, and is one of the reasons why you can't just replace the Android bootloader with something else (you need the appropriate signing keys to do so).
On Qualcomm devices, secure boot, once enabled, blows an irreversible hardware fuse. You then need the appropriate signing keys and software to sign images and you can, I believe, continue to blow fuses to overwrite old signing keys should you want to invalidate them. Thanks to the fuses, you can never deactivate secure boot (without, like, replacing the SoC with a miraculous solder job, or whatever). It's really irreversible.
That is definitely wrong.
By their very nature efuses can be programmed only once. You can never overwrite the old values with arbitrary new values.
In theory you can flip more zeroes to ones, since the fusing operation is only performed on the ones (or only on the zeroes -- the polarity choice is arbitrary but it is made at manufacturing time). But this is not really helpful; you can't feasibly generate your own signing key under the constraint that certain bits must be one... the cost of doing this grows exponentially with the number of constrained bits.
In practice I have never ever seen an efuse array that didn't also have a "permanent write-protect" fuse. If that fuse exists, the programming software will certainly activate it after verifying that the key was programmed correctly.
My understanding is this: you cannot overwrite the old values, but you can blow an additional fuse. If you have five fuses, then you blow the first fuse for the first key, then the second fuse for the second key. When you blow the second fuse, the system will only look at the second fuse, then the third, etc.
Only if you’re willing to accept the loss of Apple Pay via Touch ID as well as the entire iOS-apps-on-Mac feature. It’s been years since Apple allowed you to run kernel-level code without losing features.
Can you elaborate what you mean here? Maybe I missed something, but Apple does not provide any iOS-apps-on-Mac feature? Except of course for/through their development tools, but no Appstore thingy or alike.
https://machow2.com/run-ios-apps-mac/
Edit: In case you prefer a first-party source:
https://developer.apple.com/documentation/apple-silicon/runn...
Edit: https://support.apple.com/en-ca/guide/app-store/fird2c7092da...
https://developer.apple.com/macos/iphone-and-ipad-apps/ https://support.apple.com/guide/app-store/iphone-ipad-apps-m...
(I don’t fundamentally disagree with your point, though, although I am also obligated to mention you can load kexts from certain developers without disabling SIP which I guess is truly “without compromise” if you were lucky enough to get one of these certificates years ago when Apple handed them out like candy, but I digress.)
I don’t think you’ll be able to say that in a few releases. Apple is doing all that it can to make it almost impossible. Currently it’s already comically hard.
I mean, installing audio highjack on an M1 is a quick 19 steps involving a reboot (I kid you not):
https://rogueamoeba.com/support/knowledgebase/?showArticle=A...
As a Mac user, installing software that can capture user input (like audio or keyboard strokes) in as few steps as possible is not a priority for me.
I think there's a fine line between (a) requiring extra steps as part of a genuine concern for user security, and (b) preventing the user from running custom code to "protect them from themselves". As a developer, I'm willing to tolerate the former but not the latter.
This is revisionism. Walled gardens exist upon a spectrum. Even AOL was a walled garden. Both Windows and macOS have varying degrees of walled garden features and restrictions.
So the title should be Intel and AMD are getting worse.
Related discussion:
And, "no meaningful evidence"? Really? You sound like the WHO talking about COVID not being humanly transmissible ~2y ago, or that there was no evidence masks did anything; and we all know how that went...
But do feel free to continue helping them build better nooses to put around our necks --- including your own --- while continuing to preach about how good they are.
I wouldn't be so quick to discount locusts. There was a big swarm of them not long ago. The world is growing crazier by the year.
https://www.npr.org/sections/goatsandsoda/2020/06/14/8760024...
So cloud vendors can pressure Intel/AMD into exclusive features, or turning off features they don't like, etc. Where Dell/HP/others increasingly lose that kind of leverage.
Basically less of the vendor leverage bubbling down to normal end user owners of hardware.
I am extremely impressed with Tim's integrity. His decision to stand up to this nonsense has and will cost his business dearly, but it has won him him the kind of credibility that can't be bought at any price. People remember stuff like this for a long, long time.
https://blends.debian.org/science/tasks/ https://wiki.debian.org/Teams/DebianScience
Edit: of course a lot of more modern science and ML stuff is notoriously difficult to package, with pre-generated files, vendored code, lock files and so on.
https://wiki.gentoo.org/wiki/InfiniBand https://wiki.archlinux.org/title/InfiniBand https://pve.proxmox.com/wiki/Infiniband
Is this referring to the closed blobs on Power10? Is there anywhere to read more?
And is there any indication Power11 won't suffer the same? Someday POWER9 won't cut it for performance...
https://www.phoronix.com/forums/forum/phoronix/latest-phoron...
So really it's just one guy on phoronix who made that claim. Probably just wishful thinking. But if it is true, everybody with first-hand knowledge of it would be under NDA. So we'll probably never know.
1. Today we have FSP blobs but in the future we're going to have (menacing voice) Scalable FSP blobs. I consider Coreboot people to be unreliable narrators since Coreboot is feature-poor and isn't free from blobs anyway.
2. Pluton is going to be required for Windows so Intel, AMD, and Qualcomm will all have it. Resistance is futile. (It is really dumb that MS is FUDding themselves by not documenting Pluton.)
3. AFAIK Power10 was mostly finished before the pandemic. The switch from GloFo to Samsung and IBM's lack of experience with the Samsung process is more likely the cause of the third-party IP. Even if it was fully open the price/performance would still suck like all Power generations.
Coreboot might not be perfect, but until there is enough powerful hardware (like ARM and RISC-V that isn't just multi-core but also has enough single-threaded performance) it's not like you're going to be able to run free and libre firmware on reasonable hardware (and no, pre-CSME hardware and pre-FSP hardware is not reasonable, it's just old at this point).
I hope POWER and ARM and later on RISC-V are getting powerful enough to not have to trust a CSME or FSP in the long run, but I doubt it. Even just having a PAVP DRM is something that is pushed by various corporate legal departments so hard that all the hardware that ends up in consumer land is going to be hobbled one way or another.
I'm afraid we'll end up in a world where you can get that libre and free stack on high performance hardware, but won't get access to all the IP, including IP cores for embedded FPGAs and IP like streaming media including audio, video and games.
Exactly. Also what worries me is that all it takes is one significant terrorist event to be organized over a libre software stack to get all this treachery in computing to become law too.
I don’t understand, why is this a downside?
If they fail to reliable provide that: sadly shows how weak that platform is
Without any commitment to a future openness that can rapidly become an expensive cul-de-sac for anyone willing to develop for it.