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, 19 Apr 2021 09:45:48 -0700
From:   Joao Moreira <>
To:     Rasmus Villemoes <>,
        Kees Cook <>,
        Andy Lutomirski <>
Cc:     Borislav Petkov <>,
        Sami Tolvanen <>,
        X86 ML <>, Josh Poimboeuf <>,
        Peter Zijlstra <>,
        Nathan Chancellor <>,
        Nick Desaulniers <>,
        Sedat Dilek <>,,
        LKML <>,
        clang-built-linux <>
Subject: Re: [PATCH 05/15] x86: Implement function_nocfi

> Why not? In particular, I'd really like somebody to answer the question
> "why not just store a cookie before each address-taken or
> external-linkage function?".
FWIIW, this was done before (at least twice): First with grsecurity/PaX 
RAP ( then with kCFI 
(, - which is no longer maintained).

At the time I worked on kCFI someone raised a concern regarding this 
cookie-based design being mutually exclusive to execute-only memories 
(XOM), what, if XOM is really relevant to someone, should be a valid 

Since design is being questioned, an x86/CET-specific third design for 
CFI was recently discussed here: -- I assume 
that, arch-dependency considered, this should be easier to integrate 
when compared to clang-cfi. Also, given that it is based on CET, this 
also has the benefit of constraining mispeculations (which is a nice 

Tks, Joao

Powered by blists - more mailing lists