Date:   Mon, 26 Sep 2022 17:11:51 -0400
From:   David Malcolm <dmalcolm@...hat.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-hardening@...r.kernel.org, j.koschel@...nl
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:
> https://lore.kernel.org/linux-hardening/20220914115953.3854029-1-keescook@chromium.org/

Thanks!

> 
> 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:
> https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
> 
> Clang seems to support the address_space and noderef attributes:
> https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments
> https://clang.llvm.org/docs/AttributeReference.html#noderef
> But when I tried a while back to make it work, it fell over:
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=clang/address_space&id=beff911c13390a71b3f7921fd82ec6a71ca75c02
> 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:
  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=sparse
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:
> https://lpc.events/event/16/contributions/1211/
> "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).
> https://clang.llvm.org/docs/DataFlowSanitizer.html
> https://github.com/vusec/kdfsan-linux/commit/45614ee1a3a0d7b98c5cecb1b747184279bc615c
> 
> 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:
> https://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/linux.git/log/?h=lto
> 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:
> https://lpc.events/event/16/contributions/1173/
> https://outflux.net/slides/2022/lpc/features.pdf
> 

Thanks; this is all very helpful
Dave

Powered by blists - more mailing lists