On Wed, 29 Jan 2025 at 00:14, Joel Granados wrote:
>
> All ctl_table declared outside of functions and that remain unmodified after
> initialization are const qualified.
Hmm. A quick grep shows
static struct ctl_table alignment_tbl[5] = {
in arch/csky/abiv1/alignment.c that didn't get c
On Fri, 29 Nov 2024 at 23:15, Linus Torvalds
wrote:
>
> And yes, we could make the word-at-a-time case also know about masking
> the last word, but it's kind of annoying and depends on byte ordering.
Actually, it turned out to be really trivial to do. It does depend on
byte order
On Sun, 1 Dec 2024 at 06:17, Christian Brauner wrote:
>
> /*
> * Hold rcu lock to keep the name from being freed behind our back.
> * Use cquire semantics to make sure the terminating NUL from
> * __d_alloc() is seen.
> *
> * Note, we're deliberately sloppy here. We don't need to care about
>
On Sat, 30 Nov 2024 at 13:05, Kees Cook wrote:
>
> Yeah, this just means it has greater potential to be garbled.
Garbled is fine. Id' just rather it be "consistently padded".
> This is fine, but it doesn't solve either an unstable source nor
> concurrent writers to dest.
Yeah, I guess concurren
On Sat, 30 Nov 2024 at 12:28, Mateusz Guzik wrote:
>
> > + /* The dentry name won't change while we hold the rcu read
> > lock. */
> > + __set_task_comm(me,
> > smp_load_acquire(&bprm->file->f_path.dentry->d_name.name),
> > + true);
>
> This do
On Sat, 30 Nov 2024 at 04:30, Christian Brauner wrote:
>
> What does the smp_load_acquire() pair with?
I'm not sure we have them everywhere, but at least this one at dentry
creation time.
__d_alloc():
/* Make sure we always see the terminating NUL character */
smp_store_release(&
Edited down to just the end result:
On Fri, 29 Nov 2024 at 20:49, Kees Cook wrote:
>
> void __set_task_comm(struct task_struct *tsk, const char *buf, bool exec)
> {
> size_t len = min(strlen(buf), sizeof(tsk->comm) - 1);
>
> trace_task_rename(tsk, buf);
> memcpy(tsk->com
On Sat, 28 Sept 2024 at 11:13, Nathan Chancellor wrote:
>
> MODVERSIONS recently grew a dependency on !COMPILE_TEST so that Rust
> could be more easily tested. However, this introduces a Kconfig warning
> when building allmodconfig with a clang version that supports RANDSTRUCT
> natively because R
On Tue, 30 Jul 2024 at 16:09, Jeff Xu wrote:
>
> > + task = get_proc_task(file_inode(file));
> > + if (task) {
> > + ptrace_active = task->ptrace && task->mm == mm &&
> > task->parent == current;
>
> Do we need to call "read_lock(&tasklist_lock);"
On Tue, 23 Jul 2024 at 11:30, Linus Torvalds
wrote:
>
> but while that looks a bit prettier, the whole "fs_parser.h" thing is
> admittedly odd.
.. don't get me wrong - /proc obviously *is* a filesystem, but in this
context it's a boot command line parame
On Tue, 23 Jul 2024 at 10:18, Adrian Ratiu wrote:
>
> This adds a Kconfig option and boot param to allow removing
> the FOLL_FORCE flag from /proc/pid/mem write calls because
> it can be abused.
Ack, this looks much simpler.
That said, I think this can be prettied up some more:
> +enum proc_mem
On Wed, 17 Jul 2024 at 15:24, Kees Cook wrote:
>
> > In particular, this patch would make it easy to make that
> > SECURITY_PROC_MEM_RESTRICT_FOLL_FORCE config option be a "choice"
> > where you pick "never, ptrace, always" by just changing the rules in
> > proc_is_ptracing().
>
> So the original
On Wed, 17 Jul 2024 at 10:23, Kees Cook wrote:
>
> For this to be available for general distros, I still want to have a
> bootparam to control this, otherwise this mitigation will never see much
> testing as most kernel deployments don't build their own kernels. A
> simple __ro_after_init variable
On Mon, 15 Jul 2024 at 09:29, Kees Cook wrote:
>
> Please pull these small pstore updates for v6.11-rc1. (Note that since there
> were no pstore updates for v6.10, this is based on v6.9-rc2. I forgot
> to do my traditional merge-on-rc2 for this tree when v6.10-rc2 happened.)
Note that this is exa
On Tue, 28 May 2024 at 15:12, Thomas Gleixner wrote:
>
> I principle it applies to any clocksource which needs a spinlock to
> serialize access. HPET is not the only insanity here.
HPET may be the main / only one we care about.
Because:
> Think about i8253 :)
I see the smiley, but yeah, I don'
On Sun, 12 May 2024 at 01:03, Martin Uecker wrote:
>
> But I guess it still could be smarter. Or does it have to be a
> sanitizer because compile-time will always have too many false
> positives?
Yes, there will be way too many false positives.
I'm pretty sure there will be a ton of "intentional
On Thu, 9 May 2024 at 11:48, Al Viro wrote:
>
> FWIW, the thing that somewhat worries me about having a helper along
> the lines of combine_to_u64(low, high) is that
> foo->splat = combine_to_u64(something, something_else);
> would be inviting hard-to-catch brainos -
> foo->splat =
On Thu, 9 May 2024 at 11:08, Linus Torvalds
wrote:
>
> Any half-way decent compiler will end up optimizing away the shifts
> and adds for the high bits because they see the assignment to
> 'all_bits'. There's no point in generating high bits that just get
>
On Thu, 9 May 2024 at 10:54, Al Viro wrote:
>
> On Thu, May 09, 2024 at 08:38:28AM -0700, Linus Torvalds wrote:
>
> > Going the other way is similar:
> >
> > all_bits = low_bits + ((u64) high_bits << 16) << 16);
> >
> > and again, the
On Thu, 9 May 2024 at 07:09, Theodore Ts'o wrote:
>
> struct ext2_super {
>...
>__u32time_lo;
>__u32time_high;
>...
> }
>
> time_t now;
>
> sb->time_low = now;
> sb->time_high = now >> 32;
>
> This is obviously (to a human) correct,
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
> bein
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'
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 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;
> >}
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 Thu, 8 Feb 2024 at 10:55, Borislav Petkov wrote:
>
> What about its benefit?
>
> I haven't seen a bug fix saying "found by KFENCE" or so but that doesn't
> mean a whole lot.
It does find some things. You can search for "BUG: KFENCE" on lore,
and there are real bug reports.
That said, there ar
On Thu, 1 Feb 2024 at 23:53, Arnd Bergmann wrote:
>
> I did a creduce pass on this warning when it first showed up
> and opened a gcc bug report as well as a driver workaround:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214
> https://lore.kernel.org/lkml/20240103114819.2913937-1-a...@kern
On Fri, 26 Jan 2024 at 14:24, Kees Cook wrote:
>
> I think xe has some other weird problems too. This may be related (under
> allocating):
>
> ../drivers/gpu/drm/xe/xe_vm.c: In function 'xe_vma_create':
> ../drivers/gpu/drm/xe/xe_vm.c:806:21: warning: allocation of insufficient
> size '224' for t
On Mon, 22 Jan 2024 at 07:29, Gustavo A. R. Silva wrote:
>
> Enable -Wstringop-overflow globally
I suspect I'll have to revert this.
On arm64, I get a "writing 16 bytes into a region of size 0" in the Xe driver
drivers/gpu/drm/xe/xe_gt_pagefault.c:340
but I haven't looked into it much yet.
On Mon, 22 Jan 2024 at 17:38, Kees Cook wrote:
>
> I've tried to find the right balance between not enough details and too
> much. I guess I got it wrong.
My complaint isn't about the level of detail.
My complaint is about how the commit log IS ACTIVELY MISLEADING
GARBAGE and does not match the
On Mon, 22 Jan 2024 at 16:46, Kees Cook wrote:
>
> Refactor open-coded unsigned wrap-around addition test to use
> check_add_overflow(),
NAK.
First off, none of this has anything to do with -fno-strict-overflow.
We do that, because without it gcc ends up doing various odd and
surprising things,
On Fri, 20 Oct 2023 at 10:40, Justin Stitt wrote:
>
> There's some docs at [1]. Perhaps there could be more?
>
> [1]:
> https://elixir.bootlin.com/linux/v6.6-rc6/source/include/linux/fortify-string.h#L292
Note that we have so few 'strlcpy()' calls that we really should
remove that horrid horrid
On Sun, 24 Sept 2023 at 09:58, Alexey Dobriyan wrote:
>
> Most of those in uapi/ are likely unnecessary: extern "C" means
> "don't mangle", but kernel doesn't export functions to userspace
> except vDSO so there is nothing to mangle in the first place.
I suspect a lot of it is "this got copied-an
On Fri, 22 Sept 2023 at 20:49, Kees Cook wrote:
>
> 2) __cplusplus is relatively common in UAPI headers already:
>$ git grep __cplusplus -- include/uapi | wc -l
>58
Look a bit closer.
Most of those - by far - is for the usual
#if defined(__cplusplus)
extern "C" {
#endif
pattern.
34 matches
Mail list logo
