| Message ID | 20200522075207.157349-1-elver@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] kasan: Disable branch tracing for core runtime | expand |
On Fri, 22 May 2020 09:52:07 +0200 Marco Elver <elver@google.com> wrote: > During early boot, while KASAN is not yet initialized, it is possible to > enter reporting code-path and end up in kasan_report(). While > uninitialized, the branch there prevents generating any reports, > however, under certain circumstances when branches are being traced > (TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel > reboots without warning. > > To prevent similar issues in future, we should disable branch tracing > for the core runtime. > > Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/ > Reported-by: kernel test robot <rong.a.chen@intel.com> > Signed-off-by: Marco Elver <elver@google.com> I assume this affects 5.6 and perhaps earlier kernels? I also assume that a cc:stable is appropriate for this fix?
On Sat, 23 May 2020 at 01:42, Andrew Morton <akpm@linux-foundation.org> wrote: > > On Fri, 22 May 2020 09:52:07 +0200 Marco Elver <elver@google.com> wrote: > > > During early boot, while KASAN is not yet initialized, it is possible to > > enter reporting code-path and end up in kasan_report(). While > > uninitialized, the branch there prevents generating any reports, > > however, under certain circumstances when branches are being traced > > (TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel > > reboots without warning. > > > > To prevent similar issues in future, we should disable branch tracing > > for the core runtime. > > > > Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/ > > Reported-by: kernel test robot <rong.a.chen@intel.com> > > Signed-off-by: Marco Elver <elver@google.com> > > I assume this affects 5.6 and perhaps earlier kernels? > > I also assume that a cc:stable is appropriate for this fix? Yes, it does. On the other hand, the workaround is simple enough (disable any kind of branch profiling). Note, the patch won't cleanly apply to 5.6 and early without this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a16c09edc58982d56c49ab577fdcdf830fbc3a5 Thanks, -- Marco
diff --git a/mm/kasan/Makefile b/mm/kasan/Makefile index 434d503a6525..de3121848ddf 100644 --- a/mm/kasan/Makefile +++ b/mm/kasan/Makefile @@ -15,14 +15,14 @@ CFLAGS_REMOVE_tags_report.o = $(CC_FLAGS_FTRACE) # Function splitter causes unnecessary splits in __asan_load1/__asan_store1 # see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533 -CFLAGS_common.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -CFLAGS_generic.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -CFLAGS_generic_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -CFLAGS_init.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -CFLAGS_quarantine.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -CFLAGS_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -CFLAGS_tags.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -CFLAGS_tags_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) +CFLAGS_common.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING +CFLAGS_generic.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING +CFLAGS_generic_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING +CFLAGS_init.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING +CFLAGS_quarantine.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING +CFLAGS_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING +CFLAGS_tags.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING +CFLAGS_tags_report.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) -DDISABLE_BRANCH_PROFILING obj-$(CONFIG_KASAN) := common.o init.o report.o obj-$(CONFIG_KASAN_GENERIC) += generic.o generic_report.o quarantine.o diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c index 56ff8885fe2e..098a7dbaced6 100644 --- a/mm/kasan/generic.c +++ b/mm/kasan/generic.c @@ -15,7 +15,6 @@ */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#define DISABLE_BRANCH_PROFILING #include <linux/export.h> #include <linux/interrupt.h> diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c index 25b7734e7013..8a959fdd30e3 100644 --- a/mm/kasan/tags.c +++ b/mm/kasan/tags.c @@ -12,7 +12,6 @@ */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#define DISABLE_BRANCH_PROFILING #include <linux/export.h> #include <linux/interrupt.h>
During early boot, while KASAN is not yet initialized, it is possible to enter reporting code-path and end up in kasan_report(). While uninitialized, the branch there prevents generating any reports, however, under certain circumstances when branches are being traced (TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel reboots without warning. To prevent similar issues in future, we should disable branch tracing for the core runtime. Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/ Reported-by: kernel test robot <rong.a.chen@intel.com> Signed-off-by: Marco Elver <elver@google.com> --- v2: * Remove duplicate DISABLE_BRANCH_PROFILING from tags.c as reported by Qian Cai. --- mm/kasan/Makefile | 16 ++++++++-------- mm/kasan/generic.c | 1 - mm/kasan/tags.c | 1 - 3 files changed, 8 insertions(+), 10 deletions(-)