Messages in this thread | | | Subject | Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7 | From | Rob Gardner <> | Date | Fri, 13 Jan 2017 10:36:26 -0700 |
| |
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
| |