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

[Khalid Aziz <khalid.aziz@oracle.com>]

On 01/12/2017 06:31 PM, Rob Gardner wrote:
> 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.
>

But could you have mmap'd the file writable, set the tags and then 
changed the protection on memory to read-only? That would be the logical 
way to ADI protect a memory being used to mmap a file. Right?

--
Khalid

> 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?
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html