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 8F4FDC636CD for ; Fri, 10 Feb 2023 11:57:11 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9ZEYkh8sYNOHKndwaCXdfzbAwAP6P4+T/auC8cc/xyE=; b=2DcXfRq+BHuRiZ j100MIHoFrU8VEVffu2+jXjyT/+c9DUVPRBsFoFckDh2g1z79mUkYHJKu3lzMRhlrMPPI4kxD+T5I i7KFw6+S17wEu+EPw01Df904VaEkIoXJlOd7nwQwddB+Fxzf3McKqpfY2PLKV/ub7p5Si8AJjkTYw /nk6gW3QYKRaqz0DfchMdXjI2SiW255lb+wV2VO5wzdm5pjJIWJeUg/ntkchamxCpKkPHA81anZR4 l1CJZP4hOjFyp8bzQKUSSNXnBrjxbjmygZy2qQ1G7hz8YhEIKgXe4QX+RBDXLtzLmflAH038l+K3G rK5AQOEiwAIHObIZGMrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQS0k-005ZMg-1V; Fri, 10 Feb 2023 11:56:14 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQS0d-005ZJf-DI for linux-arm-kernel@lists.infradead.org; Fri, 10 Feb 2023 11:56:10 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 881EEB824D8; Fri, 10 Feb 2023 11:56:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 303FAC433D2; Fri, 10 Feb 2023 11:56:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676030164; bh=rXnN4wcztfkFznbCKp8IU3R9EqcR49j22N/PE/ZUBus=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fi5mz1zMW2G/8QRdrOmQMZTpLlqRrx6WPrLbGMwbfvVVSw783dcPms3oln84mdu/u sDIvkv8O1T+2Q44yjk79dz8Mrf784lC23xctynuORLhEN/fojZs1otZCoxSP6C4gQn pH/V/1ejdS4oeCBXl9WuMWGlWqLV3muMy2pDcuXxDoexHqm3w/tHzJrRpfER2zjqkt MLR8RSLdMH/hQUbUXaJx5LukPohtp92Z6CMvxQpK891fG4eRaoGTWvSuRa4RymCVX2 V65iU9ffDSERB6ql2OoEUfVbBIunLA2dinKzkKA8OSwWUPrN/FIRvrlCQ1ZqmDukaT Z2FJmAzhpp4aQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pQS0X-009GId-VW; Fri, 10 Feb 2023 11:56:02 +0000 Date: Fri, 10 Feb 2023 11:56:01 +0000 Message-ID: <86a61lzqcu.wl-maz@kernel.org> From: Marc Zyngier To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Catalin Marinas , Mark Rutland , Peter Zijlstra , Quentin Perret , Kees Cook Subject: Re: [RFC PATCH] arm64: Move HYP text out of kernel mapping In-Reply-To: <20230210100006.1161696-1-ardb@kernel.org> References: <20230210100006.1161696-1-ardb@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ardb@kernel.org, linux-arm-kernel@lists.infradead.org, will@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com, peterz@infradead.org, qperret@google.com, keescook@chromium.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230210_035607_779776_A30F30C9 X-CRM114-Status: GOOD ( 32.91 ) 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 Fri, 10 Feb 2023 10:00:06 +0000, Ard Biesheuvel wrote: > > The HYP text region contains the code that the hypervisor runs when > running KVM at EL2. This code is never called by the kernel running at > EL1, regardless of whether it booted at EL2 or whether it runs KVM in > VHE mode or not. > > This means that this code has no need to be mapped with executable > permissions in the kernel's address space, and should therefore be > moved out of it. That way, any gadgets that may exist in this code are > no longer exploitable at the kernel's exception level (speculative or > otherwise). I *really* like this, as it also means that we get simply free this code when running VHE or that EL2 isn't available at all (in a guest). > > Cc: Marc Zyngier > Cc: Will Deacon > Cc: Catalin Marinas > Cc: Mark Rutland > Cc: Peter Zijlstra > Cc: Quentin Perret > Cc: Kees Cook > Signed-off-by: Ard Biesheuvel > --- > arch/arm64/kernel/vmlinux.lds.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > This change currently results in the following warnings*: > > (kvm_arm_pmu_available) can't patch jump_label at __kvm_nvhe___kvm_vcpu_run+0x16c/0x570 > (kvm_arm_pmu_available) can't patch jump_label at __kvm_nvhe___deactivate_traps+0x40/0x144 > (kvm_protected_mode_initialized) can't patch jump_label at __kvm_nvhe___kvm_vcpu_run+0x380/0x570 > (kvm_protected_mode_initialized) can't patch jump_label at __kvm_nvhe_hyp_panic+0x54/0xf8 > (kvm_protected_mode_initialized) can't patch jump_label at __kvm_nvhe___kvm_tlb_flush_vmid_ipa+0xc0/0x1b8 > (kvm_protected_mode_initialized) can't patch jump_label at __kvm_nvhe___kvm_tlb_flush_vmid+0x84/0x150 > (kvm_protected_mode_initialized) can't patch jump_label at __kvm_nvhe___kvm_flush_cpu_context+0x84/0x150 > (kvm_protected_mode_initialized) can't patch jump_label at __kvm_nvhe_handle_trap+0x80/0x128 > > The warnings are due to the fact that the jump label code refuses to > patch sections that are not kernel text. > > So the questions are: > a) Mark pointed out off-list that he has been getting rid of static keys > in favor of alternatives in the arch code, as those are guaranteed to > be patched only once. Should we try to get rid of these as well? The question is whether we can use these alternatives at such a late point in the boot process. Today, we are done with the alternatives as soon as all the early CPUs are up. > b) These look like they are set only once and never turned off again. > The pKVM one is definitely only set at boot time, but I couldn't > figure out whether the same applies to the PMU one? Yes, the PMU is in the same bag. As soon as we have found an architectural PMU *and* that the driver has been registered, we're good. But we cannot just rely on the CPU ID regs as the perf backend could fail to register. In both cases, this would be very late patching. Mark? Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel