On Wed, Feb 3, 2021 at 7:10 PM Josh Poimboeuf [off-list ref] 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!