HalvarFlakeApr 4, 2017
"Thus, determining the correct rate
at which to refresh DRAM cells has become more difficult, as also
indicated by industry [45]. This is due to two major phenomena, both
of which get worse (i.e., become more prominent) with technology
scaling. First, Data Pattern Dependence (DPD): the retention time of a DRAM cell is heavily dependent on the data pattern stored in itself and in the neighboring cells [69]. " - worth reading: https://arxiv.org/pdf/1703.00626.pdf
Show threadcynicalsecurity ->@bsd.networkApr 4, 2017
@HalvarFlake this is beautiful: basically non-deterministic RAM. It means that all the work Sun Microsystems had done on self-healing suddenly becomes of great relevance because you have to assume RAM is not trustworthy unless verified.
Show threaddonbApr 4, 2017
@cynicalsecurity @HalvarFlake RAM is also not trustworthy if verified then presumed safe, e.g. tOCTOU bus hijacking. This is provable using lower bandwidth RAM technologies like PSRAM where there are fewer pins and lower speed. I've done it in closed environments as a PoC. The only solution is RAM with a TPM embedded or the ability to encrypt all before it traverses the bus. Either solution is expensive although Atmel's crypto RAM is a good step.
Show threadcynicalsecurity ->@bsd.networkApr 4, 2017
@donb @HalvarFlake that is a very good point: you cannot trust the bus. How are we doing on external attacks against the bus à-la-Rowhammer?
Show threaddonbApr 4, 2017
@cynicalsecurity that's a better question for @HalvarFlake. My solution is to not let adversaries load code or finesse execution environments
Show threadcynicalsecurity ->@bsd.networkApr 4, 2017
@donb how on Earth do you prevent adversaries from running code, assuming your computers are used by humans? @HalvarFlake
Show threaddonb
@cynicalsecurity @HalvarFlake it's a lot easier to do in IoT architectures where you control all executable code :)
Apr 4, 2017 at 5:24pmAmaroq