LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH v3 1/3] include/of_fdt.h: add a weak arch hook to update fdt pgprot
@ 2019-05-16 10:28 Hsin-Yi Wang
  2019-05-16 10:28 ` [PATCH v3 2/3] arm64: implement update_fdt_pgprot() Hsin-Yi Wang
  2019-05-16 10:28 ` [PATCH v3 3/3] fdt: add support for rng-seed Hsin-Yi Wang
  0 siblings, 2 replies; 13+ messages in thread
From: Hsin-Yi Wang @ 2019-05-16 10:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Rob Herring, devicetree, linux-kernel, Frank Rowand,
	Catalin Marinas, Will Deacon, Andrew Morton, Mike Rapoport,
	Ard Biesheuvel, Miles Chen, Hsin-Yi Wang, James Morse,
	Andrew Murray, Mark Rutland, Chintan Pandya, Jun Yao, Yu Zhao,
	Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook

Does nothing as default, arch can implement their function to map
fdt to RO/RW. This is convenient if arch map fdt to RO during init
but needs to write fdt in some special cases after that.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
 drivers/of/fdt.c       | 13 +++++++++++++
 include/linux/of_fdt.h |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index de893c9616a1..e84971d1e9ea 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -30,6 +30,19 @@
 
 #include "of_private.h"
 
+/*
+ * update_fdt_pgprot - Arch hook for changing fdt pgprot
+ *
+ * @prot: page protection flags for fdt
+ *
+ * Architecture can implement this function if they want to chagne
+ * fdt page protection flags before or after doing modification and
+ * fixups to fdt.
+ *
+ * Default does nothing.
+ */
+__weak void update_fdt_pgprot(pgprot_t prot) {}
+
 /*
  * of_fdt_limit_memory - limit the number of regions in the /memory node
  * @limit: maximum entries
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index a713e5d156d8..406c3e7b2b75 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -109,5 +109,7 @@ static inline void unflatten_device_tree(void) {}
 static inline void unflatten_and_copy_device_tree(void) {}
 #endif /* CONFIG_OF_EARLY_FLATTREE */
 
+extern void update_fdt_pgprot(pgprot_t prot);
+
 #endif /* __ASSEMBLY__ */
 #endif /* _LINUX_OF_FDT_H */
-- 
2.20.1


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 10:28 [PATCH v3 1/3] include/of_fdt.h: add a weak arch hook to update fdt pgprot Hsin-Yi Wang
@ 2019-05-16 10:28 ` Hsin-Yi Wang
  2019-05-16 14:37   ` Rob Herring
  2019-05-16 10:28 ` [PATCH v3 3/3] fdt: add support for rng-seed Hsin-Yi Wang
  1 sibling, 1 reply; 13+ messages in thread
From: Hsin-Yi Wang @ 2019-05-16 10:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Rob Herring, devicetree, linux-kernel, Frank Rowand,
	Catalin Marinas, Will Deacon, Andrew Morton, Mike Rapoport,
	Ard Biesheuvel, Miles Chen, Hsin-Yi Wang, James Morse,
	Andrew Murray, Mark Rutland, Chintan Pandya, Jun Yao, Yu Zhao,
	Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook

Basically does similar things like __fixmap_remap_fdt(). It's supposed
to be called after fixmap_remap_fdt() is called at least once, so region
checking can be skipped. Since it needs to know dt physical address, make
a copy of the value of __fdt_pointer.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
 arch/arm64/kernel/setup.c |  2 ++
 arch/arm64/mm/mmu.c       | 17 +++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 413d566405d1..207cbb5f7965 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -66,6 +66,7 @@ static int num_standard_resources;
 static struct resource *standard_resources;
 
 phys_addr_t __fdt_pointer __initdata;
+phys_addr_t fdt_pointer;
 
 /*
  * Standard memory resources
@@ -292,6 +293,7 @@ void __init setup_arch(char **cmdline_p)
 	early_fixmap_init();
 	early_ioremap_init();
 
+	fdt_pointer = __fdt_pointer;
 	setup_machine_fdt(__fdt_pointer);
 
 	parse_early_param();
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a170c6369a68..196ab4d9e92a 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -32,6 +32,7 @@
 #include <linux/io.h>
 #include <linux/mm.h>
 #include <linux/vmalloc.h>
+#include <linux/of_fdt.h>
 
 #include <asm/barrier.h>
 #include <asm/cputype.h>
@@ -953,6 +954,22 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 	return dt_virt;
 }
 
+extern phys_addr_t fdt_pointer;
+
+/* Should be called after fixmap_remap_fdt() is called. */
+void update_fdt_pgprot(pgprot_t prot)
+{
+	u64 dt_virt_base = __fix_to_virt(FIX_FDT);
+	int offset, size;
+
+	offset = fdt_pointer % SWAPPER_BLOCK_SIZE;
+	size = fdt_totalsize((void *)dt_virt_base + offset);
+
+	update_mapping_prot(round_down(fdt_pointer, SWAPPER_BLOCK_SIZE),
+			dt_virt_base,
+			round_up(offset + size, SWAPPER_BLOCK_SIZE), prot);
+}
+
 int __init arch_ioremap_pud_supported(void)
 {
 	/* only 4k granule supports level 1 block mappings */
-- 
2.20.1


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH v3 3/3] fdt: add support for rng-seed
  2019-05-16 10:28 [PATCH v3 1/3] include/of_fdt.h: add a weak arch hook to update fdt pgprot Hsin-Yi Wang
  2019-05-16 10:28 ` [PATCH v3 2/3] arm64: implement update_fdt_pgprot() Hsin-Yi Wang
@ 2019-05-16 10:28 ` Hsin-Yi Wang
  2019-05-16 15:39   ` Randy Dunlap
  1 sibling, 1 reply; 13+ messages in thread
From: Hsin-Yi Wang @ 2019-05-16 10:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Rob Herring, devicetree, linux-kernel, Frank Rowand,
	Catalin Marinas, Will Deacon, Andrew Morton, Mike Rapoport,
	Ard Biesheuvel, Miles Chen, Hsin-Yi Wang, James Morse,
	Andrew Murray, Mark Rutland, Chintan Pandya, Jun Yao, Yu Zhao,
	Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook

Introducing a chosen node, rng-seed, which is an entropy that can be
passed to kernel called very early to increase initial device
randomness. Bootloader should provide this entropy and the value is
read from /chosen/rng-seed in DT.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
change v2->v3:
1. use arch hook for fdt pgprot change
2. handle CONFIG_KEXEC
---
 Documentation/devicetree/bindings/chosen.txt | 14 +++++
 drivers/of/fdt.c                             | 55 ++++++++++++++++++++
 2 files changed, 69 insertions(+)

diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 45e79172a646..fef5c82672dc 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -28,6 +28,20 @@ mode) when EFI_RNG_PROTOCOL is supported, it will be overwritten by
 the Linux EFI stub (which will populate the property itself, using
 EFI_RNG_PROTOCOL).
 
+rng-seed
+-----------
+
+This property served as an entropy to add device randomness. It is parsed
+as a byte array, e.g.
+
+/ {
+	chosen {
+		rng-seed = <0x31 0x95 0x1b 0x3c 0xc9 0xfa 0xb3 ...>;
+	};
+};
+
+This random value should be provided by bootloader.
+
 stdout-path
 -----------
 
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e84971d1e9ea..e9862657268d 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -10,6 +10,7 @@
 
 #include <linux/crc32.h>
 #include <linux/kernel.h>
+#include <linux/kexec.h>
 #include <linux/initrd.h>
 #include <linux/memblock.h>
 #include <linux/mutex.h>
@@ -24,6 +25,8 @@
 #include <linux/debugfs.h>
 #include <linux/serial_core.h>
 #include <linux/sysfs.h>
+#include <linux/random.h>
+#include <linux/reboot.h>
 
 #include <asm/setup.h>  /* for COMMAND_LINE_SIZE */
 #include <asm/page.h>
@@ -1087,11 +1090,14 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
 	return 0;
 }
 
+int rng_seed_size;
+
 int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 				     int depth, void *data)
 {
 	int l;
 	const char *p;
+	const void *rng_seed;
 
 	pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
 
@@ -1126,6 +1132,16 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 
 	pr_debug("Command line is: %s\n", (char*)data);
 
+	rng_seed = of_get_flat_dt_prop(node, "rng-seed", &rng_seed_size);
+	if (rng_seed && rng_seed_size > 0) {
+		add_device_randomness(rng_seed, rng_seed_size);
+
+		/* try to clear seed so it won't be found. */
+		update_fdt_pgprot(PAGE_KERNEL);
+		fdt_delprop(initial_boot_params, node, "rng-seed");
+		update_fdt_pgprot(PAGE_KERNEL_RO);
+	}
+
 	/* break now */
 	return 1;
 }
@@ -1327,4 +1343,43 @@ static int __init of_fdt_raw_init(void)
 late_initcall(of_fdt_raw_init);
 #endif
 
+#ifdef CONFIG_KEXEC
+static int update_fdt_random_seed(struct notifier_block *nb,
+				  unsigned long code, void *unused)
+{
+	int node;
+	void *rng_seed;
+
+	if (!kexec_in_progress || !rng_seed_size)
+		return NOTIFY_DONE;
+
+	node = fdt_path_offset(initial_boot_params, "/chosen");
+	if (node < 0)
+		node = fdt_path_offset(initial_boot_params, "/chosen@0");
+	if (node < 0)
+		return NOTIFY_DONE;
+
+	rng_seed = kmalloc(rng_seed_size, GFP_ATOMIC);
+	get_random_bytes(rng_seed, rng_seed_size);
+
+	update_fdt_pgprot(PAGE_KERNEL);
+	fdt_setprop(initial_boot_params, node, "rng-seed", rng_seed,
+			rng_seed_size);
+
+	kfree(rng_seed);
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block fdt_random_seed_nb = {
+	.notifier_call = update_fdt_random_seed,
+};
+
+static int register_update_fdt_random_seed(void)
+{
+	return register_reboot_notifier(&fdt_random_seed_nb);
+}
+late_initcall(register_update_fdt_random_seed);
+#endif
+
 #endif /* CONFIG_OF_EARLY_FLATTREE */
-- 
2.20.1


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 10:28 ` [PATCH v3 2/3] arm64: implement update_fdt_pgprot() Hsin-Yi Wang
@ 2019-05-16 14:37   ` Rob Herring
  2019-05-16 14:39     ` Ard Biesheuvel
                       ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Rob Herring @ 2019-05-16 14:37 UTC (permalink / raw)
  To: Hsin-Yi Wang
  Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
	Miles Chen, James Morse, Andrew Murray, Mark Rutland,
	Chintan Pandya, Jun Yao, Yu Zhao, Robin Murphy, Laura Abbott,
	Stephen Boyd, Kees Cook

On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> Basically does similar things like __fixmap_remap_fdt(). It's supposed
> to be called after fixmap_remap_fdt() is called at least once, so region
> checking can be skipped. Since it needs to know dt physical address, make
> a copy of the value of __fdt_pointer.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> ---
>  arch/arm64/kernel/setup.c |  2 ++
>  arch/arm64/mm/mmu.c       | 17 +++++++++++++++++
>  2 files changed, 19 insertions(+)

Why not just map the FDT R/W at the start and change it to RO just
before calling unflatten_device_tree? Then all the FDT scanning
functions or any future fixups we need can just assume R/W. That is
essentially what Stephen suggested. However, there's no need for a
weak function as it can all be done within the arch code.

However, I'm still wondering why the FDT needs to be RO in the first place.

Rob

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 14:37   ` Rob Herring
@ 2019-05-16 14:39     ` Ard Biesheuvel
  2019-05-16 14:43     ` Mark Rutland
  2019-05-16 14:51     ` Hsin-Yi Wang
  2 siblings, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2019-05-16 14:39 UTC (permalink / raw)
  To: Rob Herring
  Cc: Hsin-Yi Wang,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Devicetree List, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Miles Chen,
	James Morse, Andrew Murray, Mark Rutland, Chintan Pandya,
	Jun Yao, Yu Zhao, Robin Murphy, Laura Abbott, Stephen Boyd,
	Kees Cook

On Thu, 16 May 2019 at 16:37, Rob Herring <robh+dt@kernel.org> wrote:
>
> On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > Basically does similar things like __fixmap_remap_fdt(). It's supposed
> > to be called after fixmap_remap_fdt() is called at least once, so region
> > checking can be skipped. Since it needs to know dt physical address, make
> > a copy of the value of __fdt_pointer.
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> > ---
> >  arch/arm64/kernel/setup.c |  2 ++
> >  arch/arm64/mm/mmu.c       | 17 +++++++++++++++++
> >  2 files changed, 19 insertions(+)
>
> Why not just map the FDT R/W at the start and change it to RO just
> before calling unflatten_device_tree? Then all the FDT scanning
> functions or any future fixups we need can just assume R/W. That is
> essentially what Stephen suggested. However, there's no need for a
> weak function as it can all be done within the arch code.
>
> However, I'm still wondering why the FDT needs to be RO in the first place.
>

It was RO because it could be RO, and we wanted to ensure that it
didn't get modified inadvertently (hence the CRC check we added as
well)

If there is a need for the FDT to be RW, let's make it RW.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 14:37   ` Rob Herring
  2019-05-16 14:39     ` Ard Biesheuvel
@ 2019-05-16 14:43     ` Mark Rutland
  2019-05-16 15:17       ` Rob Herring
  2019-05-16 14:51     ` Hsin-Yi Wang
  2 siblings, 1 reply; 13+ messages in thread
From: Mark Rutland @ 2019-05-16 14:43 UTC (permalink / raw)
  To: Rob Herring
  Cc: Hsin-Yi Wang,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
	Miles Chen, James Morse, Andrew Murray, Chintan Pandya, Jun Yao,
	Yu Zhao, Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook

On Thu, May 16, 2019 at 09:37:05AM -0500, Rob Herring wrote:
> On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > Basically does similar things like __fixmap_remap_fdt(). It's supposed
> > to be called after fixmap_remap_fdt() is called at least once, so region
> > checking can be skipped. Since it needs to know dt physical address, make
> > a copy of the value of __fdt_pointer.
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> > ---
> >  arch/arm64/kernel/setup.c |  2 ++
> >  arch/arm64/mm/mmu.c       | 17 +++++++++++++++++
> >  2 files changed, 19 insertions(+)
> 
> Why not just map the FDT R/W at the start and change it to RO just
> before calling unflatten_device_tree? Then all the FDT scanning
> functions or any future fixups we need can just assume R/W. That is
> essentially what Stephen suggested. However, there's no need for a
> weak function as it can all be done within the arch code.
> 
> However, I'm still wondering why the FDT needs to be RO in the first place.

We want to preserve the original FDT in a pristine form for kexec (and
when exposed to userspace), and mapping it RO was the easiest way to
catch it being randomly modified (e.g. without fixups applied).

I'd prefer to keep it RO once we've removed/cleared certain properties
from the chosen node that don't make sense to pass on for kexec

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 14:37   ` Rob Herring
  2019-05-16 14:39     ` Ard Biesheuvel
  2019-05-16 14:43     ` Mark Rutland
@ 2019-05-16 14:51     ` Hsin-Yi Wang
  2019-05-16 15:32       ` Rob Herring
  2 siblings, 1 reply; 13+ messages in thread
From: Hsin-Yi Wang @ 2019-05-16 14:51 UTC (permalink / raw)
  To: Rob Herring
  Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
	Miles Chen, James Morse, Andrew Murray, Mark Rutland,
	Chintan Pandya, Jun Yao, Yu Zhao, Robin Murphy, Laura Abbott,
	Stephen Boyd, Kees Cook

On Thu, May 16, 2019 at 10:37 PM Rob Herring <robh+dt@kernel.org> wrote:

>
> Why not just map the FDT R/W at the start and change it to RO just
> before calling unflatten_device_tree? Then all the FDT scanning
> functions or any future fixups we need can just assume R/W. That is
> essentially what Stephen suggested. However, there's no need for a
> weak function as it can all be done within the arch code.
>
We need to add a new seed for kexec

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 14:43     ` Mark Rutland
@ 2019-05-16 15:17       ` Rob Herring
  0 siblings, 0 replies; 13+ messages in thread
From: Rob Herring @ 2019-05-16 15:17 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Hsin-Yi Wang,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
	Miles Chen, James Morse, Andrew Murray, Chintan Pandya, Jun Yao,
	Yu Zhao, Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook

On Thu, May 16, 2019 at 9:43 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Thu, May 16, 2019 at 09:37:05AM -0500, Rob Herring wrote:
> > On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >
> > > Basically does similar things like __fixmap_remap_fdt(). It's supposed
> > > to be called after fixmap_remap_fdt() is called at least once, so region
> > > checking can be skipped. Since it needs to know dt physical address, make
> > > a copy of the value of __fdt_pointer.
> > >
> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> > > ---
> > >  arch/arm64/kernel/setup.c |  2 ++
> > >  arch/arm64/mm/mmu.c       | 17 +++++++++++++++++
> > >  2 files changed, 19 insertions(+)
> >
> > Why not just map the FDT R/W at the start and change it to RO just
> > before calling unflatten_device_tree? Then all the FDT scanning
> > functions or any future fixups we need can just assume R/W. That is
> > essentially what Stephen suggested. However, there's no need for a
> > weak function as it can all be done within the arch code.
> >
> > However, I'm still wondering why the FDT needs to be RO in the first place.
>
> We want to preserve the original FDT in a pristine form for kexec (and
> when exposed to userspace), and mapping it RO was the easiest way to
> catch it being randomly modified (e.g. without fixups applied).

The CRC check already existed for this purpose and that works for
every arch including ones where the FDT is copied.

BTW, This version of the patchset disables the export to userspace
since the CRC will be wrong.

> I'd prefer to keep it RO once we've removed/cleared certain properties
> from the chosen node that don't make sense to pass on for kexec

I want clear rules about when the FDT can be modified or not which are
not arch specific.

It's really only a question of with what granularity it's made R/W.
Wrapping every modification seems like overkill to me.

Rob

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 14:51     ` Hsin-Yi Wang
@ 2019-05-16 15:32       ` Rob Herring
  2019-05-16 16:48         ` Hsin-Yi Wang
  0 siblings, 1 reply; 13+ messages in thread
From: Rob Herring @ 2019-05-16 15:32 UTC (permalink / raw)
  To: Hsin-Yi Wang
  Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
	Miles Chen, James Morse, Andrew Murray, Mark Rutland, Jun Yao,
	Yu Zhao, Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook

On Thu, May 16, 2019 at 9:51 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> On Thu, May 16, 2019 at 10:37 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> >
> > Why not just map the FDT R/W at the start and change it to RO just
> > before calling unflatten_device_tree? Then all the FDT scanning
> > functions or any future fixups we need can just assume R/W. That is
> > essentially what Stephen suggested. However, there's no need for a
> > weak function as it can all be done within the arch code.
> >
> We need to add a new seed for kexec

Doesn't kexec operate on a copy because it already does modifications.

Rob

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 3/3] fdt: add support for rng-seed
  2019-05-16 10:28 ` [PATCH v3 3/3] fdt: add support for rng-seed Hsin-Yi Wang
@ 2019-05-16 15:39   ` Randy Dunlap
  0 siblings, 0 replies; 13+ messages in thread
From: Randy Dunlap @ 2019-05-16 15:39 UTC (permalink / raw)
  To: Hsin-Yi Wang, linux-arm-kernel
  Cc: Rob Herring, devicetree, linux-kernel, Frank Rowand,
	Catalin Marinas, Will Deacon, Andrew Morton, Mike Rapoport,
	Ard Biesheuvel, Miles Chen, James Morse, Andrew Murray,
	Mark Rutland, Chintan Pandya, Jun Yao, Yu Zhao, Robin Murphy,
	Laura Abbott, Stephen Boyd, Kees Cook

On 5/16/19 3:28 AM, Hsin-Yi Wang wrote:
> Introducing a chosen node, rng-seed, which is an entropy that can be
> passed to kernel called very early to increase initial device
> randomness. Bootloader should provide this entropy and the value is
> read from /chosen/rng-seed in DT.
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> ---
> change v2->v3:
> 1. use arch hook for fdt pgprot change
> 2. handle CONFIG_KEXEC
> ---
>  Documentation/devicetree/bindings/chosen.txt | 14 +++++
>  drivers/of/fdt.c                             | 55 ++++++++++++++++++++
>  2 files changed, 69 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> index 45e79172a646..fef5c82672dc 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -28,6 +28,20 @@ mode) when EFI_RNG_PROTOCOL is supported, it will be overwritten by
>  the Linux EFI stub (which will populate the property itself, using
>  EFI_RNG_PROTOCOL).
>  
> +rng-seed
> +-----------
> +
> +This property served as an entropy to add device randomness. It is parsed

                 serves


> +as a byte array, e.g.
> +
> +/ {
> +	chosen {
> +		rng-seed = <0x31 0x95 0x1b 0x3c 0xc9 0xfa 0xb3 ...>;
> +	};
> +};
> +
> +This random value should be provided by bootloader.
> +
>  stdout-path
>  -----------
>  



-- 
~Randy

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 15:32       ` Rob Herring
@ 2019-05-16 16:48         ` Hsin-Yi Wang
  2019-05-16 17:34           ` James Morse
  0 siblings, 1 reply; 13+ messages in thread
From: Hsin-Yi Wang @ 2019-05-16 16:48 UTC (permalink / raw)
  To: Rob Herring
  Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
	Miles Chen, James Morse, Andrew Murray, Mark Rutland, Jun Yao,
	Yu Zhao, Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook

On Thu, May 16, 2019 at 11:32 PM Rob Herring <robh+dt@kernel.org> wrote:

> Doesn't kexec operate on a copy because it already does modifications.
>
Hi Rob,

This patch is to assist "[PATCH v3 3/3] fdt: add support for rng-seed"
(https://lkml.org/lkml/2019/5/16/257). I thought that by default
second kernel would use original fdt, so I write new seed back to
original fdt. Might be wrong.

** "[PATCH v3 3/3] fdt: add support for rng-seed" is supposed to
handle for adding new seed in kexec case, discussed in v2
(https://lkml.org/lkml/2019/5/13/425)

By default (not considering user defines their own fdt), if second
kernel uses copied fdt, when is it copied and can we modify that?

Thanks!

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 16:48         ` Hsin-Yi Wang
@ 2019-05-16 17:34           ` James Morse
  2019-05-16 17:44             ` Stephen Boyd
  0 siblings, 1 reply; 13+ messages in thread
From: James Morse @ 2019-05-16 17:34 UTC (permalink / raw)
  To: Hsin-Yi Wang
  Cc: Rob Herring,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
	Miles Chen, Andrew Murray, Mark Rutland, Jun Yao, Yu Zhao,
	Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook

Hi!

On 16/05/2019 17:48, Hsin-Yi Wang wrote:
> On Thu, May 16, 2019 at 11:32 PM Rob Herring <robh+dt@kernel.org> wrote:
>> Doesn't kexec operate on a copy because it already does modifications.

It does!

> This patch is to assist "[PATCH v3 3/3] fdt: add support for rng-seed"
> (https://lkml.org/lkml/2019/5/16/257). I thought that by default
> second kernel would use original fdt, so I write new seed back to
> original fdt. Might be wrong.
> 
> ** "[PATCH v3 3/3] fdt: add support for rng-seed" is supposed to
> handle for adding new seed in kexec case, discussed in v2
> (https://lkml.org/lkml/2019/5/13/425)
> 
> By default (not considering user defines their own fdt), if second
> kernel uses copied fdt, when is it copied and can we modify that?

Regular kexec's user-space already updates the dtb for the cmdline and maybe the initrd.
For KASLR, it generates its own seed with getrandom():

https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n483

If user-space can do it, user-space should do it!


Thanks,

James

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()
  2019-05-16 17:34           ` James Morse
@ 2019-05-16 17:44             ` Stephen Boyd
  0 siblings, 0 replies; 13+ messages in thread
From: Stephen Boyd @ 2019-05-16 17:44 UTC (permalink / raw)
  To: Hsin-Yi Wang, James Morse
  Cc: Rob Herring,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, linux-kernel, Frank Rowand, Catalin Marinas,
	Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
	Miles Chen, Andrew Murray, Mark Rutland, Jun Yao, Yu Zhao,
	Robin Murphy, Laura Abbott, Kees Cook

Quoting James Morse (2019-05-16 10:34:16)
> Hi!
> 
> On 16/05/2019 17:48, Hsin-Yi Wang wrote:
> > On Thu, May 16, 2019 at 11:32 PM Rob Herring <robh+dt@kernel.org> wrote:
> >> Doesn't kexec operate on a copy because it already does modifications.
> 
> It does!
> 
> > This patch is to assist "[PATCH v3 3/3] fdt: add support for rng-seed"
> > (https://lkml.org/lkml/2019/5/16/257). I thought that by default
> > second kernel would use original fdt, so I write new seed back to
> > original fdt. Might be wrong.
> > 
> > ** "[PATCH v3 3/3] fdt: add support for rng-seed" is supposed to
> > handle for adding new seed in kexec case, discussed in v2
> > (https://lkml.org/lkml/2019/5/13/425)
> > 
> > By default (not considering user defines their own fdt), if second
> > kernel uses copied fdt, when is it copied and can we modify that?
> 
> Regular kexec's user-space already updates the dtb for the cmdline and maybe the initrd.
> For KASLR, it generates its own seed with getrandom():
> 
> https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n483
> 
> If user-space can do it, user-space should do it!
> 

Doesn't it need to be done in two places? Userspace and also in the
kernel when kexec_file_load() is used? At least, I see a bit of code
that does kaslr seed updates to the copied dtb in setup_dtb() of
arch/arm64/kernel/machine_kexec_file.c that probably needs to get an
update for this new property too.


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-05-16 17:44 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-16 10:28 [PATCH v3 1/3] include/of_fdt.h: add a weak arch hook to update fdt pgprot Hsin-Yi Wang
2019-05-16 10:28 ` [PATCH v3 2/3] arm64: implement update_fdt_pgprot() Hsin-Yi Wang
2019-05-16 14:37   ` Rob Herring
2019-05-16 14:39     ` Ard Biesheuvel
2019-05-16 14:43     ` Mark Rutland
2019-05-16 15:17       ` Rob Herring
2019-05-16 14:51     ` Hsin-Yi Wang
2019-05-16 15:32       ` Rob Herring
2019-05-16 16:48         ` Hsin-Yi Wang
2019-05-16 17:34           ` James Morse
2019-05-16 17:44             ` Stephen Boyd
2019-05-16 10:28 ` [PATCH v3 3/3] fdt: add support for rng-seed Hsin-Yi Wang
2019-05-16 15:39   ` Randy Dunlap

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).