Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 14 Nov 2017 20:12:23 -0800 | Subject | Re: [RFC PATCH for 4.15 00/24] Restartable sequences and CPU op vector v11 |
| |
> On Nov 14, 2017, at 1:32 PM, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > ----- On Nov 14, 2017, at 4:15 PM, Andy Lutomirski luto@amacapital.net wrote: > > > One thing I kept however that diverge from your recommendation is the > "sign" parameter to the rseq syscall. I prefer this flexible > approach to a hardcoded signature value. We never know when we may > need to randomize or change this in the future. > > Regarding abort target signature the vs x86 disassemblers, I used a > 5-byte no-op on x86 32/64: > > x86-32: nopl <sig> > x86-64: nopl <sig>(%rip)
I still don't see how this can possibly work well with libraries. If glibc or whatever issues the syscall and registers some signature, that signature *must* match the expectation of all libraries used in that thread or it's not going to work. I can see two reasonable ways to handle it:
1. The signature is just a well-known constant. If you have an rseq abort landing site, you end up with something like:
nopl $11223344(%rip) landing_site:
or whatever the constant is.
2. The signature varies depending on the rseq_cs in use. So you get:
static struct rseq_cs this_cs = { .signature = 0x55667788; ... };
and then the abort landing site has:
nopl $11223344(%rip) nopl $55667788(%rax) landing_site:
The former is a bit easier to deal with. The latter has the nice property that you can't subvert one rseq_cs to land somewhere else, but it's not clear to me how what actual attack this prevents, so I think I prefer #1. I just think that your variant is asking for trouble down the road with incompatible userspace.
--Andy
| |