Messages in this thread | | | Subject | Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7 | From | Rob Gardner <> | Date | Thu, 12 Jan 2017 18:31:45 -0700 |
| |
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?
| |