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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ