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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZttDmNTX0vuddRrZ@finisterre.sirena.org.uk>
Date: Fri, 6 Sep 2024 19:02:42 +0100
From: Mark Brown <broonie@...nel.org>
To: Fuad Tabba <tabba@...gle.com>
Cc: Dave Martin <Dave.Martin@....com>, Marc Zyngier <maz@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kvmarm@...ts.linux.dev
Subject: Re: [PATCH v4 0/4] KVM: arm64: Fix underallocation of storage for
 SVE state

On Fri, Sep 06, 2024 at 05:14:09PM +0100, Fuad Tabba wrote:
> On Fri, 6 Sept 2024 at 17:10, Mark Brown <broonie@...nel.org> wrote:
> > On Fri, Sep 06, 2024 at 04:35:29PM +0100, Fuad Tabba wrote:

> > > Yes, but that's not really the issue here, unless I'm missing
> > > something else. The issue is that pKVM needs to store the host's SVE
> > > state too, to be able to restore it. So hiding non-symmetrically
> > > supported VLs for the guests shouldn't be relevant.

> > If the host kernel is also running at EL1 and it's only the hypervisor
> > running at EL2 then the hypervisor can control the VLs that the host
> > kernel is able to access?

> Yes it can. But do we want to impose limits on host VLs when running
> pKVM that might not exist without pKVM?

I mean, at the minute the host kernel will just not configure any
non-shared VLs so pKVM isn't making a difference anyway.  Even when we
add kernel mode SVE usage kernel mode FP is preemptable and schedulable
so we'd not likely want to use non-shared VLs there either.  If someone
ever felt moved to add support for using any non-shared VLs the most
likely usage would be for userspace and we'd constrain any tasks using
SVE to the cores that support their VLs similar to how we handle CPUs
with no 32 bit support.  Hopefully the scheduler would cope well with
that.

> Although AFAIK, such hardware doesn't exist in practice, the reason we
> went down this rabbit hole from the beginning was to ensure that we
> wouldn't run into problems if it were to happen.

Yes, it's not an issue with any presently known hardware - the issue is
leaving nasty surprises should someone build it rather than anything
immediately practical.  Ideally they won't.

My general feeling is that it would have been perfectly fine for pKVM to
enforce what the host kernel wants to do anyway, if we ever do add
support for using asymmetric VLs and care about doing so on a system
running pKVM then dealing with pKVM imposed limits at that time seems
more than reasonable.  It probably wouldn't be the largest part of the
work.  Equally we now have the code so we may as well use it?  It's not
imposing huge overheads.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists