On January 13, 2018 3:35:01 PM EST, "D. Hugh Redelmeier via talk" <[email protected]> wrote: >| 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.
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 --- Talk Mailing List [email protected] https://gtalug.org/mailman/listinfo/talk
