From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E49CC43460 for ; Fri, 16 Apr 2021 22:20:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3286B613C1 for ; Fri, 16 Apr 2021 22:20:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235258AbhDPWU5 (ORCPT ); Fri, 16 Apr 2021 18:20:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:48180 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231510AbhDPWUy (ORCPT ); Fri, 16 Apr 2021 18:20:54 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8D71E613D3 for ; Fri, 16 Apr 2021 22:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618611629; bh=cw+o8cfEuCo6PQdHXEsdN0LoqovEdVoWI1b2P0UF/Og=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jxKsP0Fr9kLKdD37KZFr2gu8uqJ4eMaAup4AizAaAIdv9BKvzqPDEgdgbRBqum7zC lWKQeigSIzxGjTJHEiwDs9xOo/IJUbEib4DA3B84aEQ5lLth2jUfE9lUj4h8QdAD1E 9Z2obm0iE+pEWoFyv7etI8gGBQtinezT/unZfPuCAuFvRIfPS4bKZ7yN9BeXLOXjNl lVBK12qMeYLlfofHvBxBmpPC1+zZX59BpJkWseUTGLjyQuWLncZGNvRiMC4y2Qys4I lhxVTpq9Aa87Zkp9Jcnq1KIFqAcjpNd7gurH56WiNZd/0MotMjImyhskUQyILS3pOl CQiDJVampjCng== Received: by mail-ed1-f51.google.com with SMTP id w18so34081898edc.0 for ; Fri, 16 Apr 2021 15:20:29 -0700 (PDT) X-Gm-Message-State: AOAM531PLaZ6BNfptW3V3jSgRBcOtDtfmcpS9+OK/xww1M8PBrcxqoY9 Gr9kofvlmXT2ePT9rj2rHEYGl3Z1krF28BnSYNMQsw== X-Google-Smtp-Source: ABdhPJwrhXiYlU+qO4b6VCJY/F1yFSIFXZAHioVtpExmGxj4TZL8vcEumj5aGB0McOtELfNfByc/+fwJgoYDXb5XsJs= X-Received: by 2002:a50:f395:: with SMTP id g21mr12764633edm.238.1618611628139; Fri, 16 Apr 2021 15:20:28 -0700 (PDT) MIME-Version: 1.0 References: <20210416203844.3803177-1-samitolvanen@google.com> <20210416203844.3803177-6-samitolvanen@google.com> <20210416211855.GD22348@zn.tnic> <20210416220251.GE22348@zn.tnic> <20210416221414.GF22348@zn.tnic> In-Reply-To: <20210416221414.GF22348@zn.tnic> From: Andy Lutomirski Date: Fri, 16 Apr 2021 15:20:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/15] x86: Implement function_nocfi To: Borislav Petkov Cc: Andy Lutomirski , Sami Tolvanen , X86 ML , Kees Cook , Josh Poimboeuf , Peter Zijlstra , Nathan Chancellor , Nick Desaulniers , Sedat Dilek , linux-hardening@vger.kernel.org, LKML , clang-built-linux Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 16, 2021 at 3:14 PM Borislav Petkov wrote: > > On Fri, Apr 16, 2021 at 03:06:17PM -0700, Andy Lutomirski wrote: > > On Fri, Apr 16, 2021 at 3:03 PM Borislav Petkov wrote: > > > > > > On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote: > > > > __nocfi only disables CFI checking in a function, the compiler still > > > > changes function addresses to point to the CFI jump table, which is > > > > why we need function_nocfi(). > > > > > > So call it __func_addr() or get_function_addr() or so, so that at least > > > it is clear what this does. > > > > > > > This seems backwards to me. If I do: > > > > extern void foo(some signature); > > > > then I would, perhaps naively, expect foo to be the actual symbol that > > I'm just reading the patch: > > ... The function_nocfi macro always returns the address of the > + * actual function instead. > + */ > +#define function_nocfi(x) ({ \ > + void *addr; \ > + asm("leaq " __stringify(x) "(%%rip), %0\n\t" : "=r" (addr)); \ > + addr; > > so it does a rip-relative load into a reg which ends up with the function > address. This is horrible. We made a mistake adapting the kernel to GCC's nonsensical stack protector ABI, especially on 32-bit, instead of making GCC fix it. Let's not repeat this with clang please. Sami, I'm assuming that: extern void func(void); results in anything that takes a pointer to func getting a pointer to some special magic descriptor instead of to func, so that: void (*ptr)(void); ptr = func; ptr(); does the right thing. Then void (*)(void) is no longer a raw pointer. Fine. But obviously there is code that needs real function pointers. How about making this a first-class feature, or at least hacking around it more cleanly. For example, what does this do: char entry_whatever[]; wrmsrl(..., (unsigned long)entry_whatever); or, alternatively, extern void func() __attribute__((nocfi)); void (*ptr)(void); ptr = func; /* probably fails to compile -- invalid conversion */ (unsigned long)func /* returns the actual pointer */ func(); /* works like normal */ And maybe allow this too: void (*ptr)(void) __attribute__((nocfi); ptr = func; ptr(); /* emits an unchecked call. maybe warns, too. anyone who does this needs to be extremely careful. */ --Andy