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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86o7pty3dm.wl-maz@kernel.org>
Date:   Thu, 16 Feb 2023 16:35:49 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Kristina Martsenko <kristina.martsenko@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
        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>,
        Zenghui Yu <yuzenghui@...wei.com>,
        Mark Rutland <mark.rutland@....com>,
        Mark Brown <broonie@...nel.org>,
        Luis Machado <luis.machado@....com>,
        Vladimir Murzin <vladimir.murzin@....com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/10] KVM: arm64: switch HCRX_EL2 between host and guest

On Thu, 16 Feb 2023 16:00:05 +0000,
Kristina Martsenko <kristina.martsenko@....com> wrote:
> 
> Switch the HCRX_EL2 register between host and guest configurations, in
> order to enable different features in the host and guest.
> 
> Note that the guest flags are only set if all CPUs have HCRX_EL2.
> Asymmetric systems where only some CPUs have HCRX_EL2 are not supported
> and will result in guests running with the host flags set (and a "SANITY
> CHECK" warning printed for the host).
> 
> After this change, SMPME is no longer set for guests, which should have
> no effect as SME is currently disabled for guests.

Why not preserve the behaviour by propagating the flag into the guest
setup?

> 
> Signed-off-by: Kristina Martsenko <kristina.martsenko@....com>
> ---
> 
> I wasn't sure what to do about asymmetric systems. It seems a bit
> fragile, maybe someone has a better idea?

I would simply prevent these CPUs from booting if they come after a
primary CPU that has the feature. These hypothetical asymmetric setups
put a huge complexity on the kernel, and I'm worried that we're just
giving implementers too much freedom.

If someone comes up with that sort of stuff, they can write the
patches themselves... Or do you know of any braindead setup involving
an asymmetric FEAT_HCX implementation?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ