linux-kernel - Re: [PATCH] [PATCH v2] AARCH64: Add gcc Shadow Call Stack support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3389ef12-81c7-6aba-6c58-63e34008af0c@linux.alibaba.com>
Date:   Sun, 27 Feb 2022 23:50:57 -0800
From:   Dan Li <ashimida@...ux.alibaba.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     catalin.marinas@....com, will@...nel.org, nathan@...nel.org,
        ndesaulniers@...gle.com, masahiroy@...nel.org, tglx@...utronix.de,
        akpm@...ux-foundation.org, mark.rutland@....com,
        samitolvanen@...gle.com, npiggin@...il.com, linux@...ck-us.net,
        mhiramat@...nel.org, ojeda@...nel.org, luc.vanoostenryck@...il.com,
        elver@...gle.com, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, llvm@...ts.linux.dev,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH] [PATCH v2] AARCH64: Add gcc Shadow Call Stack support



On 2/25/22 12:58, Kees Cook wrote:
> On Thu, Feb 24, 2022 at 07:24:10PM -0800, Dan Li wrote:
>> Signed-off-by: Dan Li <ashimida@...ux.alibaba.com>
> 
> Thanks for the tweaks!
> 
>> ---
>> FYI:
>> This function can be used to test if the shadow call stack works:
>> //noinline void __noscs scs_test(void)
>> noinline void scs_test(void)
>> {
>>      unsigned long * lr = (unsigned long *)__builtin_frame_address(0) + 1;
>>
>>      asm volatile("str xzr, [%0]\n\t": : "r"(lr) : "x30");
>> }
> 
> Not a big deal, but just FYI, there's a lot of whitespace trailing the
> "}" above...
> 

Ah, sorry for the mistake.
>>
>> If SCS protection is enabled, this function will return normally.
>> If the function has __noscs attribute (scs disabled), it will crash due to 0
>> address access.
> 
> It would be cool to turn this into an LKDTM test... (see things like the
> CFI_FORWARD_PROTO test). I imagine this should be CFI_BACKWARD_SHADOW or
> something...
> 

OK, I'll add it in the next version.

> Also, I assume you're using real hardware to test this? It'd be nice to
> see if qemu can be convinced to run with the needed features. Whenever
> I've tried this it becomes impossibly slow. :)
> 

I also use qemu to test the patch (qemu 6.1.0 with command "-cpu max"),
and can feel the performance drop.

Maybe because my test environment only has simple busybox and ltp,
the feeling of a slow system running is not that strong for me :)

For comparison, I simply tested the difference in kernel boot time
in my test environment:
//run qemu with "-cpu cortex-a57",
[    1.254481] Run /linuxrc as init process
//run qemu with "-cpu max"
[    3.566091] Run /linuxrc as init process

>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index ccbbd31b3aae..deff5b308470 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/include/linux/compiler-gcc.h
>> @@ -97,6 +97,10 @@
>>   #define KASAN_ABI_VERSION 4
>>   #endif
>>   
>> +#ifdef CONFIG_SHADOW_CALL_STACK
>> +#define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
>> +#endif
> 
> I initially wondered if we need a separate __no_sanitize(STUFF) patch to
> make the compiler-clang.h macros easier, but I see there are places
> where we do multiple ("address", "hwaddress") and have specialized
> macros, so I think this is fine. And since GCC doesn't support
> "__has_feature", I think this is the correct location for this.
> 

As in:
https://lore.kernel.org/all/26a0a816-bc3e-2ac0-d773-0819d9f225af@linux.alibaba.com/

I think maybe we could use "#ifdef CONFIG_SHADOW_CALL_STACK"
instead of "#if __has_attribute(__no_sanitize_address__)" here,
then move it to `compiler_types.h`.

 From my current test results, __noscs seems to work fine in
clang compilation.

Thanks,
Dan.