Re: [Xen-devel] [GRUB2 PATCH v4 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Tue, Mar 15, 2016 at 06:10:48PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> Le mar. 15 mars 2016 19:06, Andrei Borzenkov <arvidjaar@xxxxxxxxx> a écrit :
> > 15.03.2016 19:07, Vladimir 'phcoder' Serbinenko пишет:
> > > Looks good. Let's give a day for others to comment. Is the second email
> > the
> > > version for commit?
> > >
> > > On Tuesday, March 15, 2016, Daniel Kiper <daniel.kiper@xxxxxxxxxx>
> > wrote:
> > >
> > >> Do not pass memory maps to image if it asked for EFI boot services.
> > >> Main reason for not providing maps is because they will likely be
> > >> invalid. We do a few allocations after filling them, e.g. for relocator
> > >> needs. Usually we do not care as we would already finish boot services.
> > >> If we keep boot services then it is easier to not provide maps. However,
> > >> if image needs memory maps and they are not provided by bootloader then
> > >> it should get them itself just before ExitBootServices() call.
> > >>
> >
> > Are there any existing users of it that rely on memory map provided by
> > bootloader? What if image explicitly requested non-optional memory map?
> > According to multiboot specification it is valid and bootloader must
> > either provide requested information or fail load.
> >
> I think you have a point. @Daniel, is current behavior a problem for you?

Do you think about MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST tag? If yes it
looks that multiboot2 doc is a bit imprecise and/or GRUB2 code is wrong.

multiboot2 doc says:

[...]

If this tag is present and ‘optional’ is set to ‘0’ information conveyed by
requested tag types must be present. If bootloader is unable to supply this
information it must fail with an error
Note: it doesn’t garantee that any tags of type ‘mbi_tag_types’ will actually
be present. E.g. on a videoless system even if you requested tag ‘8’ no tags
of type ‘8’ will be present in mbi.

[...]

However, grub_multiboot_load() just looks for 
MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST
tag. If it exists and if ‘optional’ is set to ‘0’ then grub_multiboot_load() 
verify
list of requested tags. If unknown value is found then multiboot2 command fails
with "grub_error (GRUB_ERR_UNKNOWN_OS, "unsupported information tag: 0x%x", 
...".
I cannot find additional checks anywhere...

So, AIUI, "If bootloader is unable to supply..." should be read as "If 
bootloader
does not support..." or even "If bootloader do not understand..." or something
like that. This does not mean that bootloader must have requested data in hand
and provide it to image. It means that bootloader must understand what image 
ask for.
And in this term my patch does not violate spec implied by implementation (well,
multiboot2 doc makes some confusion; see below). Image may ask/request for any
memory map. However, if a given map (or set of maps) is not available or it 
could
be provided but could make confusion in some cases then it can/should not be 
provided.

Anyway, I think that maybe multiboot2 doc should be fixed and more precise
MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST tag description should be provided.
Or GRUB2 implementation is wrong then...

> Don't you just ignore the memory map in this case?

Yes to some extent. However, I think that loader should not provide
data which is known as (potentially) incorrect/faulty.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel