Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

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

Re: [PATCH 0/3] Remove accidental VLA usage

On Thu, Mar 08, 2018 at 10:02:01AM -0800, Kees Cook wrote: > On Thu, Mar 8, 2018 at 7:02 AM, Josh Poimboeuf <jpoim...@redhat.com> 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 arra

Re: [PATCH 0/3] Remove accidental VLA usage

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote: > On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf <jpoim...@redhat.com> 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 <dan.j.will

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

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 > >> > >>

Re: WARNING: kernel stack frame pointer at ffff880156a5fea0 in bash:2103 has bad value 00007ffec7d87e50

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

Re: WARNING: kernel stack frame pointer at ffff880156a5fea0 in bash:2103 has bad value 00007ffec7d87e50

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

[tip:x86/urgent] x86/asm: Don't use RBP as a temporary register in csum_partial_copy_generic()

Commit-ID: 42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6 Gitweb: http://git.kernel.org/tip/42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6 Author: Josh Poimboeuf <jpoim...@redhat.com> AuthorDate: Thu, 4 May 2017 09:51:40 -0500 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 5

Re: [PATCH] x86/asm: Don't use rbp as temp register in csum_partial_copy_generic()

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

[PATCH] x86/asm: Don't use rbp as temp register in csum_partial_copy_generic()

be affected. Reported-by: Andrey Konovalov <andreyk...@google.com> Tested-by: Andrey Konovalov <andreyk...@google.com> Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> --- arch/x86/lib/csum-copy_64.S | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --

Re: x86: warning: kernel stack regs has bad 'bp' value

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

[PATCH v19 04/10] bpf: Mark __bpf_prog_run() stack frame as non-standard

e'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-off-by: Josh Poimbo

[PATCH v18 4/9] bpf: Mark __bpf_prog_run() stack frame as non-standard

ool 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 <jpoim...@redhat.com&

Re: [PATCH v17 0/9] Compile-time stack metadata validation

On Thu, Feb 25, 2016 at 09:02:04AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf <jpoim...@redhat.com> 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 t

[PATCH v17 0/9] Compile-time stack metadata validation

: Borislav Petkov <b...@alien8.de> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Andi Kleen <a...@firstfloor.org> Cc: Pedro Alves <pal...@redhat.com> Cc: Namhyung Kim <namhy...@gmail.com> Cc: Bernd Petrovitsch <be...@petrovitsch.priv.at> Cc: Chris J

[PATCH v17 7/9] bpf: Add __bpf_prog_run() to objtool whitelist

ool 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 <jpoim...@redhat.com&

Re: [PATCH 00/33] Compile-time stack metadata validation

On Wed, Feb 24, 2016 at 08:40:54AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > Hi Ingo, > > > > On Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar wrote: > > > So I tried out this latest

Re: [PATCH 00/33] Compile-time stack metadata validation

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,

Re: [PATCH 00/33] Compile-time stack metadata validation

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

Re: [PATCH 00/33] Compile-time stack metadata validation

On Mon, Feb 15, 2016 at 08:56:21AM -0800, Linus Torvalds wrote: > On Feb 15, 2016 8:31 AM, "Josh Poimboeuf" <jpoim...@redhat.com> wrote: > > > > So is the goal to optimize for size? If I replace the calls to > > __preempt_schedule[_notrace]() with real C cal

Re: [PATCH 00/33] Compile-time stack metadata validation

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: > &

Re: [PATCH 00/33] Compile-time stack metadata validation

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 tip/m

Re: [PATCH 00/33] Compile-time stack metadata validation

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

Re: [PATCH 00/33] Compile-time stack metadata validation

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: > >

Re: [PATCH 00/33] Compile-time stack metadata validation

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: &

Re: [PATCH 00/33] Compile-time stack metadata validation

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 based

Re: [PATCH 23/33] x86/asm/bpf: Create stack frames in bpf_jit.S

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: >

Re: [PATCH 23/33] x86/asm/bpf: Create stack frames in bpf_jit.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: >

[PATCH 31/33] bpf: Add __bpf_prog_run() to stacktool whitelist

ool 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 <

[PATCH 22/33] x86/asm/bpf: Annotate callable functions

bpf_jit.S has several functions which can be called from C code. Give them proper ELF annotations. Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Cc: Alexei Starovoitov <a...@kernel.org> Cc: netdev@vger.kernel.org --- arch/x86/net/bpf_jit.S | 39 --

[PATCH 23/33] x86/asm/bpf: Create stack frames in bpf_jit.S

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 <jpoim...@redhat.com> Cc: Alexei Staro

[PATCH 00/33] Compile-time stack metadata validation

t;namhy...@gmail.com> Cc: Bernd Petrovitsch <be...@petrovitsch.priv.at> Cc: Chris J Arges <chris.j.ar...@canonical.com> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Jiri Slaby <jsl...@suse.cz> Cc: Arnaldo Carvalho de Melo <a...@kernel.org> Chris J Arges (1): x86/u

Re: [PATCH 31/33] bpf: Add __bpf_prog_run() to stacktool whitelist

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

Re: [PATCH 23/33] x86/asm/bpf: Create stack frames in bpf_jit.S

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. > >

Re: [PATCH 1/4] list: introduce list_is_first()

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