[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87blfuvbtb.fsf@collabora.com>
Date: Wed, 18 Nov 2020 12:01:36 -0500
From: Gabriel Krisman Bertazi <krisman@...labora.com>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: luto@...nel.org, tglx@...utronix.de, keescook@...omium.org,
christian.brauner@...ntu.com, peterz@...radead.org,
willy@...radead.org, shuah@...nel.org,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
linux-kselftest@...r.kernel.org, x86@...nel.org, gofmanp@...il.com,
kernel@...labora.com
Subject: Re: [PATCH v7 0/7] Syscall User Dispatch
Florian Weimer <fw@...eb.enyo.de> writes:
> * Gabriel Krisman Bertazi:
>
>> This is the v7 of syscall user dispatch. This version is a bit
>> different from v6 on the following points, after the modifications
>> requested on that submission.
>
> Is this supposed to work with existing (Linux) libcs, or do you bring
> your own low-level run-time libraries?
Hi Florian,
The main use case is to intercept Windows system calls of an application
running over Wine. While Wine is using an unmodified glibc to execute
its own native Linux syscalls, the Windows libraries might be directly
issuing syscalls that we need to capture. So there is a mix. While this
mechanism is compatible with existing libc, we might have other
libraries executing a syscall instruction directly.
--
Gabriel Krisman Bertazi
Powered by blists - more mailing lists