[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8lDN73cNOmNuciV@zn.tnic>
Date: Thu, 19 Jan 2023 14:18:47 +0100
From: Borislav Petkov <bp@...en8.de>
To: Peter Zijlstra <peterz@...radead.org>,
Jörg Rödel <joro@...tes.org>
Cc: x86@...nel.org, Joan Bruguera <joanbrugueram@...il.com>,
linux-kernel@...r.kernel.org, Juergen Gross <jgross@...e.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
xen-devel <xen-devel@...ts.xenproject.org>,
Jan Beulich <jbeulich@...e.com>,
Roger Pau Monne <roger.pau@...rix.com>,
Kees Cook <keescook@...omium.org>, mark.rutland@....com,
Andrew Cooper <Andrew.Cooper3@...rix.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v2 2/7] x86/boot: Delay sev_verify_cbit() a bit
On Mon, Jan 16, 2023 at 03:25:35PM +0100, Peter Zijlstra wrote:
> Per the comment it is important to call sev_verify_cbit() before the
> first RET instruction, this means we can delay calling this until more
Make that "... this means that this can be delayed until... "
And I believe this is not about the first RET insn but about the *next* RET
which will pop poisoned crap from the unencrypted stack and do shits with it.
Also, there's this over sev_verify_cbit():
* sev_verify_cbit() is called before switching to a new long-mode page-table
* at boot.
so you can't move it under the
movq %rax, %cr3
Looking at this more, there's a sme_enable() call on the BSP which is already in
C.
So, can we do that C-bit verification once on the BSP, *in C* which would be a
lot easier, and be done with it?
Once it is verified there, the bit is the same on all APs so all good.
Right?
joro?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists