mjg59

16 ms·

271.
by mjg59 2y ago
In theory? Sure. In practice? Establishing DDR links involves a lot of negotiation between the memory controller and the RAM and being in a situation where you can maintain the same timings while also dumping data isn't going to be eas
272.
by mjg59 2y ago
It's something that's only triggered in the event of an unclean reboot so under normal circumstances it should be irrelevant and trying to be more elegant potentially increases risk?
273.
by mjg59 2y ago
MOR should be wiping everything, especially since after a cold boot the firmware has no idea what the previous memory map was. But I can imagine a universe where it doesn't wipe the boot services heap space (because some of that is obv
274.
by mjg59 2y ago
Changing it will trigger recovery, changing it back to the original won't
275.
by mjg59 2y ago
Why? It means you'll only get one shot at the attack, but nothing here is intrinsically prevented by using a TPM PIN (or even a non-TPM password, the attack doesn't depend on TPM-based Bitlocker in any way other than if the target
276.
by mjg59 2y ago
Just have the CPU microcode clear SRAM whenever the CPU is booted
277.
by mjg59 2y ago
It would entirely prevent the described attack. Related attacks may still be possible, but are also significantly harder than simply booting off USB.
278.
by mjg59 2y ago
It depends on the mode you're using. If you use the transparent unlock functionality (the default) then it's vulnerable to hardware key extraction. If you use anything else (PIN, password, whatever) then I'm not aware of any
279.
by mjg59 2y ago
No, the TPM doesn't retain PCR measurements over reboots, and the log (rather than the composite PCR value) is handled by the firmware and the OS and the TPM has no idea it exists.
280.
by mjg59 2y ago
I steal your Windows laptop. I want your data. I don't have your credentials, so can't login to Windows. I let your laptop boot to the point where Bitlocker is automatically unlocked, perform a hard reboot, dump the RAM, extract t
281.
by mjg59 2y ago
This is exactly what I was mentioning. Despite being a TCG spec, it's implemented in firmware and has no hard requirement on a TPM at all.
282.
by mjg59 2y ago
Why? You're not booting Windows again, and restoring the secure boot state and boot order to the original values will result in the PCR values being what they were before, so what's changing that would force recovery mode?
283.
by mjg59 2y ago
This is entirely defeated by https://trustedcomputinggroup.org/resource/pc-client-work-gr... - if enabled, if the OS isn't cleanly shut down (giving it an opportunity to wipe encryption keys) the firmware will pau
284.
by mjg59 2y ago
It sounds like they'd made multiple attempts to land at Grozny and failed due to poor weather, were asking to divert back to Baku, and due to GPS interference were asking for vectors rather than being able to navigate to waypoints on t
285.
by mjg59 2y ago
Linux now uses exactly the same reboot strategy as Windows does, so no PC should "need" a different one - it may be the case that driver code leaves the hardware in a state the system vendor didn't test, and using a different
286.
by mjg59 2y ago
The encryption isn't alleged to have been compromised. The app itself deals with a lot of untrusted input (eg, thumbnailing video files you've been sent) so there's a meaningful attack surface outside the protocol itself.
287.
by mjg59 2y ago
HAP disables the ME's runtime interface, it doesn't prevent the ME from booting.
288.
by mjg59 2y ago
The valid inputs to memcpy() are defined by the C specification, so the compiler is free to make assumptions about what valid inputs are even if the library implementation chooses to allow a broader range of inputs
289.
by mjg59 2y ago
Explanation for the above: passing NULL as the destination argument to memcpy() is undefined behaviour at present. gcc assumes that the fact that memcpy() is called therefore means that the destination argument can't be NULL, so "
290.
by mjg59 2y ago
That's a reasonable intuitive interpretation of how it should behave, but according to the spec it's undefined behaviour and compilers have a great degree of freedom in what happens as a result.
291.
by mjg59 2y ago
Video ram is still slow if you're accessing it from the CPU! Doing software 3D didn't really let you make use of whatever (limited) acceleration video adapters had at the time, which were mostly aimed at accelerated lines and movi
292.
by mjg59 2y ago
What? The vast majority of Linux systems running in a secure boot world run vendor-signed kernels. > Technically, this was the intent of efivarfs As the original author of efivarfs I can absolutely say that this was not the intent
293.
by mjg59 2y ago
Great question that would ideally be asked of the people who have logs
294.
by mjg59 2y ago
I wrote up finding some of these issues entirely independently: https://mjg59.dreamwidth.org/70061.html
295.
by mjg59 2y ago
The UEFI boot services that the shell relies upon aren't available after the bootloader or OS calls ExitBootServices() (the code is literally dropped out of ram and those regions handed back to the os) so this is not an easy thing to i
296.
by mjg59 2y ago
The full quote is: "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety" Is the ability to run an insecure bootloader on a system that has an installed OS with a secu
297.
by mjg59 2y ago
Distro grub is signed by the distro rather than Microsoft, so coordinating that would be extremely difficult
298.
by mjg59 2y ago
It's not normal. That's the point.
299.
by mjg59 2y ago
The protected video path for Intel integrated GPUs involves the ME.
300.
by mjg59 2y ago
It being unclear that they're exploitable doesn't justify the fact that the reference implementation had known weaknesses that were only documented in the issue tracker and a readme buried several directories deep and not referenc

More ›