Date:   Wed, 11 Jan 2017 11:11:55 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Khalid Aziz <khalid.aziz@...cle.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/11/2017 10:50 AM, Khalid Aziz wrote:
> On 01/11/2017 11:13 AM, Dave Hansen wrote:
>> On 01/11/2017 08:56 AM, Khalid Aziz wrote:
>> For memory shared by two different processes, do they have to agree on
>> what the tags are, or can they differ?
> 
> The two processes have to agree on the tag. This is part of the security
> design to prevent other processes from accessing pages belonging to
> another process unless they know the tag set on those pages.

So what do you do with static data, say from a shared executable?  You
need to ensure that two different processes from two different privilege
domains can't set different tags on the same physical memory.  That
would seem to mean that you must not allow tags to be set of memory
unless you have write access to it.  Or, you have to ensure that any
file that you might want to use this feature on is entirely unreadable
(well, un-mmap()-able really) by anybody that you are not coordinating with.

If you want to use it on copy-on-write'able data, you've got to ensure
that you've got entirely private copies.  I'm not sure we even have an
interface to guarantee that.  How could this work after a fork() on
un-COW'd, but COW'able data?

>>> Potential for side
>>> effects is too high in such case and would require kernel to either
>>> track tags for every page as they are re-allocated or migrated, or scrub
>>> pages constantly to ensure we do not get spurious tag mismatches. Unless
>>> there is a very strong reason to blindly set TTE.mcd on every PTE, I
>>> think the risk of instability is too high without lot of extra code.
>>
>> Ahh, ok.  That makes sense.  Clearing the tags is expensive.  We must
>> either clear tags or know the previous tags of the memory before we
>> access it.
>>
>> Are any of the tags special?  Do any of them mean "don't do any
>> checking", or similar?
> 
> Tag values of 0 and 15 can be considered special. Setting tag to 15 on
> memory range is disallowed. Accessing a memory location whose tag is
> cleared (means set to 0) with any tag value in the VA is allowed. Once a
> tag is set on a memory, and PSTATE.mcde and TTE.mcd are set, there isn't
> a tag that can be used to bypass version check by MMU.

Bummer.  If the hardware had allowed a special VA tag to bypass checks,
then you wouldn't need to worry about clearing the tags, and you
wouldn't need the interface to control the PTE bit setting/clearing.

Powered by blists - more mailing lists