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 08:29:49 -0700 |
| |
On 01/13/2017 07:48 AM, Khalid Aziz wrote: > 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?
Sure, if you have write access to begin with, you can set memory versions, then remove write access to the page. But I think the point is that if a process doesn't have write access, and cannot get it, then it will not ever be able to change memory versions. So in the example of a non-root process opening /etc/passwd (read only), and mmaping it, the mapping would be read-only as well. Personally I don't really see a use case for ADI on memory mapped to a file. In an abstract sense, the "backing store" for a memory mapped file is the file itself on disk, not physical memory. And there is already a way to restrict access to files, so perhaps ADI should simply be disallowed for memory mapped to files, and this particular complication can be avoided. Thoughts?
Incidentally, I see ADI as primarily a way to protect memory from improper access within a process or group of cooperating processes. There is already a way to protect memory from unrelated processes, and if that is circumvented somehow, then ADI won't help at all. Perhaps we should stop talking about ADI as a "security" feature; It does add a layer of protection against buffer overflow attacks, but this attack only exists when there is a bug in the underlying application. If an attacker gains access to the virtual memory for a process, then nothing can help you.
Rob
> > -- > 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 >
| |