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 48C3FC77B6E for ; Thu, 13 Apr 2023 17:05:10 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=OobFyAY1VeJ0Vxn2WVWhpBFF8a6koubvLhSxFKIg3bo=; b=kAa/c3xVTtFsXS 5k1oLLkfI2MWan56buwknWEIh8OV0HH/Mr2OAaSs4Jjh1dR06eVotSXLb5nYSqvfRtSSHdYOKkqG3 T+mdRO55c3SdzWurfOzGmCIO9n6Q/2n4xeuEzEq5LzWkrcnXMAnNHS4qwC3fm/4OPAIAV/zx2TBch fsKkryeaD05naqu1qu0sLZnXKvastyOnRtCRZM8p0ab0pBzYy2swaEcWRxoc1BSU0fa9gjYM99fDS jxVUdZ7hUhQLPDx4Mnrs774+02TtCppXHoPSFJ2/PiyjwR+Mh1cvTQyAmmky985pBNdkHI0R0UJyj A30cMDoEyCrcJ5hovkrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pn0Mv-006l51-1x; Thu, 13 Apr 2023 17:04:21 +0000 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pn0Mr-006l3M-1o for linux-arm-kernel@lists.infradead.org; Thu, 13 Apr 2023 17:04:19 +0000 Received: by mail-pl1-x629.google.com with SMTP id lh8so2655740plb.1 for ; Thu, 13 Apr 2023 10:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681405454; x=1683997454; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ccsEwv5oO7NDzmy7DI9h+6ldasNA+QD8FggJsRLsgZk=; b=taQlQ7g87EtETw7950+oGC++35BjVH5z2ygGlMMbTo5I7kDps9cXFqUloS7mUgBPth di55++ydNmblfUOhmk6Mf0ZCpCc0mg7Vf6yYQEQso89+hO+DKYcj2CoCTaIJIn2Ue3HO //xsWAhOf3MiEmH9CtufeOoszfiO02siNSMA9WvEfdVh/fcgRPIFebc6BJPK1WkgL3tP 87y3YtPmFMfzYiYYqk1EBz0a2F3HU71Xqg/99WsL1W85upYH9GyW5rt4Q6q7PQ2hqU9Z 1mGZ4HIyPU+it7CmDLMyrPIXqht0YEywvU8X36Fw7a9okB6fZv/g78cDMlXq5Qn95K0W G4FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681405454; x=1683997454; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ccsEwv5oO7NDzmy7DI9h+6ldasNA+QD8FggJsRLsgZk=; b=EmnpEQRj1Z7c+r/cM7HKxso2Scn6Yb4gaEQvk+ZFOpPr7x/zzLxiL6RlA5E9H9ihNy m95d3y7ESS3kbCrGrXmNqN9Hja6HYOCHtbYTo8kzgAlmXSWG2mKpZGncYlxxsd+GgBxZ X5H844VzJagG7CFDqpdCudkP4ZNy49A9yvfyyWMeSjlWdHjF43xf4jDnVmGMecEXO9f6 RhQyihBcVXkC/QwbestYpGFpL/hubLmCFJDWUEA/KoxKfdDRPwRMj4DpYKae+P425jYX pNLxczfXHYgAIUxRGUdYO2QiE007UQSneclnmWR5sf7o5mzX71rdyEll1Wc7RPqYFgiv dblQ== X-Gm-Message-State: AAQBX9fyWUme2+F40/YpCnGwpfPifOAi5ttArHW7lUU/Hef2kQDKq+e6 +ewL39M3ok16u0EadghzaaNg2w== X-Google-Smtp-Source: AKy350b5uuL0C5Q4CRc+UyiuAgC6hHLZveLsP2IeaUlDAnqKlR0imLdZbqrkBwYOC8ijNZ09PqI46Q== X-Received: by 2002:a05:6a20:66a1:b0:ea:fb53:4cb1 with SMTP id o33-20020a056a2066a100b000eafb534cb1mr2743042pzh.41.1681405453405; Thu, 13 Apr 2023 10:04:13 -0700 (PDT) Received: from google.com ([2620:15c:2d1:203:fde9:d34:5ee3:d2e8]) by smtp.gmail.com with ESMTPSA id l15-20020a654c4f000000b0051a3c744256sm1618060pgr.93.2023.04.13.10.04.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Apr 2023 10:04:12 -0700 (PDT) Date: Thu, 13 Apr 2023 10:04:05 -0700 From: Nick Desaulniers To: Mark Rutland Cc: madvenka@linux.microsoft.com, jpoimboe@redhat.com, peterz@infradead.org, chenzhongjin@huawei.com, broonie@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jamorris@linux.microsoft.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, linux-toolchains@vger.kernel.org Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Message-ID: References: <0337266cf19f4c98388e3f6d09f590d9de258dc7> <20230202074036.507249-1-madvenka@linux.microsoft.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230413_100417_596941_167635A6 X-CRM114-Status: GOOD ( 35.89 ) 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 Thu, Mar 23, 2023 at 05:17:14PM +0000, Mark Rutland wrote: > Hi Madhavan, > > At a high-level, I think this still falls afoul of our desire to not reverse > engineer control flow from the binary, and so I do not think this is the right > approach. I've expanded a bit on that below. > > I do think it would be nice to have *some* of the objtool changes, as I do > think we will want to use objtool for some things in future (e.g. some > build-time binary patching such as table sorting). > > > Problem > > ======= > > > > Objtool is complex and highly architecture-dependent. There are a lot of > > different checks in objtool that all of the code in the kernel must pass > > before livepatch can be enabled. If a check fails, it must be corrected > > before we can proceed. Sometimes, the kernel code needs to be fixed. > > Sometimes, it is a compiler bug that needs to be fixed. The challenge is > > also to prove that all the work is complete for an architecture. > > > > As such, it presents a great challenge to enable livepatch for an > > architecture. > > There's a more fundamental issue here in that objtool has to reverse-engineer > control flow, and so even if the kernel code and compiled code generation is > *perfect*, it's possible that objtool won't recognise the structure of the > generated code, and won't be able to reverse-engineer the correct control flow. > > We've seen issues where objtool didn't understand jump tables, so support for > that got disabled on x86. A key objection from the arm64 side is that we don't > want to disable compile code generation strategies like this. Further, as > compiles evolve, their code generation strategies will change, and it's likely > there will be other cases that crop up. This is inherently fragile. > > The key objections from the arm64 side is that we don't want to > reverse-engineer details from the binary, as this is complex, fragile, and > unstable. This is why we've previously suggested that we should work with > compiler folk to get what we need. > This still requires reverse-engineering the forward-edge control flow in order > to compute those offets, so the same objections apply with this approach. I do > not think this is the right approach. > > I would *strongly* prefer that we work with compiler folk to get the > information that we need. IDK if it's relevant here, but I did see a commit go by to LLVM that seemed to include such info in a custom ELF section (for the purposes of improving fuzzing, IIUC). Maybe such an encoding scheme could be tested to see if it's reliable or usable? - https://github.com/llvm/llvm-project/commit/3e52c0926c22575d918e7ca8369522b986635cd3 - https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-control-flow > > [...] > > > FWIW, I have also compared the CFI I am generating with DWARF > > information that the compiler generates. The CFIs match a > > 100% for Clang. In the case of gcc, the comparison fails > > in 1.7% of the cases. I have analyzed those cases and found > > the DWARF information generated by gcc is incorrect. The > > ORC generated by my Objtool is correct. > > > Have you reported this to the GCC folk, and can you give any examples? > I'm sure they would be interested in fixing this, regardless of whether we end > up using it. Yeah, at least a bug report is good. "See something, say something." _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel