mjg59

17 ms·

301.
by mjg59 2y ago
They could potentially do that to motherboards, but they could do that anyway (physical access would give you as much access to flash as this vulnerability does). But yes, CPUs should be fine in that respect.
302.
by mjg59 2y ago
The shape of the flaw seems pretty clearly described in the abstract - it's the ability to either modify the contents of the locked SMM memory regions (and so get arbitrary code execution there), or trigger SMM execution of code outsid
303.
by mjg59 2y ago
You've got that the wrong way around - the PSP is able to access arbitrary areas of physical memory that can only otherwise be accessed via SMM, and so compromising the PSP gives you the ability to tamper with SMM code (as discussed in
304.
by mjg59 2y ago
Platform Secure Boot will measure the firmware into the TPM, so if an attacker modifies the firmware then yes, it'll be detectable. The microcode is signed so any attempt to modify it will simply result in the CPU booting with its ROM-
305.
by mjg59 2y ago
You don't need to do that if you're able to just shove arbitrary code into SMM in the first place, which is what's supposedly happening here. But having SMM doesn't let you change any persistent CPU state - the set of ad
306.
by mjg59 2y ago
Correct, the update has to be applied on every boot, but that doesn't mean there's no microcode in the CPU itself
307.
by mjg59 2y ago
Adding to Ryan's concerns, submitting to a bug bounty program often means accepting terms and conditions that constrain your ability to publicly disclose the issue if the vendor decides to be a dick about it. Depending on how you think
308.
by mjg59 2y ago
Not 100% true - a microcode-based CPU without microcode isn't able to execute anything, so CPUs will ship with an early version of the microcode that's then (as you say) updated during boot.
309.
by mjg59 2y ago
The microcode store in the CPU itself shouldn't be writable (if it were we wouldn't need to load microcode updates from the firmware or the OS on every boot), but there needs to be some microcode on there for the CPU to be able
310.
by mjg59 2y ago
SMM shouldn't let you modify any persistent CPU-level state - SMM is slightly magic, but not that magic. It could absolutely allow modification of motherboard-level firmware, but that's repairable given enough enthusiasm.
311.
by mjg59 2y ago
Getting into SMM means you can circumvent flash protection, which means you can rewrite the firmware to backdoor the OS on every boot without needing to leave any evidence in the filesystem, which a normal compromise of ring 0 wouldn't
312.
by mjg59 2y ago
There are plenty of multitasking operating systems with a strong concept of processes without any memory protection being involved - it just means any single process can overwrite resources belonging to others, or the OS itself.
313.
by mjg59 2y ago
Eh to be fair I think the main reason Zorro III RAM cards didn't appear until way after the first Zorro III machine is that Zorro III wasn't coupled to CPU speed so sticking RAM there wasn't great from a performance perspecti
314.
by mjg59 2y ago
Older BIOSes are much simpler, and also offer no security boundary at all - nobody talks about BIOS vulnerabilities because it wouldn't give you anything you don't already have!
315.
by mjg59 2y ago
Display managers were starting the X server and then immediately drawing a background on top of it, which meant you saw the stipple for a fraction of a second and it was just kind of jarring. These days the X server commonly won't even
316.
by mjg59 2y ago
"So knowing now that root weave and all of that is from 1986, should I send X.Org a pull request to rename the party_like_its_1989 global variable to party_like_its_1986 or party_like_the_1980s" Well, that would kind of spoil the
317.
by mjg59 2y ago
If you're making that comparison then you need to count the frequency of Shenfield services separately from Abbey Wood services.
318.
by mjg59 2y ago
It feels odd to talk about the US without bringing up BART, which has comparable characteristics to the Elizabeth Line (the yellow line is over 60 miles long, for instance, and headway through the core area is under 5 minutes at peak).
319.
by mjg59 2y ago
Measured boot is, in itself, under user control - you can seal whatever secrets you want to any specific state and they'll only be accessible in that situation. This has obvious benefits in terms of being able to (for instance) tie dis
320.
by mjg59 2y ago
No, because the secure boot settings are in flash and also the firmware measures the secure boot policy when booting so TPM-backed secrets will be inaccessible if someone modifies the variable store directly. As a device owner you have the
321.
by mjg59 2y ago
I don't see any need for kernel patches, and the udev policy is just config rather than code as far as I can tell. Bringing kexec into this is certainly more complicated than not using kexec, but I wouldn't expect (and I do have s
322.
by mjg59 2y ago
UEFI didn't exist at all on older systems, so instead you had BIOS which provided no security assertions whatsoever and exposed an even larger runtime attack surface (UEFI at least as the boottime/runtime distinction, and after Ex
323.
by mjg59 2y ago
Or by anyone with physical access to your system, but also root isn't the same as the kernel - if your boot chain is fully verified then even root can't replace the component asking for your disk encryption key, and can't ext
324.
by mjg59 2y ago
A lot of the commentary here is based on misunderstandings of the capabilities and constraints of a UEFI environment and what the actual goals of this project are, and I think miss the mark to a large degree. Lennart's written some mor
325.
by mjg59 2y ago
grub consumes a bunch of untrusted material (splash pictures, fonts, filesystems, executables, and more) and parses them. grub's also written in C, which is pretty much the worst case for writing parsers. Someone able to replace any of
326.
by mjg59 2y ago
Module loading is handled by udev, so udev merely needs to support enumerating a subset of the hardware to (eg) ensure input devices are available.
327.
by mjg59 2y ago
My broader point is that the majority of kexec issues are associated with the difficulty in quiescing the hardware, and there's simply no need to load the majority of drivers before offering this option which constrains the problem sig
328.
by mjg59 2y ago
There's no reason to load things like the nvidia driver if all you want to do is offer a choice to kexec into another kernel, which makes things easier - you can continue just using the display environment the firmware set up.
329.
by mjg59 2y ago
One easy way to meet Microsoft's boot time requirements is to skip input device enumeration, so there's a lot of machines meeting the Windows sticker requirements where entering the firmware either requires a bunch of failed boots
330.
by mjg59 2y ago
The UEFI environment is a given, unless you're in a position to replace the firmware - using grub doesn't avoid it in any way. But for the most part the security properties of the underlying firmware don't matter that much if

More ›