* [PATCH 21/21] EDAC, Documentation: Describe CPER module definition and DIMM ranks
From: Robert Richter @ 2019-05-29 8:44 UTC (permalink / raw)
To: Borislav Petkov, Tony Luck, James Morse, Mauro Carvalho Chehab,
Jonathan Corbet
Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
Robert Richter, linux-doc@vger.kernel.org
In-Reply-To: <20190529084344.28562-1-rrichter@marvell.com>
Update on CPER DIMM naming convention and DIMM ranks.
Signed-off-by: Robert Richter <rrichter@marvell.com>
---
Documentation/admin-guide/ras.rst | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index c7495e42e6f4..4e2a01c77a9c 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -330,9 +330,12 @@ There can be multiple csrows and multiple channels.
.. [#f4] Nowadays, the term DIMM (Dual In-line Memory Module) is widely
used to refer to a memory module, although there are other memory
- packaging alternatives, like SO-DIMM, SIMM, etc. Along this document,
- and inside the EDAC system, the term "dimm" is used for all memory
- modules, even when they use a different kind of packaging.
+ packaging alternatives, like SO-DIMM, SIMM, etc. The UEFI
+ specification (Version 2.7) defines a memory module in the Common
+ Platform Error Record (CPER) section to be an SMBIOS Memory Device
+ (Type 17). Along this document, and inside the EDAC system, the term
+ "dimm" is used for all memory modules, even when they use a
+ different kind of packaging.
Memory controllers allow for several csrows, with 8 csrows being a
typical value. Yet, the actual number of csrows depends on the layout of
@@ -349,12 +352,14 @@ controllers. The following example will assume 2 channels:
| | ``ch0`` | ``ch1`` |
+============+===========+===========+
| ``csrow0`` | DIMM_A0 | DIMM_B0 |
- +------------+ | |
- | ``csrow1`` | | |
+ | | rank0 | rank0 |
+ +------------+ - | - |
+ | ``csrow1`` | rank1 | rank1 |
+------------+-----------+-----------+
| ``csrow2`` | DIMM_A1 | DIMM_B1 |
- +------------+ | |
- | ``csrow3`` | | |
+ | | rank0 | rank0 |
+ +------------+ - | - |
+ | ``csrow3`` | rank1 | rank1 |
+------------+-----------+-----------+
In the above example, there are 4 physical slots on the motherboard
@@ -374,11 +379,13 @@ which the memory DIMM is placed. Thus, when 1 DIMM is placed in each
Channel, the csrows cross both DIMMs.
Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
-Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above
-will have just one csrow (csrow0). csrow1 will be empty. On the other
-hand, when 2 dual ranked DIMMs are similarly placed, then both csrow0
-and csrow1 will be populated. The pattern repeats itself for csrow2 and
-csrow3.
+In the example above 2 dual ranked DIMMs are similarly placed. Thus,
+both csrow0 and csrow1 are populated. On the other hand, when 2 single
+ranked DIMMs are placed in slots DIMM_A0 and DIMM_B0, then they will
+have just one csrow (csrow0) and csrow1 will be empty. The pattern
+repeats itself for csrow2 and csrow3. Also note that some memory
+controller doesn't have any logic to identify the memory module, see
+``rankX`` directories below.
The representation of the above is reflected in the directory
tree in EDAC's sysfs interface. Starting in directory
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Dmitry Vyukov @ 2019-05-29 8:53 UTC (permalink / raw)
To: Mark Rutland
Cc: Marco Elver, Peter Zijlstra, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <20190528165036.GC28492@lakrids.cambridge.arm.com>
On Tue, May 28, 2019 at 6:50 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Tue, May 28, 2019 at 06:32:58PM +0200, Marco Elver wrote:
> > This adds a new header to asm-generic to allow optionally instrumenting
> > architecture-specific asm implementations of bitops.
> >
> > This change includes the required change for x86 as reference and
> > changes the kernel API doc to point to bitops-instrumented.h instead.
> > Rationale: the functions in x86's bitops.h are no longer the kernel API
> > functions, but instead the arch_ prefixed functions, which are then
> > instrumented via bitops-instrumented.h.
> >
> > Other architectures can similarly add support for asm implementations of
> > bitops.
> >
> > The documentation text has been copied/moved, and *no* changes to it
> > have been made in this patch.
> >
> > Tested: using lib/test_kasan with bitops tests (pre-requisite patch).
> >
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198439
> > Signed-off-by: Marco Elver <elver@google.com>
> > ---
> > Documentation/core-api/kernel-api.rst | 2 +-
> > arch/x86/include/asm/bitops.h | 210 ++++----------
> > include/asm-generic/bitops-instrumented.h | 327 ++++++++++++++++++++++
> > 3 files changed, 380 insertions(+), 159 deletions(-)
> > create mode 100644 include/asm-generic/bitops-instrumented.h
>
> [...]
>
> > +#if !defined(BITOPS_INSTRUMENT_RANGE)
> > +/*
> > + * This may be defined by an arch's bitops.h, in case bitops do not operate on
> > + * single bytes only. The default version here is conservative and assumes that
> > + * bitops operate only on the byte with the target bit.
> > + */
> > +#define BITOPS_INSTRUMENT_RANGE(addr, nr) \
> > + (const volatile char *)(addr) + ((nr) / BITS_PER_BYTE), 1
> > +#endif
>
> I was under the impression that logically, all the bitops operated on
> the entire long the bit happend to be contained in, so checking the
> entire long would make more sense to me.
>
> FWIW, arm64's atomic bit ops are all implemented atop of atomic_long_*
> functions, which are instrumented, and always checks at the granularity
> of a long. I haven't seen splats from that when fuzzing with Syzkaller.
>
> Are you seeing bugs without this?
bitops are not instrumented on x86 at all at the moment, so we have
not seen any splats. What we've seen are assorted crashes caused by
previous silent memory corruptions by incorrect bitops :)
Good point. If arm already does this, I guess we also need to check
whole long's.
^ permalink raw reply
* Re: [PATCH 2/3] tools/objtool: add kasan_check_* to uaccess whitelist
From: Dmitry Vyukov @ 2019-05-29 8:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Marco Elver, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <20190528171942.GV2623@hirez.programming.kicks-ass.net>
On Tue, May 28, 2019 at 7:19 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, May 28, 2019 at 06:32:57PM +0200, Marco Elver wrote:
> > This is a pre-requisite for enabling bitops instrumentation. Some bitops
> > may safely be used with instrumentation in uaccess regions.
> >
> > For example, on x86, `test_bit` is used to test a CPU-feature in a
> > uaccess region: arch/x86/ia32/ia32_signal.c:361
>
> That one can easily be moved out of the uaccess region. Any else?
Marco, try to update config with "make allyesconfig" and then build
the kernel without this change.
>
> > Signed-off-by: Marco Elver <elver@google.com>
> > ---
> > tools/objtool/check.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> > index 172f99195726..eff0e5209402 100644
> > --- a/tools/objtool/check.c
> > +++ b/tools/objtool/check.c
> > @@ -443,6 +443,8 @@ static void add_ignores(struct objtool_file *file)
> > static const char *uaccess_safe_builtin[] = {
> > /* KASAN */
> > "kasan_report",
> > + "kasan_check_read",
> > + "kasan_check_write",
> > "check_memory_region",
> > /* KASAN out-of-line */
> > "__asan_loadN_noabort",
> > --
> > 2.22.0.rc1.257.g3120a18244-goog
> >
^ permalink raw reply
* Великденски бонуси
From: Radoslav Dobrev @ 2019-05-29 9:07 UTC (permalink / raw)
To: linux-doc
Здравейте,
съвременното доплащане на храна под формата на ваучери за храна, които могат да бъдат използвани в най-голямата мрежа от заведения за хранене в страната, е инструмент, който ефективно повишава ефективността на персонала.
Изборът на нашите ваучери за храна като форма на социална придобивка са за работодателя не само придобиване на продуктивен и мотивиран екип, но и носят финансови облаги - стойността на изразходваните средства не се облагат с данък.
Радваме се да Ви представим още повече предимства, които бихте получили с ползването на нашите ваучери, като например ползите за служителите Ви и ще Ви разкажа за възможностите при тяхното използване - моля, обадете се.
Радослав Добрев
Head of HR Benefit Team
www.eatforyou.eu
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Marco Elver @ 2019-05-29 9:20 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Mark Rutland, Peter Zijlstra, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Jonathan Corbet,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
the arch/x86 maintainers, Arnd Bergmann, Josh Poimboeuf,
open list:DOCUMENTATION, LKML, linux-arch, kasan-dev
In-Reply-To: <CACT4Y+bV0CczjRWgHQq3kvioLaaKgN+hnYEKCe5wkbdngrm+8g@mail.gmail.com>
On Wed, 29 May 2019 at 10:53, Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, May 28, 2019 at 6:50 PM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Tue, May 28, 2019 at 06:32:58PM +0200, Marco Elver wrote:
> > > This adds a new header to asm-generic to allow optionally instrumenting
> > > architecture-specific asm implementations of bitops.
> > >
> > > This change includes the required change for x86 as reference and
> > > changes the kernel API doc to point to bitops-instrumented.h instead.
> > > Rationale: the functions in x86's bitops.h are no longer the kernel API
> > > functions, but instead the arch_ prefixed functions, which are then
> > > instrumented via bitops-instrumented.h.
> > >
> > > Other architectures can similarly add support for asm implementations of
> > > bitops.
> > >
> > > The documentation text has been copied/moved, and *no* changes to it
> > > have been made in this patch.
> > >
> > > Tested: using lib/test_kasan with bitops tests (pre-requisite patch).
> > >
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198439
> > > Signed-off-by: Marco Elver <elver@google.com>
> > > ---
> > > Documentation/core-api/kernel-api.rst | 2 +-
> > > arch/x86/include/asm/bitops.h | 210 ++++----------
> > > include/asm-generic/bitops-instrumented.h | 327 ++++++++++++++++++++++
> > > 3 files changed, 380 insertions(+), 159 deletions(-)
> > > create mode 100644 include/asm-generic/bitops-instrumented.h
> >
> > [...]
> >
> > > +#if !defined(BITOPS_INSTRUMENT_RANGE)
> > > +/*
> > > + * This may be defined by an arch's bitops.h, in case bitops do not operate on
> > > + * single bytes only. The default version here is conservative and assumes that
> > > + * bitops operate only on the byte with the target bit.
> > > + */
> > > +#define BITOPS_INSTRUMENT_RANGE(addr, nr) \
> > > + (const volatile char *)(addr) + ((nr) / BITS_PER_BYTE), 1
> > > +#endif
> >
> > I was under the impression that logically, all the bitops operated on
> > the entire long the bit happend to be contained in, so checking the
> > entire long would make more sense to me.
> >
> > FWIW, arm64's atomic bit ops are all implemented atop of atomic_long_*
> > functions, which are instrumented, and always checks at the granularity
> > of a long. I haven't seen splats from that when fuzzing with Syzkaller.
> >
> > Are you seeing bugs without this?
>
> bitops are not instrumented on x86 at all at the moment, so we have
> not seen any splats. What we've seen are assorted crashes caused by
> previous silent memory corruptions by incorrect bitops :)
>
> Good point. If arm already does this, I guess we also need to check
> whole long's.
For the default, we decided to err on the conservative side for now,
since it seems that e.g. x86 operates only on the byte the bit is on.
Other architectures that need bitops-instrumented.h may redefine
BITOPS_INSTRUMENT_RANGE.
Let me know what you prefer.
Thanks,
-- Marco
^ permalink raw reply
* [PATCH] ftrace: add simple oneshot function tracer
From: Thomas Preisner @ 2019-05-29 9:31 UTC (permalink / raw)
Cc: linux, Steven Rostedt, Ingo Molnar, Jonathan Corbet, linux-doc,
linux-kernel
The "oneshot" tracer records every address (ip, parent_ip) exactly once.
As a result, "oneshot" can be used to efficiently create kernel function
coverage/usage reports such as in undertaker-tailor[0].
In order to provide this functionality, "oneshot" uses a
configurable hashset for blacklisting already recorded addresses. This
way, no user space application is required to parse the function
tracer's output and to deactivate functions after they have been
recorded once. Additionally, the tracer's output is reduced to a bare
mininum so that it can be passed directly to undertaker-tailor.
Further information regarding this oneshot function tracer can also be
found at [1].
[0]: https://undertaker.cs.fau.de
[1]: https://tpreisner.de/pub/ba-thesis.pdf
Signed-off-by: Thomas Preisner <linux@tpreisner.de>
---
Documentation/trace/ftrace.rst | 7 ++
kernel/trace/Kconfig | 68 ++++++++++
kernel/trace/Makefile | 1 +
kernel/trace/trace.h | 4 +
kernel/trace/trace_entries.h | 13 ++
kernel/trace/trace_oneshot.c | 220 +++++++++++++++++++++++++++++++++
kernel/trace/trace_selftest.c | 38 ++++++
7 files changed, 351 insertions(+)
create mode 100644 kernel/trace/trace_oneshot.c
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index f60079259669..ee56d9f9b246 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -759,6 +759,13 @@ Here is the list of current tracers that may be configured.
unlikely branch is hit and if it was correct in its prediction
of being correct.
+ "oneshot"
+
+ Traces every kernel function and originating address exactly
+ once. For kernel modules the offset together with the module
+ name is printed. As a result, this tracer can be used to
+ efficiently create kernel function coverage/usage reports.
+
"nop"
This is the "trace nothing" tracer. To remove all
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 5d965cef6c77..3b5c2650763a 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -279,6 +279,74 @@ config HWLAT_TRACER
file. Every time a latency is greater than tracing_thresh, it will
be recorded into the ring buffer.
+menuconfig ONESHOT_TRACER
+ bool "Oneshot Function Tracer"
+ default n
+ depends on HAVE_FUNCTION_TRACER
+ select GENERIC_TRACER
+ help
+ This tracer records every function call (and callee) exactly once per
+ cpu. It uses a separate hashtable for each cpu core to keep track of
+ already recorded functions.
+
+ Very useful for efficiently creating kernel function coverage/usage
+ reports. Can also be used for mostly automated kernel-tailoring in
+ conjunction with the undertaker toolchain as this tracer produces
+ significantly less output in comparison to the normal function
+ tracer.
+
+ If unsure, say N.
+
+if ONESHOT_TRACER
+
+config ONESHOT_HASHTABLE_DYNAMIC_ALLOC
+ bool "Dynamic Hashtable Allocation"
+ default y
+ help
+ When this is enabled (default) the oneshot tracer will try to allocate
+ memory for one hashtable per cpu. This method should always work but
+ might not be the most efficient way as vmalloc only allocates a
+ contiguous memory region in the virtual address space instead of the
+ physical one.
+
+ When this is disabled the oneshot tracer will use static allocation to
+ allocate memory for NR_CPUS hashtables. Keep in mind that this will
+ drastically increase the size of the compiled kernel and may even succeed
+ the kernel size restrictions thus failing the build. If that happens you
+ may decrease NR_CPUS to a more fitting value as it is not possible to
+ detect the exact amount of cpu cores beforehand.
+
+ If unsure, say Y.
+
+config ONESHOT_HASHTABLE_BUCKET_COUNT
+ int "Hashtable bucket count"
+ default 24
+ help
+ Sets the hashtable bucket count to be reserved for every cpu core.
+
+ Be aware that this value represents magnitudes of 2 so increasing this
+ number results in a much higher memory usage.
+
+ If unsure, keep the default.
+
+config ONESHOT_HASHTABLE_ELEMENT_COUNT
+ int "Hashtable element count"
+ default 500000
+ help
+ Sets the hashtable element count to be reserved for every cpu core.
+
+ Depending on how many kernel features you have selected it might be
+ useful to increase this number to be able to memorize more already
+ visited function to decrease the generated output.
+
+ Be aware that this number determines a huge amount of memory to be
+ reserved for the hashtables so increasing this will result in a higher
+ memory usage.
+
+ If unsure, keep the default.
+
+endif # ONESHOT_TRACER
+
config ENABLE_DEFAULT_TRACERS
bool "Trace process context switches and events"
depends on !GENERIC_TRACER
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index c2b2148bb1d2..25b66b759bd8 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_IRQSOFF_TRACER) += trace_irqsoff.o
obj-$(CONFIG_PREEMPT_TRACER) += trace_irqsoff.o
obj-$(CONFIG_SCHED_TRACER) += trace_sched_wakeup.o
obj-$(CONFIG_HWLAT_TRACER) += trace_hwlat.o
+obj-$(CONFIG_ONESHOT_TRACER) += trace_oneshot.o
obj-$(CONFIG_NOP_TRACER) += trace_nop.o
obj-$(CONFIG_STACK_TRACER) += trace_stack.o
obj-$(CONFIG_MMIOTRACE) += trace_mmiotrace.o
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 005f08629b8b..e1e1d28a2914 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -40,6 +40,7 @@ enum trace_type {
TRACE_BLK,
TRACE_BPUTS,
TRACE_HWLAT,
+ TRACE_ONESHOT,
TRACE_RAW_DATA,
__TRACE_LAST_TYPE,
@@ -398,6 +399,7 @@ extern void __ftrace_bad_type(void);
IF_ASSIGN(var, ent, struct bprint_entry, TRACE_BPRINT); \
IF_ASSIGN(var, ent, struct bputs_entry, TRACE_BPUTS); \
IF_ASSIGN(var, ent, struct hwlat_entry, TRACE_HWLAT); \
+ IF_ASSIGN(var, ent, struct oneshot_entry, TRACE_ONESHOT);\
IF_ASSIGN(var, ent, struct raw_data_entry, TRACE_RAW_DATA);\
IF_ASSIGN(var, ent, struct trace_mmiotrace_rw, \
TRACE_MMIO_RW); \
@@ -828,6 +830,8 @@ extern int trace_selftest_startup_preemptirqsoff(struct tracer *trace,
struct trace_array *tr);
extern int trace_selftest_startup_wakeup(struct tracer *trace,
struct trace_array *tr);
+extern int trace_selftest_startup_oneshot(struct tracer *trace,
+ struct trace_array *tr);
extern int trace_selftest_startup_nop(struct tracer *trace,
struct trace_array *tr);
extern int trace_selftest_startup_branch(struct tracer *trace,
diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
index fc8e97328e54..fbf3c813721f 100644
--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -366,3 +366,16 @@ FTRACE_ENTRY(hwlat, hwlat_entry,
FILTER_OTHER
);
+
+FTRACE_ENTRY(oneshot, oneshot_entry,
+
+ TRACE_ONESHOT,
+
+ F_STRUCT(
+ __field( unsigned long, ip )
+ ),
+
+ F_printk("%lx\n", __entry->ip),
+
+ FILTER_OTHER
+);
diff --git a/kernel/trace/trace_oneshot.c b/kernel/trace/trace_oneshot.c
new file mode 100644
index 000000000000..931925aff20b
--- /dev/null
+++ b/kernel/trace/trace_oneshot.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * oneshot tracer
+ *
+ * Copyright (C) 2019 Thomas Preisner <linux@tpreisner.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/ftrace.h>
+#include <linux/hashtable.h>
+#include <linux/percpu.h>
+
+#include "trace.h"
+#include "trace_output.h"
+
+#ifdef CONFIG_ONESHOT_TRACER
+
+static struct trace_array *oneshot_trace;
+
+struct ip_entry {
+ unsigned long address;
+ struct hlist_node next;
+};
+
+struct oneshot_hashtable {
+ DECLARE_HASHTABLE(functions, CONFIG_ONESHOT_HASHTABLE_BUCKET_COUNT);
+ int size;
+ struct ip_entry elements[CONFIG_ONESHOT_HASHTABLE_ELEMENT_COUNT];
+};
+
+static DEFINE_PER_CPU(struct oneshot_hashtable *, visited);
+#ifndef CONFIG_ONESHOT_HASHTABLE_DYNAMIC_ALLOC
+static oneshot_hashtable visited_functions[NR_CPUS];
+#endif /* CONFIG_ONESHOT_HASHTABLE_DYNAMIC_ALLOC */
+
+
+/*
+ * returns true if value has been inserted or if hashtable is full
+ */
+static inline bool
+oneshot_lookup_and_insert(struct oneshot_hashtable *curr_visited,
+ unsigned long address)
+{
+ struct ip_entry *entry;
+
+ hash_for_each_possible(curr_visited->functions, entry, next, address) {
+ if (entry->address == address)
+ return false;
+ }
+
+ if (curr_visited->size >= CONFIG_ONESHOT_HASHTABLE_ELEMENT_COUNT)
+ return true;
+
+ entry = &curr_visited->elements[curr_visited->size++];
+ entry->address = address;
+
+ hash_add(curr_visited->functions, &entry->next, address);
+
+ return true;
+}
+
+static void trace_oneshot(struct trace_array *tr, unsigned long ip)
+{
+ struct trace_event_call *call = &event_oneshot;
+ struct ring_buffer *buffer = tr->trace_buffer.buffer;
+ struct ring_buffer_event *event;
+ struct oneshot_entry *entry;
+
+ event = trace_buffer_lock_reserve(buffer, TRACE_ONESHOT, sizeof(*entry),
+ 0, 0);
+ if (!event)
+ return;
+
+ entry = ring_buffer_event_data(event);
+ entry->ip = ip;
+
+ if (!call_filter_check_discard(call, entry, buffer, event))
+ trace_buffer_unlock_commit_nostack(buffer, event);
+}
+
+static void
+oneshot_tracer_call(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *op, struct pt_regs *pt_regs)
+{
+ struct trace_array *tr = op->private;
+ struct oneshot_hashtable *curr_visited;
+
+ if (unlikely(!tr->function_enabled))
+ return;
+
+ preempt_disable_notrace();
+ curr_visited = this_cpu_read(visited);
+
+ if (oneshot_lookup_and_insert(curr_visited, ip))
+ trace_oneshot(oneshot_trace, ip);
+
+ if (oneshot_lookup_and_insert(curr_visited, parent_ip))
+ trace_oneshot(oneshot_trace, parent_ip);
+
+ preempt_enable_notrace();
+}
+
+static int start_oneshot_tracer(struct trace_array *tr)
+{
+ int ret;
+
+ if (unlikely(tr->function_enabled))
+ return 0;
+
+ ret = register_ftrace_function(tr->ops);
+ if (!ret)
+ tr->function_enabled = 1;
+
+ return ret;
+}
+
+static void stop_oneshot_tracer(struct trace_array *tr)
+{
+ if (unlikely(!tr->function_enabled))
+ return;
+
+ unregister_ftrace_function(tr->ops);
+ tr->function_enabled = 0;
+}
+
+static int oneshot_trace_init(struct trace_array *tr)
+{
+ int cpu;
+
+ oneshot_trace = tr;
+
+ for_each_possible_cpu(cpu) {
+#ifdef CONFIG_ONESHOT_HASHTABLE_DYNAMIC_ALLOC
+ struct oneshot_hashtable *tmp;
+
+ tmp = vmalloc(sizeof(struct oneshot_hashtable));
+ if (!tmp)
+ return 1;
+
+ per_cpu(visited, cpu) = tmp;
+#else
+ per_cpu(visited, cpu) = &visited_functions[cpu];
+#endif /* CONFIG_ONESHOT_HASHTABLE_DYNAMIC_ALLOC */
+
+ per_cpu(visited, cpu)->size = 0;
+ hash_init(per_cpu(visited, cpu)->functions);
+ }
+
+ ftrace_init_array_ops(tr, oneshot_tracer_call);
+
+ start_oneshot_tracer(tr);
+ return 0;
+}
+
+static void oneshot_trace_reset(struct trace_array *tr)
+{
+ int cpu;
+
+ stop_oneshot_tracer(tr);
+ ftrace_reset_array_ops(tr);
+
+ for_each_possible_cpu(cpu) {
+ vfree(per_cpu(visited, cpu));
+ }
+}
+
+static void oneshot_print_header(struct seq_file *s)
+{
+ // do not print anything!
+}
+
+static enum print_line_t oneshot_print_line(struct trace_iterator *iter)
+{
+ struct trace_seq *s = &iter->seq;
+ struct trace_entry *entry = iter->ent;
+ struct oneshot_entry *field;
+ struct module *mod;
+
+ trace_assign_type(field, entry);
+
+ mod = __module_address(field->ip);
+ if (mod) {
+ unsigned long addr;
+
+ addr = field->ip - (unsigned long) mod->core_layout.base;
+ trace_seq_printf(s, "%lx %s\n", addr, mod->name);
+ } else {
+ trace_seq_printf(s, "%lx\n", field->ip);
+ }
+
+ return trace_handle_return(s);
+}
+
+struct tracer oneshot_tracer __read_mostly = {
+ .name = "oneshot",
+ .init = oneshot_trace_init,
+ .reset = oneshot_trace_reset,
+ .print_header = oneshot_print_header,
+ .print_line = oneshot_print_line,
+#ifdef CONFIG_FTRACE_SELFTEST
+ .selftest = trace_selftest_startup_oneshot,
+#endif
+ .allow_instances = true,
+};
+
+
+__init static int init_oneshot_tracer(void)
+{
+ int ret;
+
+ ret = register_tracer(&oneshot_tracer);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+core_initcall(init_oneshot_tracer);
+#endif /* CONFIG_ONESHOT_TRACER */
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index 69ee8ef12cee..95449ecfaca7 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -1028,6 +1028,44 @@ trace_selftest_startup_preemptirqsoff(struct tracer *trace, struct trace_array *
}
#endif /* CONFIG_IRQSOFF_TRACER && CONFIG_PREEMPT_TRACER */
+#ifdef CONFIG_ONESHOT_TRACER
+__init int
+trace_selftest_startup_oneshot(struct tracer *trace, struct trace_array *tr)
+{
+ unsigned long count;
+ int ret;
+
+ /* make sure msleep has been recorded */
+ msleep(1);
+
+ /* start the tracing */
+ ret = tracer_init(trace, tr);
+ if (ret) {
+ warn_failed_init_tracer(trace, ret);
+ return ret;
+ }
+
+ /* Sleep for a 1/10 of a second */
+ msleep(100);
+
+ /* stop the tracing. */
+ tracing_stop();
+
+ /* check the trace buffer */
+ ret = trace_test_buffer(&tr->trace_buffer, &count);
+
+ trace->reset(tr);
+ tracing_start();
+
+ if (!ret && !count) {
+ printk(KERN_CONT ".. no entries found ..");
+ ret = -1;
+ }
+
+ return ret;
+}
+#endif /* CONFIG_ONESHOT_TRACER */
+
#ifdef CONFIG_NOP_TRACER
int
trace_selftest_startup_nop(struct tracer *trace, struct trace_array *tr)
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 2/3] tools/objtool: add kasan_check_* to uaccess whitelist
From: Marco Elver @ 2019-05-29 9:46 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Peter Zijlstra, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <CACT4Y+ZK5i0r0GSZUOBGGOE0bzumNor1d89W8fvphF6EDqKqHg@mail.gmail.com>
On Wed, 29 May 2019 at 10:55, Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, May 28, 2019 at 7:19 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Tue, May 28, 2019 at 06:32:57PM +0200, Marco Elver wrote:
> > > This is a pre-requisite for enabling bitops instrumentation. Some bitops
> > > may safely be used with instrumentation in uaccess regions.
> > >
> > > For example, on x86, `test_bit` is used to test a CPU-feature in a
> > > uaccess region: arch/x86/ia32/ia32_signal.c:361
> >
> > That one can easily be moved out of the uaccess region. Any else?
>
> Marco, try to update config with "make allyesconfig" and then build
> the kernel without this change.
>
Done. The only instance of the uaccess warning is still in
arch/x86/ia32/ia32_signal.c.
Change the patch to move this access instead? Let me know what you prefer.
Thanks,
-- Marco
^ permalink raw reply
* Re: [PATCH 2/3] tools/objtool: add kasan_check_* to uaccess whitelist
From: Peter Zijlstra @ 2019-05-29 9:58 UTC (permalink / raw)
To: Marco Elver
Cc: Dmitry Vyukov, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <CANpmjNP7nNO36p03_1fksx1O2-MNevHzF7revUwQ3b7+RR0y+w@mail.gmail.com>
On Wed, May 29, 2019 at 11:46:10AM +0200, Marco Elver wrote:
> On Wed, 29 May 2019 at 10:55, Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Tue, May 28, 2019 at 7:19 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Tue, May 28, 2019 at 06:32:57PM +0200, Marco Elver wrote:
> > > > This is a pre-requisite for enabling bitops instrumentation. Some bitops
> > > > may safely be used with instrumentation in uaccess regions.
> > > >
> > > > For example, on x86, `test_bit` is used to test a CPU-feature in a
> > > > uaccess region: arch/x86/ia32/ia32_signal.c:361
> > >
> > > That one can easily be moved out of the uaccess region. Any else?
> >
> > Marco, try to update config with "make allyesconfig" and then build
> > the kernel without this change.
> >
>
> Done. The only instance of the uaccess warning is still in
> arch/x86/ia32/ia32_signal.c.
>
> Change the patch to move this access instead? Let me know what you prefer.
Yes, I think that might be best. The whitelist should be minimal.
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Peter Zijlstra @ 2019-05-29 10:01 UTC (permalink / raw)
To: Marco Elver
Cc: Dmitry Vyukov, Mark Rutland, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <CANpmjNNtjS3fUoQ_9FQqANYS2wuJZeFRNLZUq-ku=v62GEGTig@mail.gmail.com>
On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> For the default, we decided to err on the conservative side for now,
> since it seems that e.g. x86 operates only on the byte the bit is on.
This is not correct, see for instance set_bit():
static __always_inline void
set_bit(long nr, volatile unsigned long *addr)
{
if (IS_IMMEDIATE(nr)) {
asm volatile(LOCK_PREFIX "orb %1,%0"
: CONST_MASK_ADDR(nr, addr)
: "iq" ((u8)CONST_MASK(nr))
: "memory");
} else {
asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
: : RLONG_ADDR(addr), "Ir" (nr) : "memory");
}
}
That results in:
LOCK BTSQ nr, (addr)
when @nr is not an immediate.
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Marco Elver @ 2019-05-29 10:16 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Dmitry Vyukov, Mark Rutland, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <20190529100116.GM2623@hirez.programming.kicks-ass.net>
On Wed, 29 May 2019 at 12:01, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> > For the default, we decided to err on the conservative side for now,
> > since it seems that e.g. x86 operates only on the byte the bit is on.
>
> This is not correct, see for instance set_bit():
>
> static __always_inline void
> set_bit(long nr, volatile unsigned long *addr)
> {
> if (IS_IMMEDIATE(nr)) {
> asm volatile(LOCK_PREFIX "orb %1,%0"
> : CONST_MASK_ADDR(nr, addr)
> : "iq" ((u8)CONST_MASK(nr))
> : "memory");
> } else {
> asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
> : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
> }
> }
>
> That results in:
>
> LOCK BTSQ nr, (addr)
>
> when @nr is not an immediate.
Thanks for the clarification. Given that arm64 already instruments
bitops access to whole words, and x86 may also do so for some bitops,
it seems fine to instrument word-sized accesses by default. Is that
reasonable?
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Peter Zijlstra @ 2019-05-29 10:30 UTC (permalink / raw)
To: Marco Elver
Cc: Dmitry Vyukov, Mark Rutland, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <CANpmjNMvwAny54udYCHfBw1+aphrQmiiTJxqDq7q=h+6fvpO4w@mail.gmail.com>
On Wed, May 29, 2019 at 12:16:31PM +0200, Marco Elver wrote:
> On Wed, 29 May 2019 at 12:01, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> > > For the default, we decided to err on the conservative side for now,
> > > since it seems that e.g. x86 operates only on the byte the bit is on.
> >
> > This is not correct, see for instance set_bit():
> >
> > static __always_inline void
> > set_bit(long nr, volatile unsigned long *addr)
> > {
> > if (IS_IMMEDIATE(nr)) {
> > asm volatile(LOCK_PREFIX "orb %1,%0"
> > : CONST_MASK_ADDR(nr, addr)
> > : "iq" ((u8)CONST_MASK(nr))
> > : "memory");
> > } else {
> > asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
> > : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
> > }
> > }
> >
> > That results in:
> >
> > LOCK BTSQ nr, (addr)
> >
> > when @nr is not an immediate.
>
> Thanks for the clarification. Given that arm64 already instruments
> bitops access to whole words, and x86 may also do so for some bitops,
> it seems fine to instrument word-sized accesses by default. Is that
> reasonable?
Eminently -- the API is defined such; for bonus points KASAN should also
do alignment checks on atomic ops. Future hardware will #AC on unaligned
[*] LOCK prefix instructions.
(*) not entirely accurate, it will only trap when crossing a line.
https://lkml.kernel.org/r/1556134382-58814-1-git-send-email-fenghua.yu@intel.com
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Dmitry Vyukov @ 2019-05-29 10:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Marco Elver, Mark Rutland, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <20190529103010.GP2623@hirez.programming.kicks-ass.net>
On Wed, May 29, 2019 at 12:30 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, May 29, 2019 at 12:16:31PM +0200, Marco Elver wrote:
> > On Wed, 29 May 2019 at 12:01, Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> > > > For the default, we decided to err on the conservative side for now,
> > > > since it seems that e.g. x86 operates only on the byte the bit is on.
> > >
> > > This is not correct, see for instance set_bit():
> > >
> > > static __always_inline void
> > > set_bit(long nr, volatile unsigned long *addr)
> > > {
> > > if (IS_IMMEDIATE(nr)) {
> > > asm volatile(LOCK_PREFIX "orb %1,%0"
> > > : CONST_MASK_ADDR(nr, addr)
> > > : "iq" ((u8)CONST_MASK(nr))
> > > : "memory");
> > > } else {
> > > asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
> > > : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
> > > }
> > > }
> > >
> > > That results in:
> > >
> > > LOCK BTSQ nr, (addr)
> > >
> > > when @nr is not an immediate.
> >
> > Thanks for the clarification. Given that arm64 already instruments
> > bitops access to whole words, and x86 may also do so for some bitops,
> > it seems fine to instrument word-sized accesses by default. Is that
> > reasonable?
>
> Eminently -- the API is defined such; for bonus points KASAN should also
> do alignment checks on atomic ops. Future hardware will #AC on unaligned
> [*] LOCK prefix instructions.
>
> (*) not entirely accurate, it will only trap when crossing a line.
> https://lkml.kernel.org/r/1556134382-58814-1-git-send-email-fenghua.yu@intel.com
Interesting. Does an address passed to bitops also should be aligned,
or alignment is supposed to be handled by bitops themselves?
This probably should be done as a separate config as not related to
KASAN per se. But obviously via the same
{atomicops,bitops}-instrumented.h hooks which will make it
significantly easier.
^ permalink raw reply
* RE: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: David Laight @ 2019-05-29 11:20 UTC (permalink / raw)
To: 'Dmitry Vyukov', Peter Zijlstra
Cc: Marco Elver, Mark Rutland, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <CACT4Y+aVB3jK_M0-2D_QTq=nncVXTsNp77kjSwBwjqn-3hAJmA@mail.gmail.com>
From: Dmitry Vyukov
> Sent: 29 May 2019 11:57
> On Wed, May 29, 2019 at 12:30 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, May 29, 2019 at 12:16:31PM +0200, Marco Elver wrote:
> > > On Wed, 29 May 2019 at 12:01, Peter Zijlstra <peterz@infradead.org> wrote:
> > > >
> > > > On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> > > > > For the default, we decided to err on the conservative side for now,
> > > > > since it seems that e.g. x86 operates only on the byte the bit is on.
> > > >
> > > > This is not correct, see for instance set_bit():
> > > >
> > > > static __always_inline void
> > > > set_bit(long nr, volatile unsigned long *addr)
> > > > {
> > > > if (IS_IMMEDIATE(nr)) {
> > > > asm volatile(LOCK_PREFIX "orb %1,%0"
> > > > : CONST_MASK_ADDR(nr, addr)
> > > > : "iq" ((u8)CONST_MASK(nr))
> > > > : "memory");
> > > > } else {
> > > > asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
> > > > : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
> > > > }
> > > > }
> > > >
> > > > That results in:
> > > >
> > > > LOCK BTSQ nr, (addr)
> > > >
> > > > when @nr is not an immediate.
> > >
> > > Thanks for the clarification. Given that arm64 already instruments
> > > bitops access to whole words, and x86 may also do so for some bitops,
> > > it seems fine to instrument word-sized accesses by default. Is that
> > > reasonable?
> >
> > Eminently -- the API is defined such; for bonus points KASAN should also
> > do alignment checks on atomic ops. Future hardware will #AC on unaligned
> > [*] LOCK prefix instructions.
> >
> > (*) not entirely accurate, it will only trap when crossing a line.
> > https://lkml.kernel.org/r/1556134382-58814-1-git-send-email-fenghua.yu@intel.com
>
> Interesting. Does an address passed to bitops also should be aligned,
> or alignment is supposed to be handled by bitops themselves?
The bitops are defined on 'long []' and it is expected to be aligned.
Any code that casts the argument is likely to be broken on big-endian.
I did a quick grep a few weeks ago and found some very dubious code.
Not all the casts seemed to be on code that was LE only (although
I didn't try to find out what the casts were from).
The alignment trap on x86 could be avoided by only ever requesting 32bit
cycles - and assuming the buffer is always 32bit aligned (eg int []).
But on BE passing an 'int []' is just so wrong ....
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Andrey Ryabinin @ 2019-05-29 11:23 UTC (permalink / raw)
To: Dmitry Vyukov, Peter Zijlstra
Cc: Marco Elver, Mark Rutland, Alexander Potapenko, Andrey Konovalov,
Jonathan Corbet, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, the arch/x86 maintainers, Arnd Bergmann,
Josh Poimboeuf, open list:DOCUMENTATION, LKML, linux-arch,
kasan-dev
In-Reply-To: <CACT4Y+aVB3jK_M0-2D_QTq=nncVXTsNp77kjSwBwjqn-3hAJmA@mail.gmail.com>
On 5/29/19 1:57 PM, Dmitry Vyukov wrote:
> On Wed, May 29, 2019 at 12:30 PM Peter Zijlstra <peterz@infradead.org> wrote:
>>
>> On Wed, May 29, 2019 at 12:16:31PM +0200, Marco Elver wrote:
>>> On Wed, 29 May 2019 at 12:01, Peter Zijlstra <peterz@infradead.org> wrote:
>>>>
>>>> On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
>>>>> For the default, we decided to err on the conservative side for now,
>>>>> since it seems that e.g. x86 operates only on the byte the bit is on.
>>>>
>>>> This is not correct, see for instance set_bit():
>>>>
>>>> static __always_inline void
>>>> set_bit(long nr, volatile unsigned long *addr)
>>>> {
>>>> if (IS_IMMEDIATE(nr)) {
>>>> asm volatile(LOCK_PREFIX "orb %1,%0"
>>>> : CONST_MASK_ADDR(nr, addr)
>>>> : "iq" ((u8)CONST_MASK(nr))
>>>> : "memory");
>>>> } else {
>>>> asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
>>>> : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
>>>> }
>>>> }
>>>>
>>>> That results in:
>>>>
>>>> LOCK BTSQ nr, (addr)
>>>>
>>>> when @nr is not an immediate.
>>>
>>> Thanks for the clarification. Given that arm64 already instruments
>>> bitops access to whole words, and x86 may also do so for some bitops,
>>> it seems fine to instrument word-sized accesses by default. Is that
>>> reasonable?
>>
>> Eminently -- the API is defined such; for bonus points KASAN should also
>> do alignment checks on atomic ops. Future hardware will #AC on unaligned
>> [*] LOCK prefix instructions.
>>
>> (*) not entirely accurate, it will only trap when crossing a line.
>> https://lkml.kernel.org/r/1556134382-58814-1-git-send-email-fenghua.yu@intel.com
>
> Interesting. Does an address passed to bitops also should be aligned,
> or alignment is supposed to be handled by bitops themselves?
>
It should be aligned. This even documented in Documentation/core-api/atomic_ops.rst:
Native atomic bit operations are defined to operate on objects aligned
to the size of an "unsigned long" C data type, and are least of that
size. The endianness of the bits within each "unsigned long" are the
native endianness of the cpu.
> This probably should be done as a separate config as not related to
> KASAN per se. But obviously via the same
> {atomicops,bitops}-instrumented.h hooks which will make it
> significantly easier.
>
Agreed.
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Dmitry Vyukov @ 2019-05-29 11:29 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: Peter Zijlstra, Marco Elver, Mark Rutland, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <377465ba-3b31-31e7-0f9d-e0a5ab911ca4@virtuozzo.com>
On Wed, May 29, 2019 at 1:23 PM Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
> On 5/29/19 1:57 PM, Dmitry Vyukov wrote:
> > On Wed, May 29, 2019 at 12:30 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >>
> >> On Wed, May 29, 2019 at 12:16:31PM +0200, Marco Elver wrote:
> >>> On Wed, 29 May 2019 at 12:01, Peter Zijlstra <peterz@infradead.org> wrote:
> >>>>
> >>>> On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> >>>>> For the default, we decided to err on the conservative side for now,
> >>>>> since it seems that e.g. x86 operates only on the byte the bit is on.
> >>>>
> >>>> This is not correct, see for instance set_bit():
> >>>>
> >>>> static __always_inline void
> >>>> set_bit(long nr, volatile unsigned long *addr)
> >>>> {
> >>>> if (IS_IMMEDIATE(nr)) {
> >>>> asm volatile(LOCK_PREFIX "orb %1,%0"
> >>>> : CONST_MASK_ADDR(nr, addr)
> >>>> : "iq" ((u8)CONST_MASK(nr))
> >>>> : "memory");
> >>>> } else {
> >>>> asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
> >>>> : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
> >>>> }
> >>>> }
> >>>>
> >>>> That results in:
> >>>>
> >>>> LOCK BTSQ nr, (addr)
> >>>>
> >>>> when @nr is not an immediate.
> >>>
> >>> Thanks for the clarification. Given that arm64 already instruments
> >>> bitops access to whole words, and x86 may also do so for some bitops,
> >>> it seems fine to instrument word-sized accesses by default. Is that
> >>> reasonable?
> >>
> >> Eminently -- the API is defined such; for bonus points KASAN should also
> >> do alignment checks on atomic ops. Future hardware will #AC on unaligned
> >> [*] LOCK prefix instructions.
> >>
> >> (*) not entirely accurate, it will only trap when crossing a line.
> >> https://lkml.kernel.org/r/1556134382-58814-1-git-send-email-fenghua.yu@intel.com
> >
> > Interesting. Does an address passed to bitops also should be aligned,
> > or alignment is supposed to be handled by bitops themselves?
> >
>
> It should be aligned. This even documented in Documentation/core-api/atomic_ops.rst:
>
> Native atomic bit operations are defined to operate on objects aligned
> to the size of an "unsigned long" C data type, and are least of that
> size. The endianness of the bits within each "unsigned long" are the
> native endianness of the cpu.
>
>
> > This probably should be done as a separate config as not related to
> > KASAN per se. But obviously via the same
> > {atomicops,bitops}-instrumented.h hooks which will make it
> > significantly easier.
> >
>
> Agreed.
Thanks. I've filed https://bugzilla.kernel.org/show_bug.cgi?id=203751
for checking alignment with all the points and references, so that
it's not lost.
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Peter Zijlstra @ 2019-05-29 12:01 UTC (permalink / raw)
To: David Laight
Cc: 'Dmitry Vyukov', Marco Elver, Mark Rutland,
Andrey Ryabinin, Alexander Potapenko, Andrey Konovalov,
Jonathan Corbet, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, the arch/x86 maintainers, Arnd Bergmann,
Josh Poimboeuf, open list:DOCUMENTATION, LKML, linux-arch,
kasan-dev
In-Reply-To: <a0157a8d778a48b7ba3935f3e6840d30@AcuMS.aculab.com>
On Wed, May 29, 2019 at 11:20:56AM +0000, David Laight wrote:
> From: Dmitry Vyukov
> > Sent: 29 May 2019 11:57
> > Interesting. Does an address passed to bitops also should be aligned,
> > or alignment is supposed to be handled by bitops themselves?
>
> The bitops are defined on 'long []' and it is expected to be aligned.
> Any code that casts the argument is likely to be broken on big-endian.
> I did a quick grep a few weeks ago and found some very dubious code.
> Not all the casts seemed to be on code that was LE only (although
> I didn't try to find out what the casts were from).
>
> The alignment trap on x86 could be avoided by only ever requesting 32bit
> cycles - and assuming the buffer is always 32bit aligned (eg int []).
> But on BE passing an 'int []' is just so wrong ....
Right, but as argued elsewhere, I feel we should clean up the dubious
code instead of enabling it.
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Peter Zijlstra @ 2019-05-29 12:01 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Andrey Ryabinin, Marco Elver, Mark Rutland, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <CACT4Y+ZDmqqM6YW72Q-=kAurta5ctscLT5p=nQJ5y=82yVMq=w@mail.gmail.com>
On Wed, May 29, 2019 at 01:29:51PM +0200, Dmitry Vyukov wrote:
> Thanks. I've filed https://bugzilla.kernel.org/show_bug.cgi?id=203751
> for checking alignment with all the points and references, so that
> it's not lost.
Thanks!
^ permalink raw reply
* Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN
From: Mark Rutland @ 2019-05-29 13:26 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Peter Zijlstra, Marco Elver, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Jonathan Corbet, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
Arnd Bergmann, Josh Poimboeuf, open list:DOCUMENTATION, LKML,
linux-arch, kasan-dev
In-Reply-To: <CACT4Y+aVB3jK_M0-2D_QTq=nncVXTsNp77kjSwBwjqn-3hAJmA@mail.gmail.com>
On Wed, May 29, 2019 at 12:57:15PM +0200, Dmitry Vyukov wrote:
> On Wed, May 29, 2019 at 12:30 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, May 29, 2019 at 12:16:31PM +0200, Marco Elver wrote:
> > > On Wed, 29 May 2019 at 12:01, Peter Zijlstra <peterz@infradead.org> wrote:
> > > >
> > > > On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> > > > > For the default, we decided to err on the conservative side for now,
> > > > > since it seems that e.g. x86 operates only on the byte the bit is on.
> > > >
> > > > This is not correct, see for instance set_bit():
> > > >
> > > > static __always_inline void
> > > > set_bit(long nr, volatile unsigned long *addr)
> > > > {
> > > > if (IS_IMMEDIATE(nr)) {
> > > > asm volatile(LOCK_PREFIX "orb %1,%0"
> > > > : CONST_MASK_ADDR(nr, addr)
> > > > : "iq" ((u8)CONST_MASK(nr))
> > > > : "memory");
> > > > } else {
> > > > asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
> > > > : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
> > > > }
> > > > }
> > > >
> > > > That results in:
> > > >
> > > > LOCK BTSQ nr, (addr)
> > > >
> > > > when @nr is not an immediate.
> > >
> > > Thanks for the clarification. Given that arm64 already instruments
> > > bitops access to whole words, and x86 may also do so for some bitops,
> > > it seems fine to instrument word-sized accesses by default. Is that
> > > reasonable?
> >
> > Eminently -- the API is defined such; for bonus points KASAN should also
> > do alignment checks on atomic ops. Future hardware will #AC on unaligned
> > [*] LOCK prefix instructions.
> >
> > (*) not entirely accurate, it will only trap when crossing a line.
> > https://lkml.kernel.org/r/1556134382-58814-1-git-send-email-fenghua.yu@intel.com
>
> Interesting. Does an address passed to bitops also should be aligned,
> or alignment is supposed to be handled by bitops themselves?
>
> This probably should be done as a separate config as not related to
> KASAN per se. But obviously via the same
> {atomicops,bitops}-instrumented.h hooks which will make it
> significantly easier.
Makes sense to me -- that should be easy to hack into gen_param_check()
in gen-atomic-instrumented.sh, something like:
----
diff --git a/scripts/atomic/gen-atomic-instrumented.sh b/scripts/atomic/gen-atomic-instrumented.sh
index e09812372b17..2f6b8f521e57 100755
--- a/scripts/atomic/gen-atomic-instrumented.sh
+++ b/scripts/atomic/gen-atomic-instrumented.sh
@@ -21,6 +21,13 @@ gen_param_check()
[ ${type#c} != ${type} ] && rw="read"
printf "\tkasan_check_${rw}(${name}, sizeof(*${name}));\n"
+
+ [ "${type#c}" = "v" ] || return
+
+cat <<EOF
+ if (IS_ENABLED(CONFIG_PETERZ))
+ WARN_ON(!IS_ALIGNED(${name}, sizeof(*${name})));
+EOF
}
#gen_param_check(arg...)
----
On arm64 our atomic instructions always perform an alignment check, so
we'd only miss if an atomic op bailed out after a plain READ_ONCE() of
an unaligned atomic variable.
Thanks,
Mark.
^ permalink raw reply related
* [PATCH v2 0/3] ima/evm fixes for v5.2
From: Roberto Sassu @ 2019-05-29 13:30 UTC (permalink / raw)
To: zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, Roberto Sassu
Changelog
v1:
- remove patch 2/4 (evm: reset status in evm_inode_post_setattr()); file
attributes cannot be set if the signature is portable and immutable
- patch 3/4: add __ro_after_init to ima_appraise_req_evm variable
declaration
- patch 3/4: remove ima_appraise_req_evm kernel option and introduce
'enforce-evm' and 'log-evm' as possible values for ima_appraise=
- remove patch 4/4 (ima: only audit failed appraisal verifications)
- add new patch (ima: show rules with IMA_INMASK correctly)
Roberto Sassu (3):
evm: check hash algorithm passed to init_desc()
ima: don't ignore INTEGRITY_UNKNOWN EVM status
ima: show rules with IMA_INMASK correctly
.../admin-guide/kernel-parameters.txt | 3 ++-
security/integrity/evm/evm_crypto.c | 3 +++
security/integrity/ima/ima_appraise.c | 8 +++++++
security/integrity/ima/ima_policy.c | 21 +++++++++++--------
4 files changed, 25 insertions(+), 10 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v2 1/3] evm: check hash algorithm passed to init_desc()
From: Roberto Sassu @ 2019-05-29 13:30 UTC (permalink / raw)
To: zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, Roberto Sassu, stable
In-Reply-To: <20190529133035.28724-1-roberto.sassu@huawei.com>
This patch prevents memory access beyond the evm_tfm array by checking the
validity of the index (hash algorithm) passed to init_desc(). The hash
algorithm can be arbitrarily set if the security.ima xattr type is not
EVM_XATTR_HMAC.
Fixes: 5feeb61183dde ("evm: Allow non-SHA1 digital signatures")
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Cc: stable@vger.kernel.org
---
security/integrity/evm/evm_crypto.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
index e11564eb645b..82a38e801ee4 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -89,6 +89,9 @@ static struct shash_desc *init_desc(char type, uint8_t hash_algo)
tfm = &hmac_tfm;
algo = evm_hmac;
} else {
+ if (hash_algo >= HASH_ALGO__LAST)
+ return ERR_PTR(-EINVAL);
+
tfm = &evm_tfm[hash_algo];
algo = hash_algo_name[hash_algo];
}
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Roberto Sassu @ 2019-05-29 13:30 UTC (permalink / raw)
To: zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, Roberto Sassu, stable
In-Reply-To: <20190529133035.28724-1-roberto.sassu@huawei.com>
Currently, ima_appraise_measurement() ignores the EVM status when
evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a valid
security.ima xattr with type IMA_XATTR_DIGEST or IMA_XATTR_DIGEST_NG,
ima_appraise_measurement() returns INTEGRITY_PASS regardless of the EVM
status. The problem is that the EVM status is overwritten with the
appraisal status.
This patch mitigates the issue by selecting signature verification as the
only method allowed for appraisal when EVM is not initialized. Since the
new behavior might break user space, it must be turned on by adding the
'-evm' suffix to the value of the ima_appraise= kernel option.
Fixes: 2fe5d6def1672 ("ima: integrity appraisal extension")
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Cc: stable@vger.kernel.org
---
Documentation/admin-guide/kernel-parameters.txt | 3 ++-
security/integrity/ima/ima_appraise.c | 8 ++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 138f6664b2e2..d84a2e612b93 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1585,7 +1585,8 @@
Set number of hash buckets for inode cache.
ima_appraise= [IMA] appraise integrity measurements
- Format: { "off" | "enforce" | "fix" | "log" }
+ Format: { "off" | "enforce" | "fix" | "log" |
+ "enforce-evm" | "log-evm" }
default: "enforce"
ima_appraise_tcb [IMA] Deprecated. Use ima_policy= instead.
diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index 5fb7127bbe68..afef06e10fb9 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -18,6 +18,7 @@
#include "ima.h"
+static bool ima_appraise_req_evm __ro_after_init;
static int __init default_appraise_setup(char *str)
{
#ifdef CONFIG_IMA_APPRAISE_BOOTPARAM
@@ -28,6 +29,9 @@ static int __init default_appraise_setup(char *str)
else if (strncmp(str, "fix", 3) == 0)
ima_appraise = IMA_APPRAISE_FIX;
#endif
+ if (strcmp(str, "enforce-evm") == 0 ||
+ strcmp(str, "log-evm") == 0)
+ ima_appraise_req_evm = true;
return 1;
}
@@ -245,7 +249,11 @@ int ima_appraise_measurement(enum ima_hooks func,
switch (status) {
case INTEGRITY_PASS:
case INTEGRITY_PASS_IMMUTABLE:
+ break;
case INTEGRITY_UNKNOWN:
+ if (ima_appraise_req_evm &&
+ xattr_value->type != EVM_IMA_XATTR_DIGSIG)
+ goto out;
break;
case INTEGRITY_NOXATTRS: /* No EVM protected xattrs. */
case INTEGRITY_NOLABEL: /* No security.evm xattr. */
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/3] ima: show rules with IMA_INMASK correctly
From: Roberto Sassu @ 2019-05-29 13:30 UTC (permalink / raw)
To: zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, Roberto Sassu, stable
In-Reply-To: <20190529133035.28724-1-roberto.sassu@huawei.com>
Show the '^' character when a policy rule has flag IMA_INMASK.
Fixes: 80eae209d63ac ("IMA: allow reading back the current IMA policy")
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Cc: stable@vger.kernel.org
---
security/integrity/ima/ima_policy.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index e0cc323f948f..ae4034f041c4 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1146,10 +1146,10 @@ enum {
};
static const char *const mask_tokens[] = {
- "MAY_EXEC",
- "MAY_WRITE",
- "MAY_READ",
- "MAY_APPEND"
+ "^MAY_EXEC",
+ "^MAY_WRITE",
+ "^MAY_READ",
+ "^MAY_APPEND"
};
#define __ima_hook_stringify(str) (#str),
@@ -1209,6 +1209,7 @@ int ima_policy_show(struct seq_file *m, void *v)
struct ima_rule_entry *entry = v;
int i;
char tbuf[64] = {0,};
+ int offset = 0;
rcu_read_lock();
@@ -1232,15 +1233,17 @@ int ima_policy_show(struct seq_file *m, void *v)
if (entry->flags & IMA_FUNC)
policy_func_show(m, entry->func);
- if (entry->flags & IMA_MASK) {
+ if ((entry->flags & IMA_MASK) || (entry->flags & IMA_INMASK)) {
+ if (entry->flags & IMA_MASK)
+ offset = 1;
if (entry->mask & MAY_EXEC)
- seq_printf(m, pt(Opt_mask), mt(mask_exec));
+ seq_printf(m, pt(Opt_mask), mt(mask_exec) + offset);
if (entry->mask & MAY_WRITE)
- seq_printf(m, pt(Opt_mask), mt(mask_write));
+ seq_printf(m, pt(Opt_mask), mt(mask_write) + offset);
if (entry->mask & MAY_READ)
- seq_printf(m, pt(Opt_mask), mt(mask_read));
+ seq_printf(m, pt(Opt_mask), mt(mask_read) + offset);
if (entry->mask & MAY_APPEND)
- seq_printf(m, pt(Opt_mask), mt(mask_append));
+ seq_printf(m, pt(Opt_mask), mt(mask_append) + offset);
seq_puts(m, " ");
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 6/8] docs/gpu: fix a documentation build break in i915.rst
From: Jonathan Corbet @ 2019-05-29 13:50 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Doc Mailing List, Linux Kernel Mailing List, Jani Nikula,
Markus Heiser, Mauro Carvalho Chehab, Oleksandr Natalenko
In-Reply-To: <CAKMK7uFVP6o5jU_cEPshYXwWN39ohybid52yBj567dGBiejzTg@mail.gmail.com>
On Wed, 29 May 2019 08:54:16 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Documentation/gpu/i915.rst is not included in the TOC tree, but newer
> > versions of sphinx parse it anyway. That leads to this hard build failure:
>
> It is included I think: Documentation/gpu/index.rst -> drivers.rst ->
> i915.rst. With that corrected A-b: me.
>
> btw this patch didn't go to intel-gfx and all i915 maintainers, I
> think per get_maintainers.pl it should have. Just asking since I had a
> few patches of my own where get_maintainers.pl didn't seem to do the
> right thing somehow.
It is included, just a level down and I wasn't paying attention.
In any case, this patch needs to be dropped; the kerneldoc comment
changes I sent (and Jani acked) are the better fix for this problem.
Thanks,
jon
^ permalink raw reply
* [PATCH v2 0/3] Bitops instrumentation for KASAN
From: Marco Elver @ 2019-05-29 14:14 UTC (permalink / raw)
To: peterz, aryabinin, dvyukov, glider, andreyknvl, mark.rutland
Cc: corbet, tglx, mingo, bp, hpa, x86, arnd, jpoimboe, linux-doc,
linux-kernel, linux-arch, kasan-dev, Marco Elver
The previous version of this patch series and discussion can be found
here: https://lkml.org/lkml/2019/5/28/769
The most significant change is the change of the instrumented access
size to cover the entire word of a bit.
Marco Elver (3):
lib/test_kasan: Add bitops tests
x86: Move CPU feature test out of uaccess region
asm-generic, x86: Add bitops instrumentation for KASAN
Documentation/core-api/kernel-api.rst | 2 +-
arch/x86/ia32/ia32_signal.c | 9 +-
arch/x86/include/asm/bitops.h | 210 ++++----------
include/asm-generic/bitops-instrumented.h | 317 ++++++++++++++++++++++
lib/test_kasan.c | 75 ++++-
5 files changed, 450 insertions(+), 163 deletions(-)
create mode 100644 include/asm-generic/bitops-instrumented.h
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply
* [PATCH v2 1/3] lib/test_kasan: Add bitops tests
From: Marco Elver @ 2019-05-29 14:14 UTC (permalink / raw)
To: peterz, aryabinin, dvyukov, glider, andreyknvl, mark.rutland
Cc: corbet, tglx, mingo, bp, hpa, x86, arnd, jpoimboe, linux-doc,
linux-kernel, linux-arch, kasan-dev, Marco Elver
In-Reply-To: <20190529141500.193390-1-elver@google.com>
This adds bitops tests to the test_kasan module. In a follow-up patch,
support for bitops instrumentation will be added.
Signed-off-by: Marco Elver <elver@google.com>
---
Changes in v2:
* Use BITS_PER_LONG.
* Use heap allocated memory for test, as newer compilers (correctly)
warn on OOB stack access.
---
lib/test_kasan.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 72 insertions(+), 3 deletions(-)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 7de2702621dc..6562df0ca30d 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -11,16 +11,17 @@
#define pr_fmt(fmt) "kasan test: %s " fmt, __func__
+#include <linux/bitops.h>
#include <linux/delay.h>
+#include <linux/kasan.h>
#include <linux/kernel.h>
-#include <linux/mman.h>
#include <linux/mm.h>
+#include <linux/mman.h>
+#include <linux/module.h>
#include <linux/printk.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/uaccess.h>
-#include <linux/module.h>
-#include <linux/kasan.h>
/*
* Note: test functions are marked noinline so that their names appear in
@@ -623,6 +624,73 @@ static noinline void __init kasan_strings(void)
strnlen(ptr, 1);
}
+static noinline void __init kasan_bitops(void)
+{
+ long *bits = kmalloc(sizeof(long), GFP_KERNEL | __GFP_ZERO);
+ if (!bits)
+ return;
+
+ pr_info("within-bounds in set_bit");
+ set_bit(0, bits);
+
+ pr_info("within-bounds in set_bit");
+ set_bit(BITS_PER_LONG - 1, bits);
+
+ pr_info("out-of-bounds in set_bit\n");
+ set_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in __set_bit\n");
+ __set_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in clear_bit\n");
+ clear_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in __clear_bit\n");
+ __clear_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in clear_bit_unlock\n");
+ clear_bit_unlock(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in __clear_bit_unlock\n");
+ __clear_bit_unlock(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in change_bit\n");
+ change_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in __change_bit\n");
+ __change_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in test_and_set_bit\n");
+ test_and_set_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in __test_and_set_bit\n");
+ __test_and_set_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in test_and_set_bit_lock\n");
+ test_and_set_bit_lock(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in test_and_clear_bit\n");
+ test_and_clear_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in __test_and_clear_bit\n");
+ __test_and_clear_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in test_and_change_bit\n");
+ test_and_change_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in __test_and_change_bit\n");
+ __test_and_change_bit(BITS_PER_LONG, bits);
+
+ pr_info("out-of-bounds in test_bit\n");
+ (void)test_bit(BITS_PER_LONG, bits);
+
+#if defined(clear_bit_unlock_is_negative_byte)
+ pr_info("out-of-bounds in clear_bit_unlock_is_negative_byte\n");
+ clear_bit_unlock_is_negative_byte(BITS_PER_LONG, bits);
+#endif
+ kfree(bits);
+}
+
static int __init kmalloc_tests_init(void)
{
/*
@@ -664,6 +732,7 @@ static int __init kmalloc_tests_init(void)
kasan_memchr();
kasan_memcmp();
kasan_strings();
+ kasan_bitops();
kasan_restore_multi_shot(multishot);
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox