Re: Kernel prctl feature for syscall interception and emulation

2020-11-19 Thread Paul Gofman
On 11/19/20 20:57, David Laight wrote: >>> The Windows code is not completely loaded at initialization time. It >>> also has dynamic libraries loaded later. yes, wine knows the memory >>> regions, but there is no guarantee there is a small number of segments >>> or that the full picture is known

Re: Kernel prctl feature for syscall interception and emulation

2020-11-19 Thread Paul Gofman
On 11/19/20 23:54, Paul Gofman wrote: > On 11/19/20 20:57, David Laight wrote: >>>> The Windows code is not completely loaded at initialization time. It >>>> also has dynamic libraries loaded later. yes, wine knows the memory >>>> regions, but there

Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas

2020-05-31 Thread Paul Gofman
Hi! thanks for looking into this. On 5/31/20 08:56, Gabriel Krisman Bertazi wrote: > >> Is it possible to disassemble and instrument the Windows code to insert >> breakpoints (or emulation calls) at all the Windows syscall points? > Hi Kees, > > I considered instrumenting the syscall

Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas

2020-05-31 Thread Paul Gofman
On 5/31/20 03:59, Andy Lutomirski wrote: > > I’m suggesting that the kernel learn how to help you, maybe like this: > > prctl(PR_SET_SYSCALL_THUNK, target, address_of_unredirected_syscall, 0, 0, 0, > 0); > > This would be inherited on clone/fork and cleared on execve. > If we are talking about

Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas

2020-05-31 Thread Paul Gofman
On 5/31/20 19:49, Matthew Wilcox wrote: > On Sun, May 31, 2020 at 03:39:33PM +0300, Paul Gofman wrote: >>> Paul (cc'ed) is the wine expert, but my understanding is that memory >>> allocation and initial program load of the emulated binary will go >>> through wine. I

Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas

2020-05-31 Thread Paul Gofman
On 5/31/20 20:31, Matthew Wilcox wrote: > If it's the cost of the syscall that's the problem, there are ways > around that. We'd still want a personality() call to indicate that > the syscall handler should look (somewhere) to determine the current > personality, but that could be issued at the

Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas

2020-05-31 Thread Paul Gofman
On 5/31/20 21:10, Andy Lutomirski wrote: > > That's not what I meant. I meant that you would set the kernel up to > redirect *all* syscalls from the thread with the sole exception of one > syscall instruction in the thunk. This would catch Windows syscalls > and Linux syscalls. The thunk would

Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas

2020-05-31 Thread Paul Gofman
On 5/31/20 21:57, Andy Lutomirski wrote: > > I think that the implementation may well want to live in seccomp, but > doing this as a seccomp filter isn't quite right. It's not a security > thing -- it's an emulation thing. Seccomp is all about making > inescapable sandboxes, but that's not what