Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Jul 2020 09:07:43 -0700
From: Andy Lutomirski <>
To: Dave Hansen <>
Cc: "Andersen, John" <>, Paolo Bonzini <>, 
	Sean Christopherson <>, Jonathan Corbet <>, 
	Thomas Gleixner <>, Ingo Molnar <>, Borislav Petkov <>, 
	X86 ML <>, "H. Peter Anvin" <>, Shuah Khan <>, 
	Liran Alon <>, Andrew Jones <>, 
	Rick Edgecombe <>, 
	Kristen Carlson Accardi <>, Vitaly Kuznetsov <>, 
	Wanpeng Li <>, Jim Mattson <>, 
	Joerg Roedel <>, Mauro Carvalho Chehab <>, 
	Greg KH <>, "Paul E. McKenney" <>, 
	Pawan Gupta <>, Juergen Gross <>, 
	Mike Kravetz <>, Oliver Neukum <>, 
	Andrew Lutomirski <>, Peter Zijlstra <>, 
	Fenghua Yu <>,,, Dave Hansen <>, 
	Arjan van de Ven <>,, 
	Baoquan He <>, Arvind Sankar <>, 
	Kees Cook <>, Dan Williams <>,,, Peter Xu <>,, 
	"open list:DOCUMENTATION" <>, LKML <>, 
	kvm list <>, 
	Kernel Hardening <>
Subject: Re: [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning

On Thu, Jul 9, 2020 at 8:56 AM Dave Hansen <> wrote:
> On 7/9/20 8:44 AM, Andersen, John wrote:
> >
> >         Bits which are allowed to be pinned default to WP for CR0 and SMEP,
> >         SMAP, and UMIP for CR4.
> I think it also makes sense to have FSGSBASE in this set.
> I know it hasn't been tested, but I think we should do the legwork to
> test it.  If not in this set, can we agree that it's a logical next step?

I have no objection to pinning FSGSBASE, but is there a clear
description of the threat model that this whole series is meant to
address?  The idea is to provide a degree of protection against an
attacker who is able to convince a guest kernel to write something
inappropriate to CR4, right?  How realistic is this?

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.