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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 4C733C4332D for ; Fri, 15 Jan 2021 12:34:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1EF7E2371F for ; Fri, 15 Jan 2021 12:34:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387541AbhAOMez (ORCPT ); Fri, 15 Jan 2021 07:34:55 -0500 Received: from foss.arm.com ([217.140.110.172]:38960 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387500AbhAOMei (ORCPT ); Fri, 15 Jan 2021 07:34:38 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 986DEED1; Fri, 15 Jan 2021 04:33:52 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.41.13]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD5D03F70D; Fri, 15 Jan 2021 04:33:50 -0800 (PST) Date: Fri, 15 Jan 2021 12:33:47 +0000 From: Mark Rutland To: "Madhavan T. Venkataraman" Cc: linux-arm-kernel@lists.infradead.org, Mark Brown , Julien Thierry , jpoimboe@redhat.com, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Live patching on ARM64 Message-ID: <20210115123347.GB39776@C02TD0UTHF1T.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 14, 2021 at 04:07:55PM -0600, Madhavan T. Venkataraman wrote: > Hi all, > > My name is Madhavan Venkataraman. Hi Madhavan, > Microsoft is very interested in Live Patching support for ARM64. > On behalf of Microsoft, I would like to contribute. > > I would like to get in touch with the people who are currently working > in this area, find out what exactly they are working on and see if they > could use an extra pair of eyes/hands with what they are working on. > > It looks like the most recent work in this area has been from the > following folks: > > Mark Brown and Mark Rutland: > Kernel changes to providing reliable stack traces. > > Julien Thierry: > Providing ARM64 support in objtool. > > Torsten Duwe: > Ftrace with regs. IIRC that's about right. I'm also trying to make arm64 patch-safe (more on that below), and there's a long tail of work there for anyone interested. > I apologize if I have missed anyone else who is working on Live Patching > for ARM64. Do let me know. > > Is there any work I can help with? Any areas that need investigation, any code > that needs to be written, any work that needs to be reviewed, any testing that > needs to done? You folks are probably super busy and would not mind an extra > hand. One general thing that I believe we'll need to do is to rework code to be patch-safe (which implies being noinstr-safe too). For example, we'll need to rework the instruction patching code such that this cannot end up patching itself (or anything that has instrumented it) in an unsafe way. Once we have objtool it should be possible to identify those cases automatically. Currently I'm aware that we'll need to do something in at least the following places: * The entry code -- I'm currently chipping away at this. * The insn framework (which is used by some patching code), since the bulk of it lives in arch/arm64/kernel/insn.c and isn't marked noinstr. We can probably shift the bulk of the aarch64_insn_gen_*() and aarch64_get_*() helpers into a header as __always_inline functions, which would allow them to be used in noinstr code. As those are typically invoked with a number of constant arguments that the compiler can fold, this /might/ work out as an optimization if the compiler can elide the error paths. * The alternatives code, since we call instrumentable and patchable functions between updating instructions and performing all the necessary maintenance. There are a number of cases within __apply_alternatives(), e.g. - test_bit() - cpus_have_cap() - pr_info_once() - lm_alias() - alt_cb, if the callback is not marked as noinstr, or if it calls instrumentable code (e.g. from the insn framework). - clean_dcache_range_nopatch(), as read_sanitised_ftr_reg() and related code can be instrumented. This might need some underlying rework elsewhere (e.g. in the cpufeature code, or atomics framework). So on the kernel side, maybe a first step would be to try to headerize the insn generation code as __always_inline, and see whether that looks ok? With that out of the way it'd be a bit easier to rework patching code depending on the insn framework. I'm not sure about the objtool side, so I'll leave that to Julien and co to answer. Thanks, Mark. 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 4644DC433E0 for ; Fri, 15 Jan 2021 12:35:33 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0D1CF2339D for ; Fri, 15 Jan 2021 12:35:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D1CF2339D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=zXtyw2/BmAhVzrlN+HDcwFfoo9nzLDtvR+0uP+Sp5Kc=; b=qnkATuxRlGgFLQaD/2LOaE/CN /iLVscOvlmSVb5Gf5+P/POQULqdgSGAPdy6cyGNYjRzmFD2c88EhTm7obt7D4SvZ0f31ntJ9ClGcQ qq4+nPhNJ3yEvmcuz43KY8Ic+06KsFiXh7rOkR02Tz8Fr47ZXgQACi6FG3uDONOkS5iGLkr7MbmGO KR3qfnffvjzy+FfPgN3NlzYUwKuoQBHKjtHnZVyNkUpNvnmtuYm/KfLasSnVMD0zVnsdfnEd+XkhQ L6+AFWgeGSdskiuDDdQrIq7sMf2q+jLhu8Fdmz+Wh2+LUptdzOQH7qDTFfZBXg6RJY2hM8epSC4/z TtOVKTsnQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0OIi-0004xo-1D; Fri, 15 Jan 2021 12:34:00 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0OIe-0004wo-Jh for linux-arm-kernel@lists.infradead.org; Fri, 15 Jan 2021 12:33:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 986DEED1; Fri, 15 Jan 2021 04:33:52 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.41.13]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD5D03F70D; Fri, 15 Jan 2021 04:33:50 -0800 (PST) Date: Fri, 15 Jan 2021 12:33:47 +0000 From: Mark Rutland To: "Madhavan T. Venkataraman" Subject: Re: Live patching on ARM64 Message-ID: <20210115123347.GB39776@C02TD0UTHF1T.local> References: 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-20210115_073356_766819_CFD29F68 X-CRM114-Status: GOOD ( 26.05 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Julien Thierry , linux-kernel@vger.kernel.org, Mark Brown , jpoimboe@redhat.com, live-patching@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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, Jan 14, 2021 at 04:07:55PM -0600, Madhavan T. Venkataraman wrote: > Hi all, > > My name is Madhavan Venkataraman. Hi Madhavan, > Microsoft is very interested in Live Patching support for ARM64. > On behalf of Microsoft, I would like to contribute. > > I would like to get in touch with the people who are currently working > in this area, find out what exactly they are working on and see if they > could use an extra pair of eyes/hands with what they are working on. > > It looks like the most recent work in this area has been from the > following folks: > > Mark Brown and Mark Rutland: > Kernel changes to providing reliable stack traces. > > Julien Thierry: > Providing ARM64 support in objtool. > > Torsten Duwe: > Ftrace with regs. IIRC that's about right. I'm also trying to make arm64 patch-safe (more on that below), and there's a long tail of work there for anyone interested. > I apologize if I have missed anyone else who is working on Live Patching > for ARM64. Do let me know. > > Is there any work I can help with? Any areas that need investigation, any code > that needs to be written, any work that needs to be reviewed, any testing that > needs to done? You folks are probably super busy and would not mind an extra > hand. One general thing that I believe we'll need to do is to rework code to be patch-safe (which implies being noinstr-safe too). For example, we'll need to rework the instruction patching code such that this cannot end up patching itself (or anything that has instrumented it) in an unsafe way. Once we have objtool it should be possible to identify those cases automatically. Currently I'm aware that we'll need to do something in at least the following places: * The entry code -- I'm currently chipping away at this. * The insn framework (which is used by some patching code), since the bulk of it lives in arch/arm64/kernel/insn.c and isn't marked noinstr. We can probably shift the bulk of the aarch64_insn_gen_*() and aarch64_get_*() helpers into a header as __always_inline functions, which would allow them to be used in noinstr code. As those are typically invoked with a number of constant arguments that the compiler can fold, this /might/ work out as an optimization if the compiler can elide the error paths. * The alternatives code, since we call instrumentable and patchable functions between updating instructions and performing all the necessary maintenance. There are a number of cases within __apply_alternatives(), e.g. - test_bit() - cpus_have_cap() - pr_info_once() - lm_alias() - alt_cb, if the callback is not marked as noinstr, or if it calls instrumentable code (e.g. from the insn framework). - clean_dcache_range_nopatch(), as read_sanitised_ftr_reg() and related code can be instrumented. This might need some underlying rework elsewhere (e.g. in the cpufeature code, or atomics framework). So on the kernel side, maybe a first step would be to try to headerize the insn generation code as __always_inline, and see whether that looks ok? With that out of the way it'd be a bit easier to rework patching code depending on the insn framework. I'm not sure about the objtool side, so I'll leave that to Julien and co to answer. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel