From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCHv2] arm64/kvm: Prohibit guest LOR accesses Date: Wed, 14 Feb 2018 11:52:06 +0100 Message-ID: <20180214105206.GM23189@cbox> References: <20180213133923.40002-1-mark.rutland@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20180213133923.40002-1-mark.rutland@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Mark Rutland Cc: Vladimir Murzin , Marc Zyngier , Catalin Marinas , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org List-Id: kvmarm@lists.cs.columbia.edu On Tue, Feb 13, 2018 at 01:39:23PM +0000, Mark Rutland wrote: > We don't currently limit guest accesses to the LOR registers, which we > neither virtualize nor context-switch. As such, guests are provided with > unusable information/controls, and are not isolated from each other (or > the host). > > To prevent these issues, we can trap register accesses and present the > illusion LORegions are unssupported by the CPU. To do this, we mask > ID_AA64MMFR1.LO, and set HCR_EL2.TLOR to trap accesses to the following > registers: > > * LORC_EL1 > * LOREA_EL1 > * LORID_EL1 > * LORN_EL1 > * LORSA_EL1 > > ... when trapped, we inject an UNDEFINED exception to EL1, simulating > their non-existence. > > As noted in D7.2.67, when no LORegions are implemented, LoadLOAcquire > and StoreLORelease must behave as LoadAcquire and StoreRelease > respectively. We can ensure this by clearing LORC_EL1.EN when a CPU's > EL2 is first initialized, as the host kernel will not modify this. > > Signed-off-by: Mark Rutland > Cc: Vladimir Murzin > Cc: Catalin Marinas > Cc: Christoffer Dall > Cc: Marc Zyngier > Cc: Will Deacon > Cc: kvmarm@lists.cs.columbia.edu Applied, thanks. -Christoffer