[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABWYdi15x=-2qenWSdX_ONSha_Pz7GFJrx8axN6CJS5cWxTTSg@mail.gmail.com>
Date: Thu, 4 Feb 2021 10:41:18 -0800
From: Ivan Babrou <ivan@...udflare.com>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
kernel-team <kernel-team@...udflare.com>,
Ignat Korchagin <ignat@...udflare.com>,
Hailong liu <liu.hailong6@....com.cn>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
Miroslav Benes <mbenes@...e.cz>,
Julien Thierry <jthierry@...hat.com>,
Jiri Slaby <jirislaby@...nel.org>, kasan-dev@...glegroups.com,
linux-mm@...ck.org, linux-kernel <linux-kernel@...r.kernel.org>,
Alasdair Kergon <agk@...hat.com>,
Mike Snitzer <snitzer@...hat.com>, dm-devel@...hat.com,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Andrii Nakryiko <andriin@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>,
Robert Richter <rric@...nel.org>,
"Joel Fernandes (Google)" <joel@...lfernandes.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
bpf@...r.kernel.org
Subject: Re: BUG: KASAN: stack-out-of-bounds in unwind_next_frame+0x1df5/0x2650
On Wed, Feb 3, 2021 at 7:10 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> This line gives a big clue:
>
> [160676.608966][ C4] RIP: 0010:0xffffffffc17d814c
>
> That address, without a function name, most likely means that it was
> running in some generated code (mostly likely BPF) when it got
> interrupted.
We do have eBPF/XDP in our environment.
> Right now, the ORC unwinder tries to fall back to frame pointers when it
> encounters generated code:
>
> orc = orc_find(state->signal ? state->ip : state->ip - 1);
> if (!orc)
> /*
> * As a fallback, try to assume this code uses a frame pointer.
> * This is useful for generated code, like BPF, which ORC
> * doesn't know about. This is just a guess, so the rest of
> * the unwind is no longer considered reliable.
> */
> orc = &orc_fp_entry;
> state->error = true;
> }
>
> Because the ORC unwinder is guessing from that point onward, it's
> possible for it to read the KASAN stack redzone, if the generated code
> hasn't set up frame pointers. So the best fix may be for the unwinder
> to just always bypass KASAN when reading the stack.
>
> The unwinder has a mechanism for detecting and warning about
> out-of-bounds, and KASAN is short-circuiting that.
>
> This should hopefully get rid of *all* the KASAN unwinder warnings, both
> crypto and networking.
It definitely worked on my dm-crypt case, and I've tried it without
your previous AVX related patch. I will apply it to our tree and
deploy to the staging KASAN environment to see how it fares with
respect to networking stacks. Feel free to ping me if I don't get back
to you with the results on Monday.
Thanks for looking into this!
Powered by blists - more mailing lists