Re: GIMPLE problem
On Wed, Jun 24, 2020 at 1:36 AM Gary Oblock via Gcc wrote:
>
> I'm somehow misusing GIMPLE (probably in multiple ways) and I need
> some help in straightening out this little mess I've made.
>
> I'm trying to do the following:
>
> In an attempt at structure reorganization (instance interleaving) an
> array of structures is being transformed into a structure of arrays.
>
> for the simple example I'm using
> typedef struct type type_t;
> struct type {
> double x;
> double y;
> };
> .
> .
> type_t *data = (type_t *)malloc( len * sizeof(type_t));
> .
> .
> result = data[i].y;
>
> Is transformed into this or something close to it
>
> typedef long _reorg_SP_ptr_type_type_t
> typedef struct _reorg_base_type_type_t _reorg_base_type_type_t
>
> struct _reorg_base_type_type_t {
> double *x;
> double *y;
> };
>
> _reorg_SP_ptr_type_type_t data;
>
> _reorg_base_type_type_t _reorg_base_var_type_t;
>
> // Note I'm ignoring a bunch of stuff that needs to happen
> // when a malloc fails..
> _reorg_base_var_type_t.x = (double*)malloc( len*sizeof(double));
> _reorg_base_var_type_t.y = (double*)malloc( len*sizeof(double));
>
> data = 0;
> .
> .
> double *temp = _reorg_base_var_type_t.y;
> result = temp[i];
>
> Now, believe it or not the the whole bit above, except for "result =
> data[i].y",
> seems to work just fine.
>
> I attempted to do this (result = data[i].y) via basically two different
> ways. One is using ARRAY_REF and in the other faking an array access with
> INDIRECT_REF. The first approach chokes on the fact that temp is a pointer
> and the second dies in ssa operand scanning because it doesn't have a case
> for INDIRECT_REF.
On GIMPLE there's no INDIRECT_REF but you have to use a MEM_REF
instead. I'd use an ARRAY_REF and what you need to build is, in
-fdump-tree-XYZ-gimple (aka GIMPLE frontend) syntax:
temp_2 = _reorg_base_var_type_t.y;
result_3 = __MEM (temp_2)[i_4];
so for the ARRAY_REF you have to dereference temp but view it as
array type double[]. That is, the TREE_TYPE of the MEM_REF you
build should be the array type. You can build an array type from
the component type via build_array_type (component_type, NULL_TREE)/
> The code below shows both ways. What have I done wrong here and what to
> I need to do differently to get it to work?
>
> Thanks,
>
> Gary
>
> PS Please ignore the then case below.
>
>
> gimple_stmt_iterator gsi = gsi_for_stmt( stmt);
>
> // Dump for debugging
> print_gimple_stmt ( stderr, stmt, 0);
>
> tree lhs = gimple_assign_lhs( stmt);
> tree rhs = gimple_assign_rhs1( stmt);
>
> bool ro_on_left = tree_contains_a_reorgtype_p ( lhs, info);
>
> tree ro_side = ro_on_left ? lhs : rhs;
> tree nonro_side = ro_on_left ? rhs : lhs;
>
> switch ( recognize_op ( ro_side, info) ) // "a->f"
>{
>case ReorgOpT_Indirect:
> {
>tree orig_field = TREE_OPERAND( ro_side, 1);
>tree field_type = TREE_TYPE( orig_field);
>tree base = ri->instance_interleave.base;
>
>tree base_field =
>find_coresponding_field ( base, orig_field);
>
>tree base_field_type = TREE_TYPE( base_field);
>
>tree field_val_temp =
> make_temp_ssa_name( field_type, NULL, "field_val_temp");
>
>tree inner_op = TREE_OPERAND( ro_side, 0);
>
>// For either case generate common code:
>
>// field_array = _base.f
>tree field_arry_addr =
>make_temp_ssa_name( base_field_type, NULL, "field_arry_addr");
>
>tree rhs_faa = build3 ( COMPONENT_REF,
> //base_field_type, // This doesn't work
> ptr_type_node, // This seems bogus
> base,
> //base_field, // This doesn't work
> orig_field, // This seems bogus
> NULL_TREE);
>
>// Use this to access the array of element.
>gimple *get_field_arry_addr =
>gimple_build_assign( field_arry_addr, rhs_faa);
>
> // index = a
> tree index =
> make_temp_ssa_name( ri->pointer_rep, NULL, "index");
> gimple *get_index =
> gimple_build_assign( index, inner_op);
>
> gimple *temp_set;
> gimple *final_set;
>
> #if WITH_INDIRECT
> // offset = index * size_of_field
> tree size_of_field = TYPE_SIZE_UNIT ( base_field_type);
> tree offset = make_temp_ssa_name( sizetype, NULL, "offset");
>
> gimple *get_offset =
> gimple_build_assign ( offset, MULT_EXPR, index, size_of_field);
>
> // field_addr = field_array + offset
> // bug fix here (TBD) type must be *double not double
> tree field_addr =
> make_te
Re: Automatically generated ChangeLog files - script
On 6/22/20 3:15 PM, Alexandre Oliva wrote:
On May 26, 2020, Martin Liška wrote:
On 5/26/20 12:15 PM, Pierre-Marie de Rodat wrote:
* contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb,
It's not supported right now and it will make the filename parsing
much more complicated.
Hello.
I support the patch:
Another colleague recently run into a problem with either:
* $filename <$case>:
or
* $filename [$condition]:
I can't recall which one it was, but the following patch is supposed to
implement both. Alas, I couldn't figure out how to test it:
git_check_commit.py is failing with:
Traceback (most recent call last):
File "contrib/gcc-changelog/git_check_commit.py", line 38, in
not args.non_strict_mode):
File "/l/tmp/build/gcc/contrib/gcc-changelog/git_repository.py", line 57, in
parse_git_revisions
elif file.renamed_file:
AttributeError: 'Diff' object has no attribute 'renamed_file'
accept and [cond] in ChangeLog
From: Alexandre Oliva
Only '(' and ':' currently terminate file lists in ChangeLog entries
in the ChangeLog parser. This rules out such legitimate entries as:
* filename :
* filename [COND]:
This patch extends the ChangeLog parser to recognize these forms.
for contrib/ChangeLog
* gcc-changelog/git_commit.py: Support CASE and COND.
---
contrib/gcc-changelog/git_commit.py | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/gcc-changelog/git_commit.py
index 4a78793..537c667 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -154,6 +154,7 @@ changelog_regex = re.compile(r'^(?:[fF]or
+)?([a-z0-9+-/]*)ChangeLog:?')
pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$')
dr_regex = re.compile(r'\tDR ([0-9]+)$')
star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
+end_of_location_regex = re.compile(r'[[<(:]')
Please escape the '[':
+end_of_location_regex = re.compile(r'[\[<(:]')
and please a test-case for it.
Thanks,
Martin
LINE_LIMIT = 100
TAB_WIDTH = 8
@@ -203,14 +204,13 @@ class ChangeLogEntry:
line = m.group('content')
if in_location:
-# Strip everything that is not a filename in "line": entities
-# "(NAME)", entry text (the colon, if present, and anything
-# that follows it).
-if '(' in line:
-line = line[:line.index('(')]
-in_location = False
-if ':' in line:
-line = line[:line.index(':')]
+# Strip everything that is not a filename in "line":
+# entities "(NAME)", cases "", conditions
+# "[COND]", entry text (the colon, if present, and
+# anything that follows it).
+m = end_of_location_regex.search(line)
+if m:
+line = line[:m.start()]
in_location = False
# At this point, all that's left is a list of filenames
[PATCH v2 1/5] gcc-plugins/stackleak: Don't instrument itself
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 Acked-by: Kees Cook --- kernel/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/Makefile b/kernel/Makefile index f3218bc5ec69..155b5380500a 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -125,6 +125,7 @@ obj-$(CONFIG_WATCH_QUEUE) += watch_queue.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 KCSAN_SANITIZE_stackleak.o := n -- 2.25.4
[PATCH v2 0/5] Improvements of the stackleak gcc plugin
This is the v2 of the patch series with various improvements of the stackleak gcc plugin. The first three patches disable unneeded gcc plugin instrumentation for some files. The fourth patch is the main improvement. It eliminates an unwanted side-effect of kernel code instrumentation performed by stackleak gcc plugin. This patch is a deep reengineering of the idea described on grsecurity blog: https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction The final patch adds 'verbose' stackleak parameter for printing additional info about the kernel code instrumentation during kernel building. 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 Changes from v1: - rebase onto 5.8.0-rc2; - don't exclude alloca() from the instrumentation logic, because it will be used in kernel stack offset randomization; - reorder patches in the series; - don't use gcc plugins for building vgettimeofday.c in arm and arm64 vDSO; - follow alphabetic order in include/linux/compiler_attributes.h. Link to v1: https://lore.kernel.org/lkml/20200604134957.505389-1-alex.po...@linux.com/ Alexander Popov (5): gcc-plugins/stackleak: Don't instrument itself ARM: vdso: Don't use gcc plugins for building vgettimeofday.c arm64: vdso: Don't use gcc plugins for building vgettimeofday.c gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving gcc-plugins/stackleak: Add 'verbose' plugin parameter arch/arm/vdso/Makefile | 2 +- arch/arm64/kernel/vdso/Makefile| 2 +- include/linux/compiler_attributes.h| 13 ++ kernel/Makefile| 1 + kernel/stackleak.c | 16 +- scripts/Makefile.gcc-plugins | 2 + scripts/gcc-plugins/stackleak_plugin.c | 248 + 7 files changed, 239 insertions(+), 45 deletions(-) -- 2.25.4
[PATCH v2 3/5] arm64: vdso: Don't use gcc plugins for building vgettimeofday.c
Don't use gcc plugins for building arch/arm64/kernel/vdso/vgettimeofday.c to avoid unneeded instrumentation. Signed-off-by: Alexander Popov --- arch/arm64/kernel/vdso/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile index 556d424c6f52..0f1ad63b3326 100644 --- a/arch/arm64/kernel/vdso/Makefile +++ b/arch/arm64/kernel/vdso/Makefile @@ -29,7 +29,7 @@ ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \ ccflags-y := -fno-common -fno-builtin -fno-stack-protector -ffixed-x18 ccflags-y += -DDISABLE_BRANCH_PROFILING -CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) +CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) $(GCC_PLUGINS_CFLAGS) KBUILD_CFLAGS += $(DISABLE_LTO) KASAN_SANITIZE := n UBSAN_SANITIZE := n -- 2.25.4
[PATCH v2 2/5] ARM: vdso: Don't use gcc plugins for building vgettimeofday.c
Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to avoid unneeded instrumentation. Signed-off-by: Alexander Popov --- arch/arm/vdso/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile index d3c9f03e7e79..a54f70731d9f 100644 --- a/arch/arm/vdso/Makefile +++ b/arch/arm/vdso/Makefile @@ -29,7 +29,7 @@ CPPFLAGS_vdso.lds += -P -C -U$(ARCH) CFLAGS_REMOVE_vdso.o = -pg # Force -O2 to avoid libgcc dependencies -CFLAGS_REMOVE_vgettimeofday.o = -pg -Os +CFLAGS_REMOVE_vgettimeofday.o = -pg -Os $(GCC_PLUGINS_CFLAGS) ifeq ($(c-gettimeofday-y),) CFLAGS_vgettimeofday.o = -O2 else -- 2.25.4
[PATCH v2 5/5] gcc-plugins/stackleak: Add 'verbose' plugin parameter
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 | 47 +++---
1 file changed, 42 insertions(+), 5 deletions(-)
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index a18b0d4af456..48e141e07956 100644
--- a/scripts/gcc-plugins/stackleak_plugin.c
+++ b/scripts/gcc-plugins/stackleak_plugin.c
@@ -34,6 +34,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
@@ -46,6 +48,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, bool after)
@@ -102,6 +105,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;
}
@@ -195,6 +202,11 @@ static unsigned int stackleak_instrument_execute(void)
if (!is_alloca(stmt))
continue;
+ if (verbose) {
+ fprintf(stderr, "stackleak: be careful,
alloca() in %s()\n",
+
DECL_NAME_POINTER(current_function_decl));
+ }
+
/* Insert stackleak_track_stack() call after alloca() */
add_stack_tracking(&gsi, true);
if (bb == entry_bb)
@@ -384,13 +396,31 @@ 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;
- if (cfun->calls_alloca)
+ /*
+* Leave stack tracking in functions that call alloca().
+* Additional case:
+* 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 in fact don't use alloca().
+* For more info see gcc commit 7072df0aae0c59ae437e.
+* Let's leave such functions instrumented as well.
+*/
+ if (cfun->calls_alloca) {
+ if (verbose)
+ fprintf(stderr, "stackleak: instrument %s():
calls_alloca\n", fn);
return 0;
+ }
- if (large_stack_frame())
+ /* Leave stack tracking in functions with 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();
@@ -516,9 +546,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'"),
@@ -541,6 +568,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);
@@ -548,6 +579,12 @@ __visible int plugin_init(struct plugin_name_args
*plugin_info,
}
}
+ if (disable) {
+ if (verbose)
+ fpr
[PATCH v2 4/5] gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving
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
Acked-by: Miguel Ojeda
---
include/linux/compiler_attributes.h| 13 ++
kernel/stackleak.c | 16 +-
scripts/Makefile.gcc-plugins | 2 +
scripts/gcc-plugins/stackleak_plugin.c | 205 +
4 files changed, 196 insertions(+), 40 deletions(-)
diff --git a/include/linux/compiler_attributes.h
b/include/linux/compiler_attributes.h
index cdf016596659..551ea8cb70b1 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -37,6 +37,7 @@
# define __GCC4_has_attribute___copy__0
# define __GCC4_has_attribute___designated_init__ 0
# define __GCC4_has_attribute___externally_visible__ 1
+# define __GCC4_has_attribute___no_caller_saved_registers__ 0
# define __GCC4_has_attribute___noclone__ 1
# define __GCC4_has_attribute___nonstring__ 0
# define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
@@ -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.
-
Re: [PATCH v2 3/5] arm64: vdso: Don't use gcc plugins for building vgettimeofday.c
On Wed, Jun 24, 2020 at 03:33:28PM +0300, Alexander Popov wrote: > Don't use gcc plugins for building arch/arm64/kernel/vdso/vgettimeofday.c > to avoid unneeded instrumentation. > > Signed-off-by: Alexander Popov > --- > arch/arm64/kernel/vdso/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile > index 556d424c6f52..0f1ad63b3326 100644 > --- a/arch/arm64/kernel/vdso/Makefile > +++ b/arch/arm64/kernel/vdso/Makefile > @@ -29,7 +29,7 @@ ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 > --hash-style=sysv \ > ccflags-y := -fno-common -fno-builtin -fno-stack-protector -ffixed-x18 > ccflags-y += -DDISABLE_BRANCH_PROFILING > > -CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) > +CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) > $(GCC_PLUGINS_CFLAGS) > KBUILD_CFLAGS+= $(DISABLE_LTO) > KASAN_SANITIZE := n > UBSAN_SANITIZE := n > -- > 2.25.4 I'll pick this one up as a fix for 5.8, please let me know if that's a problem. Will
Re: [PATCH v2 2/5] ARM: vdso: Don't use gcc plugins for building vgettimeofday.c
On Wed, Jun 24, 2020 at 03:33:27PM +0300, Alexander Popov wrote: > Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to > avoid unneeded instrumentation. > > Signed-off-by: Alexander Popov But why is skipping it safe? Luis
Re: [PATCH v2 5/5] gcc-plugins/stackleak: Add 'verbose' plugin parameter
On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote: > 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 Would be nice if we instead could pass an argument to make which lets us enable this. Luis
Re: [PATCH v2 2/5] ARM: vdso: Don't use gcc plugins for building vgettimeofday.c
On 24.06.2020 15:52, Luis Chamberlain wrote: > On Wed, Jun 24, 2020 at 03:33:27PM +0300, Alexander Popov wrote: >> Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to >> avoid unneeded instrumentation. >> >> Signed-off-by: Alexander Popov > > But why is skipping it safe? Hello Luis, Kees and Will discussed that in detail in v1 of the series: https://lore.kernel.org/lkml/20200610073046.GA15939@willie-the-truck/ Best regards, Alexander
Re: [PATCH v2 5/5] gcc-plugins/stackleak: Add 'verbose' plugin parameter
On 24.06.2020 15:53, Luis Chamberlain wrote: > On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote: >> 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 > > Would be nice if we instead could pass an argument to make which lets > us enable this. This feature is useful only for debugging stackleak gcc plugin. The cflag that enables it is similar to -fplugin-arg-structleak_plugin-verbose, which is used for debugging the structleak plugin. This debugging feature clutters the kernel build output, I don't think that many people will use it. So IMO creating a separate argument for make is not really needed. Thanks! Best regards, Alexander
Re: [PATCH v2 0/5] Improvements of the stackleak gcc plugin
On Wed, 24 Jun 2020 15:33:25 +0300, Alexander Popov wrote: > This is the v2 of the patch series with various improvements of the > stackleak gcc plugin. > > The first three patches disable unneeded gcc plugin instrumentation for > some files. > > The fourth patch is the main improvement. It eliminates an unwanted > side-effect of kernel code instrumentation performed by stackleak gcc > plugin. This patch is a deep reengineering of the idea described on > grsecurity blog: > https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction > > [...] Applied to arm64 (for-next/fixes), thanks! [1/1] arm64: vdso: Don't use gcc plugins for building vgettimeofday.c https://git.kernel.org/arm64/c/e56404e8e475 Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev
Re: [PATCH v2 5/5] gcc-plugins/stackleak: Add 'verbose' plugin parameter
On Wed, Jun 24, 2020 at 04:09:20PM +0300, Alexander Popov wrote: > On 24.06.2020 15:53, Luis Chamberlain wrote: > > On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote: > >> 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 > > > > Would be nice if we instead could pass an argument to make which lets > > us enable this. > > This feature is useful only for debugging stackleak gcc plugin. > > The cflag that enables it is similar to > -fplugin-arg-structleak_plugin-verbose, > which is used for debugging the structleak plugin. > > This debugging feature clutters the kernel build output, I don't think that > many > people will use it. So IMO creating a separate argument for make is not really > needed. Yup, agreed. The precedent for plugin verbosity is via CONFIGs. They're not really general purpose enough to justify a "make" argument. -- Kees Cook
Re: [PATCH v2 3/5] arm64: vdso: Don't use gcc plugins for building vgettimeofday.c
On Wed, Jun 24, 2020 at 03:33:28PM +0300, Alexander Popov wrote: > Don't use gcc plugins for building arch/arm64/kernel/vdso/vgettimeofday.c > to avoid unneeded instrumentation. > > Signed-off-by: Alexander Popov It looks like Will has taken this already, but: Acked-by: Kees Cook -- Kees Cook
Re: [PATCH v2 1/5] gcc-plugins/stackleak: Don't instrument itself
On Wed, Jun 24, 2020 at 03:33:26PM +0300, Alexander Popov wrote: > 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 > Acked-by: Kees Cook Thanks! Applied to for-next/gcc-plugins. -- Kees Cook
Re: [PATCH v2 2/5] ARM: vdso: Don't use gcc plugins for building vgettimeofday.c
On Wed, Jun 24, 2020 at 03:33:27PM +0300, Alexander Popov wrote: > Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to > avoid unneeded instrumentation. > > Signed-off-by: Alexander Popov Applied to for-next/gcc-plugins. -- Kees Cook
Re: [PATCH v2 5/5] gcc-plugins/stackleak: Add 'verbose' plugin parameter
On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote: > 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 Applied to for-next/gcc-plugins. -- Kees Cook
Re: GIMPLE problem
Richard, First off I did suspect INDIRECT_REF wasn't supported, thanks for confirming that. I tried what you said in the original code before I posted but I suspect how I went at it is the problem. I'm probably doing something(s) in a glaringly stupid way. Can you spot it, because everything I'm doing makes total sense to me? Thanks Gary -- Snippet from the code with MEM_REF: tree lhs_ref = build1 ( MEM_REF, field_type, field_addr); final_set = gimple_build_assign( lhs_ref, field_val_temp); field_type is a double * field_addr is an address within an malloced array of doubles. -- Snippet from the code with ARRAY_REF: tree rhs_ref = build4 ( ARRAY_REF, field_type, field_arry_addr, index, NULL_TREE, NULL_TREE); temp_set = gimple_build_assign( field_val_temp, rhs_ref); field type is double field_arry_addr is the starting address of an array of malloced doubles. index is a pointer_rep (an integer) details: tree pointer_rep = make_node ( INTEGER_TYPE); TYPE_PRECISION (pointer_rep) = TYPE_PRECISION (pointer_sized_int_node);
Modula-2 into the GCC tree on master?
Hello GCC Steering Committee and fellow GCC developers, I was wondering whether now might be a sensible time to graft GNU Modula-2 into the GCC tree? (on the master branch only). At present gm2 fully implements PIM2, PIM3, PIM4 and ISO dialects of Modula-2. All the ISO libraries are implemented - there are a number of PIM libraries as well. There are also no extra failures on master branch for other languages when Modula-2 is introduced. Since last year all non GPL3 material has been purged, the Ulm libraries removed (which were GPL2) and libpth removed. All dependent code (coroutines) replaced by functionally equivalent modules using libatomic. Multilib libraries are built and gm2 works with lto. All code is now GPL3 or GPL3.1 with GCC runtime exemption (libraries). It comes with a testsuite using dejagnu. gm2 builds and runs on i386, amd64, powerpc64le, aarch64 and thanks to Matthias Klose there are gm2 Debian packages on https://packages.debian.org/bullseye/gm2 with a few more architectures. Currently gm2 is tracking the GCC development model, there are branches open for [gm2-4, gm2-6, gm2-8, gm2-9, gm2-10], and gm2-master. (Although the branches in [] < 10 are not all GPL3 compliant and/or require libpth). The gm2 front code is currently in git on Savannah: git clone https://git.savannah.nongnu.org/git/gm2.git and there is a nightly automatic rebase of gm2 onto GCC which is available from: git clone http://floppsie.comp.glam.ac.uk/gm2 gm2-floppsie [See http://www.nongnu.org/gm2/development.html]. which contains the above branches and GCC. The gm2-master branch (on the floppsie git repro) passes all regressions (on aarch64 and there is one failure on amd64 - which I will fix after sending this email). It perhaps might be useful to have yet another language with a regression testsuite even if just as a canary in the coal mine for various architectures, maybe? There are a few patches required to non m2 directories. A number of these have been posted before and reviewed twice by Richard Sandiford and Joseph Myers. (For reference https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg225115.html). I've made the suggested changes and the latest patches to be applied can be found here: http://git.savannah.nongnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/m2/patches/gcc/trunk The git sources can be browsed at: http://git.savannah.nongnu.org/cgit/gm2.git/tree/gcc-versionno using the master branch. When the patches are applied it would look like the gm2-master branch on floppsie.comp.glam.ac.uk. Anyway from my perspective I'd be very happy to see the master branch reside in GCC :-) and was wondering if this is a good time? regards, Gaius
Re: Modula-2 into the GCC tree on master?
Hi, Gaius Thanks for your diligent effort to complete this port of Modula-2 and prepare it for inclusion in GCC. I have forwarded the proposal to the GCC Steering Committee. Thanks, David On Wed, Jun 24, 2020 at 5:03 PM Gaius Mulley via Gcc wrote: > > > Hello GCC Steering Committee and fellow GCC developers, > > I was wondering whether now might be a sensible time to graft GNU > Modula-2 into the GCC tree? (on the master branch only). At present > gm2 fully implements PIM2, PIM3, PIM4 and ISO dialects of Modula-2. All > the ISO libraries are implemented - there are a number of PIM libraries > as well. There are also no extra failures on master branch for other > languages when Modula-2 is introduced. > > Since last year all non GPL3 material has been purged, the Ulm libraries > removed (which were GPL2) and libpth removed. All dependent code > (coroutines) replaced by functionally equivalent modules using > libatomic. Multilib libraries are built and gm2 works with lto. All > code is now GPL3 or GPL3.1 with GCC runtime exemption (libraries). It > comes with a testsuite using dejagnu. gm2 builds and runs on i386, > amd64, powerpc64le, aarch64 and thanks to Matthias Klose there are gm2 > Debian packages on https://packages.debian.org/bullseye/gm2 with a few > more architectures. > > Currently gm2 is tracking the GCC development model, there are branches > open for [gm2-4, gm2-6, gm2-8, gm2-9, gm2-10], and gm2-master. > (Although the branches in [] < 10 are not all GPL3 compliant and/or > require libpth). > > The gm2 front code is currently in git on Savannah: > >git clone https://git.savannah.nongnu.org/git/gm2.git > > and there is a nightly automatic rebase of gm2 onto GCC which is > available from: > >git clone http://floppsie.comp.glam.ac.uk/gm2 gm2-floppsie > >[See http://www.nongnu.org/gm2/development.html]. > > which contains the above branches and GCC. The gm2-master branch (on > the floppsie git repro) passes all regressions (on aarch64 and there is > one failure on amd64 - which I will fix after sending this email). It > perhaps might be useful to have yet another language with a regression > testsuite even if just as a canary in the coal mine for various > architectures, maybe? > > There are a few patches required to non m2 directories. A number of > these have been posted before and reviewed twice by Richard Sandiford > and Joseph Myers. (For reference > https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg225115.html). > I've made the suggested changes and the latest patches to be applied can > be found here: > > > http://git.savannah.nongnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/m2/patches/gcc/trunk > > The git sources can be browsed at: > >http://git.savannah.nongnu.org/cgit/gm2.git/tree/gcc-versionno > > using the master branch. When the patches are applied it would look > like the gm2-master branch on floppsie.comp.glam.ac.uk. > > Anyway from my perspective I'd be very happy to see the master > branch reside in GCC :-) and was wondering if this is a good time? > > regards, > Gaius
