linux-kernel - Re: [PATCH] HID: simplify code in fetch

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: <20250415152149.GB995325@ax162>
Date: Tue, 15 Apr 2025 08:21:49 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jiri Kosina <jikos@...nel.org>,
	Benjamin Tissoires <bentiss@...nel.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	llvm@...ts.linux.dev
Subject: Re: [PATCH] HID: simplify code in fetch_item()

On Tue, Apr 15, 2025 at 09:45:58AM +0300, Andy Shevchenko wrote:
> On Mon, Apr 14, 2025 at 05:33:26PM -0700, Nathan Chancellor wrote:
> > On Mon, Apr 14, 2025 at 09:30:36AM +0300, Andy Shevchenko wrote:
> > > On Thu, Oct 10, 2024 at 03:24:51PM -0700, Nathan Chancellor wrote:
> > > > On Tue, Oct 01, 2024 at 08:42:36AM -0700, Dmitry Torokhov wrote:
> 
> ...
> 
> > > > Getting rid of the unreachable() in some way resolves the issue. I
> > > > tested using BUG() in lieu of unreachable() like the second change I
> > > > mentioned above, which resolves the issue cleanly, as the default case
> > > > clearly cannot happen. ...
> > > 
> > > As Dmitry pointed out to this old discussion, I have a question about the above
> > > test. Have you tried to use BUG() while CONFIG_BUG=n? Does it _also_ solve the
> > > issue?
> > 
> > Yes because x86 appears to always emit ud2 for BUG() regardless of
> > whether CONFIG_BUG is set or not since HAVE_ARCH_BUG is always
> > respected.
> 
> Thank you for the reply. But do you know if this is guaranteed on the rest of
> supported architectures? I.o.w. may we assume that BUG() in lieu of unreachable()
> will always fix the issue?

I don't know. As far as I can tell, BUG() is always better than a bare
unreachable() because it is either the same as unreachable() if the
architecture does not define HAVE_ARCH_BUG and CONFIG_BUG=n (and in the
case of CONFIG_BUG=n, I think the user should get to pick up the pieces)
or when CONFIG_BUG=y and/or HAVE_ARCH_BUG is defined, the unreachable()
will truly be unreachable in the control flow graph because of the trap
or __noreturn from BUG(), so no undefined behavior. I think you would
only be able to find cases where BUG() was not sufficient to avoid
undefined behavior at runtime instead of compile time, as objtool only
supports loongarch and x86 right now and both ensure BUG() always traps.
I might be missing something though.

Cheers,
Nathan