Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API

2021-01-13 Thread Borislav Petkov
On Tue, Jan 12, 2021 at 08:34:46PM +0900, Masami Hiramatsu wrote: > Or, add one definition before that line. > > #define INSN_MODE_KERN -1 /* __ignore_sync_check__ */ I like that idea, thanks! And it seems to work: --- diff --git a/arch/x86/include/asm/inat.h b/arch/x86/include/asm/inat.h i

Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API

2021-01-12 Thread Masami Hiramatsu
On Fri, 8 Jan 2021 19:59:50 +0100 Borislav Petkov wrote: > On Wed, Jan 06, 2021 at 02:21:14PM +0900, Masami Hiramatsu wrote: > > So I think it is possible to introduce a keyword in a comment > > for ignoring sync check something like below. This will allow us > > a generic pattern matching. > >

Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API

2021-01-08 Thread Borislav Petkov
On Wed, Jan 06, 2021 at 02:21:14PM +0900, Masami Hiramatsu wrote: > So I think it is possible to introduce a keyword in a comment > for ignoring sync check something like below. This will allow us > a generic pattern matching. > > The keyword is just an example, "no-sync-check" etc. is OK. > > Wh

Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API

2021-01-05 Thread Masami Hiramatsu
On Wed, 30 Dec 2020 10:28:33 +0100 Borislav Petkov wrote: > I still haven't thought about what do to exactly there wrt making > sync-check.sh happy but the aspect of failing the build is a nice one. So I think it is possible to introduce a keyword in a comment for ignoring sync check something l

Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API

2020-12-30 Thread Borislav Petkov
On Wed, Dec 30, 2020 at 06:00:52PM +0900, Masami Hiramatsu wrote: > Maybe I need to replace it with dummy lines but it is possible. Dummy lines like "IGNORE DURING CHECK" or something like that? > But in [17/19], your patch seems not using INSN_MODE_KERN there. I replaced it only locally just so

Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API

2020-12-30 Thread Masami Hiramatsu
On Tue, 29 Dec 2020 21:06:54 +0100 Borislav Petkov wrote: > On Mon, Dec 28, 2020 at 10:15:10AM +0900, Masami Hiramatsu wrote: > > BTW, insn_decode() can return -EINVAL if !insn_complete(), is that OK? > > It does with this change. Or are you asking whether it returning -EINVAL > in that case is

Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API

2020-12-29 Thread Borislav Petkov
On Mon, Dec 28, 2020 at 10:15:10AM +0900, Masami Hiramatsu wrote: > BTW, insn_decode() can return -EINVAL if !insn_complete(), is that OK? It does with this change. Or are you asking whether it returning -EINVAL in that case is ok? I don't see why not - this way callers can differentiate where it

Re: [PATCH v1 03/19] x86/insn: Add an insn_decode() API

2020-12-27 Thread Masami Hiramatsu
Hi, On Wed, 23 Dec 2020 18:42:17 +0100 Borislav Petkov wrote: > From: Borislav Petkov > > Users of the instruction decoder should use this to decode instruction > bytes. For that, have insn*() helpers return an int value to denote > success/failure. When there's an error fetching the next insn

[PATCH v1 03/19] x86/insn: Add an insn_decode() API

2020-12-23 Thread Borislav Petkov
From: Borislav Petkov Users of the instruction decoder should use this to decode instruction bytes. For that, have insn*() helpers return an int value to denote success/failure. When there's an error fetching the next insn byte and the insn falls short, return -ENODATA to denote that. While at i