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 threadKensanApr 4, 2017
@cynicalsecurity @HalvarFlake @donb Side-question: How far can we trust the IOMMU? References would be very much appreciated!
Show threaddonbApr 4, 2017
@Kensan @HalvarFlake @cynicalsecurity counter: how can we trust silicon? :)
Show threadKensanApr 4, 2017
@donb @cynicalsecurity @HalvarFlake I would be fine with having a sane way to trustworthy firmware...
Show threaddonb
@Kensan @HalvarFlake @cynicalsecurity now that we can do! sort of! :)
Apr 4, 2017 at 7:33pmWeb