Re: [PATCH 09/14] arm64: kexec_file: add sha256 digest check in purgatory

[AKASHI Takahiro]

On Thu, Aug 24, 2017 at 06:04:40PM +0100, Mark Rutland wrote:
> On Thu, Aug 24, 2017 at 05:18:06PM +0900, AKASHI Takahiro wrote:
> > Most of sha256 code is based on crypto/sha256-glue.c, particularly using
> > non-neon version.
> > 
> > Please note that we won't be able to re-use lib/mem*.S for purgatory
> > because unaligned memory access is not allowed in purgatory where mmu
> > is turned off.
> > 
> > Since purgatory is not linked with the other part of kernel, care must be
> > taken of selecting an appropriate set of compiler options in order to
> > prevent undefined symbol references from being generated.
> 
> What is the point in performing this check in the purgatory code, when
> this will presumably have been checked when the image is loaded?

Well, this is what x86 does :)
On powerpc, meanwhile, they don't have this check.

Maybe to avoid booting corrupted kernel after loading?
(loaded data are now protected by making them unmapped, though.)

> [...]
> 
> > diff --git a/arch/arm64/purgatory/entry.S b/arch/arm64/purgatory/entry.S
> > index bc4e6b3bf8a1..74d028b838bd 100644
> > --- a/arch/arm64/purgatory/entry.S
> > +++ b/arch/arm64/purgatory/entry.S
> > @@ -6,6 +6,11 @@
> >  .text
> >  
> >  ENTRY(purgatory_start)
> > +	adr	x19, .Lstack
> > +	mov	sp, x19
> > +
> > +	bl	purgatory
> > +
> >  	/* Start new image. */
> >  	ldr	x17, arm64_kernel_entry
> >  	ldr	x0, arm64_dtb_addr
> > @@ -15,6 +20,14 @@ ENTRY(purgatory_start)
> >  	br	x17
> >  END(purgatory_start)
> >  
> > +.ltorg
> > +
> > +.align 4
> > +	.rept	256
> > +	.quad	0
> > +	.endr
> > +.Lstack:
> > +
> >  .data
> 
> Why is the stack in .text?

to call verify_sha256_digest() from asm

> Does this need to be zeroed?

No :)

> If it does, why not something like:
> 
> 	.fill	PURGATORY_STACK_SIZE 1, 0
> 
> >  
> >  .align 3
> > diff --git a/arch/arm64/purgatory/purgatory.c b/arch/arm64/purgatory/purgatory.c
> > new file mode 100644
> > index 000000000000..7fcbefa786bc
> > --- /dev/null
> > +++ b/arch/arm64/purgatory/purgatory.c
> > @@ -0,0 +1,20 @@
> > +/*
> > + * purgatory: Runs between two kernels
> > + *
> > + * Copyright (c) 2017 Linaro Limited
> > + * Author: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
> > + */
> > +
> > +#include "sha256.h"
> > +
> > +void purgatory(void)
> > +{
> > +	int ret;
> > +
> > +	ret = verify_sha256_digest();
> > +	if (ret) {
> > +		/* loop forever */
> > +		for (;;)
> > +			;
> > +	}
> > +}
> 
> Surely we can do something slightly better than a busy loop? e.g.
> something like the __no_granule_support loop in head.s?

Okey.

> > diff --git a/arch/arm64/purgatory/sha256-core.S b/arch/arm64/purgatory/sha256-core.S
> > new file mode 100644
> > index 000000000000..24f5ce25b61e
> > --- /dev/null
> > +++ b/arch/arm64/purgatory/sha256-core.S
> > @@ -0,0 +1 @@
> > +#include "../crypto/sha256-core.S_shipped"
> > diff --git a/arch/arm64/purgatory/sha256.c b/arch/arm64/purgatory/sha256.c
> > new file mode 100644
> > index 000000000000..5d20d81767e3
> > --- /dev/null
> > +++ b/arch/arm64/purgatory/sha256.c
> > @@ -0,0 +1,79 @@
> > +#include <linux/kexec.h>
> > +#include <linux/purgatory.h>
> > +#include <linux/types.h>
> > +
> > +/*
> > + * Under KASAN, those are defined as un-instrumented version, __memxxx()
> > + */
> > +#undef memcmp
> > +#undef memcpy
> > +#undef memset
> 
> This doesn't look like the right place for this undeffery; it looks
> rather fragile.

Yeah, I agree, but if not there, __memxxx() are used.

> > diff --git a/arch/arm64/purgatory/string.c b/arch/arm64/purgatory/string.c
> > new file mode 100644
> > index 000000000000..33233a210a65
> > --- /dev/null
> > +++ b/arch/arm64/purgatory/string.c
> > @@ -0,0 +1,32 @@
> > +#include <linux/types.h>
> > +
> > +void *memcpy(void *dst, const void *src, size_t len)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < len; i++)
> > +		((u8 *)dst)[i] = ((u8 *)src)[i];
> > +
> > +	return NULL;
> > +}
> > +
> > +void *memset(void *dst, int c, size_t len)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < len; i++)
> > +		((u8 *)dst)[i] = (u8)c;
> > +
> > +	return NULL;
> > +}
> > +
> > +int memcmp(const void *src, const void *dst, size_t len)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < len; i++)
> > +		if (*(char *)src != *(char *)dst)
> > +			return 1;
> > +
> > +	return 0;
> > +}
> 
> How is the compiler prevented from "optimising" these into calls to
> themselves?

I don't get what you mean by "calls to themselves."

Thanks,
-Takahiro AKASHI

> I suspect these will need to be written in asm.
> 
> Thanks,
> Mark.