[Top][All Lists]

[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: Samuel Thibault
Subject: Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point
Date: Sun, 5 Mar 2023 21:17:59 +0100
User-agent: NeoMutt/20170609 (1.8.3)


Sergey Bugaev, le dim. 05 mars 2023 23:12:42 +0300, a ecrit:
> 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,

Indeed, we would want to see the values.

> 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.

Indeed, it would be simpler for userland to just preserve the values.

I.e. save them and restore them into i386_saved_state, like the
callee-saved registers.


reply via email to

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