lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200720153400.GC1481119@kroah.com>
Date:   Mon, 20 Jul 2020 17:34:00 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Prakhar Srivastava <prsriva@...ux.microsoft.com>
Cc:     linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, catalin.marinas@....com,
        will@...nel.org, mpe@...erman.id.au, benh@...nel.crashing.org,
        paulus@...ba.org, robh+dt@...nel.org, frowand.list@...il.com,
        zohar@...ux.ibm.com, dmitry.kasatkin@...il.com, jmorris@...ei.org,
        serge@...lyn.com, pasha.tatashin@...een.com, allison@...utok.net,
        kstewart@...uxfoundation.org, takahiro.akashi@...aro.org,
        tglx@...utronix.de, vincenzo.frascino@....com,
        mark.rutland@....com, masahiroy@...nel.org, james.morse@....com,
        bhsharma@...hat.com, mbrugger@...e.com, hsinyi@...omium.org,
        tao.li@...o.com, christophe.leroy@....fr,
        nramas@...ux.microsoft.com, tusharsu@...ux.microsoft.com,
        balajib@...ux.microsoft.com, bauerman@...ux.ibm.com,
        robh@...nel.org
Subject: Re: [PATCH V3 6/6] Add the property used for carrying forward the
 IMA measurement logs and update the code to use the defined property string.

On Mon, Jul 20, 2020 at 08:23:42AM -0700, Prakhar Srivastava wrote:
> Signed-off-by: Prakhar Srivastava <prsriva@...ux.microsoft.com>

Again, subject line, no changelog :(

> ---
>  arch/arm64/kernel/machine_kexec_file.c | 19 ++++++++++---------
>  arch/powerpc/kexec/ima.c               |  8 +++++---
>  2 files changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 066670c43626..59058901e641 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -24,14 +24,15 @@
>  #include <asm/byteorder.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
> +#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 FDT_PROP_IMA_KEXEC_BUFFER	"linux,ima-kexec-buffer"
> +#define RNG_SEED_SIZE			128

Why did you reformat all of these?

>  
>  const struct kexec_file_ops * const kexec_file_loaders[] = {
>  	&kexec_image_ops,
> @@ -157,7 +158,7 @@ static int setup_dtb(struct kimage *image,
>  	if (image->arch.ima_buffer_size > 0) {
>  
>  		ret = fdt_appendprop_addrrange(dtb, 0, off,
> -				"linux,ima-kexec-buffer",
> +				FDT_PROP_IMA_KEXEC_BUFFER,
>  				image->arch.ima_buffer_addr,
>  				image->arch.ima_buffer_size);
>  		if (ret)
> diff --git a/arch/powerpc/kexec/ima.c b/arch/powerpc/kexec/ima.c
> index a9e4e9f04273..7d6c43b2eacb 100644
> --- a/arch/powerpc/kexec/ima.c
> +++ b/arch/powerpc/kexec/ima.c
> @@ -12,6 +12,8 @@
>  #include <linux/memblock.h>
>  #include <linux/libfdt.h>
>  
> +#define FDT_PROP_IMA_KEXEC_BUFFER	"linux,ima-kexec-buffer"
> +

Why are you mixing arm64 and powerpc patches together that do not do the
same thing???

Shouldn't there be a common place for these strings and not spread out
all over the kernel in random places?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ