On Thu, Feb 04, 2021 at 11:51:44AM -0800, Ivan Babrou wrote:
> > .macro FUNC_SAVE
> > #the number of pushes must equal STACK_OFFSET
> > + push%rbp
> > + mov %rsp, %rbp
> > push%r12
> > push%r13
> > push%r14
> > @@ -271,12 +273,14
On Wed, Feb 03, 2021 at 09:44:48PM -0500, Steven Rostedt wrote:
> > > [ 128.441287][C0] RIP: 0010:skcipher_walk_next
> > > (crypto/skcipher.c:322 crypto/skcipher.c:384)
>
> Why do we have an RIP in skcipher_walk_next, if its the unwinder that
> had a bug? Or are they related?
>
> Or did skci
On Wed, Feb 03, 2021 at 04:52:42PM -0800, Ivan Babrou wrote:
> We also have the following stack that doesn't touch any crypto:
>
> * https://gist.github.com/bobrik/40e2559add2f0b26ae39da30dc451f1e
Can you also run this through decode_stacktrace.sh?
Both are useful (until I submit a fix for decod
On Wed, Feb 03, 2021 at 03:30:35PM -0800, Ivan Babrou wrote:
> > > > Can you recreate with this patch, and add "unwind_debug" to the cmdline?
> > > > It will spit out a bunch of stack data.
> > >
> > > Here's the three I'm building:
> > >
> > > * https://github.com/bobrik/linux/tree/ivan/static-cal
On Wed, Feb 03, 2021 at 02:41:53PM -0800, Ivan Babrou wrote:
> On Wed, Feb 3, 2021 at 11:05 AM Josh Poimboeuf wrote:
> >
> > On Wed, Feb 03, 2021 at 09:46:55AM -0800, Ivan Babrou wrote:
> > > > Can you pretty please not line-wrap console output? It's unreadable.
&
help. Do I
> need to apply the whole series or something else?
Can you recreate with this patch, and add "unwind_debug" to the cmdline?
It will spit out a bunch of stack data.
From: Josh Poimboeuf
Subject: [PATCH] Subject: [PATCH] x86/unwind: Add 'unwind_debug' cmdline
op
On Wed, May 06, 2020 at 05:03:57PM -0700, Alexei Starovoitov wrote:
> > > > > diff --git a/include/linux/compiler-gcc.h
> > > > > b/include/linux/compiler-gcc.h
> > > > > index d7ee4c6bad48..05104c3cc033 100644
> > > > > --- a/include/linux/compiler-gcc.h
> > > > > +++ b/include/linux/compiler-gcc
On Wed, May 06, 2020 at 09:45:01AM -0700, Alexei Starovoitov wrote:
> On Wed, May 6, 2020 at 8:53 AM Josh Poimboeuf wrote:
> >
> > On Tue, May 05, 2020 at 04:59:39PM -0700, Alexei Starovoitov wrote:
> > > As far as workaround I prefer t
On Tue, May 05, 2020 at 04:59:39PM -0700, Alexei Starovoitov wrote:
> As far as workaround I prefer the following:
> From 94bbc27c5a70d78846a5cb675df4cf8732883564 Mon Sep 17 00:00:00 2001
> From: Alexei Starovoitov
> Date: Tue, 5 May 2020 16:52:41 -0700
> Subject: [PATCH] bpf,objtool: tweak interp
On Tue, May 05, 2020 at 12:53:20PM -0700, Alexei Starovoitov wrote:
> On Tue, May 05, 2020 at 01:11:08PM -0500, Josh Poimboeuf wrote:
> > On Tue, May 05, 2020 at 10:43:00AM -0700, Alexei Starovoitov wrote:
> > > > Or, if you want to minimize the patch's impact on other ar
On Tue, May 05, 2020 at 12:14:05PM -0700, Alexei Starovoitov wrote:
> >
> > Hi,
> >
> > I see the objtool warning:
> > kernel/bpf/core.o: warning: objtool: ___bpf_prog_run()+0x33: call without
> > frame pointer save/setup
> >
> > when using:
> > gcc (SUSE Linux) 9.3.1 20200406 [revision
> > 6d
On Tue, May 05, 2020 at 10:43:00AM -0700, Alexei Starovoitov wrote:
> > Or, if you want to minimize the patch's impact on other arches, and keep
> > the current patch the way it is (with bug fixed and changed patch
> > description), that's fine too. I can change the patch description
> > according
On Sat, May 02, 2020 at 11:36:11PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:8999dc89 net/x25: Fix null-ptr-deref in x25_disconnect
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1600444010
> kernel config: h
On Fri, May 01, 2020 at 08:06:22PM -0700, Alexei Starovoitov wrote:
> On Fri, May 01, 2020 at 02:56:17PM -0500, Josh Poimboeuf wrote:
> > On Fri, May 01, 2020 at 12:40:53PM -0700, Alexei Starovoitov wrote:
> > > On Fri, May 01, 2020 at 02:22:04PM -0500, Josh Poimboeuf wrote:
>
On Fri, May 01, 2020 at 12:40:53PM -0700, Alexei Starovoitov wrote:
> On Fri, May 01, 2020 at 02:22:04PM -0500, Josh Poimboeuf wrote:
> > On Fri, May 01, 2020 at 12:09:30PM -0700, Alexei Starovoitov wrote:
> > > On Thu, Apr 30, 2020 at 02:07:43PM -0500, Josh Poimboeuf wrot
On Fri, May 01, 2020 at 12:09:30PM -0700, Alexei Starovoitov wrote:
> On Thu, Apr 30, 2020 at 02:07:43PM -0500, Josh Poimboeuf wrote:
> > Objtool decodes instructions and follows all potential code branches
> > within a function. But it's not an emulator, so it doesn't
6f20 ("bpf: Disable GCC -fgcse optimization for
___bpf_prog_run()")
Reported-by: Randy Dunlap
Reported-by: Arnd Bergmann
Signed-off-by: Josh Poimboeuf
---
include/linux/compiler-gcc.h | 2 --
include/linux/compiler_types.h | 4
kernel/bpf/core.c | 10 +++---
3
In preparation for using R12 indexing instructions in BPF JIT code, add
support for generating the x86 SIB byte.
Signed-off-by: Josh Poimboeuf
---
arch/x86/net/bpf_jit_comp.c | 69 +
1 file changed, 54 insertions(+), 15 deletions(-)
diff --git a/arch/x86/net
On Sat, Mar 17, 2018 at 01:07:32PM -0700, Kees Cook wrote:
> On Sat, Mar 17, 2018 at 11:52 AM, Linus Torvalds
> wrote:
> > So the above is completely insane, bit there is actually a chance that
> > using that completely crazy "x -> sizeof(char[x])" conversion actually
> > helps, because it really
On Thu, Mar 08, 2018 at 10:02:01AM -0800, Kees Cook wrote:
> On Thu, Mar 8, 2018 at 7:02 AM, Josh Poimboeuf wrote:
> > On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote:
> >> This series adds SIMPLE_MAX() to be used in places where a stack array
> >> is actua
On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote:
> This series adds SIMPLE_MAX() to be used in places where a stack array
> is actually fixed, but the compiler still warns about VLA usage due to
> confusion caused by the safety checks in the max() macro.
>
> I'm sending these via -mm sin
On Tue, Jan 09, 2018 at 01:59:04PM -0800, Dan Williams wrote:
> > Right, but what's the purpose of preventing speculation past
> > access_ok()?
>
> Caution. It's the same rationale for the nospec_array_ptr() patches.
> If we, kernel community, can identify any possible speculation past a
> bounds
On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote:
> On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote:
> > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
> >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
> >> wrote:
> >> &g
On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote:
> > From: Andi Kleen
> >
> > When access_ok fails we should always stop speculating.
> > Add the required barriers to the x86 access_ok macro.
>
> Honestly, this seems completely
On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
> On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina wrote:
> > On Fri, 5 Jan 2018, Dan Williams wrote:
> >
> > [ ... snip ... ]
> >> Andi Kleen (1):
> >> x86, barrier: stop speculation for failed access_ok
> >>
> >> Dan Williams (13):
On Wed, Sep 27, 2017 at 08:51:22AM +0200, Richard Weinberger wrote:
> Am Mittwoch, 27. September 2017, 00:42:46 CEST schrieb Josh Poimboeuf:
> > > Here is another variant of the warning, it matches the attached .config:
> > I can take a look at it. Unfortunately, for these
On Tue, Sep 26, 2017 at 11:51:31PM +0200, Richard Weinberger wrote:
> Alexei,
>
> CC'ing Josh and Ingo.
>
> Am Dienstag, 26. September 2017, 06:09:02 CEST schrieb Alexei Starovoitov:
> > On Mon, Sep 25, 2017 at 11:23:31PM +0200, Richard Weinberger wrote:
> > > Hi!
> > >
> > > While playing with
Commit-ID: 42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6
Gitweb: http://git.kernel.org/tip/42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6
Author: Josh Poimboeuf
AuthorDate: Thu, 4 May 2017 09:51:40 -0500
Committer: Ingo Molnar
CommitDate: Fri, 5 May 2017 07:59:24 +0200
x86/asm: Don't use R
On Thu, May 04, 2017 at 03:56:49PM +, David Laight wrote:
> From: Josh Poimboeuf
> > Sent: 04 May 2017 15:52
> > Andrey Konovalov reported the following warning while fuzzing the kernel
> > with syzkaller:
> >
> > WARNING: kernel stack regs at 88006
s are no longer be affected.
Reported-by: Andrey Konovalov
Tested-by: Andrey Konovalov
Signed-off-by: Josh Poimboeuf
---
arch/x86/lib/csum-copy_64.S | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/lib/csum-copy_64.S b/arch/x86/lib/csum-copy_64.S
index 7
On Wed, May 03, 2017 at 02:48:28PM +0200, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 89c9fea3c8034cdb2fd745f551cde0b507fd6893 (4.11.0+).
>
> A reproducer and .config are attached.
>
> The reproducer open SCTP sock
ere's no way for objtool to deterministically find all possible
branch targets for a dynamic jump, so it can't verify this code.
In this case the jumps all stay within the function, and there's nothing
unusual going on related to the stack, so we can whitelist the function.
Signed
or objtool to deterministically find all possible
branch targets for a dynamic jump, so it can't verify this code.
In this case the jumps all stay within the function, and there's nothing
unusual going on related to the stack, so we can whitelist the function.
Signed-off-by: Josh Poimboeuf
Ac
On Thu, Feb 25, 2016 at 09:02:04AM +0100, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > This is v17 of the compile-time stack metadata validation patch set.
> >
> > It's based on tip:x86/debug. However, note that when run against that
> >
push/pop CFI macros arch-independent, as
suggested by H. Peter Anvin
v2:
- Fixed memory leaks reported by Petr Mladek
Cc: linux-ker...@vger.kernel.org
Cc: live-patch...@vger.kernel.org
Cc: Michal Marek
Cc: Peter Zijlstra
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Andi Kl
or objtool to deterministically find all possible
branch targets for a dynamic jump, so it can't verify this code.
In this case the jumps all stay within the function, and there's nothing
unusual going on related to the stack, so we can whitelist the function.
Signed-off-by: Josh Poimboeuf
Ac
On Wed, Feb 24, 2016 at 08:40:54AM +0100, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > Hi Ingo,
> >
> > On Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar wrote:
> > > So I tried out this latest stacktool series and it looks mostly good
On Tue, Feb 23, 2016 at 11:27:17AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar escreveu:
> > The fact that 'stacktool' already checks about assembly details like
> > __ex_table[]
> > shows that my review feedback early iterations of this series,
Hi Ingo,
On Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar wrote:
> So I tried out this latest stacktool series and it looks mostly good for an
> upstream merge.
>
> To help this effort move forward I've applied the preparatory/fix patches
> that are
> part of this series to tip:x86/debug
On Mon, Feb 15, 2016 at 08:56:21AM -0800, Linus Torvalds wrote:
> On Feb 15, 2016 8:31 AM, "Josh Poimboeuf" wrote:
> >
> > So is the goal to optimize for size? If I replace the calls to
> > __preempt_schedule[_notrace]() with real C calls and remove the thunk
On Fri, Feb 12, 2016 at 09:10:11PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 12:32:06PM -0600, Josh Poimboeuf wrote:
> > What I actually see in the listing is:
> >
> > decl__percpu_prefix:__preempt_count
> > je 1f:
> &
On Fri, Feb 12, 2016 at 12:32:06PM -0600, Josh Poimboeuf wrote:
> On Fri, Feb 12, 2016 at 06:10:37PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 12, 2016 at 08:45:43AM -0600, Josh Poimboeuf wrote:
> > > On Fri, Feb 12, 2016 at 11:36:24AM +0100, Jiri Slaby wrote:
> > &g
On Fri, Feb 12, 2016 at 06:10:37PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 08:45:43AM -0600, Josh Poimboeuf wrote:
> > On Fri, Feb 12, 2016 at 11:36:24AM +0100, Jiri Slaby wrote:
> >
> > This seems like a real frame pointer bug caused by the following line in
On Fri, Feb 12, 2016 at 11:36:24AM +0100, Jiri Slaby wrote:
> On 01/21/2016, 11:49 PM, Josh Poimboeuf wrote:
> > This is v16 of the compile-time stack metadata validation patch set,
> > along with proposed fixes for most of the warnings it found. It's based
> > on the
On Fri, Jan 22, 2016 at 02:40:35PM -0600, Chris J Arges wrote:
> On Fri, Jan 22, 2016 at 01:14:47PM -0600, Josh Poimboeuf wrote:
> > On Fri, Jan 22, 2016 at 11:43:48AM -0600, Chris J Arges wrote:
> > > On Thu, Jan 21, 2016 at 04:49:04PM -0600, Josh Poimboeuf wrote:
> >
On Fri, Jan 22, 2016 at 11:43:48AM -0600, Chris J Arges wrote:
> On Thu, Jan 21, 2016 at 04:49:04PM -0600, Josh Poimboeuf wrote:
> > This is v16 of the compile-time stack metadata validation patch set,
> > along with proposed fixes for most of the warnings it found. It's
On Fri, Jan 22, 2016 at 09:18:23AM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 22, 2016 at 09:58:04AM -0600, Josh Poimboeuf wrote:
> > On Thu, Jan 21, 2016 at 08:18:46PM -0800, Alexei Starovoitov wrote:
> > > On Thu, Jan 21, 2016 at 09:55:31PM -0600, Josh Poimboeuf wrote:
>
On Thu, Jan 21, 2016 at 08:18:46PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 21, 2016 at 09:55:31PM -0600, Josh Poimboeuf wrote:
> > On Thu, Jan 21, 2016 at 06:44:28PM -0800, Alexei Starovoitov wrote:
> > > On Thu, Jan 21, 2016 at 04:49:27PM -0600, Josh Poimboeuf wrote:
>
On Thu, Jan 21, 2016 at 06:55:41PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 21, 2016 at 04:49:35PM -0600, Josh Poimboeuf wrote:
> > stacktool reports the following false positive warnings:
> >
> > stacktool: kernel/bpf/core.o: __bpf_prog_run()+0x5c: sibling ca
On Thu, Jan 21, 2016 at 06:44:28PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 21, 2016 at 04:49:27PM -0600, Josh Poimboeuf wrote:
> > bpf_jit.S has several callable non-leaf functions which don't honor
> > CONFIG_FRAME_POINTER, which can result in bad stack traces.
>
ek
Cc: Peter Zijlstra
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Andi Kleen
Cc: Pedro Alves
Cc: Namhyung Kim
Cc: Bernd Petrovitsch
Cc: Chris J Arges
Cc: Andrew Morton
Cc: Jiri Slaby
Cc: Arnaldo Carvalho de Melo
Chris J Arges (1):
x86/uaccess: Add stack frame output o
bpf_jit.S has several functions which can be called from C code. Give
them proper ELF annotations.
Signed-off-by: Josh Poimboeuf
Cc: Alexei Starovoitov
Cc: netdev@vger.kernel.org
---
arch/x86/net/bpf_jit.S | 39 ---
1 file changed, 16 insertions(+), 23
bpf_jit.S has several callable non-leaf functions which don't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create a stack frame before the call instructions when
CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
Cc: Alexei Starovoitov
Cc: n
for stacktool to deterministically find all possible
branch targets for a dynamic jump, so it can't verify this code.
In this case the jumps all stay within the function, and there's nothing
unusual going on related to the stack, so we can whitelist the function.
Signed-off-by: Jos
On Thu, Dec 10, 2015 at 08:10:34AM -0700, Jens Axboe wrote:
> On 12/10/2015 07:17 AM, Geliang Tang wrote:
> >We already have list_is_last(), it makes sense to also add
> >list_is_first() for consistency. This list utility function
> >to check for first element in a list.
>
> Honestly, I think we a
55 matches
Mail list logo
