linux-kernel - Re: Printing with overflow checks can cause modpost errors

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: <20250916104851.GA1679817@joelbox2>
Date: Tue, 16 Sep 2025 06:48:51 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: Andrew Ballance <andrewjballance@...il.com>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
	John Hubbard <jhubbard@...dia.com>,
	Alexandre Courbot <acourbot@...dia.com>,
	Timur Tabi <ttabi@...dia.com>, Alistair Popple <apopple@...dia.com>,
	Miguel Ojeda <ojeda@...nel.org>
Subject: Re: Printing with overflow checks can cause modpost errors

On Tue, Sep 16, 2025 at 06:32:52AM -0400, Joel Fernandes wrote:
> On Thu, Sep 11, 2025 at 11:08:17PM -0500, Andrew Ballance wrote:
> > On 9/11/25 9:53 PM, Joel Fernandes wrote:
> > > On Thu, Sep 11, 2025 at 07:27:26PM -0500, Andrew Ballance wrote:
> > > > On Thu, Sep 11, 2025 at 05:31:57PM -0400, Joel Fernandes wrote:
> > > > > Hello,
> > > > > Recently some of have been running into modpost errors more frequently. Ahead
> > > > > of Kangrejos, I am trying to study them, the one I looked at today is truly
> > > > > weird, below are more details.
> > > > > 
> > > > > I narrowed it down to the print statement and specifically the FFI call to
> > > > > printk bindings. This was first reported by Timur Tabi on CC.
> > > > > 
> > > > > With CONFIG_RUST_OVERFLOW_CHECKS=y and CONFIG_RUST_BUILD_ASSERT_ALLOW=y, the
> > > > > following patch when applied to nova-core will fail to build with following
> > > > > errors. The question is why does the overflow checking fail since the
> > > > > arithmetic is valid, and why only during printing (and say not during the
> > > > > call to write32).
> > > > > 
> > > > >    MODPOST Module.symvers
> > > > > ERROR: modpost: "rust_build_error" [drivers/gpu/nova-core/nova_core.ko] undefined!
> > > > > make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> > > > > make[1]: *** [/home/joelaf/repo/linux-nova-rm-call/Makefile:1961: modpost] Error 2
> > > > > make: *** [Makefile:248: __sub-make] Error 2
> > > > > 
> > > > > Any comments or thoughts?
> > > > > 
> > > > 
> > > > Io::write32 tries to do a bounds check at compile time and if it cannot
> > > > be done it causes a build error. it looks like because a pointer to
> > > > offset is passed across a ffi boundary, rustc makes no assumptions about
> > > > the value of offset. so it cannot do the bounds check at compile time
> > > > and causes a build error.
> > > 
> > > Are you saying this issue is related to iowrite32? I don't think so because
> > > the issue does not happen if you comment out the pr_err in my example and
> > > leave the write32 as it is. So it is something with the call to printk (FFI).
> > > 
> > > Why can't it assume the value of offset? All the values to compute it are
> > > available at compile time right?
> > > 
> > > thanks,
> > > 
> > >   - Joel
> > > 
> > 
> > This is a resend because I forgot to cc the mailing list.
> > 
> > it has to do with the FFI call. The value of offset can be found out at
> > compile time, but because a pointer is passed through, the c side could
> > theoretically change the value before write32 is called.
> > The pointer passed is const so rustc should assume that the c side does
> > not change offset, but looks like rustc does not do that.
> > 
> > as a test i created a version where a copy of offset is passed to printk
> > instead of offset and it compiles.
> > e.g:
> > // SNIP
> > let offset = <B as kernel::io::register::RegisterBase<$base>>::BASE
> >     + Self::OFFSET
> >     + (idx * Self::STRIDE);
> > let offset_copy = offset;
> > 
> > pr_err!("{}", offset_copy);
> > io.write32(self.0, offset);
> > // SNIP
> 
> Andrew,
> Thanks, I came to the same conclusion. After the first FFI call, the compiler
> has to redo the overflow checking and cannot optimize it away. The issue does
> not happen if either drop the print, or the io.write32, so it is their
> combination that causes the issue.
> 
> So I guess how do we fix it? One crude way could be for the print macro to
> alias its arguments automatically. But that does not fix the general problem
> as it could occur with other FFI calls as well, not just printing.

I even see it with the following simple example, just using same variable
between safe and unsafe code, here offset is not even going to the C side
(there's no print):

  let mut offset = 0;
  unsafe {
    offset = 5;
  }
  io.write32(self.0, offset);

So maybe the issue is that the FFI related to print involves unsafe { },
hence it causes the same issue there too?

thanks,

 - Joel