linux-kernel - Re: [PATCH v13 09/19] x86: Secure Launch kernel early boot stub

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: <Z_mMaAykU0IVKsjU@google.com>
Date: Fri, 11 Apr 2025 14:40:56 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Ross Philipson <ross.philipson@...cle.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, 
	linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-crypto@...r.kernel.org, kexec@...ts.infradead.org, 
	linux-efi@...r.kernel.org, iommu@...ts.linux.dev, 
	dpsmith@...rtussolutions.com, tglx@...utronix.de, mingo@...hat.com, 
	bp@...en8.de, hpa@...or.com, dave.hansen@...ux.intel.com, ardb@...nel.org, 
	mjg59@...f.ucam.org, James.Bottomley@...senpartnership.com, peterhuewe@....de, 
	jarkko@...nel.org, jgg@...pe.ca, luto@...capital.net, nivedita@...m.mit.edu, 
	herbert@...dor.apana.org.au, davem@...emloft.net, corbet@....net, 
	ebiederm@...ssion.com, dwmw2@...radead.org, baolu.lu@...ux.intel.com, 
	kanth.ghatraju@...cle.com, andrew.cooper3@...rix.com, 
	trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v13 09/19] x86: Secure Launch kernel early boot stub

On Thu, Apr 10, 2025, Ross Philipson wrote:
> +	/*
> +	 * Get a pointer to the monitor location on this APs stack to test below
> +	 * after mwait returns. Currently %esp points to just past the pushed APIC
> +	 * ID value.
> +	 */
> +	movl	%esp, %eax
> +	subl	$(TXT_BOOT_STACK_SIZE - 4), %eax
> +	movl	$0, (%eax)
> +
> +	/* Clear ecx/edx so no invalid extensions or hints are passed to monitor */
> +	xorl	%ecx, %ecx
> +	xorl	%edx, %edx
> +
> +	/*
> +	 * Arm the monitor and wait for it to be poked by he SMP bringup code. The mwait

s/he/the

> +	 * instruction can return for a number of reasons. Test to see if it returned
> +	 * because the monitor was written to.
> +	 */
> +	monitor
> +
> +1:
> +	mfence
> +	mwait
> +	movl	(%eax), %edx

Why load the value into EDX?  At a glance, the value is never consumed.

> +	testl	%edx, %edx
> +	jz	1b

This usage of MONITOR/MWAIT is flawed.  The monitor needs to be re-armed in each
loop, otherwise mwait will be a glorified nop.

More importantly, the exit condition needs to be checked before monitor, even on
the first iteration.  In the (probably extremely unlikely) scenario that the write
to wake the CPU arrives before MONITOR is executed, this CPU may get stuck waiting
indefinitely.

E.g. something like:


1:
	monitor
	cmpl	(%eax), 0
	jnz	2f
	mwait
	jmp	1b
2: