On Fri, Oct 30, 2020 at 10:24:53AM +0900, Masami Hiramatsu wrote:
> What's the objdump say here?
The expected "bad":
0: c5 ec 95(bad)
3: b2 02 mov$0x2,%dl
5: bd 4b c8 a8 36 mov$0x36a8c84b,%ebp
a: b2 c5 mov
Hi,
On Thu, 29 Oct 2020 13:42:31 +0100
Borislav Petkov wrote:
> Hi Masami,
>
> On Sat, Oct 24, 2020 at 01:27:41AM +0200, Borislav Petkov wrote:
> > @@ -230,14 +231,20 @@ void insn_get_prefixes(struct insn *insn)
> > * If necessary, first collects any preceding (prefix) bytes.
> > * Sets @in
Hi Masami,
On Sat, Oct 24, 2020 at 01:27:41AM +0200, Borislav Petkov wrote:
> @@ -230,14 +231,20 @@ void insn_get_prefixes(struct insn *insn)
> * If necessary, first collects any preceding (prefix) bytes.
> * Sets @insn->opcode.value = opcode1. No effect if @insn->opcode.got
> * is already
On Tue, 27 Oct 2020 14:42:51 +0100
Borislav Petkov wrote:
> On Sat, Oct 24, 2020 at 09:10:25AM -0700, Andy Lutomirski wrote:
> > I can pretty much guarantee that a real modern CPU is able to decode a
> > <15 byte instruction that is followed by unmapped or non-executable
> > pages. I don't know
On Sat, Oct 24, 2020 at 09:10:25AM -0700, Andy Lutomirski wrote:
> I can pretty much guarantee that a real modern CPU is able to decode a
> <15 byte instruction that is followed by unmapped or non-executable
> pages. I don't know specifically how the CPU implements it, but it
> works.
Yes, so rep
On Sat, Oct 24, 2020 at 1:23 AM Borislav Petkov wrote:
>
> On Fri, Oct 23, 2020 at 05:12:49PM -0700, Andy Lutomirski wrote:
> > I disagree. A real CPU does exactly what I'm describing. If I stick
>
> A real modern CPU fetches up to 32 bytes insn window which it tries
> to decode etc. I don't kno
On Sat, Oct 24, 2020 at 04:13:15PM +0900, Masami Hiramatsu wrote:
> Thanks, so will you split this into several patches, since I saw some
> cleanups in this patch?
Oh, most definitely. This was just a preview of where this is going...
> Yeah, that's good to me because in the most cases, user need
On Fri, Oct 23, 2020 at 05:12:49PM -0700, Andy Lutomirski wrote:
> I disagree. A real CPU does exactly what I'm describing. If I stick
A real modern CPU fetches up to 32 bytes insn window which it tries
to decode etc. I don't know, though, what it does when that fetch
encounters a fault - I will
On Fri, 23 Oct 2020 17:12:49 -0700
Andy Lutomirski wrote:
> On Fri, Oct 23, 2020 at 4:27 PM Borislav Petkov wrote:
> >
> > On Fri, Oct 23, 2020 at 07:47:04PM +0900, Masami Hiramatsu wrote:
> > > Thanks! I look forward to it.
> >
> > Ok, here's a first stab, it is a single big diff and totally un
On Sat, 24 Oct 2020 01:27:41 +0200
Borislav Petkov wrote:
> On Fri, Oct 23, 2020 at 07:47:04PM +0900, Masami Hiramatsu wrote:
> > Thanks! I look forward to it.
>
> Ok, here's a first stab, it is a single big diff and totally untested
> but it should show what I mean. I've made some notes while c
On Fri, Oct 23, 2020 at 4:27 PM Borislav Petkov wrote:
>
> On Fri, Oct 23, 2020 at 07:47:04PM +0900, Masami Hiramatsu wrote:
> > Thanks! I look forward to it.
>
> Ok, here's a first stab, it is a single big diff and totally untested
> but it should show what I mean. I've made some notes while conv
On Fri, Oct 23, 2020 at 07:47:04PM +0900, Masami Hiramatsu wrote:
> Thanks! I look forward to it.
Ok, here's a first stab, it is a single big diff and totally untested
but it should show what I mean. I've made some notes while converting,
as I went along.
Have a look at insn_decode() and its call
On Fri, 23 Oct 2020 11:32:54 +0200
Borislav Petkov wrote:
> On Fri, Oct 23, 2020 at 06:28:50PM +0900, Masami Hiramatsu wrote:
> > OK, would you think we also better to integrate it with insn_init()?
>
> That kinda makes sense because it would obviate the need to call it
> as user of the interfac
On Fri, Oct 23, 2020 at 06:28:50PM +0900, Masami Hiramatsu wrote:
> OK, would you think we also better to integrate it with insn_init()?
That kinda makes sense because it would obviate the need to call it
as user of the interface but simply do insn_decode() which will do
everything for you. Lemme
On Thu, 22 Oct 2020 10:58:32 -0700
Andy Lutomirski wrote:
> On Thu, Oct 22, 2020 at 6:21 AM Masami Hiramatsu wrote:
> >
> > On Thu, 22 Oct 2020 11:30:44 +0200
> > Borislav Petkov wrote:
> >
> > > On Thu, Oct 22, 2020 at 04:31:00PM +0900, Masami Hiramatsu wrote:
> > > > No, insn_get_length() imp
On Thu, Oct 22, 2020 at 10:58:32AM -0700, Andy Lutomirski wrote:
> I'm guessing that the confusion here is that the kernel instruction
> decoder was originally designed to be used to decode kernel
> instructions, which are generally trusted to be valid, but that it's
> starting to be used to decode
On Thu, Oct 22, 2020 at 10:21:40PM +0900, Masami Hiramatsu wrote:
> extern void insn_init(struct insn *insn, const void *kaddr, int buf_len, int
> x86_64);
> extern void insn_get_prefixes(struct insn *insn);
> extern void insn_get_opcode(struct insn *insn);
> extern void insn_get_modrm(struct insn
On Thu, Oct 22, 2020 at 6:21 AM Masami Hiramatsu wrote:
>
> On Thu, 22 Oct 2020 11:30:44 +0200
> Borislav Petkov wrote:
>
> > On Thu, Oct 22, 2020 at 04:31:00PM +0900, Masami Hiramatsu wrote:
> > > No, insn_get_length() implies it decodes whole of the instruction.
> > > (yeah, we need an alias of
On Thu, 22 Oct 2020 11:30:44 +0200
Borislav Petkov wrote:
> On Thu, Oct 22, 2020 at 04:31:00PM +0900, Masami Hiramatsu wrote:
> > No, insn_get_length() implies it decodes whole of the instruction.
> > (yeah, we need an alias of that, something like insn_get_complete())
>
> That's exactly what I'
On Thu, Oct 22, 2020 at 04:31:00PM +0900, Masami Hiramatsu wrote:
> No, insn_get_length() implies it decodes whole of the instruction.
> (yeah, we need an alias of that, something like insn_get_complete())
That's exactly what I'm trying to point out: the whole API is not
entirely wrong - it just n
On Wed, Oct 21, 2020 at 06:45:58PM +0200, Borislav Petkov wrote:
> On Wed, Oct 21, 2020 at 11:26:13PM +0900, Masami Hiramatsu wrote:
> > Hmm, I meant someone might think it can be used for filtering the
> > instruction something like,
> >
> > insn_init(insn, buf, buflen, 1);
> > ret = insn_get_len
On Wed, 21 Oct 2020 18:45:58 +0200
Borislav Petkov wrote:
> On Wed, Oct 21, 2020 at 11:26:13PM +0900, Masami Hiramatsu wrote:
> > Hmm, I meant someone might think it can be used for filtering the
> > instruction something like,
> >
> > insn_init(insn, buf, buflen, 1);
> > ret = insn_get_length(i
On Wed, Oct 21, 2020 at 11:26:13PM +0900, Masami Hiramatsu wrote:
> Hmm, I meant someone might think it can be used for filtering the
> instruction something like,
>
> insn_init(insn, buf, buflen, 1);
> ret = insn_get_length(insn);
> if (!ret) {
> /* OK, this is safe */
> patch_text(bu
On Wed, 21 Oct 2020 11:27:50 +0200
Borislav Petkov wrote:
> On Wed, Oct 21, 2020 at 09:50:13AM +0900, Masami Hiramatsu wrote:
> > Agreed. So I'm OK for returning the result of "decoding".
> > But we also need to note that the returning success doesn't
> > mean the instruction is valid. That needs
On Wed, Oct 21, 2020 at 09:50:13AM +0900, Masami Hiramatsu wrote:
> Agreed. So I'm OK for returning the result of "decoding".
> But we also need to note that the returning success doesn't
> mean the instruction is valid. That needs another validator.
>
...
>
> Yes, so let's add the return value (w
On Tue, 20 Oct 2020 16:37:46 +0200
Borislav Petkov wrote:
> On Tue, Oct 20, 2020 at 11:27:00PM +0900, Masami Hiramatsu wrote:
> > So, if this return value is optional, it is OK to me. But the success
> > return value does NOT mean it a correctly encoded instruction.
>
> Ok, so what is the correc
On Tue, Oct 20, 2020 at 11:27:00PM +0900, Masami Hiramatsu wrote:
> So, if this return value is optional, it is OK to me. But the success
> return value does NOT mean it a correctly encoded instruction.
Ok, so what is the correct way to find out whether the decoding was
successful?
Because as it
Hi Borislav,
On Tue, 20 Oct 2020 14:02:32 +0200
Borislav Petkov wrote:
> Hi guys,
>
> this has come up a couple of times in the past, how about if those insn
> decoder functions returned an error value so that callers can use that
> instead of looking at different insn...got fields whether a ce
Hi guys,
this has come up a couple of times in the past, how about if those insn
decoder functions returned an error value so that callers can use that
instead of looking at different insn...got fields whether a certain
subset of the insn got decoded properly or not?
Here's a dirty diff to show w
29 matches
Mail list logo
