lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 9 Jan 2020 17:46:22 +0000 From: Andrew Murray <andrew.murray@....com> To: Mark Rutland <mark.rutland@....com> Cc: Marc Zyngier <maz@...nel.org>, kvm@...r.kernel.org, Catalin Marinas <catalin.marinas@....com>, linux-kernel@...r.kernel.org, Sudeep Holla <sudeep.holla@....com>, kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH v2 11/18] KVM: arm64: don't trap Statistical Profiling controls to EL2 On Thu, Jan 09, 2020 at 05:42:51PM +0000, Mark Rutland wrote: > Hi Andrew, > > On Thu, Jan 09, 2020 at 05:25:12PM +0000, Andrew Murray wrote: > > On Mon, Dec 23, 2019 at 12:10:42PM +0000, Andrew Murray wrote: > > > On Mon, Dec 23, 2019 at 12:05:12PM +0000, Marc Zyngier wrote: > > > > On 2019-12-23 11:56, Andrew Murray wrote: > > > > > My original concern in the cover letter was in how to prevent > > > > > the guest from attempting to use these registers in the first > > > > > place - I think the solution I was looking for is to > > > > > trap-and-emulate ID_AA64DFR0_EL1 such that the PMSVer bits > > > > > indicate that SPE is not emulated. > > > > > > > > That, and active trapping of the SPE system registers resulting in injection > > > > of an UNDEF into the offending guest. > > > > > > Yes that's no problem. > > > > The spec says that 'direct access to [these registers] are UNDEFINED' - is it > > not more correct to handle this with trap_raz_wi than an undefined instruction? > > The term UNDEFINED specifically means treated as an undefined > instruction. The Glossary in ARM DDI 0487E.a says for UNDEFINED: > > | Indicates cases where an attempt to execute a particular encoding bit > | pattern generates an exception, that is taken to the current Exception > | level, or to the default Exception level for taking exceptions if the > | UNDEFINED encoding was executed at EL0. This applies to: > | > | * Any encoding that is not allocated to any instruction. > | > | * Any encoding that is defined as never accessible at the current > | Exception level. > | > | * Some cases where an enable, disable, or trap control means an > | encoding is not accessible at the current Exception level. > > So these should trigger an UNDEFINED exception rather than behaving as > RAZ/WI. OK thanks for the clarification - I'll leave it as an undefined instruction. Thanks, Andrew Murray > > Thanks, > Mark.
Powered by blists - more mailing lists