From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F2D3198A2A; Thu, 5 Sep 2024 08:11:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725523875; cv=none; b=WzgqS9czp+/DOP0cDt9No9q3HvK2wkD9mkggLcQWLL6SwmVsEu5rmdsL1B1lexEjkZWPN1yuL7UnVoB6+/MOKjxvR0xrnSbjzKYVSJLcWa5W+3bWrDIhHH1L74ZQ6RfkFSud11f+ECxEXD3MiegUnMUHOAPXePiIq43Du6obTBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725523875; c=relaxed/simple; bh=eUD04zlafn+wiXqeYlufuTdlxuxhQPQinUvJdRHnqy0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=qLYYqQC0Um8SmIXDyQb3n5swLiFoCYKDFCMTKln4ZnJ68tXmTh0PulvKqsY5wjVrszd1I09ZgBfmDNDfi/063beTLkKZDvhQze6a8XHNV+8+K2pwilwJhwWeFHOPDI/f6WKgWNmbxdn8svLZzU9+ik7MTnOLbY4KnwfwXsYF5mk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Yto2ZNSi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yto2ZNSi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 824FBC4CEC4; Thu, 5 Sep 2024 08:11:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725523874; bh=eUD04zlafn+wiXqeYlufuTdlxuxhQPQinUvJdRHnqy0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Yto2ZNSiJbYgqNuZgAF8BVoVKlFLn3SWpT+2IdwIHG10gmH6rRxOGOuaBuFoLsKQy EiQghyh9NOAHk52FjbzPgUzXdj24+OFD+CW916ZIvzs/8VFrSlivW2e3qycekYeIvK EjiptqE66af0nt322Gd978d2WHAPl36ZZPoVFP6THed3CRxPFnS6+XYt0rY5QhgPSl 2jR+ENyHGjFn4N4D4dF003yLHrav7DcMhKJqOHTVErWv/S2hVyuXE5Igu5FJ5UJtgG MeoN2gS4Htj26o5FkszjqwycGI5gHpHBKlHv4yLAvLUFvzpS1d9/wzBeUq/GQ1ULnR lGnSccPjqXsWA== 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 1sm7aB-009rdr-Jj; Thu, 05 Sep 2024 09:11:11 +0100 Date: Thu, 05 Sep 2024 09:11:11 +0100 Message-ID: <86mskmv7ts.wl-maz@kernel.org> From: Marc Zyngier To: qixiang.xu@outlook.com Cc: oliver.upton@linux.dev, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] KVM: arm64: Make nVHE ASLR conditional on nokaslr In-Reply-To: References: <20240905061659.3410362-1-qixiang.xu@outlook.com> <20240905063026.3411766-1-qixiang.xu@outlook.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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: qixiang.xu@outlook.com, oliver.upton@linux.dev, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 05 Sep 2024 07:30:26 +0100, qixiang.xu@outlook.com wrote: > > From: Qxiang Xu > > The random tag of hyp VA is determined by the `CONFIG_RANDOMIZE_BASE` > option, so even if `nokaslr` is set in the cmdline, KASLR cannot be > disabled for hyp VA. To align with kernel behavior, disable KASLR if > the kernel cmdline includes `nokaslr`. > > Link: https://lore.kernel.org/r/20240905061659.3410362-1-qixiang.xu@outlook.com I get a 404. > Signed-off-by: Qxiang Xu > --- > arch/arm64/kvm/va_layout.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c > index 91b22a014610..bebb4b1ddc82 100644 > --- a/arch/arm64/kvm/va_layout.c > +++ b/arch/arm64/kvm/va_layout.c > @@ -72,7 +72,7 @@ __init void kvm_compute_layout(void) > va_mask = GENMASK_ULL(tag_lsb - 1, 0); > tag_val = hyp_va_msb; > > - if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && tag_lsb != (vabits_actual - 1)) { > + if (kaslr_enabled() && tag_lsb != (vabits_actual - 1)) { > /* We have some free bits to insert a random tag. */ > tag_val |= get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb); > } This is a change in behaviour that would leave the 2 implementations affected by Spectre-v3a unmitigated and leaking information to *guests*, while they would have been safe until this change. Is this what we really want to do? This is also not disabling the whole thing, since we still do the indirect vector dance. So while I'm not opposed to having an option that disables the randomisation, it has to match two requirements: - it has to be a *new* option -- changing an existing behaviour is not acceptable, - it has to disable both the VA alteration and the vector indirection. Thanks, M. -- Without deviation from the norm, progress is not possible.