Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752043AbdIMJXt (ORCPT ); Wed, 13 Sep 2017 05:23:49 -0400 Received: from mx2.suse.de ([195.135.220.15]:39061 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751380AbdIMJXs (ORCPT ); Wed, 13 Sep 2017 05:23:48 -0400 Subject: Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version To: Andrew Cooper , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: boris.ostrovsky@oracle.com References: <20170908144849.2958-1-jgross@suse.com> <20170908144849.2958-5-jgross@suse.com> From: Juergen Gross Message-ID: <7d34f929-b45d-c056-865d-94082312b0bc@suse.com> Date: Wed, 13 Sep 2017 11:23:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1303 Lines: 37 On 12/09/17 20:54, Andrew Cooper wrote: > On 08/09/17 15:48, Juergen Gross wrote: >> static void gnttab_request_version(void) >> { >> - int rc; >> + long rc; >> struct gnttab_set_version gsv; >> >> - gsv.version = 1; >> + rc = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL); > > This hypercall is information leak and layering violation. Please can > we avoid adding more dependence on its presence? (I'm got a > proto-series which strips various corners off the hypervisor for attack > surface reduction purposes, and this hypercall is one victim which is > restricted to privileged domains only.) > > For translated guests, it is definitely not the right number to check. > What matters is the maximum frame inside the translated guest, not on > the host. Oh, right. > For PV guests, I'm not sure what to suggest, but the result of > XENMEM_maximum_ram_page isn't applicable. Xen's max_page can increase > at runtime through memory hotplug, after which ballooning operations can > leave Linux with a frame it wishes to grant which exceeds the limit > calculated here. We need a way to decide whether V2 is to be selected. Is there a way to determine which is the highest physical address being available for memory hotplug on a system? Something in ACPI tables perhaps? Juergen