| From: David Collier-Brown via talk <[email protected]>
| 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-memory
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.
---
Talk Mailing List
[email protected]
https://gtalug.org/mailman/listinfo/talk
