linux-kernel - Re: [PATCH 2/4] xen: limit grant v2 interface to the v1 functionality

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:   Tue, 12 Sep 2017 18:09:50 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org
Subject: Re: [PATCH 2/4] xen: limit grant v2 interface to the v1 functionality

On 12/09/17 18:05, Boris Ostrovsky wrote:
> On 09/12/2017 11:50 AM, Juergen Gross wrote:
>> On 12/09/17 17:44, Boris Ostrovsky wrote:
>>> On 09/08/2017 10:48 AM, Juergen Gross wrote:
>>>> As there is currently no user for sub-page grants or transient grants
>>>> remove that functionality. This at once makes it possible to switch
>>>> from grant v2 to grant v1 without restrictions, as there is no loss of
>>>> functionality other than the limited frame number width related to
>>>> the switch.
>>> But isn't that ABI violation? v2 is expected to support this (XSAs
>>> notwithstanding)
>> No, I don't think so.
>>
>> The hypervisor still supports it, but the domU (or dom0) isn't required
>> to make use of all the features IMHO. Or are you aware of any backend
>> querying the grant version of a frontend and acting in another way if v2
>> is detected?
> 
> I am not aware of any but that doesn't mean that they don't (or won't)
> exist.

But isn't the frontend the one which is defining what is granted in
which way? How should there be an ABI breakage when the frontend just
isn't using sub-page or transitive grants?


Juergen