Received: by 10.192.165.156 with SMTP id m28csp1407161imm; Wed, 18 Apr 2018 09:09:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx49/Vf+wZlwinN21m8MHk+OpV1YcdLmHH73vfrWxeu3WDBzI8yw19ThmdTXvuz42631eQdVu X-Received: by 2002:a17:902:d807:: with SMTP id a7-v6mr2722074plz.314.1524067767699; Wed, 18 Apr 2018 09:09:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524067767; cv=none; d=google.com; s=arc-20160816; b=EQ1Z6q5dRKduVssp4ngX8lK3+2mXSLkuIkELp+qqGA25TW9eaWztWD1CfxUfk3zKKL sAmpx/bUGsq2J5tiAhplhoFYAQboyjU88ih+ggQ+W1lZmpDoKx1Eqn1iBQT3fGDL5cyK d0pAFYHL7W4m2JCuXuR+hX2UeNWnht7VsOoVewj419wsB4CjJLPmdq9r24F7Aprf3dm0 N82jQxJDZE4cV+YxeXA2hu/8V72MvfZTQWfc25lzn1aaOKoRLecJZoIROa73EksORbIE yWKIYG9iUvHkUxED5GZgiMZ0QvVjsBiFrtohOZJtSU7Ih2yFxGfR3br7z12mjbHHeizR 9+Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=qGf+txAW9yQWFT30fboKQXg5Lm8gyAyMrkrl3ton6jI=; b=mYVMPRFCdUmfivCBOf700XrdLEsOnUxIMc7B5OgpbC9cukwZ//uoL9W2zu/fOgVQrE dIgoUHQt8M1Iz/wXScdSKo4vk7vjEeNiqIWfV7CW0nWpdW8ok5WmiY26o/Pj44k2fPZB 71uzOlENw8yjIPKrTcG2g+3PIYpwMlixolptnQ+pG3lFCE2atG27cBA3bT/NW6i1q1fQ FcB+BhKXGm7hJLOV+ekSr/1kNuY9vlzTxlD5UvwgQzDxfRutqsKZFWrIW+PaZoOwEvNY gJl7yoVz2LTYihGtVBpzC3fV1L+9S3rK3e1QvBT7FEAz5j/KvDFm3lGJdFQEG8ByDiQa HUaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=AoTZvbmc; dkim=fail header.i=@chromium.org header.s=google header.b=PVv/RUYn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d17si1115418pgo.183.2018.04.18.09.09.12; Wed, 18 Apr 2018 09:09:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=AoTZvbmc; dkim=fail header.i=@chromium.org header.s=google header.b=PVv/RUYn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752698AbeDRQHf (ORCPT + 99 others); Wed, 18 Apr 2018 12:07:35 -0400 Received: from mail-vk0-f65.google.com ([209.85.213.65]:36654 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751232AbeDRQHd (ORCPT ); Wed, 18 Apr 2018 12:07:33 -0400 Received: by mail-vk0-f65.google.com with SMTP id w1so1371595vkf.3 for ; Wed, 18 Apr 2018 09:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qGf+txAW9yQWFT30fboKQXg5Lm8gyAyMrkrl3ton6jI=; b=AoTZvbmcceUqw3bXu2Dx2vwVMMJVpRo8X6wCWP4ro/d9xj4BYY7W4GrzIQapFBsWp4 gbm2RKQ2ePKAZB/Pu8hm7uqNr1D0EXwmo4WJXQzS6YcEZOrBrAU+1q/oxS4t3pqrIeb6 xPXpJZDn2GjFE+itwBjd7Dn3qHAK1GcOf4N4QTauDso4aPygO5cWchp2sE9S2vPuXffe EkGaMHQd+5BGRHGYKVYHtxXk9/skySZpAc0j7UcnlbDNrfbuD+CakX4qwjQSdhYK641C 4UDcC1KvX0lAm3AONDztsdZZtCzvDwrvpK5a+tBo+m55nDo7oJ28U6mTvVnpdkAMtOPY 4tjA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qGf+txAW9yQWFT30fboKQXg5Lm8gyAyMrkrl3ton6jI=; b=PVv/RUYns7zT3Rx5uPbHEiGETVgmO2sESXDITUxhjoZXELnGKkrNXxcqKg6KnoEQgr s2cSco0TJPqOnkWkPv9bjLzeqaAJKrLpO06cofM3ViEyD0waMHFnk4newSsmrtglw513 eGJ1RoDwxZrCCbPhWtf1GqoU3UnehdyieHOLc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qGf+txAW9yQWFT30fboKQXg5Lm8gyAyMrkrl3ton6jI=; b=iMU8Jnwh3qWEb54PPzKdTyR+AHcQ5WSDTaTVJOXZbAIoVenvW12+IqyjwwaHdVwjF2 5t5i1LbR+qhOgTf5utiq+856n6yJVx2Sx+ZDIOqnBnu18fbhT5sQV9WxcpdoeXnJlX/P t0f2lK/C15FvA8i1/7RZFIC3c6JP9kOqVn6b21JCNA9ZcT13jVJZeOVZNjRPexAYiiv7 qQvq36hv/4B0g+fazHE3iKhFS/pSt84SMo3EII5+NIuMBAZVisq7Cb3G5ylfrvSzMT2W 2htF5mPeApzWoO0eoWIkLnB1BlMPrQfhshGjHxdVe2uZOIUPTOYNNtMbkvyxm0xklMoN Hq5Q== X-Gm-Message-State: ALQs6tA6tcC2SwbNJnrj4Gym/OFoWaNpsJQt9H52qAERxodZWcvony+D 2FZTb+IqRztf1PPTQ3cT6Ze94ZwZPQYeRoSj2epGyw== X-Received: by 10.31.185.210 with SMTP id j201mr1807813vkf.123.1524067651986; Wed, 18 Apr 2018 09:07:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.164.81 with HTTP; Wed, 18 Apr 2018 09:07:31 -0700 (PDT) In-Reply-To: <20180416061044.z6eb4psw2sbszemb@gmail.com> References: <20180415041542.5364-1-jmoreira@suse.de> <20180415041542.5364-2-jmoreira@suse.de> <20180416061044.z6eb4psw2sbszemb@gmail.com> From: Kees Cook Date: Wed, 18 Apr 2018 09:07:31 -0700 X-Google-Sender-Auth: GtIqG6tekszRW4TasKcxV6lIkUA Message-ID: Subject: Re: [PATCH 1/4] x86/crypto: camellia: Fix function prototypes To: Ingo Molnar Cc: Joao Moreira , Kernel Hardening , LKML , X86 ML , Herbert Xu , "David S. Miller" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Greg KH Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 15, 2018 at 11:10 PM, Ingo Molnar wrote: > > * Joao Moreira wrote: > >> Convert the use of 'struct camellia_ctx *' to 'void *' in prototypes of >> functions which are referenced through 'struct common_glue_func_entry', >> making their prototypes match those of this struct and, consequently, >> turning them compatible with CFI requirements. >> >> Whenever needed, cast 'void *' to 'struct camellia_ctx *'. > >> +static inline void camellia_enc_blk(void *ctx, u8 *dst, const u8 *src) >> { >> - __camellia_enc_blk(ctx, dst, src, false); >> + __camellia_enc_blk((struct camellia_ctx *) ctx, dst, src, false); >> } > > I don't see how this is an improvement: instead of having a proper type there's > now an opaque type and an ugly (and dangerous) type cast. I agree with your instinct, as the existing best-practice in the kernel is to always use correct types and avoid casts to let the compiler check things, avoid nasty surprises, etc, but for callbacks with context pointers, we're already just hiding the casts in various places. For example, even without this patch: typedef void (*common_glue_func_t)(void *ctx, u8 *dst, const u8 *src); #define GLUE_FUNC_CAST(fn) ((common_glue_func_t)(fn)) static const struct common_glue_ctx camellia_enc = { ... .funcs = { { ... .num_blocks = 1, .fn_u = { .ecb = GLUE_FUNC_CAST(camellia_enc_blk) } } } }; While it is nicely wrapped up in macros, this is actually casting away the _entire_ function prototype, not just the first argument. The "camellia_enc_blk" function could point to anything (even "void (*func)(void)") and the compiler wouldn't complain. And this was done just to mask the ctx argument. > What does "compatible with CFI requirements" mean? As Joao mentioned, he wrote this up pretty well in his 0/n patch: https://lkml.kernel.org/r/20180415041542.5364-1-jmoreira@suse.de To further clarify, fine-grained function-prototype-checking CFI makes sure that indirect function call sites only call functions with a matching expected prototype (to protect against having function pointers rewritten during an attack, etc). In this case, callers of .fn_u.ecb() expect the target function to have the prototype "void (*func)(void *ctx, u8 *dst, const u8 *src)" (as defined by struct common_glue_ctx), however, camellia_enc_blk() is "void (*func)(struct camellia_ctx *ctx, u8 *dst, const u8 *src)" and will trip the CFI check. If we rearrange our macro magic to defining the callbacks rather than defining the function pointers, I think we'll gain several things: - we will cast only the ctx argument instead of the entire function prototype - we'll retain (and improve) source-code robustness against generally miscasting - CFI will be happy So, instead of the original series, how about something like this: Switch function pointers to not use the function cast, and define a new GLUE_FUNC macro that kinda looks like the tricks used for syscalls: static const struct common_glue_ctx camellia_enc = { ... .funcs = { { ... .num_blocks = 1, .fn_u = { .ecb = camellia_enc_blk } } } }; #define GLUE_FUNC(func, context) \ static inline void func(void *ctx, u8 *dst, const u8 *src) \ { __##func((context)ctx, dst, src); } \ __##func(context ctx, u8 *dst, const u8 *src) GLUE_FUNC(camellia_enc_blk, struct camellia_ctx *) { ...original function... } -Kees -- Kees Cook Pixel Security