On Thu, 8 Feb 2024 at 00:33, Jakub Kicinski wrote:
>
> On Wed, 7 Feb 2024 20:04:44 +0100 Borislav Petkov wrote:
> > On Wed, Feb 07, 2024 at 07:35:53PM +0100, Matthieu Baerts wrote:
> > > Sorry, I'm sure I understand your suggestion: do you mean not including
> > > KFENCE in hardening.config either
On Wed, 7 Feb 2024 20:04:44 +0100 Borislav Petkov wrote:
> On Wed, Feb 07, 2024 at 07:35:53PM +0100, Matthieu Baerts wrote:
> > Sorry, I'm sure I understand your suggestion: do you mean not including
> > KFENCE in hardening.config either, but in another one?
> >
> > For the networking tests, we ar
On Wed, 7 Feb 2024 at 23:12, Matthieu Baerts wrote:
>
> On 07/02/2024 20:04, Borislav Petkov wrote:
> > On Wed, Feb 07, 2024 at 07:35:53PM +0100, Matthieu Baerts wrote:
> >> Sorry, I'm sure I understand your suggestion: do you mean not including
> >> KFENCE in hardening.config either, but in anoth
On 07/02/2024 20:04, Borislav Petkov wrote:
> On Wed, Feb 07, 2024 at 07:35:53PM +0100, Matthieu Baerts wrote:
>> Sorry, I'm sure I understand your suggestion: do you mean not including
>> KFENCE in hardening.config either, but in another one?
>>
>> For the networking tests, we are already merging
On Wed, Oct 04, 2023 at 09:32:54AM +0200, Ingo Molnar wrote:
...
> > Note: Ingo Molnar has some concerns about the comment being out of sync
> > [1] but I believe the comment still has a place as we can still
> > theoretically copy 64 bytes into our destination buffer without a
> > NUL-byte. The
On Wed, Feb 07, 2024 at 07:35:53PM +0100, Matthieu Baerts wrote:
> Sorry, I'm sure I understand your suggestion: do you mean not including
> KFENCE in hardening.config either, but in another one?
>
> For the networking tests, we are already merging .config files, e.g. the
> debug.config one. We ar
Hi Boris,
Thank you for your reply.
On 07/02/2024 19:16, Borislav Petkov wrote:
> On Wed, Feb 07, 2024 at 07:05:31PM +0100, Marco Elver wrote:
>> I think this would belong into some "hardening" config - while KFENCE
>> is not a mitigation (due to sampling) it has the performance
>> characteristic
Hi Marco,
Thank you for your reply!
On 07/02/2024 19:05, Marco Elver wrote:
> [Cc'ing a bunch more people to get input]
>
> Hi Matt,
>
> On Wed, 7 Feb 2024 at 17:16, Matthieu Baerts wrote:
> [...]
>> When talking to Jakub about the kernel config used by the new CI for the
>> net tree [1], Jaku
On Wed, Feb 07, 2024 at 07:05:31PM +0100, Marco Elver wrote:
> I think this would belong into some "hardening" config - while KFENCE
> is not a mitigation (due to sampling) it has the performance
> characteristics of unintrusive hardening techniques, so I think it
> would be a good fit. I think tha
On Wed, 7 Feb 2024 at 16:24, 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 t
[Cc'ing a bunch more people to get input]
Hi Matt,
On Wed, 7 Feb 2024 at 17:16, Matthieu Baerts wrote:
[...]
> When talking to Jakub about the kernel config used by the new CI for the
> net tree [1], Jakub suggested [2] to check if KFENCE could not be
> enabled by default for x86 architecture.
>
Hi!
> > 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 ton of patches replacing
> strncpy with strscpy [1]
On 2/7/24 04:30, Kees Cook wrote:
struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
as a flexible array, so convert it into one so that it doesn't trip
the array bounds sanitizer[1]. Only a few places were using sizeof()
on the whole struct, so adjust those to follow the
On Wed, Feb 07, 2024 at 08:08:14AM -0800, Kees Cook wrote:
> On Wed, Feb 07, 2024 at 05:31:54PM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 7, 2024 at 5:24 PM Kees Cook wrote:
> > >
> > > This allows replacements of the idioms "var += offset" and "var -= offset"
> > > with the wrapping_inc() and
On Wed, Feb 07, 2024 at 05:31:54PM +0200, Andy Shevchenko wrote:
> On Wed, Feb 7, 2024 at 5:24 PM Kees Cook wrote:
> >
> > This allows replacements of the idioms "var += offset" and "var -= offset"
> > with the wrapping_inc() and wrapping_dec() helpers respectively. They
> > will avoid wrap-around
On Wed, Feb 7, 2024 at 5:24 PM Kees Cook wrote:
>
> This allows replacements of the idioms "var += offset" and "var -= offset"
> with the wrapping_inc() and wrapping_dec() helpers respectively. They
> will avoid wrap-around sanitizer instrumentation.
>
> Add to the selftests to validate behavior a
This allows replacements of the idioms "var += offset" and "var -= offset"
with the wrapping_inc() and wrapping_dec() helpers respectively. They
will avoid wrap-around sanitizer instrumentation.
Add to the selftests to validate behavior and lack of side-effects.
Cc: Rasmus Villemoes
Cc: Marco El
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
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:
wrappi
v5: drop redundant checks (gustavo)
v4:
https://lore.kernel.org/linux-hardening/20240206102354.make.081-k...@kernel.org/
v3: https://lore.kernel.org/all/20240205090854.make.507-k...@kernel.org/
v2: https://lore.kernel.org/all/20240130220218.it.154-k...@kernel.org/
v1: https://lore.kernel.org/lkml/
On Wed, Feb 07, 2024 at 01:45:28AM +, Justin Stitt wrote:
> I wouldn't mind also seeing a test_ubsan_div_overflow test case here.
>
> It has some quirky behavior and it'd be nice to test that the sanitizers
> properly capture it.
>
> Check out this Godbolt: https://godbolt.org/z/qG5f1j6n1
>
On Tue, Feb 06, 2024 at 05:02:16PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 6, 2024 at 4:22 PM Kees Cook wrote:
> >
> > The ARCH=um build has its own idea about strscpy()'s definition. Adjust
> > the callers to remove the redundant sizeof() arguments ahead of treewide
> > changes, since it need
struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
as a flexible array, so convert it into one so that it doesn't trip
the array bounds sanitizer[1]. Only a few places were using sizeof()
on the whole struct, so adjust those to follow the calculation pattern
to avoid including
On Tue, Feb 06, 2024 at 02:32:32PM -0600, Gustavo A. R. Silva wrote:
>
>
> On 2/6/24 12:39, Kees Cook wrote:
> > struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
> > as a flexible array, so convert it into one so that it doesn't trip the
> > array bounds sanitizer[1]. Only
On Tue, Feb 06, 2024 at 10:54:06AM -0600, Gustavo A. R. Silva wrote:
>
>
> On 2/6/24 04:31, 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
On Wed, Feb 07, 2024 at 12:51:51AM +, Justin Stitt wrote:
> Hi,
>
> On Tue, Feb 06, 2024 at 06:22:18AM -0800, Kees Cook wrote:
> > Similar to strscpy(), update strscpy_pad()'s 3rd argument to be
> > optional when the destination is a compile-time known size array.
>
> This patch is diff'd aga
26 matches
Mail list logo
