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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241018124952.17670-E-hca@linux.ibm.com>
Date: Fri, 18 Oct 2024 14:49:52 +0200
From: Heiko Carstens <hca@...ux.ibm.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Sven Schnelle <svens@...ux.ibm.com>,
        "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Florent Revest <revest@...omium.org>,
        linux-trace-kernel@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Martin KaFai Lau <martin.lau@...ux.dev>, bpf <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
        Alan Maguire <alan.maguire@...cle.com>,
        Mark Rutland <mark.rutland@....com>, linux-arch@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Huacai Chen <chenhuacai@...nel.org>,
        WANG Xuerui <kernel@...0n.name>, Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Naveen N Rao <naveen@...nel.org>,
        Madhavan Srinivasan <maddy@...ux.ibm.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v17 11/16] fprobe: Rewrite fprobe on function-graph tracer

On Wed, Oct 16, 2024 at 10:10:22AM -0400, Steven Rostedt wrote:
> On Wed, 16 Oct 2024 14:07:31 +0200
> Sven Schnelle <svens@...ux.ibm.com> wrote:
> > I haven't yet fully understood why this logic is needed, but the
> > WARN_ON_ONCE triggers on s390. I'm assuming this fails because fp always
> > has the upper bits of the address set on x86 (and likely others). As an
> > example, in my test setup, fp is 0x8feec218 on s390, while it is
> > 0xffff888100add118 in x86-kvm.
> 
> Since we only need to save 4 bits for size, we could have what it is
> replacing always be zero or always be f, depending on the arch. The
> question then is, is s390's 4 MSBs always zero?
> 
> Thus we could make it be:
> 
> static inline int decode_fprobe_header(unsigned long val, struct fprobe **fp)
> {
> 	unsigned long ptr;
> 
> 	ptr = (val & FPROBE_HEADER_PTR_MASK) | FPROBE_HEADER_MSB_MASK;
> 	if (fp)
> 		*fp = (struct fprobe *)ptr;
> 	return val >> FPROBE_HEADER_PTR_BITS;
> }
> 
> And define FPROBE_HEADER_MSB_MASK to be either:
> 
> For most archs:
> 
> #define FPROBE_HEADER_MSB_MASK	(0xf << FPROBE_HEADER_PTR_BITS)
> 
> or on s390:
> 
> #define FPROBE_HEADER_MSB_MASK	(0x0)
> 
> Would this work?

This would work for s390. Right now we don't make any use of the four
MSBs, and they are always zero. If for some reason this would ever
change, we would need to come up with a different solution.

Please note that this only works for addresses in the kernel address
space. For user space the full 64 bit address range (minus the top
page) can be used for user space applications. I'm just writing this
here, just in case something like this comes up for uprobes or
something similar as well.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ