Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[Rob Gardner]

On 01/13/2017 09:08 AM, Dave Hansen wrote:
> On 01/13/2017 07:29 AM, Rob Gardner wrote:
> > so perhaps ADI should simply be disallowed for memory mapped to
> > files, and this particular complication can be avoided. Thoughts?
> What's a "file" from your perspective?
>
> In Linux, shared memory is a file.  hugetlbfs is done with files.  Many
> databases mmap() their data into their address space.

Of course I meant a traditional file is the DOS sense, ie, data stored 
on something magnetic. ;) But it doesn't really matter because I am just 
trying to envision a use case for any of the mmap scenarios.

For instance a very persuasive use case for ADI is to 'color' malloc 
memory, freed malloc memory, and malloc's metadata with different ADI 
version tags so as to catch buffer overflows, underflows, use-after-free 
and use-after-realloc type scenarios. What is an equally compelling or 
even mildly interesting use case for ADI in shared memory and file mmap 
situations? Maybe you could mmap a file and immediately tag the entire 
thing with some version, thus disallowing all access to it, and then 
hand out access a chunk at a time. And then?

Rob