On Tue, 12 Dec 2023 01:20:20 +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We don't need the NUL-padding behavior that strncpy() provides as vscsi
> is N
On Tue, Jan 30, 2024 at 1:27 AM Andy Shevchenko
wrote:
> On Tue, Jan 30, 2024 at 12:03 AM Kees Cook wrote:
> > On Mon, Jan 29, 2024 at 09:55:25PM +, Justin Stitt wrote:
> > > On Mon, Jan 29, 2024 at 12:29:04PM -0800, Kees Cook wrote:
...
> > > BTW, this hack for function overloading is insa
On Tue, Jan 30, 2024 at 12:03 AM Kees Cook wrote:
> On Mon, Jan 29, 2024 at 09:55:25PM +, Justin Stitt wrote:
> > On Mon, Jan 29, 2024 at 12:29:04PM -0800, Kees Cook wrote:
...
> > BTW, this hack for function overloading is insane. Never really looked into
> > it before.
>
> It very much is.
On Mon, Jan 29, 2024 at 09:55:25PM +, Justin Stitt wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 12:29:04PM -0800, Kees Cook wrote:
> > Using sizeof(dst) is the overwhelmingly common case for strscpy().
> > Instead of requiring this everywhere, allow a 2-argument version to be
> > used that will us
On Mon, Jan 29, 2024 at 09:16:36PM +0100, Rasmus Villemoes wrote:
> On 29/01/2024 19.34, Kees Cook wrote:
> > This allows replacements of the idioms "var += offset" and "var -= offset"
> > with the inc_wrap() and dec_wrap() helpers respectively. They will avoid
> > wrap-around sanitizer instrumenta
Hi,
On Mon, Jan 29, 2024 at 12:29:04PM -0800, Kees Cook wrote:
> Using sizeof(dst) is the overwhelmingly common case for strscpy().
> Instead of requiring this everywhere, allow a 2-argument version to be
> used that will use the sizeof() internally.
Yeah, this is definitely the case. I have a to
Using sizeof(dst) is the overwhelmingly common case for strscpy().
Instead of requiring this everywhere, allow a 2-argument version to be
used that will use the sizeof() internally.
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Kees Cook
---
What do
On Mon, Jan 29, 2024 at 09:08:43PM +0100, Rasmus Villemoes wrote:
> On 29/01/2024 19.34, Kees Cook wrote:
> > Provide helpers that will perform wrapping addition, subtraction, or
> > multiplication without tripping the arithmetic wrap-around sanitizers. The
> > first argument is the type under whic
On Mon, Jan 29, 2024 at 07:54:18PM +, Justin Stitt wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 10:00:39AM -0800, Kees Cook wrote:
> > Effectively revert commit 6aaa31aeb9cf ("ubsan: remove overflow
> > checks"), to allow the kernel to be built with the "overflow"
> > sanitizers again. This gives
On 29/01/2024 19.34, Kees Cook wrote:
> This allows replacements of the idioms "var += offset" and "var -= offset"
> with the inc_wrap() and dec_wrap() helpers respectively. They will avoid
> wrap-around sanitizer instrumentation.
>
> Cc: Rasmus Villemoes
> Cc: Mark Rutland
> Cc: "Gustavo A. R.
On 29/01/2024 19.34, Kees Cook wrote:
> Provide helpers that will perform wrapping addition, subtraction, or
> multiplication without tripping the arithmetic wrap-around sanitizers. The
> first argument is the type under which the wrap-around should happen
> with. In other words, these two calls wi
Hi,
On Mon, Jan 29, 2024 at 10:00:39AM -0800, Kees Cook wrote:
> Effectively revert commit 6aaa31aeb9cf ("ubsan: remove overflow
> checks"), to allow the kernel to be built with the "overflow"
> sanitizers again. This gives developers a chance to experiment[1][2][3]
> with the instrumentation agai
On Mon, Jan 29, 2024 at 08:08:28PM +0100, Geert Uytterhoeven wrote:
> Hi Kees,
>
> On Mon, Jan 29, 2024 at 6:38 PM Kees Cook wrote>
> > On Mon, Jan 29, 2024 at 10:57:40AM +0100, Geert Uytterhoeven wrote:
> > > CC Kees (for the wrap-around in dma_cookie_assign() not handled in [A])
> > > [...]
> >
Hi Kees,
On Mon, Jan 29, 2024 at 6:38 PM Kees Cook wrote>
> On Mon, Jan 29, 2024 at 10:57:40AM +0100, Geert Uytterhoeven wrote:
> > CC Kees (for the wrap-around in dma_cookie_assign() not handled in [A])
> > [...]
> > Was the system running for a very long time?
> > dma_cookie_assign() relies on
On Mon, Jan 29, 2024 at 10:00 AM Kees Cook wrote:
>
> Clang changed the way it enables UBSan trapping mode. Update the Makefile
> logic to discover it.
>
> Suggested-by: Fangrui Song
> Link:
> https://lore.kernel.org/lkml/cafp8o3jivzh+aav7n90nk7u2bhrnst6mrp0zhtfq-vj0m4+...@mail.gmail.com/
> Cc:
The mix of int, unsigned int, and unsigned long used by struct
poll_list::len, todo, len, and j meant that the signed overflow
sanitizer got worried it needed to instrument several places where
arithmetic happens between these variables. Since all of the variables
are always positive and bounded by
The loop counter "i" in copy_compat_iovec_from_user() is an int, but
because the nr_segs argument is unsigned long, the signed overflow
sanitizer got worried "i" could wrap around. Instead of making "i" an
unsigned long (which may enlarge the type size), switch both nr_segs
and i to u32. There is n
This allows replacements of the idioms "var += offset" and "var -= offset"
with the inc_wrap() and dec_wrap() helpers respectively. They will avoid
wrap-around sanitizer instrumentation.
Cc: Rasmus Villemoes
Cc: Mark Rutland
Cc: "Gustavo A. R. Silva"
Cc: linux-hardening@vger.kernel.org
Signed-o
Provide helpers that will perform wrapping addition, subtraction, or
multiplication without tripping the arithmetic wrap-around sanitizers. The
first argument is the type under which the wrap-around should happen
with. In other words, these two calls will get very different results:
add_wr
Hi,
In preparation for gaining instrumentation for signed[1], unsigned[2], and
pointer[3] wrap-around, expand the overflow header to include wrap-around
helpers that can be used to annotate arithmetic where wrapped calculations
are expected (e.g. atomics).
After spending time getting the unsigned
The check_add_overflow() helper is mostly a wrapper around
__builtin_add_overflow(), but GCC and Clang refuse to operate on pointer
arguments that would normally be allowed if the addition were open-coded.
For example, we have many places where pointer overflow is tested:
struct foo *ptr;
The check_*_overflow() helpers will return results with potentially
wrapped-around values. These values have always been checked by the
selftests, so avoid the confusing language in the kern-doc. The idea of
"safe for use" was relative to the expectation of whether or not the
caller wants a wrapped
For instances where only the overflow needs to be checked (and the sum
isn't used), provide the new helper add_would_overflow(), which is
a wrapper for check_add_overflow().
Cc: Rasmus Villemoes
Cc: "Gustavo A. R. Silva"
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Kees Cook
---
include/
To allow for fine-grained control of where the wrapping sanitizers can
be disabled, split them from the main UBSAN CFLAGS into their own set of
rules.
Cc: Masahiro Yamada
Cc: Nathan Chancellor
Cc: Nicolas Schier
Cc: linux-kbu...@vger.kernel.org
Signed-off-by: Kees Cook
---
scripts/Makefile.li
In order to get x86_64 booting with the unsigned wrap-around sanitizer,
several kernel areas that depend heavily on unsigned wrap-around need to
be disabled entirely (with "UBSAN_UNSIGNED_WRAP := n"). As we fine-tune
the sanitizer, we can revisit these and perform finer grain annotations.
Signed-o
Gain coverage for pointer wrap-around checking. Adds support for
-fsanitize=pointer-overflow, and introduces the __pointer_wrap function
attribute to match the signed and unsigned attributes. Also like the
others, it is currently disabled under CONFIG_COMPILE_TEST.
Cc: Andrew Morton
Cc: Masahiro
Effectively revert commit 6aaa31aeb9cf ("ubsan: remove overflow
checks"), to allow the kernel to be built with the "overflow"
sanitizers again. This gives developers a chance to experiment[1][2][3]
with the instrumentation again, while compilers adjust their sanitizers
to deal with the impact of -f
Hi,
Lay the ground work for gaining instrumentation for signed[1],
unsigned[2], and pointer[3] wrap-around by making all 3 sanitizers
available for testing. Additionally gets x86_64 bootable under the
unsigned sanitizer for the first time.
The compilers will need work before this can be generally
Clang changed the way it enables UBSan trapping mode. Update the Makefile
logic to discover it.
Suggested-by: Fangrui Song
Link:
https://lore.kernel.org/lkml/cafp8o3jivzh+aav7n90nk7u2bhrnst6mrp0zhtfq-vj0m4+...@mail.gmail.com/
Cc: Nathan Chancellor
Cc: Masahiro Yamada
Cc: Nicolas Schier
Cc: Ni
On Mon, Jan 29, 2024 at 10:57:40AM +0100, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> CC Kees (for the wrap-around in dma_cookie_assign() not handled in [A])
> [...]
> Was the system running for a very long time?
> dma_cookie_assign() relies on 2-complement signed wrap-around:
>
> cookie = c
On Mon, 29 Jan 2024, David Laight wrote:
> ...
> > > I'm sure that the safest return for 'truncated' is the buffer length.
> > > The a series of statements like:
> > > buf += xxx(buf, buf_end - buf, .);
> > > can all be called with a single overflow check at the end.
> > >
> > > Forget the c
...
> > I'm sure that the safest return for 'truncated' is the buffer length.
> > The a series of statements like:
> > buf += xxx(buf, buf_end - buf, .);
> > can all be called with a single overflow check at the end.
> >
> > Forget the check, and the length just contains a trailing '\0'
> >
Please discard - missing version identifier in the subject line.
New version here:
https://lore.kernel.org/r/20240129092952.1980246-1-...@kernel.org
--
Lee Jones [李琼斯]
There is an ongoing effort to replace the use of {v}snprintf() variants
with safer alternatives - for a more in depth view, see Jon's write-up
on LWN [0] and/or Alex's on the Kernel Self Protection Project [1].
Whist executing the task, it quickly became apparent that the initial
thought of simply
There is an ongoing effort to replace the use of {v}snprintf() variants
with safer alternatives - for a more in depth view, see Jon's write-up
on LWN [0] and/or Alex's on the Kernel Self Protection Project [1].
Whist executing the task, it quickly became apparent that the initial
thought of simply
NB: I was _just_ about to send out v2 with Rasmus's suggestions before I
saw your reply. I'm going to submit it anyway and Cc both you and
Rasmus. If you still disagree with my suggested approach, we can either
continue discussion here or on the new version.
More below:
> From: Lee Jones
> > Se
36 matches
Mail list logo
