3 ms·

Maybe a paranoid app could try to allocate the memory adjacent to any sensitive bits as a buffer? That would be pretty difficult to do but might be possible if

Maybe a paranoid app could try to allocate the memory adjacent to any sensitive bits as a buffer? That would be pretty difficult to do but might be possible if you are tremendously paranoid and have a good way to examine the hardware.

pas 5y ago
Or use different banks of DRAM for different security contexts, managed via NUMA?
to11mtm 5y ago
I wonder how easy that would be to reason about though. I really don't know much about modern DRAM circuitry I feel like it might be abstracted away to some level, also there are bios-tweaky settings that might make a difference (i.e. things like channel configuration and/or bank interleaving, if that's still a thing.) IDK though. Maybe there's a way. I've worked on code that uses padding around a data structure to ensure it has it's own cache line. Maybe if you allocate a large enough contiguous block you'll be OK?
mnw21cam 5y ago
You'd have to have the operating system's cooperation, because it may be mapping individual 4k pages all over the place, and it's the only thing that has a chance of knowing how the memory is laid out on the actual chips.
- AshamedCaptain 5y ago
  And the CPU and the chipset's cooperation. In many cases it is even a trade secret how data is striped across the different slots/banks.
  - xxpor 5y ago
    Doesn't the same thing to exploiting rowhammer though? If you're after specific data, how would you know what physical address to use, even if you knew the physical address of the target data?
    - jandrese 5y ago
      Yes, but there is a difference between an attack being run by a low level hardware hacker vs. the software being run by average users. This is why I said it would be hard, you would need to encode a lot of low level hardware knowledge into your application. This might only be useful in very specialized circumstances, like with kernel support on only a handful of carefully chosen hardware platforms. However, someone like Apple could do this on their systems, as they control both the kernel and the hardware. Sensitive memory locations could be cordoned off in special zones with buffering to prevent Rowhammer type attacks.
  - StillBored 5y ago
    <i> it is even a trade secret how data is striped across the different slots/banks </i> If that is true, vs just the usual "you don't need to know" trash common these days, its crazy. A pretty good picture can be built up with just software timing analysis, but its hardly rocket science to hook a logic analyzer/scope up and determine bit swizzling and page/bank interleave. Plus, many of the more open BIOS vendors have tended to provide page/row/controller/socket interleave options for quite a while, partially because it can mean a 5-10% uplift for some applications to have it set one way or the other. Its been one of those how do you tune your memory system options for a couple decades now.
    - deleted 5y ago
      [deleted]
staticassertion 5y ago
If your app is particularly paranoid you could just double your memory usage, and verify errors against the clone.

pas 5y ago

Or use different banks of DRAM for different security contexts, managed via NUMA?

to11mtm 5y ago

I wonder how easy that would be to reason about though. I really don't know much about modern DRAM circuitry I feel like it might be abstracted away to some level, also there are bios-tweaky settings that might make a difference (i.e. things like channel configuration and/or bank interleaving, if that's still a thing.) IDK though. Maybe there's a way. I've worked on code that uses padding around a data structure to ensure it has it's own cache line. Maybe if you allocate a large enough contiguous block you'll be OK?

mnw21cam 5y ago

You'd have to have the operating system's cooperation, because it may be mapping individual 4k pages all over the place, and it's the only thing that has a chance of knowing how the memory is laid out on the actual chips.

AshamedCaptain 5y ago
And the CPU and the chipset's cooperation. In many cases it is even a trade secret how data is striped across the different slots/banks.
- xxpor 5y ago
  Doesn't the same thing to exploiting rowhammer though? If you're after specific data, how would you know what physical address to use, even if you knew the physical address of the target data?
  - jandrese 5y ago
    Yes, but there is a difference between an attack being run by a low level hardware hacker vs. the software being run by average users. This is why I said it would be hard, you would need to encode a lot of low level hardware knowledge into your application. This might only be useful in very specialized circumstances, like with kernel support on only a handful of carefully chosen hardware platforms. However, someone like Apple could do this on their systems, as they control both the kernel and the hardware. Sensitive memory locations could be cordoned off in special zones with buffering to prevent Rowhammer type attacks.
- StillBored 5y ago
  <i> it is even a trade secret how data is striped across the different slots/banks </i> If that is true, vs just the usual "you don't need to know" trash common these days, its crazy. A pretty good picture can be built up with just software timing analysis, but its hardly rocket science to hook a logic analyzer/scope up and determine bit swizzling and page/bank interleave. Plus, many of the more open BIOS vendors have tended to provide page/row/controller/socket interleave options for quite a while, partially because it can mean a 5-10% uplift for some applications to have it set one way or the other. Its been one of those how do you tune your memory system options for a couple decades now.
  - deleted 5y ago
    [deleted]

staticassertion 5y ago

If your app is particularly paranoid you could just double your memory usage, and verify errors against the clone.