On Mon, Jul 22, 2024 at 11:22 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Mon, 2024-07-22 at 10:51 -0700, Alexei Starovoitov wrote: > > [...] > > > It's not that simple. > > Above sequence violates -mno-red-zone. > > The part of the fix may look like: > > movabs .., rax > > add %gs.., rax > > mov rbp, qword ptr [rax - ...] > > > > mov rax, rsp > > mox rax, rbp > > sub rsp, ... > > > > it's probably correct from mno-red-zone pov and > > end result is maybe correct for stack unwind, > > but if irq happens in the middle it won't crash, > > but unwind will not work. > > The main reason to use r9 is to have valid unwind > > at any point of the prog. > > Oh, I see, bad things would happen if this sequence: > > movabs $0x...,%rsp > add %gs:0x...,%rsp > > Would be split by an interrupt. > However, I don't understand why 'push %rbp' violates red zone. > In any case, the interrupt argument is sufficient, > thank you for explaining. push rbp itself doesn't break red-zone. If we do: movabs .., rax add %gs.., rax mov rax, rsp push rbp at the time of setting of rsp the unwind is broken. hence the idea to mov rbp, qword ptr [rax - ...] before setting rsp. We have to maintain uwindable stack at all times. But if we overwrite rsp it means everything will go into this new memory. We'd need another 16k of space in there for everything that bpf prog can call, since kernel code will be using that area from the moment of the switch. At the end we'd have to restore to original stack somehow. Instead of single 'leave' insn the sequence has to preserve unwinding. It all looks very tricky and fragile.
