lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YwWIQ/3BDQHOiTek@ZenIV>
Date:   Wed, 24 Aug 2022 03:09:07 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Bart Van Assche <bvanassche@....org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Hellwig <hch@....de>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        Jens Axboe <axboe@...nel.dk>
Subject: Re: [for-linus][PATCH 01/10] tracing: Suppress sparse warnings
 triggered by is_signed_type()

On Tue, Aug 23, 2022 at 04:57:00PM -0700, Linus Torvalds wrote:
> On Tue, Aug 23, 2022 at 4:18 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Can you try the sparse version at
> >
> >    git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git
> >
> > which I just set up temporarily with some patches of mine.
> 
> Ugh, and while testing this with sparse, I noticed that sparse itself
> got that whole 'is_signed_type()' check wrong.
> 
> The sparse fix was to remove one line of code, but that one worries
> me, because that one line was clearly very intentional:
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git/commit/?id=7e5f1c2eba1426e414698071dd0de7d039eb385d
> 
> Adding Al, since he's actually the original source of that bitwise
> code (and did a lot of other sparse code on the type handling and
> preprocessor side in particular).

Ouch...  That'll take quite a bit of swap-in (and digging through the
old notes).  I'll take a look, but there's an unrelated problem:
	ANY ordered comparisons should spew warnings on bitwise
And we really want that to happen - things like
#define MASK cpu_to_le32(1023)
	if (foo->len > MASK)
		return -EINVAL;
	something(le32_to_cpu(foo->len));
should trigger warnings and I have seen real bugs of that sort.

So I'm not sure how is that supposed to work without sparse getting
loudly unhappy.

Al, going to look through that thread and then try to reconstruct sparse-related
notes...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ