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=-14.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 F23DDC433DB for ; Thu, 28 Jan 2021 22:11:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B5ABB64DF2 for ; Thu, 28 Jan 2021 22:11:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229872AbhA1WLg (ORCPT ); Thu, 28 Jan 2021 17:11:36 -0500 Received: from linux.microsoft.com ([13.77.154.182]:34908 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229677AbhA1WLe (ORCPT ); Thu, 28 Jan 2021 17:11:34 -0500 Received: from [192.168.254.32] (unknown [47.187.219.45]) by linux.microsoft.com (Postfix) with ESMTPSA id 7F77920B7192; Thu, 28 Jan 2021 14:10:52 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7F77920B7192 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1611871853; bh=ZA2oSM80w+RdJ/gENbHPlEraVHFQ5GUGuDOI84otWqQ=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=b1XGVIJ11p8YrFEjhTOOsWPkgVJ1pwfcR9jZ+MllQtZMHIWyYefW7DKgPJatPai+7 Dz7hbE72mu7+23aHXEWklEXI7+cnEwZ1vcsBxJ9nq7MlZTar2idPNvNO9c86/AYmH4 78ogAZo3+o5tEXQX2VNOWZoF16HDXD/bYTvewRCs= From: "Madhavan T. Venkataraman" Subject: Re: [RFC PATCH 00/17] objtool: add base support for arm64 To: Mark Brown , Mark Rutland , Julien Thierry , Josh Poimboeuf Cc: Ard Biesheuvel , Michal Marek , Peter Zijlstra , Catalin Marinas , Masahiro Yamada , Linux Kernel Mailing List , linux-efi , linux-hardening@vger.kernel.org, live-patching@vger.kernel.org, Will Deacon , Linux ARM , Kees Cook References: <20210120173800.1660730-1-jthierry@redhat.com> <186bb660-6e70-6bbf-4e96-1894799c79ce@redhat.com> <20210121185452.fxoz4ehqfv75bdzq@treble> <20210122174342.GG6391@sirena.org.uk> Message-ID: Date: Thu, 28 Jan 2021 16:10:51 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: live-patching@vger.kernel.org Hi, I sent this suggestion to linux-arm-kernel in response to the Reliable Stacktrace RFC from Mark Brown and Mark Rutland. I am repeating it here for two reasons: - It involves objtool. - There are many more recipients in this thread that may be interested in this topic. Please let me know if this suggestion is acceptable. If it is not, please let me know why. Thanks. Also, I apologize to all of you who have received this more than once. FP and no-FP functions ===================== I have a suggestion for objtool and the unwinder for ARM64. IIUC, objtool is responsible for walking all the code paths (except unreachable and ignored ones) and making sure that every function has proper frame pointer code (prolog, epilog, etc). If a function is found to not have it, the kernel build is failed. Is this understanding correct? If so, can we take a different approach for ARM64? Instead of failing the kernel build, can we just mark the functions as: FP Functions that have proper FP code no-FP Functions that don't May be, we can add an "FP" flag in the symbol table entry for this. Then, the unwinder can check the functions it encounters in the stack trace and inform the caller if it found any no-FP functions. The caller of the unwinder can decide what he wants to do with that information. - the caller can ignore it - the caller can print the stack trace with a warning that no-FP functions were found - if the caller is livepatch, the caller can retry until the no-FP functions disappear from the stack trace. This way, we can have live patching even when some of the functions in the kernel are no-FP. Does this make any sense? Is this acceptable? What are the pitfalls? If we can do this, the unwinder could detect cases such as: - If gcc thinks that a function is a leaf function but the function contains inline assembly code that calls another function. - If a call to a function bounces through some intermediate code such as a trampoline. - etc. For specific no-FP functions, the unwinder might be able to deduce the original caller. In these cases, the stack trace would still be reliable. For all the others, the stack trace would be considered unreliable. Compiler instead of objtool =========================== If the above suggestion is acceptable, I have another suggestion. It is a lot of work for every new architecture to add frame pointer verification support in objtool. Can we get some help from the compiler? The compiler knows which C functions it generates the FP prolog and epilog for. It can mark those functions as FP. As for assembly functions, kernel developers could manually annotate functions that have proper FP code. The compiler/assembler would mark them as FP. Only a small subset of assembly functions would even have FP prolog and epilog. Is this acceptable? What are the pitfalls? This can be implemented easily for all architectures for which the compiler generates FP code. Can this be implemented using a GCC plugin? I know squat about GCC plugins. Thanks! Madhavan