* Declaring unrecoverable_exception() as __noreturn ?
From: Christophe Leroy @ 2021-02-10 16:44 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev@lists.ozlabs.org
As far as I can see, almost all callers of unrecoverable_exception() expect it to never return.
Can we mark it __noreturn ?
Below is interrupt_exit_kernel_prepare() with then without unrecoverable_exception() declared as
__noreturn. (CONFIG_PREEMPT_NONE, and with the BUG_ON() removed)
With the __noreturn added, we get no stack frame on the likely path
000003a8 <interrupt_exit_kernel_prepare>:
3a8: 81 43 00 84 lwz r10,132(r3)
3ac: 71 4a 00 02 andi. r10,r10,2
3b0: 41 82 00 30 beq 3e0 <interrupt_exit_kernel_prepare+0x38>
3b4: 80 62 00 70 lwz r3,112(r2)
3b8: 74 63 00 01 andis. r3,r3,1
3bc: 40 82 00 34 bne 3f0 <interrupt_exit_kernel_prepare+0x48>
3c0: 7d 40 00 a6 mfmsr r10
3c4: 55 4a 04 5e rlwinm r10,r10,0,17,15
3c8: 7d 40 01 24 mtmsr r10
3cc: 7d 20 00 a6 mfmsr r9
3d0: 55 29 07 fa rlwinm r9,r9,0,31,29
3d4: 55 29 04 5e rlwinm r9,r9,0,17,15
3d8: 7d 20 01 24 mtmsr r9
3dc: 4e 80 00 20 blr
3e0: 94 21 ff f0 stwu r1,-16(r1)
3e4: 7c 08 02 a6 mflr r0
3e8: 90 01 00 14 stw r0,20(r1)
3ec: 48 00 00 01 bl 3ec <interrupt_exit_kernel_prepare+0x44>
3ec: R_PPC_REL24 unrecoverable_exception
3f0: 38 e2 00 70 addi r7,r2,112
3f4: 3d 00 00 01 lis r8,1
3f8: 7c c0 38 28 lwarx r6,0,r7
3fc: 7c c6 40 78 andc r6,r6,r8
400: 7c c0 39 2d stwcx. r6,0,r7
404: 40 a2 ff f4 bne 3f8 <interrupt_exit_kernel_prepare+0x50>
408: 38 60 00 01 li r3,1
40c: 4b ff ff b4 b 3c0 <interrupt_exit_kernel_prepare+0x18>
Without the modification:
000003a8 <interrupt_exit_kernel_prepare>:
3a8: 94 21 ff f0 stwu r1,-16(r1)
3ac: 93 e1 00 0c stw r31,12(r1)
3b0: 81 23 00 84 lwz r9,132(r3)
3b4: 71 29 00 02 andi. r9,r9,2
3b8: 41 82 00 38 beq 3f0 <interrupt_exit_kernel_prepare+0x48>
3bc: 81 22 00 70 lwz r9,112(r2)
3c0: 75 23 00 01 andis. r3,r9,1
3c4: 40 82 00 4c bne 410 <interrupt_exit_kernel_prepare+0x68>
3c8: 7d 20 00 a6 mfmsr r9
3cc: 55 29 04 5e rlwinm r9,r9,0,17,15
3d0: 7d 20 01 24 mtmsr r9
3d4: 7d 20 00 a6 mfmsr r9
3d8: 55 29 07 fa rlwinm r9,r9,0,31,29
3dc: 55 29 04 5e rlwinm r9,r9,0,17,15
3e0: 7d 20 01 24 mtmsr r9
3e4: 83 e1 00 0c lwz r31,12(r1)
3e8: 38 21 00 10 addi r1,r1,16
3ec: 4e 80 00 20 blr
3f0: 7c 08 02 a6 mflr r0
3f4: 90 01 00 14 stw r0,20(r1)
3f8: 48 00 00 01 bl 3f8 <interrupt_exit_kernel_prepare+0x50>
3f8: R_PPC_REL24 unrecoverable_exception
3fc: 81 22 00 70 lwz r9,112(r2)
400: 80 01 00 14 lwz r0,20(r1)
404: 75 23 00 01 andis. r3,r9,1
408: 7c 08 03 a6 mtlr r0
40c: 41 82 ff bc beq 3c8 <interrupt_exit_kernel_prepare+0x20>
410: 39 02 00 70 addi r8,r2,112
414: 3d 20 00 01 lis r9,1
418: 7c e0 40 28 lwarx r7,0,r8
41c: 7c e7 48 78 andc r7,r7,r9
420: 7c e0 41 2d stwcx. r7,0,r8
424: 40 a2 ff f4 bne 418 <interrupt_exit_kernel_prepare+0x70>
428: 38 60 00 01 li r3,1
42c: 7d 20 00 a6 mfmsr r9
430: 55 29 04 5e rlwinm r9,r9,0,17,15
434: 7d 20 01 24 mtmsr r9
438: 7d 20 00 a6 mfmsr r9
43c: 55 29 07 fa rlwinm r9,r9,0,31,29
440: 55 29 04 5e rlwinm r9,r9,0,17,15
444: 7d 20 01 24 mtmsr r9
448: 83 e1 00 0c lwz r31,12(r1)
44c: 38 21 00 10 addi r1,r1,16
450: 4e 80 00 20 blr
^ permalink raw reply
* Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64
From: Rob Herring @ 2021-02-10 17:15 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210209182200.30606-1-nramas@linux.microsoft.com>
On Tue, Feb 09, 2021 at 10:21:50AM -0800, Lakshmi Ramasubramanian wrote:
> On kexec file load Integrity Measurement Architecture (IMA) subsystem
> may verify the IMA signature of the kernel and initramfs, and measure
> it. The command line parameters passed to the kernel in the kexec call
> may also be measured by IMA. A remote attestation service can verify
> a TPM quote based on the TPM event log, the IMA measurement list, and
> the TPM PCR data. This can be achieved only if the IMA measurement log
> is carried over from the current kernel to the next kernel across
> the kexec call.
>
> powerpc already supports carrying forward the IMA measurement log on
> kexec. This patch set adds support for carrying forward the IMA
> measurement log on kexec on ARM64.
>
> This patch set moves the platform independent code defined for powerpc
> such that it can be reused for other platforms as well. A chosen node
> "linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
> the address and the size of the memory reserved to carry
> the IMA measurement log.
>
> This patch set has been tested for ARM64 platform using QEMU.
> I would like help from the community for testing this change on powerpc.
> Thanks.
>
> This patch set is based on
> commit 96acc833dec8 ("ima: Free IMA measurement buffer after kexec syscall")
> in https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> "next-integrity" branch.
Is that a hard dependency still? Given this is now almost entirely
deleting arch code and adding drivers/of/ code, I was going to apply it.
Rob
^ permalink raw reply
* Re: [PATCH v17 05/10] powerpc: Move ima buffer fields to struct kimage
From: Rob Herring @ 2021-02-10 17:20 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210209182200.30606-6-nramas@linux.microsoft.com>
On Tue, Feb 09, 2021 at 10:21:55AM -0800, Lakshmi Ramasubramanian wrote:
> The fields ima_buffer_addr and ima_buffer_size in "struct kimage_arch"
> for powerpc are used to carry forward the IMA measurement list across
> kexec system call. These fields are not architecture specific, but are
> currently limited to powerpc.
>
> arch_ima_add_kexec_buffer() defined in "arch/powerpc/kexec/ima.c"
> sets ima_buffer_addr and ima_buffer_size for the kexec system call.
> This function does not have architecture specific code, but is
> currently limited to powerpc.
>
> Move ima_buffer_addr and ima_buffer_size to "struct kimage".
> Rename arch_ima_add_kexec_buffer() to of_ima_add_kexec_buffer()
> and move it in drivers/of/kexec.c.
>
> Co-developed-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> Suggested-by: Will Deacon <will@kernel.org>
> ---
> arch/powerpc/include/asm/ima.h | 3 ---
> arch/powerpc/include/asm/kexec.h | 5 -----
> arch/powerpc/kexec/ima.c | 29 ++++++-----------------------
> drivers/of/kexec.c | 23 +++++++++++++++++++++++
> include/linux/kexec.h | 3 +++
> include/linux/of.h | 5 +++++
> security/integrity/ima/ima_kexec.c | 3 ++-
> 7 files changed, 39 insertions(+), 32 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ima.h b/arch/powerpc/include/asm/ima.h
> index ead488cf3981..51f64fd06c19 100644
> --- a/arch/powerpc/include/asm/ima.h
> +++ b/arch/powerpc/include/asm/ima.h
> @@ -14,9 +14,6 @@ static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
> #endif
>
> #ifdef CONFIG_IMA_KEXEC
> -int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
> - size_t size);
> -
> int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
> #else
> static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
> diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
> index bdd0ddb9ac4d..ecf88533d6b4 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -112,11 +112,6 @@ struct kimage_arch {
> unsigned long elf_headers_sz;
> void *elf_headers;
> void *fdt;
> -
> -#ifdef CONFIG_IMA_KEXEC
> - phys_addr_t ima_buffer_addr;
> - size_t ima_buffer_size;
> -#endif
> };
>
> char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
> diff --git a/arch/powerpc/kexec/ima.c b/arch/powerpc/kexec/ima.c
> index 720e50e490b6..ed38125e2f87 100644
> --- a/arch/powerpc/kexec/ima.c
> +++ b/arch/powerpc/kexec/ima.c
> @@ -128,23 +128,6 @@ void remove_ima_buffer(void *fdt, int chosen_node)
> }
>
> #ifdef CONFIG_IMA_KEXEC
> -/**
> - * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA buffer
> - *
> - * Architectures should use this function to pass on the IMA buffer
> - * information to the next kernel.
> - *
> - * Return: 0 on success, negative errno on error.
> - */
> -int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
> - size_t size)
> -{
> - image->arch.ima_buffer_addr = load_addr;
> - image->arch.ima_buffer_size = size;
> -
> - return 0;
> -}
> -
> static int write_number(void *p, u64 value, int cells)
> {
> if (cells == 1) {
> @@ -180,7 +163,7 @@ int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node)
> u8 value[16];
>
> remove_ima_buffer(fdt, chosen_node);
> - if (!image->arch.ima_buffer_size)
> + if (!image->ima_buffer_size)
> return 0;
>
> ret = get_addr_size_cells(&addr_cells, &size_cells);
> @@ -192,11 +175,11 @@ int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node)
> if (entry_size > sizeof(value))
> return -EINVAL;
>
> - ret = write_number(value, image->arch.ima_buffer_addr, addr_cells);
> + ret = write_number(value, image->ima_buffer_addr, addr_cells);
> if (ret)
> return ret;
>
> - ret = write_number(value + 4 * addr_cells, image->arch.ima_buffer_size,
> + ret = write_number(value + 4 * addr_cells, image->ima_buffer_size,
> size_cells);
> if (ret)
> return ret;
> @@ -206,13 +189,13 @@ int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node)
> if (ret < 0)
> return -EINVAL;
>
> - ret = fdt_add_mem_rsv(fdt, image->arch.ima_buffer_addr,
> - image->arch.ima_buffer_size);
> + ret = fdt_add_mem_rsv(fdt, image->ima_buffer_addr,
> + image->ima_buffer_size);
> if (ret)
> return -EINVAL;
>
> pr_debug("IMA buffer at 0x%llx, size = 0x%zx\n",
> - image->arch.ima_buffer_addr, image->arch.ima_buffer_size);
> + image->ima_buffer_addr, image->ima_buffer_size);
>
> return 0;
> }
> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
> index 469e09613cdd..9f33d215b9f2 100644
> --- a/drivers/of/kexec.c
> +++ b/drivers/of/kexec.c
> @@ -63,6 +63,29 @@ static int fdt_find_and_del_mem_rsv(void *fdt, unsigned long start, unsigned lon
> return -ENOENT;
> }
>
> +#ifdef CONFIG_IMA_KEXEC
> +/**
> + * of_ima_add_kexec_buffer - Add IMA buffer for next kernel
> + *
> + * @image: kimage struct to set IMA buffer data
> + * @load_addr: Starting address where IMA buffer is loaded at
> + * @size: Number of bytes in the IMA buffer
> + *
> + * Use this function to pass on the IMA buffer information to
> + * the next kernel across kexec system call.
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int of_ima_add_kexec_buffer(struct kimage *image,
> + unsigned long load_addr, size_t size)
> +{
> + image->ima_buffer_addr = load_addr;
> + image->ima_buffer_size = size;
> +
There's nothing DT specific about this function, so this is the wrong
place for it. I would just remove it and directly set the members.
Rob
^ permalink raw reply
* Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function
From: Rob Herring @ 2021-02-10 17:23 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210209182200.30606-3-nramas@linux.microsoft.com>
On Tue, Feb 09, 2021 at 10:21:52AM -0800, Lakshmi Ramasubramanian wrote:
> From: Rob Herring <robh@kernel.org>
>
> Both arm64 and powerpc do essentially the same FDT /chosen setup for
> kexec. The differences are either omissions that arm64 should have
> or additional properties that will be ignored. The setup code can be
> combined and shared by both powerpc and arm64.
>
> The differences relative to the arm64 version:
> - If /chosen doesn't exist, it will be created (should never happen).
> - Any old dtb and initrd reserved memory will be released.
> - The new initrd and elfcorehdr are marked reserved.
> - "linux,booted-from-kexec" is set.
>
> The differences relative to the powerpc version:
> - "kaslr-seed" and "rng-seed" may be set.
> - "linux,elfcorehdr" is set.
> - Any existing "linux,usable-memory-range" is removed.
>
> Combine the code for setting up the /chosen node in the FDT and updating
> the memory reservation for kexec, for powerpc and arm64, in
> of_kexec_alloc_and_setup_fdt() and move it to "drivers/of/kexec.c".
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> ---
> drivers/of/Makefile | 6 ++
> drivers/of/kexec.c | 258 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of.h | 13 +++
> 3 files changed, 277 insertions(+)
> create mode 100644 drivers/of/kexec.c
>
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 6e1e5212f058..c13b982084a3 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -14,4 +14,10 @@ obj-$(CONFIG_OF_RESOLVE) += resolver.o
> obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
>
> +ifdef CONFIG_KEXEC_FILE
> +ifdef CONFIG_OF_FLATTREE
> +obj-y += kexec.o
> +endif
> +endif
> +
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
> new file mode 100644
> index 000000000000..469e09613cdd
> --- /dev/null
> +++ b/drivers/of/kexec.c
> @@ -0,0 +1,258 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 Arm Limited
> + *
> + * Based on arch/arm64/kernel/machine_kexec_file.c:
> + * Copyright (C) 2018 Linaro Limited
> + *
> + * And arch/powerpc/kexec/file_load.c:
> + * Copyright (C) 2016 IBM Corporation
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/kexec.h>
> +#include <linux/libfdt.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/random.h>
> +#include <linux/types.h>
> +
> +/* relevant device tree properties */
> +#define FDT_PROP_KEXEC_ELFHDR "linux,elfcorehdr"
> +#define FDT_PROP_MEM_RANGE "linux,usable-memory-range"
> +#define FDT_PROP_INITRD_START "linux,initrd-start"
> +#define FDT_PROP_INITRD_END "linux,initrd-end"
> +#define FDT_PROP_BOOTARGS "bootargs"
> +#define FDT_PROP_KASLR_SEED "kaslr-seed"
> +#define FDT_PROP_RNG_SEED "rng-seed"
> +#define RNG_SEED_SIZE 128
> +
> +/**
> + * fdt_find_and_del_mem_rsv - delete memory reservation with given address and size
> + *
> + * @fdt: Flattened device tree for the current kernel.
> + * @start: Starting address of the reserved memory.
> + * @size: Size of the reserved memory.
> + *
> + * Return: 0 on success, or negative errno on error.
> + */
> +static int fdt_find_and_del_mem_rsv(void *fdt, unsigned long start, unsigned long size)
> +{
> + int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
> +
> + for (i = 0; i < num_rsvs; i++) {
> + u64 rsv_start, rsv_size;
> +
> + ret = fdt_get_mem_rsv(fdt, i, &rsv_start, &rsv_size);
> + if (ret) {
> + pr_err("Malformed device tree.\n");
> + return -EINVAL;
> + }
> +
> + if (rsv_start == start && rsv_size == size) {
> + ret = fdt_del_mem_rsv(fdt, i);
> + if (ret) {
> + pr_err("Error deleting device tree reservation.\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> + }
> + }
> +
> + return -ENOENT;
> +}
> +
> +/*
> + * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
> + *
> + * @image: kexec image being loaded.
> + * @initrd_load_addr: Address where the next initrd will be loaded.
> + * @initrd_len: Size of the next initrd, or 0 if there will be none.
> + * @cmdline: Command line for the next kernel, or NULL if there will
> + * be none.
> + *
> + * Return: fdt on success, or NULL errno on error.
> + */
> +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
> + unsigned long initrd_load_addr,
> + unsigned long initrd_len,
> + const char *cmdline)
> +{
> + void *fdt;
> + int ret, chosen_node;
> + const void *prop;
> + unsigned long fdt_size;
> +
> + fdt_size = fdt_totalsize(initial_boot_params) +
> + (cmdline ? strlen(cmdline) : 0) +
> + FDT_EXTRA_SPACE;
> +
> + fdt = kvmalloc(fdt_size, GFP_KERNEL);
> + if (!fdt)
> + return NULL;
> +
> + ret = fdt_open_into(initial_boot_params, fdt, fdt_size);
> + if (ret < 0) {
> + pr_err("Error %d setting up the new device tree.\n", ret);
> + goto out;
> + }
> +
> + /* Remove memory reservation for the current device tree. */
> + ret = fdt_find_and_del_mem_rsv(fdt, __pa(initial_boot_params),
> + fdt_totalsize(initial_boot_params));
> + if (ret == -EINVAL) {
> + pr_err("Error removing memory reservation.\n");
> + goto out;
> + }
> +
> + chosen_node = fdt_path_offset(fdt, "/chosen");
> + if (chosen_node == -FDT_ERR_NOTFOUND)
> + chosen_node = fdt_add_subnode(fdt, fdt_path_offset(fdt, "/"),
> + "chosen");
> + if (chosen_node < 0) {
> + ret = chosen_node;
> + goto out;
> + }
> +
> + ret = fdt_delprop(fdt, chosen_node, FDT_PROP_KEXEC_ELFHDR);
> + if (ret && ret != -FDT_ERR_NOTFOUND)
> + goto out;
> + ret = fdt_delprop(fdt, chosen_node, FDT_PROP_MEM_RANGE);
> + if (ret && ret != -FDT_ERR_NOTFOUND)
> + goto out;
> +
> + /* Did we boot using an initrd? */
> + prop = fdt_getprop(fdt, chosen_node, "linux,initrd-start", NULL);
> + if (prop) {
> + u64 tmp_start, tmp_end, tmp_size;
> +
> + tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
> +
> + prop = fdt_getprop(fdt, chosen_node, "linux,initrd-end", NULL);
> + if (!prop) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
> +
> + /*
> + * kexec reserves exact initrd size, while firmware may
> + * reserve a multiple of PAGE_SIZE, so check for both.
> + */
> + tmp_size = tmp_end - tmp_start;
> + ret = fdt_find_and_del_mem_rsv(fdt, tmp_start, tmp_size);
> + if (ret == -ENOENT)
> + ret = fdt_find_and_del_mem_rsv(fdt, tmp_start,
> + round_up(tmp_size, PAGE_SIZE));
> + if (ret == -EINVAL)
> + goto out;
> + }
> +
> + /* add initrd-* */
> + if (initrd_load_addr) {
> + ret = fdt_setprop_u64(fdt, chosen_node, FDT_PROP_INITRD_START,
> + initrd_load_addr);
> + if (ret)
> + goto out;
> +
> + ret = fdt_setprop_u64(fdt, chosen_node, FDT_PROP_INITRD_END,
> + initrd_load_addr + initrd_len);
> + if (ret)
> + goto out;
> +
> + ret = fdt_add_mem_rsv(fdt, initrd_load_addr, initrd_len);
> + if (ret)
> + goto out;
> +
> + } else {
> + ret = fdt_delprop(fdt, chosen_node, FDT_PROP_INITRD_START);
> + if (ret && (ret != -FDT_ERR_NOTFOUND))
> + goto out;
> +
> + ret = fdt_delprop(fdt, chosen_node, FDT_PROP_INITRD_END);
> + if (ret && (ret != -FDT_ERR_NOTFOUND))
> + goto out;
> + }
> +
> + if (image->type == KEXEC_TYPE_CRASH) {
> + /* add linux,elfcorehdr */
> + ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
> + FDT_PROP_KEXEC_ELFHDR,
> + image->arch.elf_headers_mem,
> + image->arch.elf_headers_sz);
> + if (ret)
> + goto out;
> +
> + /*
> + * Avoid elfcorehdr from being stomped on in kdump kernel by
> + * setting up memory reserve map.
> + */
> + ret = fdt_add_mem_rsv(fdt, image->arch.elf_headers_mem,
> + image->arch.elf_headers_sz);
> + if (ret)
> + goto out;
> +
> + /* add linux,usable-memory-range */
> + ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
> + FDT_PROP_MEM_RANGE,
> + crashk_res.start,
> + crashk_res.end - crashk_res.start + 1);
> + if (ret)
> + goto out;
> + }
> +
> + /* add bootargs */
> + if (cmdline) {
> + ret = fdt_setprop_string(fdt, chosen_node, FDT_PROP_BOOTARGS, cmdline);
> + if (ret)
> + goto out;
> + } else {
> + ret = fdt_delprop(fdt, chosen_node, FDT_PROP_BOOTARGS);
> + if (ret && (ret != -FDT_ERR_NOTFOUND))
> + goto out;
> + }
> +
> + /* add kaslr-seed */
> + ret = fdt_delprop(fdt, chosen_node, FDT_PROP_KASLR_SEED);
> + if (ret == -FDT_ERR_NOTFOUND)
> + ret = 0;
> + else if (ret)
> + goto out;
> +
> + if (rng_is_initialized()) {
> + u64 seed = get_random_u64();
> +
> + ret = fdt_setprop_u64(fdt, chosen_node, FDT_PROP_KASLR_SEED, seed);
> + if (ret)
> + goto out;
> + } else {
> + pr_notice("RNG is not initialised: omitting \"%s\" property\n",
> + FDT_PROP_KASLR_SEED);
> + }
> +
> + /* add rng-seed */
> + if (rng_is_initialized()) {
> + void *rng_seed;
> +
> + ret = fdt_setprop_placeholder(fdt, chosen_node, FDT_PROP_RNG_SEED,
> + RNG_SEED_SIZE, &rng_seed);
> + if (ret)
> + goto out;
> + get_random_bytes(rng_seed, RNG_SEED_SIZE);
> + } else {
> + pr_notice("RNG is not initialised: omitting \"%s\" property\n",
> + FDT_PROP_RNG_SEED);
> + }
> +
> + ret = fdt_setprop(fdt, chosen_node, "linux,booted-from-kexec", NULL, 0);
> +
> +out:
> + if (ret) {
> + kvfree(fdt);
> + fdt = NULL;
> + }
> +
> + return fdt;
> +}
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 4b27c9a27df3..f0eff5e84353 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -560,6 +560,19 @@ int of_map_id(struct device_node *np, u32 id,
>
> phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
>
> +/*
> + * Additional space needed for the buffer to build the new FDT
> + * so that we can add initrd, bootargs, kaslr-seed, rng-seed,
> + * userable-memory-range and elfcorehdr.
> + */
> +#define FDT_EXTRA_SPACE 0x1000
No need for this to be public now. Move it to of/kexec.c.
Rob
^ permalink raw reply
* Re: [PATCH v17 03/10] arm64: Use common of_kexec_alloc_and_setup_fdt()
From: Will Deacon @ 2021-02-10 17:26 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, robh, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210209182200.30606-4-nramas@linux.microsoft.com>
On Tue, Feb 09, 2021 at 10:21:53AM -0800, Lakshmi Ramasubramanian wrote:
> From: Rob Herring <robh@kernel.org>
>
> The code for setting up the /chosen node in the device tree
> and updating the memory reservation for the next kernel has been
> moved to of_kexec_alloc_and_setup_fdt() defined in "drivers/of/kexec.c".
>
> Use the common of_kexec_alloc_and_setup_fdt() to setup the device tree
> and update the memory reservation for kexec for arm64.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> ---
> arch/arm64/kernel/machine_kexec_file.c | 180 ++-----------------------
> 1 file changed, 8 insertions(+), 172 deletions(-)
I mean, of course I'm going to Ack that!
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* [PATCH v6 05/10] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
From: Serge Semin @ 2021-02-10 17:28 UTC (permalink / raw)
To: Felipe Balbi, Bjorn Andersson, Krzysztof Kozlowski,
Florian Fainelli, Rob Herring, Greg Kroah-Hartman,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: devicetree, linux-usb, linuxppc-dev, linux-kernel
In-Reply-To: <20210210172850.20849-1-Sergey.Semin@baikalelectronics.ru>
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/powerpc/boot/dts/akebono.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/akebono.dts b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@30000010000 {
interrupts = <93 2>;
};
- EHCI0: ehci@30010000000 {
+ EHCI0: usb@30010000000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x10000000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
@@ -140,14 +140,14 @@ SD0: sd@30000000000 {
interrupt-parent = <&MPIC>;
};
- OHCI0: ohci@30010010000 {
+ OHCI0: usb@30010010000 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x10010000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
interrupts = <89 1>;
};
- OHCI1: ohci@30010020000 {
+ OHCI1: usb@30010020000 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x10020000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
--
2.30.0
^ permalink raw reply related
* [PATCH RESEND v6 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
From: Serge Semin @ 2021-02-10 17:28 UTC (permalink / raw)
To: Felipe Balbi, Bjorn Andersson, Krzysztof Kozlowski,
Florian Fainelli, Rob Herring, Greg Kroah-Hartman
Cc: Andrew Lunn, Amelie Delaunay, Tony Lindgren, linux-mips,
Paul Cercueil, Paul Mackerras, linux-stm32, linux-kernel,
Alexandre Torgue, Khuong Dinh, linux-samsung-soc, Gregory Clement,
Rafal Milecki, Alexey Brodkin, Wei Xu, Chen-Yu Tsai, Andy Gross,
bcm-kernel-feedback-list, linux-arm-msm, linux-snps-arc,
Sebastian Hesselbarth, devicetree, Jason Cooper, Hauke Mehrtens,
linuxppc-dev, Maxime Ripard, Vladimir Zapolskiy, Jun Li,
Santosh Shilimkar, Matthias Brugger, Benoit Cousson, linux-omap,
linux-arm-kernel, Thomas Bogendoerfer, Vineet Gupta, linux-usb,
Patrice Chotard, Li Yang, Kukjin Kim, Maxime Coquelin,
linux-mediatek, Shawn Guo
As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].
Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in all the DTS files,
which have been unfortunate to define such nodes.
Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.
Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.
Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.
[1] Link: https://lore.kernel.org/linux-usb/20201014101402.18271-1-Sergey.Semin@baikalelectronics.ru/
Changelog v1:
- As Krzysztof suggested I've created a script which checked whether the
node names had been also updated in all the depended dts files. As a
result I found two more files which should have been also modified:
arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
Link: https://lore.kernel.org/linux-usb/20201020115959.2658-1-Sergey.Semin@baikalelectronics.ru
Changelog v2:
- Drop the patch:
[PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
and get back the one which marks the "synopsys,dwc3" compatible string
as deprecated into the DT schema related series.
- Drop the patches:
[PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
[PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
[PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
[PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
[PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
[PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
[PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
[PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
[PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
- Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
sub-node and falling back to the "dwc3@"-prefixed one on failure.
Link: https://lore.kernel.org/linux-usb/20201111091552.15593-1-Sergey.Semin@baikalelectronics.ru
Changelog v3:
- Drop the patches:
[PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
[PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name
[PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
Link: https://lore.kernel.org/linux-usb/20201205155621.3045-1-Sergey.Semin@baikalelectronics.ru
Changelog v4:
- Just resend.
Link: https://lore.kernel.org/linux-usb/20201210091756.18057-1-Sergey.Semin@baikalelectronics.ru/
Changelog v5:
- Drop the patch:
[PATCH v4 02/10] arm64: dts: amlogic: meson-g12: Set FL-adj property value
since it has been applied to the corresponding maintainers repos.
- Get back the patch:
[PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
as it has been missing in the kernel 5.11-rc7
- Rebase onto the kernel 5.11-rc7
Link: https://lore.kernel.org/lkml/20210208135154.6645-1-Sergey.Semin@baikalelectronics.ru/
Changelog v6:
- Just resend and add linux-usb.vger.kernel.org to the list of Ccecipients.
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Rafal Milecki <zajec5@gmail.com>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Khuong Dinh <khuong@os.amperecomputing.com>
Cc: Andy Gross <agross@kernel.org>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Amelie Delaunay <amelie.delaunay@st.com>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Li Yang <leoyang.li@nxp.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Jun Li <lijun.kernel@gmail.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (10):
arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
arm: dts: keystone: Correct DWC USB3 compatible string
arc: dts: Harmonize EHCI/OHCI DT nodes name
arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
arm: dts: keystone: Harmonize DWC USB3 DT nodes name
arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
arm64: dts: apm: Harmonize DWC USB3 DT nodes name
usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
arch/arc/boot/dts/axc003.dtsi | 4 ++--
arch/arc/boot/dts/axc003_idu.dtsi | 4 ++--
arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
arch/arc/boot/dts/hsdk.dts | 4 ++--
arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2e.dtsi | 6 +++---
arch/arm/boot/dts/keystone.dtsi | 4 ++--
arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
arch/arm/boot/dts/stih407-family.dtsi | 2 +-
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
arch/powerpc/boot/dts/akebono.dts | 6 +++---
drivers/usb/dwc3/dwc3-qcom.c | 3 ++-
23 files changed, 42 insertions(+), 41 deletions(-)
--
2.30.0
^ permalink raw reply
* Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64
From: Lakshmi Ramasubramanian @ 2021-02-10 17:33 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210210171500.GA2328209@robh.at.kernel.org>
On 2/10/21 9:15 AM, Rob Herring wrote:
> On Tue, Feb 09, 2021 at 10:21:50AM -0800, Lakshmi Ramasubramanian wrote:
>> On kexec file load Integrity Measurement Architecture (IMA) subsystem
>> may verify the IMA signature of the kernel and initramfs, and measure
>> it. The command line parameters passed to the kernel in the kexec call
>> may also be measured by IMA. A remote attestation service can verify
>> a TPM quote based on the TPM event log, the IMA measurement list, and
>> the TPM PCR data. This can be achieved only if the IMA measurement log
>> is carried over from the current kernel to the next kernel across
>> the kexec call.
>>
>> powerpc already supports carrying forward the IMA measurement log on
>> kexec. This patch set adds support for carrying forward the IMA
>> measurement log on kexec on ARM64.
>>
>> This patch set moves the platform independent code defined for powerpc
>> such that it can be reused for other platforms as well. A chosen node
>> "linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
>> the address and the size of the memory reserved to carry
>> the IMA measurement log.
>>
>> This patch set has been tested for ARM64 platform using QEMU.
>> I would like help from the community for testing this change on powerpc.
>> Thanks.
>>
>> This patch set is based on
>> commit 96acc833dec8 ("ima: Free IMA measurement buffer after kexec syscall")
>> in https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
>> "next-integrity" branch.
>
> Is that a hard dependency still? Given this is now almost entirely
> deleting arch code and adding drivers/of/ code, I was going to apply it.
>
I tried applying the patches in Linus' mainline branch -
PATCH #5 0005-powerpc-Move-ima-buffer-fields-to-struct-kimage.patch
doesn't apply.
But if I apply the dependent patch set (link given below), all the
patches in this patch set apply fine.
https://patchwork.kernel.org/project/linux-integrity/patch/20210204174951.25771-2-nramas@linux.microsoft.com/
thanks,
-lakshmi
^ permalink raw reply
* Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function
From: Lakshmi Ramasubramanian @ 2021-02-10 17:59 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210210172307.GB2361245@robh.at.kernel.org>
On 2/10/21 9:23 AM, Rob Herring wrote:
> On Tue, Feb 09, 2021 at 10:21:52AM -0800, Lakshmi Ramasubramanian wrote:
>> From: Rob Herring <robh@kernel.org>
>>
>> Both arm64 and powerpc do essentially the same FDT /chosen setup for
>> kexec. The differences are either omissions that arm64 should have
>> or additional properties that will be ignored. The setup code can be
>> combined and shared by both powerpc and arm64.
>>
>> The differences relative to the arm64 version:
>> - If /chosen doesn't exist, it will be created (should never happen).
>> - Any old dtb and initrd reserved memory will be released.
>> - The new initrd and elfcorehdr are marked reserved.
>> - "linux,booted-from-kexec" is set.
>>
>> The differences relative to the powerpc version:
>> - "kaslr-seed" and "rng-seed" may be set.
>> - "linux,elfcorehdr" is set.
>> - Any existing "linux,usable-memory-range" is removed.
>>
>> Combine the code for setting up the /chosen node in the FDT and updating
>> the memory reservation for kexec, for powerpc and arm64, in
>> of_kexec_alloc_and_setup_fdt() and move it to "drivers/of/kexec.c".
>>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>> ---
>> drivers/of/Makefile | 6 ++
>> drivers/of/kexec.c | 258 ++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/of.h | 13 +++
>> 3 files changed, 277 insertions(+)
>> create mode 100644 drivers/of/kexec.c
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index 4b27c9a27df3..f0eff5e84353 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -560,6 +560,19 @@ int of_map_id(struct device_node *np, u32 id,
>>
>> phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
>>
>> +/*
>> + * Additional space needed for the buffer to build the new FDT
>> + * so that we can add initrd, bootargs, kaslr-seed, rng-seed,
>> + * userable-memory-range and elfcorehdr.
>> + */
>> +#define FDT_EXTRA_SPACE 0x1000
>
> No need for this to be public now. Move it to of/kexec.c.
>
Will do.
-lakshmi
^ permalink raw reply
* Re: [PATCH v17 05/10] powerpc: Move ima buffer fields to struct kimage
From: Lakshmi Ramasubramanian @ 2021-02-10 18:00 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210210172018.GA2361245@robh.at.kernel.org>
On 2/10/21 9:20 AM, Rob Herring wrote:
> On Tue, Feb 09, 2021 at 10:21:55AM -0800, Lakshmi Ramasubramanian wrote:
>> The fields ima_buffer_addr and ima_buffer_size in "struct kimage_arch"
>> for powerpc are used to carry forward the IMA measurement list across
>> kexec system call. These fields are not architecture specific, but are
>> currently limited to powerpc.
>>
>> arch_ima_add_kexec_buffer() defined in "arch/powerpc/kexec/ima.c"
>> sets ima_buffer_addr and ima_buffer_size for the kexec system call.
>> This function does not have architecture specific code, but is
>> currently limited to powerpc.
>>
>> Move ima_buffer_addr and ima_buffer_size to "struct kimage".
>> Rename arch_ima_add_kexec_buffer() to of_ima_add_kexec_buffer()
>> and move it in drivers/of/kexec.c.
>>
>> Co-developed-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>> Suggested-by: Will Deacon <will@kernel.org>
>> ---
>> arch/powerpc/include/asm/ima.h | 3 ---
>> arch/powerpc/include/asm/kexec.h | 5 -----
>> arch/powerpc/kexec/ima.c | 29 ++++++-----------------------
>> drivers/of/kexec.c | 23 +++++++++++++++++++++++
>> include/linux/kexec.h | 3 +++
>> include/linux/of.h | 5 +++++
>> security/integrity/ima/ima_kexec.c | 3 ++-
>> 7 files changed, 39 insertions(+), 32 deletions(-)
>> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
>> index 469e09613cdd..9f33d215b9f2 100644
>> --- a/drivers/of/kexec.c
>> +++ b/drivers/of/kexec.c
>> @@ -63,6 +63,29 @@ static int fdt_find_and_del_mem_rsv(void *fdt, unsigned long start, unsigned lon
>> return -ENOENT;
>> }
>>
>> +#ifdef CONFIG_IMA_KEXEC
>> +/**
>> + * of_ima_add_kexec_buffer - Add IMA buffer for next kernel
>> + *
>> + * @image: kimage struct to set IMA buffer data
>> + * @load_addr: Starting address where IMA buffer is loaded at
>> + * @size: Number of bytes in the IMA buffer
>> + *
>> + * Use this function to pass on the IMA buffer information to
>> + * the next kernel across kexec system call.
>> + *
>> + * Return: 0 on success, negative errno on error.
>> + */
>> +int of_ima_add_kexec_buffer(struct kimage *image,
>> + unsigned long load_addr, size_t size)
>> +{
>> + image->ima_buffer_addr = load_addr;
>> + image->ima_buffer_size = size;
>> +
>
> There's nothing DT specific about this function, so this is the wrong
> place for it. I would just remove it and directly set the members.
Will do.
-lakshmi
^ permalink raw reply
* Re: [PATCH RESEND v6 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
From: Florian Fainelli @ 2021-02-10 18:21 UTC (permalink / raw)
To: Serge Semin, Felipe Balbi, Bjorn Andersson, Krzysztof Kozlowski,
Rob Herring, Greg Kroah-Hartman
Cc: Andrew Lunn, Amelie Delaunay, Tony Lindgren, linux-mips,
Paul Cercueil, Paul Mackerras, linux-stm32, linux-kernel,
Alexandre Torgue, Khuong Dinh, linux-samsung-soc, Gregory Clement,
Rafal Milecki, Alexey Brodkin, Wei Xu, Chen-Yu Tsai, Andy Gross,
bcm-kernel-feedback-list, linux-arm-msm, linux-snps-arc,
Sebastian Hesselbarth, devicetree, Jason Cooper, Hauke Mehrtens,
linuxppc-dev, Maxime Ripard, Vladimir Zapolskiy, Jun Li,
Santosh Shilimkar, Matthias Brugger, Benoit Cousson, linux-omap,
linux-arm-kernel, Thomas Bogendoerfer, Vineet Gupta, linux-usb,
Patrice Chotard, Li Yang, Kukjin Kim, Maxime Coquelin,
linux-mediatek, Shawn Guo
In-Reply-To: <20210210172850.20849-1-Sergey.Semin@baikalelectronics.ru>
On 2/10/21 9:28 AM, Serge Semin wrote:
> As the subject states this series is an attempt to harmonize the xHCI,
> EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
> framework of the patchset [1].
>
> Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
> controllers with "synopsys,"-vendor prefix compatible string in favor of
> the ones with valid "snps,"-prefix. It's done in all the DTS files,
> which have been unfortunate to define such nodes.
>
> Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
> declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
> been erroneously declared as boolean while having uint32 type. Neil said
> it was ok to init that property with 0x20 value.
>
> Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
> and DWC USB3 DT nodes name as in accordance with their DT schema the
> corresponding node name is suppose to comply with the Generic USB HCD DT
> schema, which requires the USB nodes to have the name acceptable by the
> regexp: "^usb(@.*)?". Such requirement had been applicable even before we
> introduced the new DT schema in [1], but as we can see it hasn't been
> strictly implemented for a lot the DTS files. Since DT schema is now
> available the automated DTS validation shall make sure that the rule isn't
> violated.
>
> Note most of these patches have been a part of the last three patches of
> [1]. But since there is no way to have them merged in in a combined
> manner, I had to move them to the dedicated series and split them up so to
> be accepted by the corresponding subsystem maintainers one-by-one.
>
> [1] Link: https://lore.kernel.org/linux-usb/20201014101402.18271-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v1:
> - As Krzysztof suggested I've created a script which checked whether the
> node names had been also updated in all the depended dts files. As a
> result I found two more files which should have been also modified:
> arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
> - Correct the USB DWC3 nodes name found in
> arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
>
> Link: https://lore.kernel.org/linux-usb/20201020115959.2658-1-Sergey.Semin@baikalelectronics.ru
> Changelog v2:
> - Drop the patch:
> [PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
> and get back the one which marks the "synopsys,dwc3" compatible string
> as deprecated into the DT schema related series.
> - Drop the patches:
> [PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
> [PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
> [PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
> [PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
> [PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
> [PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
> [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
> [PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
> [PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
> [PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
> [PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
> since they have been applied to the corresponding maintainers repos.
> - Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
> sub-node and falling back to the "dwc3@"-prefixed one on failure.
>
> Link: https://lore.kernel.org/linux-usb/20201111091552.15593-1-Sergey.Semin@baikalelectronics.ru
> Changelog v3:
> - Drop the patches:
> [PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
> [PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
> [PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
> [PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
> [PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
> [PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
> [PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name
> [PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
> since they have been applied to the corresponding maintainers repos.
>
> Link: https://lore.kernel.org/linux-usb/20201205155621.3045-1-Sergey.Semin@baikalelectronics.ru
> Changelog v4:
> - Just resend.
>
> Link: https://lore.kernel.org/linux-usb/20201210091756.18057-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v5:
> - Drop the patch:
> [PATCH v4 02/10] arm64: dts: amlogic: meson-g12: Set FL-adj property value
> since it has been applied to the corresponding maintainers repos.
> - Get back the patch:
> [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
> as it has been missing in the kernel 5.11-rc7
> - Rebase onto the kernel 5.11-rc7
>
> Link: https://lore.kernel.org/lkml/20210208135154.6645-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v6:
> - Just resend and add linux-usb.vger.kernel.org to the list of Ccecipients.
If this needs to go on, can you drop the people who already took your
patches (trying to lower my email amount to something manageable).
Thank you.
--
Florian
^ permalink raw reply
* Re: [PATCH RESEND v6 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
From: Serge Semin @ 2021-02-10 18:43 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Amelie Delaunay, Tony Lindgren, Bjorn Andersson,
Paul Cercueil, Paul Mackerras, Wei Xu, linux-stm32, linux-kernel,
Alexandre Torgue, Khuong Dinh, linux-samsung-soc, Gregory Clement,
Rafal Milecki, Alexey Brodkin, Krzysztof Kozlowski, Chen-Yu Tsai,
Andy Gross, bcm-kernel-feedback-list, linux-arm-msm,
linux-snps-arc, Maxime Coquelin, Sebastian Hesselbarth,
devicetree, Jason Cooper, Hauke Mehrtens, linuxppc-dev,
Maxime Ripard, Vladimir Zapolskiy, Rob Herring, Jun Li,
Santosh Shilimkar, Matthias Brugger, linux-omap, linux-arm-kernel,
Felipe Balbi, Thomas Bogendoerfer, linux-mips, Greg Kroah-Hartman,
linux-usb, Patrice Chotard, Serge Semin, Li Yang, Kukjin Kim,
Benoit Cousson, Vineet Gupta, linux-mediatek, Shawn Guo
In-Reply-To: <e169630f-1255-7597-86f2-63ee8760cc8c@gmail.com>
On Wed, Feb 10, 2021 at 10:21:47AM -0800, Florian Fainelli wrote:
> On 2/10/21 9:28 AM, Serge Semin wrote:
> > As the subject states this series is an attempt to harmonize the xHCI,
> > EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
> > framework of the patchset [1].
> >
> > Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
> > controllers with "synopsys,"-vendor prefix compatible string in favor of
> > the ones with valid "snps,"-prefix. It's done in all the DTS files,
> > which have been unfortunate to define such nodes.
> >
> > Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
> > declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
> > been erroneously declared as boolean while having uint32 type. Neil said
> > it was ok to init that property with 0x20 value.
> >
> > Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
> > and DWC USB3 DT nodes name as in accordance with their DT schema the
> > corresponding node name is suppose to comply with the Generic USB HCD DT
> > schema, which requires the USB nodes to have the name acceptable by the
> > regexp: "^usb(@.*)?". Such requirement had been applicable even before we
> > introduced the new DT schema in [1], but as we can see it hasn't been
> > strictly implemented for a lot the DTS files. Since DT schema is now
> > available the automated DTS validation shall make sure that the rule isn't
> > violated.
> >
> > Note most of these patches have been a part of the last three patches of
> > [1]. But since there is no way to have them merged in in a combined
> > manner, I had to move them to the dedicated series and split them up so to
> > be accepted by the corresponding subsystem maintainers one-by-one.
> >
> > [1] Link: https://lore.kernel.org/linux-usb/20201014101402.18271-1-Sergey.Semin@baikalelectronics.ru/
> > Changelog v1:
> > - As Krzysztof suggested I've created a script which checked whether the
> > node names had been also updated in all the depended dts files. As a
> > result I found two more files which should have been also modified:
> > arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
> > - Correct the USB DWC3 nodes name found in
> > arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
> >
> > Link: https://lore.kernel.org/linux-usb/20201020115959.2658-1-Sergey.Semin@baikalelectronics.ru
> > Changelog v2:
> > - Drop the patch:
> > [PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
> > and get back the one which marks the "synopsys,dwc3" compatible string
> > as deprecated into the DT schema related series.
> > - Drop the patches:
> > [PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
> > [PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
> > [PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
> > [PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
> > [PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
> > [PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
> > [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
> > [PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
> > [PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
> > [PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
> > [PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
> > since they have been applied to the corresponding maintainers repos.
> > - Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
> > sub-node and falling back to the "dwc3@"-prefixed one on failure.
> >
> > Link: https://lore.kernel.org/linux-usb/20201111091552.15593-1-Sergey.Semin@baikalelectronics.ru
> > Changelog v3:
> > - Drop the patches:
> > [PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
> > [PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name
> > [PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
> > since they have been applied to the corresponding maintainers repos.
> >
> > Link: https://lore.kernel.org/linux-usb/20201205155621.3045-1-Sergey.Semin@baikalelectronics.ru
> > Changelog v4:
> > - Just resend.
> >
> > Link: https://lore.kernel.org/linux-usb/20201210091756.18057-1-Sergey.Semin@baikalelectronics.ru/
> > Changelog v5:
> > - Drop the patch:
> > [PATCH v4 02/10] arm64: dts: amlogic: meson-g12: Set FL-adj property value
> > since it has been applied to the corresponding maintainers repos.
> > - Get back the patch:
> > [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
> > as it has been missing in the kernel 5.11-rc7
> > - Rebase onto the kernel 5.11-rc7
> >
> > Link: https://lore.kernel.org/lkml/20210208135154.6645-1-Sergey.Semin@baikalelectronics.ru/
> > Changelog v6:
> > - Just resend and add linux-usb.vger.kernel.org to the list of Ccecipients.
>
>
> If this needs to go on, can you drop the people who already took your
> patches (trying to lower my email amount to something manageable).
> Thank you.
Ah, sorry for the noise. I'll clean the Cc-list up in the next attempt
to have this finally fully accepted.
-Sergey
> --
> Florian
^ permalink raw reply
* [PATCH] arm64: defconfig: enable modern virtio pci device
From: Anders Roxell @ 2021-02-10 19:05 UTC (permalink / raw)
To: soc
Cc: chris, tsbogend, Anders Roxell, mst, arnd, linuxppc-dev,
catalin.marinas, linux-xtensa, paul.walmsley, virtualization,
linux-kernel, linux, jcmvbkbc, aou, palmer, linux-riscv,
linux-mips, will, jasowang, linux-arm-kernel
Since patch ("virtio-pci: introduce modern device module") got added it
is not possible to boot a defconfig kernel in qemu with a virtio pci
device. Add CONFIG_VIRTIO_PCI_MODERN=y fragment makes the kernel able
to boot.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm64/configs/defconfig | 1 +
arch/mips/configs/loongson3_defconfig | 1 +
arch/mips/configs/malta_kvm_guest_defconfig | 1 +
arch/powerpc/configs/guest.config | 1 +
arch/riscv/configs/defconfig | 1 +
arch/riscv/configs/rv32_defconfig | 1 +
arch/xtensa/configs/virt_defconfig | 1 +
kernel/configs/kvm_guest.config | 1 +
9 files changed, 9 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 3823da605430..02297ed49b20 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -972,6 +972,7 @@ CONFIG_DW_DMAC=y
CONFIG_RCAR_DMAC=y
CONFIG_RENESAS_USB_DMAC=m
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_VIRTIO_MMIO=y
CONFIG_STAGING=y
CONFIG_MFD_NVEC=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 83c28da85834..8334e9cb4608 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -910,6 +910,7 @@ CONFIG_TI_K3_UDMA_GLUE_LAYER=y
CONFIG_VFIO=y
CONFIG_VFIO_PCI=y
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
CONFIG_XEN_GNTDEV=y
diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
index 0e79f81217bc..ac5f2dcbffb1 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -324,6 +324,7 @@ CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_GOLDFISH=y
CONFIG_DMADEVICES=y
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_VIRTIO_BALLOON=m
CONFIG_VIRTIO_INPUT=y
CONFIG_VIRTIO_MMIO=y
diff --git a/arch/mips/configs/malta_kvm_guest_defconfig b/arch/mips/configs/malta_kvm_guest_defconfig
index 9185e0a0aa45..043633cdb406 100644
--- a/arch/mips/configs/malta_kvm_guest_defconfig
+++ b/arch/mips/configs/malta_kvm_guest_defconfig
@@ -332,6 +332,7 @@ CONFIG_RTC_DRV_CMOS=y
CONFIG_UIO=m
CONFIG_UIO_CIF=m
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
CONFIG_EXT2_FS=y
diff --git a/arch/powerpc/configs/guest.config b/arch/powerpc/configs/guest.config
index 209f58515d88..fbff632c8633 100644
--- a/arch/powerpc/configs/guest.config
+++ b/arch/powerpc/configs/guest.config
@@ -5,6 +5,7 @@ CONFIG_NET_FAILOVER=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_KVM_GUEST=y
CONFIG_EPAPR_PARAVIRT=y
CONFIG_VIRTIO_BALLOON=y
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 8c3d1e451703..b7fa7a1a0c6d 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -85,6 +85,7 @@ CONFIG_MMC=y
CONFIG_MMC_SPI=y
CONFIG_RTC_CLASS=y
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_INPUT=y
CONFIG_VIRTIO_MMIO=y
diff --git a/arch/riscv/configs/rv32_defconfig b/arch/riscv/configs/rv32_defconfig
index 2c2cda6cc1c5..68296101fa06 100644
--- a/arch/riscv/configs/rv32_defconfig
+++ b/arch/riscv/configs/rv32_defconfig
@@ -84,6 +84,7 @@ CONFIG_MMC=y
CONFIG_MMC_SPI=y
CONFIG_RTC_CLASS=y
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_INPUT=y
CONFIG_VIRTIO_MMIO=y
diff --git a/arch/xtensa/configs/virt_defconfig b/arch/xtensa/configs/virt_defconfig
index 6d1387dfa96f..7fad1c2454fd 100644
--- a/arch/xtensa/configs/virt_defconfig
+++ b/arch/xtensa/configs/virt_defconfig
@@ -74,6 +74,7 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
# CONFIG_USB_SUPPORT is not set
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_VIRTIO_INPUT=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT3_FS=y
diff --git a/kernel/configs/kvm_guest.config b/kernel/configs/kvm_guest.config
index 208481d91090..8dea6df20006 100644
--- a/kernel/configs/kvm_guest.config
+++ b/kernel/configs/kvm_guest.config
@@ -22,6 +22,7 @@ CONFIG_S390_GUEST=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_MENU=y
CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_VIRTIO_NET=y
--
2.30.0
^ permalink raw reply related
* Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64
From: Rob Herring @ 2021-02-10 20:42 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: Mark Rutland, tao.li, Mimi Zohar, Paul Mackerras,
vincenzo.frascino, Frank Rowand, Sasha Levin, Masahiro Yamada,
James Morris, AKASHI, Takahiro, linux-arm-kernel, Catalin Marinas,
Serge E. Hallyn, devicetree, Pavel Tatashin, Will Deacon,
Prakhar Srivastava, Hsin-Yi Wang, Allison Randal,
Christophe Leroy, Matthias Brugger, balajib, dmitry.kasatkin,
linux-kernel@vger.kernel.org, James Morse, Greg Kroah-Hartman,
Joe Perches, linux-integrity, linuxppc-dev, Thiago Jung Bauermann
In-Reply-To: <5c002c32-bc49-acda-c641-7b1494ea292d@linux.microsoft.com>
On Wed, Feb 10, 2021 at 11:33 AM Lakshmi Ramasubramanian
<nramas@linux.microsoft.com> wrote:
>
> On 2/10/21 9:15 AM, Rob Herring wrote:
> > On Tue, Feb 09, 2021 at 10:21:50AM -0800, Lakshmi Ramasubramanian wrote:
> >> On kexec file load Integrity Measurement Architecture (IMA) subsystem
> >> may verify the IMA signature of the kernel and initramfs, and measure
> >> it. The command line parameters passed to the kernel in the kexec call
> >> may also be measured by IMA. A remote attestation service can verify
> >> a TPM quote based on the TPM event log, the IMA measurement list, and
> >> the TPM PCR data. This can be achieved only if the IMA measurement log
> >> is carried over from the current kernel to the next kernel across
> >> the kexec call.
> >>
> >> powerpc already supports carrying forward the IMA measurement log on
> >> kexec. This patch set adds support for carrying forward the IMA
> >> measurement log on kexec on ARM64.
> >>
> >> This patch set moves the platform independent code defined for powerpc
> >> such that it can be reused for other platforms as well. A chosen node
> >> "linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
> >> the address and the size of the memory reserved to carry
> >> the IMA measurement log.
> >>
> >> This patch set has been tested for ARM64 platform using QEMU.
> >> I would like help from the community for testing this change on powerpc.
> >> Thanks.
> >>
> >> This patch set is based on
> >> commit 96acc833dec8 ("ima: Free IMA measurement buffer after kexec syscall")
> >> in https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> >> "next-integrity" branch.
> >
> > Is that a hard dependency still? Given this is now almost entirely
> > deleting arch code and adding drivers/of/ code, I was going to apply it.
> >
>
> I tried applying the patches in Linus' mainline branch -
> PATCH #5 0005-powerpc-Move-ima-buffer-fields-to-struct-kimage.patch
> doesn't apply.
>
> But if I apply the dependent patch set (link given below), all the
> patches in this patch set apply fine.
>
> https://patchwork.kernel.org/project/linux-integrity/patch/20210204174951.25771-2-nramas@linux.microsoft.com/
Ideally, we don't apply the same patch in 2 branches. It looks like
there's a conflict but no real dependence on the above patch (the
ima_buffer part). The conflict seems trivial enough that Linus can
resolve it in the merge window.
Or Mimi can take the whole thing if preferred?
Rob
^ permalink raw reply
* Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64
From: Mimi Zohar @ 2021-02-10 20:55 UTC (permalink / raw)
To: Rob Herring, Lakshmi Ramasubramanian
Cc: Mark Rutland, tao.li, Paul Mackerras, vincenzo.frascino,
Frank Rowand, Sasha Levin, Masahiro Yamada, James Morris,
AKASHI, Takahiro, linux-arm-kernel, Catalin Marinas,
Serge E. Hallyn, devicetree, Pavel Tatashin, Will Deacon,
Prakhar Srivastava, Hsin-Yi Wang, Allison Randal,
Christophe Leroy, Matthias Brugger, balajib, dmitry.kasatkin,
linux-kernel@vger.kernel.org, James Morse, Greg Kroah-Hartman,
Joe Perches, linux-integrity, linuxppc-dev, Thiago Jung Bauermann
In-Reply-To: <CAL_JsqLmdqfFF8u=dE+dQz+6ngv=moWkQF8tpZjUCX-vHuvU_w@mail.gmail.com>
On Wed, 2021-02-10 at 14:42 -0600, Rob Herring wrote:
> On Wed, Feb 10, 2021 at 11:33 AM Lakshmi Ramasubramanian
> <nramas@linux.microsoft.com> wrote:
> >
> > On 2/10/21 9:15 AM, Rob Herring wrote:
> > > On Tue, Feb 09, 2021 at 10:21:50AM -0800, Lakshmi Ramasubramanian wrote:
> > >> On kexec file load Integrity Measurement Architecture (IMA) subsystem
> > >> may verify the IMA signature of the kernel and initramfs, and measure
> > >> it. The command line parameters passed to the kernel in the kexec call
> > >> may also be measured by IMA. A remote attestation service can verify
> > >> a TPM quote based on the TPM event log, the IMA measurement list, and
> > >> the TPM PCR data. This can be achieved only if the IMA measurement log
> > >> is carried over from the current kernel to the next kernel across
> > >> the kexec call.
> > >>
> > >> powerpc already supports carrying forward the IMA measurement log on
> > >> kexec. This patch set adds support for carrying forward the IMA
> > >> measurement log on kexec on ARM64.
> > >>
> > >> This patch set moves the platform independent code defined for powerpc
> > >> such that it can be reused for other platforms as well. A chosen node
> > >> "linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
> > >> the address and the size of the memory reserved to carry
> > >> the IMA measurement log.
> > >>
> > >> This patch set has been tested for ARM64 platform using QEMU.
> > >> I would like help from the community for testing this change on powerpc.
> > >> Thanks.
> > >>
> > >> This patch set is based on
> > >> commit 96acc833dec8 ("ima: Free IMA measurement buffer after kexec syscall")
> > >> in https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> > >> "next-integrity" branch.
> > >
> > > Is that a hard dependency still? Given this is now almost entirely
> > > deleting arch code and adding drivers/of/ code, I was going to apply it.
> > >
> >
> > I tried applying the patches in Linus' mainline branch -
> > PATCH #5 0005-powerpc-Move-ima-buffer-fields-to-struct-kimage.patch
> > doesn't apply.
> >
> > But if I apply the dependent patch set (link given below), all the
> > patches in this patch set apply fine.
> >
> > https://patchwork.kernel.org/project/linux-integrity/patch/20210204174951.25771-2-nramas@linux.microsoft.com/
>
> Ideally, we don't apply the same patch in 2 branches. It looks like
> there's a conflict but no real dependence on the above patch (the
> ima_buffer part). The conflict seems trivial enough that Linus can
> resolve it in the merge window.
>
> Or Mimi can take the whole thing if preferred?
How about I create a topic branch with just the two patches, allowing
both of us to merge it? There shouldn't be a problem with re-writing
next-integrity history.
Mimi
^ permalink raw reply
* Re: [PATCH v5 03/10] powerpc/signal64: Move non-inline functions out of setup_sigcontext()
From: Daniel Axtens @ 2021-02-10 21:06 UTC (permalink / raw)
To: Christopher M. Riedl, linuxppc-dev
In-Reply-To: <C95KM1QVX9G3.3HP1E2NXRPNSG@oc8246131445.ibm.com>
"Christopher M. Riedl" <cmr@codefail.de> writes:
> On Sun Feb 7, 2021 at 10:44 PM CST, Daniel Axtens wrote:
>> Hi Chris,
>>
>> These two paragraphs are a little confusing and they seem slightly
>> repetitive. But I get the general idea. Two specific comments below:
>
> Umm... yeah only one of those was supposed to be sent. I will reword
> this for the next spin and address the comment below about how it is
> not entirely clear that the inline functions are being moved out.
>
>>
>> > There are non-inline functions which get called in setup_sigcontext() to
>> > save register state to the thread struct. Move these functions into a
>> > separate prepare_setup_sigcontext() function so that
>> > setup_sigcontext() can be refactored later into an "unsafe" version
>> > which assumes an open uaccess window. Non-inline functions should be
>> > avoided when uaccess is open.
>>
>> Why do we want to avoid non-inline functions? We came up with:
>>
>> - we want KUAP protection for as much of the kernel as possible: each
>> extra bit of code run with the window open is another piece of attack
>> surface.
>>
>> - non-inline functions default to traceable, which means we could end
>> up ftracing while uaccess is enabled. That's a pretty big hole in the
>> defences that KUAP provides.
>>
>> I think we've also had problems with the window being opened or closed
>> unexpectedly by various bits of code? So the less code runs in uaccess
>> context the less likely that is to occur.
>
> That is my understanding as well.
>
>>
>> > The majority of setup_sigcontext() can be refactored to execute in an
>> > "unsafe" context (uaccess window is opened) except for some non-inline
>> > functions. Move these out into a separate prepare_setup_sigcontext()
>> > function which must be called first and before opening up a uaccess
>> > window. A follow-up commit converts setup_sigcontext() to be "unsafe".
>>
>> This was a bit confusing until we realise that you're moving the _calls_
>> to the non-inline functions out, not the non-inline functions
>> themselves.
>>
>> > Signed-off-by: Christopher M. Riedl <cmr@codefail.de>
>> > ---
>> > arch/powerpc/kernel/signal_64.c | 32 +++++++++++++++++++++-----------
>> > 1 file changed, 21 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
>> > index f9e4a1ac440f..b211a8ea4f6e 100644
>> > --- a/arch/powerpc/kernel/signal_64.c
>> > +++ b/arch/powerpc/kernel/signal_64.c
>> > @@ -79,6 +79,24 @@ static elf_vrreg_t __user *sigcontext_vmx_regs(struct sigcontext __user *sc)
>> > }
>> > #endif
>> >
>> > +static void prepare_setup_sigcontext(struct task_struct *tsk, int ctx_has_vsx_region)
>>
>> ctx_has_vsx_region should probably be a bool? Although setup_sigcontext
>> also has it as an int so I guess that's arguable, and maybe it's better
>> to stick with this for constency.
>
> I've been told not to introduce unrelated changes in my patches before
> so chose to keep this as an int for consistency.
Seems reasonable.
>
>>
>> > +{
>> > +#ifdef CONFIG_ALTIVEC
>> > + /* save altivec registers */
>> > + if (tsk->thread.used_vr)
>> > + flush_altivec_to_thread(tsk);
>> > + if (cpu_has_feature(CPU_FTR_ALTIVEC))
>> > + tsk->thread.vrsave = mfspr(SPRN_VRSAVE);
>> > +#endif /* CONFIG_ALTIVEC */
>> > +
>> > + flush_fp_to_thread(tsk);
>> > +
>> > +#ifdef CONFIG_VSX
>> > + if (tsk->thread.used_vsr && ctx_has_vsx_region)
>> > + flush_vsx_to_thread(tsk);
>> > +#endif /* CONFIG_VSX */
>>
>> Alternatively, given that this is the only use of ctx_has_vsx_region,
>> mpe suggested that perhaps we could drop it entirely and always
>> flush_vsx if used_vsr. The function is only ever called with either
>> `current` or wth ctx_has_vsx_region set to 1, so in either case I think
>> that's safe? I'm not sure if it would have performance implications.
>
> I think that could work as long as we can guarantee that the context
> passed to swapcontext will always be sufficiently sized if used_vsr,
> which I think *has* to be the case?
I think you're always guaranteed that you'll have a big enough one
in your kernel thread, which is what you end up writing to, iiuc?
>>
>> Should we move this and the altivec ifdef to IS_ENABLED(CONFIG_VSX) etc?
>> I'm not sure if that runs into any problems with things like 'used_vsr'
>> only being defined if CONFIG_VSX is set, but I thought I'd ask.
>
> That's why I didn't use IS_ENABLED(CONFIG_...) here - all of these
> field (used_vr, vrsave, used_vsr) declarations are guarded by #ifdefs :/
Dang. Oh well.
>
>>
>>
>> > +}
>> > +
>> > /*
>> > * Set up the sigcontext for the signal frame.
>> > */
>> > @@ -97,7 +115,6 @@ static long setup_sigcontext(struct sigcontext __user *sc,
>> > */
>> > #ifdef CONFIG_ALTIVEC
>> > elf_vrreg_t __user *v_regs = sigcontext_vmx_regs(sc);
>> > - unsigned long vrsave;
>> > #endif
>> > struct pt_regs *regs = tsk->thread.regs;
>> > unsigned long msr = regs->msr;
>> > @@ -112,7 +129,6 @@ static long setup_sigcontext(struct sigcontext __user *sc,
>> >
>> > /* save altivec registers */
>> > if (tsk->thread.used_vr) {
>> > - flush_altivec_to_thread(tsk);
>> > /* Copy 33 vec registers (vr0..31 and vscr) to the stack */
>> > err |= __copy_to_user(v_regs, &tsk->thread.vr_state,
>> > 33 * sizeof(vector128));
>> > @@ -124,17 +140,10 @@ static long setup_sigcontext(struct sigcontext __user *sc,
>> > /* We always copy to/from vrsave, it's 0 if we don't have or don't
>> > * use altivec.
>> > */
>> > - vrsave = 0;
>> > - if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
>> > - vrsave = mfspr(SPRN_VRSAVE);
>> > - tsk->thread.vrsave = vrsave;
>> > - }
>> > -
>> > - err |= __put_user(vrsave, (u32 __user *)&v_regs[33]);
>> > + err |= __put_user(tsk->thread.vrsave, (u32 __user *)&v_regs[33]);
>>
>> Previously, if !cpu_has_feature(ALTIVEC), v_regs[33] had vrsave stored,
>> which was set to 0 explicitly. Now we store thread.vrsave instead of the
>> local vrsave. That should be safe - it is initalised to 0 elsewhere.
>>
>> So you don't have to do anything here, this is just letting you know
>> that we checked it and thought about it.
>
> Thanks! I thought about adding a comment/note here as I had to convince
> myself that thread.vrsave is indeed initialized to 0 before making this
> change as well. I will mention it in the word-smithed commit message for
> posterity.
>
>>
>> > #else /* CONFIG_ALTIVEC */
>> > err |= __put_user(0, &sc->v_regs);
>> > #endif /* CONFIG_ALTIVEC */
>> > - flush_fp_to_thread(tsk);
>> > /* copy fpr regs and fpscr */
>> > err |= copy_fpr_to_user(&sc->fp_regs, tsk);
>> >
>> > @@ -150,7 +159,6 @@ static long setup_sigcontext(struct sigcontext __user *sc,
>> > * VMX data.
>> > */
>> > if (tsk->thread.used_vsr && ctx_has_vsx_region) {
>> > - flush_vsx_to_thread(tsk);
>> > v_regs += ELF_NVRREG;
>> > err |= copy_vsx_to_user(v_regs, tsk);
>> > /* set MSR_VSX in the MSR value in the frame to
>> > @@ -655,6 +663,7 @@ SYSCALL_DEFINE3(swapcontext, struct ucontext __user *, old_ctx,
>> > ctx_has_vsx_region = 1;
>> >
>> > if (old_ctx != NULL) {
>> > + prepare_setup_sigcontext(current, ctx_has_vsx_region);
>> > if (!access_ok(old_ctx, ctx_size)
>> > || setup_sigcontext(&old_ctx->uc_mcontext, current, 0, NULL, 0,
>> > ctx_has_vsx_region)
>>
>> I had a think about whether there was a problem with bubbling
>> prepare_setup_sigcontext over the access_ok() test, but given that
>> prepare_setup_sigcontext(current ...) doesn't access any of old_ctx, I'm
>> satisfied that it's OK - no changes needed.
>
> Not sure I understand what you mean by 'bubbling over'?
Yeah sorry, overly flowery language there. I mean that the accesses that
prepare_setup_sigcontext does have moved up - like a bubble in fluid -
from after access_ok to before access_ok.
Kind regards,
Daniel
>>
>>
>> > @@ -842,6 +851,7 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
>> > #endif
>> > {
>> > err |= __put_user(0, &frame->uc.uc_link);
>> > + prepare_setup_sigcontext(tsk, 1);
>>
>> Why do we call with ctx_has_vsx_region = 1 here? It's not immediately
>> clear to me why this is correct, but mpe and Mikey seem pretty convinced
>> that it is.
>
> I think it's because we always have a "complete" sigcontext w/ the VSX
> save area here, unlike in swapcontext where we have to check. Also, the
> following unsafe_setup_sigcontext() is called with ctx_has_vsx_region=1
> so assumes that the VSX data was copied by prepare_setup_sigcontext().
>
>>
>> > err |= setup_sigcontext(&frame->uc.uc_mcontext, tsk, ksig->sig,
>> > NULL, (unsigned long)ksig->ka.sa.sa_handler,
>> > 1);
>>
>>
>> Finally, it's a bit hard to figure out where to put this, but we spent
>> some time making sure that the various things you moved into the
>> prepare_setup_sigcontext() function were called under the same
>> circumstances as they were before, and there were no concerns there.
>
> Thanks for reviewing and double checking my work :)
>
>>
>> Kind regards,
>> Daniel
^ permalink raw reply
* Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64
From: Mimi Zohar @ 2021-02-10 21:39 UTC (permalink / raw)
To: Rob Herring, Lakshmi Ramasubramanian
Cc: Mark Rutland, tao.li, Paul Mackerras, vincenzo.frascino,
Frank Rowand, Sasha Levin, Masahiro Yamada, James Morris,
AKASHI, Takahiro, linux-arm-kernel, Catalin Marinas,
Serge E. Hallyn, devicetree, Pavel Tatashin, Will Deacon,
Prakhar Srivastava, Hsin-Yi Wang, Allison Randal,
Christophe Leroy, Matthias Brugger, balajib, dmitry.kasatkin,
linux-kernel@vger.kernel.org, James Morse, Greg Kroah-Hartman,
Joe Perches, linux-integrity, linuxppc-dev, Thiago Jung Bauermann
In-Reply-To: <cf7930239b93044a1be353556b7dc730e024f658.camel@linux.ibm.com>
On Wed, 2021-02-10 at 15:55 -0500, Mimi Zohar wrote:
> On Wed, 2021-02-10 at 14:42 -0600, Rob Herring wrote:
> > On Wed, Feb 10, 2021 at 11:33 AM Lakshmi Ramasubramanian
>
> > Ideally, we don't apply the same patch in 2 branches. It looks like
> > there's a conflict but no real dependence on the above patch (the
> > ima_buffer part). The conflict seems trivial enough that Linus can
> > resolve it in the merge window.
> >
> > Or Mimi can take the whole thing if preferred?
>
> How about I create a topic branch with just the two patches, allowing
> both of us to merge it? There shouldn't be a problem with re-writing
> next-integrity history.
The 2 patches are now in the ima-kexec-fixes branch.
Mimi
^ permalink raw reply
* Re: [PATCH v2 3/7] ASoC: dt-bindings: fsl_rpmsg: Add binding doc for rpmsg cpu dai driver
From: Rob Herring @ 2021-02-10 22:12 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, lgirdwood, linuxppc-dev, Xiubo.Lee,
linux-kernel, tiwai, nicoleotsuka, broonie, perex, festevam
In-Reply-To: <1612693435-31418-4-git-send-email-shengjiu.wang@nxp.com>
On Sun, Feb 07, 2021 at 06:23:51PM +0800, Shengjiu Wang wrote:
> fsl_rpmsg cpu dai driver is driver for rpmsg audio, which is mainly used
> for getting the user's configuration from device tree and configure the
> clocks which is used by Cortex-M core. So in this document define the
> needed property.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> .../devicetree/bindings/sound/fsl,rpmsg.yaml | 80 +++++++++++++++++++
> 1 file changed, 80 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
> new file mode 100644
> index 000000000000..2d3ce10d42fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/fsl,rpmsg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP Audio RPMSG CPU DAI Controller
> +
> +maintainers:
> + - Shengjiu Wang <shengjiu.wang@nxp.com>
> +
> +properties:
> + compatible:
> + enum:
> + - fsl,imx7ulp-rpmsg
> + - fsl,imx8mn-rpmsg
> + - fsl,imx8mm-rpmsg
> + - fsl,imx8mp-rpmsg
rpmsg is a protocol. What's the h/w block?
> +
> + clocks:
> + items:
> + - description: Peripheral clock for register access
> + - description: Master clock
> + - description: DMA clock for DMA register access
> + - description: Parent clock for multiple of 8kHz sample rates
> + - description: Parent clock for multiple of 11kHz sample rates
> + minItems: 5
> +
> + clock-names:
> + items:
> + - const: ipg
> + - const: mclk
> + - const: dma
> + - const: pll8k
> + - const: pll11k
> + minItems: 5
> +
> + power-domains:
> + maxItems: 1
> +
> + fsl,audioindex:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: instance index for rpmsg image
> +
> + fsl,version:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: rpmsg image version index
What are these 2 used for?
> +
> + fsl,buffer-size:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: pre allocate dma buffer size
> +
> + fsl,enable-lpa:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: enable low power audio path.
> +
> + fsl,codec-type:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Sometimes the codec is registered by
> + driver not the device tree, this items
> + can be used to distinguish codecs
0-2^32 are valid values?
> +
> +required:
> + - compatible
> + - fsl,audioindex
> + - fsl,version
> + - fsl,buffer-size
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + rpmsg_audio: rpmsg_audio {
> + compatible = "fsl,imx8mn-rpmsg";
> + fsl,audioindex = <0> ;
> + fsl,version = <2>;
> + fsl,buffer-size = <0x6000000>;
> + fsl,enable-lpa;
> + status = "okay";
Don't show status in examples.
> + };
> --
> 2.27.0
>
^ permalink raw reply
* Re: [PATCH v2 7/7] ASoC: dt-bindings: imx-rpmsg: Add binding doc for rpmsg machine driver
From: Rob Herring @ 2021-02-10 22:17 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, lgirdwood, linuxppc-dev, Xiubo.Lee,
linux-kernel, tiwai, nicoleotsuka, broonie, perex, festevam
In-Reply-To: <1612693435-31418-8-git-send-email-shengjiu.wang@nxp.com>
On Sun, Feb 07, 2021 at 06:23:55PM +0800, Shengjiu Wang wrote:
> Imx-rpmsg is a new added machine driver for supporting audio on Cortex-M
> core. The Cortex-M core will control the audio interface, DMA and audio
> codec, setup the pipeline, the audio driver on Cortex-A core side is just
> to communitcate with M core, it is a virtual sound card and don't touch
> the hardware.
I don't understand why there are 2 nodes for this other than you happen
to want to split this into 2 Linux drivers. It's 1 h/w thing.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> .../bindings/sound/imx-audio-rpmsg.yaml | 48 +++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml b/Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml
> new file mode 100644
> index 000000000000..b941aeb80678
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/imx-audio-rpmsg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP i.MX audio complex with rpmsg
> +
> +maintainers:
> + - Shengjiu Wang <shengjiu.wang@nxp.com>
> +
> +properties:
> + compatible:
> + enum:
> + - fsl,imx-audio-rpmsg
> +
> + model:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: User specified audio sound card name
> +
> + audio-cpu:
> + description: The phandle of an CPU DAI controller
> +
> + rpmsg-out:
> + description: |
> + This is a boolean property. If present, the transmitting function
> + will be enabled,
> +
> + rpmsg-in:
> + description: |
> + This is a boolean property. If present, the receiving function
> + will be enabled.
> +
> +required:
> + - compatible
> + - model
> + - audio-cpu
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + sound-rpmsg {
> + compatible = "fsl,imx-audio-rpmsg";
> + model = "ak4497-audio";
> + audio-cpu = <&rpmsg_audio>;
> + rpmsg-out;
> + };
> --
> 2.27.0
>
^ permalink raw reply
* Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64
From: Lakshmi Ramasubramanian @ 2021-02-10 22:34 UTC (permalink / raw)
To: Mimi Zohar, Rob Herring
Cc: Mark Rutland, tao.li, Paul Mackerras, vincenzo.frascino,
Frank Rowand, Sasha Levin, Masahiro Yamada, James Morris,
AKASHI, Takahiro, linux-arm-kernel, Catalin Marinas,
Serge E. Hallyn, devicetree, Pavel Tatashin, Will Deacon,
Prakhar Srivastava, Hsin-Yi Wang, Allison Randal,
Christophe Leroy, Matthias Brugger, balajib, dmitry.kasatkin,
linux-kernel@vger.kernel.org, James Morse, Greg Kroah-Hartman,
Joe Perches, linux-integrity, linuxppc-dev, Thiago Jung Bauermann
In-Reply-To: <594445d01e085875b97b46be726247f89d1e6661.camel@linux.ibm.com>
On 2/10/21 1:39 PM, Mimi Zohar wrote:
> On Wed, 2021-02-10 at 15:55 -0500, Mimi Zohar wrote:
>> On Wed, 2021-02-10 at 14:42 -0600, Rob Herring wrote:
>>> On Wed, Feb 10, 2021 at 11:33 AM Lakshmi Ramasubramanian
>>
>>> Ideally, we don't apply the same patch in 2 branches. It looks like
>>> there's a conflict but no real dependence on the above patch (the
>>> ima_buffer part). The conflict seems trivial enough that Linus can
>>> resolve it in the merge window.
>>>
>>> Or Mimi can take the whole thing if preferred?
>>
>> How about I create a topic branch with just the two patches, allowing
>> both of us to merge it? There shouldn't be a problem with re-writing
>> next-integrity history.
>
> The 2 patches are now in the ima-kexec-fixes branch.
>
Thanks a lot Mimi.
Rob - I will address the 2 comments you'd provided today, and build the
patches in ima-kexec-fixes branch.
If you have more comments in the v17 patches, please let me know.
thanks,
-lakshmi
^ permalink raw reply
* Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function
From: Thiago Jung Bauermann @ 2021-02-10 23:24 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, robh, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev
In-Reply-To: <20210209182200.30606-3-nramas@linux.microsoft.com>
Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
> From: Rob Herring <robh@kernel.org>
>
> Both arm64 and powerpc do essentially the same FDT /chosen setup for
> kexec. The differences are either omissions that arm64 should have
> or additional properties that will be ignored. The setup code can be
> combined and shared by both powerpc and arm64.
>
> The differences relative to the arm64 version:
> - If /chosen doesn't exist, it will be created (should never happen).
> - Any old dtb and initrd reserved memory will be released.
> - The new initrd and elfcorehdr are marked reserved.
> - "linux,booted-from-kexec" is set.
>
> The differences relative to the powerpc version:
> - "kaslr-seed" and "rng-seed" may be set.
> - "linux,elfcorehdr" is set.
> - Any existing "linux,usable-memory-range" is removed.
>
> Combine the code for setting up the /chosen node in the FDT and updating
> the memory reservation for kexec, for powerpc and arm64, in
> of_kexec_alloc_and_setup_fdt() and move it to "drivers/of/kexec.c".
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> ---
> drivers/of/Makefile | 6 ++
> drivers/of/kexec.c | 258 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of.h | 13 +++
> 3 files changed, 277 insertions(+)
> create mode 100644 drivers/of/kexec.c
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v17 03/10] arm64: Use common of_kexec_alloc_and_setup_fdt()
From: Thiago Jung Bauermann @ 2021-02-10 23:30 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, robh, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev
In-Reply-To: <20210209182200.30606-4-nramas@linux.microsoft.com>
Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
> From: Rob Herring <robh@kernel.org>
>
> The code for setting up the /chosen node in the device tree
> and updating the memory reservation for the next kernel has been
> moved to of_kexec_alloc_and_setup_fdt() defined in "drivers/of/kexec.c".
>
> Use the common of_kexec_alloc_and_setup_fdt() to setup the device tree
> and update the memory reservation for kexec for arm64.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> ---
> arch/arm64/kernel/machine_kexec_file.c | 180 ++-----------------------
> 1 file changed, 8 insertions(+), 172 deletions(-)
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: Declaring unrecoverable_exception() as __noreturn ?
From: Nicholas Piggin @ 2021-02-11 0:44 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5ecc1a9a-92eb-7006-6c94-2b7b700d182a@csgroup.eu>
Excerpts from Christophe Leroy's message of February 11, 2021 2:44 am:
> As far as I can see, almost all callers of unrecoverable_exception() expect it to never return.
>
> Can we mark it __noreturn ?
I don't see why not, do_exit is noreturn. We could make die() noreturn
as well.
>
> Below is interrupt_exit_kernel_prepare() with then without unrecoverable_exception() declared as
> __noreturn. (CONFIG_PREEMPT_NONE, and with the BUG_ON() removed)
>
> With the __noreturn added, we get no stack frame on the likely path
Nice!
Thanks,
Nick
>
> 000003a8 <interrupt_exit_kernel_prepare>:
> 3a8: 81 43 00 84 lwz r10,132(r3)
> 3ac: 71 4a 00 02 andi. r10,r10,2
> 3b0: 41 82 00 30 beq 3e0 <interrupt_exit_kernel_prepare+0x38>
> 3b4: 80 62 00 70 lwz r3,112(r2)
> 3b8: 74 63 00 01 andis. r3,r3,1
> 3bc: 40 82 00 34 bne 3f0 <interrupt_exit_kernel_prepare+0x48>
> 3c0: 7d 40 00 a6 mfmsr r10
> 3c4: 55 4a 04 5e rlwinm r10,r10,0,17,15
> 3c8: 7d 40 01 24 mtmsr r10
> 3cc: 7d 20 00 a6 mfmsr r9
> 3d0: 55 29 07 fa rlwinm r9,r9,0,31,29
> 3d4: 55 29 04 5e rlwinm r9,r9,0,17,15
> 3d8: 7d 20 01 24 mtmsr r9
> 3dc: 4e 80 00 20 blr
> 3e0: 94 21 ff f0 stwu r1,-16(r1)
> 3e4: 7c 08 02 a6 mflr r0
> 3e8: 90 01 00 14 stw r0,20(r1)
> 3ec: 48 00 00 01 bl 3ec <interrupt_exit_kernel_prepare+0x44>
> 3ec: R_PPC_REL24 unrecoverable_exception
> 3f0: 38 e2 00 70 addi r7,r2,112
> 3f4: 3d 00 00 01 lis r8,1
> 3f8: 7c c0 38 28 lwarx r6,0,r7
> 3fc: 7c c6 40 78 andc r6,r6,r8
> 400: 7c c0 39 2d stwcx. r6,0,r7
> 404: 40 a2 ff f4 bne 3f8 <interrupt_exit_kernel_prepare+0x50>
> 408: 38 60 00 01 li r3,1
> 40c: 4b ff ff b4 b 3c0 <interrupt_exit_kernel_prepare+0x18>
>
> Without the modification:
>
> 000003a8 <interrupt_exit_kernel_prepare>:
> 3a8: 94 21 ff f0 stwu r1,-16(r1)
> 3ac: 93 e1 00 0c stw r31,12(r1)
> 3b0: 81 23 00 84 lwz r9,132(r3)
> 3b4: 71 29 00 02 andi. r9,r9,2
> 3b8: 41 82 00 38 beq 3f0 <interrupt_exit_kernel_prepare+0x48>
> 3bc: 81 22 00 70 lwz r9,112(r2)
> 3c0: 75 23 00 01 andis. r3,r9,1
> 3c4: 40 82 00 4c bne 410 <interrupt_exit_kernel_prepare+0x68>
> 3c8: 7d 20 00 a6 mfmsr r9
> 3cc: 55 29 04 5e rlwinm r9,r9,0,17,15
> 3d0: 7d 20 01 24 mtmsr r9
> 3d4: 7d 20 00 a6 mfmsr r9
> 3d8: 55 29 07 fa rlwinm r9,r9,0,31,29
> 3dc: 55 29 04 5e rlwinm r9,r9,0,17,15
> 3e0: 7d 20 01 24 mtmsr r9
> 3e4: 83 e1 00 0c lwz r31,12(r1)
> 3e8: 38 21 00 10 addi r1,r1,16
> 3ec: 4e 80 00 20 blr
> 3f0: 7c 08 02 a6 mflr r0
> 3f4: 90 01 00 14 stw r0,20(r1)
> 3f8: 48 00 00 01 bl 3f8 <interrupt_exit_kernel_prepare+0x50>
> 3f8: R_PPC_REL24 unrecoverable_exception
> 3fc: 81 22 00 70 lwz r9,112(r2)
> 400: 80 01 00 14 lwz r0,20(r1)
> 404: 75 23 00 01 andis. r3,r9,1
> 408: 7c 08 03 a6 mtlr r0
> 40c: 41 82 ff bc beq 3c8 <interrupt_exit_kernel_prepare+0x20>
> 410: 39 02 00 70 addi r8,r2,112
> 414: 3d 20 00 01 lis r9,1
> 418: 7c e0 40 28 lwarx r7,0,r8
> 41c: 7c e7 48 78 andc r7,r7,r9
> 420: 7c e0 41 2d stwcx. r7,0,r8
> 424: 40 a2 ff f4 bne 418 <interrupt_exit_kernel_prepare+0x70>
> 428: 38 60 00 01 li r3,1
> 42c: 7d 20 00 a6 mfmsr r9
> 430: 55 29 04 5e rlwinm r9,r9,0,17,15
> 434: 7d 20 01 24 mtmsr r9
> 438: 7d 20 00 a6 mfmsr r9
> 43c: 55 29 07 fa rlwinm r9,r9,0,31,29
> 440: 55 29 04 5e rlwinm r9,r9,0,17,15
> 444: 7d 20 01 24 mtmsr r9
> 448: 83 e1 00 0c lwz r31,12(r1)
> 44c: 38 21 00 10 addi r1,r1,16
> 450: 4e 80 00 20 blr
>
^ permalink raw reply
* Re: [PATCH v5 03/10] powerpc/signal64: Move non-inline functions out of setup_sigcontext()
From: Christopher M. Riedl @ 2021-02-10 23:51 UTC (permalink / raw)
To: Daniel Axtens, linuxppc-dev
In-Reply-To: <87a6sbeipz.fsf@dja-thinkpad.axtens.net>
On Wed Feb 10, 2021 at 3:06 PM CST, Daniel Axtens wrote:
> "Christopher M. Riedl" <cmr@codefail.de> writes:
>
> > On Sun Feb 7, 2021 at 10:44 PM CST, Daniel Axtens wrote:
> >> Hi Chris,
> >>
> >> These two paragraphs are a little confusing and they seem slightly
> >> repetitive. But I get the general idea. Two specific comments below:
> >
> > Umm... yeah only one of those was supposed to be sent. I will reword
> > this for the next spin and address the comment below about how it is
> > not entirely clear that the inline functions are being moved out.
> >
> >>
> >> > There are non-inline functions which get called in setup_sigcontext() to
> >> > save register state to the thread struct. Move these functions into a
> >> > separate prepare_setup_sigcontext() function so that
> >> > setup_sigcontext() can be refactored later into an "unsafe" version
> >> > which assumes an open uaccess window. Non-inline functions should be
> >> > avoided when uaccess is open.
> >>
> >> Why do we want to avoid non-inline functions? We came up with:
> >>
> >> - we want KUAP protection for as much of the kernel as possible: each
> >> extra bit of code run with the window open is another piece of attack
> >> surface.
> >>
> >> - non-inline functions default to traceable, which means we could end
> >> up ftracing while uaccess is enabled. That's a pretty big hole in the
> >> defences that KUAP provides.
> >>
> >> I think we've also had problems with the window being opened or closed
> >> unexpectedly by various bits of code? So the less code runs in uaccess
> >> context the less likely that is to occur.
> >
> > That is my understanding as well.
> >
> >>
> >> > The majority of setup_sigcontext() can be refactored to execute in an
> >> > "unsafe" context (uaccess window is opened) except for some non-inline
> >> > functions. Move these out into a separate prepare_setup_sigcontext()
> >> > function which must be called first and before opening up a uaccess
> >> > window. A follow-up commit converts setup_sigcontext() to be "unsafe".
> >>
> >> This was a bit confusing until we realise that you're moving the _calls_
> >> to the non-inline functions out, not the non-inline functions
> >> themselves.
> >>
> >> > Signed-off-by: Christopher M. Riedl <cmr@codefail.de>
> >> > ---
> >> > arch/powerpc/kernel/signal_64.c | 32 +++++++++++++++++++++-----------
> >> > 1 file changed, 21 insertions(+), 11 deletions(-)
> >> >
> >> > diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
> >> > index f9e4a1ac440f..b211a8ea4f6e 100644
> >> > --- a/arch/powerpc/kernel/signal_64.c
> >> > +++ b/arch/powerpc/kernel/signal_64.c
> >> > @@ -79,6 +79,24 @@ static elf_vrreg_t __user *sigcontext_vmx_regs(struct sigcontext __user *sc)
> >> > }
> >> > #endif
> >> >
> >> > +static void prepare_setup_sigcontext(struct task_struct *tsk, int ctx_has_vsx_region)
> >>
> >> ctx_has_vsx_region should probably be a bool? Although setup_sigcontext
> >> also has it as an int so I guess that's arguable, and maybe it's better
> >> to stick with this for constency.
> >
> > I've been told not to introduce unrelated changes in my patches before
> > so chose to keep this as an int for consistency.
>
> Seems reasonable.
>
> >
> >>
> >> > +{
> >> > +#ifdef CONFIG_ALTIVEC
> >> > + /* save altivec registers */
> >> > + if (tsk->thread.used_vr)
> >> > + flush_altivec_to_thread(tsk);
> >> > + if (cpu_has_feature(CPU_FTR_ALTIVEC))
> >> > + tsk->thread.vrsave = mfspr(SPRN_VRSAVE);
> >> > +#endif /* CONFIG_ALTIVEC */
> >> > +
> >> > + flush_fp_to_thread(tsk);
> >> > +
> >> > +#ifdef CONFIG_VSX
> >> > + if (tsk->thread.used_vsr && ctx_has_vsx_region)
> >> > + flush_vsx_to_thread(tsk);
> >> > +#endif /* CONFIG_VSX */
> >>
> >> Alternatively, given that this is the only use of ctx_has_vsx_region,
> >> mpe suggested that perhaps we could drop it entirely and always
> >> flush_vsx if used_vsr. The function is only ever called with either
> >> `current` or wth ctx_has_vsx_region set to 1, so in either case I think
> >> that's safe? I'm not sure if it would have performance implications.
> >
> > I think that could work as long as we can guarantee that the context
> > passed to swapcontext will always be sufficiently sized if used_vsr,
> > which I think *has* to be the case?
>
> I think you're always guaranteed that you'll have a big enough one
> in your kernel thread, which is what you end up writing to, iiuc?
Ah yup you are correct. I confused myself with the comment in
swapcontext about the ctx_size. We call prepare_setup_sigcontext() with
current which will always have space. The ctx_size only matters on the
next call to setup_sigcontext() which ends up potentially copying the
VSX region to userspace (v_regs).
TL;DR - yes, I'll remove the ctx_has_vsx_region argument to
prepare_setup_sigcontext() with the next version. Thanks!
>
> >>
> >> Should we move this and the altivec ifdef to IS_ENABLED(CONFIG_VSX) etc?
> >> I'm not sure if that runs into any problems with things like 'used_vsr'
> >> only being defined if CONFIG_VSX is set, but I thought I'd ask.
> >
> > That's why I didn't use IS_ENABLED(CONFIG_...) here - all of these
> > field (used_vr, vrsave, used_vsr) declarations are guarded by #ifdefs :/
>
> Dang. Oh well.
> >
> >>
> >>
> >> > +}
> >> > +
> >> > /*
> >> > * Set up the sigcontext for the signal frame.
> >> > */
> >> > @@ -97,7 +115,6 @@ static long setup_sigcontext(struct sigcontext __user *sc,
> >> > */
> >> > #ifdef CONFIG_ALTIVEC
> >> > elf_vrreg_t __user *v_regs = sigcontext_vmx_regs(sc);
> >> > - unsigned long vrsave;
> >> > #endif
> >> > struct pt_regs *regs = tsk->thread.regs;
> >> > unsigned long msr = regs->msr;
> >> > @@ -112,7 +129,6 @@ static long setup_sigcontext(struct sigcontext __user *sc,
> >> >
> >> > /* save altivec registers */
> >> > if (tsk->thread.used_vr) {
> >> > - flush_altivec_to_thread(tsk);
> >> > /* Copy 33 vec registers (vr0..31 and vscr) to the stack */
> >> > err |= __copy_to_user(v_regs, &tsk->thread.vr_state,
> >> > 33 * sizeof(vector128));
> >> > @@ -124,17 +140,10 @@ static long setup_sigcontext(struct sigcontext __user *sc,
> >> > /* We always copy to/from vrsave, it's 0 if we don't have or don't
> >> > * use altivec.
> >> > */
> >> > - vrsave = 0;
> >> > - if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
> >> > - vrsave = mfspr(SPRN_VRSAVE);
> >> > - tsk->thread.vrsave = vrsave;
> >> > - }
> >> > -
> >> > - err |= __put_user(vrsave, (u32 __user *)&v_regs[33]);
> >> > + err |= __put_user(tsk->thread.vrsave, (u32 __user *)&v_regs[33]);
> >>
> >> Previously, if !cpu_has_feature(ALTIVEC), v_regs[33] had vrsave stored,
> >> which was set to 0 explicitly. Now we store thread.vrsave instead of the
> >> local vrsave. That should be safe - it is initalised to 0 elsewhere.
> >>
> >> So you don't have to do anything here, this is just letting you know
> >> that we checked it and thought about it.
> >
> > Thanks! I thought about adding a comment/note here as I had to convince
> > myself that thread.vrsave is indeed initialized to 0 before making this
> > change as well. I will mention it in the word-smithed commit message for
> > posterity.
> >
> >>
> >> > #else /* CONFIG_ALTIVEC */
> >> > err |= __put_user(0, &sc->v_regs);
> >> > #endif /* CONFIG_ALTIVEC */
> >> > - flush_fp_to_thread(tsk);
> >> > /* copy fpr regs and fpscr */
> >> > err |= copy_fpr_to_user(&sc->fp_regs, tsk);
> >> >
> >> > @@ -150,7 +159,6 @@ static long setup_sigcontext(struct sigcontext __user *sc,
> >> > * VMX data.
> >> > */
> >> > if (tsk->thread.used_vsr && ctx_has_vsx_region) {
> >> > - flush_vsx_to_thread(tsk);
> >> > v_regs += ELF_NVRREG;
> >> > err |= copy_vsx_to_user(v_regs, tsk);
> >> > /* set MSR_VSX in the MSR value in the frame to
> >> > @@ -655,6 +663,7 @@ SYSCALL_DEFINE3(swapcontext, struct ucontext __user *, old_ctx,
> >> > ctx_has_vsx_region = 1;
> >> >
> >> > if (old_ctx != NULL) {
> >> > + prepare_setup_sigcontext(current, ctx_has_vsx_region);
> >> > if (!access_ok(old_ctx, ctx_size)
> >> > || setup_sigcontext(&old_ctx->uc_mcontext, current, 0, NULL, 0,
> >> > ctx_has_vsx_region)
> >>
> >> I had a think about whether there was a problem with bubbling
> >> prepare_setup_sigcontext over the access_ok() test, but given that
> >> prepare_setup_sigcontext(current ...) doesn't access any of old_ctx, I'm
> >> satisfied that it's OK - no changes needed.
> >
> > Not sure I understand what you mean by 'bubbling over'?
>
>
> Yeah sorry, overly flowery language there. I mean that the accesses that
> prepare_setup_sigcontext does have moved up - like a bubble in fluid -
> from after access_ok to before access_ok.
>
> Kind regards,
> Daniel
> >>
> >>
> >> > @@ -842,6 +851,7 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
> >> > #endif
> >> > {
> >> > err |= __put_user(0, &frame->uc.uc_link);
> >> > + prepare_setup_sigcontext(tsk, 1);
> >>
> >> Why do we call with ctx_has_vsx_region = 1 here? It's not immediately
> >> clear to me why this is correct, but mpe and Mikey seem pretty convinced
> >> that it is.
> >
> > I think it's because we always have a "complete" sigcontext w/ the VSX
> > save area here, unlike in swapcontext where we have to check. Also, the
> > following unsafe_setup_sigcontext() is called with ctx_has_vsx_region=1
> > so assumes that the VSX data was copied by prepare_setup_sigcontext().
> >
> >>
> >> > err |= setup_sigcontext(&frame->uc.uc_mcontext, tsk, ksig->sig,
> >> > NULL, (unsigned long)ksig->ka.sa.sa_handler,
> >> > 1);
> >>
> >>
> >> Finally, it's a bit hard to figure out where to put this, but we spent
> >> some time making sure that the various things you moved into the
> >> prepare_setup_sigcontext() function were called under the same
> >> circumstances as they were before, and there were no concerns there.
> >
> > Thanks for reviewing and double checking my work :)
> >
> >>
> >> Kind regards,
> >> Daniel
^ permalink raw reply
* Re: [PATCH v17 04/10] powerpc: Use common of_kexec_alloc_and_setup_fdt()
From: Thiago Jung Bauermann @ 2021-02-11 1:42 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: mark.rutland, tao.li, zohar, paulus, vincenzo.frascino,
frowand.list, sashal, robh, masahiroy, jmorris, takahiro.akashi,
linux-arm-kernel, catalin.marinas, serge, devicetree,
pasha.tatashin, will, prsriva, hsinyi, allison, christophe.leroy,
mbrugger, balajib, dmitry.kasatkin, linux-kernel, james.morse,
gregkh, joe, linux-integrity, linuxppc-dev
In-Reply-To: <20210209182200.30606-5-nramas@linux.microsoft.com>
Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
> From: Rob Herring <robh@kernel.org>
>
> The code for setting up the /chosen node in the device tree
> and updating the memory reservation for the next kernel has been
> moved to of_kexec_alloc_and_setup_fdt() defined in "drivers/of/kexec.c".
>
> Use the common of_kexec_alloc_and_setup_fdt() to setup the device tree
> and update the memory reservation for kexec for powerpc.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> ---
> arch/powerpc/include/asm/kexec.h | 1 +
> arch/powerpc/kexec/elf_64.c | 29 ++++---
> arch/powerpc/kexec/file_load.c | 132 +-----------------------------
> arch/powerpc/kexec/file_load_64.c | 3 +
> 4 files changed, 25 insertions(+), 140 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
> index dbf09d2f36d0..bdd0ddb9ac4d 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -111,6 +111,7 @@ struct kimage_arch {
> unsigned long elf_headers_mem;
> unsigned long elf_headers_sz;
> void *elf_headers;
> + void *fdt;
>
> #ifdef CONFIG_IMA_KEXEC
> phys_addr_t ima_buffer_addr;
> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
> index d0e459bb2f05..bfabd06f99b1 100644
> --- a/arch/powerpc/kexec/elf_64.c
> +++ b/arch/powerpc/kexec/elf_64.c
> @@ -19,6 +19,7 @@
> #include <linux/kexec.h>
> #include <linux/libfdt.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/of_fdt.h>
> #include <linux/slab.h>
> #include <linux/types.h>
> @@ -29,7 +30,6 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
> unsigned long cmdline_len)
> {
> int ret;
> - unsigned int fdt_size;
> unsigned long kernel_load_addr;
> unsigned long initrd_load_addr = 0, fdt_load_addr;
> void *fdt;
> @@ -102,19 +102,13 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
> pr_debug("Loaded initrd at 0x%lx\n", initrd_load_addr);
> }
>
> - fdt_size = fdt_totalsize(initial_boot_params) * 2;
> - fdt = kmalloc(fdt_size, GFP_KERNEL);
> + fdt = of_kexec_alloc_and_setup_fdt(image, initrd_load_addr,
> + initrd_len, cmdline);
> if (!fdt) {
> pr_err("Not enough memory for the device tree.\n");
This error string can be a bit misleading now, since
of_kexec_alloc_and_setup_fdt() can fail for reasons other than lack of
memory. I suggest changing it to the error string from fdt_open_into()
below:
pr_err("Error setting up the new device tree.\n");
With this change:
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
And also:
Tested-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ 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