bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point


From: Sergey Bugaev
Subject: Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point
Date: Sun, 5 Mar 2023 23:12:42 +0300

On Wed, Mar 1, 2023 at 9:44 AM Luca Dariz <luca@orpolo.org> wrote:
> Il 28/02/23 15:14, Sergey Bugaev ha scritto:
> > - nothing else is clobbered, in particular not rflags (or is the
> > "reserved" half of rflags clobbered?) and not the registers that
> > contain args
>
> if we follow the usual calling conventions, the registers containing
> args are clobbered. In fact, in the code I set them to 0 before sysret,
> to avoid the risk of them containing sensitive information from the
> syscall execution.

Hmm, but if I do thread_get_state () while the thread is blocked
inside a syscall, I will see the original (pre-syscall) values of the
registers, right? This is important for inspecting the RPC being done,
see SYSCALL_EXAMINE and MSG_EXAMINE in glibc.

It would be easier if the registers were preserved after the syscall
too, but if that's not the case we should be able to work around that
in userspace. Specifically, trampoline.c wants to modify the (on-stack
for i386) values of 'option' and 'timeout' of a mach_msg call that
another thread is making, so that once INTR_MSG_TRAP returns,
_hurd_intr_rpc_mach_msg () will see the modified values. We could
maybe do the same on x86_64 by just modifying the corresponding
registers, but then we need to differentiate the registers having been
modified and now holding the new value, and having been just clobbered
by the real syscall.

Sergey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]