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