linux-kernel - Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks

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: <83E86178-FBC7-49C5-B624-8B8106D10CBC@zytor.com>
Date: Mon, 11 Mar 2024 19:20:54 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andy Lutomirski <luto@...nel.org>, Dave Hansen <dave.hansen@...el.com>,
        Nadav Amit <nadav.amit@...il.com>
CC: Pasha Tatashin <pasha.tatashin@...een.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Borislav Petkov <bp@...en8.de>, Christian Brauner <brauner@...nel.org>,
        bristot@...hat.com, Ben Segall <bsegall@...gle.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, dianders@...omium.org,
        dietmar.eggemann@....com, eric.devolder@...cle.com, hca@...ux.ibm.com,
        "hch@...radead.org" <hch@...radead.org>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Jason Gunthorpe <jgg@...pe.ca>, jpoimboe@...nel.org,
        Joerg Roedel <jroedel@...e.de>, juri.lelli@...hat.com,
        Kent Overstreet <kent.overstreet@...ux.dev>, kinseyho@...gle.com,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        lstoakes@...il.com, mgorman@...e.de, mic@...ikod.net,
        michael.christie@...cle.com, Ingo Molnar <mingo@...hat.com>,
        mjguzik@...il.com, "Michael S. Tsirkin" <mst@...hat.com>,
        Nicholas Piggin <npiggin@...il.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Petr Mladek <pmladek@...e.com>,
        Rick P Edgecombe <rick.p.edgecombe@...el.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Uladzislau Rezki <urezki@...il.com>, vincent.guittot@...aro.org,
        vschneid@...hat.com
Subject: Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks

On March 11, 2024 7:16:38 PM PDT, Andy Lutomirski <luto@...nel.org> wrote:
>On Mon, Mar 11, 2024, at 6:25 PM, H. Peter Anvin wrote:
>> On March 11, 2024 5:53:33 PM PDT, Dave Hansen <dave.hansen@...el.com> wrote:
>>>On 3/11/24 16:56, Nadav Amit wrote:
>>>> So you can look on the dirty-bit, which is not being set
>>>> speculatively and save yourself one problem.
>>>Define "set speculatively". :)
>>>
>>>> If software on one logical processor writes to a page while software
>>>> on another logical processor concurrently clears the R/W flag in the
>>>> paging-structure entry that maps the page, execution on some
>>>> processors may result in the entry’s dirty flag being set (due to the
>>>> write on the first logical processor) and the entry’s R/W flag being
>>>> clear (due to the update to the entry on the second logical
>>>> processor).
>>>
>>>In other words, you'll see both a fault *AND* the dirty bit.  The write
>>>never retired and the dirty bit is set.
>>>
>>>Does that count as being set speculatively?
>>>
>>>That's just the behavior that the SDM explicitly admits to.
>>
>> Indeed; both the A and D bits are by design permissive; that is, the 
>> hardware can set them at any time.
>>
>> The only guarantees are:
>>
>> 1. The hardware will not set the A bit on a not present late, nor the D 
>> bit on a read only page.
>
>Wait a sec.  What about setting the D bit on a not-present page?
>
>I always assumed that the actual intended purpose of the D bit was for things like file mapping.  Imagine an alternate universe in which Linux used hardware dirty tracking instead of relying on do_wp_page, etc.
>
>mmap(..., MAP_SHARED): PTE is created, read-write, clean
>
>user program may or may not write to the page.
>
>Now either munmap is called or the kernel needs to reclaim memory.  So the kernel checks if the page is dirty and, if so, writes it back, and then unmaps it.
>
>Now some silly people invented SMP, so this needs an atomic operation:  xchg the PTE to all-zeros, see if the dirty bit is set, and, if itt's set, write back the page.  Otherwise discard it.
>
>Does this really not work on Intel CPU?
>

Sorry, I should have been more clear.

Hardware will not set a bit that would correspond to a prohibited access.