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

Russell rreiter91 at gmail.com
Sat Jan 13 16:19:22 EST 2018

On January 13, 2018 3:35:01 PM EST, "D. Hugh Redelmeier via talk" <talk at gtalug.org> wrote:
>| From: David Collier-Brown via talk <talk at gtalug.org>
>| Oracle and Fujitsu (who actually make the chips) still hasn't said
>| machine types will suffer from speculation attacks, but did implement
>| hardware cache change recently in the M7 and M8  series (the
>| 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
>| 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
>| isn't the same "version" as your process. Version sounds like a short
>| used like a pid, but don't quote me on that: the papers are written
>| marketers, not engineers (;-))
>| See
>Interesting.  This looks like it catches bugs where a program uses an
>pointer that points to memory that has since been freed and possibly 
>- 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
>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
>error.  It is also nice to know that this kind of error won't be

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.



Spartan to date, but Brendan Gregg has several enthusiastic videos out there.

Linux Superpowers with eBPF


More information about the talk mailing list