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  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]
Date:   Mon, 11 Oct 2021 16:59:28 -0700
From:   Linus Torvalds <>
To:     Catalin Marinas <>
Cc:     Al Viro <>,
        Andreas Gruenbacher <>,
        Christoph Hellwig <>,
        "Darrick J. Wong" <>, Jan Kara <>,
        Matthew Wilcox <>,
        cluster-devel <>,
        linux-fsdevel <>,
        Linux Kernel Mailing List <>,
        "" <>,
        Josef Bacik <>,
        Will Deacon <>
Subject: Re: [RFC][arm64] possible infinite loop in btrfs search_ioctl()

On Mon, Oct 11, 2021 at 2:08 PM Catalin Marinas <> wrote:
> +#ifdef CONFIG_ARM64_MTE
> +#define FAULT_GRANULE_SIZE     (16)


> If this looks in the right direction, I'll do some proper patches
> tomorrow.

Looks fine to me. It's going to be quite expensive and bad for caches, though.

That said, fault_in_writable() is _supposed_ to all be for the slow
path when things go south and the normal path didn't work out, so I
think it's fine.

I do wonder how the sub-page granularity works. Is it sufficient to
just read from it? Because then a _slightly_ better option might be to
do one write per page (to catch page table writability) and then one
read per "granule" (to catch pointer coloring or cache poisoning

That said, since this is all preparatory to us wanting to write to it
eventually anyway, maybe marking it all dirty in the caches is only


Powered by blists - more mailing lists