On 15/02/17 15:45, Richard Earnshaw (lists) wrote:
On 18/01/17 17:10, Jiong Wang wrote:
NOTE, this approach however requires DWARF change as the original LR
is signed,
the binary needs new libgcc to make sure c++ eh works correctly.
Given this
acceleration already needs the user specify
-mstack-protector-dialect=pauth
which means the target platform largely should have install new
libgcc, otherwise
you can't utilize new pointer authentication features.
gcc/
2016-11-11 Jiong Wang <jiong.w...@arm.com>
* config/aarch64/aarch64-opts.h
(aarch64_stack_protector_type): New
enum.
(aarch64_layout_frame): Swap callees and locals when
-mstack-protector-dialect=pauth specified.
(aarch64_expand_prologue): Use AARCH64_PAUTH_SSP_OR_RA_SIGN
instead
of AARCH64_ENABLE_RETURN_ADDRESS_SIGN.
(aarch64_expand_epilogue): Likewise.
* config/aarch64/aarch64.md (*do_return): Likewise.
(aarch64_override_options): Sanity check for ILP32 and
TARGET_PAUTH.
* config/aarch64/aarch64.h (AARCH64_PAUTH_SSP_OPTION,
AARCH64_PAUTH_SSP,
AARCH64_PAUTH_SSP_OR_RA_SIGN, LINK_SSP_SPEC): New defines.
* config/aarch64/aarch64.opt (-mstack-protector-dialect=): New
option.
* doc/invoke.texi (AArch64 Options): Documents
-mstack-protector-dialect=.
Patch updated
to migrate to TARGET_STACK_PROTECT_RUNTIME_ENABLED_P.
aarch64 cross check OK with the following options enabled on all testcases.
-fstack-protector-all -mstack-protector-pauth
OK for trunk?
gcc/
2017-01-18 Jiong Wang <jiong.w...@arm.com>
* config/aarch64/aarch64-protos.h
(aarch64_pauth_stack_protector_enabled): New declaration.
* config/aarch64/aarch64.c (aarch64_layout_frame): Swap
callee-save area
and locals area when aarch64_pauth_stack_protector_enabled
returns true.
(aarch64_stack_protect_runtime_enabled): New function.
(aarch64_pauth_stack_protector_enabled): New function.
(aarch64_return_address_signing_enabled): Enabled by
aarch64_pauth_stack_protector_enabled.
(aarch64_override_options): Sanity check for
-mstack-protector-pauth.
(TARGET_STACK_PROTECT_RUNTIME_ENABLED_P): Define.
* config/aarch64/aarch64.h (LINK_SSP_SPEC): Likewise.
* config/aarch64/aarch64.opt (-mstack-protector-pauth): New option.
* doc/invoke.texi (AArch64 Options): Documents
-mstack-protector-pauth.
gcc/testsuite/
* gcc.target/aarch64/stack_protector_1.c: New test.
1.patch
diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index
632dd4768d82c340ae4e9b4a93206743756c06e7..a3ad623eef498d00b52d24bf02a5748fad576c3d
100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -383,6 +383,7 @@ void aarch64_init_cumulative_args (CUMULATIVE_ARGS *,
const_tree, rtx,
void aarch64_init_expanders (void);
void aarch64_init_simd_builtins (void);
void aarch64_emit_call_insn (rtx);
+bool aarch64_pauth_stack_protector_enabled (void);
void aarch64_register_pragmas (void);
void aarch64_relayout_simd_types (void);
void aarch64_reset_previous_fndecl (void);
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index
3718ad1b3bf27c6bdb9e74831fd660e617cccbde..dd742d37ab6fc6fb5085e1c6b5d86d5ce1ce5f8a
100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -958,4 +958,11 @@ extern const char *host_detect_local_cpu (int argc, const
char **argv);
extern tree aarch64_fp16_type_node;
extern tree aarch64_fp16_ptr_type_node;
+#ifndef TARGET_LIBC_PROVIDES_SSP
+#define LINK_SSP_SPEC "%{!mstack-protector-pauth:\
+ %{fstack-protector|fstack-protector-all\
+ |fstack-protector-strong|fstack-protector-explicit:\
+ -lssp_nonshared -lssp}}"
+#endif
+
I don't think we want to suppress this. PAUTH pased stack protections
isn't an all-or-nothing solution. What if some object files are built
with traditional -fstack-protector code?
I had done a decription on this in the ping email (changed summary may caused
trouble to email client)
--
Code compiled with "-mstack-protector-pauth" can co-work with code compiled
without "-mstack-protector-pauth". The only problem is when
"-mstack-protector-pauth" is specified, "-lssp/-lssp_nonshared" won't be implied
as the software runtime supports are not required any more. So if the user has
some object files compiled using default stack protector and wants them to be
linked with object files compiled using "-mstack-protector-pauth", if
"-mstack-protector-pauth" appear in the final command line and "gcc" is used as
linker driver, then "-lssp/-lssp_nonshared" needs to be specified explicitly.
--
Generally, after this patch, if there are object files comes from tranditional
-fstack-protector then the user is responsible to specify -lssp/-lssp-nonshared.
My intention to remove ssp library when -fstack-protector-pauth specified was to
make pauth based stack protector also be available on those configurations where
libssp is not enabled or not available.
Does this make sense?
If the library isn't referenced by any of the input objects we won't
pull anything useful in from the library, so leaving it in the link list
should be harmless.
For linux target, I agree.
+ return ((aarch64_ra_sign_scope == AARCH64_FUNCTION_ALL
+ || (aarch64_ra_sign_scope == AARCH64_FUNCTION_NON_LEAF
+ && cfun->machine->frame.reg_offset[LR_REGNUM] >= 0))
+ || aarch64_pauth_stack_protector_enabled ());
}
Do we really want to force signing of ALL leaf functions if using PAUTH
based signing? Surely we only need to check those that might be
vulnerable to buffer overruns.
aarch64_pauth_stack_protector_enabled () is already checking that, it will
return true only if crtl->stack_protect_guard is not NULL. While
crtl->stack_protect_guard will only be created for functions which gcc
middle-end (create_stack_guard) identified to be vulnerable to buffer overruns.
Regards,
Jiong
