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] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 17 Apr 2021 02:02:31 +0200
From:   Thomas Gleixner <>
To:     Kees Cook <>
Cc:     Sami Tolvanen <>,,
        Josh Poimboeuf <>,
        Peter Zijlstra <>,
        Nathan Chancellor <>,
        Nick Desaulniers <>,
        Sedat Dilek <>,,,
Subject: Re: [PATCH 06/15] x86: Avoid CFI jump tables in IDT and entry points

On Fri, Apr 16 2021 at 16:56, Kees Cook wrote:
> On Sat, Apr 17, 2021 at 12:26:56AM +0200, Thomas Gleixner wrote:
>> Where is the analysis why excluding 
>> > +CFLAGS_REMOVE_idt.o		:= $(CC_FLAGS_CFI)
>> > +CFLAGS_REMOVE_paravirt.o	:= $(CC_FLAGS_CFI)
>> all of idt.c and paravirt.c is correct and how that is going to be
>> correct in the future?
>> These files are excluded from CFI, so I can add whatever I want to them
>> and circumvent the purpose of CFI, right?
>> Brilliant plan that. But I know, sekurity ...
> *sigh* we're on the same side. :P I will choose to understand your
> comments here as:
> "How will enforcement of CFI policy be correctly maintained here if
> the justification for disabling it for whole compilation units is not
> clearly understandable by other developers not familiar with the nuances
> of its application?"

Plus, if there is a justification for disabling it for a whole
compilation unit:

 Where is the tooling which makes sure that this compilation unit is not
 later on filled with code which should be subject to CFI?



Powered by blists - more mailing lists