From: Andrew Cooper <firstname.lastname@example.org> To: Jan Beulich <JBeulich@suse.com> Cc: Xen-devel <email@example.com>, Andy Lutomirski <firstname.lastname@example.org> Subject: Re: [PATCH 2/2] xen/x86: Introduce a new VMASSIST for architectural behaviour of iopl Date: Thu, 17 Mar 2016 11:05:26 +0000 [thread overview] Message-ID: <56EA8F76.email@example.com> (raw) In-Reply-To: <56EA9C5002000078000DDBBE@prv-mh.provo.novell.com> On 17/03/16 11:00, Jan Beulich wrote: >>>> On 17.03.16 at 11:45, <firstname.lastname@example.org> wrote: >> On 17/03/16 10:25, Jan Beulich wrote: >>>>>> On 16.03.16 at 21:05, <email@example.com> wrote: >>>> @@ -1742,8 +1742,10 @@ static void load_segments(struct vcpu *n) >>>> cs_and_mask = (unsigned short)regs->cs | >>>> ((unsigned int)vcpu_info(n, evtchn_upcall_mask) << 16); >>>> /* Fold upcall mask into RFLAGS.IF. */ >>>> - eflags = regs->_eflags & ~X86_EFLAGS_IF; >>>> + eflags = regs->_eflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL); >>> This and ... >>> >>>> @@ -1788,8 +1790,10 @@ static void load_segments(struct vcpu *n) >>>> ((unsigned long)vcpu_info(n, evtchn_upcall_mask) << 32); >>>> >>>> /* Fold upcall mask into RFLAGS.IF. */ >>>> - rflags = regs->rflags & ~X86_EFLAGS_IF; >>>> + rflags = regs->rflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL); >>> ... this is not really necessary (but also not wrong) - the actual >>> EFLAGS.IOPL is always zero (and assumed to be so by code >>> further down from the respective adjustments you make). For >>> consistency's sake it might be better to either drop the changes >>> here, or also adjust the two places masking regs->eflags. >> I will adjust the others. I would prefer not to rely on the assumption >> that it is actually 0. > But you realize that if it wasn't zero, we'd have a security issue? Indeed. But as this adjustment is literally free for us to use, making Xen a little more robust in the (hopefully never) case were IOPL ends up not being 0. ~Andrew > (This notwithstanding I'm fine with both directions, as indicated > before.) > > Jan > _______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-03-17 11:05 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-03-16 20:05 [PATCH 0/2] XSA-171 Followup work Andrew Cooper 2016-03-16 20:05 ` [PATCH 1/2] xen/x86: Don't hold TRAPBOUNCE_flags in %cl during create_bounce_frame Andrew Cooper 2016-03-16 20:05 ` [PATCH 2/2] xen/x86: Introduce a new VMASSIST for architectural behaviour of iopl Andrew Cooper 2016-03-17 10:25 ` Jan Beulich 2016-03-17 10:45 ` Andrew Cooper 2016-03-17 11:00 ` Jan Beulich 2016-03-17 11:05 ` Andrew Cooper [this message]
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=56EA8F76.email@example.com \ --firstname.lastname@example.org \ --cc=JBeulich@suse.com \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 2/2] xen/x86: Introduce a new VMASSIST for architectural behaviour of iopl' \ /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
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).