linux-kernel - Re: [GIT PULL] x86/shstk for 6.4

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: <061cd3573d105969e4c439d61f74134fbc78d2db.camel@intel.com>
Date:   Sun, 7 May 2023 15:57:07 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "Torvalds, Linus" <torvalds@...ux-foundation.org>
CC:     "keescook@...omium.org" <keescook@...omium.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: Re: [GIT PULL] x86/shstk for 6.4

On Sat, 2023-05-06 at 17:38 -0700, Linus Torvalds wrote:
> So that means that the
> 
>         if (pte_dirty(pte))
>                 pte = pte_mksaveddirty(pte);
> 
> in pte_wrprotect() is just nonsensical, and basically says "if either
> the real dirty or the SW dirty bit is set, set the SW dirty bit". But
> that's entirely redundant wrt the old state of the dirty bit.
> 
> It reality should just 'or' the HW dirty bit into the SW dirty bit
> and
> be done with it.
> 
> Of course, maybe I confused the issue by talking about HW dirty and
> SW
> dirty, because we *also* have that entirely *other* legacy
> "SOFT_DIRTY" bit that is different from the new SW dirty bit
> ("SAVED_DIRTY").

Sorry, I did think you meant the old _PAGE_SOFT_DIRTY when you were
talking about the SW dirty bit here.

Yea, if only _PAGE_SAVED_DIRTY is set, and not _PAGE_DIRTY, then it's
pointless to do pte_mksaveddirty() here. So I guess you were pointing
out an example of the general wrongness you elaborated on. I thought
you were saying it was a functional bug.