From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [RFC 3/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode Date: Fri, 7 Aug 2015 14:08:24 +0100 Message-ID: <55C4ADC8.8000301@citrix.com> References: <1438879519-564-1-git-send-email-Ben.Catterall@citrix.com> <1438879519-564-4-git-send-email-Ben.Catterall@citrix.com> <55C3C9C7.8030808@citrix.com> <55C4A9B6.1030303@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55C4A9B6.1030303@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ben Catterall , Andrew Cooper , xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com, keir@xen.org, tim@xen.org, ian.campbell@citrix.com, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org On 07/08/15 13:51, Ben Catterall wrote: > > I don't know if we can make these synchronous as we need a way to > interrupt the vcpu if it's spinning for a long time. Otherwise an > attacker could just spin in depriv and cause a DoS. With that in mind, > the scheduler may decide to migrate the vcpu whilst it's in depriv mode > which would mean this per-pcpu data is held in the stack copy which is > then migrated to another pcpu incorrectly. IMO, DoS attacks on depriv'd emulators aren't very interesting. I think it is counter-productive to address this attack in this initial implementation at the expense (delays/complexity/etc.) of solving the key requirement of mitigating information leaks and privilege escalation attacks David