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 threadcynicalsecurity ->@bsd.networkApr 4, 2017

@donb @HalvarFlake @Kensan ah, now /that/ I can answer because my dad worked on this precise issue in the 1970s. The short answer is "Mykotron" (those old enough will remember this as the NSA fab which made the Clipper Chip), i.e. build your own tightly controlled fab. The longer answer is a verifiable design built by two/theee separate fabs which are then subjected to 100% coverage with test vectors.

There are issues with this too: how do you cover what has been "added and removed here"?

Show threaddonb
@cynicalsecurity @Kensan @HalvarFlake not just addition/removal, but implementation of the security model, side channel issues exploitable by software, and more. Some friends of mine at Tortuga Logic are doing great work on silicon verification, but it's not exhaustive. You can control what silicon is manufactured, but design verification is a different beast altogether.
Apr 4, 2017 at 7:38pmWeb