From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752055AbbCYEKa (ORCPT ); Wed, 25 Mar 2015 00:10:30 -0400 Received: from ozlabs.org ([103.22.144.67]:49518 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbbCYEK0 (ORCPT ); Wed, 25 Mar 2015 00:10:26 -0400 From: Rusty Russell To: Denys Vlasenko Cc: lguest@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] lguest: simplify lguest_iret In-Reply-To: <55117432.7060604@redhat.com> References: <1426974173-22145-1-git-send-email-dvlasenk@redhat.com> <877fu8jsqu.fsf@rustcorp.com.au> <55117432.7060604@redhat.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Wed, 25 Mar 2015 14:08:56 +1030 Message-ID: <871tkdiw4v.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Denys Vlasenko writes: > On 03/23/2015 04:30 AM, Rusty Russell wrote: >> + * They may be about to iret, where they asked us never to >> + * deliver interrupts. In this case, we can emulate that iret >> + * then immediately deliver the interrupt. This is bascially >> + * a noop: the iret would pop the interrupt frame and restore >> + * eflags, and then we'd set it up again. So just restore the >> + * eflags word and jump straight to the handler in this case. >> */ >> + if (cpu->regs->eip >= cpu->lg->noirq_start && >> + (cpu->regs->eip < cpu->lg->noirq_end)) { >> + restore_eflags(cpu); > > In truth, this is not _exactly_ true for irets to CPL3. > > If a new interrupt comes right after iret, then > a new transition to CPL0 will happen. > > This means ss:esp will be loaded from tss.ss0:tss.sp0. > > Meaning, that the new iret frame may be in a different place > than the one which was used by iret. True. We could check the to-be-restored-CPL and reset the sp. Instead, I've added this comment: /* * They may be about to iret, where they asked us never to * deliver interrupts. In this case, we can emulate that iret * then immediately deliver the interrupt. This is basically * a noop: the iret would pop the interrupt frame and restore * eflags, and then we'd set it up again. So just restore the * eflags word and jump straight to the handler in this case. * * Denys Vlasenko points out that this isn't quite right: if * the iret was returning to userspace, then that interrupt * would reset the stack pointer (which the Guest told us * about via LHCALL_SET_STACK). But unless the Guest is being * *really* weird, that will be the same as the current stack * anyway. */ > There is no good reason for CPL0 code to move iret frame around, > but who knows. As an example, look what 32-bit Linux kernel does > with NMI iret frames... it's mind bending. Fortunately, lguest is allergic to NMIs :) Thanks! Rusty.