linux-kernel - Re: [PATCH] driver core: faux: fix Undefined Behavior in faux_device

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: <206ebae8-4e2d-4e04-8872-fa3a56b3e398@linux.intel.com>
Date: Wed, 18 Jun 2025 20:33:27 -0700
From: Marc Herbert <marc.herbert@...ux.intel.com>
To: Dan Williams <dan.j.williams@...el.com>,
 Greg KH <gregkh@...uxfoundation.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Benjamin.Cheatham@....com,
 Jonathan.Cameron@...wei.com, dakr@...nel.org, linux-acpi@...r.kernel.org,
 linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org,
 rafael.j.wysocki@...el.com, rafael@...nel.org, sudeep.holla@....com,
 Dan Carpenter <dan.carpenter@...aro.org>, Kees Cook <kees@...nel.org>
Subject: Re: [PATCH] driver core: faux: fix Undefined Behavior in
 faux_device_destroy()

On 2025-06-18 17:23, Dan Williams wrote:
> Marc Herbert wrote:
> [..]
>> In other words, by turning this off unconditionally at the global level,
>> the kernel could actually lose (surprise!) some performance.
> 
> I expect the answer is that any compiler that does fail to convert this
> to defined behavior is not suitable for compiling the kernel.
> 
> The issue is not "oh hey, this fixup in this case is tiny", it is
> "changing this precedent implicates a large flag day audit". I am
> certain this is one of many optimizations that the kernel is willing to
> sacrifice.

None of these ideas crossed my mind:
- dropping -fno-delete-null-pointer-checks
- anything "large" like a "flag day audit" or any large cleanup/refactoring/etc.

Sorry for the confusion.

During the discussion, some seemed to perceive
-fno-delete-null-pointer-checks as a "performance-neutral" choice. So I
just tried to correct that impression "in passing", but please do _not_
read too much into it.

What I was really interested in:

1. Is it acceptable to swap two lines to _locally_ get rid of C Fear,
   Uncertainty and Doubt and time-consuming consultations with language
   lawyers. On a _case-by-case_ basis.

2. Are C99 declarations acceptable.

3. Do tooling and "convergence" with other C projects matter.

Note "acceptable" != mandatory; _allowing_ C99 declarations does NOT
imply scanning existing code and systematically reducing variable scope
everywhere possible. Same as every other "new" C feature.

I think these were valid "policy" questions, that this "poster child"
was an efficient way to ask all of them with a ridiculously small amount
of code and I think I got loud and clear answers. Case closed, moving on!

> Otherwise, the massive effort to remove undefined behavior from the
> kernel and allow for complier optimzations around that removal is called
> the "Rust for Linux" project.

Nice one!

On 2025-06-18 19:35, Dan Carpenter wrote:

> But, again, this is a totally different thing from what the patch does.
> The faux_device_destroy() code is not doing a dereference, it's doing
> pointer math.

pointer math is what we _want_ the code to do. But if that relies on
some undefined behavior(s) then the bets are off again. Check
https://stackoverflow.com/questions/26906621/does-struct-name-null-b-cause-undefined-behaviour-in-c11
where offsetof() is a suggested alternative.
Spoiler alert: more language lawyers. Do not click ;-)