[GTALUG] "Secured Memory" [was Re: Spectre type 2: Branch Target Injection}

[D. Hugh Redelmeier]

| From: David Collier-Brown via talk <talk at 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-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.