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. > 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. > 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. Jan > and by computing it in a way that is immune to integer overflow. > The new code is slightly longer, but it is much easier to understand and > use.
