> On Jul 13, 2018, at 10:21 PM, Joerg Roedel <jroedel@xxxxxxx> 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 >
