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

From: Michael Ellerman
Date: Fri Sep 28 2018 - 08:56:12 EST


Christophe LEROY <christophe.leroy@xxxxxx> 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