From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls Date: Mon, 11 Jan 2016 18:32:17 +0000 Message-ID: <5693F531.9000004@citrix.com> References: <1452520774-16794-1-git-send-email-andrew.cooper3@citrix.com> <5693CDE302000078000C5788@prv-mh.provo.novell.com> <5693E3BD.6070009@citrix.com> <5693F3B9.5060407@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5693F3B9.5060407@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: David Vrabel , Jan Beulich Cc: StefanoStabellini , Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org On 11/01/16 18:26, David Vrabel wrote: > On 11/01/16 17:17, Andrew Cooper wrote: >> So from one point of view, sufficient justification for this change is >> "because the Linux way isn't the only valid way to do this". > "Because we can" isn't a good justification for adding something new. "Because I need this to sensibly regression test bits of the hypervisor" is. > Particularly something that is trivially easy to (accidentally) misuse > and open a big security hole between userspace and kernel. This is no conceptual difference to incorrectly updating a pagetable, or having wrong dpl checks in the IDT. An OS which doesn't use the hypercall can't shoot itself. An OS which does use it has plenty of other ways to accidentally compromise itself. > The vague idea for a userspace netfront that's floating around > internally is also not a good reason for pushing this feature at this time. It is a valid (albeit unwise) alternate usecase, showing that the concept isn't unique to my situation. ~Andrew