On Tue, Dec 01, 2020 at 02:21:45AM +0900, Masami Hiramatsu wrote:
> Because it overruns the buffer. Maybe -E2BIG/ENODATA or any other
> error (except for -EINVAL) is OK :)
ENODATA it is. :)
And propagating that error value is easy because the err_out: labels are
all coming from the
On Mon, 30 Nov 2020 14:44:42 +0100
Borislav Petkov wrote:
> On Sun, Nov 29, 2020 at 05:50:05PM +0900, Masami Hiramatsu wrote:
> > Good point. I think we can return, e.g. -EFAULT if we failed in
> > get_next(). Then, we can read out next page, for example.
>
> Why -EFAULT?
Because it overruns
On Sun, Nov 29, 2020 at 05:50:05PM +0900, Masami Hiramatsu wrote:
> Good point. I think we can return, e.g. -EFAULT if we failed in
> get_next(). Then, we can read out next page, for example.
Why -EFAULT?
Running this
size = 1;
ret = insn_decode(, b, size, INSN_MODE_64)
i.e.,
On Fri, 27 Nov 2020 09:45:39 -0800
Andy Lutomirski wrote:
> On Tue, Nov 24, 2020 at 9:46 AM Borislav Petkov wrote:
> >
> > On Tue, Nov 24, 2020 at 11:19:33AM +0100, Borislav Petkov wrote:
> > > In any case, at least the case where I give it
> > >
> > > 0x48 0xcf 0x48 0x83
> > >
> > > and say
On Fri, Nov 27, 2020 at 09:45:39AM -0800, Andy Lutomirski wrote:
> Is -22 (-EINVAL) the same error it returns if you pass in garbage?
Define garbage.
Yes, if you have a sequence of bytes which you can unambiguously
determine to be
- an invalid instruction in some of the tables
- REX prefix
On Tue, Nov 24, 2020 at 9:46 AM Borislav Petkov wrote:
>
> On Tue, Nov 24, 2020 at 11:19:33AM +0100, Borislav Petkov wrote:
> > In any case, at least the case where I give it
> >
> > 0x48 0xcf 0x48 0x83
> >
> > and say that buf size is 4, should return an error because the second
> > insn is
On Tue, 24 Nov 2020 18:46:47 +0100
Borislav Petkov wrote:
> On Tue, Nov 24, 2020 at 11:19:33AM +0100, Borislav Petkov wrote:
> > In any case, at least the case where I give it
> >
> > 0x48 0xcf 0x48 0x83
> >
> > and say that buf size is 4, should return an error because the second
> > insn is
On Tue, Nov 24, 2020 at 11:19:33AM +0100, Borislav Petkov wrote:
> In any case, at least the case where I give it
>
> 0x48 0xcf 0x48 0x83
>
> and say that buf size is 4, should return an error because the second
> insn is incomplete. So I need to go look at that now.
Ok, got it:
From: Borislav Petkov
Hi,
here's what I had in mind, finally split into proper patches. The final
goal is for all users of the decoder to simply call insn_decode() and
look at its retval. Simple.
As to amluto's question about detecting partial insns, see the diff
below.
Running that gives:
9 matches
Mail list logo
