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

[Russell]

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
>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.

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