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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux