linux-kernel - Re: [PATCH] firmware: Add device tree binding for coreboot

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: <CAL_Jsq+rGLFcOcs8Rmr8NntbPhGBG+F7yAF0YQ-Rm-UsmmTLSA@mail.gmail.com>
Date:	Mon, 16 Jun 2014 08:30:12 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Julius Werner <jwerner@...omium.org>
Cc:	Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Stephen Warren <stephen.r.warren@...il.com>,
	Doug Anderson <dianders@...omium.org>,
	Olof Johansson <olofj@...omium.org>,
	Stefan Reinauer <stefan.reinauer@...eboot.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH] firmware: Add device tree binding for coreboot

On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner <jwerner@...omium.org> wrote:
>> This is just to export a fixed log to userspace (like a DMI table) or
>> the kernel will actually use the data in some way? Based on the link,
>> it looks like the former to me.
>
> I could imagine both. The link is an in-kernel driver that exposes a
> log through a sysfs node (in a way that has already been established
> on x86 systems, which find the location through EBDA or ACPI entries
> instead). We are also using a user-space tool that reads the address
> from /proc/device-tree and accesses it through /dev/mem. The areas can
> contain many interesting entries (like the location of an early
> framebuffer set up by the firmware), so I could also imagine use cases
> where the kernel makes use of it directly.

I can be argued that the boot interface is DT and any configuration
data should be put there in a common way. We don't really need yet
another boot mechanism as we already have:

UEFI + FDT
UEFI + ACPI
"standard" bootloaders (e.g. u-boot, grub, barebox, etc.) + FDT

Allowing every bootloader to define its own boot interfaces would only
result in a mess for both code and testing. I don't want to get into a
debate about this now as it is not too relevant to this patch, but
just want to highlight the resistance you will face going down this
path.

>> Don't you need need to keep the kernel from allocating this memory by
>> using one of the reserved memory mechanisms? The recently added one
>> should be able to specific what the memory is reserved for IIRC.
>
> Our bootloader is carving the location out of the /memory node and
> adding it to the device tree reserve map. As far as I know, that only
> contains a list of raw start and size entries. At any rate, I think
> it's useful (and in line with other bindings) to add a more explicit
> node like this (if only to make it easier accessible through
> /proc/device-tree).

Understand there are 3 different memory reservation bindings. The
original "/memreserve/" method is indeed limited. What I think you
should use is the binding documented in
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt.
So you could do something like this:

        reserved-memory {
                #address-cells = <1>;
                #size-cells = <1>;
                ranges;

                /* global autoconfigured region for contiguous allocations */
                linux,cma {
                        compatible = "shared-dma-pool";
                        reusable;
                        size = <0x4000000>;
                        alignment = <0x2000>;
                        linux,cma-default;
                };

                coreboot_reserved: coreboot@...ea000 {
                      compatible = "coreboot";
                      reg = <0xfdfea000 0x264>,
                          <0xfdfea000 0x16000>;
                };


>> /firmware is already used IIRC. What if you have other firmware such
>> as Trustzone?
>
> I'm not quite sure how Trusted Foundations works and whether it would
> even make sense to use it in parallel to coreboot, but it seems to be
> using the /firmware/trusted-foundations subnode so that should be
> fine. "firmware" seems to be used by other firmware implementations
> (like "samsung,secure-firmware") which are similar in nature to and
> mutually exclusive with coreboot, so I thought the node makes sense.
> (The kernel should use the compatible string to find it anyway, so a
> future name clash would not be world-ending.)

They are not mutually exclusive. What runs in secure world or not is
entirely independent of non-secure boot. You may not care about it,
but other platforms could.

Rob
--
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/