linux-kernel - Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Sep 2017 11:23:45 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Andrew Cooper <andrew.cooper3@...rix.com>,
        linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org
Cc:     boris.ostrovsky@...cle.com
Subject: Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version

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