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

Message-ID: <Z_9SrP4kIGTCexF_@smile.fi.intel.com>
Date: Wed, 16 Apr 2025 09:48:12 +0300
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Nathan Chancellor <nathan@...nel.org>
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 08:21:49AM -0700, Nathan Chancellor wrote:
> 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.

Thank you for this information!

-- 
With Best Regards,
Andy Shevchenko