STM32H7 is just an example. Most (all?) STM32 with has hardware SPI slave support. For example the STM32F030C8T6 is on JLCPCB as a basic part (no per-part cost for assembly) at $0.82 while the RP2040 is $1.11.
While the RP2040 and RP2350 has a much nicer to use SDK and for certain applications like USB it is much easier to set up, the STM32 is much more versatile and is just a much more mature product (don't get me started about the RP2350 having broken pull-downs on GPIO pins).
Until basic features like cloud backup/restore[1] works on GrapheneOS, they are irrelevant when talking about sophisticated targeted attacks. Your random journalist uncovering corruption in Saudi Arabia doesn't have the time to figure out how to flash a new ROM image, sideload Google apps, etc. GrapheneOS is great for privacy conscious technical users who wishes to use Android. For everyone else, iOS is far more secure OOB than popular Android phones and iOS with Lockdown mode beats GrapheneOS and is a single journo friendly toggle.
For all the drones in the replies repeating the same talking point over and over again you fail to address the criticism: GrapheneOS is not usable for non-technical users.
Now in terms of security/privacy, anyone who is talking about "look at the public exploits" is missing the point because nobody is attacking GrapheneOS for the same reason why nobody attacks macOS. Yes there is some marginal security difference but it's mostly because nobody who matters uses it. (I'm sorry but you, random SV tech worker who knows about GrapheneOS doesn't count.)
If you want some examples of just a _few_ things iOS does that nobody else does:
1. Secure nonvolatile storage[2]: On the most recent iOS devices there is an off chip custom dedicated smart card like device that manages passcode attempts. It's set up in a way that even if you completely hack the storage IC + SEP you cannot get any info on the passcode and still need to brute force on device. The only comparable feature is the StrongBox implemented either with an off the shelf SE (huge attack surface) or Titan M on latest Pixel phones which if hacked + TEE hack (also huge attack surface) gains you offline brute force.
2. Trusted Execution Monitor[3]: Even if you get kernel data rw access via exploit, you cannot kernel code execution because of hardware locks. You cannot even get EL0 userland execution because of the dedicated TXM which monitors the page tables. The only comparable feature is Samsung Knox which does monitor based page table management but done much worse and is full of holes. Pixel has nothing. Neither of them have any hardware locks on kernel code.
3. kalloc_type[4]: in addition to the standard slab based heap isolation that Linux also provides, XNU also promises never to reuse a virtual address for objects of different type completely defeating cross-cache based attacks. Types are also tagged with metadata showing which fields in a struct are pointers and which are numerical data such that the two will never overlap in random cases of slab sharing.
There's tonnes more but there's no point listing them all. As someone who've researched both iOS and Android attacks (and you can ask anyone in the industry who've done the same), iOS security is far ahead. GrapheneOS only provides mitigations that bring Android up to par in many areas (caveat: MTE is coming soon on iOS but is current shipped in a performance regressive way in GrapheneOS and a don't-enable-me-but-we-technically-shipped-it developer toggle on Pixels).
Also: Android attacks are far and plenty. You don't hear about most of them because they're not newsworthy because they're just dumb vendor bugs and nobody expects Android to be more secure because they don't market it that way. If you want a glimpse of what in-the-wilds are publicly disclosed for both iOS and Android, look at P0's list[5] especially for recent years (2024-2025).
Again none of this matters because the bigger argument is that GrapheneOS is not user friendly and therefore it's irrelevant how powerful they defend against the 0.01% attacker who targets specific people.
> I'm going to be honest here and say that I don't know what Microsoft's actual motivation for requiring a TPM in Windows 11 is.
It is quite obvious: to force people to buy a new PC. TPM provides no added security value for the vast majority of users[1] but it is a convenient hardware that has only started to become standard (fTPM) in PCs built in the last ~8 years so it provides an excuse for Microsoft to declare computers older than that (which can run Windows 10) obsolete using "security" as an easy scapegoat.
All they did was release technical drawings for a proprietary connector they designed to interface with their products. That's not what "open source" means. They're not releasing any schematics for their products. This is purely so you can build devices that can interface with their proprietary connector, which will be financially beneficial to them as most people probably do not own a Beelink PC.
I've been shouting at the void for years (https://gist.github.com/osy/45e612345376a65c56d0678834535166) about how TPM doesn't bring any practical security and was originally introduced for DRM then repurposed to sell "enterprise" security and now it's used as an excuse to force consumers to buy new PCs. TPM was designed by a committee who focused on designing the most secure gate without building a fence. There are many issues that Microsoft knew about for decades and never bothered to fix because security was never the goal.
It's true that nobody is expected to balance a binary tree as part of the job but the point of these questions is to see how you approach the problem and how you communicate your solution. Given that you can't perfectly predict how someone will do at the job, employers use leetcode problems as a proxy. Even those who memorize leetcode solutions must also memorize how it works and understand the solution. Given that the problem is random and you're likely given multiple interviews, it's unlikely you've memorized the exact problem and solution without cheating. If you've memorized enough solutions that it's likely you've seen the problem before and you can understand the solution enough to present it, then you're in the 0.1% and deserve to pass.
Yes really. The lack of any working implementation in production systems is an issue (D-RTM + encrypted sessions), something that Apple has done in an equivalent threat model since the iPhone 11. You can argue that "insecure by design" doesn't apply because there is a secure design in the abstract but the fact that nobody has adopted it in 20 years says something about the design itself.
It's _also_ insecure by design because in every deployed implementation (including with PIN), it is S-RTM meaning that _any_ UEFI driver vuln will compromise your TPM key. Yes, any UEFI vulnerability in its countless vendor drivers, USB stack, network stack, etc.
The screenshot is (obviously) from a jailbroken phone. Currently nobody with a stock phone can reproduce it (through Console on a Mac with Developer Mode enabled) although you are free to try it and test for yourself. This is just another side effect of how jailbreaks make your device more unstable.
Yes, when implemented correctly (I've never seen Google's implementation so I can't comment), D-RTM + Secure Boot is good. If Microsoft would give us this before shoving TPM down our throats, it would be good :) But they haven't even fixed the weaknesses they identified on their own in 2006.
> There are a plethora of attacks on TPM in the past but we need to be clear that a system that is widely attacked does not necessarily mean it is fundamentally insecure but only that there are many implementation issues. Most of these implementation issues do not touch upon the points raised in this article (it doesn't matter if the gate to your garden is strong or weak if there is no fence around the garden). Nevertheless, many of the attacks demonstrate the lack of care and consideration in the TPM ecosystem.
The issue is that TPM is being heavily pushed while it provides no security value. When you have Secure Boot (no additional hardware required), you get everything that Microsoft promises. The entire idea of TPM is that it gives you an extra level of security and I argue that it doesn't.
This is not the way TPMs are used by most of the industry. For example, Microsoft and now Canonical are advertising it as a way to do FDE which Microsoft has known to be broken since 2006. They are requiring it for Windows 11 because of "security" and have provided no software feature on Windows for this kind of use case. It is only done by the OSS community.
> The other useful application is to prevent block device data extraction without knowing the passkey.
Nope, read the appendix. Since 2006, BitLocker without PIN is vulnerable to physical extraction with $80 worth of equipment. And to enable enhanced PIN for BitLocker you have to jump to a lot of hoops that most people don't even know about.
> This sounds like the rant of a typical Linux fanboy
Hi, it's me the Linux fanboy whose entire personality is making Hackintosh and VM apps for iOS. Just a friendly reminder that attacks on the author's credentials have no baring on the weight of the arguments.
> The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module
It sounds like you have zero experience in security :)
> it defines a general-purpose hardware security module
No it doesn't. I think you're hinting at HSM which is another beast I may write another fanboy FUD piece about at some point. But no, HSMs are not the same as TPMs. And TPMs are not HSMs. For one thing, and HSM defines something called a trust boundary where keys should never leave. TPMs will happily hand you the keys when you meet a certain condition. HSMs support key migration and provides a secure way to transfer keys from one HSM to another without leaving the trust boundary. I can go on and on...
> TPM's security properties also depend on the rest of the system
The argument isn't TPM versus no security. The argument is TPM versus the existing security you have on Windows. (Passwords, FDE, etc). Of course all this depends on the system. TPM doesn't add anything (* with the exception already listed in the article).
> it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed
Nope. Architecturally flawed. But I'd just be repeating the argument from the article.
> means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped
They can with a $80 FPGA. Read the appendix.
> I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data.
They can with a $80 FPGA. (Unless your datacenter uses Intel TXT and tboot and other prerequisites that were talked about in the article)
> I like not having to worry about having sensitive keys on the filesystem somewhere
If you use BitLocker, they are always in kernel memory
> derived from the TPM doing remote attestation at boot
That's not what "remote attestation" means :)
> I like not having to worry about unattended reboots or entering LUKS passphrases remotely
If you like that, just disable your password and you'll get the same result
What’s the threat model of TPM? They claim it’s for “physical attacks” but they can only enforce it when there is no software vulnerability or unauthorized privileged access anywhere so it’s a very small area of the Venn diagram where you have an attacker whose capability is “physical access” but also “does not possess any exploit or one-touch-access”. This narrows down the list to:
• Malicious coworkers, family members, and house keepers against a computer who is NEVER left unattended (i.e. screen locked when you leave 100% of the time)
• Local government agents (i.e. the local police) who can confiscate your powered on device but cannot afford to buy 3rd party cracking services that utilize exploits or more advanced extraction techniques (external RAM dumping)
• A device that is completely powered off and confiscated by a powerful nation state agent but not later on returned to the original owner and they forgot to wipe the device in case of implants.
In any case the design of TPM is completely flawed and suffers from “astronaut architects”. If you grep the three volume 1000+ pages of the TPM 2.0 architecture documents, you’ll not find a single mention of “threat model”.
Specifically TPM is a multi-million dollar industry signed on by many tech companies (including Microsoft who uses it as an excuse to get you to buy a new PC because TPM == more secure right, but also because older computers don’t support it) because places like governments and banks require it because they also don’t understand threat models.
TPM protection is fundamentally flawed because:
• It cannot protect against a compromise in the boot chain (e.g. a UEFI driver is exploited, and it lies to TPM about the subsequent stage of code that is loaded while running a malware implant)
• It cannot protect against RCE (remote code execution). This means if Windows ever has a vulnerability that can be exploited remotely, they can keylog -> steal your PIN -> replay it later to dump the key. Or just dump the key in memory if they have a PE (privilege escalation) as well.
• It cannot protect against a user volunteerly installing malware (Bonzi buddy?)
• It cannot protect against an attacker who installs something on your unattended computer (USB Rubber Ducky, Flipper Zero, etc)
Basically the most common ways people get compromised sees no protection from TPM while esoteric attack situations that no attacker will realistic attempt are protected.
TPM can never protect against these cases because it is logically (fTPM) and/or physically (dTPM) separate from the CPU. That means it cannot perform any policy enforcement against a CPU whose execution is under control of the attacker.
It’s FOSS :) other than that, Parallels only does virtualization and does it really well. UTM/QEMU does virtualization not-as-well-but-still-pretty-good in addition to emulation.
While the RP2040 and RP2350 has a much nicer to use SDK and for certain applications like USB it is much easier to set up, the STM32 is much more versatile and is just a much more mature product (don't get me started about the RP2350 having broken pull-downs on GPIO pins).