All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
	Andi Shyti <andi.shyti@linux.intel.com>,
	thomas.hellstrom@linux.intel.com, jani.nikula@intel.com,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	airlied@linux.ie, linux-hardening@vger.kernel.org,
	matthew.auld@intel.com, mchehab@kernel.org, nirmoy.das@intel.com,
	Mauro Carvalho Chehab <mauro.chehab@linux.intel.com>
Subject: Re: [PATCH v7 1/8] overflow: Move and add few utility macros into overflow
Date: Mon, 22 Aug 2022 13:12:30 -0700	[thread overview]
Message-ID: <202208221301.366A33DACA@keescook> (raw)
In-Reply-To: <52c09fde-f788-4c2b-efdc-d1783dbc0f6c@intel.com>

On Tue, Aug 23, 2022 at 04:32:10AM +0900, Gwan-gyeong Mun wrote:
> On 8/22/22 11:05 PM, Andrzej Hajda wrote:
> > On 18.08.2022 02:12, Kees Cook wrote:
> > > On Thu, Aug 18, 2022 at 01:07:29AM +0200, Andi Shyti wrote:
> > > > [...]
> > > > > +#define safe_conversion(ptr, value) ({ \
> > > > > +    typeof(value) __v = (value); \
> > > > > +    typeof(ptr) __ptr = (ptr); \
> > > > > +    overflows_type(__v, *__ptr) ? 0 : ((*__ptr =
> > > > > (typeof(*__ptr))__v), 1); \
> > > > > +})
> > > 
> > > I try to avoid "safe" as an adjective for interface names, since it
> > > doesn't really answer "safe from what?" This looks more like "assign, but
> > > zero when out of bounds". And it can be built from existing macros here:
> > > 
> > >     if (check_add_overflow(0, value, ptr))
> > >         *ptr = 0;
> > > 
> > > I actually want to push back on this a bit, because there can still be
> > > logic bugs built around this kind of primitive. Shouldn't out-of-bounds
> > > assignments be seen as a direct failure? I would think this would be
> > > sufficient:
> > > 
> > > #define check_assign(value, ptr)    check_add_overflow(0, value, ptr)
> > > 
> > > And callers would do:
> > > 
> > >     if (check_assign(value, &var))
> > >         return -EINVAL;
> > > 
> Yes, I also like check_assign() you suggested more than safe_conversion.
> As shown below, it would be more readable to return true when assign
> succeeds and false when it fails. What do you think?

No, this inverts the style of all the other check_*() functions, so it
should remain "non-zero is failure".

> /**
>  * check_assign - perform a type conversion (cast) of an source value into
>  * a new variable, checking that the destination is large enough to hold the
>  * source value.
>  *
>  * @value: Source value
>  * @ptr: Destination pointer address, If the pointer type is not used, a
> warning message is output during build.
>  *
>  * Returns:
>  * If the value would overflow the destination, it returns false. If not
> return true.
>  */
> #define check_assign(value, ptr) __must_check_overflow(({	\
> 	typecheck_pointer(ptr); 		\
> 	!__builtin_add_overflow(0, value, ptr);	\
> }))

Please don't use the __builtin*s, instead stick to the check_* family,
as they correctly wrap the builtins and perform type checking, etc. As
mentioned, check_assign() should just be:

#define check_assign(value, ptr)    check_add_overflow(0, value, ptr)

I don't think any of the other code is needed? What's the use-case for
the other stuff? i.e. Why does anything need overflows_type()?

-Kees

-- 
Kees Cook

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: thomas.hellstrom@linux.intel.com,
	Mauro Carvalho Chehab <mauro.chehab@linux.intel.com>,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	jani.nikula@intel.com, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	chris@chris-wilson.co.uk, airlied@linux.ie, nirmoy.das@intel.com,
	linux-hardening@vger.kernel.org,
	Andi Shyti <andi.shyti@linux.intel.com>,
	mchehab@kernel.org, matthew.auld@intel.com
Subject: Re: [PATCH v7 1/8] overflow: Move and add few utility macros into overflow
Date: Mon, 22 Aug 2022 13:12:30 -0700	[thread overview]
Message-ID: <202208221301.366A33DACA@keescook> (raw)
In-Reply-To: <52c09fde-f788-4c2b-efdc-d1783dbc0f6c@intel.com>

On Tue, Aug 23, 2022 at 04:32:10AM +0900, Gwan-gyeong Mun wrote:
> On 8/22/22 11:05 PM, Andrzej Hajda wrote:
> > On 18.08.2022 02:12, Kees Cook wrote:
> > > On Thu, Aug 18, 2022 at 01:07:29AM +0200, Andi Shyti wrote:
> > > > [...]
> > > > > +#define safe_conversion(ptr, value) ({ \
> > > > > +    typeof(value) __v = (value); \
> > > > > +    typeof(ptr) __ptr = (ptr); \
> > > > > +    overflows_type(__v, *__ptr) ? 0 : ((*__ptr =
> > > > > (typeof(*__ptr))__v), 1); \
> > > > > +})
> > > 
> > > I try to avoid "safe" as an adjective for interface names, since it
> > > doesn't really answer "safe from what?" This looks more like "assign, but
> > > zero when out of bounds". And it can be built from existing macros here:
> > > 
> > >     if (check_add_overflow(0, value, ptr))
> > >         *ptr = 0;
> > > 
> > > I actually want to push back on this a bit, because there can still be
> > > logic bugs built around this kind of primitive. Shouldn't out-of-bounds
> > > assignments be seen as a direct failure? I would think this would be
> > > sufficient:
> > > 
> > > #define check_assign(value, ptr)    check_add_overflow(0, value, ptr)
> > > 
> > > And callers would do:
> > > 
> > >     if (check_assign(value, &var))
> > >         return -EINVAL;
> > > 
> Yes, I also like check_assign() you suggested more than safe_conversion.
> As shown below, it would be more readable to return true when assign
> succeeds and false when it fails. What do you think?

No, this inverts the style of all the other check_*() functions, so it
should remain "non-zero is failure".

> /**
>  * check_assign - perform a type conversion (cast) of an source value into
>  * a new variable, checking that the destination is large enough to hold the
>  * source value.
>  *
>  * @value: Source value
>  * @ptr: Destination pointer address, If the pointer type is not used, a
> warning message is output during build.
>  *
>  * Returns:
>  * If the value would overflow the destination, it returns false. If not
> return true.
>  */
> #define check_assign(value, ptr) __must_check_overflow(({	\
> 	typecheck_pointer(ptr); 		\
> 	!__builtin_add_overflow(0, value, ptr);	\
> }))

Please don't use the __builtin*s, instead stick to the check_* family,
as they correctly wrap the builtins and perform type checking, etc. As
mentioned, check_assign() should just be:

#define check_assign(value, ptr)    check_add_overflow(0, value, ptr)

I don't think any of the other code is needed? What's the use-case for
the other stuff? i.e. Why does anything need overflows_type()?

-Kees

-- 
Kees Cook

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: thomas.hellstrom@linux.intel.com,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	jani.nikula@intel.com, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	chris@chris-wilson.co.uk, airlied@linux.ie, nirmoy.das@intel.com,
	linux-hardening@vger.kernel.org, mchehab@kernel.org,
	matthew.auld@intel.com
Subject: Re: [Intel-gfx] [PATCH v7 1/8] overflow: Move and add few utility macros into overflow
Date: Mon, 22 Aug 2022 13:12:30 -0700	[thread overview]
Message-ID: <202208221301.366A33DACA@keescook> (raw)
In-Reply-To: <52c09fde-f788-4c2b-efdc-d1783dbc0f6c@intel.com>

On Tue, Aug 23, 2022 at 04:32:10AM +0900, Gwan-gyeong Mun wrote:
> On 8/22/22 11:05 PM, Andrzej Hajda wrote:
> > On 18.08.2022 02:12, Kees Cook wrote:
> > > On Thu, Aug 18, 2022 at 01:07:29AM +0200, Andi Shyti wrote:
> > > > [...]
> > > > > +#define safe_conversion(ptr, value) ({ \
> > > > > +    typeof(value) __v = (value); \
> > > > > +    typeof(ptr) __ptr = (ptr); \
> > > > > +    overflows_type(__v, *__ptr) ? 0 : ((*__ptr =
> > > > > (typeof(*__ptr))__v), 1); \
> > > > > +})
> > > 
> > > I try to avoid "safe" as an adjective for interface names, since it
> > > doesn't really answer "safe from what?" This looks more like "assign, but
> > > zero when out of bounds". And it can be built from existing macros here:
> > > 
> > >     if (check_add_overflow(0, value, ptr))
> > >         *ptr = 0;
> > > 
> > > I actually want to push back on this a bit, because there can still be
> > > logic bugs built around this kind of primitive. Shouldn't out-of-bounds
> > > assignments be seen as a direct failure? I would think this would be
> > > sufficient:
> > > 
> > > #define check_assign(value, ptr)    check_add_overflow(0, value, ptr)
> > > 
> > > And callers would do:
> > > 
> > >     if (check_assign(value, &var))
> > >         return -EINVAL;
> > > 
> Yes, I also like check_assign() you suggested more than safe_conversion.
> As shown below, it would be more readable to return true when assign
> succeeds and false when it fails. What do you think?

No, this inverts the style of all the other check_*() functions, so it
should remain "non-zero is failure".

> /**
>  * check_assign - perform a type conversion (cast) of an source value into
>  * a new variable, checking that the destination is large enough to hold the
>  * source value.
>  *
>  * @value: Source value
>  * @ptr: Destination pointer address, If the pointer type is not used, a
> warning message is output during build.
>  *
>  * Returns:
>  * If the value would overflow the destination, it returns false. If not
> return true.
>  */
> #define check_assign(value, ptr) __must_check_overflow(({	\
> 	typecheck_pointer(ptr); 		\
> 	!__builtin_add_overflow(0, value, ptr);	\
> }))

Please don't use the __builtin*s, instead stick to the check_* family,
as they correctly wrap the builtins and perform type checking, etc. As
mentioned, check_assign() should just be:

#define check_assign(value, ptr)    check_add_overflow(0, value, ptr)

I don't think any of the other code is needed? What's the use-case for
the other stuff? i.e. Why does anything need overflows_type()?

-Kees

-- 
Kees Cook

  reply	other threads:[~2022-08-22 20:12 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16  9:35 [PATCH v7 0/8] Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation Gwan-gyeong Mun
2022-08-16  9:35 ` Gwan-gyeong Mun
2022-08-16  9:35 ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-16  9:35 ` [PATCH v7 1/8] overflow: Move and add few utility macros into overflow Gwan-gyeong Mun
2022-08-16  9:35   ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-16  9:35   ` Gwan-gyeong Mun
2022-08-17 23:07   ` Andi Shyti
2022-08-17 23:07     ` [Intel-gfx] " Andi Shyti
2022-08-17 23:07     ` Andi Shyti
2022-08-18  0:12     ` Kees Cook
2022-08-18  0:12       ` [Intel-gfx] " Kees Cook
2022-08-18  0:12       ` Kees Cook
2022-08-22 11:02       ` Jani Nikula
2022-08-22 11:02         ` [Intel-gfx] " Jani Nikula
2022-08-22 11:02         ` Jani Nikula
2022-08-22 14:05       ` Andrzej Hajda
2022-08-22 14:05         ` [Intel-gfx] " Andrzej Hajda
2022-08-22 14:05         ` Andrzej Hajda
2022-08-22 14:26         ` [Intel-gfx] " Andrzej Hajda
2022-08-22 14:26           ` Andrzej Hajda
2022-08-22 19:32         ` Gwan-gyeong Mun
2022-08-22 19:32           ` Gwan-gyeong Mun
2022-08-22 19:32           ` Gwan-gyeong Mun
2022-08-22 20:12           ` Kees Cook [this message]
2022-08-22 20:12             ` [Intel-gfx] " Kees Cook
2022-08-22 20:12             ` Kees Cook
2022-08-23  2:30             ` Gwan-gyeong Mun
2022-08-23  2:30               ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-23  2:30               ` Gwan-gyeong Mun
2022-08-16  9:35 ` [PATCH v7 2/8] util_macros: Add exact_type macro to catch type mis-match while compiling Gwan-gyeong Mun
2022-08-16  9:35   ` Gwan-gyeong Mun
2022-08-16  9:35   ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-16  9:35 ` [PATCH v7 3/8] drm/i915/gem: Typecheck page lookups Gwan-gyeong Mun
2022-08-16  9:35   ` Gwan-gyeong Mun
2022-08-16  9:35   ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-16  9:35 ` [PATCH v7 4/8] drm/i915: Check for integer truncation on scatterlist creation Gwan-gyeong Mun
2022-08-16  9:35   ` Gwan-gyeong Mun
2022-08-16  9:35   ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-16  9:35 ` [PATCH v7 5/8] drm/i915: Check for integer truncation on the configuration of ttm place Gwan-gyeong Mun
2022-08-16  9:35   ` Gwan-gyeong Mun
2022-08-16  9:35   ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-16  9:35 ` [PATCH v7 6/8] drm/i915: Check if the size is too big while creating shmem file Gwan-gyeong Mun
2022-08-16  9:35   ` Gwan-gyeong Mun
2022-08-16  9:35   ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-16  9:35 ` [PATCH v7 7/8] drm/i915: Use error code as -E2BIG when the size of gem ttm object is too large Gwan-gyeong Mun
2022-08-16  9:35   ` Gwan-gyeong Mun
2022-08-16  9:35   ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-16  9:35 ` [PATCH v7 8/8] drm/i915: Remove truncation warning for large objects Gwan-gyeong Mun
2022-08-16  9:35   ` Gwan-gyeong Mun
2022-08-16  9:35   ` [Intel-gfx] " Gwan-gyeong Mun
2022-08-24 19:00 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation Patchwork
2022-08-24 19:00 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-08-24 19:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-08-26 14:25 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=202208221301.366A33DACA@keescook \
    --to=keescook@chromium.org \
    --cc=airlied@linux.ie \
    --cc=andi.shyti@linux.intel.com \
    --cc=andrzej.hajda@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gwan-gyeong.mun@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.auld@intel.com \
    --cc=mauro.chehab@linux.intel.com \
    --cc=mchehab@kernel.org \
    --cc=nirmoy.das@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.