linux-kernel - Re: [tip: x86/mm] x86/mm: Clear _PAGE_DIRTY when we clear _PAGE

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: <CAHk-=wj+VBV5kBMfXYNOb+aLt3WJqMKFT0wU=KaV3R12NvN5TA@mail.gmail.com>
Date: Tue, 25 Feb 2025 19:31:01 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org, 
	kernel test robot <oliver.sang@...el.com>, Ingo Molnar <mingo@...nel.org>, x86@...nel.org
Subject: Re: [tip: x86/mm] x86/mm: Clear _PAGE_DIRTY when we clear _PAGE_RW

On Tue, 25 Feb 2025 at 18:45, Matthew Wilcox <willy@...radead.org> wrote:
>
> Are you saying that the PTE dirty bit controls whether the CPU flushes
> cache back to memory?  That isn't how I understand CPUs to work.

No, I'm saying that dropping the dirty bit drops information.

Yes, yes, we have the SW-dirty bit, and hopefully that is indeed
always set, but the way we test for "is this page dirty and needs
writeback" is literally to test *both*.

        return pte_flags(pte) & _PAGE_DIRTY_BITS;

> I don't understand why the dirty bit needs to be saved.  At least in
> the vfree() case, we're freeing the memory so any unflushed writes to
> it may as well disappear.  But I don't know all the circumstances in
> which these functions are called.

I'm not saying that it needs to be saved.

But I *am* saying that it needs to be explained why dropping it is fine.

And I am also saying that your explanation for why it should be
cleared makes no sense, since two out of three cases also cleared
_PAGE_PRESENT, at which point the whole shadow stack issue is
completely irrelevant.

So please explain *why* clearing PAGE_DIRTY is ok. Don't bring up
issues like the shadow stack setting that is irrelevant for at least
two of the cases that you changed.

If all of these are purely used for vmalloc() or direct mappings, then
*that* is a valid explanation ("we don't care about dirty bits on
kernel mappings"), for example.

               Linus