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: <962fa158-5315-4d93-afb1-8a1c08787ad8@stanley.mountain>
Date: Thu, 20 Feb 2025 16:46:43 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Martin Uecker <uecker@...raz.at>
Cc: 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, Justin Stitt <justinstitt@...gle.com>,
	Kees Cook <keescook@...omium.org>
Subject: Re: Rust kernel policy

On Thu, Feb 20, 2025 at 09:57:29AM +0100, Martin Uecker wrote:
> In particulary, I have a relatively concrete plan to have a memory safe
> mode for C that can be toggled for some region of code and would make
> sure there is no UB or memory safety issues left (I am experimenting with
> this in the GCC FE).  So the idea is that one could start to activate this
> for certain critical regions of code to make sure there is no signed
> integer overflow or OOB access in it.

I don't think diferentiating between signed and unsigned integer
overflows is useful.  In the kernel, most security issues from integer
overflows are from unsigned integer overflows.  Kees says that we
should warn about "Unexpected" behavior instead of "Undefined".  In fact,
Justin Stitt has done the opposite of what you're doing and only checks
for unsigned overflows.  He created a sanitizer that warns about integer
overflows involving size_t type (which is unsigned), because sizes are
so important.  (Checking only size_t avoids probably the largest source
of harmless integer overflows which is dealing with time).

The sanitizer has a list of exceptions like if (a < a + b) where the
integer overflow is idiomatic.  But the concern was that there might be
other deliberate integer overflows which aren't in the exception list so
Justin also created a macro to turn off the santizer.

	x = wrapping_ok(a + b);

What I would like is a similar macro so we could write code like:

	x = saturate_math(a + b + c + d * d_size);

If anything overflowed the result would be ULONG_MAX.  In the kernel,
we have the size_add() and size_mul() macros which do saturation math
instead of wrapping math but we'd have to say:

	x = size_add(a, size_add(b, size_add(c, size_add(size_mul(d, d_size)))));

Which is super ugly.  Maybe we could create something like this macro?

#define saturate_math(x) ({             \
        unsigned long res;              \
        __trap_overflow(label_name));   \
        res = (x);                      \
        if (0) {                        \
lable_name:                             \
                res = ULONG_MAX;        \
        }                               \
        res;                            \
})

regards,
dan carpenter