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: <bf3273120d8d48a79357f229c5890576@overdrivepizza.com>
Date:   Wed, 20 Apr 2022 15:40:41 -0700
From:   Joao Moreira <joao@...rdrivepizza.com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>, hjl.tools@...il.com,
        Fangrui Song <maskray@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
        andrew.cooper3@...rix.com, keescook@...omium.org,
        samitolvanen@...gle.com, mark.rutland@....com,
        alyssa.milburn@...ux.intel.com, gabriel.gomes@...ux.intel.com,
        rick.p.edgecombe@...el.com
Subject: Re: [RFC PATCH 00/11] Kernel FineIBT Support

>> 
>> If FineIBT needs it, I could reconsider.  But I think there's a strong
>> case to be made that the linker should be doing that instead.
> 
> That sounds reasonable to me (and reminds me of linker relaxation).
> Joao, can you please work with Fangrui (LLD) and HJ (GNU binutils) to
> determine how feasible this would be? I assume code outside the kernel
> might enjoy such an optimization, too.  When that's the case, then it
> probably makes more sense to "upstream" such "optimizations" from the
> kernel-specific objtool into the toolchains.

Alright, these are the greenlights I was hoping for.

I went quickly into this with HJ and he mentioned that it should be 
doable in the linker, and that he has a patch for it in gcc (for local 
function, from what I could see): 
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590832.html

If @Fangrui is fine with it, I would like to try implementing this 
myself in lld (I'm still learning a lot about lld and having an actual 
problem to solve is the kind of fuel I need). Should take me a while, 
but I think this is not urgent, right? I can also go ahead and replicate 
HJ's gcc patch into clang, so we can also handle the local functions 
within the compiler (I think this makes a lot of sense).

Once we have these in, I'll revisit FineIBT and extend the features to 
handle the FineIBT instrumentation. Hopefully we'll be released from 
needing objtool (famous last words?!).

This sounds like a plan, but I'm ofc open to suggestions or different 
ideas/plans.

Tks,
Joao

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ