On 9 February 2017 at 17:41, Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote: > On 2/9/2017 10:16 AM, Ard Biesheuvel wrote: >> >> On 9 February 2017 at 17:06, Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote: >>> >>> On 2/9/2017 3:16 AM, Ard Biesheuvel wrote: >>>> >>>> >>>> On arm64, we have made some changes over the past year to the way the >>>> kernel itself is allocated and to how it deals with the initrd and FDT. >>>> This patch brings the allocation logic in the EFI stub in line with >>>> that, >>>> which is necessary because the introduction of KASLR has created the >>>> possibility for the initrd to be allocated in a place where the kernel >>>> may not be able to map it. (This is currently a theoretical scenario, >>>> since it only affects systems where the size of RAM exceeds the size of >>>> the linear mapping.) >>>> >>>> So adhere to the arm64 boot protocol, and make sure that the initrd is >>>> fully inside a 1GB aligned 32 GB window that covers the kernel as well. >>>> >>>> The FDT may be anywhere in memory on arm64 now that we map it via the >>>> fixmap, so we can lift the address restriction there completely. >>>> >>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> >>>> --- >>> >>> >>> >>> I'll give this a test on our platform that was running into the current >>> limitation - probably this weekend. >>> >>> I reviewed the code and its ok, but I do have one question. Do we need >>> to >>> handle the case where initrd ends up below the kernel? >>> >>> Lets assume KALSR puts the kernel somewhere up high in DDR, after the >>> 32GB >>> mark in DDR. Now lets assume the unlikely scenario that the initrd won't >>> fit anywhere after 32GB, but will fit before 32GB. Per my understanding >>> of >>> efi_high_alloc, it will put the initrd before the 32GB mark, which will >>> be >>> outside of the window where the kernel is. >>> >> >> The 32 GB does not have to be 32 GB aligned, only 1 GB aligned. So as >> long as the follow expression holds, we should be fine >> >> >> align(max(kernel_end, initrd_end), 1g) - align_down (min >> (kernel_start, initrd_start), 1g) <= 32g > > > Yes, and I argue there is a possibility (we'll call it extremely remote) > where that may not hold. My question is, do we care about that possibility, > and if so, do we do anything about it? > We allocate top down, so we start at align_down(base_of_image, 1g) + 32g, and go down until we hit a region that first our initrd. We will disregard the region that the kernel occupies, but below that, we will just proceed until we find a slot. This effectively means we have a 63 GB window, with the kernel in the middle, where we can load the initrd and adhere to the boot protocol. I don't see how we could end up in the situation where we load the kernel somewhere, and both the 31 GB before *and* after are completely occupied. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
