| 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
| ||
|
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