linux-kernel - Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <7f78da33-a591-e913-d96e-fec022f2ba9e@oracle.com>
Date:   Fri, 6 Jan 2017 11:18:01 -0700
From:   Khalid Aziz <khalid.aziz@...cle.com>
To:     Rob Gardner <rob.gardner@...cle.com>,
        David Miller <davem@...emloft.net>, dave.hansen@...ux.intel.com
Cc:     mhocko@...nel.org, corbet@....net, arnd@...db.de,
        akpm@...ux-foundation.org, 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, 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, khalid@...ehiking.org
Subject: Re: [RFC PATCH v3] sparc64: Add support for Application Data
 Integrity (ADI)

On 01/06/2017 10:54 AM, Rob Gardner wrote:
> On 01/06/2017 09:10 AM, Khalid Aziz wrote:
>> On 01/06/2017 10:02 AM, David Miller wrote:
>>> From: Dave Hansen <dave.hansen@...ux.intel.com>
>>> Date: Fri, 6 Jan 2017 08:55:03 -0800
>>>
>>>> Actually, that reminds me...  How does your code interface with
>>>> ksm?  Or
>>>> is there no interaction needed since you're always working on virtual
>>>> addresses?
>>>
>>> This reminds me, I consider this feature potentially extremely useful
>>> for
>>> kernel debugging.  So I would like to make sure we don't implement
>>> anything
>>> in a way which would preclude that in the long term.
>>
>> I agree and please do point out if I have made any implementation
>> decisions that could preclude that.
>>
>> Thanks,
>> Khalid
>
>
> Khalid, I have already pointed out an implementation decision that
> interferes with the potential for kernel debugging with ADI: lazy
> clearing of version tags.

This does not preclude kernel debugging. If kernel debugging ends up 
requiring tags be cleared whenever a page is freed, we can add that code 
as part of kernel debugging support code and enable it conditionally 
only when kernel is being debugged. Forcing every task to incur the 
large cost of clearing tags on every "free" all the time is just not an 
acceptable cost only to support kernel debugging. It should be a dynamic 
switch to be toggled on only when debugging kernel. PSTATE.mcde being 
set is not enough to trigger a trap. It is easy enough to clear TTE.mcd 
before block initialization of a page and avoid a trap due to tag 
mismatch, or just use physical address with block initialization.

We can evaluate all of these options when we get to implementing kernel 
debugging using ADI.

Thanks,
Khalid


>
> Details: when memory is "freed" the version tags are left alone, as it
> is an expensive operation to go through the memory and clear the tag for
> each cache line. So this is done lazily whenever memory is "allocated".
> More specifically, the first time a user process touches freshly
> allocated memory, a fault occurs and the kernel then clears the page. In
> the NG4 and M7 variants of clear_user_page, the block init store ASI is
> used to optimize, and it has the side effect of clearing the ADI tag for
> the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set,
> then instead of the ADI tag being cleared, the tag is *checked*, and if
> there is a mismatch between the version in the virtual address and the
> version in memory, then you'll get a trap and panic. Therefore, with
> this design, you cannot have pstate.mcde enabled while in the kernel (in
> general). To solve this you have to check the state of pstate.mcde (or
> just turn it off) before doing any block init store in clear_user_page,
> memset, memcpy, etc.
>
> Rob
>
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html