On January 13, 2018 3:35:01 PM EST, "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:
| From: David Collier-Brown via talk <talk@gtalug.org>
| Oracle and Fujitsu (who actually make the chips) still hasn't said which | machine types will suffer from speculation attacks, but did implement a | hardware cache change recently in the M7 and M8 series (the conventional, | glow-in-the-dark 5 GHz chipsets that speculate wildly) which they market as | "Silicon Secured Memory".
The date on this document (2016 Feb 11) suggests that it isn't about Spectre-like or Meltdown-like attacks.
| It reads as if they've been having trouble with "invalid [memory references], | stale memory reference and buffer overflows", and have added microcode to | cause SEGVs before the data arrives if you try to fetch a cache line that | isn't the same "version" as your process. Version sounds like a short value | used like a pid, but don't quote me on that: the papers are written by | marketers, not engineers (;-)) | | See | https://blogs.oracle.com/partnertech/sas-and-oracle-sparc-m7-silicon-secured...
Interesting. This looks like it catches bugs where a program uses an old pointer that points to memory that has since been freed and possibly reallocated.
- the metadata is only 4 bits, so there could be cases that are not caught (not too likely unless the error is engineered by an opponent)
- the metadata is per cache-line. I'm guessing that that means the malloc(3) and free(3) routines must paint the memory with this metadata, with one operation per cache-line-sized chunk of RAM.
An additional feature would be that if a pointer were used to attempt to reference the next object in memory, it would likely fail due to metadata clash.
On Linux there is a library called Electric Fence (efence) that will catch roughly the same errors. When you link it in, each malloc allocates a whole new page of memory. Free unmaps that page. So references through dangling pointers become segfaults. Bonus: it places the object at the end of the page so that overruns cause segfaults. (Fine print: there is a global runtime option to place the objects at the start of pages so underrun is caught instead.)
In theory, efence is quite expensive: each object takes a page of memory. Core dumps get quite large. But in many real-world programs, the memory isn't a problem. I used this extensively many years ago when memories were a lot smaller and addresses were only 32 bits.
I would expect that the SPARC feature could be used in production code whereas few would use efence that way.
With a sensible high level language, these checks should not be important. But for C and C++ it is useful. When trying to debug a failure, it is really nice to know automatically that it is or isn't due to this kind of error. It is also nice to know that this kind of error won't be silent.
Speaking up, so to speak; Current buzz indicates Skylake and better CPU's survive these Lfence kludge's, hopefully to +-5% perf hits. Ad Hoc it looks like more than that on my new setup after this mornings dnfdragora updates I notice that Enhanced Berkeley Packet Filtering is now in kernel 4.x. http://www.brendangregg.com/ebpf.html https://github.com/iovisor/bcc/blob/master/INSTALL.md#fedora---binary Spartan to date, but Brendan Gregg has several enthusiastic videos out there. Linux Superpowers with eBPF https://youtu.be/bj3qdEDbCD4 -- Russell