Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type
Hi Stas, On Wed, 2017-06-07 at 21:54 +0300, Stas Sergeev wrote: > Hi Ricardo, would you mind unsubscribing > linux-msdos@ from all your future mails on > this subject? Otherwise I am afraid there > would be no subscribers left when you are > finally done. :) Sure! I will drop linux-msdos in the subsequent round of patches. > I think all non-kernel-dev MLs should be > treated with more care. Eg your initial > questions were certainly on-topic, but the > kernel patch-series (esp in such quantity) > are definitely not. Sure thing. I apologize for such a large quantity of e-mail. I just wanted to not miss your input and the inputs of your ML. I agree that at this point this can be handled in the kernel-specific MLs. Thanks and BR, Ricardo PS. Just bear with me in a couple of extra e-mails while the discussion on v7 is finished. I promise this is the last one! Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type
Hi Ricardo, would you mind unsubscribing linux-msdos@ from all your future mails on this subject? Otherwise I am afraid there would be no subscribers left when you are finally done. :) I think all non-kernel-dev MLs should be treated with more care. Eg your initial questions were certainly on-topic, but the kernel patch-series (esp in such quantity) are definitely not. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type
On Tue, Jun 06, 2017 at 05:28:52PM -0700, Ricardo Neri wrote: > I see. You were more concerned about the naming of the coding artifacts > (e.g., function names, error prints, etc) than the actual filenames. Well, I'm not sure here. We could either have a generalized prefix or put the function name in there - __func__ - for easier debuggability, i.e., find the origin of the error message faster. But I'm sensing that we're already well inside the bikeshed so let's not change anything now. :) -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type
On Tue, 2017-06-06 at 13:58 +0200, Borislav Petkov wrote: > On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote: > > I agree that insn-eval reads somewhat funny. I did not want to go with > > insn-dec.c as insn.c, in my opinion, already decodes the instruction > > (i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes). > > In insn-eval.c I simply take those decoded parameters and evaluate them > > to obtain the values they contain (e.g., a specific memory location). > > Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands? > > So actually I'm gravitating towards calling all that instruction > "massaging" code with a single prefix to denote this comes from the insn > decoder/handler/whatever... > > I.e., > > "insn-decoder: x86: invalid register type" > > or > > "inat: x86: invalid register type" > > or something to that effect. > > I mean, If we're going to grow our own - as we do, apparently - maybe it > all should be a separate entity with its proper name. I see. You were more concerned about the naming of the coding artifacts (e.g., function names, error prints, etc) than the actual filenames. I think I have aligned with the function naming of insn.c in all the functions that are exposed via header by using the inns_ prefix. For static functions I don't use that prefix. Perhaps I can use the __ prefix as insn.c does. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type
On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote: > I agree that insn-eval reads somewhat funny. I did not want to go with > insn-dec.c as insn.c, in my opinion, already decodes the instruction > (i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes). > In insn-eval.c I simply take those decoded parameters and evaluate them > to obtain the values they contain (e.g., a specific memory location). > Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands? So actually I'm gravitating towards calling all that instruction "massaging" code with a single prefix to denote this comes from the insn decoder/handler/whatever... I.e., "insn-decoder: x86: invalid register type" or "inat: x86: invalid register type" or something to that effect. I mean, If we're going to grow our own - as we do, apparently - maybe it all should be a separate entity with its proper name. Hmm. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type
On Mon, 2017-05-29 at 18:37 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:05AM -0700, Ricardo Neri wrote:
> > We are not in a critical failure path. The invalid register type is caused
> > when trying to decode invalid instruction bytes from a user-space program.
> > Thus, simply print an error message. To prevent this warning from being
> > abused from user space programs, use the rate-limited variant of printk.
> >
> > Cc: Borislav Petkov
> > Cc: Andy Lutomirski
> > Cc: Dave Hansen
> > Cc: Adam Buchbinder
> > Cc: Colin Ian King
> > Cc: Lorenzo Stoakes
> > Cc: Qiaowei Ren
> > Cc: Arnaldo Carvalho de Melo
> > Cc: Masami Hiramatsu
> > Cc: Adrian Hunter
> > Cc: Kees Cook
> > Cc: Thomas Garnier
> > Cc: Peter Zijlstra
> > Cc: Dmitry Vyukov
> > Cc: Ravi V. Shankar
> > Cc: x...@kernel.org
> > Signed-off-by: Ricardo Neri
> > ---
> > arch/x86/lib/insn-eval.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
> > index e746a6f..182e2ae 100644
> > --- a/arch/x86/lib/insn-eval.c
> > +++ b/arch/x86/lib/insn-eval.c
> > @@ -5,6 +5,7 @@
> > */
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -85,9 +86,8 @@ static int get_reg_offset(struct insn *insn, struct
> > pt_regs *regs,
> > break;
> >
> > default:
> > - pr_err("invalid register type");
> > - BUG();
> > - break;
> > + printk_ratelimited(KERN_ERR "insn-eval: x86: invalid register
> > type");
>
> You can use pr_err_ratelimited() and define "insn-eval" with pr_fmt.
> Look for examples in the tree.
Will do. I have looked at the examples.
>
> Btw, "insn-eval" is perhaps not the right name - since we're building
> an instruction decoder, maybe it should be called "insn-dec" or so. I'm
> looking at those other arch/x86/lib/insn.c, arch/x86/include/asm/inat.h
> things and how they're starting to morph into one decoding facility,
> AFAICT.
I agree that insn-eval reads somewhat funny. I did not want to go with
insn-dec.c as insn.c, in my opinion, already decodes the instruction
(i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes).
In insn-eval.c I simply take those decoded parameters and evaluate them
to obtain the values they contain (e.g., a specific memory location).
Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands?
Thanks and BR,
Ricardo
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type
On Fri, May 05, 2017 at 11:17:05AM -0700, Ricardo Neri wrote:
> We are not in a critical failure path. The invalid register type is caused
> when trying to decode invalid instruction bytes from a user-space program.
> Thus, simply print an error message. To prevent this warning from being
> abused from user space programs, use the rate-limited variant of printk.
>
> Cc: Borislav Petkov
> Cc: Andy Lutomirski
> Cc: Dave Hansen
> Cc: Adam Buchbinder
> Cc: Colin Ian King
> Cc: Lorenzo Stoakes
> Cc: Qiaowei Ren
> Cc: Arnaldo Carvalho de Melo
> Cc: Masami Hiramatsu
> Cc: Adrian Hunter
> Cc: Kees Cook
> Cc: Thomas Garnier
> Cc: Peter Zijlstra
> Cc: Dmitry Vyukov
> Cc: Ravi V. Shankar
> Cc: x...@kernel.org
> Signed-off-by: Ricardo Neri
> ---
> arch/x86/lib/insn-eval.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
> index e746a6f..182e2ae 100644
> --- a/arch/x86/lib/insn-eval.c
> +++ b/arch/x86/lib/insn-eval.c
> @@ -5,6 +5,7 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -85,9 +86,8 @@ static int get_reg_offset(struct insn *insn, struct pt_regs
> *regs,
> break;
>
> default:
> - pr_err("invalid register type");
> - BUG();
> - break;
> + printk_ratelimited(KERN_ERR "insn-eval: x86: invalid register
> type");
You can use pr_err_ratelimited() and define "insn-eval" with pr_fmt.
Look for examples in the tree.
Btw, "insn-eval" is perhaps not the right name - since we're building
an instruction decoder, maybe it should be called "insn-dec" or so. I'm
looking at those other arch/x86/lib/insn.c, arch/x86/include/asm/inat.h
things and how they're starting to morph into one decoding facility,
AFAICT.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type
We are not in a critical failure path. The invalid register type is caused
when trying to decode invalid instruction bytes from a user-space program.
Thus, simply print an error message. To prevent this warning from being
abused from user space programs, use the rate-limited variant of printk.
Cc: Borislav Petkov
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Adam Buchbinder
Cc: Colin Ian King
Cc: Lorenzo Stoakes
Cc: Qiaowei Ren
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Kees Cook
Cc: Thomas Garnier
Cc: Peter Zijlstra
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index e746a6f..182e2ae 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -5,6 +5,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -85,9 +86,8 @@ static int get_reg_offset(struct insn *insn, struct pt_regs
*regs,
break;
default:
- pr_err("invalid register type");
- BUG();
- break;
+ printk_ratelimited(KERN_ERR "insn-eval: x86: invalid register
type");
+ return -EINVAL;
}
if (regno >= nr_registers) {
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
