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 0CAD0C433F5 for ; Mon, 14 Feb 2022 14:08:23 +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=tj74P3wh0KUP1juN05BwYYoy0XABENI9Z5xwxXKWHwM=; b=U1BQ0jLgFpxA0U dfPTApRjP5XkjT7aQCFQ6zoRaWwPxT53f/79Zb/1oHPZDBGhvCD+h/JeLDL63dP3BiL5aLnUKa3V4 ukGhq0uzWElyj6hlusuICGYrVJC+QiVaLP94ndYSMB0F1ijz0R4WGB4zYjbLWv3Zs0bt8k9Vd28jK CFXczqd2rdKLUflacXdzvAgP10dtwcQFbieZCCoh26HPMoQE2guXJNCdL76isMRVNZID1o+0eKBhX J1M6AGMXkTrqegkRxHXxEPdl46eSbOiH/jtM9kjt+1Vdi5J4f1mh3JeY6A/SUALXMUwEwE1/4zixY 0ZUkOh/9eq7BzOoOBxow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJc0D-00FaEn-7Q; Mon, 14 Feb 2022 14:06:53 +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 1nJc07-00FaCu-FC for linux-arm-kernel@lists.infradead.org; Mon, 14 Feb 2022 14:06:49 +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 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 Cc: will@kernel.org, qperret@google.com, tabba@google.com, surenb@google.com, kernel-team@android.com, Catalin Marinas , James Morse , Alexandru Elisei , Suzuki K Poulose , Ard Biesheuvel , Mark Rutland , Pasha Tatashin , Joey Gouly , Peter Collingbourne , Andrew Scull , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220214_060647_833811_DAE366DE X-CRM114-Status: GOOD ( 32.82 ) 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, 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel