linux-kernel - Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKv+Gu-b=QvMF++V9UjULRxrGvoz-0ytFLeuLm8Y5sQH4p53Sw@mail.gmail.com>
Date:	Tue, 25 Aug 2015 16:51:22 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Leif Lindholm <leif.lindholm@...aro.org>
Cc:	Haojian Zhuang <haojian.zhuang@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Dan Zhao <dan.zhao@...ilicon.com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	Jian Zhang <zhangjian001@...ilicon.com>,
	Guangyue Zeng <zengguangyue@...ilicon.com>,
	Yiping Xu <xuyiping@...ilicon.com>,
	Jassi Brar <jassisinghbrar@...il.com>,
	Wei Xu <xuwei5@...ilicon.com>,
	Zhenwei Wang <Zhenwei.wang@...ilicon.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Bintian Wang <bintian.wang@...wei.com>,
	Pawel Moll <Pawel.Moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"kongfei@...ilicon.com" <kongfei@...ilicon.com>,
	Rob Herring <robh+dt@...nel.org>,
	Haoju Mo <mohaoju@...ilicon.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"guodong.xu@...aro.org" <guodong.xu@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"leo.yan@...aro.org" <leo.yan@...aro.org>
Subject: Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node

On 25 August 2015 at 16:24, Leif Lindholm <leif.lindholm@...aro.org> wrote:
> On Tue, Aug 25, 2015 at 09:43:14PM +0800, Haojian Zhuang wrote:
>> Since we discussed a lot on this, let's make a conclusion on it.
>>
>> 1. UEFI could append the reserved buffer in it's memory mapping.
>
> Yes. It needs to.
>
> (I will let Mark comment on points 2-4.)
>
>> 5. A patch is necessary in kernel. If efi stub feature is enabled,
>>    arm kernel should not parse memory node or reserved memory buffer in
>>    DT any more.
>
> This is already the case. The stub deletes any present memory nodes and
> reserved entries in drivers/firmware/efi/libstub/fdt.c:update_fdt().
>
> Then, during setup_arch(), arch/arm64/kernel/efi.c:efi_init() calls
> reserve_regions(), which adds only those memory regions available for
> use by Linux as RAM to memblock.
>
>>    Arm kernel should either fetch memory information from
>>    efi or DT.
>
> Absolutely.
>
>>    Currently arm kernel fetch both efi memory information and
>>    reserved buffer from DTB at the same time.
>
> No, it does not.
>

It should not, but it does. Due to an oversight, the stub removes
/memreserve/ entries but ignores the reserved-memory node completely.

This was reported here in fact

http://thread.gmane.org/gmane.linux.kernel.efi/5736/focus=5742

but there has not been a followup to this series.

I think it is fine to keep those memory reservations in the DT, but
you should simply understand that UEFI does not parse the DT, so you
need to tell it which memory it cannot touch. Otherwise, the firmware
itself or anything that executes under it (UEFI drivers, the UEFI
Shell, GRUB, the UEFI stub in the kernel) will think it is available
and may allocate it for its own use. This may include runtime services
regions that will remain reserved even after exiting boot services.

-- 
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/