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
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
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
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]
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
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();
}
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)
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):
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
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
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):
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
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),
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
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
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
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
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
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
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
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
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
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
+
There is the following code in aarch64_layout_frame:
else if (crtl->outgoing_args_size.is_constant (_outgoing_args_size)
&& frame.saved_regs_size.is_constant (_saved_regs_size)
&& const_outgoing_args_size + const_saved_regs_size < 512
&& (!saves_below_hard_fp_p ||
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
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 @@
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
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
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
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
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
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
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,
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
:
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
is also
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
54 matches
Mail list logo
