From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D82CEC5 for ; Mon, 16 May 2022 12:28:26 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id d19so25477020lfj.4 for ; Mon, 16 May 2022 05:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=l7Fo0NeV7YueiEmkqNM4ZujNOBF0kyGi5nhK9D38CaE=; b=iiwL2Jqvlxyr2hAuSFDNP8tiNHrlQxAX6X5eXc/cmjVuAYKf/iJzMy3/a+Qcm5JmQL ANO+Qp7/aXRFbYOyyTTLldnKd18zxolxl4isMaGC4vJQu/+9sbuJytY3Ypx90mj8zQC4 tzNBayxdsgod0IQH/BUq/qfbBMJ0FzLwTtHS4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=l7Fo0NeV7YueiEmkqNM4ZujNOBF0kyGi5nhK9D38CaE=; b=qbyYvIUVw2z37hDgtWiDG0ZWGQSO0q9F9DniAKoaS3bkxNojpkMGt8u67goGyRkB0q mfRlMkQNtdPoaf8srujYDYgyAHpbRamoWql01QGrMtyiOmww/nlJQwSGGeKfjVjFmYVZ T7LbFpPLEnL+nK0Kmeh5ULzxb1HPd5HOuO48oC/ES1pFctVr3uTcayxI2D/NWxt/TQXB 3BNRIvYMTI7GkjspOwMNcACwlbYv5EaF1qEneiveik13oXwZH9aCwzVmVhbvtHJAqn4J FuAvbATczKxvtJPFxAkHjINPMwFk+QbKybYq6akVkX/wHwdW/38nGeO9R4acj/qFqUb4 i9OA== X-Gm-Message-State: AOAM5337T9HPJnamRXnZz9C6niKrQf1eRHXZ7ZUg0cOqXGe3AanhU+6M tBNB+lPQ4+c2f6BmqdT3Klg/pQ== X-Google-Smtp-Source: ABdhPJw4BLL5Yn4P0JiAebR1HlqACpRsi83Tuc5vArRTpPHSHMnS0jRcMj9vnWN/D0VLd8H8S3aGnA== X-Received: by 2002:a05:6512:2391:b0:473:ac1e:f2ce with SMTP id c17-20020a056512239100b00473ac1ef2cemr12881841lfv.297.1652704104659; Mon, 16 May 2022 05:28:24 -0700 (PDT) Received: from [172.16.11.74] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id 27-20020ac25f5b000000b0047255d210desm1296280lfz.13.2022.05.16.05.28.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 May 2022 05:28:24 -0700 (PDT) Message-ID: <9bd2db3e-2955-66ba-574e-7976bdd95a8e@rasmusvillemoes.dk> Date: Mon, 16 May 2022 14:28:22 +0200 Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH v2 07/21] cfi: Add type helper macros Content-Language: en-US To: Kees Cook , Sami Tolvanen Cc: linux-kernel@vger.kernel.org, Josh Poimboeuf , Peter Zijlstra , x86@kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-8-samitolvanen@google.com> <202205141447.E3B5A29@keescook> From: Rasmus Villemoes In-Reply-To: <202205141447.E3B5A29@keescook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14/05/2022 23.49, Kees Cook wrote: > On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote: >> With CONFIG_CFI_CLANG, assembly functions called indirectly >> from C code must be annotated with type identifiers to pass CFI >> checking. The compiler emits a __kcfi_typeid_ symbol for >> each address-taken function declaration in C, which contains the >> expected type identifier. Add typed versions of SYM_FUNC_START and >> SYM_FUNC_START_ALIAS, which emit the type identifier before the >> function. >> >> Signed-off-by: Sami Tolvanen > > And the reason to not make this change universally (i.e. directly in > SYM_FUNC_START) is to minimize how many of these symbol annotations get > emitted? (And to more directly indicate which asm is called indirectly?) > > What happens if an asm function is called indirectly and it doesn't have > this annotation? Presumably that's a fail. I'm also interested in how this works at the asm/linker level. I assume that the .o file generated from the asm input has __kcfi_typeid_ as an undefined symbol; the compiler emits that symbol as an absolute one upon taking the address of , and the linker then has the info it needs to patch things up. But what then happens if we have some function implemented in assembly which for whatever .config reason never has its address taken in any .c translation unit that gets linked in? Does the __kcfi_typeid_ symbol silently resolve to 0, or does the link fail? I can't really imagine the compiler emitting __kcfi_typeid_ symbols for each and every function it sees merely declared in some header. Two different .c files both taking the address of should of course emit the same value for __kcfi_typeid_. Is there any sanity check anywhere that that's actually the case? Can we please have some objdump/readelf output from some .o files involved here? Rasmus 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 98D91C433F5 for ; Mon, 16 May 2022 12:29:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZfIyzgB7bsIqJi2et6AfP8GRCYgazi/CTDpDuc5leTw=; b=F/a7aWMaiwDPHz 7AyuH/dHt7g6PXpoFEVnQjYL/iKSiYnobsNZ8Cyk0i3ou2TZk7zqnDs3QrJp59Jx5VBDz0UFR9L8B FCbH3sXdGEZehhScARyCAGk2Zp8OqdKw4pqk6owdqi/lWkEgumCwBoEKMdoghkL5AaIZlHwhyw6A9 b2xmSw7HtgB92bc2OTpChFJSH8fjBJ7FS3VikZhPpuYDO323oTA/AZc1D4ivmLOCjXcJLmv5UATMC VWfX+VYDN9tgH5y+LSdQXxC8vGbhRGeNh59RUtxiUT1utNspBuZXz6MsxFyVJnmiTUR8vA2wN7PtD gf/2xs9bA7llrImexcOA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqZpu-007bOd-8Q; Mon, 16 May 2022 12:28:30 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqZpq-007bMt-R2 for linux-arm-kernel@lists.infradead.org; Mon, 16 May 2022 12:28:28 +0000 Received: by mail-lf1-x133.google.com with SMTP id b18so25455165lfv.9 for ; Mon, 16 May 2022 05:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=l7Fo0NeV7YueiEmkqNM4ZujNOBF0kyGi5nhK9D38CaE=; b=iiwL2Jqvlxyr2hAuSFDNP8tiNHrlQxAX6X5eXc/cmjVuAYKf/iJzMy3/a+Qcm5JmQL ANO+Qp7/aXRFbYOyyTTLldnKd18zxolxl4isMaGC4vJQu/+9sbuJytY3Ypx90mj8zQC4 tzNBayxdsgod0IQH/BUq/qfbBMJ0FzLwTtHS4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=l7Fo0NeV7YueiEmkqNM4ZujNOBF0kyGi5nhK9D38CaE=; b=E2B4IBSQmiMZhY5NDV+rnL6VztGwUkoXlRV75M7qcdR+34mhW2JDxJ409HBplxFdFB foqz/8hYuVjcNqDE2B3KivRC2vIo0DaHcYlbePYi1R2pFKmT1TPelYTK3fTZ56Vk9ZNd 8jpiNBjWzPy6IoNxaXPZlp7RMFlXnYbsqS/Ti0id7h2+T6SMcDsce2HDmgWcdfvDo02q TW8t33QlthgHdE+BT3wyByToiPPiBjSQjNBhIeFcZ7apyXBVsXVqR5Ay6wW4TOvwSloj jdG6pXdTTOmXJc5Jf02qP2thJMUXWzlBZbg4cYFBJKxyN2jMFM0zSg11mkLMbVtVYVSE pjaA== X-Gm-Message-State: AOAM533k0HI95AvcH1jQLjWfX/lBFCfPQ1QCYDHUF8zacq2RglUa0Jla oVjXUopj5Knp6mfG6S5enpXqAw== X-Google-Smtp-Source: ABdhPJw4BLL5Yn4P0JiAebR1HlqACpRsi83Tuc5vArRTpPHSHMnS0jRcMj9vnWN/D0VLd8H8S3aGnA== X-Received: by 2002:a05:6512:2391:b0:473:ac1e:f2ce with SMTP id c17-20020a056512239100b00473ac1ef2cemr12881841lfv.297.1652704104659; Mon, 16 May 2022 05:28:24 -0700 (PDT) Received: from [172.16.11.74] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id 27-20020ac25f5b000000b0047255d210desm1296280lfz.13.2022.05.16.05.28.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 May 2022 05:28:24 -0700 (PDT) Message-ID: <9bd2db3e-2955-66ba-574e-7976bdd95a8e@rasmusvillemoes.dk> Date: Mon, 16 May 2022 14:28:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH v2 07/21] cfi: Add type helper macros Content-Language: en-US To: Kees Cook , Sami Tolvanen Cc: linux-kernel@vger.kernel.org, Josh Poimboeuf , Peter Zijlstra , x86@kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-8-samitolvanen@google.com> <202205141447.E3B5A29@keescook> From: Rasmus Villemoes In-Reply-To: <202205141447.E3B5A29@keescook> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220516_052826_918217_AD12EBBC X-CRM114-Status: GOOD ( 19.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 14/05/2022 23.49, Kees Cook wrote: > On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote: >> With CONFIG_CFI_CLANG, assembly functions called indirectly >> from C code must be annotated with type identifiers to pass CFI >> checking. The compiler emits a __kcfi_typeid_ symbol for >> each address-taken function declaration in C, which contains the >> expected type identifier. Add typed versions of SYM_FUNC_START and >> SYM_FUNC_START_ALIAS, which emit the type identifier before the >> function. >> >> Signed-off-by: Sami Tolvanen > > And the reason to not make this change universally (i.e. directly in > SYM_FUNC_START) is to minimize how many of these symbol annotations get > emitted? (And to more directly indicate which asm is called indirectly?) > > What happens if an asm function is called indirectly and it doesn't have > this annotation? Presumably that's a fail. I'm also interested in how this works at the asm/linker level. I assume that the .o file generated from the asm input has __kcfi_typeid_ as an undefined symbol; the compiler emits that symbol as an absolute one upon taking the address of , and the linker then has the info it needs to patch things up. But what then happens if we have some function implemented in assembly which for whatever .config reason never has its address taken in any .c translation unit that gets linked in? Does the __kcfi_typeid_ symbol silently resolve to 0, or does the link fail? I can't really imagine the compiler emitting __kcfi_typeid_ symbols for each and every function it sees merely declared in some header. Two different .c files both taking the address of should of course emit the same value for __kcfi_typeid_. Is there any sanity check anywhere that that's actually the case? Can we please have some objdump/readelf output from some .o files involved here? Rasmus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel