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:   Mon, 2 May 2022 08:31:35 -0700
From:   Sami Tolvanen <>
To:     Sami Tolvanen <>,
        LKML <>,
        Kees Cook <>,
        Josh Poimboeuf <>,
        Peter Zijlstra <>, X86 ML <>,
        Catalin Marinas <>,
        Will Deacon <>,
        Mark Rutland <>,
        Nathan Chancellor <>,
        Nick Desaulniers <>,
        Joao Moreira <>,
        Sedat Dilek <>,
        Steven Rostedt <>,,
        linux-arm-kernel <>,
Subject: Re: [RFC PATCH 00/21] KCFI support

On Sat, Apr 30, 2022 at 9:08 AM Kenton Groombridge <> wrote:
> Many thanks for continuing to work on this! As a user who has been
> following the evolution of this patch series for a while now, I have a
> couple of burning questions:
> 1) The LLVM patch says that kCFI is not compatible with execute-only
> memory. Is there a plan ahead for kCFI if and when execute-only memory
> is implemented?

There's no plan for executable-only memory right now, that would
require type hashes to be moved somewhere else to read-only memory.

> 2) kCFI only checks indirect calls while Clang's traditional CFI has
> more schemes like bad cast checking and so on. Are there any major
> security tradeoffs as a result of this?

No, cfi-icall is only scheme that's relevant for the kernel. The other
schemes implemented in Clang are mostly useful for C++.


Powered by blists - more mailing lists