Hi All,
Embarrassingly, due to personal reasons, I may not be able to complete
the series of patches on the forward side of GCC CFI for the time being.
Please forgive me for not realizing that I should have sent this help
email a long time ago :(
This topic has been delayed for a long time, and
Hi Kees,
Sincerely sorry, I just saw this email.
Embarrassingly, due to another job change, my plan was postponed again :(.
I may not be able to attend this year's GCC meeting. Is there any other
way to let this get some traction in GCC? I really hope someone can help
with this topic.
BTW, I'm s
On 03/27, Sami Tolvanen wrote:
> On Mon, Mar 27, 2023 at 2:30 AM Peter Zijlstra wrote:
> >
> > On Sat, Mar 25, 2023 at 01:54:16AM -0700, Dan Li wrote:
> >
> > > In the compiler part[4], most of the content is the same as Sami's
> > > implementation[3], except for some minor differences, mainly inc
On 03/27, Peter Zijlstra wrote:
> On Sat, Mar 25, 2023 at 01:54:16AM -0700, Dan Li wrote:
>
> > In the compiler part[4], most of the content is the same as Sami's
> > implementation[3], except for some minor differences, mainly including:
> >
> > 1. The function typeid is calculated differently a
This series of patches is mainly used to support the control flow
integrity protection of the linux kernel [1], which is similar to
-fsanitize=kcfi in clang 16.0 [2,3].
Any suggestion please let me know :).
Thanks, Dan.
[1]
https://lore.kernel.org/all/20220908215504.3686827-1-samitolva...@googl
The KCFI sanitizer enabled with -fsanitize=kcfi implements a forward
edge control flow integrity scheme for indirect calls, similar to
-fsanitize=kcfi [1] in llvm.
At compile time, it appends a uniform type identifier before the
first instruction of each function and inserts check code before
each
Based on Sami's patch[1], this patch makes the corresponding kernel
configuration of CFI available when compiling the kernel with the gcc[2].
The code after enabling cfi (with -fsanitize=kcfi,
-fpatchable-function-entry=3,1) is as follows:
int (*p)(void);
int func (int)
{
p();
}
__kcfi_f
In the AArch64 platform, typeid can be directly inserted in front
of the function header (offset is patch_area_entry + 4), it should
be assumed that patch_area_entry is the same for all functions.
For all functions that will not be called indirectly, insert the
reserved RESERVED_CFI_TYPEID (0x0) a
32-bit sanitize_code can no longer accommodate new options,
extending it to 64-bit.
Signed-off-by: Dan Li
gcc/ChangeLog:
PR c/102768
* asan.h (sanitize_flags_p): Promote to uint64_t.
* common.opt: Likewise.
* dwarf2asm.cc (dw2_output_indirect_constant_1): Likewis
On 02/08, Peter Collingbourne wrote:
> On Sun, Dec 18, 2022 at 10:06 PM Dan Li wrote:
> >
> > This series of patches is mainly used to support the control flow
> > integrity protection of the linux kernel [1], which is similar to
> > -fsanitize=kcfi in clang 16.0 [2,3].
> >
> > I hope that this fe
On 02/09, Hongtao Liu wrote:
> On Mon, Dec 19, 2022 at 3:59 PM Dan Li via Gcc-patches
> wrote:
> >
> > This series of patches is mainly used to support the control flow
> > integrity protection of the linux kernel [1], which is similar to
> > -fsanitize=kcfi in cl
The CFI sanitizer enabled with -fsanitize=cfi implements a forward
edge control flow integrity scheme for indirect calls, roughly
similar to -fsanitize=kcfi [1] in llvm.
At compile time, it appends a uniform type identifier before the
first instruction of each function and inserts check code befor
32-bit sanitize_code can no longer accommodate new options,
extending it to 64-bit.
Signed-off-by: Dan Li
gcc/ChangeLog:
PR c/102768
* asan.h (sanitize_flags_p): Promote to uint64_t.
* common.opt: Likewise.
* dwarf2asm.cc (dw2_output_indirect_constant_1): Likewis
In the AArch64 platform, typeid can be directly inserted in front
of the function header (offset is -4).
For all functions that will not be called indirectly, insert the
reserved RESERVED_CFI_TYPEID (0x0) as typeid in front of them. If
not, the attacker may use the instruction/data before the func
This series of patches is mainly used to support the control flow
integrity protection of the linux kernel [1], which is similar to
-fsanitize=kcfi in clang 16.0 [2,3].
I hope that this feature will also support user-mode CFI in the
future (at least for developers who can recompile the runtime),
s
On 4/12/22 06:05, Richard Sandiford wrote:
Dan Li writes:
Gentile ping for this :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html
Sorry, I should have realised this at the time, but I don't think
we can do this after all. The ABI requires us to set up
Gentile ping for this :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html
R30_REGNUM could also be used as a component in shrink-wrapping
separate, this patch enables it in aarch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_get_separate_comp
Gentile ping for this :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html
R30_REGNUM could also be used as a component in shrink-wrapping
separate, this patch enables it in aarch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_get_separate_comp
Gentile ping for this :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html
R30_REGNUM could also be used as a component in shrink-wrapping
separate, this patch enables it in aarch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_get_separate_comp
On 2/11/22 07:35, Richard Sandiford wrote:
Dan Li writes:
On 2/11/22 01:53, Richard Sandiford wrote:
Dan Li writes:
On 2/10/22 01:55, Richard Sandiford wrote:
void f();
int g(int x) {
if (x == 0) {
__asm__ ("":::"x19", "x20");
return 1;
}
f();
R30_REGNUM could also be used as a component in shrink-wrapping
separate, this patch enables it in aarch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_get_separate_components):
Remove bitmap clear of R30_REGNUM.
(aarch64_components_for_bb): Support R30_REGNUM as a
On 2/15/22 10:02, Richard Sandiford wrote:
Dan Li writes:
Shadow Call Stack can be used to protect the return address of a
Looks good, thanks. However, when I bootstrap it on
aarch64-linux-gnu I get:
.../gcc/ubsan.cc: In function ‘bool
ubsan_expand_null_ifn(gimple_stmt_iterator*)’:
.../
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds basic
support for SCS from the compiler
On 2/15/22 10:02, Richard Sandiford wrote:
Dan Li writes:
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
Looks good, thanks. However, when I bootstrap it on
aarch64-linux-gnu I get:
.../gcc/ubsan.cc: In fu
On 2/11/22 07:35, Richard Sandiford wrote:
Dan Li writes:
On 2/11/22 01:53, Richard Sandiford wrote:
Dan Li writes:
On 2/10/22 01:55, Richard Sandiford wrote:
And I think maybe we could handle this through three patches:
1.Keep current patch (a V5) unchanged for scs.
2.Add shrink-warpp
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds basic
support for SCS from the compiler
On 2/11/22 07:35, Richard Sandiford wrote:
Dan Li writes:
On 2/11/22 01:53, Richard Sandiford wrote:
Dan Li writes:
On 2/10/22 01:55, Richard Sandiford wrote:
And I think maybe we could handle this through three patches:
1.Keep current patch (a V5) unchanged for scs.
2.Add shrink-warpp
On 2/11/22 01:53, Richard Sandiford wrote:
Dan Li writes:
On 2/10/22 01:55, Richard Sandiford wrote:
But treating scs push and scs pop as part of the register save and
restore sequences would have one advantage: it would allow the
scs push and scs pop to be shrink-wrapped.
Sorry for my
On 2/10/22 01:55, Richard Sandiford wrote:
There might be a little difference:
- Using push candidates means that a register to be ignored in pop
candidates will not be emitted again during the "restore" (pop_candidates
should always be a subset of push_candidates, since popping a register
w
On 2/9/22 08:08, Richard Sandiford wrote:
Dan Li writes:
+
+ /* When shadow call stack is enabled, the scs_pop in the epilogue will
+ restore x30, and we don't need to pop x30 again in the traditional
+ way. Pop candidates record the registers that need to be popped
+ eventuall
There is the following code in aarch64_layout_frame:
else if (crtl->outgoing_args_size.is_constant (&const_outgoing_args_size)
&& frame.saved_regs_size.is_constant (&const_saved_regs_size)
&& const_outgoing_args_size + const_saved_regs_size < 512
&& (!saves_below_hard_f
Hi, Richard,
I have sent out my v4[1], please let me know if i got something wrong :).
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589921.html
Thanks,
Dan.
On 1/31/22 09:00, Richard Sandiford wrote:
Dan Li writes:
Shadow Call Stack can be used to protect the return address o
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds basic
support for SCS from the compiler
On 1/31/22 09:00, Richard Sandiford wrote:
Dan Li writes:
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
/* This file should be included last. */
#include "target-def.h"
@@ -7478,10 +7479,31 @@ aarch6
On 1/31/22 08:26, Richard Sandiford wrote:
Thanks for the discussion and sorry for the slow reply, was out most of
last week.
Dan Li writes:
Thanks, Ard,
On 1/26/22 00:10, Ard Biesheuvel wrote:
On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
Hi, all,
Sorry for bothering.
I'm trying to co
Hi, Richard,
I have sent out my v3[1], and (probably) fixed the previous issues,
please let me know if i got something wrong :)
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589471.html
Thanks,
Dan.
On 1/25/22 02:19, Richard Sandiford wrote:
Dan Li writes:
+
if (flag_stack
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds basic
support for SCS from the compiler
On 1/26/22 03:09, Ard Biesheuvel wrote:
On Wed, 26 Jan 2022 at 11:40, Dan Li wrote:
Thanks, Ard,
On 1/26/22 00:10, Ard Biesheuvel wrote:
On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
Hi, all,
Sorry for bothering.
I'm trying to commit aarch64 scs code to the gcc and there is an issue
th
Thanks, Ard,
On 1/26/22 00:10, Ard Biesheuvel wrote:
On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
Hi, all,
Sorry for bothering.
I'm trying to commit aarch64 scs code to the gcc and there is an issue
that I'm not sure about, could someone give me some suggestions?
(To avoid noise, I did't cc
Hi, all,
Sorry for bothering.
I'm trying to commit aarch64 scs code to the gcc and there is an issue
that I'm not sure about, could someone give me some suggestions?
(To avoid noise, I did't cc PING^3 [1] to the kernel mail list :) )
When clang enables scs, the following instructions are usuall
On 1/25/22 02:19, Richard Sandiford wrote:
Dan Li writes:
+
if (flag_stack_usage_info)
current_function_static_stack_size = constant_lower_bound (frame_size);
@@ -9066,6 +9089,10 @@ aarch64_expand_epilogue (bool for_sibcall)
RTX_FRAME_RELATED_P (insn) = 1;
On 1/20/22 04:02, Richard Sandiford wrote:
Thanks for the patch and sorry for the (very) slow review.
Thanks for the review, Richard :).
+/* Handle a "no_sanitize_shadow_call_stack" attribute; arguments as in
+ struct attribute_spec.handler. */
+static tree
+handle_no_sanitize_shadow_ca
Gentile ping for this again.
Could someone please give me a quick reply first? :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586204.html
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
Gentile ping for this again :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586204.html
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler
Gentile ping for this :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586204.html
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, othe
On 12/6/21 10:41 AM, Dan Li wrote:
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds basic
support for SCS from the compiler
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds basic
support for SCS from the compiler
On 11/23/21 6:51 PM, Szabolcs Nagy wrote:
The 11/23/2021 16:32, Dan Li wrote:
On 11/3/21 8:00 PM, Szabolcs Nagy wrote:
i assume exception handling info has to change for scs to
work (to pop the shadow stack when transferring control),
so either scs must require -fno-exceptions or the eh info
n Li wrote:
On 11/2/21 9:04 PM, Szabolcs Nagy wrote:
The 11/02/2021 00:06, Dan Li via Gcc-patches wrote:
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other suppo
On 11/2/21 9:04 PM, Szabolcs Nagy wrote:
The 11/02/2021 00:06, Dan Li via Gcc-patches wrote:
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as described in [2]). This patch only adds basic
support for SCS from the compiler
During the generation of the epilogue of aarch64(aarch64_expand_epilogue),
the value of crtl->calls_eh_return does not need to be checked again.
This value has been checked during aarch64_return_address_signing_enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_expand_epilogue):
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_expand_epilogue):
* config/aarch64/aarch64.md:
Signed-off-by: Dan Li
---
gcc/config/aarch64/aarch64.c | 6 +-
gcc/config/aarch64/aarch64.md | 3 +--
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/gcc/config/
54 matches
Mail list logo
