Re: Stack instrumentation for kernel.
I can't verify it at the moment. But it looks good to me. Please send it to gcc mailing list for review. On Fri, Jul 11, 2014 at 3:52 PM, Yuri Gribov wrote: > Dmitry, > >> Yes, -fsanitize=kernel-address is highly desirable asap. Because >> current scheme is incompatible with inline instrumentation for kernel. >> So we need to start telling people to use -fsanitize=kernel-address as >> early as possible. > > Could you check the attached patch which implements > -fsanitize=kernel-address on top of userspace Asan? It worked for us > here. I'm going to send it for GCC upstream review if it works for > you. > > -Y > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
Dmitry,
> Yes, -fsanitize=kernel-address is highly desirable asap. Because
> current scheme is incompatible with inline instrumentation for kernel.
> So we need to start telling people to use -fsanitize=kernel-address as
> early as possible.
Could you check the attached patch which implements
-fsanitize=kernel-address on top of userspace Asan? It worked for us
here. I'm going to send it for GCC upstream review if it works for
you.
-Y
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a83f6c6..70f9c2b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5376,6 +5376,11 @@ more details. The run-time behavior can be influenced
using the
@url{https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags} for
a list of supported options.
+@item -fsanitize=kernel-address
+@opindex fsanitize=kernel-address
+Enable AddressSanitizer for Linux kernel.
+See
@uref{http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel}
for more details.
+
@item -fsanitize=thread
@opindex fsanitize=thread
Enable ThreadSanitizer, a fast data race detector.
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 2849455..04038f6 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -231,6 +231,7 @@ enum sanitize_code {
SANITIZE_FLOAT_DIVIDE = 1 << 12,
SANITIZE_FLOAT_CAST = 1 << 13,
SANITIZE_BOUNDS = 1 << 14,
+ SANITIZE_KERNEL_ADDRESS = 1 << 15,
SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
| SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
| SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
diff --git a/gcc/opts.c b/gcc/opts.c
index 419a074..42fef36 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1475,6 +1475,7 @@ common_handle_option (struct gcc_options *opts,
{ "float-cast-overflow", SANITIZE_FLOAT_CAST,
sizeof "float-cast-overflow" - 1 },
{ "bounds", SANITIZE_BOUNDS, sizeof "bounds" - 1 },
+ { "kernel-address", SANITIZE_KERNEL_ADDRESS, sizeof
"kernel-address" - 1 },
{ NULL, 0, 0 }
};
const char *comma;
@@ -1520,6 +1521,25 @@ common_handle_option (struct gcc_options *opts,
the null pointer checks. */
if (flag_sanitize & SANITIZE_NULL)
opts->x_flag_delete_null_pointer_checks = 0;
+
+ /* Kernel ASan implies normal ASan but does not yet support
+ all features. */
+ if (flag_sanitize & SANITIZE_KERNEL_ADDRESS)
+ {
+ flag_sanitize |= SANITIZE_ADDRESS;
+ maybe_set_param_value
(PARAM_ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD, 0,
+ opts->x_param_values,
+ opts_set->x_param_values);
+ maybe_set_param_value (PARAM_ASAN_GLOBALS, 0,
+ opts->x_param_values,
+ opts_set->x_param_values);
+ maybe_set_param_value (PARAM_ASAN_STACK, 0,
+ opts->x_param_values,
+ opts_set->x_param_values);
+ maybe_set_param_value (PARAM_ASAN_USE_AFTER_RETURN, 0,
+ opts->x_param_values,
+ opts_set->x_param_values);
+ }
break;
}
Re: Stack instrumentation for kernel.
On Tue, Jul 8, 2014 at 5:16 PM, Alexey Preobrazhensky wrote:
>
>
> On Friday, June 20, 2014 6:26:37 PM UTC+4, Yuri Gribov wrote:
>>
>> On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin
>> wrote:
>> > --param asan-memintrin=0 --param asan-fixed-shadow-offset=0
>>
>> This wasn't yet upstreamed.
>
>
> Can you share remaining patches with us?
Sure, attached. The patch is somewhat ugly: asan-fixed-shadow-offset
is only supported for stack prologues/epilogues (memory accesses still
use constant shadow offset) because I only needed to make it work for
Kasan. I can further improve this patch (and probably upstream it) if
people find it useful.
-Y
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
commit 220af201fe980065f5ee6f74a46380b93744c68f
Author: Yury Gribov
Date: Tue Jun 3 12:11:15 2014 +0400
2014-05-27 Yury Gribov
gcc/ChangeLog:
* asan.c (asan_emit_stack_protection): Support non-fixed shadow
offset.
* params.def (PARAM_ASAN_FIXED_SHADOW_OFFSET): New parameter.
* params.h: Likewise.
libsanitizer/ChangeLog:
* asan/asan_rtl.cc (__asan_get_shadow_ptr): New function.
diff --git a/gcc/asan.c b/gcc/asan.c
index 667a662..0b897d9 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -952,6 +952,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
HOST_WIDE_INT *offsets, tree *decls, int length)
{
rtx shadow_base, shadow_mem, ret, mem, orig_base, lab;
+ rtx shadow_start, shadow_start_lab = NULL_RTX, shadow_start_lab2 = NULL_RTX;
char buf[30];
unsigned char shadow_bytes[4];
HOST_WIDE_INT base_offset = offsets[length - 1];
@@ -1047,7 +1048,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
use_after_return_class);
ret = init_one_libfunc (buf);
rtx addr = convert_memory_address (ptr_mode, base);
- ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode, 2,
+ ret = emit_library_call_value (ret, NULL_RTX, LCT_PURE, ptr_mode, 2,
GEN_INT (asan_frame_size
+ base_align_bias),
TYPE_MODE (pointer_sized_int_node),
@@ -1085,10 +1086,27 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
shadow_base = expand_binop (Pmode, lshr_optab, base,
GEN_INT (ASAN_SHADOW_SHIFT),
NULL_RTX, 1, OPTAB_DIRECT);
- shadow_base
-= plus_constant (Pmode, shadow_base,
-targetm.asan_shadow_offset ()
-+ (base_align_bias >> ASAN_SHADOW_SHIFT));
+ if (ASAN_FIXED_SHADOW_OFFSET)
+{
+ shadow_base
+= plus_constant (Pmode, shadow_base,
+targetm.asan_shadow_offset ()
++ (base_align_bias >> ASAN_SHADOW_SHIFT));
+}
+ else
+{
+ ret = init_one_libfunc ("__asan_get_shadow_ptr");
+ shadow_start = gen_reg_rtx (ptr_mode);
+ emit_library_call_value (ret, shadow_start, LCT_NORMAL, ptr_mode, 0);
+ shadow_start_lab = gen_label_rtx ();
+ int very_unlikely = REG_BR_PROB_BASE / 100 - 1;
+ emit_cmp_and_jump_insns (shadow_start, const0_rtx, EQ, NULL_RTX,
+ VOIDmode, 0, shadow_start_lab, very_unlikely);
+
+ shadow_base
+= expand_binop (Pmode, add_optab, shadow_base, shadow_start, NULL_RTX,
1, OPTAB_DIRECT);
+ shadow_base = plus_constant (Pmode, shadow_base, (base_align_bias >>
ASAN_SHADOW_SHIFT));
+}
gcc_assert (asan_shadow_set != -1
&& (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
shadow_mem = gen_rtx_MEM (SImode, shadow_base);
@@ -1137,6 +1155,8 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
cur_shadow_byte = ASAN_STACK_MAGIC_MIDDLE;
}
do_pending_stack_adjust ();
+ if (shadow_start_lab != NULL_RTX)
+emit_label (shadow_start_lab);
/* Construct epilogue sequence. */
start_sequence ();
@@ -1182,6 +1202,16 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
emit_label (lab2);
}
+ if (!ASAN_FIXED_SHADOW_OFFSET)
+{
+// ret = init_one_libfunc ("__asan_get_shadow_ptr");
+// shadow_start = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL,
ptr_mode, 0);
+ shadow_start_lab2 = gen_label_rtx ();
+ int very_unlikely = REG_BR_PROB_BASE / 100 - 1;
+ emit_cmp_and_jump_insns (shadow_start, const0_rtx, EQ, NULL_RTX,
+ VOIDmode, 0, shadow_start_lab2, very_unlikely);
+}
+
shadow_mem = gen_rtx_MEM (BLKmode, shadow_base);
set_mem_alias_set (shadow_mem, asan_shadow_s
Re: Stack instrumentation for kernel.
On Friday, June 20, 2014 6:26:37 PM UTC+4, Yuri Gribov wrote: > > On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin > wrote: > > --param asan-memintrin=0 --param asan-fixed-shadow-offset=0 > > This wasn't yet upstreamed. > Can you share remaining patches with us? > > > And with --param asan-stack=1 it also works now. > > This requires asan-fixed-shaw-offset=0. > > -Y > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
Cool! Yes, -fsanitize=kernel-address is highly desirable asap. Because current scheme is incompatible with inline instrumentation for kernel. So we need to start telling people to use -fsanitize=kernel-address as early as possible. On Fri, Jun 20, 2014 at 7:26 AM, Yuri Gribov wrote: > On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin > wrote: >> --param asan-memintrin=0 --param asan-fixed-shadow-offset=0 > > This wasn't yet upstreamed. > >> And with --param asan-stack=1 it also works now. > > This requires asan-fixed-shaw-offset=0. > > -Y > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin wrote: > --param asan-memintrin=0 --param asan-fixed-shadow-offset=0 This wasn't yet upstreamed. > And with --param asan-stack=1 it also works now. This requires asan-fixed-shaw-offset=0. -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin wrote: > 2014-06-20 16:16 GMT+04:00 Yuri Gribov : >> All, >> >> FYI it should now be possible to replace existing Kasan implementation >> (which abuses TSan) with stock userspace Asan. We (well, Andrew) have >> successfully sanitized kernel with CFLAGS = -fsanitize=address --param >> asan-stack=0 --param asan-globals=0 --param use-after-return=0 --param >> asan-instrumentation-with-call-threshold=0. As Dmitry pointed out, we >> could hide all these --param's under -fsanitize=kernel-address. >> >> @Andrey: did I miss anything in CFLAGS? >> > > --param asan-memintrin=0 --param asan-fixed-shadow-offset=0 > > And with --param asan-stack=1 it also works now. rock&roll! > > Am I right to assume that params hidden under -fsantize=kernel-addres > could be overwritten if anyone wants to enable > for e.g. stack instrumentation? Like this: > -fsanitize=kernel-address --param asan-stack=1 I think so, yes. > >> -Y >> >> -- >> You received this message because you are subscribed to the Google Groups >> "address-sanitizer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to address-sanitizer+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > Best regards, > Andrey Ryabinin > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
2014-06-20 16:22 GMT+04:00 Konstantin Serebryany : > Nice! > > On Fri, Jun 20, 2014 at 4:16 PM, Yuri Gribov wrote: >> All, >> >> FYI it should now be possible to replace existing Kasan implementation >> (which abuses TSan) with stock userspace Asan. We (well, Andrew) have >> successfully sanitized kernel with CFLAGS = -fsanitize=address --param >> asan-stack=0 --param asan-globals=0 --param use-after-return=0 --param >> asan-instrumentation-with-call-threshold=0. As Dmitry pointed out, we >> could hide all these --param's under -fsanitize=kernel-address. >> >> @Andrey: did I miss anything in CFLAGS? >> >> -Y >> >> -- >> You received this message because you are subscribed to the Google Groups >> "address-sanitizer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to address-sanitizer+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Best regards, Andrey Ryabinin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
2014-06-20 16:16 GMT+04:00 Yuri Gribov : > All, > > FYI it should now be possible to replace existing Kasan implementation > (which abuses TSan) with stock userspace Asan. We (well, Andrew) have > successfully sanitized kernel with CFLAGS = -fsanitize=address --param > asan-stack=0 --param asan-globals=0 --param use-after-return=0 --param > asan-instrumentation-with-call-threshold=0. As Dmitry pointed out, we > could hide all these --param's under -fsanitize=kernel-address. > > @Andrey: did I miss anything in CFLAGS? > --param asan-memintrin=0 --param asan-fixed-shadow-offset=0 And with --param asan-stack=1 it also works now. Am I right to assume that params hidden under -fsantize=kernel-addres could be overwritten if anyone wants to enable for e.g. stack instrumentation? Like this: -fsanitize=kernel-address --param asan-stack=1 > -Y > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Best regards, Andrey Ryabinin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
Nice! On Fri, Jun 20, 2014 at 4:16 PM, Yuri Gribov wrote: > All, > > FYI it should now be possible to replace existing Kasan implementation > (which abuses TSan) with stock userspace Asan. We (well, Andrew) have > successfully sanitized kernel with CFLAGS = -fsanitize=address --param > asan-stack=0 --param asan-globals=0 --param use-after-return=0 --param > asan-instrumentation-with-call-threshold=0. As Dmitry pointed out, we > could hide all these --param's under -fsanitize=kernel-address. > > @Andrey: did I miss anything in CFLAGS? > > -Y > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
All, FYI it should now be possible to replace existing Kasan implementation (which abuses TSan) with stock userspace Asan. We (well, Andrew) have successfully sanitized kernel with CFLAGS = -fsanitize=address --param asan-stack=0 --param asan-globals=0 --param use-after-return=0 --param asan-instrumentation-with-call-threshold=0. As Dmitry pointed out, we could hide all these --param's under -fsanitize=kernel-address. @Andrey: did I miss anything in CFLAGS? -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
I must say that experiment with stack instrumentation was quiet successful. There was only one small problem with expanding stack size on arm - https://lkml.org/lkml/2014/6/18/339 I didn't bother to check x86_64 yet, but I don't expect any problems there. -- Best regards, Andrew Ryabinin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
>>> I propose to add -fsanitize=kernel-address when the first patch is >>> committed. Now it will just enable "-fsanitize=address >>> -asan-instrumentation-with-call-threshold=-1" internally. But later we >>> will be able to change instrumentation for kernel under the hood w/o >>> disturbing users. >> >> Yup, sounds right. Note that this will (unfortunately) be >> --param asan-instrumentation-with-call-threshold=0 (not -1) >> because GCC developers don't want to allow negative parameters. > > If it all happens under the covers of -fsanitize=kernel-address, it > does not matter much, right? Sure. -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Fri, Jun 6, 2014 at 8:29 PM, Yuri Gribov wrote: > Dmitry, > >> I propose to add -fsanitize=kernel-address when the first patch is >> committed. Now it will just enable "-fsanitize=address >> -asan-instrumentation-with-call-threshold=-1" internally. But later we >> will be able to change instrumentation for kernel under the hood w/o >> disturbing users. > > Yup, sounds right. Note that this will (unfortunately) be > --param asan-instrumentation-with-call-threshold=0 (not -1) > because GCC developers don't want to allow negative parameters. If it all happens under the covers of -fsanitize=kernel-address, it does not matter much, right? >> As for __kasan vs __asan prefixes, I don't care too much. >> __asan will work for us. > > Ok. Or we could throw in a some __attribute__((alias))'es. We can (and probably will) throw them temporary during transition. But I don't want to leave them forever. It looks ugly. >> Also, does gcc asan pass emit ctors into every translation unit? It >> was not working for us a year ago in kernel. Do you plan to disable >> them in kernel instrumentation mode? > > We had some discussion with Andrey but haven't yet fleshed anything out. > For now we will disable them with --param asan-globals=0. Then this is another reason to introduce -fsanitize=kernel-address earlier rather than later. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
Dmitry, > I propose to add -fsanitize=kernel-address when the first patch is > committed. Now it will just enable "-fsanitize=address > -asan-instrumentation-with-call-threshold=-1" internally. But later we > will be able to change instrumentation for kernel under the hood w/o > disturbing users. Yup, sounds right. Note that this will (unfortunately) be --param asan-instrumentation-with-call-threshold=0 (not -1) because GCC developers don't want to allow negative parameters. > As for __kasan vs __asan prefixes, I don't care too much. > __asan will work for us. Ok. Or we could throw in a some __attribute__((alias))'es. > Also, does gcc asan pass emit ctors into every translation unit? It > was not working for us a year ago in kernel. Do you plan to disable > them in kernel instrumentation mode? We had some discussion with Andrey but haven't yet fleshed anything out. For now we will disable them with --param asan-globals=0. -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Tue, May 27, 2014 at 1:37 PM, Yuri Gribov wrote: > On Mon, May 26, 2014 at 7:57 PM, 'Dmitry Vyukov' via address-sanitizer > wrote: >> What exactly do you want to write? We need to coordinate. > > From compiler's side we'll probably start experimenting with stack > instrumentation. Provided that we stick with function calls, I like > the frame metadata approach most (i.e. insert calls to > __kasan_instrument_stack/__kasan_uninstrument_stack at start/end of > function). Hi Yuri, Regarding your instrumentation patch in the gcc mailing list. I was thinking about evolution of kasan instrumentation in gcc. Let's submit it as is for now to reduce traction in the gcc community. But sooner or later we will want inline instrumentation for kasan, and it won't work with this "-fsanitize=address -asan-instrumentation-with-call-threshold=-1" scheme (the compiler won't be able to understand what type of instrumentation user wants). Also we now have -fsanitize=kernel-address in our makefiles, and we will need to replace it with "-fsanitize=address -asan-instrumentation-with-call-threshold=-1"; and later when we have inline instrumentation we will need to replace it once again. So I propose to add -fsanitize=kernel-address when the first patch is committed. Now it will just enable "-fsanitize=address -asan-instrumentation-with-call-threshold=-1" internally. But later we will be able to change instrumentation for kernel under the hood w/o disturbing users. As for __kasan vs __asan prefixes, I don't care too much. __asan will work for us. Sounds good? Also, does gcc asan pass emit ctors into every translation unit? It was not working for us a year ago in kernel. Do you plan to disable them in kernel instrumentation mode? -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
2014-05-27 21:03 GMT+04:00 'Dmitry Vyukov' via address-sanitizer : > > Sounds good to me. > From your experience, how long can it take to integrate a feature like > kasan into mainline kernel? Ha! I don't have such experience. It's hard to say, I expect that this definitely will take several weeks after sending first patch series. > We would like to support some central repository for kasan until that > happens. We are in progress of setting up github.org/google/kasan > repo, but it's delayed due to some formal procedures. > Unfortunately I'm also not able to share my work yet for the same reason. > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Best regards, Andrew Ryabinin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Tue, May 27, 2014 at 12:15 PM, Andrey Ryabinin wrote: > 2014-05-26 19:57 GMT+04:00 'Dmitry Vyukov' via address-sanitizer > : >> On Mon, May 26, 2014 at 7:36 PM, Andrey Ryabinin >> wrote: >>> 2014-05-26 14:51 GMT+04:00 'Dmitry Vyukov' via address-sanitizer >>> : Regarding kernel, we need to put together a TODO list -- there is lots of work. Do you able to build kernel with asan and boot it? Just verifying it and pointing any weak places in our docs would be a good start. Thanks! >>> >>> Actually I advanced much further than just building and booting. I did >>> some work on the basis of existing >>> implementation from https://github.com/xairy/linux. First of all I >>> removed all x86 specific hacks, so it's >>> cross-platform now (currently I'm running sanitized kernel on ARM board). >>> Also added SLUB and buddy allocator support. >>> There are some other minor improvements, like proper integration with >>> kbuild instead of nasty gcc.py script... >> >> Whoa! >> We want this! >> >> >>> Since we are all working on the same thing, I would be cool to avoid >>> extra efforts and start to work together. >>> I assume that you want kasan to be a part of mainline Linux kernel, as >>> do I. So design & implementation >>> should be discussed with Linux kernel community. >>> What do you think if I will send our work to Linux kernel mail list, >>> and we will discuss it and any further step >>> together with Linux community? >> >> We absolutely want to discuss it with the community and make it part >> of mainline kernel. >> >> Were you able to find some bugs? Bug count is usually a strong >> argument in favor of a tool. >> > > I didn't found any bugs yet, but didn't test much. Though, I found one > interesting bug in put_user, because of kasan compiler > puts functions calls almost everywhere. It was there for a very long > time - http://thread.gmane.org/gmane.linux.kernel/1696488 Nice catch! > Testing of linux-next tree in my near plans. > > >> What exactly do you want to write? We need to coordinate. >> > > I propose to sent RFC patch set and find out how much community like > this feature. > Here is my plan: > 1. Sent kasan patches for slub/buddy allocator. I don't want to keep > slab support for several reasons > - I don't like how it's implemented now. > - slub support is much simpler to implement, so it will be easier to > review and increase chances for positive feedback > - usually linux kernel guys don't like big patch sets, so it would be > better to split. > 2. If we get positive feedback and after mainline gcc will support > outline instrumentation - send updated patchset. > According to reviewers feedback we may need to perform several > iterations to fix all issuse before merging to mainline. > 3. After basic support will be merged we may proceed further with slab > support and other things, that comes to mind. Sounds good to me. >From your experience, how long can it take to integrate a feature like kasan into mainline kernel? We would like to support some central repository for kasan until that happens. We are in progress of setting up github.org/google/kasan repo, but it's delayed due to some formal procedures. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
2014-05-27 14:38 GMT+04:00 Yuri Gribov : >> alternative to __kasan_instrument_stack is to implement >> __asan_get_shadow_ptr(addr) and then reuse the existing inline stack >> instrumentation. > > This would be even easier. > Don't forget that shadow in kernel is not always available. __asan_get_shadow_ptr(addr) should return NULL if shadow is not allocated yet, so inlined code must check return value. This means that we will check the same thing (if shadow available or not) twice - once in __asan_get_shadow_ptr and later - checking of the return value. The good part here is that we will save one function call (__kasan_uninstrument_stack). > -Y > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Best regards, Andrew Ryabinin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
> alternative to __kasan_instrument_stack is to implement > __asan_get_shadow_ptr(addr) and then reuse the existing inline stack > instrumentation. This would be even easier. -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Tue, May 27, 2014 at 1:37 PM, Yuri Gribov wrote: > On Mon, May 26, 2014 at 7:57 PM, 'Dmitry Vyukov' via address-sanitizer > wrote: >> What exactly do you want to write? We need to coordinate. > > From compiler's side we'll probably start experimenting with stack > instrumentation. Provided that we stick with function calls, I like > the frame metadata approach most (i.e. insert calls to > __kasan_instrument_stack/__kasan_uninstrument_stack at start/end of > function). alternative to __kasan_instrument_stack is to implement __asan_get_shadow_ptr(addr) and then reuse the existing inline stack instrumentation. > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Mon, May 26, 2014 at 7:57 PM, 'Dmitry Vyukov' via address-sanitizer wrote: > What exactly do you want to write? We need to coordinate. >From compiler's side we'll probably start experimenting with stack instrumentation. Provided that we stick with function calls, I like the frame metadata approach most (i.e. insert calls to __kasan_instrument_stack/__kasan_uninstrument_stack at start/end of function). -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
2014-05-26 19:57 GMT+04:00 'Dmitry Vyukov' via address-sanitizer : > On Mon, May 26, 2014 at 7:36 PM, Andrey Ryabinin > wrote: >> 2014-05-26 14:51 GMT+04:00 'Dmitry Vyukov' via address-sanitizer >> : >>> >>> Regarding kernel, we need to put together a TODO list -- there is lots of >>> work. >>> Do you able to build kernel with asan and boot it? Just verifying it >>> and pointing any weak places in our docs would be a good start. >>> Thanks! >>> >> >> Actually I advanced much further than just building and booting. I did >> some work on the basis of existing >> implementation from https://github.com/xairy/linux. First of all I >> removed all x86 specific hacks, so it's >> cross-platform now (currently I'm running sanitized kernel on ARM board). >> Also added SLUB and buddy allocator support. >> There are some other minor improvements, like proper integration with >> kbuild instead of nasty gcc.py script... > > Whoa! > We want this! > > >> Since we are all working on the same thing, I would be cool to avoid >> extra efforts and start to work together. >> I assume that you want kasan to be a part of mainline Linux kernel, as >> do I. So design & implementation >> should be discussed with Linux kernel community. >> What do you think if I will send our work to Linux kernel mail list, >> and we will discuss it and any further step >> together with Linux community? > > We absolutely want to discuss it with the community and make it part > of mainline kernel. > > Were you able to find some bugs? Bug count is usually a strong > argument in favor of a tool. > I didn't found any bugs yet, but didn't test much. Though, I found one interesting bug in put_user, because of kasan compiler puts functions calls almost everywhere. It was there for a very long time - http://thread.gmane.org/gmane.linux.kernel/1696488 Testing of linux-next tree in my near plans. > What exactly do you want to write? We need to coordinate. > I propose to sent RFC patch set and find out how much community like this feature. Here is my plan: 1. Sent kasan patches for slub/buddy allocator. I don't want to keep slab support for several reasons - I don't like how it's implemented now. - slub support is much simpler to implement, so it will be easier to review and increase chances for positive feedback - usually linux kernel guys don't like big patch sets, so it would be better to split. 2. If we get positive feedback and after mainline gcc will support outline instrumentation - send updated patchset. According to reviewers feedback we may need to perform several iterations to fix all issuse before merging to mainline. 3. After basic support will be merged we may proceed further with slab support and other things, that comes to mind. > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Best regards, Andrew Ryabinin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
> Actually I advanced much further than just building and booting. I did > some work on the basis of existing > implementation from https://github.com/xairy/linux. First of all I > removed all x86 specific hacks, so it's > cross-platform now (currently I'm running sanitized kernel on ARM board). > Also added SLUB and buddy allocator support. > There are some other minor improvements, like proper integration with > kbuild instead of nasty gcc.py script... We also sent outline instrumentation patches to GCC (https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02194.html) so perhaps Kasan would soon be usable with mainline compiler. -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Mon, May 26, 2014 at 7:36 PM, Andrey Ryabinin wrote: > 2014-05-26 14:51 GMT+04:00 'Dmitry Vyukov' via address-sanitizer > : >> >> Regarding kernel, we need to put together a TODO list -- there is lots of >> work. >> Do you able to build kernel with asan and boot it? Just verifying it >> and pointing any weak places in our docs would be a good start. >> Thanks! >> > > Actually I advanced much further than just building and booting. I did > some work on the basis of existing > implementation from https://github.com/xairy/linux. First of all I > removed all x86 specific hacks, so it's > cross-platform now (currently I'm running sanitized kernel on ARM board). > Also added SLUB and buddy allocator support. > There are some other minor improvements, like proper integration with > kbuild instead of nasty gcc.py script... Whoa! We want this! > Since we are all working on the same thing, I would be cool to avoid > extra efforts and start to work together. > I assume that you want kasan to be a part of mainline Linux kernel, as > do I. So design & implementation > should be discussed with Linux kernel community. > What do you think if I will send our work to Linux kernel mail list, > and we will discuss it and any further step > together with Linux community? We absolutely want to discuss it with the community and make it part of mainline kernel. Were you able to find some bugs? Bug count is usually a strong argument in favor of a tool. What exactly do you want to write? We need to coordinate. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
2014-05-26 14:51 GMT+04:00 'Dmitry Vyukov' via address-sanitizer : > > Regarding kernel, we need to put together a TODO list -- there is lots of > work. > Do you able to build kernel with asan and boot it? Just verifying it > and pointing any weak places in our docs would be a good start. > Thanks! > Actually I advanced much further than just building and booting. I did some work on the basis of existing implementation from https://github.com/xairy/linux. First of all I removed all x86 specific hacks, so it's cross-platform now (currently I'm running sanitized kernel on ARM board). Also added SLUB and buddy allocator support. There are some other minor improvements, like proper integration with kbuild instead of nasty gcc.py script... Since we are all working on the same thing, I would be cool to avoid extra efforts and start to work together. I assume that you want kasan to be a part of mainline Linux kernel, as do I. So design & implementation should be discussed with Linux kernel community. What do you think if I will send our work to Linux kernel mail list, and we will discuss it and any further step together with Linux community? -- Best regards, Andrew Ryabinin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Mon, May 26, 2014 at 2:18 PM, Yuri Gribov wrote: > Kostya, > >>> I'm wondering, have you thought about implementing stack instrumentation for >>> linux kernel? >> Of course we did! This is in our near term plans. > > When do you think we can expect this feature? Difficult to say. Several months maybe. >> We first need to prepare a reasonable patch to GCC that implements >> kasan instrumentation (in progress). > > Could you provide some details about Kasan instrumentation plans? Are > you going to keep function calls or do inline instrumentation similar > to userspace Asan? Eventually we want to switch to inlined instrumentation similar to user-space asan. But we need to figure out how it will look like, it's much easier to experiment with runtime calls. The instrumentation is not the hotspot ATM. >> Then we are going to extend it to support stack overflow instrumentation. > > Can we help on compiler/kernel side? We will be sending gcc patches soon. Review and +1's are welcome. Regarding kernel, we need to put together a TODO list -- there is lots of work. Do you able to build kernel with asan and boot it? Just verifying it and pointing any weak places in our docs would be a good start. Thanks! -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
Kostya, >> I'm wondering, have you thought about implementing stack instrumentation for >> linux kernel? > Of course we did! This is in our near term plans. When do you think we can expect this feature? > We first need to prepare a reasonable patch to GCC that implements > kasan instrumentation (in progress). Could you provide some details about Kasan instrumentation plans? Are you going to keep function calls or do inline instrumentation similar to userspace Asan? > Then we are going to extend it to support stack overflow instrumentation. Can we help on compiler/kernel side? -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stack instrumentation for kernel.
On Mon, May 26, 2014 at 1:28 PM, Andrey Ryabinin wrote: > Hi all > > I'm wondering, have you thought about implementing stack instrumentation for > linux kernel? Of course we did! This is in our near term plans. > It seems there is not much difference from userspace implementation. Yep. > For stack redzones we need a lot larger stack than usual. Currently kernel > stack is limited to 8K-sizeof(struct thread_info). > However it should be trivial to enlarge default stack size for sanitizers > needs. > > > UAR implementation will be a bit more complicated, but it seems doable to > me. UAR in kasan is not in our near term plans... > > For allocating "fake stack" slab allocator would be probably enough, but > there are some problems: > 1. I believe we don't want to allocate slab redzones, and call kasan hooks > for such "fake stack" allocations. > 2. On early boot stages until some point kmalloc is not available yet. > > Solutions: > 1. We could create kmem_caches for "fake stacks" with special flag, which > will prevent us from redzone allocation and > calling kasan hooks. > 2. That's trivial - just check if slab_state == UP. > > > Poisoning/unpoisoning stacks could be implemented the same way like for > userspace, just without inlining. > > At first, poison shadow after "fake stack" allocation faze (if "fake stack" > allocation failed poison current stack). > And then that call unpoison_shadow(addr, size) for every stack variable. > For speed up it might be worth to implement unpoison_shadow_x functions > where x is most common variables sizes (1, 2, 4, 8, 16). > The big problem I expect here, is that it's probably gonna be slooow. > > > Another option, suggested by Yuri Gribov, would be to call function only > once and provide it with address of the beginning of descriptor of caller's > frame. > > That would certainly speed things up. > > Something like poison_stack(void *stack_start_addres, char > *stack_description, stack_size) > > > > So, what do you think about it? We first need to prepare a reasonable patch to GCC that implements kasan instrumentation (in progress). Then we are going to extend it to support stack overflow instrumentation. --kcc > > Best regards, > Andrey Ryabinin > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
