osy
Joined 7 years ago
Karma
672
Submissions
84
Member since
Jul 10
Recent submissions
Comment · 1 month ago
Comment · 1 year ago
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).
Comment · 1 year ago
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.
[1]: https://discuss.grapheneos.org/d/15370-restore-from-google-c...
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.
[2]: https://support.apple.com/guide/security/secure-enclave-sec5...
[3]: https://support.apple.com/guide/security/operating-system-in...
[4]: https://security.apple.com/blog/towards-the-next-generation-...
Comment · 1 year ago
> 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.
[1]: https://gist.github.com/osy/45e612345376a65c56d0678834535166
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
I use this to stream my ROG Ally to my Vision Pro on long plane rides. The latency is crazy low.
Comment · 2 years ago
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.
Comment · 2 years ago
Yes, where did you think Meta get their idea from? It's the same as lying down mode and hand gestures...
Comment · 2 years ago
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.
Comment · 2 years ago
TPM is insecure against physical attacks by design: https://gist.github.com/osy/45e612345376a65c56d0678834535166
The only secure implementation is called D-RTM which requires a level of chip, OEM, and OS support that's not done in practice.
Comment · 2 years ago
They are all denial of service bugs. I.e. crashes/hangs. No remote code execution or disclosure of sensitive data.
Glad they were able to figure out the branding though.
> Today, powerful, widely available AI tools allow users to easily generate or alter photorealistic images to a degree that was difficult to imagine just a few years ago.
Photoshop has existed for decades and so has fake images. This is a low friction way to attest "this image came from an iPhone sensor and Apple approved it". It will still take the usual image forensics to determine if the scene it depicts is legitimate.