Re: [PATCH v4 1/2] powerpc/32: add stack protector support

[Michael Ellerman <mpe@ellerman.id.au>]

Christophe LEROY <christophe.leroy@c-s.fr> writes:
> Le 27/09/2018 à 09:45, Segher Boessenkool a écrit :
>> On Thu, Sep 27, 2018 at 08:20:00AM +0200, Christophe LEROY wrote:
...
>> 
>>> However this is the canary for initial startup only. Only idle() still
>>> uses this canary once the system is running. A new canary is set for any
>>> new forked task.
>> 
>> Ah, that makes things a lot better!  Do those new tasks get a canary
>> from something with sufficient entropy though?
>
> For the kernel threads that are started early, probably not. For the 
> ones started a bit later, and for user processes, I believe they have 
> better entropy. Anyway, all this is handled by the kernel core and is 
> out of control of individual arches, as its done in kernel/fork.c in 
> function dup_task_struct(). However this function is declared as
> static __latent_entropy struct task_struct *copy_process(). This 
> __latent_entropy attibute must help in a way.
>
>> 
>>> Maybe should the idle canary be updated later once there is more entropy
>> 
>> That is tricky to do, but sure, if you can, that should help.
>> 
>>> ? Today there is a new call to boot_init_stack_canary() in
>>> cpu_startup_entry(), but it is enclosed inside #ifdef CONFIG_X86.
>> 
>> It needs to know the details of how ssp works on each platform.
>
> Well, that could be for another patch in the future. That's probably 
> feasible on x86 and PPC because they both use TLS guard, but not for 
> other arches where the guard is global at the moment. So we'll have to 
> do it carefully.
>
> I agree with you that we may not for the time being get all the expected 
> security against hackers out of it due to that little entropy, but my 
> main concern at the time being is to deter developper's bugs clobbering 
> the stack, and for that any non trivial canary should make it, shouldn't 
> it ?

Yes.

The problem of low entropy at boot on systems without a good hardware
source is sort of unsolvable.

As you say it's up to the core kernel/random code, we shouldn't be
trying to do anything tricky in the arch code.

You don't want your system to take 3 hours to boot because it's waiting
for entropy for the stack canary.

If we can update the canary later once the entropy pool is setup that
would be ideal.

cheers