[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 22 May 2017 20:04:40 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Daniel Axtens <dja@...ens.net>, kernel-hardening@...ts.openwall.com, linuxppc-dev@...ts.ozlabs.org
Cc: Daniel Micay <danielmicay@...il.com>, Kees Cook <keescook@...omium.org>, Daniel Axtens <dja@...ens.net>
Subject: Re: [PATCH 1/2] powerpc: Don't fortify prom_init
Daniel Axtens <dja@...ens.net> writes:
> prom_init is a bit special; in theory it should be able to be
> linked separately to the kernel. To keep this from getting too
> complex, the symbols that prom_init.c uses are checked.
>
> Fortification adds symbols, and it gets quite messy as it includes
> things like panic(). So just don't fortify prom_init.c for now.
Calling panic() at that point is unlikely to work well.
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Daniel Micay <danielmicay@...il.com>
> Signed-off-by: Daniel Axtens <dja@...ens.net>
>
> ---
>
> This will need to go in before the main fortify support, but it
> doesn't make any sense in the absence of fortify. I think it would
> make most sense for Kees to queue this up with the main fortify patch,
> with an Ack from mpe?
Yeah that's fine by me.
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index dd8a04f3053a..613f79f03877 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -15,6 +15,9 @@
>
> #undef DEBUG_PROM
>
> +/* we cannot use FORTIFY as it brings in new symbols */
> +#define __NO_FORTIFY
> +
> #include <stdarg.h>
> #include <linux/kernel.h>
> #include <linux/string.h>
Acked-by: Michael Ellerman <mpe@...erman.id.au>
cheers
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
