linux-kernel - Re: [PATCH 1/2] arm64/sme: Restore SMCR on exit from suspend

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: <65973ce3-a316-40a4-bad4-fbc99bccff12@sirena.org.uk>
Date: Tue, 30 Jan 2024 12:42:13 +0000
From: Mark Brown <broonie@...nel.org>
To: Dave Martin <Dave.Martin@....com>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Jackson Cooper-Driver <Jackson.Cooper-Driver@....com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] arm64/sme: Restore SMCR on exit from suspend

On Tue, Jan 30, 2024 at 10:53:42AM +0000, Dave Martin wrote:
> On Tue, Jan 30, 2024 at 12:02:48AM +0000, Mark Brown wrote:

Sorry, didn't see these bits due to the large block of quoted text.

> > +	if (system_supports_fa64())
> > +		smcr |= SMCR_ELx_FA64;

> This seems to silently duplicate logic present in cpufeatures.c.
> Would it be cleaner to save/restore this register explicitly across
> suspend, once cpufeatures has initialised it?

I was unsure about that, I could go either way.  All the register save
and restore is currently done in assembler which felt like it was doing
things too early so I went with this instead.

> Or this could be factored somehow, but dumbly saving/restoring it is
> probably simpler (?)

Yes, I keep thinking about doing that but factoring out is annoying
since there's also the KVM case where we don't always want to base the
decision about the settings on the cpufeature detection.

> > +	write_sysreg_s(smcr, SYS_SMCR_EL1);

> Is there an ISB or equivalent somewhere on this path?

> Can we blow up when trying to restore SME state (e.g., ZT0) before we
> enter userspace for the first time, if the firmware left the SME regs
> inaccessible?

I concluded when I wrote this that there was but I confess I can't
remember where exactly now.

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