linux-kernel - Re: [PATCH 6/7] x86/boot/compressed/64: Check SEV encryption in 32-bit boot-path

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]

Date:   Wed, 10 Feb 2021 08:25:11 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Joerg Roedel <joro@...tes.org>, x86@...nel.org
Cc:     Joerg Roedel <jroedel@...e.de>, hpa@...or.com,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Jiri Slaby <jslaby@...e.cz>,
        Dan Williams <dan.j.williams@...el.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Juergen Gross <jgross@...e.com>,
        Kees Cook <keescook@...omium.org>,
        David Rientjes <rientjes@...gle.com>,
        Cfir Cohen <cfir@...gle.com>,
        Erdem Aktas <erdemaktas@...gle.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Mike Stunes <mstunes@...are.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Martin Radev <martin.b.radev@...il.com>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH 6/7] x86/boot/compressed/64: Check SEV encryption in
 32-bit boot-path

On 2/10/21 2:21 AM, Joerg Roedel wrote:
> +1:	rdrand	%eax
> +	jnc	1b
> +2:	rdrand	%ebx
> +	jnc	2b
> +
> +	/* Store to memory and keep it in the registers */
> +	movl	%eax, rva(sev_check_data)(%ebp)
> +	movl	%ebx, rva(sev_check_data+4)(%ebp)
> +
> +	/* Enable paging to see if encryption is active */
> +	movl	%cr0, %edx	/* Backup %cr0 in %edx */
> +	movl	$(X86_CR0_PG | X86_CR0_PE), %ecx /* Enable Paging and Protected mode */
> +	movl	%ecx, %cr0
> +
> +	cmpl	%eax, rva(sev_check_data)(%ebp)
> +	jne	3f
> +	cmpl	%ebx, rva(sev_check_data+4)(%ebp)
> +	jne	3f
> +
> +	movl	%edx, %cr0	/* Restore previous %cr0 */
> +
> +	jmp	4f

This is all very cute.  But, if this fails, it means that the .data
section is now garbage, right?.  I guess failing here is less
entertaining than trying to run the kernel with random garbage in .data,
but it doesn't make it very far either way, right?

Why bother with rdrand, though?  Couldn't you just pick any old piece of
.data and compare before and after?