Re: [PATCH] Make XEN_FW_EFI_MEM_INFO easier to use

[Demi Marie Obenour <demi@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Thu, Aug 25, 2022 at 09:59:56AM +0200, Jan Beulich wrote:
> On 24.08.2022 23:04, Demi Marie Obenour wrote:
> > The XEN_FW_EFI_MEM_INFO platform op has very surprising behavior: it
> > only sets info->mem.size if the initial value was *larger* than the size
> > of the memory region.
> 
> And intentionally so - the caller didn't ask for any bigger region,
> after all.

That needs to be documented, then.  I thought it provided the full
region that contained the address.

> >  This is not particularly useful and cost me most
> > of a day of debugging.  It also has some integer overflow problems,
> > though as the data comes from dom0 or the firmware (both of which are
> > trusted) these are not security issues.
> 
> I'm afraid we're trusting the firmware in this regard elsewhere as
> well. So if there was a need to change that, I guess it would need
> changing everywhere, not just here. But we trust the E820 map as
> well, when on non-EFI platforms, so I don't see why we would need
> to change that. In any event such would want to be a separate
> change imo.

That is valid.

> > Fix both of these problems by unconditionally setting the memory region
> > size
> 
> If you were to report a larger ending address, why would you not also
> report a smaller starting address?
> 
> But before you go that route - I don't think we can change the API
> now that it has been in use this way for many years. If a "give me
> the full enclosing range" variant is wanted, it will need to be
> fully separate.

Does anyone use this API?

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]