linux-kernel - Re: [RFC 0/5] drivers: Add boot constraints core

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:   Fri, 7 Jul 2017 15:39:02 -0700
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Rob Clark <robdclark@...il.com>
Cc:     Russell King - ARM Linux <linux@...linux.org.uk>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Shiraz Hashim <shashim@...eaurora.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC 0/5] drivers: Add boot constraints core

On 07/05, Rob Clark wrote:
> On Thu, Jun 29, 2017 at 5:00 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
> > On 06/29, Russell King - ARM Linux wrote:
> >>
> >> As far as the memory being used goes, they probably locate the frame
> >> buffer well away from the kernel or any area that the kernel is likely
> >> to use during decompression.
> >>
> >> It's probably also marked as a reserved memory region in DT to avoid
> >> the kernel touching it during boot, or _maybe_ they just locate it
> >> somewhere in memory that they've tested that the kernel doesn't touch
> >> until after their kernel has initialised the LCD controller (thereby
> >> avoiding the memory being permanently consumed.)
> >>
> >
> > Yes. The display controller is typically pointed to a memory
> > carveout that we treat as reserved in the kernel. I'm fairly
> > certain that we avoid the "permanently consumed" problem by
> > making it a carveout for the display controller, so that when the
> > display controller probes it can take ownership of the memory
> > from the bootloader.
> >
> 
> For aarch64/arm64 booting with EFI, the bootloader passes info about
> memory layout to the kernel (including the fact that the framebuffer
> is carved out) so kernel doesn't clobber the scanout buffer.  The
> non-EFI case, the bootloader should (not that lk does) patch up the
> fdt reserved memory node w/ correct address/size.  I think
> lk+downstream just relies on luck.
> 

Downstream+lk seems to be doing a carveout with reserved-memory
in DT[1]. The bootloader isn't updating the DT to indicate this,
instead we rely on an agreement between bootloader and kernel's
DT file to have the carveout. Once the display driver configures
things enough to allocate another display buffer it actually
frees the memory back to the system[2]. Most of the code for this
splash screen stuff is in that mdss_mdp_splash_logo.c file.

[1] https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/msm8996.dtsi?h=rel/msm-4.4#n231
[2] https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/drivers/video/fbdev/msm/mdss_mdp_splash_logo.c?h=rel/msm-4.4#n252

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project