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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 26 Sep 2022 17:11:51 -0400
From:   David Malcolm <>
To:     Kees Cook <>
Subject: Re: -fanalyzer thoughts

On Wed, 2022-09-14 at 05:43 -0700, Kees Cook wrote:
> Hi!
> Thanks for the talk today! I sent a patch for the aic79xx_osm.c issue
> you mentioned:


> I didn't have a chance to add some more comments and ask a question
> before the session ended, so here I am in email, CCing the kernel
> hardening list in case other folks want to chime in. :)

Sorry for the belated response (back-to-back conferences and travel).

> You asked, "Should I try to have GCC type-check __user vs __kernel,
> or leave it to sparse?" I would *love* to get this in the compiler
> proper. Not nearly enough people are running sparse, so its output
> has
> become quite noisy, which means more and more regressions are
> slipping
> into the kernel. I was surprised a while back to discover that
> kernel's
> use of the address_space and noderef attributes weren't supported by
> GCC. It does seems like it'd make a good attribute (for which there
> is existing precedent), rather than polluting the global namespace,
> as AVR does:
> Clang seems to support the address_space and noderef attributes:
> But when I tried a while back to make it work, it fell over:
> If these get implemented in GCC, it'd be good to coordinate with
> Clang
> too, to make sure it works sanely in the kernel.

I've been experimenting with implementing this in GCC.

It turned out that GCC's bugzilla had a bunch of existing RFE bugs for
sparse support filed back in 2014, so I've created a tracker bug to
make it easier to find them; see:
and I'm hoping to get at least some of this done for GCC 13 (though
feature freeze is about 5 weeks away...)

> The question I had was if you had seen this LPC presentation:
> "How I started chasing speculative type confusion bugs in the kernel
> and
> ended up with 'real' ones"
> The authors used Clang's "Data Flow Sanitizer" and built a working
> taint/sink system that seems like it could be used for MUCH more
> analysis
> than just what they were looking it (as they hint at too).
> I wonder if DFSan could be ported to GCC? It seems to overlap
> logically
> with some of the -fanalyzer work, but I don't know the internals for
> either, so I likely have no idea what I'm talking about. ;)

Thanks for the links, both Kasper and DFSan look really interesting.

If I'm reading things right DFSan seems to be a run-time thing,
modifying the generated code to sanitize it, whereas GCC's -fanalyzer
is a compile-time thing, so I don't think it's directly compatible.

> Related, I wonder if LTO builds would help with -fanalyzer's control
> flow analysis? (DFSan requires LTO.)

>  Getting the kernel built with LTO
> under GCC seems to be an on-going project, but no pull requests have
> been sent lately:
> Maybe poking them from your side might help that get landed? I think
> people are interested in having LTO for the kernel for the
> performance
> gains it can provide.

Unfortunately, building with LTO tends to break -fanalyzer by exploding
the complexity of the analysis: I have an implementation of call
summarization to try to tame this, but it's buggy.  So a fair amount of
work would need to happen at the -fanalyzer side in addition to getting
the kernel to just build with LTO, so it's not been a priority for me.

> The second-to-last slide in my presentation (in the "bonus slides"
> section) has slightly more context about LTO and the kernel:

Thanks; this is all very helpful

Powered by blists - more mailing lists