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

Michael Ellerman mpe at ellerman.id.au
Fri Sep 28 22:56:07 AEST 2018


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


More information about the Linuxppc-dev mailing list