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: <D4D747C5-2B0E-44B0-A550-BA05BE0AF2FA@zytor.com>
Date: Mon, 11 Mar 2024 18:25:56 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Dave Hansen <dave.hansen@...el.com>, Nadav Amit <nadav.amit@...il.com>,
        Andy Lutomirski <luto@...nel.org>
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 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.

2. *Provided that the user has invalidated the page entry in the TLB*, hardware guarantees the respective bits will be set before a dependent memory access is made visible. Thus the bits are guaranteed to reflect a strict superset of operations performed architecturally.