Re: yet another approach Was: [PATCH bpf-next v3 4/5] bpf, x86: Add jit support for private stack

[Yonghong Song <yonghong.song@linux.dev>]

On 10/3/24 3:32 PM, Alexei Starovoitov wrote:
> On Thu, Oct 3, 2024 at 1:44 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>> Looks like the idea needs more thought.
>>>
>>> in_task_stack() won't recognize the private stack,
>>> so it will look like stack overflow and double fault.
>>>
>>> do you have CONFIG_VMAP_STACK ?
>> Yes, my above test runs fine withCONFIG_VMAP_STACK. Let me guard private stack support with
>> CONFIG_VMAP_STACK for now. Not sure whether distributions enable
>> CONFIG_VMAP_STACK or not.
> Good! but I'm surprised it makes a difference.

That only for the test case I tried. Now I tried the whole bpf selftests
with CONFIG_VMAP_STACK on. There are still some failures. Some of them
due to stack protector. I disabled stack protector and then those stack
protector error gone. But some other errors show up like below:

[   27.186581] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[   27.187480] BUG: unable to handle page fault for address: ffff888109572800
[   27.188299] #PF: supervisor instruction fetch in kernel mode
[   27.189085] #PF: error_code(0x0011) - permissions violation

or

[   27.736844] BUG: unable to handle page fault for address: 0000000080000000
[   27.737759] #PF: supervisor instruction fetch in kernel mode
[   27.738631] #PF: error_code(0x0010) - not-present page
[   27.739455] PGD 0 P4D 0
[   27.739818] Oops: Oops: 0010 [#1] PREEMPT SMP PTI

...

Some further investigations are needed.

> Please still root cause the crash without VMAP_STACK.

Sure. Let me investigate cases with VMAP_STACK first and
then will try to look at it without VMAP_STACK.

>
> We need to do a lot more homework here before proceeding.
> Look at arch/x86/kernel/dumpstack_64.c
> At least we need new stack_type for priv stack.
> stack_type_unknown doesn't inspire confidence.
> Need to make sure stack trace is still reliable with priv stack.
> Though it may look appealing from performance pov.
> We may need to go back to r9 approach with push/pop around calls,
> since that is surely keeping unwinder happy
> while this approach will have to teach unwinder.

Good point.