lkml.org 
[lkml]   [2017]   [Jan]   [12]   [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/12/2017 05:22 PM, Khalid Aziz wrote:
> On 01/12/2017 10:53 AM, Dave Hansen wrote:
>> On 01/12/2017 08:50 AM, Khalid Aziz wrote:
>>> 2. Any shared page that has ADI protection enabled on it, must stay ADI
>>> protected across all processes sharing it.
>>
>> Is that true?
>>
>> What happens if a page with ADI tags set is accessed via a PTE without
>> the ADI enablement bit set?
>
> ADI protection applies across all processes in terms of all of them
> must use the same tag to access the shared memory, but if a process
> accesses a shared page with TTE.mcde bit cleared, access will be granted.
>
>>
>>> COW creates an intersection of the two. It creates a new copy of the
>>> shared data. It is a new data page and hence the process creating it
>>> must be the one responsible for enabling ADI protection on it.
>>
>> Do you mean that the application must be responsible? Or the kernel
>> running in the context of the new process must be responsible?
>>
>>> It is also a copy of what was ADI protected data, so should it
>>> inherit the protection instead?
>>
>> I think the COW'd copy must inherit the VMA bit, the PTE bits, and the
>> tags on the cachelines.
>>
>>> I misspoke earlier. I had misinterpreted the results of test I ran.
>>> Changing the tag on shared memory is allowed by memory controller. The
>>> requirement is every one sharing the page must switch to the new tag or
>>> else they get SIGSEGV.
>>
>> I asked this in the last mail, but I guess I'll ask it again. Please
>> answer this directly.
>>
>> If we require that everyone coordinate their tags on the backing
>> physical memory, and we allow a lower-privileged program to access the
>> same data as a more-privileged one, then the lower-privilege app can
>> cause arbitrary crashes in the privileged application.
>>
>> For instance, say sudo mmap()'s /etc/passwd and uses ADI tags to protect
>> the mapping. Couldn't any other app in the system prevent sudo from
>> working?
>>
>> How can we *EVER* allow tags to be set on non-writable mappings?

I don't think you can write a tag to memory if you don't have write
access in the TTE. Writing a tag requires a store instruction, and if
the machine is at all sane, this will fault if you don't have write access.

Rob



>
> I understand your quetion better now. That is a very valid concern.
> Using ADI tags to prevent an unauthorized process from just reading
> data in memory, say an in-memory copy of database, is one of the use
> cases for ADI. This means there is a reasonable case to allow enabling
> ADI and setting tags even on non-writable mappings. On the other hand,
> if an unauthorized process manages to map the right memory pages in
> its address space, it can read them any way by not setting TTE.mcd.
>
> Userspace app can set tag on any memory it has mapped in without
> requiring assistance from kernel. Can this problem be solved by not
> allowing setting TTE.mcd on non-writable mappings? Doesn't the same
> problem occur on writable mappings? If a privileged process mmap()'s a
> writable file with MAP_SHARED, enables ADI and sets tag on the mmap'd
> memory region, then another lower privilege process mmap's the same
> file writable (assuming file permissions allow it to), enables ADI and
> sets a different tag on it, the privileged process would get SIGSEGV
> when it tries to access the mmap'd file. Right?



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