From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= Subject: Re: [xen-unstable test] 56456: regressions - FAIL Date: Wed, 20 May 2015 11:55:11 +0200 Message-ID: <555C59FF.1090508@citrix.com> References: <55572DDC.8050306@citrix.com> <5559C03C020000780007AF3A@mail.emea.novell.com> <20150518101759.GA94471@deinos.phlegethon.org> <5559C40A.2020106@citrix.com> <5559E6E2020000780007B02C@mail.emea.novell.com> <20150519102034.GD12275@deinos.phlegethon.org> <555B2CBA020000780007B8FE@mail.emea.novell.com> <555B5194.8030908@citrix.com> <555C4CBF.7080304@citrix.com> <555C6C2E020000780007C020@mail.emea.novell.com> <20150520094312.GA12015@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yv0ic-00064f-LM for xen-devel@lists.xenproject.org; Wed, 20 May 2015 09:55:18 +0000 In-Reply-To: <20150520094312.GA12015@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan , Jan Beulich Cc: AndrewCooper , ian.jackson@eu.citrix.com, xen-devel List-Id: xen-devel@lists.xenproject.org El 20/05/15 a les 11.43, Tim Deegan ha escrit: > At 10:12 +0100 on 20 May (1432116766), Jan Beulich wrote: >>>>> On 20.05.15 at 10:58, wrote: >>> After looking into this a little bit more, I'm afraid I don't see a >>> straight forward way to check for the permissions of all paging levels. >>> Here are the options I've found in order to deal with this: >>> >>> - Use guest_get_eff_l1e and only check for the permissions of the L1 >>> entry. Is it possible that the guest places an invalid entry in the >>> linear l1 table without Xen realizing? >> >> No - all page table changes are being validated by Xen. > > Yes, using guest_get_eff_l1e() is safe for Xen. The only concern is > whether it's safe for the guest -- Xen might not honour an upper-level > read-only mark (which copy_to_guest() would) or a supervisor-mode-only > mark (which it wouldn't). > >>> - Add a new function hook somewhere (pv_domain maybe?) that can be >>> used to translate GVA to PFN for PV guests (mimicking what >>> paging_gva_to_gfn does). This would be implemented using >>> guest_walk_X_level, where X is the paging levels of the guest. >>> >>> - Use some glue to be able to call guest_walk_{3/4}_level from >>> paging.c directly, and correctly choose which one to use based on >>> the guest bitness. IMHO this looks quite wacky, and I'm not even >>> sure if it's possible given the amount of preprocessor foo in >>> guest_pt.h. >>> >>> I have the first option already implemented, but I would appreciate some >>> advice regarding the security implications of it. >> >> I think with all of the options here being unsatisfactory we should >> reconsider your original option of restoring previous behavior >> (without any mapping) for the PV case. Tim? > > Yeah, I don't think it's worth adding a bunch mode pagetable-walk > machinery just to keep this function clean. So I suppose we have to > have two paths. in this code. FWIW there's also the option of taking the callers p2m lock if it's a HVM guest: http://lists.xen.org/archives/html/xen-devel/2014-10/msg01769.html And avoid doing any modifications of the code paths. Roger.