On Fri, Jun 26, 2020 at 11:49 AM Gabriel Krisman Bertazi
wrote:
> We couldn't patch Windows code because of the aforementioned DRM and
> anti-cheat mechanisms, but I suppose this limitation doesn't apply to
> Wine/native code, and if this assumption is correct, this approach could
> work.
>
> One
"Robert O'Callahan" writes:
> rr (https://rr-project.org, https://arxiv.org/abs/1705.05937) grapples
> with a similar problem. We need to intercept commonly-executed system
> calls and wrap them with our own processing, with minimal overhead. I
> think our basic approach might work for Wine
rr (https://rr-project.org, https://arxiv.org/abs/1705.05937) grapples
with a similar problem. We need to intercept commonly-executed system
calls and wrap them with our own processing, with minimal overhead. I
think our basic approach might work for Wine without kernel changes.
We use
Andy Lutomirski writes:
> On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski wrote:
>>
>>
>> What if there was a special filter type that ran a BPF program on each
>> syscall, and the program was allowed to access user memory to make its
>> decisions, e.g. to look at some list of memory
On Fri, May 29, 2020 at 11:01 PM Gabriel Krisman Bertazi
wrote:
>
> Modern Windows applications are executing system call instructions
> directly from the application's code without going through the WinAPI.
> This breaks Wine emulation, because it doesn't have a chance to
> intercept and emulate
On Mon, Jun 1, 2020 at 1:08 PM Kees Cook wrote:
>
> On Sun, May 31, 2020 at 02:03:48PM -0700, Andy Lutomirski wrote:
> > On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski wrote:
> > >
> > >
> > > What if there was a special filter type that ran a BPF program on each
> > > syscall, and the program
On Sun, May 31, 2020 at 02:03:48PM -0700, Andy Lutomirski wrote:
> On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski wrote:
> >
> >
> > What if there was a special filter type that ran a BPF program on each
> > syscall, and the program was allowed to access user memory to make its
> > decisions,
Andy Lutomirski writes:
> On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski wrote:
>>
>>
>> What if there was a special filter type that ran a BPF program on each
>> syscall, and the program was allowed to access user memory to make its
>> decisions, e.g. to look at some list of memory
Paul Gofman writes:
> 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
Matthew Wilcox writes:
> 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. It does the allocation and mark the vma
On June 1, 2020 6:59:26 AM PDT, Andy Lutomirski wrote:
>
>
>> On Jun 1, 2020, at 2:23 AM, Billy Laws wrote:
>>
>>
>>>
>>> On May 30, 2020, at 5:26 PM, Gabriel Krisman Bertazi
> wrote:
>>>
>>> Andy Lutomirski writes:
>>>
>>> On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
>
> On Jun 1, 2020, at 2:23 AM, Billy Laws wrote:
>
>
>>
>> On May 30, 2020, at 5:26 PM, Gabriel Krisman Bertazi
>> wrote:
>>
>> Andy Lutomirski writes:
>>
>> On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
>> wrote:
>
> Modern Windows applications are
> On May 30, 2020, at 5:26 PM, Gabriel Krisman Bertazi
> wrote:
>
> Andy Lutomirski writes:
>
On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
wrote:
>>>
>>> Modern Windows applications are executing system call instructions
>>> directly from the application's code without
> On May 31, 2020, at 4:50 PM, Brendan Shanks wrote:
>
>
>> On May 31, 2020, at 11:57 AM, Andy Lutomirski wrote:
>>
>> Using SECCOMP_RET_USER_NOTIF is likely to be considerably more
>> expensive than my scheme. On a non-PTI system, my approach will add a
>> few tens of ns to each
> On May 31, 2020, at 11:57 AM, Andy Lutomirski wrote:
>
> Using SECCOMP_RET_USER_NOTIF is likely to be considerably more
> expensive than my scheme. On a non-PTI system, my approach will add a
> few tens of ns to each syscall. On a PTI system, it will be worse.
> But using any kind of
On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski wrote:
>
>
> What if there was a special filter type that ran a BPF program on each
> syscall, and the program was allowed to access user memory to make its
> decisions, e.g. to look at some list of memory addresses. But this
> would explicitly
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
On Sun, May 31, 2020 at 11:36 AM Paul Gofman wrote:
>
> 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
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
On Sun, May 31, 2020 at 5:56 AM Paul Gofman wrote:
>
> 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
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
On Sun, May 31, 2020 at 08:10:18PM +0300, Paul Gofman wrote:
> 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
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. It does the allocation and mark
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. It does the allocation and mark the vma accordingly
> > before returning
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
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
Kees Cook writes:
> On Sat, May 30, 2020 at 01:59:53AM -0400, Gabriel Krisman Bertazi wrote:
>> Modern Windows applications are executing system call instructions
>> directly from the application's code without going through the WinAPI.
>> This breaks Wine emulation, because it doesn't have a
> On May 30, 2020, at 5:26 PM, Gabriel Krisman Bertazi
> wrote:
>
> Andy Lutomirski writes:
>
On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
wrote:
>>>
>>> Modern Windows applications are executing system call instructions
>>> directly from the application's code
Andy Lutomirski writes:
>> On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
>> wrote:
>>
>> Modern Windows applications are executing system call instructions
>> directly from the application's code without going through the WinAPI.
>> This breaks Wine emulation, because it doesn't have
> On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
> wrote:
>
> Modern Windows applications are executing system call instructions
> directly from the application's code without going through the WinAPI.
> This breaks Wine emulation, because it doesn't have a chance to
> intercept and
On Sat, May 30, 2020 at 01:59:53AM -0400, Gabriel Krisman Bertazi wrote:
> Modern Windows applications are executing system call instructions
> directly from the application's code without going through the WinAPI.
> This breaks Wine emulation, because it doesn't have a chance to
> intercept and
Modern Windows applications are executing system call instructions
directly from the application's code without going through the WinAPI.
This breaks Wine emulation, because it doesn't have a chance to
intercept and emulate these syscalls before they are submitted to Linux.
In addition, we cannot
32 matches
Mail list logo
