[PATCH v3] ARM: fix atags_to_fdt with stack-protector-strong

Kees Cook keescook at chromium.org
Thu Jan 7 11:16:13 PST 2016


On Thu, Jan 7, 2016 at 11:11 AM, Geert Uytterhoeven
<geert at linux-m68k.org> wrote:
> Hi Kees,
>
> On Thu, Jan 7, 2016 at 7:40 PM, Kees Cook <keescook at chromium.org> wrote:
>>> Also, I suspect that all of the decompressor should be built with
>>> -fno-stack-protector as we don't have sufficient environment here.
>>> Maybe it should be placed in the global CFLAGS for the decompressor?
>>
>> I prefer keeping it disabled in as narrow a range as possible. If
>> other code gains a level of complexity that it triggers the stack
>> protector code insertion, I think that's worth examining when it
>> happens. If this ever becomes an actual burden, then yeah, let's do it
>> for the whole decompressor, but I think it'd be best to revisit it if
>> it happens again.
>
> What's the failure mode if the stack protector code insertion is triggered?

AIUI, this code shouldn't even link if the ssp code gets inserted
since it can't resolve __stack_chk_fail.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security



More information about the linux-arm-kernel mailing list