Re: [PATCH 0/5] some vxworks patches

[Rasmus Villemoes]

On 03/06/2020 19.41, Olivier Hainque wrote:
> Hi Rasmus,
> 
>> On 26 May 2020, at 16:52, Rasmus Villemoes  wrote:
>>
>> libstdc++, but I'd like some feedback on whether vxworks 5 is even
>> supposed to be (still) supported before digging further.
> 
> Unfortunately, no, not really: while we don't break it
> intentionally, it was transitioned to End Of Life a couple
> of years a ago and we don't test on such configurations
> any more.
> 
> We are gradually going to a similar path for VxWorks 6, with 6.8
> EOL since July 2019 and 6.9 turned Legacy early 2020 after ~9 years
> out.

Hi Olivier,

Thanks for the answer, though obviously not what I was hoping for.

Just for the record, who exactly are "we" above?

> Your message comes in timely - I was about to send a note
> mentioning this soon now, as we are starting a transition of
> all our production toolchains to gcc-10 and we are resuming
> posting updates upstream as stage1 has just reopened.
> 
> The system environment on 5 and 6 is essentially frozen. Maintaining
> new versions of gcc operational on such legacy versions is increasingly
> difficult with every release as incompatibilities of various degrees
> of subtlety keep creeping in.
>
> Build failures are one thing and can often be addressed, but we have
> witnessed, for example, issues with newer dwarf constructs incorrectly
> processed by the system unwind lib or wrong code gen problems on arm
> for vx6 related to the use of a long deprecated ABI.
> 
> We can take patches that are reported as helping such cases,
> as we have done in the past, as long as they are localized and look
> generally good. But as I mentioned, we are not in a position to
> really test vx5 configurations any more.

I (and my customer) am willing to put in some effort to make (or keep)
gcc working for vxworks 5. In case the ifdeffery in the existing
vxworks-related files becomes too unwieldy, would it be possible to
create a separate vxworks5 target, similar to the existing vxworksae
variant?

Thanks,
Rasmus

[PATCH 1/5] gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic

[Alexander Popov]

Some time ago Variable Length Arrays (VLA) were removed from the kernel.
The kernel is built with '-Wvla'. Let's exclude alloca() from the
instrumentation logic and make it simpler. The build-time assertion
against alloca() is added instead.

Unfortunately, for that assertion we can't simply check cfun->calls_alloca
during RTL phase. It turned out that gcc before version 7 called
allocate_dynamic_stack_space() from expand_stack_vars() for runtime
alignment of constant-sized stack variables. That caused cfun->calls_alloca
to be set for functions that don't use alloca().

Signed-off-by: Alexander Popov 
---
 scripts/gcc-plugins/stackleak_plugin.c | 51 +++---
 1 file changed, 21 insertions(+), 30 deletions(-)

diff --git a/scripts/gcc-plugins/stackleak_plugin.c 
b/scripts/gcc-plugins/stackleak_plugin.c
index cc75eeba0be1..1ecfe50d0bf5 100644
--- a/scripts/gcc-plugins/stackleak_plugin.c
+++ b/scripts/gcc-plugins/stackleak_plugin.c
@@ -9,10 +9,9 @@
  * any of the gcc libraries
  *
  * This gcc plugin is needed for tracking the lowest border of the kernel 
stack.
- * It instruments the kernel code inserting stackleak_track_stack() calls:
- *  - after alloca();
- *  - for the functions with a stack frame size greater than or equal
- * to the "track-min-size" plugin parameter.
+ * It instruments the kernel code inserting stackleak_track_stack() calls
+ * for the functions with a stack frame size greater than or equal to
+ * the "track-min-size" plugin parameter.
  *
  * This plugin is ported from grsecurity/PaX. For more information see:
  *   https://grsecurity.net/
@@ -46,7 +45,7 @@ static struct plugin_info stackleak_plugin_info = {
"disable\t\tdo not activate the plugin\n"
 };
 
-static void stackleak_add_track_stack(gimple_stmt_iterator *gsi, bool after)
+static void stackleak_add_track_stack(gimple_stmt_iterator *gsi)
 {
gimple stmt;
gcall *stackleak_track_stack;
@@ -56,12 +55,7 @@ static void stackleak_add_track_stack(gimple_stmt_iterator 
*gsi, bool after)
/* Insert call to void stackleak_track_stack(void) */
stmt = gimple_build_call(track_function_decl, 0);
stackleak_track_stack = as_a_gcall(stmt);
-   if (after) {
-   gsi_insert_after(gsi, stackleak_track_stack,
-   GSI_CONTINUE_LINKING);
-   } else {
-   gsi_insert_before(gsi, stackleak_track_stack, GSI_SAME_STMT);
-   }
+   gsi_insert_before(gsi, stackleak_track_stack, GSI_SAME_STMT);
 
/* Update the cgraph */
bb = gimple_bb(stackleak_track_stack);
@@ -87,14 +81,13 @@ static bool is_alloca(gimple stmt)
 
 /*
  * Work with the GIMPLE representation of the code. Insert the
- * stackleak_track_stack() call after alloca() and into the beginning
- * of the function if it is not instrumented.
+ * stackleak_track_stack() call into the beginning of the function.
  */
 static unsigned int stackleak_instrument_execute(void)
 {
basic_block bb, entry_bb;
-   bool prologue_instrumented = false, is_leaf = true;
-   gimple_stmt_iterator gsi;
+   bool is_leaf = true;
+   gimple_stmt_iterator gsi = { 0 };
 
/*
 * ENTRY_BLOCK_PTR is a basic block which represents possible entry
@@ -111,27 +104,17 @@ static unsigned int stackleak_instrument_execute(void)
 */
FOR_EACH_BB_FN(bb, cfun) {
for (gsi = gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi)) {
-   gimple stmt;
-
-   stmt = gsi_stmt(gsi);
+   gimple stmt = gsi_stmt(gsi);
 
/* Leaf function is a function which makes no calls */
if (is_gimple_call(stmt))
is_leaf = false;
 
-   if (!is_alloca(stmt))
-   continue;
-
-   /* Insert stackleak_track_stack() call after alloca() */
-   stackleak_add_track_stack(&gsi, true);
-   if (bb == entry_bb)
-   prologue_instrumented = true;
+   /* Variable Length Arrays are forbidden in the kernel */
+   gcc_assert(!is_alloca(stmt));
}
}
 
-   if (prologue_instrumented)
-   return 0;
-
/*
 * Special cases to skip the instrumentation.
 *
@@ -168,7 +151,7 @@ static unsigned int stackleak_instrument_execute(void)
bb = single_succ(ENTRY_BLOCK_PTR_FOR_FN(cfun));
}
gsi = gsi_after_labels(bb);
-   stackleak_add_track_stack(&gsi, false);
+   stackleak_add_track_stack(&gsi);
 
return 0;
 }
@@ -185,12 +168,20 @@ static bool large_stack_frame(void)
 /*
  * Work with the RTL representation of the code.
  * Remove the unneeded stackleak_track_stack() calls from the functions
- * which don't call alloca() and don't have a large enough

[PATCH 0/5] Improvements of the stackleak gcc plugin

[Alexander Popov]

In this patch series I collected various improvements of the stackleak
gcc plugin.

The first patch excludes alloca() from the stackleak instrumentation logic
to make it simpler.

The second patch is the main improvement. It eliminates an unwanted
side-effect of kernel code instrumentation. This patch is a deep
reengineering of the idea described on grsecurity blog:
  https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction

The third patch adds 'verbose' plugin parameter for printing additional
info about the kernel code instrumentation.

Two other patches disable unneeded stackleak instrumentation for some
files.

I would like to thank Alexander Monakov  for his
advisory on gcc internals.

This patch series was tested for gcc version 4.8, 5, 6, 7, 8, 9, and 10
on x86_64, i386 and arm64.
That was done using the project 'kernel-build-containers':
  https://github.com/a13xp0p0v/kernel-build-containers


Alexander Popov (5):
  gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic
  gcc-plugins/stackleak: Use asm instrumentation to avoid useless
register saving
  gcc-plugins/stackleak: Add 'verbose' plugin parameter
  gcc-plugins/stackleak: Don't instrument itself
  gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO

 arch/arm64/kernel/vdso/Makefile|   3 +-
 include/linux/compiler_attributes.h|  13 ++
 kernel/Makefile|   1 +
 kernel/stackleak.c |  16 +-
 scripts/Makefile.gcc-plugins   |   2 +
 scripts/gcc-plugins/stackleak_plugin.c | 260 -
 6 files changed, 232 insertions(+), 63 deletions(-)

-- 
2.25.2

[PATCH 2/5] gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving

[Alexander Popov]

The kernel code instrumentation in stackleak gcc plugin works in two stages.
At first, stack tracking is added to GIMPLE representation of every function
(except some special cases). And later, when stack frame size info is
available, stack tracking is removed from the RTL representation of the
functions with small stack frame. There is an unwanted side-effect for these
functions: some of them do useless work with caller-saved registers.

As an example of such case, proc_sys_write without instrumentation:
55  push   %rbp
41 b8 01 00 00 00   mov$0x1,%r8d
48 89 e5mov%rsp,%rbp
e8 11 ff ff ff  callq  81284610 
5d  pop%rbp
c3  retq
0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
00 00 00

proc_sys_write with instrumentation:
55  push   %rbp
48 89 e5mov%rsp,%rbp
41 56   push   %r14
41 55   push   %r13
41 54   push   %r12
53  push   %rbx
49 89 f4mov%rsi,%r12
48 89 fbmov%rdi,%rbx
49 89 d5mov%rdx,%r13
49 89 cemov%rcx,%r14
4c 89 f1mov%r14,%rcx
4c 89 eamov%r13,%rdx
4c 89 e6mov%r12,%rsi
48 89 dfmov%rbx,%rdi
41 b8 01 00 00 00   mov$0x1,%r8d
e8 f2 fe ff ff  callq  81298e80 
5b  pop%rbx
41 5c   pop%r12
41 5d   pop%r13
41 5e   pop%r14
5d  pop%rbp
c3  retq
66 0f 1f 84 00 00 00nopw   0x0(%rax,%rax,1)
00 00

Let's improve the instrumentation to avoid this:

1. Make stackleak_track_stack() save all register that it works with.
Use no_caller_saved_registers attribute for that function. This attribute
is available for x86_64 and i386 starting from gcc-7.

2. Insert calling stackleak_track_stack() in asm:
  asm volatile("call stackleak_track_stack" :: "r" (current_stack_pointer))
Here we use ASM_CALL_CONSTRAINT trick from arch/x86/include/asm/asm.h.
The input constraint is taken into account during gcc shrink-wrapping
optimization. It is needed to be sure that stackleak_track_stack() call is
inserted after the prologue of the containing function, when the stack
frame is prepared.

This work is a deep reengineering of the idea described on grsecurity blog
  https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction

Signed-off-by: Alexander Popov 
---
 include/linux/compiler_attributes.h|  13 ++
 kernel/stackleak.c |  16 +-
 scripts/Makefile.gcc-plugins   |   2 +
 scripts/gcc-plugins/stackleak_plugin.c | 206 +
 4 files changed, 196 insertions(+), 41 deletions(-)

diff --git a/include/linux/compiler_attributes.h 
b/include/linux/compiler_attributes.h
index cdf016596659..522d57ae8532 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -41,6 +41,7 @@
 # define __GCC4_has_attribute___nonstring__   0
 # define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
 # define __GCC4_has_attribute___fallthrough__ 0
+# define __GCC4_has_attribute___no_caller_saved_registers__ 0
 #endif
 
 /*
@@ -175,6 +176,18 @@
  */
 #define __mode(x)   __attribute__((__mode__(x)))
 
+/*
+ * Optional: only supported since gcc >= 7
+ *
+ *   gcc: 
https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#index-no_005fcaller_005fsaved_005fregisters-function-attribute_002c-x86
+ * clang: 
https://clang.llvm.org/docs/AttributeReference.html#no-caller-saved-registers
+ */
+#if __has_attribute(__no_caller_saved_registers__)
+# define __no_caller_saved_registers   
__attribute__((__no_caller_saved_registers__))
+#else
+# define __no_caller_saved_registers
+#endif
+
 /*
  * Optional: not supported by clang
  *
diff --git a/kernel/stackleak.c b/kernel/stackleak.c
index b193a59fc05b..a8fc9ae1d03d 100644
--- a/kernel/stackleak.c
+++ b/kernel/stackleak.c
@@ -104,19 +104,9 @@ asmlinkage void notrace stackleak_erase(void)
 }
 NOKPROBE_SYMBOL(stackleak_erase);
 
-void __used notrace stackleak_track_stack(void)
+void __used __no_caller_saved_registers notrace stackleak_track_stack(void)
 {
-   /*
-* N.B. stackleak_erase() fills the kernel stack with the poison value,
-* which has the register width. That code assumes that the value
-* of 'lowest_stack' is aligned on the register width boundary.
-*
-* That is true for x86 and x86_64 because of the kernel stack
-* alignment on these platforms (for details, see 'cc_stack_align' in
-* arch/x86/Makefile)

[PATCH 4/5] gcc-plugins/stackleak: Don't instrument itself

[Alexander Popov]

There is no need to try instrumenting functions in kernel/stackleak.c.
Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
is disabled.

Signed-off-by: Alexander Popov 
---
 kernel/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/Makefile b/kernel/Makefile
index 4cb4130ced32..d372134ac9ec 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -118,6 +118,7 @@ obj-$(CONFIG_RSEQ) += rseq.o
 
 obj-$(CONFIG_SYSCTL_KUNIT_TEST) += sysctl-test.o
 
+CFLAGS_stackleak.o += $(DISABLE_STACKLEAK_PLUGIN)
 obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += stackleak.o
 KASAN_SANITIZE_stackleak.o := n
 KCOV_INSTRUMENT_stackleak.o := n
-- 
2.25.2

[PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO

[Alexander Popov]

Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c.
Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
is disabled.

Signed-off-by: Alexander Popov 
---
 arch/arm64/kernel/vdso/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 3862cad2410c..9b84cafbd2da 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -32,7 +32,8 @@ UBSAN_SANITIZE:= n
 OBJECT_FILES_NON_STANDARD  := y
 KCOV_INSTRUMENT:= n
 
-CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables
+CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables \
+   $(DISABLE_STACKLEAK_PLUGIN)
 
 ifneq ($(c-gettimeofday-y),)
   CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
-- 
2.25.2

[PATCH 3/5] gcc-plugins/stackleak: Add 'verbose' plugin parameter

[Alexander Popov]

Add 'verbose' plugin parameter for stackleak gcc plugin.
It can be used for printing additional info about the kernel code
instrumentation.

For using it add the following to scripts/Makefile.gcc-plugins:
  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK) \
+= -fplugin-arg-stackleak_plugin-verbose

Signed-off-by: Alexander Popov 
---
 scripts/gcc-plugins/stackleak_plugin.c | 31 +-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/scripts/gcc-plugins/stackleak_plugin.c 
b/scripts/gcc-plugins/stackleak_plugin.c
index 0769c5b9156d..19358712d4ed 100644
--- a/scripts/gcc-plugins/stackleak_plugin.c
+++ b/scripts/gcc-plugins/stackleak_plugin.c
@@ -33,6 +33,8 @@ __visible int plugin_is_GPL_compatible;
 static int track_frame_size = -1;
 static bool build_for_x86 = false;
 static const char track_function[] = "stackleak_track_stack";
+static bool disable = false;
+static bool verbose = false;
 
 /*
  * Mark these global variables (roots) for gcc garbage collector since
@@ -45,6 +47,7 @@ static struct plugin_info stackleak_plugin_info = {
.help = "track-min-size=nn\ttrack stack for functions with a stack 
frame size >= nn bytes\n"
"arch=target_arch\tspecify target build arch\n"
"disable\t\tdo not activate the plugin\n"
+   "verbose\t\tprint info about the instrumentation\n"
 };
 
 static void add_stack_tracking_gcall(gimple_stmt_iterator *gsi)
@@ -98,6 +101,10 @@ static tree get_current_stack_pointer_decl(void)
return var;
}
 
+   if (verbose) {
+   fprintf(stderr, "stackleak: missing current_stack_pointer in 
%s()\n",
+   DECL_NAME_POINTER(current_function_decl));
+   }
return NULL_TREE;
 }
 
@@ -366,6 +373,7 @@ static bool remove_stack_tracking_gasm(void)
  */
 static unsigned int stackleak_cleanup_execute(void)
 {
+   const char *fn = DECL_NAME_POINTER(current_function_decl);
bool removed = false;
 
/*
@@ -376,11 +384,17 @@ static unsigned int stackleak_cleanup_execute(void)
 * For more info see gcc commit 7072df0aae0c59ae437e.
 * Let's leave such functions instrumented.
 */
-   if (cfun->calls_alloca)
+   if (cfun->calls_alloca) {
+   if (verbose)
+   fprintf(stderr, "stackleak: instrument %s() old\n", fn);
return 0;
+   }
 
-   if (large_stack_frame())
+   if (large_stack_frame()) {
+   if (verbose)
+   fprintf(stderr, "stackleak: instrument %s()\n", fn);
return 0;
+   }
 
if (lookup_attribute_spec(get_identifier("no_caller_saved_registers")))
removed = remove_stack_tracking_gasm();
@@ -506,9 +520,6 @@ __visible int plugin_init(struct plugin_name_args 
*plugin_info,
 
/* Parse the plugin arguments */
for (i = 0; i < argc; i++) {
-   if (!strcmp(argv[i].key, "disable"))
-   return 0;
-
if (!strcmp(argv[i].key, "track-min-size")) {
if (!argv[i].value) {
error(G_("no value supplied for option 
'-fplugin-arg-%s-%s'"),
@@ -531,6 +542,10 @@ __visible int plugin_init(struct plugin_name_args 
*plugin_info,
 
if (!strcmp(argv[i].value, "x86"))
build_for_x86 = true;
+   } else if (!strcmp(argv[i].key, "disable")) {
+   disable = true;
+   } else if (!strcmp(argv[i].key, "verbose")) {
+   verbose = true;
} else {
error(G_("unknown option '-fplugin-arg-%s-%s'"),
plugin_name, argv[i].key);
@@ -538,6 +553,12 @@ __visible int plugin_init(struct plugin_name_args 
*plugin_info,
}
}
 
+   if (disable) {
+   if (verbose)
+   fprintf(stderr, "stackleak: disabled for this 
translation unit\n");
+   return 0;
+   }
+
/* Give the information about the plugin */
register_callback(plugin_name, PLUGIN_INFO, NULL,
&stackleak_plugin_info);
-- 
2.25.2

Re: [PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO

[Will Deacon via Gcc]

On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote:
> Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c.
> Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
> is disabled.
> 
> Signed-off-by: Alexander Popov 
> ---
>  arch/arm64/kernel/vdso/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> index 3862cad2410c..9b84cafbd2da 100644
> --- a/arch/arm64/kernel/vdso/Makefile
> +++ b/arch/arm64/kernel/vdso/Makefile
> @@ -32,7 +32,8 @@ UBSAN_SANITIZE  := n
>  OBJECT_FILES_NON_STANDARD:= y
>  KCOV_INSTRUMENT  := n
>  
> -CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> +CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables \
> + $(DISABLE_STACKLEAK_PLUGIN)

I can pick this one up via arm64, thanks. Are there any other plugins we
should be wary of? It looks like x86 filters out $(GCC_PLUGINS_CFLAGS)
when building the vDSO.

Will

Re: [PATCH 1/5] gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic

[Jann Horn via Gcc]

On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov  wrote:
> Some time ago Variable Length Arrays (VLA) were removed from the kernel.
> The kernel is built with '-Wvla'. Let's exclude alloca() from the
> instrumentation logic and make it simpler. The build-time assertion
> against alloca() is added instead.
[...]
> +   /* Variable Length Arrays are forbidden in the kernel 
> */
> +   gcc_assert(!is_alloca(stmt));

There is a patch series from Elena and Kees on the kernel-hardening
list that deliberately uses __builtin_alloca() in the syscall entry
path to randomize the stack pointer per-syscall - see
.

Re: [PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO

[Jann Horn via Gcc]

On Thu, Jun 4, 2020 at 3:58 PM Will Deacon  wrote:
> On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote:
> > Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c.
> > Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
> > is disabled.
> >
> > Signed-off-by: Alexander Popov 
> > ---
> >  arch/arm64/kernel/vdso/Makefile | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/vdso/Makefile 
> > b/arch/arm64/kernel/vdso/Makefile
> > index 3862cad2410c..9b84cafbd2da 100644
> > --- a/arch/arm64/kernel/vdso/Makefile
> > +++ b/arch/arm64/kernel/vdso/Makefile
> > @@ -32,7 +32,8 @@ UBSAN_SANITIZE  := n
> >  OBJECT_FILES_NON_STANDARD:= y
> >  KCOV_INSTRUMENT  := n
> >
> > -CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> > +CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables \
> > + $(DISABLE_STACKLEAK_PLUGIN)
>
> I can pick this one up via arm64, thanks. Are there any other plugins we
> should be wary of? It looks like x86 filters out $(GCC_PLUGINS_CFLAGS)
> when building the vDSO.

Maybe at some point we should replace exclusions based on
GCC_PLUGINS_CFLAGS and KASAN_SANITIZE and UBSAN_SANITIZE and
OBJECT_FILES_NON_STANDARD and so on with something more generic...
something that says "this file will not be built into the normal
kernel, it contains code that runs in realmode / userspace / some
similarly weird context, and none of our instrumentation
infrastructure is available there"...

Re: [PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO

[Alexander Popov]

On 04.06.2020 17:14, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 3:58 PM Will Deacon  wrote:
>> On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote:
>>> Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c.
>>> Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
>>> is disabled.
>>>
>>> Signed-off-by: Alexander Popov 
>>> ---
>>>  arch/arm64/kernel/vdso/Makefile | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/kernel/vdso/Makefile 
>>> b/arch/arm64/kernel/vdso/Makefile
>>> index 3862cad2410c..9b84cafbd2da 100644
>>> --- a/arch/arm64/kernel/vdso/Makefile
>>> +++ b/arch/arm64/kernel/vdso/Makefile
>>> @@ -32,7 +32,8 @@ UBSAN_SANITIZE  := n
>>>  OBJECT_FILES_NON_STANDARD:= y
>>>  KCOV_INSTRUMENT  := n
>>>
>>> -CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables
>>> +CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables \
>>> + $(DISABLE_STACKLEAK_PLUGIN)
>>
>> I can pick this one up via arm64, thanks. Are there any other plugins we
>> should be wary of? 

I can't tell exactly. I'm sure Kees has the whole picture.

>> It looks like x86 filters out $(GCC_PLUGINS_CFLAGS)
>> when building the vDSO.

Yes, that's why building x86 vDSO doesn't need $(DISABLE_STACKLEAK_PLUGIN).

> Maybe at some point we should replace exclusions based on
> GCC_PLUGINS_CFLAGS and KASAN_SANITIZE and UBSAN_SANITIZE and
> OBJECT_FILES_NON_STANDARD and so on with something more generic...
> something that says "this file will not be built into the normal
> kernel, it contains code that runs in realmode / userspace / some
> similarly weird context, and none of our instrumentation
> infrastructure is available there"...

Good idea. I would also add 'notrace' to that list.

Best regards,
Alexander

Re: [PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO

[Jann Horn via Gcc]

On Thu, Jun 4, 2020 at 4:21 PM Alexander Popov  wrote:
> On 04.06.2020 17:14, Jann Horn wrote:
> > Maybe at some point we should replace exclusions based on
> > GCC_PLUGINS_CFLAGS and KASAN_SANITIZE and UBSAN_SANITIZE and
> > OBJECT_FILES_NON_STANDARD and so on with something more generic...
> > something that says "this file will not be built into the normal
> > kernel, it contains code that runs in realmode / userspace / some
> > similarly weird context, and none of our instrumentation
> > infrastructure is available there"...
>
> Good idea. I would also add 'notrace' to that list.

Hm? notrace code should definitely still be subject to sanitizer
instrumentation.

Re: [PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO

[Alexander Popov]

On 04.06.2020 17:25, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 4:21 PM Alexander Popov  wrote:
>> On 04.06.2020 17:14, Jann Horn wrote:
>>> Maybe at some point we should replace exclusions based on
>>> GCC_PLUGINS_CFLAGS and KASAN_SANITIZE and UBSAN_SANITIZE and
>>> OBJECT_FILES_NON_STANDARD and so on with something more generic...
>>> something that says "this file will not be built into the normal
>>> kernel, it contains code that runs in realmode / userspace / some
>>> similarly weird context, and none of our instrumentation
>>> infrastructure is available there"...
>>
>> Good idea. I would also add 'notrace' to that list.
> 
> Hm? notrace code should definitely still be subject to sanitizer
> instrumentation.

I mean ftrace is sometimes disabled for functions that are executed in those
weird contexts. As well as kcov instrumentation.

It would be nice if that generic mechanism could help with choosing which kernel
code instrumentation technologies should be disabled in the given context.

Best regards,
Alexander

Re: [PATCH 2/5] gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving

[Miguel Ojeda via Gcc]

Hi Alexander,

On Thu, Jun 4, 2020 at 3:50 PM Alexander Popov  wrote:
>
> diff --git a/include/linux/compiler_attributes.h 
> b/include/linux/compiler_attributes.h
> index cdf016596659..522d57ae8532 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -41,6 +41,7 @@
>  # define __GCC4_has_attribute___nonstring__   0
>  # define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
>  # define __GCC4_has_attribute___fallthrough__ 0
> +# define __GCC4_has_attribute___no_caller_saved_registers__ 0
>  #endif

Nit: if you do another version, please move it before `noclone` to
keep the order (`fallthrough` was added in the wrong place).

Otherwise don't worry, I will sort it together with `fallthrough` when
I send a patch.

> +/*
> + * Optional: only supported since gcc >= 7
> + *
> + *   gcc: 
> https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#index-no_005fcaller_005fsaved_005fregisters-function-attribute_002c-x86
> + * clang: 
> https://clang.llvm.org/docs/AttributeReference.html#no-caller-saved-registers
> + */
> +#if __has_attribute(__no_caller_saved_registers__)
> +# define __no_caller_saved_registers   
> __attribute__((__no_caller_saved_registers__))
> +#else
> +# define __no_caller_saved_registers
> +#endif

Ditto.

Acked-by: Miguel Ojeda 

Cheers,
Miguel

Re: [PATCH 1/5] gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic

[Alexander Popov]

On 04.06.2020 17:01, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov  wrote:
>> Some time ago Variable Length Arrays (VLA) were removed from the kernel.
>> The kernel is built with '-Wvla'. Let's exclude alloca() from the
>> instrumentation logic and make it simpler. The build-time assertion
>> against alloca() is added instead.
> [...]
>> +   /* Variable Length Arrays are forbidden in the 
>> kernel */
>> +   gcc_assert(!is_alloca(stmt));
> 
> There is a patch series from Elena and Kees on the kernel-hardening
> list that deliberately uses __builtin_alloca() in the syscall entry
> path to randomize the stack pointer per-syscall - see
> .

Thanks, Jann.

At first glance, leaving alloca() handling in stackleak instrumentation logic
would allow to integrate stackleak and this version of random_kstack_offset.

Kees, Elena, did you try random_kstack_offset with upstream stackleak?

It looks to me that without stackleak erasing random_kstack_offset can be
weaker. I mean, if next syscall has a bigger stack randomization gap, the data
on thread stack from the previous syscall is not overwritten and can be used. Am
I right?

Another aspect: CONFIG_STACKLEAK_METRICS can be used for guessing kernel stack
offset, which is bad. It should be disabled if random_kstack_offset is on.

Best regards,
Alexander

Question about comparing function function decls

[Gary Oblock via Gcc]

I'm trying to determine during LTO optimization (with one partition)
whether of not a function call is to a function in the partition.

Here is the routine I've written. Note, I'm willing to admit up front
that the comparison below ( ) is probably dicey.

---
static bool
is_user_function ( gimple *call_stmt)
{
  tree fndecl = gimple_call_fndecl ( call_stmt);

  DEBUG_L("is_user_function: decl in: %p,", fndecl);
  DEBUG_F( print_generic_decl, stderr, fndecl, (dump_flags_t)-1);
  DEBUG("\n");
  INDENT(2);

  cgraph_node* node;
  bool ret_val = false;
  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
  {
DEBUG_L("decl %p,", node->decl);
DEBUG_F( print_generic_decl, stderr, node->decl, (dump_flags_t)-1);
DEBUG("\n");

if ( node->decl == fndecl )
  {
ret_val = true;
break;
  }
  }

  INDENT(-2);
  return ret_val;
}
---

Here's the test program I was compiling.

-- aux.h --
#include "stdlib.h"
typedef struct type type_t;
struct type {
  int i;
  double x;
};

#define MAX(x,y) ((x)>(y) ? (x) : (y))

extern int max1( type_t *, size_t);
extern double max2( type_t *, size_t);
extern type_t *setup( size_t);
-- aux.c --
#include "aux.h"
#include "stdlib.h"

type_t *
setup( size_t size)
{
  type_t *data = (type_t *)malloc( size * sizeof(type_t));
  size_t i;
  for( i = 0; i < size; i++ ) {
data[i].i = rand();
data[i].x = drand48();
  }
  return data;
}

int
max1( type_t *array, size_t len)
{
  size_t i;
  int result = array[0].i;
  for( i = 1; i < len; i++  ) {
result = MAX( array[i].i, result);
  }
  return result;
}

double
max2( type_t *array, size_t len)
{
  size_t i;
  double result = array[0].x;
  for( i = 1; i < len; i++  ) {
result = MAX( array[i].x, result);
  }
  return result;
}
-- main.c -
#include "aux.h"
#include "stdio.h"

type_t *data1;

int
main(void)
{
  type_t *data2 = setup(200);
  data1 = setup(100);

  printf("First %d\n" , max1(data1,100));
  printf("Second %e\n", max2(data2,200));
}
---

The output follows:

---
L# 1211: is_user_function: decl in: 0x7f078461be00,  static intD. 
max1D. (struct type_t *, size_t);
L# 1222:   decl 0x7f078462,  static struct type_t * setupD. (size_t);
L# 1222:   decl 0x7f078461bf00,  static intD. max1.constprop.0D. 
(struct type_t *);
L# 1222:   decl 0x7f078461bd00,  static doubleD. max2.constprop.0D. 
(struct type_t *);
L# 1222:   decl 0x7f078461bb00,  static intD. mainD. (void);
---

Now it's pretty obvious that constant propagation decided the size_t
len arguments to max1 and max2 were no longer needed. However, the
function declaration information on the calls to them weren't updated
so they'll never match. Now if there is another way to see if the
function is in the partition or if there is some other way to compare
the functions in a partition, please let me know.

Thanks,

Gary Oblock
Ampere Computing

PS. The body of the message is attached in a file because my email program
(Outlook) mangled the above.



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.


gcc_msg
Description: gcc_msg

Re: [PATCH 0/5] Improvements of the stackleak gcc plugin

[Kees Cook via Gcc]

On Thu, Jun 04, 2020 at 04:49:52PM +0300, Alexander Popov wrote:
> In this patch series I collected various improvements of the stackleak
> gcc plugin.

Great; thank you! I'll take a closer look at this shortly!

-- 
Kees Cook

gcc-8-20200604 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20200604 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20200604/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision f4a45e0d85e51bd6550a82f31f70484c03332a4e

You'll find:

 gcc-8-20200604.tar.xzComplete GCC

  SHA256=e53a28c9eb11846062cc5d5337ef302b318d70efa74f5f2c5687667d2edea239
  SHA1=d9de2d6b5ef941a49cfc6124579ba1007180f2b0

Diffs from 8-20200528 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: GSoC: OMPD conversation

[Martin Jambor]

Hi,

On Sun, May 31 2020, y2s1982 . wrote:
> Hello team,
>
> I just wanted to give an update to my current progress. I spent most of the
> time looking over OMPD documentation again and studying LLVM's approach to
> it.
>

thanks a lot, sorry about replying this late again, unfortunately I
missed your email on Monday and only noticed it yesterday.

[...]

>>
>> 1) We are used to reviewing patches in our email clients and prefer it
>>to reviews in web-based tools.  I have quite a lot of customizations
>>in place that I am used to and so prefer it to
>>one-method-fits-everyone web tools.
>>
> I understand. This kind of information is exactly what I wanted to know so
> I can adjust my work process to fit the community needs. My I follow the
> above process of making PR but also create a patch using 'git diff' command
> and share that with the mailing list?

yeah, sure, although I think people usually use git format-patch.

>
>>
>> 2) Do not spend too much time thinking about how to organize the
>>project.  The time is better spent actually thinking about the
>>project itself, particularly because I expect this one to entail a
>>lot of experimenting with an occasional dead end.
>>
> I understand. I just thought this discussion belonged to me getting to know
> how to work with the community and therefore fit the community bonding
> period theme. I am very excited to get to actually work, too.
>
>>
>> >> Having said that, if you'd like to do a hangouts video call to say hello
>> >> to each other and perhaps to discuss some issues with setting up your
>> >> work, I personally am definitely happy to do that too.  As a regular
>> >> communication tool, I did not find videoconferencing to be very useful
>> >> in the past (but I guess I can be persuaded to try again).
>> >
>> > Hmm. In my last coop that ended during pandemic, we used the video
>> > conferencing tool to do daily stand-ups so the team can keep tabs on how
>> > different parts of the project is going and give suggestions as needed. A
>> > little off-topic, but how often would you like to discuss my progress of
>> > the project?
>>
>> So... ideally the stream of emails discussing the overall approach,
>> followed by a stream of patches and reviews would make it completely
>> unnecessary to ask you for some kind of regular status reports.
>> Nevertheless, if some task takes you more than a 4-5 work-days in which
>> you don't get back to us, please send us a quick summary of what you
>> have been working on.  This arrangement of course means that you need to
>> reach out to us if you believe you are stuck, so please do.
>>
>> But let me reiterate that I am willing to try a videoconference or two
>> if you think it would be useful at any point.
>>
> Would it be nice to have a face-to-face conversation perhaps in the first
> week of June? Perhaps open to any interested community member to discuss
> the beginnings of the OMPD?

OK, so me not noticing the email made that impossible, I'm afraid.  But
let's try the 2nd week.  Feel free to offer a suitable time.  I plan to
ping Jakub on IRC tomorrow and see if/when he'd be willing to attend.

>>
>> No, GCC, the compiler, reads C and then goes through various stages of
>> intermediate representations of the C code, one of which is gimple,
>> optimizes it and produces an assembly.
>>
>> If that C file contains OpenMP directives (and you compile with
>> -fopenmp) many of those are converted in one way or another into calls
>> into the "GNU offloading and multi-processing (run-time) library:"
>> libgomp.  It used to be just GNU OpenMP library but now it is also the
>> run-time library for OpenACC.
>>
>> For example, #pragma omp parallel is compiled in a way that the body of
>> the construct is outlined into a special artificial function and the
>> construct itself is compiled into a call to a function GOMP_parallel,
>> with a reference to the function with the body passed in one of the
>> parameters.  In gimple optimized dump, the function is called
>> __builtin_GOMP_parallel which I admit is slightly confusing, but it is
>> the same thing - and the concept should be well visible in the dump.
>>
>> GOMP_parallel is a function in libgomp.  Grep-ing for it in the libgomp
>> subdirectory finds it in parallel.c.  From the dump you should have good
>> idea what it receives in its parameters.  Reading a large chunk of
>> libgomp source code starting there - and perhaps at other such entry
>> points - is probably a good idea.
>>
>
> I think I will study the libgomp library first week of June. I will keep
> the above in mind as I look over the code. Now that I have more
> understanding of OMPD, I aim to find relevant functions that I could use
> for OMPD.
>
>
>> > I skimmed through the documentation to familiarize with the interface. I
>> > would have to read more on it as I go through the development.
>> > I also looked at the clang project. I could see how some of the document
>> > was used to creat