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
| ||
|
Date: Mon, 19 Oct 2020 13:54:47 -0400 From: Arvind Sankar <nivedita@...m.mit.edu> To: Arvind Sankar <nivedita@...m.mit.edu> Cc: Joerg Roedel <joro@...tes.org>, x86@...nel.org, Joerg Roedel <jroedel@...e.de>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Kees Cook <keescook@...omium.org>, Martin Radev <martin.b.radev@...il.com>, Tom Lendacky <thomas.lendacky@....com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 3/5] x86/boot/compressed/64: Check SEV encryption in 64-bit boot-path On Mon, Oct 19, 2020 at 01:00:08PM -0400, Arvind Sankar wrote: > On Mon, Oct 19, 2020 at 05:11:19PM +0200, Joerg Roedel wrote: > > From: Joerg Roedel <jroedel@...e.de> > > > > Check whether the hypervisor reported the correct C-bit when running as > > an SEV guest. Using a wrong C-bit position could be used to leak > > sensitive data from the guest to the hypervisor. > > > > The check function is in arch/x86/kernel/sev_verify_cbit.S so that it > > can be re-used in the running kernel image. > > > > Signed-off-by: Joerg Roedel <jroedel@...e.de> > > --- > > > + > > + /* Store value to memory and keep it in %r10 */ > > + movq %r10, sev_check_data(%rip) > > + > > Does there need to be a cache flush/invalidation between this and the > read below to avoid just reading back from cache, or will the hardware > take care of that? Also, isn't it possible that the initial page tables we're running on have already been messed with and have the C-bit in the wrong location, so that this write happens decrypted? > > > + /* Backup current %cr3 value to restore it later */ > > + movq %cr3, %r11 > > + > > + /* Switch to new %cr3 - This might unmap the stack */ > > + movq %rdi, %cr3 > > Does there need to be a TLB flush after this? When executed from the > main kernel's head code, CR4.PGE is enabled, and if the original page > mapping had the global bit set (the decompressor stub sets that in the > identity mapping), won't the read below still use the original encrypted > mapping if we don't explicitly flush it? > > > + > > + /* > > + * Compare value in %r10 with memory location - If C-Bit is incorrect > > + * this would read the encrypted data and make the check fail. > > + */ > > + cmpq %r10, sev_check_data(%rip) > > + > > + /* Restore old %cr3 */ > > + movq %r11, %cr3 > > + > > + /* Check CMPQ result */ > > + je 3f > > + > > + /* > > + * The check failed - Prevent any forward progress to prevent ROP > > + * attacks, invalidate the stack and go into a hlt loop. > > + */ > > + xorq %rsp, %rsp > > + subq $0x1000, %rsp > > +2: hlt > > + jmp 2b > > +3: > > +#endif > > + ret > > +SYM_FUNC_END(sev_verify_cbit) > > + > > -- > > 2.28.0 > >
Powered by blists - more mailing lists