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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C414C433F5 for ; Mon, 14 Feb 2022 14:06:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0096349F55; Mon, 14 Feb 2022 09:06:52 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgugCc4G-aEk; Mon, 14 Feb 2022 09:06:50 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 514B149E20; Mon, 14 Feb 2022 09:06:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3D9CB4120D for ; Mon, 14 Feb 2022 09:06:49 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+g5EzafHOB0 for ; Mon, 14 Feb 2022 09:06:48 -0500 (EST) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id CEDC840DFE for ; Mon, 14 Feb 2022 09:06:47 -0500 (EST) 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 2585DB80EA9; Mon, 14 Feb 2022 14:06:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3150C340EE; Mon, 14 Feb 2022 14:06:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644847604; bh=uUt6bE07NssIaYfZ1Wzc5VcSVVOyx1PQSGWXB+SwyNg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TTjhN2oQXHO/DPe8aypKoXxulEjAeg9gpvnVZ98AN1NH4isPapKOXXyyV6mDb7GhX SbNHHxzhjn512Ou4zrxUTjx5KIbns+zuIDsKXiDTYayIv7JPf1DVZNHVyjBOnpwlxt 5us9f6eMs18RID38v6oueyITdTp4U/j1/FtOFkWkT7K5k/03ZqjDFwFyncMlnmhQ48 3rZDqhttac1LzYsBgP2rfA6efbI6zzBKVCNe794A4bmustR8jmoBpZglhSHOJcF9R1 ZLoRcBrINUI6hx91vkfpEKw7bKZvf5oQIv0ig6WeaKAmHtYPxoTyS4yKnsASNU6xO/ T9Km6girYxw3w== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nJc02-007nP8-LH; Mon, 14 Feb 2022 14:06:42 +0000 Date: Mon, 14 Feb 2022 14:06:41 +0000 Message-ID: <87leyd4k5q.wl-maz@kernel.org> From: Marc Zyngier To: Kalesh Singh Subject: Re: [PATCH 4/7] KVM: arm64: Allocate guard pages near hyp stacks In-Reply-To: <20220210224220.4076151-5-kaleshsingh@google.com> References: <20220210224220.4076151-1-kaleshsingh@google.com> <20220210224220.4076151-5-kaleshsingh@google.com> 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/27.1 (x86_64-pc-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: kaleshsingh@google.com, will@kernel.org, qperret@google.com, tabba@google.com, surenb@google.com, kernel-team@android.com, catalin.marinas@arm.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, ardb@kernel.org, mark.rutland@arm.com, pasha.tatashin@soleen.com, joey.gouly@arm.com, pcc@google.com, ascull@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Pasha Tatashin , will@kernel.org, Peter Collingbourne , kernel-team@android.com, linux-kernel@vger.kernel.org, Joey Gouly , kvmarm@lists.cs.columbia.edu, Catalin Marinas , surenb@google.com, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, 10 Feb 2022 22:41:45 +0000, Kalesh Singh wrote: > > From: Quentin Perret > > Allocate unbacked VA space underneath each stack page to ensure stack > overflows get trapped and don't corrupt memory silently. > > The stack is aligned to twice its size (PAGE_SIZE), meaning that any > valid stack address has PAGE_SHIFT bit as 0. This allows us to easily > check for overflow in the exception entry without corrupting any GPRs. > > Signed-off-by: Quentin Perret > [ Kalesh - Update commit text and comments, > refactor, add overflow handling ] > Signed-off-by: Kalesh Singh > --- > arch/arm64/kvm/hyp/nvhe/host.S | 16 ++++++++++++++++ > arch/arm64/kvm/hyp/nvhe/setup.c | 19 ++++++++++++++++++- > arch/arm64/kvm/hyp/nvhe/switch.c | 5 +++++ > 3 files changed, 39 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S > index 3d613e721a75..78e4b612ac06 100644 > --- a/arch/arm64/kvm/hyp/nvhe/host.S > +++ b/arch/arm64/kvm/hyp/nvhe/host.S > @@ -153,6 +153,10 @@ SYM_FUNC_END(__host_hvc) > > .macro invalid_host_el2_vect > .align 7 > + > + /* Test stack overflow without corrupting GPRs */ > + test_sp_overflow PAGE_SHIFT, .L__hyp_sp_overflow\@ > + I am definitely concerned with this in a system not using pKVM (which is on average 100% of the upstream users so far! ;-). This is more or less guaranteed to do the wrong thing 50% of the times, depending on the alignment of the stack. > /* If a guest is loaded, panic out of it. */ > stp x0, x1, [sp, #-16]! > get_loaded_vcpu x0, x1 > @@ -165,6 +169,18 @@ SYM_FUNC_END(__host_hvc) > * been partially clobbered by __host_enter. > */ > b hyp_panic > + > +.L__hyp_sp_overflow\@: > + /* > + * Reset SP to the top of the stack, to allow handling the hyp_panic. > + * This corrupts the stack but is ok, since we won't be attempting > + * any unwinding here. > + */ > + ldr_this_cpu x0, kvm_init_params + NVHE_INIT_STACK_HYP_VA, x1 > + mov sp, x0 > + > + bl hyp_panic_bad_stack > + ASM_BUG() > .endm > > .macro invalid_host_el1_vect > diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c > index 99e178cf4249..114053dff228 100644 > --- a/arch/arm64/kvm/hyp/nvhe/setup.c > +++ b/arch/arm64/kvm/hyp/nvhe/setup.c > @@ -105,7 +105,24 @@ static int recreate_hyp_mappings(phys_addr_t phys, unsigned long size, > if (ret) > return ret; > > - /* Map stack pages in the 'private' VA range */ > + /* > + * Allocate 'private' VA range for stack guard pages. > + * > + * The 'private' VA range grows upward and stacks downwards, so > + * allocate the guard page first. But make sure to align the > + * stack itself with PAGE_SIZE * 2 granularity to ease overflow > + * detection in the entry assembly code. > + */ > + do { > + start = (void *)hyp_alloc_private_va_range(PAGE_SIZE); > + if (IS_ERR(start)) > + return PTR_ERR(start); > + } while (IS_ALIGNED((u64) start, PAGE_SIZE * 2)); This seems cumbersome. Can't we tweak hyp_alloc_private_va_range() to perform the required alignment? It could easily be convinced to return an address that is aligned on the size of the region, which would avoid this sort of loop. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm