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 8E504150996; Fri, 6 Sep 2024 07:47:22 +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=1725608842; cv=none; b=QYCQXFsnTd4Vaz75PfY9OqqGHQIAG9iB331O6jWP7Bk9uJ+jwaFSq0wmqvj710Pc6tcY223QvCTyFpS23Cwu1908/PVPxpT5UcJPc3ZeQcbNgu74M3Ps2zKv4EQHyIBe3t5JtLu+Ut30caTvXnNTc+Nk1NYF5DbW6SgmZfM+k9o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725608842; c=relaxed/simple; bh=hu+JAGtJySQgKbao5D33RzcckbHiifZyAyWscrsM0tI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=cjCFfpYkhncf/Etd6kxw7C+zGb6ROoCWgHr4l2MpW2bFQ/wNsZocOpKbeYW/3SNXNCAQqW4AMYT4f9ZVeOOAj+VgvAAbdrVBVz389xUefGN1GKwlhu5WhZ4i9Pfp0WK+A5UvwZDoFqHEQPSCpLato8ZT/vPInADT8+wqQr+dB0o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tBpOHeZ4; 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="tBpOHeZ4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2545C4CEC6; Fri, 6 Sep 2024 07:47:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725608842; bh=hu+JAGtJySQgKbao5D33RzcckbHiifZyAyWscrsM0tI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tBpOHeZ4d8C22dDll+yR2/qAwMd86ivVz57ukXTFEoPhHBrwx2GM81zkMtrv0cC+1 JSnB+kDXSBp5J/jT0B0xhxXHi7gsjNWkLedG/1iICHvTIQLmI/ZsBjPgLYhUysvx4X wik+C+g4c+KTdnQix2z9eUBJHnS9HyCZkhx6MB4zYyP9lxKq7kCtYPncbNu/E8P+iH jlhm42VvMlTQeALFxHGFgPjIUn3RcfBYwsT6fAE+u0K9tHQdicdcjXvv/iwST4pJ32 r8SBh4hLKOPZh+A2laHn09kUOXihGTT6EDG6S+gBTQTrjkzz5Be4jDkO+ylN2iaEOo 3p/SfULt/zuBQ== 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 1smTgc-00ADNL-KF; Fri, 06 Sep 2024 08:47:19 +0100 Date: Fri, 06 Sep 2024 08:47:18 +0100 Message-ID: <86frqdusu1.wl-maz@kernel.org> From: Marc Zyngier To: Qixiang Xu 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> <86mskmv7ts.wl-maz@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/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 Fri, 06 Sep 2024 08:19:07 +0100, Qixiang Xu wrote: > > Marc, > > Thanks for your reply. > > > 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? > > The reason for adding this is to make debugging nvhe hyp code easier. > Otherwise, we would need to calculate the offset every time. > Do you have any better suggestions for the debugging? You already have facilities to dump stacktraces from the HYP code, and Vincent's tracing infrastructure is available on the list (feel free to review it!). And as I said, I'm not opposed to disabling the randomisation with a command-line option. I oppose to using 'nokaslr' for this, as it changes the existing behaviour. > > This is also not disabling the whole thing, since we still do the > > indirect vector dance. > > I'm not sure if my understanding is correct, but based on > the hyp_map_vectors function, the address of the indirect vector > is only related to __io_map_base and is not random. Of course it isn't random. It is in the idmap, since VBAR_EL2 can be leaked to EL1, and that's the whole point that the only thing you can leak isn't random. But when you decide to disable randomisation, you might as well disable the indirection, which adds extra complexity for no benefit. You may want to read [1] to get the context of what you are changing. M. [1] https://lore.kernel.org/all/20180314165049.30105-1-marc.zyngier@arm.com/ -- Without deviation from the norm, progress is not possible.