Re: [v6 PATCH 06/21] x86/insn-eval: Add utility functions to get segment selector

Ricardo Neri <[email protected]>
Newsgroups gmane.linux.msdos.general,gmane.linux.kernel,gmane.comp.emulators.wine.devel
Message-ID <1494009100.74182.13.camel@ranerica-desktop>
On Sun, 2017-04-30 at 19:15 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 01:44:43PM -0700, Ricardo Neri wrote:
> > I regard that the role of this function is to obtain the the segment
> > selector from either of the prefixes or inferred from the operands. It
> > is the role of caller to determine if the segment selector should be
> > ignored.
> 
> No, this is wrong. The function is called resolve_seg_selector() and it
> gives you the segment selector. CS, DS, ES, and SS in 64-bit mode are
> treated as null segments and your function should return/signal exactly
> that, i.e, saying that those should be ignored in that case.
> 
> > I double-checked the latest version of the Intel Software Development
> > manual [2], in the table 3-5 in section 3.7.4 mentions that DS is
> > default segment for all data references, except string destinations. I
> > tested this code with the UMIP-protected instructions and whenever I use
> > %edi the default segment is %ds.
> 
> Yes, all correct. Except that we're adding a more-or-less generic x86
> insn decoder so we should make it so...
> 
> > Is this example valid? The documentation of MOVS specifies that it
> > always moves DS:(E)SI to ES:(E)DI.
> 
> ... that the decoder should do exactly that:
> 
> 	if (MOVS and rDI)
> 		return SEG_ES;
> 
> And you're handing in struct insn * so you can easily check which insn
> you're looking at.

I see. I have submitted v7 of the series and I have implemented all the
changes above. Now I am able to identify string instructions.

Thanks and BR,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.