lkml.org 
[lkml]   [2017]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7
From
Date
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



\
 
 \ /
  Last update: 2017-01-13 18:39    [W:0.166 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site