On Tue, Feb 16, 2010 at 10:45:15AM +0100, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Tue, Feb 16, 2010 at 10:14:56AM +0100, Jan Kiszka wrote:
> >> Gleb Natapov wrote:
> >>> On Mon, Feb 15, 2010 at 07:17:18PM +0100, Jan Kiszka wrote:
> >>>> As there is no interception on AMD on the end of an NMI handler but only
> >>>> on its iret, we are forced to step out by setting TF in rflags. This can
> >>>> collide with host or guest using single-step mode, and it may leak the
> >>>> flags onto the guest stack if IRET triggers some exception.
> >>> The code is trying to handle the case where debugger used TF flags and we
> >>> want to single step from NMI handler simultaneously. Do you see problem
> >>> with
> >>> that code? Uf yes may be it sill be much simpler to fix it? TF leakage is
> >>> real,
> >>> but what problem it may cause? Note that your patch does not solve this
> >>> problem
> >>> too. See the comment that you've deleted:
> >>> /* Something prevents NMI from been injected. Single step over
> >>> possible problem (IRET or exception injection or interrupt
> >>> shadow) */
> >>> So the reason for single step is not necessary IRET, _any_ exception
> >>> is possible at this point.
> >> That is exactly what my code tries to avoid: Exceptions are all (famous
> >> last word) caught, and single-stepping is disabled until that is
> >> resolved. So no more leakage, and only IRET remains as reason here (thus
> >> my deletion).
> >>
> > I don't understand why only IRET remains as a reason here? Code will get
> > there if interrupt shadow is in effect too and then next instruction may
> > generate any exception not only those that IRET generates.
>
> OK, so the faults raised by the instruction under the interrupt shadow
> can still cause troubles. Guess we have to live with it unless we what
> to trap all exceptions that instructions can raise. Will adjust the comment.
>
I don't see the point to complicate code significantly to fix it only
partially.
> >
> > Also you haven't answered what is the problem with current code (except
> > TF leakage) and why TF leakage is so important. BTW are you sure that TF
> > leakage actually happens? I see in Intel SDM:
> >
> > The processor clears the TF flag before calling the exception handler.
>
> Does it clear it _for_ the exception handler or also in rflags pushed on
> the stack?
Have no idea. Looking for relevant info in SDM.
>
> Besides this, proper #DB forwarding to the guest was missing.
During NMI injection? How to reproduce?
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
