Trustworthy Computing in 2021(ariadne.space)
ariadne.space
Trustworthy Computing in 2021
https://ariadne.space/2021/10/19/trustworthy-computing-in-2021/
31 コメント
Wish modern hardware had better support for this. I don't think I'll ever trust their proprietary firmwares. The problem is becoming so widespread. All kinds of peripherals have firmware now. Who knows what they're doing. Did that storage device really delete the data or is it just pretending? Only way to be sure is to physically destroy the device.
> Only way to be sure is to physically destroy the device.
Or ... never write unencrypted data to the device.
Or ... never write unencrypted data to the device.
Yeah, that was my solution as well. It's much easier to destroy a small secret key than terabytes of data.
Especially with N-of-M secret sharing.
I thought something along these lines when it comes to peripherals, too, but don't these (mice and keyboards chiefly) communicate with PCs through a subset of the USB standard which only handles HID and nothing else?
Would any snooping be possible through an input device if it only did HID?
Would any snooping be possible through an input device if it only did HID?
> PCs through a subset of the USB standard which only handles HID and nothing else?
Yes. Is the device truly limited to doing just that, though? No way to know. I don't know enough electronics to tear it down and analyze its parts, much less dump firmware and reverse engineer it.
>Would any snooping be possible through an input device if it only did HID?
For all I know, it could be silently storing every keystroke in some small memory module hidden somewhere.
Yes. Is the device truly limited to doing just that, though? No way to know. I don't know enough electronics to tear it down and analyze its parts, much less dump firmware and reverse engineer it.
>Would any snooping be possible through an input device if it only did HID?
For all I know, it could be silently storing every keystroke in some small memory module hidden somewhere.
We had that problem with PS/2 keyboards too, you can buy hardware keyloggers for those.
AFAIK it wasn't possible for a PS/2 connected thing to suddenly present itself as some sort of drive, present a file on that, and then have that executed via autoload, or so.
How would the HiFive Unmatched stack up here? Seems like it would do rather well:
https://starfivetech.com/uploads/hifive-unmatched-sw-referen...
https://sifive.cdn.prismic.io/sifive/28560457-c5a4-4f88-866c...
https://starfivetech.com/uploads/hifive-unmatched-sw-referen...
https://sifive.cdn.prismic.io/sifive/28560457-c5a4-4f88-866c...
It would, but I don’t have an Unmatched board so I didn’t evaluate it.
Same reason why I did not mention the Pine64 stuff: I don’t own any of it.
Same reason why I did not mention the Pine64 stuff: I don’t own any of it.
[deleted]
What would be a trustworthy motherboard to use to build a solid machine learning system, with a budget of say $5-10K?
A Talos workstation?
But the question is moot because GPUs have proprietary firmware, and NVidia drivers that give you CUDA are also closed-source.
Maybe air-gapping your sensitive machines is a more viable approach for ML.
But the question is moot because GPUs have proprietary firmware, and NVidia drivers that give you CUDA are also closed-source.
Maybe air-gapping your sensitive machines is a more viable approach for ML.
What was the thing that detracted from the corebooted Thinkpad's trustworthiness?
Libreboot has no binary blobs, Coreboot still has a couple. But modern CPU architectures require some of those blobs to function correctly. So Coreboot has broader compatibility with modern hardware than Libreboot.
Both are good, but I've always leaned towards Libreboot just cause I think ThinkPads from 2005-2008 look amazing and it's fun to know that there is no proprietary software on my computer.
Both are good, but I've always leaned towards Libreboot just cause I think ThinkPads from 2005-2008 look amazing and it's fun to know that there is no proprietary software on my computer.
I flash libreboot first to get rid of the intel management engine and then the latest coreboot to the bios region. I think I configuried it so that it doesn't include any blobs, but I'm not sure. Wish it were easier to tell for non-experts.
Corebooted Thinkpads are the gold standard. Don't listen to this article - it's utter nonsense - the author even recommend Libreboot which is effectively abandonware barely maintained by one unstable individual.
conspicuously, infuriatingly absent:
https://www.pine64.org/
https://puri.sm/
https://www.pine64.org/
https://puri.sm/
This article appears to be focused on laptops, desktops, and servers, and the author uses the term "system" to collectively refer to these. If this really is "infurating" (and you're not just using the term to be hyperbolic) then I think recognizing that sometimes blog authors write about topics that are more specific or have a different focus than you'd prefer would help calm you down a bit.
The pine64 page has laptops, e.g. https://www.pine64.org/pinebook/
I was only evaluating hardware I actually own. I don’t own any of the PINE64 SBCs or laptops. And while I have a PinePhone, I rarely use it, it sits in my junk drawer basically.
I’d add the MNT Reform to that list. I’m a huge fan of what they’re doing and hope to get in on the next batch.
The machines that get 5/5, do they have open hardware? I heard somewhere that there's this thing called microcode that resides in the processor and could contain backdoors. Is that taken into account here?
It's not.
Microcode (insofar as how the term is used for x86/AMD) controls the operation of the CPU itself and the implementation of certain CPU instructions that aren't hardwired. It's too low-level to do things on its own like send a copy of RAM through a network adapter, etc.
Nonetheless, if you could manage to reverse engineer the microcode (which is likely different per CPU manufacturer and microarchitecture), and decrypt it (I do know AMD's microcode was not encrypted for a time, but is now), you could probably alter the behavior of some CPU instructions. Maybe you could manipulate some CPU instructions into allowing code to be executed where it wouldn't previously be executed, e.g. ignoring privilege checks, etc. and maybe you could do it without introducing side effects and causing existing code to misbehave or crash.
However it's a thousand times easier to modify the actual code the CPU is executing from RAM somehow - through OS vulnerabilities, etc. Any CPU code is either going to be running in kernel mode with full privileges or eventually interacting with code that does through some sort of interface. Operating system code is either available (open source) or widely distributed (Windows). Modern software development is further and further abstracted away from real hardware with ever increasing layers which are also either open source or widely distributed.
The possibility for finding human error somewhere in this scheme is vastly more likely to produce useful vulnerabilities - not the CPU microcode which is completely unknown, undocumented, encrypted, changes which each CPU, and updates thereof provided by the manufacturer.
Microcode (insofar as how the term is used for x86/AMD) controls the operation of the CPU itself and the implementation of certain CPU instructions that aren't hardwired. It's too low-level to do things on its own like send a copy of RAM through a network adapter, etc.
Nonetheless, if you could manage to reverse engineer the microcode (which is likely different per CPU manufacturer and microarchitecture), and decrypt it (I do know AMD's microcode was not encrypted for a time, but is now), you could probably alter the behavior of some CPU instructions. Maybe you could manipulate some CPU instructions into allowing code to be executed where it wouldn't previously be executed, e.g. ignoring privilege checks, etc. and maybe you could do it without introducing side effects and causing existing code to misbehave or crash.
However it's a thousand times easier to modify the actual code the CPU is executing from RAM somehow - through OS vulnerabilities, etc. Any CPU code is either going to be running in kernel mode with full privileges or eventually interacting with code that does through some sort of interface. Operating system code is either available (open source) or widely distributed (Windows). Modern software development is further and further abstracted away from real hardware with ever increasing layers which are also either open source or widely distributed.
The possibility for finding human error somewhere in this scheme is vastly more likely to produce useful vulnerabilities - not the CPU microcode which is completely unknown, undocumented, encrypted, changes which each CPU, and updates thereof provided by the manufacturer.
None of it is open hardware but some of it has been reverse engineered. I know some x86 CPU's have had their microcode reverse engineered, starting with the 8086 but also AMD's K8 and K10. There are lots of die photos of the 486DX chips and a patent says the microcode was pretty small (only 250 "lines", 12kbits.) About the POWER CPUs I have no idea. They're RISC so do they even have microcode?
Stopped reading at "Macbook is ... as trustworthy as the Libreboot ThinkPad". Anyone who trusts closed source, proprietary, for-profit platforms from PRISM partners doesn't know what they're talking about.
Strictly from a hardware POV. That wasn’t intended to be praise for Apple, but rather an indictment of the industry at large that Apple designed hardware that is easier to extend trust to.
If you are interested in this kind of thing, then you'll also want to check out LibreBoot[1] and Bootstrappable Builds[2]. The latter is working with stage0 [3] and mes [4] to bootstrap Guix (among other projects.) All of that is further down the chain, but we'll need it if we want to build trustworthy systems.
1. https://libreboot.org/
2. https://www.bootstrappable.org
3. https://github.com/oriansj/stage0/
4. https://www.gnu.org/software/mes/