mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Kees Cook' <keescook@chromium.org>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	"'Andy Shevchenko'" <andriy.shevchenko@linux.intel.com>,
	'Andrew Morton' <akpm@linux-foundation.org>,
	"'Matthew Wilcox (Oracle)'" <willy@infradead.org>,
	'Christoph Hellwig' <hch@infradead.org>,
	"'Jason A. Donenfeld'" <Jason@zx2c4.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: RE: [PATCH next v3 0/5] minmax: Relax type checks in min() and max().
Date: Wed, 23 Aug 2023 08:52:23 +0000	[thread overview]
Message-ID: <acf8a7389d1f47a5ac55390b7ea76692@AcuMS.aculab.com> (raw)
In-Reply-To: <202308211113.4F49E73109@keescook>

From: Kees Cook <keescook@chromium.org>
> Sent: Monday, August 21, 2023 7:24 PM
....
> > > It seems like the existing type_max/type_min macros could be used to
> > > figure out that the args are safe to appropriately automatically cast,
> > > etc. e.g. type_max(u16) <= type_max(unsigned int) && type_min(u16) >=
> > > type_min(unsigned int) ...
> >
> > That doesn't really help; min(a,b) is ok if any of:
> > 1) is_signed(a) == is_signed(b).
> > 2) is_signed(a + 0) == is_signed(b + 0)  // Converts char/short to int.
> > 3) a or b is a constant between 0 and MAXINT and is cast to int.
> >
> > The one you found passes (1) - both types are unsigned.
> > min(len, sizeof (int)) passes (3) and is converted to
> > min(len, (int)sizeof (int)) and can still return the expected negatives.
> 
> It seems like the foot-gun problems are when a value gets clamped by the
> imposed type. Can't we just warn about those cases?

Also when -1 gets converted to 0xffffffff.

...
> But this is also unsafe:
> 
> 	unsigned int a = ...;
>         u16 b = ...;
> 	unsigned int c = min_t(u16, a, b);
> 
> Both are unsigned, but "a > U16_MAX" still goes sideways.

Right, this is one reason why min_t() is broken.
If min() allowed that - no reason why it shouldn't - then it wouldn't
get written in the first place.

> I worry that weakening the min/max() type checking gets into silent errors:
> 
> 	unsigned int a = ...;
>         u16 b = ...;
> 	u16 c = max(a, b);
> 
> when "a > U16_MAX".

Nothing can be done on the RHS to detect invalid narrowing in assignments.
And you don't want the compiler to complain because that will just cause
explicit casts be added making the code harder to read and (probably)
adding more bugs.

> Looking at warning about clamped types on min_t(), though I see tons of
> int vs unsigned int issue. (e.g. dealing with PAGE_SIZE vs an int).

Linus doesn't like me silently converting unsigned constants
to signed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  parent reply	other threads:[~2023-08-23  9:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04 10:50 David Laight
2023-08-04 10:53 ` [PATCH v3 1/5] minmax: Add min_unsigned(a, b) and max_unsigned(a, b) David Laight
2023-08-04 10:54 ` [PATCH v3 2/5] minmax: Allow min()/max()/clamp() if the arguments have the same signedness David Laight
2023-08-04 10:55 ` [PATCH v3 3/5] minmax: Fix indentation of __cmp_once() and __clamp_once() David Laight
2023-08-04 10:55 ` [PATCH v3 4/5] minmax: Allow comparisons of 'int' against 'unsigned char/short' David Laight
2023-08-04 10:56 ` [PATCH v3 5/5] minmax: Relax check to allow comparison between int and small unsigned constants David Laight
2023-08-04 18:14   ` Linus Torvalds
2023-08-07 10:50     ` David Laight
2023-08-07 15:48       ` Linus Torvalds
2023-08-10  8:29         ` David Laight
2023-08-10 19:46           ` Linus Torvalds
2023-08-14  8:04             ` David Laight
2023-08-14 14:51             ` David Laight
2023-08-14 15:29               ` David Laight
2023-08-14 21:21 ` [PATCH next v3 0/5] minmax: Relax type checks in min() and max() Kees Cook
2023-08-15  8:55   ` David Laight
2023-08-21 18:24     ` Kees Cook
2023-08-22 17:35       ` Linus Torvalds
2023-08-23  8:42         ` David Laight
2023-08-23  8:52       ` David Laight [this message]
2023-08-23 15:32         ` Linus Torvalds
2023-08-24  9:05           ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acf8a7389d1f47a5ac55390b7ea76692@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=Jason@zx2c4.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hch@infradead.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®