Ask HN: How do you trust that your personal machine is not compromised?

seL4 actually makes proofs for some core isolation promises, like realtime-ness and data flow adhering to capabilities (though with neglect of side channels for that aspect, which can be corrected for by also verifying the code that runs on top to not do shady stuff to probe side channels).

Considering the security UI layers control device access, I don't think AOSP or Android in general (with its many vendor customisations) is the most trustable.

Knowing a PUK-code for a SIM card you own (and you can insert/hotswap) is all you need(ed) to unlock practically any Android phone until recently. Granted, this got reported and then fixed, it doesn't matter how good the TCB is if the front door is wide open.

I'd say that actual trust is hard to come by because you cannot trust what you see, since what you see is merely what is 'presented'. If a device says something like "the only Root CA I trust to sign my stage 1 boot loader is X", I still don't know if it is lying or not. I also can't do something like replace a SoC BROM since it's fused RO or simply a ROM (and not EPROM or Flash), or because the sources for that are owned by the SoC manufacturer, which isn't AOSP or Google, and I cannot inspect, build and run them. Hell, we can make this worse: even if I could flash it, who's to say that the memory I flashed is also the memory that is read when the SoC comes out of reset? What if there is a separate area on the die that has a different ROM that nobody told us about.

So trust isn't going to be purely based on "because this is the design we present you", but has to be based on non-technical factors and independent research. The former is mainly based on soft factors, and the latter is hard to come by and often just based on individual devices, not even an entire SKU release.

Architecturally, it seems to me that Apple with their own SoCs, bootrom, RTKit, iBoot etc. has a stronger platform trust case because they actually own the stack all the way with nobody else having a say about it. Especially with the spreading around of individually signed and verified hardware ROMs that don't even run on the same chips in the same device, a compromise would be very limited in scope. The only other hardware/software combination that would come close is the aforementioned Pixel devices since Google has almost all of the stack there as well.

On the x86 side it's a mess that will never be resolved, nearly every technology that was supposed to make it more trustworthy has been used to reduce trust and install persistent access outside the view of the OS. AGESA, IME, TXT, SGX, even the SMM implementations before any of those came along had problems that essentially circumvent any trust that was built up by other means. Even the hardcoded certificate signature hashes in the CPUs are coming in range if easy brute forcing (SHA1 mostly) which means that entire decades of systems can now think they are running trusted software from the reset vector all the way to the OS, just because a signature hash was using a crappy algo that was never intended to be used that way.

Windows is probably only ever going to be boot-trustable (but not OS-trustable) on ARM, just like macOS root-of-trust is pointless on anything before the T2 chip (and M1 later on). For Linux, it's about as trustworthy as you want to make it, but putting in the work is a PITA, so unless a distro or derivative (Qubes, ChromeOS etc.) does it for you, most users leave it as-is (untrusted).

Isn't a (non-Android) Linux phone a security downgrade unless you get Qubes running on it or something? (And secure boot, and an HSM of some sort, and...)

I don't think you can trust any commercial baseband, period. They all have to adhere to complex radio standards, nobody wants to implement them because their design-by-committee stuff is boring/lame/hard/painful, so what you get is a few stacks that pass the tests and everyone builds on top of that. Same goes for any other RTOS-style firmware, it's really hard to get right, and because most of them are built by/for the 'device' world, they often have very long release cycles, slow development etc. just like say, head units in cars or painfully slow touch screens on devices that should just have buttons (like office style coffee machines, ATMs etc).

WiFi is in a similar position, but at least the diversity is a bit better causing integration tests to fail better when too many bad implementations try to talk to each other.

That leaves all the other chips, which I think are best trusted in a divide and conquer setup where they all have to independently verify their blobs, and not be allowed to mess with each others memory/internal state. It can make them more expensive, but it also compartmentalises them in a way that side-channel attacks within CPU cores are completely mitigated.

Only a very very very small amount of companies in the world will have the capital, expertise and manpower to make devices where enough of the stack can be trusted, and out of all of those, only some actually seem to try:

  - Google (mostly for UX, but also to make fat stacks of cash via ads) 
  - Apple (mostly for UX, but also to make fat stacks of cash via ecosystem)
  - Microsoft (console, ARM windows, mostly for DRM, but also UX)
  - Sony (console, mostly for DRM, but also UX)
  - Nintendo (console, mostly for DRM)

Besides the vertical integration they could make, there is the problem of their 'personalities' usually not being a good fit for people that want to go off the deep end in terms of security, privacy, control, feelings etc. But anyone and everyone else simply cannot do to silicon what needs to be done, even if just because of the lack of IP.

The more a company does _not_ want to get burned on their security/privacy positions and keeps iterating making better designs, the more you _could_ trust them. The only realistic alternative is going back to 80's computing, and nobody has time for that.