On Tue, 07 May 2024 19:33:18 +0200, Erick Archer wrote:
> This commit can be considered an addition to commit ca7e324e8ad3
> ("compiler_types: add Endianness-dependent __counted_by_{le,be}") [1].
>
> In the commit referenced above the __counted_by_{le,be}() attributes
> were defined based on platf
On Tue, May 07, 2024 at 03:28:46PM -0700, Jakub Kicinski wrote:
> On Fri, 03 May 2024 21:31:25 +0100 Simon Horman wrote:
> > This short patchset provides two minor cleanups for the gve driver.
> >
> > These were found by tooling as mentioned in each patch,
> > and otherwise by inspection.
> >
> >
Hi,
This short patchset provides two minor cleanups for the gve driver.
These were found by tooling as mentioned in each patch,
and otherwise by inspection.
No change in run time behaviour is intended.
Each patch is compile tested only.
---
Changes in v2:
- Collected Reviewed-by tags, thanks!
-
Although it does not seem to have any untoward side-effects,
the use of ';' to separate to assignments seems more appropriate than ','.
Flagged by clang-18 -Wcomma
No functional change intended.
Compile tested only.
Reviewed-by: Shailend Chand
Reviewed-by: Larysa Zaremba
Signed-off-by: Simon H
Make use of standard helpers to simplify filling in stats strings.
The first two ethtool_puts() changes address the following fortification
warnings flagged by W=1 builds with clang-18. (The last ethtool_puts
change does not because the warning relates to writing beyond the first
element of an arr
From: Eric Dumazet
Date: Tue, 7 May 2024 20:21:58 +0200
> On Tue, May 7, 2024 at 2:40 PM Alexander Lobakin
> wrote:
>>
>> In fact, this structure contains a flexible array at the end, but
>> historically its size, alignment etc., is calculated manually.
>> There are several instances of the stru
From: Jakub Kicinski
Date: Tue, 7 May 2024 11:10:35 -0700
> On Tue, 7 May 2024 14:39:37 +0200 Alexander Lobakin wrote:
>> There are several instances of the structure embedded into other
>> structures, but also there's ongoing effort to remove them and we
>> could in the meantime declare &net_de
From: Kees Cook
> Sent: 08 May 2024 00:28
>
> Over the last decade or so, our work hardening against weaknesses
> in various kernel APIs and eliminating the ambiguities in C language
> semantics have traditionally been somewhat off in one corner or another
> of the Linux codebase. This topic is go
The read_actions_logged() and write_actions_logged() helpers called by the
sysctl proc handler seccomp_actions_logged_handler() are already expecting
their sysctl table argument to be read-only. Actually mark the argument
as const in preparation[1] for global constification of the sysctl tables.
S
: Justin Stitt
---
Changes in v2:
- change @speed type from int to unsigned long and use a clamp (thanks Kees)
- also update documentation to avoid confusion
- Link to v1:
https://lore.kernel.org/r/20240508-b4-b4-sio-sr_select_speed-v1-1-968906b90...@google.com
---
Here's the syzkaller repro
Hi,
On Wed, May 08, 2024 at 09:32:20AM +0100, Simon Horman wrote:
> Make use of standard helpers to simplify filling in stats strings.
>
> The first two ethtool_puts() changes address the following fortification
> warnings flagged by W=1 builds with clang-18. (The last ethtool_puts
> change does
On Wed, May 08, 2024 at 05:22:51PM +, Justin Stitt wrote:
> Running syzkaller with the newly reintroduced signed integer overflow
> sanitizer produces this report:
>
> [ 65.194362] [ cut here ]
> [ 65.197752] UBSAN: signed-integer-overflow in
> ../drivers/scsi/sr_i
On Tue, 7 May 2024 at 16:27, Kees Cook wrote:
>
> When I say "overflow", I mean "overflow and underflow", but more
> specifically I mean "wrap-around". This is not about "undefined
> behavior". We already demand from our compilers that all our arithmetic
> uses a well-defined overflow resolution s
On 2024-05-08 10:13:41+, Kees Cook wrote:
> The read_actions_logged() and write_actions_logged() helpers called by the
> sysctl proc handler seccomp_actions_logged_handler() are already expecting
> their sysctl table argument to be read-only. Actually mark the argument
> as const in preparation
On Wed, May 08, 2024 at 10:13:41AM -0700, Kees Cook wrote:
> The read_actions_logged() and write_actions_logged() helpers called by the
> sysctl proc handler seccomp_actions_logged_handler() are already expecting
> their sysctl table argument to be read-only. Actually mark the argument
> as const i
On Wed, May 08, 2024 at 10:52:44AM -0700, Linus Torvalds wrote:
> On Tue, 7 May 2024 at 16:27, Kees Cook wrote:
> [...]
> Put another way the absolute first and fundamental thing you should
> look at is to make sure tools don't complain about sane behavior.
Agreed, and I explicitly called this ou
On Wed, 8 May 2024 at 12:45, Kees Cook wrote:
>
> On Wed, May 08, 2024 at 10:52:44AM -0700, Linus Torvalds wrote:
> > Example:
> >
> >static inline u32 __hash_32_generic(u32 val)
> >{
> > return val * GOLDEN_RATIO_32;
> >}
>
> But what about:
>
> static inline u32 __item_offset
On Wed, May 08, 2024 at 01:07:38PM -0700, Linus Torvalds wrote:
> On Wed, 8 May 2024 at 12:45, Kees Cook wrote:
> >
> > On Wed, May 08, 2024 at 10:52:44AM -0700, Linus Torvalds wrote:
> > > Example:
> > >
> > >static inline u32 __hash_32_generic(u32 val)
> > >{
> > > return val * G
On Mon, 6 May 2024 12:38:32 +0200
Ard Biesheuvel wrote:
> The logic in arch/x86/boot/compressed/kaslr.c is now only used by non-EFI
> boot.
>
> In general, I am highly skeptical that hopes and prayers are enough to
> prevent the firmware from stepping on such a region, unless this is
> only a
On Wed, May 08, 2024 at 12:22:38PM +, David Laight wrote:
> Have you estimated the performance cost of checking the result of
> all integer arithmetic.
I hadn't included that in my already very long email as performance is
somewhat secondary to the correctness goals. Perhaps that was a mistake
On Wed, 8 May 2024 at 15:54, Kees Cook wrote:
>
> Sure, but if the bar is omniscience, that's not a path forward.
I really don't think there's a lot of omniscience involved at all.
> I haven't really heard a viable counterproposal here.
So let me make the counter-proposal that you actually conc
On Wed, 8 May 2024 at 16:47, Linus Torvalds
wrote:
>
> But again, maybe it would be worth looking into, at least for some
> limited cases. To go back to your particular example, it might be
> worth trying to limit it for unusual type sizes like implicit casts to
> 'u16' or bitfields: not because t
On Wed, 8 May 2024 at 16:47, Linus Torvalds
wrote:
>
> So *that* I feel could be something where you can warn without a ton
> of compiler smarts at all. If you see an *implicit* cast to unsigned
> and then the subsequent operations wraps around, it's probably worth
> being a lot more worried about
On Wed, 1 May 2024 18:30:40 +0300
Mike Rapoport wrote:
> > So this will allocate the same physical location for every boot, if booting
> > the same kernel and having the same physical memory layout?
>
> Up to kaslr that might use that location for the kernel image.
> But it's the same as alloc
On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> For example, the most common case of overflow we've ever had has very
> much been array indexing. Now, sometimes that has actually been actual
> undefined behavior, because it's been overflow in signed variables,
> and those are "eas
25 matches
Mail list logo
