linux-kernel - Re: [RFC PATCH v2 0/4] x86/crypto: Fix crypto function casts

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: <CAGXu5jJ40OaniqR+rwu2npRNM4hGjbZoReWF=vhE99hB1Dqbow@mail.gmail.com>
Date:   Mon, 6 May 2019 14:54:19 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Joao Moreira <jmoreira@...e.de>
Cc:     Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [RFC PATCH v2 0/4] x86/crypto: Fix crypto function casts

On Mon, May 6, 2019 at 12:20 PM Joao Moreira <jmoreira@...e.de> wrote:
> It is possible to indirectly invoke functions with prototypes that do not
> match those of the respectively used function pointers by using void types.
> This feature is frequently used as a way of relaxing function invocation,
> making it possible that different data structures are passed to different
> functions through the same pointer.
>
> Despite the benefits, this can lead to a situation where functions with a
> given prototype are invoked by pointers with a different prototype, what is
> undesirable as it may prevent the use of heuristics such as prototype
> matching-based Control-Flow Integrity, which can be used to prevent
> ROP-based attacks.
>
> One way of fixing this situation is through the use of helper functions
> with prototypes that match the one in the respective invoking pointer.
>
> Given the above, the current efforts to improve the Linux security, and the
> upcoming kernel support to compilers with CFI features, fix the prototype
> casting of x86/crypto algorithms camellia, cast6, serpent and twofish with
> the use of a macro that generates the helper function.
>
> This patch does not introduce semantic changes to the cryptographic
> algorithms, yet, if someone finds relevant, the affected algorithms were
> tested with the help of tcrypt.ko without any visible harm.

Awesome; thanks for working on this! I'm looking through the patches
now and pondering solutions to the RFC in twofish. I'll send notes in
a bit...

-- 
Kees Cook