Well the code was copied from handling unhashed subpackets and has
same assumptions. I do agree that it does not handle arbitrary length
data. But if you consider it wrong, it should be changed for both
hashed and unhashed packets. Currently, for example, if the length of
unhashed subpackets will b
On Wed, Mar 30, 2016 at 11:47 AM, Ignat Korchagin wrote:
> Well the code was copied from handling unhashed subpackets and has
> same assumptions. I do agree that it does not handle arbitrary length
> data. But if you consider it wrong, it should be changed for both
> hashed and unhashed packets. C
Implemented as a separate function which should process arbitrary length data.
As for tests, it seems that the easiest way is to add this signature to
tests/file_filter. Not sure how should I send you the patch with binary data
though.
diff --git a/grub-core/commands/verify.c b/grub-core/comman
If image requested EFI boot services then skip multiboot2 memory maps.
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 have finished boot services.
If we keep boot ser
Add tags used to pass ImageHandle to loaded image if requested.
It is used by at least ExitBootServices() function.
Signed-off-by: Daniel Kiper
Reviewed-by: Konrad Rzeszutek Wilk
---
v4 - suggestions/fixes:
- reduce number of #ifdefs in grub_multiboot_get_mbi_size()
(suggested by Vladimi
Hi,
This patch series:
- enables EFI boot services usage in loaded images
by multiboot2 protocol,
- add support for multiboot2 protocol compatible
relocatable images.
Daniel
grub-core/Makefile.core.def |1 +
grub-core/lib/i386/relocator64.S | 11
grub-core/
Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded
If image requested EFI boot services then skip multiboot2 memory maps.
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 have finished boot services.
If we keep boot ser
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong
Hello,
Ping?
Regards,
On 19/02/16 16:28, Julien Grall wrote:
Xen is currently crashing because of malformed compatible property for
the boot module. This is because the property string is not
null-terminated as requested by the ePAR spec.
---
grub-core/loader/arm64/xen_boot.c | 2 +-
1 file
Hi Julien,
I have posted the v3 , please check
http://lists.xen.org/archives/html/xen-devel/2016-03/msg03564.html
And I hope GRUB patch can be merged :-)
On 30 March 2016 at 23:52, Julien Grall wrote:
> Hello,
>
> Ping?
>
> Regards,
>
>
> On 19/02/16 16:28, Julien Grall wrote:
>>
>> Xen is curr
11 matches
Mail list logo
