linux-kernel - Re: [PATCH v3 06/10] arm64: efi: add EFI stub

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 8 Feb 2017 17:34:38 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Jeffrey Hugo <jhugo@...eaurora.org>
Cc:     Timur Tabi <timur@...eaurora.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        linux-efi@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        lkml <linux-kernel@...r.kernel.org>,
        Leif Lindholm <leif.lindholm@...aro.org>,
        Mark Salter <msalter@...hat.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 06/10] arm64: efi: add EFI stub

On Wed, Feb 08, 2017 at 10:30:37AM -0700, Jeffrey Hugo wrote:
> On 2/8/2017 10:03 AM, Mark Rutland wrote:
> >On Wed, Feb 08, 2017 at 10:35:02AM -0600, Timur Tabi wrote:
> >>On 02/08/2017 10:29 AM, Ard Biesheuvel wrote:
> >>>>>>>+       status = handle_cmdline_files(sys_table, image, cmdline_ptr,
> >>>>>>>+                                     "initrd=", dram_base + SZ_512M,
> >>>>>>>+                                     (unsigned long *)&initrd_addr,
> >>>>>>>+                                     (unsigned long *)&initrd_size);
> >>>>>
> >>>>>So I know this patch is almost three years old, but why is there a
> >>>>>512M limit on the initrd size?
> >>>>>
> >>>How do you reckon this constitutes a limit?
> >>
> >>handle_cmdline_files() calls efi_high_alloc() with that limit.  I'm
> >>still trying to understand all the details myself, but apparently
> >>our firmware and initrd need to fit within the first 512MB because
> >>of dram_base + SZ_512M. When we change "dram_base + SZ_512M" to
> >>"~0", everything works.
> >
> >Just to check, how big is that initrd?
> >
> >I guess it's possible that there simply isn't sufficient contiguous free
> >memory in that range, even if the initrd isn't that large. Can you share
> >the EFI memory map dump from booting with efi=debug?
> >
> >We originally needed to restrict this to ensure that the kernel could
> >map the initrd (and I think the 512M restriction specifically was
> >inherited from the DTB mapping restriction). Since then, we have relaxed
> >things in the kernel, and today Documentation/arm64/booting.txt says:
> >
> >	If an initrd/initramfs is passed to the kernel at boot, it must
> >	reside entirely within a 1 GB aligned physical memory window of
> >	up to 32 GB in size that fully covers the kernel Image as well.
> >
> >... so I think the EFI stub should be able to take advantage of that
> >relaxation.
> 
> I agree.  The wrinkle I can see in this is it looks like KASLR can
> put the kernel anywhere in RAM.  How do we ensure initrd is within
> 32GB of the kernel on a system with 256 GB of RAM?

The EFI stub chose the physical location of the kernel, and should know
where it put it. The virtual location of the kernel shouldn't matter.

At some point though, this does become best-effort, unless we want a SAT
solver in the stub.

Thanks,
Mark.