
TRRespass: Rowhammer against DDR4 - mdriley
https://www.vusec.net/projects/trrespass/
======
cesarb
IIRC, there was a proposal some time ago to use performance counters to detect
a rowhammer attempt (high number of cache misses) and stop it (by pausing the
offending process until the DRAM refresh can catch up). Did anything come out
of it?

~~~
emavan
Maybe you refer to ANVIL. It was demonstrated to not be completely effective

~~~
cesarb
Thanks for the keyword! Searching for "rowhammer anvil" led me to
[https://web.eecs.umich.edu/~genkin/papers/another-flip-
rowha...](https://web.eecs.umich.edu/~genkin/papers/another-flip-
rowhammer.pdf) which links to
[https://lwn.net/Articles/704920/](https://lwn.net/Articles/704920/) which is
the article I was thinking of. I can't find much else about that kernel patch
other than
[https://patchwork.kernel.org/patch/9400475/](https://patchwork.kernel.org/patch/9400475/)
and
[https://patchwork.kernel.org/patch/9401819/](https://patchwork.kernel.org/patch/9401819/)
so that approach was probably abandoned.

------
kalium_xyz
I wish we could get rid of this dependency on the natural world that computers
seem to have. Sadly I cant of a way to implement computers outside of reality
and have some safe interface to them.

~~~
AnthonyMouse
The dependency comes from pushing the physical limits until the abstraction
leaks. Older memory technologies were not vulnerable to rowhammer. But they
were also a lot slower.

~~~
CarlRJ
That's it, we're going back to core memory.

~~~
BuildTheRobots
If you thought "cold boot attacks" were a problem with DDR, using memory that
still holds data 50 years later might be an issue.

[https://en.wikipedia.org/wiki/Cold_boot_attack](https://en.wikipedia.org/wiki/Cold_boot_attack)

------
gentleman11
Theoretically, if we accepted lower performance, could we design our hardware
and software to actually be secure? The number of exploits over the last two
years is making my head spin

~~~
Jap2-0
This brings up something I've often wondered about: we can basically guarantee
that a very short snippet of code (say, a few lines) is secure, right?
However, there is no real way to guarantee that full programs are secure. Can
we not truly guarantee that some portion of code is secure, or is it simply
the amount of code that makes it impractical (and financially infeasible)? If
the latter, what is the practical boundary?

~~~
simcop2387
> we can basically guarantee that a very short snippet of code (say, a few
> lines) is secure, right?

That's the problem, we can't do that. Between hardware flaws like rowhammer,
meltdown, spectre, etc. it's not possible to say that a piece of code isn't
going to trigger something intentionally or not.

You can say that something very very likely doesn't trigger any known
vulnerability, but only while also specifying the exact hardware to run it on
and probably other external variables.

~~~
Jap2-0
> Between hardware flaws like rowhammer, meltdown, spectre, etc. it's not
> possible to say that a piece of code isn't going to trigger something
> intentionally or not.

I guess I was thinking software vulnerabilities specifically (although in the
context of this article I should have thought about the hardware side more).
Or to be even more specific, flaws that are from that program in particular.

~~~
simcop2387
Software side there's a lot that can be proven and said about small sections
of programs. I think a sibling commenter talked about an ISO standard related
to that (And I think it covers some hardware bits). My layman's understanding
of it is that it's a way to specify as many assumptions about how the code
will be run, where, and what side effects it will have and no others. That
makes for a really nice set of assertions but the end effect is that you can't
say anything about certain kinds of programs; i.e. This program is safe, That
program can't be safe, and then these programs are unknowable. Godel should
never have been allowed to publish anything.

~~~
saagarjha
Making those proofs is nice and all, but they rarely take side channels or
processor bugs into account.

------
guug
ECC should be standard and mandatory at this point.

~~~
logicchains
Not everybody's working on web or something running untrusted code. Not fair
to force people to pay a financial or performance hit for something they don't
need; the world loses if peoples' scientific computations take 20% longer to
run because of some ugly patch to an obscure vulnerability in speculative
execution, or because the university can afford less computing resources
because the only option is expensive ram.

~~~
Dylan16807
If ECC was made for the same markets as normal memory, it would cost <12% more
and make entire computers cost <2% more, with no meaningful performance hit.
It's reasonable and should be mainstream.

You want ECC for trusted code, too.

------
forkexec
How expensive would 16 GiB of refress-less "4 nm" SRAM placed on the CPU
package flip-chip style be?

~~~
duskwuff
Ludicrously expensive. The largest SRAMs that are commercially available are
around 288 Mbit (32 MB with parity), and cost hundreds of dollars per chip.

I'm not sure you could even _physically_ fit 16 GiB of SRAM onto a CPU with
current technology. SRAM cells are much larger than DRAM.

~~~
willis936
AMD’s Epyc 7742 has 256 MB of SRAM in its central die. That die is massive and
the chip costs 7 grand.

------
vlovich123
Time yet to add support to encrypt memory transparently in the DRAM
controller?

~~~
cesarb
That already exists with AMD SME and AMD SEV
([https://en.wikipedia.org/wiki/Zen_(microarchitecture)#Enhanc...](https://en.wikipedia.org/wiki/Zen_\(microarchitecture\)#Enhanced_security_and_virtualization_support)).
But to protect against bit flipping attacks like rowhammer you need
authentication, not encryption, and I don't think these features authenticate
the encrypted memory (since they would need extra memory to hold the
authentication tag).

~~~
mjevans
The parent post is probably thinking of the bit-scrambling involved in the
encryption providing some form of protection.

~~~
simcop2387
Yea, it should prevent usable bitflips from hapoening. Instead you'd get
complete corruption of a block

------
wyldfire
might want to merge this with
[https://news.ycombinator.com/item?id=22547324](https://news.ycombinator.com/item?id=22547324)

