[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5jKt9NuGeHumTkO2aD1MoBdP-OwRTXu1_qq0r8_t=Y6sMw@mail.gmail.com>
Date: Mon, 6 May 2019 15:19:55 -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 3/4] Fix twofish crypto functions prototype casts
On Mon, May 6, 2019 at 12:20 PM Joao Moreira <jmoreira@...e.de> wrote:
> RFC: twofish_enc_blk_ctr_3way is assigned both to .ecb and to .ctr,
> what makes its declaration through the macro undoable, as thought in
> this patch. Suggestions on how to fix this are welcome.
This looks like a typo in the original code (due to the lack of type checking!)
typedef void (*common_glue_func_t)(void *ctx, u8 *dst, const u8 *src);
...
#define GLUE_FUNC_CAST(fn) ((common_glue_func_t)(fn))
...
void twofish_enc_blk_ctr_3way(void *ctx, u128 *dst, const u128 *src,
le128 *iv)
static const struct common_glue_ctx twofish_ctr = {
...
.fn_u = { .ecb = GLUE_FUNC_CAST(twofish_enc_blk_ctr_3way) }
...
return glue_ctr_req_128bit(&twofish_ctr, req);
int glue_ctr_req_128bit(const struct common_glue_ctx *gctx,
struct skcipher_request *req)
...
gctx->funcs[i].fn_u.ctr(ctx, dst, src, &ctrblk);
The twofish_ctr structure is actually only ever using the .ctr
assignment in the code, but it's a union, so the assignment via .ecb
is the same as .ctr.
--
Kees Cook
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
