Fixes for low memory allocation machinery in early boot code

[Daniel Kiper <daniel.kiper@oracle.com>]

Hey,

So, as I promised in other thread I am sending more info about my investigation
related to low memory allocation for trampoline and other early boot data.

Starting from the beginning it looks that there are "soft" limits enforced
in BIOS early boot code looking for usable low memory region. Hight limit
is set at 640 KiB and low at 256 KiB. This means that if a value from a given
source which describes low memory region (i.e. EBDA base segment, base memory
size, multiboot protocol) is out of bounds then we try to get new value from
next one (I mean source). However, at the end there are no checks that assure
us that we got what we expected. So, I think that at first we should add "hard"
checks here. This means that if we get value out of earlier mentioned bounds
then we should print relevant message on serial console and halt the system.

Additionally, my investigation has shown that there are no bound checks in
low memory allocation machinery for trampoline (by the way, in BIOS path we
allocate 64 KiB for trampoline but in EFI code we properly calculate its size;
so, I think we should do the same calculation in BIOS path), stack and boot data
taken from multiboot protocol. Hence, relevant fixes should be added here too.

Moreover I think that at least allocation machinery with additional checks
described in last paragraph can be used on EFI platforms when Xen is booted
via multiboot2 protocol. However, then high limit should be defined as 1 MiB.
Though I think that low limit, 256 KiB, should stay as is.

So, I think that we should prepare following patches:
  - allocate properly calculated amount of memory for trampoline,
  - define high/low limit as a constants and use them,
  - add bounds checks for chosen low memory region, and bounds
    checks in allocation machinery for trampoline and stack,
  - add bounds checks to allocator in reloc.c.

I have a feeling that this fixes are not very critical, however, nice to have.
So, looking at code before and after my "x86: multiboot2 protocol support" patch
series I think that we can apply them on top of it. Then relevant code changes
will be much easier to analyze and cleaner, especially in reloc.c. However, if
ease of backporting of low memory allocator patches is more important then they
should precede "x86: multiboot2 protocol support" patch series.

What do you think about that?

Daniel

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