linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ali Raza <aliraza@bu.edu>
To: Andy Lutomirski <luto@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
	masahiroy@kernel.org, michal.lkml@markovi.net,
	Nick Desaulniers <ndesaulniers@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	juri.lelli@redhat.com, vincent.guittot@linaro.org,
	dietmar.eggemann@arm.com, Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>,
	mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com,
	Paolo Bonzini <pbonzini@redhat.com>,
	jpoimboe@kernel.org, linux-doc@vger.kernel.org,
	linux-kbuild@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
	the arch/x86 maintainers <x86@kernel.org>,
	rjones@redhat.com, munsoner@bu.edu, tommyu@bu.edu,
	drepper@redhat.com, lwoodman@redhat.com, mboydmcse@gmail.com,
	okrieg@bu.edu, rmancuso@bu.edu
Subject: Re: [RFC UKL 07/10] x86/signal: Adjust signal handler register values and return frame
Date: Thu, 6 Oct 2022 17:20:40 -0400	[thread overview]
Message-ID: <fd0c0121-ec9e-94d7-e03e-1493799378dc@bu.edu> (raw)
In-Reply-To: <40484dc2-8da3-486d-9c53-02ae23a50fbb@app.fastmail.com>

On 10/4/22 13:34, Andy Lutomirski wrote:
> 
> 
> On Mon, Oct 3, 2022, at 3:21 PM, Ali Raza wrote:
>> For a UKL thread, returning to a signal handler is not done with iret or
>> sysret.  This means we need to adjust the way the return stack frame is
>> handled for these threads.  When constructing the signal frame, we leave
>> the previous frame in place because we will return to it from the signal
>> handler.  We also leave space for pushing eflags and the return address.
>> UKL threads will only use the __KERNEL_DS value in the ss register and 0xC3
>> in the cs register.
> 
> This is unclear.  Are you taking about returning from the kernel fault code *to* the signal handler or are you talking about returning *from* the user signal hander to the user code that was running when the signal happened?
> 
> In any case, I don't see what this has to do with iret or sysret.  Surely UKL can use a sigreturn() just like regular Linux.
> 
> The part where a UKL thread has permission to return to a CPL0 context should be a separate patch.
> 
> --Andy

Yes, the commit message should have been clearer. 

The changes in __setup_rt_frame make sure that in case of a UKL thread,
the new frame should have the UKL specific regs->cs and regs->ds values,
and not have them overwritten with __USER_CS and __USER_DS. This helps
creating the correct iret frame in the interrupt return case where an
iret is used.

After the signal handler is invoked, user code calls sigreturn() as it
normally would. Once inside the rt_sigreturn() system call, UKL case is
handled a little different than normal. This is because UKL invokes
systems calls as function calls, so user stack gets a return address.
Also, UKL stores eflags on the user stack. This is used on return from
system calls in UKL, where we first switch to the user stack, then
restore flags through popfq. This restarts the interrupts so it is
important to have already switched to user stack from kernel stack. Once
flags are restored, we do a ret instead of iret. 

So, in rt_sigreturn() system call, we calculate the correct UKL regs->sp
by allowing space for the flags and return address on stack. Second, in
restore_sigcontext(), we again make sure that regs->cs and regs->ss are
only updated to user values for non UKL case.

Since, this patch involves both the signal handling and sigreturn case,
yes this can be broken into two patches.




  reply	other threads:[~2022-10-06 21:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 22:21 [RFC UKL 00/10] Unikernel Linux (UKL) Ali Raza
2022-10-03 22:21 ` [RFC UKL 01/10] kbuild: Add sections and symbols to linker script for UKL support Ali Raza
2022-10-03 22:21 ` [RFC UKL 02/10] x86/boot: Load the PT_TLS segment for Unikernel configs Ali Raza
2022-10-04 17:30   ` Andy Lutomirski
2022-10-06 21:00     ` Ali Raza
2022-10-03 22:21 ` [RFC UKL 03/10] sched: Add task_struct tracking of kernel or application execution Ali Raza
2022-10-03 22:21 ` [RFC UKL 04/10] x86/entry: Create alternate entry path for system calls Ali Raza
2022-10-04 17:43   ` Andy Lutomirski
2022-10-06 21:12     ` Ali Raza
2022-10-03 22:21 ` [RFC UKL 05/10] x86/uaccess: Make access_ok UKL aware Ali Raza
2022-10-04 17:36   ` Andy Lutomirski
2022-10-06 21:16     ` Ali Raza
2022-10-03 22:21 ` [RFC UKL 06/10] x86/fault: Skip checking kernel mode access to user address space for UKL Ali Raza
2022-10-03 22:21 ` [RFC UKL 07/10] x86/signal: Adjust signal handler register values and return frame Ali Raza
2022-10-04 17:34   ` Andy Lutomirski
2022-10-06 21:20     ` Ali Raza [this message]
2022-10-03 22:21 ` [RFC UKL 08/10] exec: Make exec path for starting UKL application Ali Raza
2022-10-03 22:21 ` [RFC UKL 09/10] exec: Give userspace a method for starting UKL process Ali Raza
2022-10-04 17:35   ` Andy Lutomirski
2022-10-06 21:25     ` Ali Raza
2022-10-03 22:21 ` [RFC UKL 10/10] Kconfig: Add config option for enabling and sample for testing UKL Ali Raza
2022-10-04  2:11   ` Bagas Sanjaya
2022-10-06 21:28     ` Ali Raza
2022-10-07 10:21       ` Masahiro Yamada
2022-10-13 17:08         ` Ali Raza
2022-10-06 21:27 ` [RFC UKL 00/10] Unikernel Linux (UKL) H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fd0c0121-ec9e-94d7-e03e-1493799378dc@bu.edu \
    --to=aliraza@bu.edu \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=drepper@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=lwoodman@redhat.com \
    --cc=masahiroy@kernel.org \
    --cc=mboydmcse@gmail.com \
    --cc=mgorman@suse.de \
    --cc=michal.lkml@markovi.net \
    --cc=mingo@redhat.com \
    --cc=munsoner@bu.edu \
    --cc=ndesaulniers@google.com \
    --cc=okrieg@bu.edu \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rjones@redhat.com \
    --cc=rmancuso@bu.edu \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tommyu@bu.edu \
    --cc=vincent.guittot@linaro.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vschneid@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).