linux-kernel - Re: [PATCH] arm: drop arch implementation for find

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: <CAHk-=wjDk4iug---FSTxbbNX_JDh4gAXCL4PhZ0JGKuu00SMmg@mail.gmail.com>
Date:   Tue, 26 Jul 2022 11:48:39 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Yury Norov <yury.norov@...il.com>, linux-kernel@...r.kernel.org,
        Dennis Zhou <dennis@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm: drop arch implementation for find_bit() functions

On Tue, Jul 26, 2022 at 11:35 AM Guenter Roeck <linux@...ck-us.net> wrote:
>
> bitmap unit tests succeed, and the KFENCE report is no longer seen
> even after 65 retries (previously it reproduced easily with 5-15
> retries).
>
> Tested-by: Guenter Roeck <linux@...ck-us.net>

Russell, how do you want to handle this?

It's not exactly super-critical, in that this whole issue with the
bitmap overrun probably not happening in real life outside of the
tests. And even when it does happen, it's probably just going to be a
read that nobody cares about (ie very unlikely to hit something like a
"next-page-is-not-mapped" situation).

But it *could* trigger those kinds of things, I guess.

I'll happily take the patch myself as-is, it seems very safe
(considering that all architectures except for 32-bit arm and m68k
already use the generic code).

But as you pointed out, the arm code does the byte-at-a-time thing,
which *could* hide some other arm code using unaligned bitmaps.

Of course, if you actually have unaligned bitmaps (and one of the arm
chips that don't handle unaligned accesses), you'd then probably have
been bitten by just the *regular* bitmap functions doing word accesses
anyway, so I don't really see that as being an issue - I don't expect
anybody would only use the find_bit() functions, and not use the
regular set/clear/test_bit() functions before/after.

Anyway, the patch looks very safe and fixes a known - but likely
*very* minor - issue.

Just let me know how you want to handle this:

 (a) I'll take it directly on your say-so

 (b) you have other things pending anyway and will apply it and send
me a pull request

 (c) you are nervous enough that you prefer leaving this for the next
merge window

I don't personally really see (c) as an issue, but I don't feel
strongly enough about it to really mind one way or another, so
whatever you feel is simplest and works best for you...

                         Linus