Messages in this thread | | | Subject | Re: [PATCH 10/39] x86/entry/32: Handle Entry from Kernel-Mode on Entry-Stack | From | Andy Lutomirski <> | Date | Fri, 13 Jul 2018 23:26:54 -0700 |
| |
> On Jul 13, 2018, at 10:21 PM, Joerg Roedel <jroedel@suse.de> wrote: > >> On Fri, Jul 13, 2018 at 04:31:02PM -0700, Andy Lutomirski wrote: >> What you're really doing is keeping it available for an extra flag. >> Please update the comment as such. But see below. > > Thanks, will do. > >>> +.macro PARANOID_EXIT_TO_KERNEL_MODE >>> + >>> + /* >>> + * Test if we entered the kernel with the entry-stack. Most >>> + * likely we did not, because this code only runs on the >>> + * return-to-kernel path. >>> + */ >>> + testl $CS_FROM_ENTRY_STACK, PT_CS(%esp) >>> + jz .Lend_\@ >>> + >>> + /* Unlikely slow-path */ >>> + >>> + /* Clear marker from stack-frame */ >>> + andl $(~CS_FROM_ENTRY_STACK), PT_CS(%esp) >>> + >>> + /* Copy the remaining task-stack contents to entry-stack */ >>> + movl %esp, %esi >>> + movl PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %edi >> >> I'm confused. Why do we need any special handling here at all? How >> could we end up with the contents of the stack frame we interrupted in >> a corrupt state? >> >> I guess I don't understand why this patch is needed. > > The patch is needed because we can get exceptions in kernel-mode while > we are already on user-cr3 and entry-stack. In this case we need to > return with user-cr3 and entry-stack to the kernel too, otherwise we > would go to user-space with kernel-cr3. > > So based on that, I did the above because the entry-stack is a per-cpu > data structure and I am not sure that we always return from the exception > on the same CPU where we got it. Therefore the path is called > PARANOID_... :)
But we should just be able to IRET and end up right back on the entry stack where we were when we got interrupted.
On x86_64, we *definitely* can’t schedule in NMI, MCE, or #DB because we’re on a percpu stack. Are you *sure* we need this patch?
> > > Regards, > > Joerg >
| |