Hi Kailiang,
On 3/31/26 10:36 AM, XU Kailiang wrote:
> Hi,
>
> This series adds two contrib/plugins examples for the linux-user syscall
> filter API.
>
> The first patch adds a minimal zlib-based demo. It redirects the guest
> loader's library open to a local thunk library and handles the thunk's
> magic syscalls by calling the host zlib implementation directly.
>
> The second patch adds a callback-capable qsort prototype. It shows that
> the same interface can also bridge callback-style library calls back
> into guest translated code, using a small thunk library plus a
> ucontext-based host-side bridge.
>
> The final patch extends both demos from the openat()-based loader path
> to open() and openat2().
>
> To keep the examples small, both demos currently target x86_64
> linux-user and assume guest_base == 0 on a little-endian 64-bit host,
> so guest virtual addresses are directly usable as host pointers. The
> qsort prototype is built only on hosts with working ucontext support.
>
> Once the demo library path matches, both demos intentionally assert that
> opening the thunk library succeeds. These examples are meant to show the
> local-library hand-off path once a known thunk library is in place, not
> fallback behavior when that local library is missing or unusable.
>
> One limitation is worth calling out explicitly: straightforward local
> library hand-off is only part of the problem. Once execution needs to
> leave the guest, run host code, and then re-enter guest translated code
> again, for example through a host-side function pointer callback,
> additional target- and ABI-specific handling is needed. The qsort
> prototype shows one such bridge for x86_64 guest callbacks, but this
> series does not attempt to provide a general solution for that broader
> case.
>
> Patch 1 adds the zlib compression demo.
> Patch 2 adds the callback-capable qsort prototype.
> Patch 3 extends both demos to open() and openat2().
>
> Reproduction instructions are included in docs/about/emulation.rst and
> in each example directory.
>
> Thanks,
> XU Kailiang
>
> XU Kailiang (3):
> contrib/plugins: add a zlib compression filter example
> contrib/plugins: add a callback-capable qsort prototype
> contrib/plugins: handle more loader open syscalls in the syscall
> filter demos
>
> contrib/plugins/meson.build | 16 +-
> .../Makefile | 19 +
> .../README.rst | 47 ++
> .../callback-demo.c | 75 +++
> .../callback-qsort.h | 14 +
> .../callback-thunk.S | 38 ++
> .../plugins/syscall_filter_callback_qsort.c | 484 ++++++++++++++++++
> .../syscall_filter_zlib-example/Makefile | 19 +
> .../syscall_filter_zlib-example/README.rst | 44 ++
> .../zcompress-demo.c | 94 ++++
> .../zcompress-thunk.c | 35 ++
> .../zcompress-thunk.h | 16 +
> contrib/plugins/syscall_filter_zlib.c | 319 ++++++++++++
> docs/about/emulation.rst | 41 ++
> 14 files changed, 1260 insertions(+), 1 deletion(-)
> create mode 100644 contrib/plugins/syscall_filter_callback_qsort-example/Makefile
> create mode 100644 contrib/plugins/syscall_filter_callback_qsort-example/README.rst
> create mode 100644 contrib/plugins/syscall_filter_callback_qsort-example/callback-demo.c
> create mode 100644 contrib/plugins/syscall_filter_callback_qsort-example/callback-qsort.h
> create mode 100644 contrib/plugins/syscall_filter_callback_qsort-example/callback-thunk.S
> create mode 100644 contrib/plugins/syscall_filter_callback_qsort.c
> create mode 100644 contrib/plugins/syscall_filter_zlib-example/Makefile
> create mode 100644 contrib/plugins/syscall_filter_zlib-example/README.rst
> create mode 100644 contrib/plugins/syscall_filter_zlib-example/zcompress-demo.c
> create mode 100644 contrib/plugins/syscall_filter_zlib-example/zcompress-thunk.c
> create mode 100644 contrib/plugins/syscall_filter_zlib-example/zcompress-thunk.h
> create mode 100644 contrib/plugins/syscall_filter_zlib.c
>
>
> base-commit: 512b794b1091bc4810d28e8ef28addf6344c3889
that's a good demonstration of the thunk approach you have been working
on. However, I'm not sure of the value to add those manually crafted
examples upstream for now. All they test is the syscall filter, but we
already have tests for it.
In case we want to have something more useful upstream, it would be nice
to provide a plugin than can automatically execute a program linked with
any of those thunk libraries (ideally hosted somewhere, so we don't have
to compile this).
What do you think about this? Are you missing specific bits to make it work?
Regards,
Pierrick