linux-kernel - Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X

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-next>] [day] [month] [year] [list]

Date:   Tue, 15 Nov 2016 12:07:42 +0100
From:   Juergen Gross <jgross@...e.com>
To:     Jan Beulich <JBeulich@...e.com>
Cc:     David Vrabel <david.vrabel@...rix.com>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        xen-devel@...ts.xenproject.org, Ingo Molnar <mingo@...hat.com>,
        Alex Thorlton <athorlton@....com>, Russ Anderson <rja@....com>,
        linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible
 entries

On 15/11/16 11:44, Jan Beulich wrote:
>>>> On 15.11.16 at 10:55, <JGross@...e.com> wrote:
>> On 15/11/16 10:45, Jan Beulich wrote:
>>>>>> On 15.11.16 at 09:42, <JGross@...e.com> wrote:
>>>> For a fully dynamical solution we'd need a way to get a partial
>>>> E820 map from the hypervisor (e.g. first 128 entries) in order to
>>>> be able to setup at least some memory and later get the rest of
>>>> the memory map using some dynamically allocated memory.
>>>
>>> And we could of course also make the hypercall allow for that (e.g.
>>> by defining the semantics of a specific error code, so far not used
>>> by it, to avoid mis-interpretation of output on older hypervisors),
>>> or introduce a new clone of the existing one(s).
>>
>> I'd go with the new error code. What about E2BIG or ENOSPC?
> 
> Either seems fine.
> 
>> I think the hypervisor should fill in the number of entries required
>> in this case.
> 
> And you'd then mean the caller to imply that the passed in (and now
> overwritten) count to describe how many entries got filled? That's
> not that nice an interface. I'd rather return the number of entries
> filled, and require the sizing variant (NULL handle) to be used to
> obtain the number of entries. After all if a caller _wants_ to handle
> a partial map, it doesn't really care how many further entries there
> are.

I just wanted to avoid two interface changes. IMO the caller knows the
buffer size he supplied and it is rather clear that e.g. E2BIG means
it has been filled completely.

And the assumption the caller doesn't care for the further entries is
not necessarily true: he might not care at the moment of the call, but
he will eventually care for them later when he is able to allocate an
appropriate sized buffer.

OTOH I'm not feeling strong in this case and you are the hypervisor
maintainer. Either solution is fine for me.


Juergen