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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ae1662fa-4e51-d92d-7f19-403c92406194@oracle.com>
Date:   Thu, 12 Jan 2017 17:22:26 -0700
From:   Khalid Aziz <khalid.aziz@...cle.com>
To:     Dave Hansen <dave.hansen@...ux.intel.com>, davem@...emloft.net,
        corbet@....net, arnd@...db.de, akpm@...ux-foundation.org
Cc:     hpa@...or.com, viro@...iv.linux.org.uk, nitin.m.gupta@...cle.com,
        chris.hyser@...cle.com, tushar.n.dave@...cle.com,
        sowmini.varadhan@...cle.com, mike.kravetz@...cle.com,
        adam.buchbinder@...il.com, minchan@...nel.org, hughd@...gle.com,
        kirill.shutemov@...ux.intel.com, keescook@...omium.org,
        allen.pais@...cle.com, aryabinin@...tuozzo.com,
        atish.patra@...cle.com, joe@...ches.com, pmladek@...e.com,
        jslaby@...e.cz, cmetcalf@...lanox.com,
        paul.gortmaker@...driver.com, mhocko@...e.com, jmarchan@...hat.com,
        lstoakes@...il.com, 0x7f454c46@...il.com, vbabka@...e.cz,
        tglx@...utronix.de, mingo@...hat.com, dan.j.williams@...el.com,
        iamjoonsoo.kim@....com, mgorman@...hsingularity.net,
        vdavydov.dev@...il.com, hannes@...xchg.org, namit@...are.com,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-arch@...r.kernel.org,
        x86@...nel.org, linux-mm@...ck.org
Subject: Re: [PATCH v4 0/4] Application Data Integrity feature introduced by
 SPARC M7

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 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?

Thanks,
Khalid