4 ms·

> This still won't prevent yoinking the entire RAM modules and dumping them offline. Theoretically no, but realistically I doubt even intel agencies can pull t

> This still won't prevent yoinking the entire RAM modules and dumping them offline. Theoretically no, but realistically I doubt even intel agencies can pull this off. > Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die. The real solution is putting the keys somewhere with a guarantee they will be gone prior to possibly executing untrusted code. In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.

bri3d 2y ago
> Theoretically no, but realistically I doubt even intel agencies can pull this off. For older LPDDR3 it's completely practical, see https://www.youtube.com/watch?v=nTvIQDe0rQU https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely gets harder with newer systems, though. > In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records. This already exists: it's the MOR bit and it's supposed to be in play here. I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
- bangaladore 2y ago
  > I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs. True. Given that the CPU is what's resetting and running the UEFI code, you better hope it could recognize and clear a scratchpad reliably.

bri3d 2y ago

> Theoretically no, but realistically I doubt even intel agencies can pull this off. For older LPDDR3 it's completely practical, see https://www.youtube.com/watch?v=nTvIQDe0rQU https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely gets harder with newer systems, though. > In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records. This already exists: it's the MOR bit and it's supposed to be in play here. I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.

bangaladore 2y ago
> I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs. True. Given that the CPU is what's resetting and running the UEFI code, you better hope it could recognize and clear a scratchpad reliably.