linux-kernel - Re: [git pull] vfs.git misc bits

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] [day] [month] [year] [list]

Message-ID: <Y/pPV0q43R+drVtV@ZenIV>
Date:   Sat, 25 Feb 2023 18:11:35 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-arch@...r.kernel.org
Subject: Re: [git pull] vfs.git misc bits

On Sat, Feb 25, 2023 at 09:04:57AM -0800, Linus Torvalds wrote:
> On Fri, Feb 24, 2023 at 8:57 PM Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > Let's have it sit around for at least a few days, OK?  I mean, I'm pretty
> > certain that these are fixes, but they hadn't been in any public tree -
> > only posted to linux-arch.  At least #fixes gets picked by linux-next...
> 
> Ack, sounds good.

... and Intel build-bot had immediately caught a breakage in microblaze.
Fixed and pushed out; I've checked all architectures affected by
this series, and that was the only build breakage.  However, I still have
no way to test it (or anything, for that matter) on microblaze - I've no
userland images for it.  Status right now:

alpha: bug confirmed, patch fixes it.
hexagon, m68k, riscv: acked by maintainer (with explicit tested-by for m68k and riscv)
microblaze, openrisc, nios2: builds, no way for me to test.
sparc32, sparc64, itanic: builds, preparing to test (itanic - once I resurrect
the sodding space heater I hadn't tried to boot for a couple of years; no
idea whether it works).
parisc: builds, but maintainers say that reproducer doesn't confirm the bug
in mainline.  I've parisc32 box, will try to resurrect and see what's going
on.  No way to test parisc64 here - no hardware and qemu/pa-risc doesn't handle
64bit system emulation.

Incidentally, while digging through the arch code around #PF, something's
weird on csky.  Not this bug (it's handled correctly there), but...
looks like vm_get_page_prot(0) returns something that would *not*
pass pte_present().  Which should make life wonderful for e.g. PROT_READ|PROT_WRITE
mmap() + memcpy to it + PROT_NONE mprotect() + PROT_READ|PROT_WRITE mprotect().

Unless I'm seriously misunderstanding something, we have 3 mutually exclusive
cases:
	absent PTE - no further information in it.  No page at the corresponding
address range, access will fault and work from scratch; pte_none() is true for those.
	swap PTE - page had been swapped out, access will fault, the information in
the entry encodes the location in swap.  is_swap_pte() is true for those.
	normal page - page is there, access might or might not fault due to permissions,
PTE contains the page frame number.  pte_present() is true for those.

PROT_NONE should not yield something that looks like a swap entry.  And on csky we
have
#define PAGE_NONE       __pgprot(_PAGE_PROT_NONE)
#define pte_none(pte)           (!(pte_val(pte) & ~_PAGE_GLOBAL))
#define pte_present(pte)        (pte_val(pte) & _PAGE_PRESENT)

and

arch/csky/abiv1/inc/abi/pgtable-bits.h:26:#define _PAGE_PROT_NONE               _PAGE_READ
arch/csky/abiv1/inc/abi/pgtable-bits.h:8:#define _PAGE_READ             (1<<1)
arch/csky/abiv1/inc/abi/pgtable-bits.h:14:#define _PAGE_GLOBAL          (1<<6)
arch/csky/abiv1/inc/abi/pgtable-bits.h:7:#define _PAGE_PRESENT          (1<<0)

arch/csky/abiv2/inc/abi/pgtable-bits.h:26:#define _PAGE_PROT_NONE               _PAGE_WRITE
arch/csky/abiv2/inc/abi/pgtable-bits.h:9:#define _PAGE_WRITE            (1<<9)
arch/csky/abiv2/inc/abi/pgtable-bits.h:14:#define _PAGE_GLOBAL          (1<<0)
arch/csky/abiv2/inc/abi/pgtable-bits.h:10:#define _PAGE_PRESENT         (1<<10)

IOW, on both ABI variants we have PAGE_NONE looking like a malformed swap entry.
And is_swap_pte() is simply !pte_none() && !pte_present()...