linux-kernel - [GIT PULL] tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 15 May 2018 18:37:14 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Juergen Gross <jgross@...e.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        xen-devel@...ts.xenproject.org
Subject: [GIT PULL] tracing/x86/xen: Remove zero data size trace events
 trace_xen_mmu_flush_tlb{_all}


Linus,

Some of the ftrace internal events use a zero for a data size of
a field event. This is increasingly important for the histogram trigger
work that is being extended.

While auditing trace events, I found that a couple of the xen events
were used as just marking that a function was called, by creating
a static array of size zero. This can play havoc with the tracing
features if these events are used, because a zero size of a static
array is denoted as a special nul terminated dynamic array (this is
what the trace_marker code uses). But since the xen events have no
size, they are not nul terminated, and unexpected results may occur.

As trace events were never intended on being a marker to denote
that a function was hit or not, especially since function tracing
and kprobes can trivially do the same, the best course of action is
to simply remove these events.


Please pull the latest trace-v4.17-rc4-2 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v4.17-rc4-2

Tag SHA1: 580faa7b1b80b1332683dc869732a4db8a506b9c
Head SHA1: 45dd9b0666a162f8e4be76096716670cf1741f0e


Steven Rostedt (VMware) (1):
      tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}

----
 arch/x86/xen/mmu.c         |  4 +---
 arch/x86/xen/mmu_pv.c      |  4 +---
 include/trace/events/xen.h | 16 ----------------
 3 files changed, 2 insertions(+), 22 deletions(-)
---------------------------
commit 45dd9b0666a162f8e4be76096716670cf1741f0e
Author: Steven Rostedt (VMware) <rostedt@...dmis.org>
Date:   Wed May 9 14:36:09 2018 -0400

    tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}
    
    Doing an audit of trace events, I discovered two trace events in the xen
    subsystem that use a hack to create zero data size trace events. This is not
    what trace events are for. Trace events add memory footprint overhead, and
    if all you need to do is see if a function is hit or not, simply make that
    function noinline and use function tracer filtering.
    
    Worse yet, the hack used was:
    
     __array(char, x, 0)
    
    Which creates a static string of zero in length. There's assumptions about
    such constructs in ftrace that this is a dynamic string that is nul
    terminated. This is not the case with these tracepoints and can cause
    problems in various parts of ftrace.
    
    Nuke the trace events!
    
    Link: http://lkml.kernel.org/r/20180509144605.5a220327@gandalf.local.home
    
    Cc: stable@...r.kernel.org
    Fixes: 95a7d76897c1e ("xen/mmu: Use Xen specific TLB flush instead of the generic one.")
    Reviewed-by: Juergen Gross <jgross@...e.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d33e7dbe3129..2d76106788a3 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -42,13 +42,11 @@ xmaddr_t arbitrary_virt_to_machine(void *vaddr)
 }
 EXPORT_SYMBOL_GPL(arbitrary_virt_to_machine);
 
-static void xen_flush_tlb_all(void)
+static noinline void xen_flush_tlb_all(void)
 {
 	struct mmuext_op *op;
 	struct multicall_space mcs;
 
-	trace_xen_mmu_flush_tlb_all(0);
-
 	preempt_disable();
 
 	mcs = xen_mc_entry(sizeof(*op));
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 486c0a34d00b..2c30cabfda90 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1310,13 +1310,11 @@ unsigned long xen_read_cr2_direct(void)
 	return this_cpu_read(xen_vcpu_info.arch.cr2);
 }
 
-static void xen_flush_tlb(void)
+static noinline void xen_flush_tlb(void)
 {
 	struct mmuext_op *op;
 	struct multicall_space mcs;
 
-	trace_xen_mmu_flush_tlb(0);
-
 	preempt_disable();
 
 	mcs = xen_mc_entry(sizeof(*op));
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index 7dd8f34c37df..fdcf88bcf0ea 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -352,22 +352,6 @@ DECLARE_EVENT_CLASS(xen_mmu_pgd,
 DEFINE_XEN_MMU_PGD_EVENT(xen_mmu_pgd_pin);
 DEFINE_XEN_MMU_PGD_EVENT(xen_mmu_pgd_unpin);
 
-TRACE_EVENT(xen_mmu_flush_tlb_all,
-	    TP_PROTO(int x),
-	    TP_ARGS(x),
-	    TP_STRUCT__entry(__array(char, x, 0)),
-	    TP_fast_assign((void)x),
-	    TP_printk("%s", "")
-	);
-
-TRACE_EVENT(xen_mmu_flush_tlb,
-	    TP_PROTO(int x),
-	    TP_ARGS(x),
-	    TP_STRUCT__entry(__array(char, x, 0)),
-	    TP_fast_assign((void)x),
-	    TP_printk("%s", "")
-	);
-
 TRACE_EVENT(xen_mmu_flush_tlb_one_user,
 	    TP_PROTO(unsigned long addr),
 	    TP_ARGS(addr),