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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 14 Sep 2022 05:43:32 -0700
From:   Kees Cook <keescook@...omium.org>
To:     David Malcolm <dmalcolm@...hat.com>
Cc:     linux-hardening@...r.kernel.org, j.koschel@...nl
Subject: -fanalyzer thoughts

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/

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. :)

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.


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. ;)


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.

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!

-Kees

-- 
Kees Cook

Powered by blists - more mailing lists