* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Vladimir Murzin @ 2016-12-07 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZywn46QbnvKcN-jkt43Vf+GBSNQkLgnnNg-DC-8aSO5w@mail.gmail.com>
Hi Linus,
On 07/12/16 14:11, Linus Walleij wrote:
> Another target I had in mind was the Integrator which
> incidentally supports a bunch of the old noMMU core
> tiles where we can swap in an ARM946, which I guess
> could work with this?
Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
reported it did a trick for Versatile, there is a good chance it would work
for Integrator too ;)
[1] https://www.spinics.net/lists/arm-kernel/msg546823.html
Thanks
Vladimir
^ permalink raw reply
* [PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'
From: Will Deacon @ 2016-12-07 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207090638.GI10776@rric.localdomain>
On Wed, Dec 07, 2016 at 10:06:38AM +0100, Robert Richter wrote:
> On 06.12.16 17:38:11, Will Deacon wrote:
> > On Mon, Dec 05, 2016 at 03:42:14PM +0000, Ard Biesheuvel wrote:
> > > On 2 December 2016 at 14:49, James Morse <james.morse@arm.com> wrote:
> > > > Patch "arm64: mm: Fix memmap to be initialized for the entire section"
> > > > changes pfn_valid() in a way that breaks hibernate. These patches fix
> > > > hibernate, and provided struct page's are allocated for nomap pages,
> > > > can be applied before [0].
> > > >
> > > > Hibernate core code belives 'valid' to mean "I can access this". It
> > > > uses pfn_valid() to test the page if the page is 'valid'.
> > > >
> > > > pfn_valid() needs to be changed so that all struct pages in a numa
> > > > node have the same node-id. Currently 'nomap' pages are skipped, and
> > > > retain their pre-numa node-ids, which leads to a later BUG_ON().
> > > >
> > > > These patches make hibernate's savable_page() take its escape route
> > > > via 'if (PageReserved(page) && pfn_is_nosave(pfn))'.
> > > >
> > >
> > > This makes me feel slightly uneasy. Robert makes a convincing point,
> > > but I wonder if we can expect more fallout from the ambiguity of
> > > pfn_valid(). Now we are not only forced to assign non-existing (as far
> > > as the OS is concerned) pages to the correct NUMA node, we also need
> > > to set certain page flags.
> >
> > Yes, I really don't know how to proceed here. Playing whack-a-mole with
> > pfn_valid() users doesn't sounds like an improvement on the current
> > situation to me.
> >
> > Robert -- if we leave pfn_valid() as it is, would a point-hack to
> > memmap_init_zone help, or do you anticipate other problems?
>
> I would suggest to fix the hibernation code as I commented on before
> to use pfn_is_nosave() that defaults to pfn_valid() but uses memblock_
> is_nomap() for arm64. Let's just fix it and see if no other issues
> arise. I am trying to send a patch for this until tomorrow.
I'd rather not use mainline as a guinea pig like this, since I'd be very
surprised if other places don't break given the scope for different
interpretations of pfn_valid.
> I am also going to see how early_pfn_valid() could be redirected to
> use memblock_is_nomap() on arm64. That would "quick fix" the problem,
> though I rather prefer to go further with the current solution.
I don't like either of them, but early_pfn_valid is easier to revert so
let's go with that.
Will
^ permalink raw reply
* [PATCH v5 3/4] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-07 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1620991.lLXgDihv8c@avalon>
2016-12-07 15:25 GMT+01:00 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Bartosz,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
>> Add the vga-bridge node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>> the display automatically.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>> b/arch/arm/boot/dts/da850-lcdk.dts index afcb482..39602eb 100644
>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>> @@ -51,6 +51,51 @@
>> system-clock-frequency = <24576000>;
>> };
>> };
>> +
>> + vga-bridge {
>> + compatible = "ti,ths8135";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port at 0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + vga_bridge_in: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&lcdc_out_vga>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + vga_bridge_out: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&vga_con_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + vga {
>> + compatible = "vga-connector";
>> +
>> + ddc-i2c-bus = <&i2c0>;
>> +
>> + port {
>> + vga_con_in: endpoint {
>> + remote-endpoint = <&vga_bridge_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &pmx_core {
>> @@ -236,3 +281,25 @@
>> &memctrl {
>> status = "okay";
>> };
>> +
>> +&lcdc {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&lcd_pins>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + lcdc_out: port at 1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + lcdc_out_vga: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&vga_bridge_in>;
>> + };
>> + };
>
> Just to make sure you're aware, when there's a single endpoint you can
> simplify the DT by omitting the endpoint number. This would become
>
> lcdc_out: port at 1 {
> reg = <1>;
>
> lcdc_out_vga: endpoint {
> remote-endpoint = <&vga_bridge_in>;
> };
> };
>
> It's entirely up to you, both get my
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>> + };
>> +};
>
> --
> Regards,
>
> Laurent Pinchart
>
Hi Laurent,
thanks for the hint, I'll change it if there's going to be a new
version of the series.
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Vladimir Murzin @ 2016-12-07 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22e20a24-5f1e-a23d-0d18-31dc14179cf5@westnet.com.au>
Hi Greg,
On 07/12/16 14:21, Greg Ungerer wrote:
> Hi Vladimir,
>
> On 07/12/16 23:57, Greg Ungerer wrote:
>> On 07/12/16 19:23, Vladimir Murzin wrote:
>>> On 07/12/16 06:08, Greg Ungerer wrote:
>>>> Does the ARM Versatile machine have a maintainer?
>>>> I have CC'ed this patch set to those names reported by get_maintainer.
>>>> I had no feedback on the first posting of this series back in August.
>>>>
>>>> The following patches support configuring and building the versatile
>>>> machine with a no-MMU kernel.
>>>>
>>>> There is only a few minor changes required. It was previously possible
>>>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>>>> the change to devicetree lost that capability. These changes make it
>>>> possible again.
>>>>
>>>> One patch is a fix for address translation (broken in older kernels
>>>> too),
>>>> two are build problems when CONFIG_MMU is disabled, and the last is the
>>>> actuall configuration changes needed.
>>>>
>>>> The motivation for this is that the versatile machine is well supported
>>>> in qemu. And this provides an excellent platform for development and
>>>> testing no-MMU support on ARM in general. With these patches applied
>>>> it is possible to build and run a kernel with MMU disabled on qemu.
>>>
>>> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work
>>> for you?
>>>
>>> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
>>
>> Sorry I hadn't seen these patches before.
>>
>> Just tried them out. With CONFIG_EXPERT set I can select and
>> build for the Versatile machine with CONFIG_MMU not set. The
>> build is successful, but the resulting kernel doesn't boot.
>>
>> I see that the resulting .config has CONFIG_PLAT_VERSATILE set
>> but not CONFIG_ARCH_VERSATILE. Is this intentional?
>
> Let me revise that. By setting the "Multiple platform selection"
> selection correctly to v5 platforms I did get CONFIG_ARCH_VERSATILE
> set, and could still successfully build the kernel.
>
> A couple of other config options I had to readjust and I can
> boot up this kernel under qemu. So success!
>
Congrats!!!
Thanks for trying these patches! It is really nice to see someone else shows
interest on NOMMU! If you don't mind I'll keep you in Cc when/if I re-spin my
patches ;)
Cheers
Vladimir
>
>> With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
>> into arch/arm/mach-versatile, and you don't get any device tree
>> built.
>>
>> Ultimately to produce a working kernel we will still need my
>> patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
>> No surprise here, this was missing in older kernels too.
>
> So in the end this is the only extra change I needed as well
> to get the running kernel.
>
> Regards
> Greg
>
>
>
^ permalink raw reply
* [PATCH v5 3/4] ARM: dts: da850-lcdk: add the vga-bridge node
From: Laurent Pinchart @ 2016-12-07 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481107365-24839-4-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
> Add the vga-bridge node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts index afcb482..39602eb 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -51,6 +51,51 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga-bridge {
> + compatible = "ti,ths8135";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&lcdc_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + ddc-i2c-bus = <&i2c0>;
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <&vga_bridge_out>;
> + };
> + };
> + };
> };
>
> &pmx_core {
> @@ -236,3 +281,25 @@
> &memctrl {
> status = "okay";
> };
> +
> +&lcdc {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + lcdc_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + lcdc_out_vga: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_bridge_in>;
> + };
> + };
Just to make sure you're aware, when there's a single endpoint you can
simplify the DT by omitting the endpoint number. This would become
lcdc_out: port at 1 {
reg = <1>;
lcdc_out_vga: endpoint {
remote-endpoint = <&vga_bridge_in>;
};
};
It's entirely up to you, both get my
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v5 2/4] drm: bridge: add support for TI ths8135
From: Laurent Pinchart @ 2016-12-07 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJX9b3UqNz_nERH-N58Yw3jkSZ1P+PjjA51x3wTC0So7mQ@mail.gmail.com>
Hi Bartosz,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:45:11 Bartosz Golaszewski wrote:
> 2016-12-07 11:42 GMT+01:00 Bartosz Golaszewski <bgolaszewski@baylibre.com>:
> > THS8135 is a configurable video DAC. Add DT bindings for this chip and
> > use the dumb-vga-dac driver for now as no configuration is required to
> > make it work.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > ---
> >
> > .../bindings/display/bridge/ti,ths8135.txt | 52 +++++++++++++++++
> > drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
You might be asked by DT maintainers to split this in two, but regardless of
whether it's one patch or two, you can add my
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > 2 files changed, 53 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt>
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> > b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt new
> > file mode 100644
> > index 0000000..23cd8ee
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> > @@ -0,0 +1,52 @@
> > +THS8135 Video DAC
> > +-----------------
> > +
> > +This is the binding for Texas Instruments THS8135 Video DAC bridge.
> > +
> > +Required properties:
> > +
> > +- compatible: Must be "ti,ths8135"
> > +
> > +Required nodes:
> > +
> > +This device has two video ports. Their connections are modelled using the
> > OF +graph bindings specified in
> > Documentation/devicetree/bindings/graph.txt. +
> > +- Video port 0 for RGB input
> > +- Video port 1 for VGA output
> > +
> > +Example
> > +-------
> > +
> > +vga-bridge {
> > + compatible = "ti,ths8135";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + vga_bridge_in: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&lcdc_out_vga>;
> > + };
> > + };
> > +
> > + port at 1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <1>;
> > +
> > + vga_bridge_out: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&vga_con_in>;
> > + };
> > + };
> > + };
> > +};
> > diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > b/drivers/gpu/drm/bridge/dumb-vga-dac.c index afec232..498fa75 100644
> > --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > @@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device
> > *pdev)>
> > static const struct of_device_id dumb_vga_match[] = {
> >
> > { .compatible = "dumb-vga-dac" },
> >
> > + { .compatible = "ti,ths8135" },
> >
> > {},
> >
> > };
> > MODULE_DEVICE_TABLE(of, dumb_vga_match);
> >
> > --
> > 2.9.3
>
> + Maxime
>
> Sorry, I forgot to include your e-mail.
>
> Bartosz
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-12-07 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a2ab1e0c-d24b-ac8d-fb9a-4ae7271455b9@uclinux.org>
Hi Vladimir,
On 07/12/16 23:57, Greg Ungerer wrote:
> On 07/12/16 19:23, Vladimir Murzin wrote:
>> On 07/12/16 06:08, Greg Ungerer wrote:
>>> Does the ARM Versatile machine have a maintainer?
>>> I have CC'ed this patch set to those names reported by get_maintainer.
>>> I had no feedback on the first posting of this series back in August.
>>>
>>> The following patches support configuring and building the versatile
>>> machine with a no-MMU kernel.
>>>
>>> There is only a few minor changes required. It was previously possible
>>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>>> the change to devicetree lost that capability. These changes make it
>>> possible again.
>>>
>>> One patch is a fix for address translation (broken in older kernels
>>> too),
>>> two are build problems when CONFIG_MMU is disabled, and the last is the
>>> actuall configuration changes needed.
>>>
>>> The motivation for this is that the versatile machine is well supported
>>> in qemu. And this provides an excellent platform for development and
>>> testing no-MMU support on ARM in general. With these patches applied
>>> it is possible to build and run a kernel with MMU disabled on qemu.
>>
>> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work
>> for you?
>>
>> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
>
> Sorry I hadn't seen these patches before.
>
> Just tried them out. With CONFIG_EXPERT set I can select and
> build for the Versatile machine with CONFIG_MMU not set. The
> build is successful, but the resulting kernel doesn't boot.
>
> I see that the resulting .config has CONFIG_PLAT_VERSATILE set
> but not CONFIG_ARCH_VERSATILE. Is this intentional?
Let me revise that. By setting the "Multiple platform selection"
selection correctly to v5 platforms I did get CONFIG_ARCH_VERSATILE
set, and could still successfully build the kernel.
A couple of other config options I had to readjust and I can
boot up this kernel under qemu. So success!
> With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
> into arch/arm/mach-versatile, and you don't get any device tree
> built.
>
> Ultimately to produce a working kernel we will still need my
> patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
> No surprise here, this was missing in older kernels too.
So in the end this is the only extra change I needed as well
to get the running kernel.
Regards
Greg
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Linus Walleij @ 2016-12-07 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481090912-29835-1-git-send-email-gerg@uclinux.org>
On Wed, Dec 7, 2016 at 7:08 AM, Greg Ungerer <gerg@uclinux.org> wrote:
> Does the ARM Versatile machine have a maintainer?
Russell did the original port so he tends to look after it a bit.
Rob Herring and myself tend to maintain it a bit too.
> I have CC'ed this patch set to those names reported by get_maintainer.
> I had no feedback on the first posting of this series back in August.
Sorry.
> The following patches support configuring and building the versatile
> machine with a no-MMU kernel.
Which I think is pretty nice.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Vladimir Murzin @ 2016-12-07 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a2ab1e0c-d24b-ac8d-fb9a-4ae7271455b9@uclinux.org>
On 07/12/16 13:57, Greg Ungerer wrote:
> Hi Vladimir,
>
> On 07/12/16 19:23, Vladimir Murzin wrote:
>> Hi Greg,
>>
>> On 07/12/16 06:08, Greg Ungerer wrote:
>>> Does the ARM Versatile machine have a maintainer?
>>> I have CC'ed this patch set to those names reported by get_maintainer.
>>> I had no feedback on the first posting of this series back in August.
>>>
>>> The following patches support configuring and building the versatile
>>> machine with a no-MMU kernel.
>>>
>>> There is only a few minor changes required. It was previously possible
>>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>>> the change to devicetree lost that capability. These changes make it
>>> possible again.
>>>
>>> One patch is a fix for address translation (broken in older kernels too),
>>> two are build problems when CONFIG_MMU is disabled, and the last is the
>>> actuall configuration changes needed.
>>>
>>> The motivation for this is that the versatile machine is well supported
>>> in qemu. And this provides an excellent platform for development and
>>> testing no-MMU support on ARM in general. With these patches applied
>>> it is possible to build and run a kernel with MMU disabled on qemu.
>>
>> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work for you?
>>
>> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
>
> Sorry I hadn't seen these patches before.
>
> Just tried them out. With CONFIG_EXPERT set I can select and
> build for the Versatile machine with CONFIG_MMU not set. The
> build is successful, but the resulting kernel doesn't boot.
It is why "no guarantee" there ;)
>
> I see that the resulting .config has CONFIG_PLAT_VERSATILE set
> but not CONFIG_ARCH_VERSATILE. Is this intentional?
No.
>
> With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
> into arch/arm/mach-versatile, and you don't get any device tree
> built.
>
I've just done:
$ make ARCH=arm versatile_defconfig nommu.config
...
$ grep VERSATILE .config 1 CONFIG_ARCH_VERSATILE=y
CONFIG_PLAT_VERSATILE=y
CONFIG_I2C_VERSATILE=y
CONFIG_POWER_RESET_VERSATILE=y
CONFIG_PLAT_VERSATILE_CLCD=y
# CONFIG_LEDS_VERSATILE is not set
CONFIG_COMMON_CLK_VERSATILE=y
CONFIG_CLKSRC_VERSATILE=y
CONFIG_VERSATILE_FPGA_IRQ=y
CONFIG_VERSATILE_FPGA_IRQ_NR=4
CONFIG_DEBUG_VERSATILE=y
$ cat arch/arm/configs/nommu.config
CONFIG_EXPERT=y
# CONFIG_MMU is not set
I didn't submit nommu config fragment, but it is is what I've been using to
simplify defconfigs and randconfig builds.
> Ultimately to produce a working kernel we will still need my
> patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
> No surprise here, this was missing in older kernels too.
Agreed.
Cheers
Vladimir
>
> Regards
> Greg
>
>
>>>
>>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>>> ---
>>> arch/arm/Kconfig | 10 ++++++++++
>>> arch/arm/Kconfig.debug | 3 ++-
>>> arch/arm/include/asm/mach/map.h | 1 +
>>> arch/arm/mach-versatile/Kconfig | 3 ++-
>>> arch/arm/mach-versatile/Makefile.boot | 3 +++
>>> arch/arm/mach-versatile/versatile_dt.c | 4 ++++
>>> 6 files changed, 22 insertions(+), 2 deletions(-)
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>>
>
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Linus Walleij @ 2016-12-07 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481093992-30520-2-git-send-email-gerg@uclinux.org>
On Wed, Dec 7, 2016 at 7:59 AM, Greg Ungerer <gerg@uclinux.org> wrote:
> The motivation for this is that the versatile machine is well supported
> in qemu. And this provides an excellent platform for development and
> testing no-MMU support on ARM in general.
>
> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Pretty cool eh?
Have you tested it on real hardware?
Otherwise I can test it if I have a git branch
I can pull in and compile.
Another target I had in mind was the Integrator which
incidentally supports a bunch of the old noMMU core
tiles where we can swap in an ARM946, which I guess
could work with this?
> --- a/arch/arm/mach-versatile/Kconfig
> +++ b/arch/arm/mach-versatile/Kconfig
> @@ -1,12 +1,13 @@
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family"
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
> select ARM_AMBA
> select ARM_TIMER_SP804
> select ARM_VIC
> select CLKSRC_VERSATILE
> select COMMON_CLK_VERSATILE
> select CPU_ARM926T
> + select GPIOLIB
Not really related but I don't mind.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/3] soc: zte: pm_domains: Add support for zx296718 board
From: Shawn Guo @ 2016-12-07 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481091204-6559-2-git-send-email-baoyou.xie@linaro.org>
On Wed, Dec 07, 2016 at 02:13:23PM +0800, Baoyou Xie wrote:
> This patch introduces the power domain driver of zx296718
> which belongs to zte's 2967 family.
The 'board' in subject is not appropriate, as zx296718 is a SoC, not
board.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
When you repost, tags like Reviewed-by, Acked-by, and Tested-by provided
by people on your patches should be added after your Signed-off-by line.
Specifically, the Reviewed-by from Jun Nie on v2 of the patch should be
added here.
> ---
> drivers/soc/zte/Makefile | 2 +-
> drivers/soc/zte/zx296718_pm_domains.c | 194 ++++++++++++++++++++++++++++++++++
> 2 files changed, 195 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
>
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> index 97ac8ea..2d2a2cc 100644
> --- a/drivers/soc/zte/Makefile
> +++ b/drivers/soc/zte/Makefile
> @@ -1,4 +1,4 @@
> #
> # zx SOC drivers
> #
> -obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o zx296718_pm_domains.o
I would suggest to name it pm_domains_zx296718.o, so that power domain
files can alphabetically grouped. Also, we may want to write the
Makefile like below, so that a target can be added or removed easily.
obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains_zx296718.o
> diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
> new file mode 100644
> index 0000000..5355b94
> --- /dev/null
> +++ b/drivers/soc/zte/zx296718_pm_domains.c
> @@ -0,0 +1,194 @@
> +/*
> + * Copyright (C) 2015 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +#include <dt-bindings/arm/zte_pm_domains.h>
The header is added by another patch. You should include that patch
into the series, as there is dependency between patches.
> +#include "pm_domains.h"
> +
> +static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
> + [REG_CLKEN] = 0x18,
> + [REG_ISOEN] = 0x1c,
> + [REG_RSTEN] = 0x20,
> + [REG_PWREN] = 0x24,
> + [REG_ACK_SYNC] = 0x28,
> +};
> +
> +enum {
> + PCU_DM_VOU = 0,
> + PCU_DM_SAPPU,
> + PCU_DM_VDE,
> + PCU_DM_VCE,
> + PCU_DM_HDE,
> + PCU_DM_VIU,
> + PCU_DM_USB20,
> + PCU_DM_USB21,
> + PCU_DM_USB30,
> + PCU_DM_HSIC,
> + PCU_DM_GMAC,
> + PCU_DM_TS,
> +};
> +
> +static struct zx_pm_domain vou_domain = {
> + .dm = {
> + .name = "vou_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_VOU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
Please have a newline between struct variables.
> +static struct zx_pm_domain sappu_domain = {
> + .dm = {
> + .name = "sappu_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_SAPPU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain vde_domain = {
> + .dm = {
> + .name = "vde_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_VDE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain vce_domain = {
> + .dm = {
> + .name = "vce_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_VCE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain hde_domain = {
> + .dm = {
> + .name = "hde_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_HDE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx_pm_domain viu_domain = {
> + .dm = {
> + .name = "viu_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_VIU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain usb20_domain = {
> + .dm = {
> + .name = "usb20_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_USB20,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain usb21_domain = {
> + .dm = {
> + .name = "usb21_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_USB21,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain usb30_domain = {
> + .dm = {
> + .name = "usb30_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_USB30,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain hsic_domain = {
> + .dm = {
> + .name = "hsic_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_HSIC,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain gmac_domain = {
> + .dm = {
> + .name = "gmac_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
> + },
> + .bit = PCU_DM_GMAC,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain ts_domain = {
> + .dm = {
> + .name = "ts_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
Can we assign these two function hooks in zx_pd_probe()? If so, both
functions can be static ones in pm_domains.c.
> + },
> + .bit = PCU_DM_TS,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +struct generic_pm_domain *zx296718_pm_domains[] = {
static?
> + [DM_ZX296718_SAPPU] = &sappu_domain.dm,
> + [DM_ZX296718_VDE] = &vde_domain.dm,
> + [DM_ZX296718_VCE] = &vce_domain.dm,
> + [DM_ZX296718_HDE] = &hde_domain.dm,
> + [DM_ZX296718_VIU] = &viu_domain.dm,
> + [DM_ZX296718_USB20] = &usb20_domain.dm,
> + [DM_ZX296718_USB21] = &usb21_domain.dm,
> + [DM_ZX296718_USB30] = &usb30_domain.dm,
> + [DM_ZX296718_HSIC] = &hsic_domain.dm,
> + [DM_ZX296718_GMAC] = &gmac_domain.dm,
> + [DM_ZX296718_TS] = &ts_domain.dm,
> + [DM_ZX296718_VOU] = &vou_domain.dm,
> +};
> +
> +static int zx296718_pd_probe(struct platform_device *pdev)
> +{
> + return zx_pd_probe(pdev,
> + zx296718_pm_domains,
> + ARRAY_SIZE(zx296718_pm_domains));
> +}
> +
> +static const struct of_device_id zx296718_pm_domain_matches[] = {
> + { .compatible = "zte,zx296718-pcu", },
Where is the patch documents the bindings?
Shawn
> + { },
> +};
> +
> +static struct platform_driver zx296718_pd_driver = {
> + .driver = {
> + .name = "zx-powerdomain",
> + .owner = THIS_MODULE,
> + .of_match_table = zx296718_pm_domain_matches,
> + },
> + .probe = zx296718_pd_probe,
> +};
> +
> +static int __init zx296718_pd_init(void)
> +{
> + return platform_driver_register(&zx296718_pd_driver);
> +}
> +subsys_initcall(zx296718_pd_init);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-12-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5847D4F8.1080108@arm.com>
Hi Vladimir,
On 07/12/16 19:23, Vladimir Murzin wrote:
> Hi Greg,
>
> On 07/12/16 06:08, Greg Ungerer wrote:
>> Does the ARM Versatile machine have a maintainer?
>> I have CC'ed this patch set to those names reported by get_maintainer.
>> I had no feedback on the first posting of this series back in August.
>>
>> The following patches support configuring and building the versatile
>> machine with a no-MMU kernel.
>>
>> There is only a few minor changes required. It was previously possible
>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>> the change to devicetree lost that capability. These changes make it
>> possible again.
>>
>> One patch is a fix for address translation (broken in older kernels too),
>> two are build problems when CONFIG_MMU is disabled, and the last is the
>> actuall configuration changes needed.
>>
>> The motivation for this is that the versatile machine is well supported
>> in qemu. And this provides an excellent platform for development and
>> testing no-MMU support on ARM in general. With these patches applied
>> it is possible to build and run a kernel with MMU disabled on qemu.
>
> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work for you?
>
> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
Sorry I hadn't seen these patches before.
Just tried them out. With CONFIG_EXPERT set I can select and
build for the Versatile machine with CONFIG_MMU not set. The
build is successful, but the resulting kernel doesn't boot.
I see that the resulting .config has CONFIG_PLAT_VERSATILE set
but not CONFIG_ARCH_VERSATILE. Is this intentional?
With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
into arch/arm/mach-versatile, and you don't get any device tree
built.
Ultimately to produce a working kernel we will still need my
patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
No surprise here, this was missing in older kernels too.
Regards
Greg
>>
>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>> ---
>> arch/arm/Kconfig | 10 ++++++++++
>> arch/arm/Kconfig.debug | 3 ++-
>> arch/arm/include/asm/mach/map.h | 1 +
>> arch/arm/mach-versatile/Kconfig | 3 ++-
>> arch/arm/mach-versatile/Makefile.boot | 3 +++
>> arch/arm/mach-versatile/versatile_dt.c | 4 ++++
>> 6 files changed, 22 insertions(+), 2 deletions(-)
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
>
^ permalink raw reply
* [PATCHv4 09/10] mm/usercopy: Switch to using lm_alias
From: Mark Rutland @ 2016-12-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKTdZUbbHU91mbN+Qy80AGXRhpzdLNXr3oxxZyxAzmjmQ@mail.gmail.com>
On Tue, Dec 06, 2016 at 12:10:50PM -0800, Kees Cook wrote:
> On Tue, Dec 6, 2016 at 10:18 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Nov 29, 2016 at 11:39:44AM -0800, Kees Cook wrote:
> >> On Tue, Nov 29, 2016 at 10:55 AM, Laura Abbott <labbott@redhat.com> wrote:
> >> >
> >> > The usercopy checking code currently calls __va(__pa(...)) to check for
> >> > aliases on symbols. Switch to using lm_alias instead.
> >> >
> >> > Signed-off-by: Laura Abbott <labbott@redhat.com>
> >>
> >> Acked-by: Kees Cook <keescook@chromium.org>
> >>
> >> I should probably add a corresponding alias test to lkdtm...
> >>
> >> -Kees
> >
> > Something like the below?
> >
> > It uses lm_alias(), so it depends on Laura's patches. We seem to do the
> > right thing, anyhow:
>
> Cool, this looks good. What happens on systems without an alias?
In that case, lm_alias() should be an identity function, and we'll just
hit the usual kernel address (i.e. it should be identical to
USERCOPY_KERNEL).
> Laura, feel free to add this to your series:
>
> Acked-by: Kees Cook <keescook@chromium.org>
I'm happy with that, or I can resend this as a proper patch once the
rest is in.
Thanks,
Mark.
^ permalink raw reply
* [Question] New mmap64 syscall?
From: Florian Weimer @ 2016-12-07 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206185440.GA4654@yury-N73SV>
On 12/06/2016 07:54 PM, Yury Norov wrote:
> 3. Introduce new mmap64() syscall like this:
> sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off);
> (The pointer here because otherwise we have 7 args, if simply pass off_hi and
> off_lo in registers.)
I would prefer a batched mmap/munmap/mremap/mprotect/madvise interface,
so that VM changes can be coalesced and the output reduced. This
interface could then be used to implement mmap on 32-bit architectures
as well because the offset restrictions would not apply there.
Thanks,
Florian
^ permalink raw reply
* [PATCH 8/8] efi: Handle secure boot from UEFI-2.6 [ver #5]
From: David Howells @ 2016-12-07 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1
if we're to engage lockdown mode.
Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/firmware/efi/libstub/secureboot.c | 16 +++++++++++++++-
include/linux/efi.h | 4 ++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
index ba6ef717c66f..333b1594cce4 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -22,6 +22,9 @@ static const efi_char16_t const efi_SecureBoot_name[] = {
static const efi_char16_t const efi_SetupMode_name[] = {
'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
};
+static const efi_char16_t const efi_DeployedMode_name[] = {
+ 'D', 'e', 'p', 'l', 'o', 'y', 'e', 'd', 'M', 'o', 'd', 'e', 0
+};
/* SHIM variables */
static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
@@ -40,7 +43,7 @@ static efi_char16_t const shim_MokSBState_name[] = {
enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
{
u32 attr;
- u8 secboot, setupmode, moksbstate;
+ u8 secboot, setupmode, deployedmode, moksbstate;
unsigned long size;
efi_status_t status;
@@ -59,6 +62,17 @@ enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
if (secboot == 0 || setupmode == 1)
goto secure_boot_disabled;
+ /* UEFI-2.6 requires DeployedMode to be 1. */
+ if (sys_table_arg->hdr.revision >= EFI_2_60_SYSTEM_TABLE_REVISION) {
+ size = sizeof(deployedmode);
+ status = get_efi_var(efi_DeployedMode_name, &efi_variable_guid,
+ NULL, &size, &deployedmode);
+ if (status != EFI_SUCCESS)
+ goto out_efi_err;
+ if (deployedmode == 0)
+ goto secure_boot_disabled;
+ }
+
/* See if a user has put shim into insecure mode. If so, and if the
* variable doesn't have the runtime attribute set, we might as well
* honor that.
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 135ca9c0c0b5..e1893f5002c3 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -645,6 +645,10 @@ typedef struct {
#define EFI_SYSTEM_TABLE_SIGNATURE ((u64)0x5453595320494249ULL)
+#define EFI_2_60_SYSTEM_TABLE_REVISION ((2 << 16) | (60))
+#define EFI_2_50_SYSTEM_TABLE_REVISION ((2 << 16) | (50))
+#define EFI_2_40_SYSTEM_TABLE_REVISION ((2 << 16) | (40))
+#define EFI_2_31_SYSTEM_TABLE_REVISION ((2 << 16) | (31))
#define EFI_2_30_SYSTEM_TABLE_REVISION ((2 << 16) | (30))
#define EFI_2_20_SYSTEM_TABLE_REVISION ((2 << 16) | (20))
#define EFI_2_10_SYSTEM_TABLE_REVISION ((2 << 16) | (10))
^ permalink raw reply related
* [PATCH 7/8] efi: Add EFI_SECURE_BOOT bit [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
From: Josh Boyer <jwboyer@fedoraproject.org>
UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit
that can be passed to efi_enabled() to find out whether secure boot is
enabled.
This will be used by the SysRq+x handler, registered by the x86 arch, to find
out whether secure boot mode is enabled so that it can be disabled.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---
arch/x86/kernel/setup.c | 15 +++++++++++++++
include/linux/efi.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9c337b0e8ba7..d8972ec6257d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1152,6 +1152,21 @@ void __init setup_arch(char **cmdline_p)
/* Allocate bigger log buffer */
setup_log_buf(1);
+ if (IS_ENABLED(CONFIG_EFI)) {
+ switch (boot_params.secure_boot) {
+ case efi_secureboot_mode_disabled:
+ pr_info("Secure boot disabled\n");
+ break;
+ case efi_secureboot_mode_enabled:
+ set_bit(EFI_SECURE_BOOT, &efi.flags);
+ pr_info("Secure boot enabled\n");
+ break;
+ default:
+ pr_info("Secure boot could not be determined\n");
+ break;
+ }
+ }
+
reserve_initrd();
acpi_table_upgrade();
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 92e23f03045e..135ca9c0c0b5 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1066,6 +1066,7 @@ extern int __init efi_setup_pcdp_console(char *);
#define EFI_ARCH_1 7 /* First arch-specific bit */
#define EFI_DBG 8 /* Print additional debug info at runtime */
#define EFI_NX_PE_DATA 9 /* Can runtime data regions be mapped non-executable? */
+#define EFI_SECURE_BOOT 10 /* Are we in Secure Boot mode? */
#ifdef CONFIG_EFI
/*
^ permalink raw reply related
* [PATCH 6/8] efi: Disable secure boot if shim is in insecure mode [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
From: Josh Boyer <jwboyer@fedoraproject.org>
A user can manually tell the shim boot loader to disable validation of
images it loads. When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set. Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/firmware/efi/libstub/secureboot.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
index 70e2a36577d4..ba6ef717c66f 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -23,6 +23,12 @@ static const efi_char16_t const efi_SetupMode_name[] = {
'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
};
+/* SHIM variables */
+static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
+static efi_char16_t const shim_MokSBState_name[] = {
+ 'M', 'o', 'k', 'S', 'B', 'S', 't', 'a', 't', 'e', 0
+};
+
#define get_efi_var(name, vendor, ...) \
efi_call_runtime(get_variable, \
(efi_char16_t *)(name), (efi_guid_t *)(vendor), \
@@ -33,7 +39,8 @@ static const efi_char16_t const efi_SetupMode_name[] = {
*/
enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
{
- u8 secboot, setupmode;
+ u32 attr;
+ u8 secboot, setupmode, moksbstate;
unsigned long size;
efi_status_t status;
@@ -52,6 +59,21 @@ enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
if (secboot == 0 || setupmode == 1)
goto secure_boot_disabled;
+ /* See if a user has put shim into insecure mode. If so, and if the
+ * variable doesn't have the runtime attribute set, we might as well
+ * honor that.
+ */
+ size = sizeof(moksbstate);
+ status = get_efi_var(shim_MokSBState_name, &shim_guid,
+ &attr, &size, &moksbstate);
+
+ /* If it fails, we don't care why. Default to secure */
+ if (status != EFI_SUCCESS)
+ goto secure_boot_enabled;
+ if (!(attr & EFI_VARIABLE_RUNTIME_ACCESS) && moksbstate == 1)
+ goto secure_boot_disabled;
+
+secure_boot_enabled:
pr_efi(sys_table_arg, "UEFI Secure Boot is enabled.\n");
return efi_secureboot_mode_enabled;
^ permalink raw reply related
* [PATCH 5/8] efi: Get the secure boot status [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
Get the firmware's secure-boot status in the kernel boot wrapper and stash
it somewhere that the main kernel image can find.
The efi_get_secureboot() function is extracted from the arm stub and (a)
generalised so that it can be called from x86 and (b) made to use
efi_call_runtime() so that it can be run in mixed-mode.
Suggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: David Howells <dhowells@redhat.com>
---
Documentation/x86/zero-page.txt | 2 +
arch/x86/boot/compressed/eboot.c | 2 +
arch/x86/boot/compressed/head_32.S | 1
arch/x86/boot/compressed/head_64.S | 1
arch/x86/include/asm/bootparam_utils.h | 5 +-
arch/x86/include/uapi/asm/bootparam.h | 3 +
arch/x86/kernel/asm-offsets.c | 1
drivers/firmware/efi/libstub/Makefile | 2 -
drivers/firmware/efi/libstub/arm-stub.c | 58 +------------------------
drivers/firmware/efi/libstub/secureboot.c | 66 +++++++++++++++++++++++++++++
include/linux/efi.h | 8 ++++
11 files changed, 90 insertions(+), 59 deletions(-)
create mode 100644 drivers/firmware/efi/libstub/secureboot.c
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index 95a4d34af3fd..b8527c6b7646 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -31,6 +31,8 @@ Offset Proto Name Meaning
1E9/001 ALL eddbuf_entries Number of entries in eddbuf (below)
1EA/001 ALL edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
(below)
+1EB/001 ALL kbd_status Numlock is enabled
+1EC/001 ALL secure_boot Secure boot is enabled in the firmware
1EF/001 ALL sentinel Used to detect broken bootloaders
290/040 ALL edd_mbr_sig_buffer EDD MBR signatures
2D0/A00 ALL e820_map E820 memory map table
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index c8c32ebcdfdb..5b151c262ac2 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1158,6 +1158,8 @@ struct boot_params *efi_main(struct efi_config *c,
else
setup_boot_services32(efi_early);
+ boot_params->secure_boot = efi_get_secureboot(sys_table);
+
setup_graphics(boot_params);
setup_efi_pci(boot_params);
diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
index d85b9625e836..c635f7e32f5c 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -61,6 +61,7 @@
__HEAD
ENTRY(startup_32)
+ movb $0, BP_secure_boot(%esi)
#ifdef CONFIG_EFI_STUB
jmp preferred_addr
diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index beab8322f72a..ccd2c7461b7f 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -244,6 +244,7 @@ ENTRY(startup_64)
* that maps our entire kernel(text+data+bss+brk), zero page
* and command line.
*/
+ movb $0, BP_secure_boot(%rsi)
#ifdef CONFIG_EFI_STUB
/*
* The entry point for the PE/COFF executable is efi_pe_entry, so
diff --git a/arch/x86/include/asm/bootparam_utils.h b/arch/x86/include/asm/bootparam_utils.h
index 4a8cb8d7cbd5..7e16d53ff6a3 100644
--- a/arch/x86/include/asm/bootparam_utils.h
+++ b/arch/x86/include/asm/bootparam_utils.h
@@ -38,9 +38,10 @@ static void sanitize_boot_params(struct boot_params *boot_params)
memset(&boot_params->ext_ramdisk_image, 0,
(char *)&boot_params->efi_info -
(char *)&boot_params->ext_ramdisk_image);
- memset(&boot_params->kbd_status, 0,
+ boot_params->kbd_status = 0;
+ memset(&boot_params->_pad5, 0,
(char *)&boot_params->hdr -
- (char *)&boot_params->kbd_status);
+ (char *)&boot_params->_pad5);
memset(&boot_params->_pad7[0], 0,
(char *)&boot_params->edd_mbr_sig_buffer[0] -
(char *)&boot_params->_pad7[0]);
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index b10bf319ed20..5138dacf8bb8 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -135,7 +135,8 @@ struct boot_params {
__u8 eddbuf_entries; /* 0x1e9 */
__u8 edd_mbr_sig_buf_entries; /* 0x1ea */
__u8 kbd_status; /* 0x1eb */
- __u8 _pad5[3]; /* 0x1ec */
+ __u8 secure_boot; /* 0x1ec */
+ __u8 _pad5[2]; /* 0x1ed */
/*
* The sentinel is set to a nonzero value (0xff) in header.S.
*
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index c62e015b126c..de827d6ac8c2 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -81,6 +81,7 @@ void common(void) {
BLANK();
OFFSET(BP_scratch, boot_params, scratch);
+ OFFSET(BP_secure_boot, boot_params, secure_boot);
OFFSET(BP_loadflags, boot_params, hdr.loadflags);
OFFSET(BP_hardware_subarch, boot_params, hdr.hardware_subarch);
OFFSET(BP_version, boot_params, hdr.version);
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 6621b13c370f..9af966863612 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -28,7 +28,7 @@ OBJECT_FILES_NON_STANDARD := y
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
-lib-y := efi-stub-helper.o gop.o
+lib-y := efi-stub-helper.o gop.o secureboot.o
# include the stub's generic dependencies from lib/ when building for ARM/arm64
arm-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c sort.c
diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index b4f7d78f9e8b..06d503419071 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -20,52 +20,6 @@
bool __nokaslr;
-static int efi_get_secureboot(efi_system_table_t *sys_table_arg)
-{
- static efi_char16_t const sb_var_name[] = {
- 'S', 'e', 'c', 'u', 'r', 'e', 'B', 'o', 'o', 't', 0 };
- static efi_char16_t const sm_var_name[] = {
- 'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0 };
-
- efi_guid_t var_guid = EFI_GLOBAL_VARIABLE_GUID;
- efi_get_variable_t *f_getvar = sys_table_arg->runtime->get_variable;
- u8 val;
- unsigned long size = sizeof(val);
- efi_status_t status;
-
- status = f_getvar((efi_char16_t *)sb_var_name, (efi_guid_t *)&var_guid,
- NULL, &size, &val);
-
- if (status != EFI_SUCCESS)
- goto out_efi_err;
-
- if (val == 0)
- return 0;
-
- status = f_getvar((efi_char16_t *)sm_var_name, (efi_guid_t *)&var_guid,
- NULL, &size, &val);
-
- if (status != EFI_SUCCESS)
- goto out_efi_err;
-
- if (val == 1)
- return 0;
-
- return 1;
-
-out_efi_err:
- switch (status) {
- case EFI_NOT_FOUND:
- return 0;
- case EFI_DEVICE_ERROR:
- return -EIO;
- case EFI_SECURITY_VIOLATION:
- return -EACCES;
- default:
- return -EINVAL;
- }
-}
-
efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
void *__image, void **__fh)
{
@@ -226,7 +180,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
efi_guid_t loaded_image_proto = LOADED_IMAGE_PROTOCOL_GUID;
unsigned long reserve_addr = 0;
unsigned long reserve_size = 0;
- int secure_boot = 0;
+ enum efi_secureboot_mode secure_boot = efi_secureboot_mode_unknown;
struct screen_info *si;
/* Check if we were booted by the EFI firmware */
@@ -296,19 +250,13 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
pr_efi_err(sys_table, "Failed to parse EFI cmdline options\n");
secure_boot = efi_get_secureboot(sys_table);
- if (secure_boot > 0)
- pr_efi(sys_table, "UEFI Secure Boot is enabled.\n");
-
- if (secure_boot < 0) {
- pr_efi_err(sys_table,
- "could not determine UEFI Secure Boot status.\n");
- }
/*
* Unauthenticated device tree data is a security hazard, so
* ignore 'dtb=' unless UEFI Secure Boot is disabled.
*/
- if (secure_boot != 0 && strstr(cmdline_ptr, "dtb=")) {
+ if (secure_boot != efi_secureboot_mode_disabled &&
+ strstr(cmdline_ptr, "dtb=")) {
pr_efi(sys_table, "Ignoring DTB from command line.\n");
} else {
status = handle_cmdline_files(sys_table, image, cmdline_ptr,
diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
new file mode 100644
index 000000000000..70e2a36577d4
--- /dev/null
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -0,0 +1,66 @@
+/*
+ * Secure boot handling.
+ *
+ * Copyright (C) 2013,2014 Linaro Limited
+ * Roy Franz <roy.franz at linaro.org
+ * Copyright (C) 2013 Red Hat, Inc.
+ * Mark Salter <msalter@redhat.com>
+ *
+ * This file is part of the Linux kernel, and is made available under the
+ * terms of the GNU General Public License version 2.
+ *
+ */
+
+#include <linux/efi.h>
+#include <asm/efi.h>
+
+/* BIOS variables */
+static const efi_guid_t efi_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
+static const efi_char16_t const efi_SecureBoot_name[] = {
+ 'S', 'e', 'c', 'u', 'r', 'e', 'B', 'o', 'o', 't', 0
+};
+static const efi_char16_t const efi_SetupMode_name[] = {
+ 'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
+};
+
+#define get_efi_var(name, vendor, ...) \
+ efi_call_runtime(get_variable, \
+ (efi_char16_t *)(name), (efi_guid_t *)(vendor), \
+ __VA_ARGS__);
+
+/*
+ * Determine whether we're in secure boot mode. We return:
+ */
+enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
+{
+ u8 secboot, setupmode;
+ unsigned long size;
+ efi_status_t status;
+
+ size = sizeof(secboot);
+ status = get_efi_var(efi_SecureBoot_name, &efi_variable_guid,
+ NULL, &size, &secboot);
+ if (status != EFI_SUCCESS)
+ goto out_efi_err;
+
+ size = sizeof(setupmode);
+ status = get_efi_var(efi_SetupMode_name, &efi_variable_guid,
+ NULL, &size, &setupmode);
+ if (status != EFI_SUCCESS)
+ goto out_efi_err;
+
+ if (secboot == 0 || setupmode == 1)
+ goto secure_boot_disabled;
+
+ pr_efi(sys_table_arg, "UEFI Secure Boot is enabled.\n");
+ return efi_secureboot_mode_enabled;
+
+secure_boot_disabled:
+ return efi_secureboot_mode_disabled;
+
+out_efi_err:
+ pr_efi_err(sys_table_arg, "Could not determine UEFI Secure Boot status.\n");
+ if (status == EFI_NOT_FOUND)
+ goto secure_boot_disabled;
+ return efi_secureboot_mode_unknown;
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index c7904556d7a8..92e23f03045e 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1477,6 +1477,14 @@ efi_status_t efi_setup_gop(efi_system_table_t *sys_table_arg,
bool efi_runtime_disabled(void);
extern void efi_call_virt_check_flags(unsigned long flags, const char *call);
+enum efi_secureboot_mode {
+ efi_secureboot_mode_unset,
+ efi_secureboot_mode_unknown,
+ efi_secureboot_mode_disabled,
+ efi_secureboot_mode_enabled,
+};
+enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table);
+
/*
* Arch code can implement the following three template macros, avoiding
* reptition for the void/non-void return cases of {__,}efi_call_virt():
^ permalink raw reply related
* [PATCH 4/8] efi: Add SHIM and image security database GUID definitions [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
Add the definitions for shim and image security database, both of which
are used widely in various Linux distros.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
include/linux/efi.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 93a82de167eb..c7904556d7a8 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -610,6 +610,9 @@ void efi_native_runtime_setup(void);
#define EFI_CONSOLE_OUT_DEVICE_GUID EFI_GUID(0xd3b36f2c, 0xd551, 0x11d4, 0x9a, 0x46, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
#define APPLE_PROPERTIES_PROTOCOL_GUID EFI_GUID(0x91bd12fe, 0xf6c3, 0x44fb, 0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0)
+#define EFI_IMAGE_SECURITY_DATABASE_GUID EFI_GUID(0xd719b2cb, 0x3d3a, 0x4596, 0xa3, 0xbc, 0xda, 0xd0, 0x0e, 0x67, 0x65, 0x6f)
+#define EFI_SHIM_LOCK_GUID EFI_GUID(0x605dab50, 0xe046, 0x4300, 0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23)
+
/*
* This GUID is used to pass to the kernel proper the struct screen_info
* structure that was populated by the stub based on the GOP protocol instance
^ permalink raw reply related
* [PATCH 3/8] arm/efi: Allow invocation of arbitrary runtime services [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
efi_call_runtime() is provided for x86 to be able abstract mixed mode
support. Provide this for ARM also so that common code work in mixed mode
also.
Suggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: David Howells <dhowells@redhat.com>
---
arch/arm/include/asm/efi.h | 1 +
arch/arm64/include/asm/efi.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
index 0b06f5341b45..e4e6a9d6a825 100644
--- a/arch/arm/include/asm/efi.h
+++ b/arch/arm/include/asm/efi.h
@@ -55,6 +55,7 @@ void efi_virtmap_unload(void);
#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
#define __efi_call_early(f, ...) f(__VA_ARGS__)
+#define efi_call_runtime(f, ...) sys_table_arg->runtime->f(__VA_ARGS__)
#define efi_is_64bit() (false)
#define efi_call_proto(protocol, f, instance, ...) \
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 771b3f0bc757..d74ae223d89f 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -49,6 +49,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
#define __efi_call_early(f, ...) f(__VA_ARGS__)
+#define efi_call_runtime(f, ...) sys_table_arg->runtime->f(__VA_ARGS__)
#define efi_is_64bit() (true)
#define efi_call_proto(protocol, f, instance, ...) \
^ permalink raw reply related
* [PATCH 2/8] x86/efi: Allow invocation of arbitrary runtime services [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
Provide the ability to perform mixed-mode runtime service calls for x86 in
the same way that commit 0a637ee61247bd4bed9b2a07568ef7a1cfc76187
("x86/efi: Allow invocation of arbitrary boot services") provides the
ability to invoke arbitrary boot services.
Suggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: David Howells <dhowells@redhat.com>
---
arch/x86/boot/compressed/eboot.c | 1 +
arch/x86/boot/compressed/head_32.S | 6 +++---
arch/x86/boot/compressed/head_64.S | 8 ++++----
arch/x86/include/asm/efi.h | 5 +++++
4 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ff01c8fc76f7..c8c32ebcdfdb 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -32,6 +32,7 @@ static void setup_boot_services##bits(struct efi_config *c) \
\
table = (typeof(table))sys_table; \
\
+ c->runtime_services = table->runtime; \
c->boot_services = table->boottime; \
c->text_output = table->con_out; \
}
diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
index fd0b6a272dd5..d85b9625e836 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -82,7 +82,7 @@ ENTRY(efi_pe_entry)
/* Relocate efi_config->call() */
leal efi32_config(%esi), %eax
- add %esi, 32(%eax)
+ add %esi, 40(%eax)
pushl %eax
call make_boot_params
@@ -108,7 +108,7 @@ ENTRY(efi32_stub_entry)
/* Relocate efi_config->call() */
leal efi32_config(%esi), %eax
- add %esi, 32(%eax)
+ add %esi, 40(%eax)
pushl %eax
2:
call efi_main
@@ -264,7 +264,7 @@ relocated:
#ifdef CONFIG_EFI_STUB
.data
efi32_config:
- .fill 4,8,0
+ .fill 5,8,0
.long efi_call_phys
.long 0
.byte 0
diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index efdfba21a5b2..beab8322f72a 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -265,7 +265,7 @@ ENTRY(efi_pe_entry)
/*
* Relocate efi_config->call().
*/
- addq %rbp, efi64_config+32(%rip)
+ addq %rbp, efi64_config+40(%rip)
movq %rax, %rdi
call make_boot_params
@@ -285,7 +285,7 @@ handover_entry:
* Relocate efi_config->call().
*/
movq efi_config(%rip), %rax
- addq %rbp, 32(%rax)
+ addq %rbp, 40(%rax)
2:
movq efi_config(%rip), %rdi
call efi_main
@@ -457,14 +457,14 @@ efi_config:
#ifdef CONFIG_EFI_MIXED
.global efi32_config
efi32_config:
- .fill 4,8,0
+ .fill 5,8,0
.quad efi64_thunk
.byte 0
#endif
.global efi64_config
efi64_config:
- .fill 4,8,0
+ .fill 5,8,0
.quad efi_call
.byte 1
#endif /* CONFIG_EFI_STUB */
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index e99675b9c861..2f77bcefe6b4 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -191,6 +191,7 @@ static inline efi_status_t efi_thunk_set_virtual_address_map(
struct efi_config {
u64 image_handle;
u64 table;
+ u64 runtime_services;
u64 boot_services;
u64 text_output;
efi_status_t (*call)(unsigned long, ...);
@@ -226,6 +227,10 @@ static inline bool efi_is_64bit(void)
#define __efi_call_early(f, ...) \
__efi_early()->call((unsigned long)f, __VA_ARGS__);
+#define efi_call_runtime(f, ...) \
+ __efi_early()->call(efi_table_attr(efi_runtime_services, f, \
+ __efi_early()->runtime_services), __VA_ARGS__)
+
extern bool efi_reboot_required(void);
#else
^ permalink raw reply related
* [PATCH 1/8] efi: use typed function pointers for runtime services table [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Instead of using void pointers, and casting them to correctly typed
function pointers upon use, declare the runtime services pointers
as function pointers using their respective prototypes, for which
typedefs are already available.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/linux/efi.h | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index a07a476178cd..93a82de167eb 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -508,24 +508,6 @@ typedef struct {
u64 query_variable_info;
} efi_runtime_services_64_t;
-typedef struct {
- efi_table_hdr_t hdr;
- void *get_time;
- void *set_time;
- void *get_wakeup_time;
- void *set_wakeup_time;
- void *set_virtual_address_map;
- void *convert_pointer;
- void *get_variable;
- void *get_next_variable;
- void *set_variable;
- void *get_next_high_mono_count;
- void *reset_system;
- void *update_capsule;
- void *query_capsule_caps;
- void *query_variable_info;
-} efi_runtime_services_t;
-
typedef efi_status_t efi_get_time_t (efi_time_t *tm, efi_time_cap_t *tc);
typedef efi_status_t efi_set_time_t (efi_time_t *tm);
typedef efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, efi_bool_t *pending,
@@ -560,6 +542,24 @@ typedef efi_status_t efi_query_variable_store_t(u32 attributes,
unsigned long size,
bool nonblocking);
+typedef struct {
+ efi_table_hdr_t hdr;
+ efi_get_time_t *get_time;
+ efi_set_time_t *set_time;
+ efi_get_wakeup_time_t *get_wakeup_time;
+ efi_set_wakeup_time_t *set_wakeup_time;
+ efi_set_virtual_address_map_t *set_virtual_address_map;
+ void *convert_pointer;
+ efi_get_variable_t *get_variable;
+ efi_get_next_variable_t *get_next_variable;
+ efi_set_variable_t *set_variable;
+ efi_get_next_high_mono_count_t *get_next_high_mono_count;
+ efi_reset_system_t *reset_system;
+ efi_update_capsule_t *update_capsule;
+ efi_query_capsule_caps_t *query_capsule_caps;
+ efi_query_variable_info_t *query_variable_info;
+} efi_runtime_services_t;
+
void efi_native_runtime_setup(void);
/*
^ permalink raw reply related
* [PATCH 0/8] efi: Pass secure boot mode to kernel [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
Here's a set of patches that can determine the secure boot state of the
UEFI BIOS and pass that along to the main kernel image. This involves
generalising ARM's efi_get_secureboot() function and making it mixed-mode
safe.
Changes:
Ver 5:
- Fix i386 compilation error (rsi should've been changed to esi).
- Fix arm64 compilation error ('sys_table_arg' is a hidden macro parameter).
Ver 4:
- Use an enum to tell the kernel whether secure boot mode is enabled,
disabled, couldn't be determined or wasn't even tried due to not being
in EFI mode.
- Support the UEFI-2.6 DeployedMode flag.
- Don't clear boot_params->secure_boot in x86 sanitize_boot_params().
- Preclear the boot_params->secure_boot on x86 head_*.S entry if we may
not go through efi_main().
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-secure-boot
at tag:
efi-secure-boot-20161207-2
Note that the patches are not terminal on the branch.
David
---
Ard Biesheuvel (1):
efi: use typed function pointers for runtime services table
David Howells (5):
x86/efi: Allow invocation of arbitrary runtime services
arm/efi: Allow invocation of arbitrary runtime services
efi: Add SHIM and image security database GUID definitions
efi: Get the secure boot status
efi: Handle secure boot from UEFI-2.6
Josh Boyer (2):
efi: Disable secure boot if shim is in insecure mode
efi: Add EFI_SECURE_BOOT bit
Documentation/x86/zero-page.txt | 2 +
arch/arm/include/asm/efi.h | 1
arch/arm64/include/asm/efi.h | 1
arch/x86/boot/compressed/eboot.c | 3 +
arch/x86/boot/compressed/head_32.S | 7 +-
arch/x86/boot/compressed/head_64.S | 9 +--
arch/x86/include/asm/bootparam_utils.h | 5 +
arch/x86/include/asm/efi.h | 5 +
arch/x86/include/uapi/asm/bootparam.h | 3 +
arch/x86/kernel/asm-offsets.c | 1
arch/x86/kernel/setup.c | 15 ++++
drivers/firmware/efi/libstub/Makefile | 2 -
drivers/firmware/efi/libstub/arm-stub.c | 58 +---------------
drivers/firmware/efi/libstub/secureboot.c | 102 +++++++++++++++++++++++++++++
include/linux/efi.h | 52 ++++++++++-----
15 files changed, 182 insertions(+), 84 deletions(-)
create mode 100644 drivers/firmware/efi/libstub/secureboot.c
^ permalink raw reply
* [PATCH] dmaengine: pl330: do not generate unaligned access
From: Vladimir Murzin @ 2016-12-07 13:17 UTC (permalink / raw)
To: linux-arm-kernel
When PL330 is used with !MMU the following fault is seen:
Unhandled fault: alignment exception (0x801) at 0x8f26a002
Internal error: : 801 [#1] ARM
Modules linked in:
CPU: 0 PID: 640 Comm: dma0chan0-copy0 Not tainted 4.8.0-6a82063-clean+ #1600
Hardware name: ARM-Versatile Express
task: 8f1baa80 task.stack: 8e6fe000
PC is at _setup_req+0x4c/0x350
LR is at 0x8f2cbc00
pc : [<801ea538>] lr : [<8f2cbc00>] psr: 60000093
sp : 8e6ffdc0 ip : 00000000 fp : 00000000
r10: 00000000 r9 : 8f2cba10 r8 : 8f2cbc00
r7 : 80000013 r6 : 8f21a050 r5 : 8f21a000 r4 : 8f2ac800
r3 : 8e6ffe18 r2 : 00944251 r1 : ffffffbc r0 : 8f26a000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 00c5387c
Process dma0chan0-copy0 (pid: 640, stack limit = 0x8e6fe210)
Stack: (0x8e6ffdc0 to 0x8e700000)
fdc0: 00000001 60000093 00000000 8f2cba10 8f26a000 00000004 8f0ae000 8f2cbc00
fde0: 8f0ae000 8f2ac800 8f21a000 8f21a050 80000013 8f2cbc00 8f2cba10 00000000
fe00: 60000093 801ebca0 8e6ffe18 000013ff 40000093 00000000 00944251 8f2ac800
fe20: a0000013 8f2b1320 00001986 00000000 00000001 000013ff 8f1e4f00 8f2cba10
fe40: 8e6fff6c 801e9044 00000003 00000000 fef98c80 002faf07 8e6ffe7c 00000000
fe60: 00000002 00000000 00001986 8f1f158d 8f1e4f00 80568de4 00000002 00000000
fe80: 00001986 8f1f53ff 40000001 80580500 8f1f158d 8001e00c 00000000 cfdfdfdf
fea0: fdae2a25 00000001 00000004 8e6fe000 00000008 00000010 00000000 00000005
fec0: 8f2b1330 8f2b1334 8e6ffe80 8e6ffe8c 00001986 00000000 8f21a014 00000001
fee0: 8e6ffe60 8e6ffe78 00000002 00000000 000013ff 00000001 80568de4 8f1e8018
ff00: 0000158d 8055ec30 00000001 803f6b00 00001986 8f2cba10 fdae2a25 00000001
ff20: 8f1baca8 8e6fff24 8e6fff24 00000000 8e6fff24 ac6f3037 00000000 00000000
ff40: 00000000 8e6fe000 8f1e4f40 00000000 8f1e4f40 8f1e4f00 801e84ec 00000000
ff60: 00000000 00000000 00000000 80031714 dfdfdfcf 00000000 dfdfdfcf 8f1e4f00
ff80: 00000000 8e6fff84 8e6fff84 00000000 8e6fff90 8e6fff90 8e6fffac 8f1e4f40
ffa0: 80031640 00000000 00000000 8000f548 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 dfdfdfcf cfdfdfdf
[<801ea538>] (_setup_req) from [<801ebca0>] (pl330_tasklet+0x41c/0x490)
[<801ebca0>] (pl330_tasklet) from [<801e9044>] (dmatest_func+0xb58/0x149c)
[<801e9044>] (dmatest_func) from [<80031714>] (kthread+0xd4/0xec)
[<80031714>] (kthread) from [<8000f548>] (ret_from_fork+0x14/0x2c)
Code: e3a03001 e3e01043 e5c03001 e59d3048 (e5802002)
This happens because _emit_{ADDH,MOV,GO) accessing to unaligned data
while writing to buffer. Fix it with writing to buffer byte by byte.
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
drivers/dma/pl330.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 030fe05..e4c1ba7 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -570,7 +570,8 @@ static inline u32 _emit_ADDH(unsigned dry_run, u8 buf[],
buf[0] = CMD_DMAADDH;
buf[0] |= (da << 1);
- *((__le16 *)&buf[1]) = cpu_to_le16(val);
+ buf[1] = val;
+ buf[2] = val >> 8;
PL330_DBGCMD_DUMP(SZ_DMAADDH, "\tDMAADDH %s %u\n",
da == 1 ? "DA" : "SA", val);
@@ -724,7 +725,10 @@ static inline u32 _emit_MOV(unsigned dry_run, u8 buf[],
buf[0] = CMD_DMAMOV;
buf[1] = dst;
- *((__le32 *)&buf[2]) = cpu_to_le32(val);
+ buf[2] = val;
+ buf[3] = val >> 8;
+ buf[4] = val >> 16;
+ buf[5] = val >> 24;
PL330_DBGCMD_DUMP(SZ_DMAMOV, "\tDMAMOV %s 0x%x\n",
dst == SAR ? "SAR" : (dst == DAR ? "DAR" : "CCR"), val);
@@ -899,10 +903,11 @@ static inline u32 _emit_GO(unsigned dry_run, u8 buf[],
buf[0] = CMD_DMAGO;
buf[0] |= (ns << 1);
-
buf[1] = chan & 0x7;
-
- *((__le32 *)&buf[2]) = cpu_to_le32(addr);
+ buf[2] = addr;
+ buf[3] = addr >> 8;
+ buf[4] = addr >> 16;
+ buf[5] = addr >> 24;
return SZ_DMAGO;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-12-07 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207120900.GC20680@gondor.apana.org.au>
On Wed, Dec 07, 2016 at 08:09:00PM +0800, Herbert Xu wrote:
> On Mon, Dec 05, 2016 at 01:57:38PM +0100, Corentin Labbe wrote:
> >
> > So how to expose PRNG to user space ? or more generally how to "use" a PRNG ?
>
> We do have the algif_rng interface.
>
So I must expose it as a crypto_rng ?
Could you explain why PRNG must not be used as hw_random ?
Regards
Corentin Labbe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox