linux-kernel - Re: Rust kernel policy

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: <9a134f1b-a661-4372-9336-289d5734bcab@stanley.mountain>
Date: Mon, 24 Feb 2025 11:12:39 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Theodore Ts'o <tytso@....edu>
Cc: Martin Uecker <uecker@...raz.at>, Greg KH <gregkh@...uxfoundation.org>,
	Boqun Feng <boqun.feng@...il.com>, "H. Peter Anvin" <hpa@...or.com>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	rust-for-linux <rust-for-linux@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
	ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Fri, Feb 21, 2025 at 01:11:54PM -0500, Theodore Ts'o wrote:
> On Fri, Feb 21, 2025 at 12:48:11PM +0300, Dan Carpenter wrote:
> > On Thu, Feb 20, 2025 at 04:40:02PM +0100, Martin Uecker wrote:
> > > I mean "memory safe" in the sense that you can not have an OOB access
> > > or use-after-free or any other UB.  The idea would be to mark certain
> > > code regions as safe, e.g.
> > > 
> > > #pragma MEMORY_SAFETY STATIC
> > 
> > Could we tie this type of thing to a scope instead?  Maybe there
> > would be a compiler parameter to default on/off and then functions
> > and scopes could be on/off if we need more fine control.
> > 
> > This kind of #pragma is basically banned in the kernel.  It's used
> > in drivers/gpu/drm but it disables the Sparse static checker.
> 
> I'm not sure what you mean by "This kind of #pragma"?  There are quite
> a lot of pragma's in the kernel sources today; surely it's only a
> specific #pragma directive that disables sparse?
> 
> Not a global, general rule: if sparse sees a #pragma, it exits, stage left?
> 
> 					- Ted

Oh, yeah, you're right.  My bad.  Sparse ignores pragmas.

I was thinking of something else.  In the amdgpu driver, it uses
#pragma pack(), which Sparse ignores, then since structs aren't
packed the build time assert fails and that's actually what disables
Sparse.

  CHECK   drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c: note: in included file (through drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h, drivers/gpu/drm/amd/amdgpu/amdgpu.h):
drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:414:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"

regards,
dan carpenter