All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, acme@redhat.com,
	ming.m.lin@intel.com, robert.richter@amd.com, ravitillo@lbl.gov,
	yrl.pp-manager.tt@hitachi.com,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [RFC PATCH] x86: Add a sanity test of x86 decoder
Date: Tue, 18 Oct 2011 08:54:53 +0200	[thread overview]
Message-ID: <20111018065453.GL16304@elte.hu> (raw)
In-Reply-To: <20111013110127.28099.19162.stgit@localhost.localdomain>


* Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:

> Add a sanity test of x86 insn decoder against the random
> input. This test is also able to reproduce the bug by
> passing random-seed and iteration-number, or by passing
> input while which has invalid byte code.

Looks good in general.

a few nitpicking details:

> -posttest: $(obj)/test_get_len vmlinux
> +quiet_cmd_sanitytest = TEST    $@
> +      cmd_sanitytest = $(obj)/insn_sanity $(posttest_64bit) -m 1000000

Just curious, what's the execution time for this? I'd expect 
milliseconds, but there will also be urandom overhead.

> +#define unlikely(cond) (cond)
> +
> +#include <asm/insn.h>
> +#include <inat.c>
> +#include <insn.c>
> +
> +/*
> + * Test of instruction analysis against tampering.
> + * Feed random binary to instruction decoder and ensure not to
> + * access out-of-instruction-buffer.
> + */
> +
> +#define DEFAULT_MAX_ITER	10000
> +#define INSN_NOP 0x90
> +
> +static const char *prog;
> +static int verbose;
> +static int x86_64;
> +static unsigned int seed;
> +static unsigned long nr_iter;
> +static unsigned long max_iter = DEFAULT_MAX_ITER;
> +static char insn_buf[MAX_INSN_SIZE * 2];
> +static FILE *input_file;

This needs more comments and a bit more vertical structure.

> +static void dump_stream(FILE *fp, const char *msg, struct insn *insn)
> +{
> +	int i;
> +	fprintf(fp, "%s:\n code:", msg);

missing newline.

> +static int get_next_insn(void)
> +{
> +	char buf[256]  = "", *tmp;
> +	int i;
> +
> +	tmp = fgets(buf, 256, input_file);

ARRAY_SIZE().

> +	if (tmp == NULL || feof(input_file))
> +		return 0;
> +
> +	for (i = 0; i < MAX_INSN_SIZE; i++) {
> +		((unsigned char *)insn_buf)[i] = (unsigned char)strtoul(tmp, &tmp, 16);

why is this cast needed? Shouldnt insn_buf[] have this type if this 
is how it's used?

> +{
> +	int i;
> +	if (nr_iter >= max_iter)

missing newline.

> +	for (i = 0; i < MAX_INSN_SIZE; i += 2)
> +		*(unsigned short *)(&insn_buf[i]) = random() & 0xffff;

this silently assumes that MAX_INSN_SIZE is a multiple of 2. Which is 
true ... for now.

> +#define insn_complete(insn)	\
> +	(insn.opcode.got && insn.modrm.got && insn.sib.got && \
> +	 insn.displacement.got && insn.immediate.got)

This could move into insn.h (even though only user-space uses it), 
right?

> +	while (generate_random_insn()) {


this loop is really weird: half of it is hidden in 
generate_random_insn()'s use of nr_iter global variable!

Why not just do it in the old-fashioned way:

	for (i = 0; i < max_iter; i++) {
		...
	}

and keep generate_random_insn() loop-invariant?

> +		if (insn.next_byte <= insn.kaddr ||
> +		    insn.kaddr + MAX_INSN_SIZE < insn.next_byte) {
> +			/* Access out-of-range memory */
> +			dump_stream(stdout, "Find access violation", &insn);
> +			warnings++;

s/Find/Found ?

> +	if (warnings)
> +		fprintf(stdout, "Warning: decoded and checked %d insns with %d warnings (seed:0x%x)\n", insns, warnings, seed);
> +	else
> +		fprintf(stdout, "Succeed: decoded and checked %d insns (seed:0x%x)\n", insns, seed);

s/Succeed/Success ?

Also, s/insns/random instructions - there's rarely any good reason to 
abbreviate in human readable output.

Thanks,

	Ingo

  reply	other threads:[~2011-10-18  6:56 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-06 14:49 [PATCH 00/12] perf_events: add support for sampling taken branches Stephane Eranian
2011-10-06 14:49 ` [PATCH 01/12] perf_events: add generic taken branch sampling support Stephane Eranian
2011-10-06 16:57   ` Peter Zijlstra
2011-10-07 10:28     ` Stephane Eranian
2011-10-07 10:32       ` Peter Zijlstra
2011-10-07 10:44         ` Stephane Eranian
2011-10-06 17:01   ` Peter Zijlstra
2011-10-06 14:49 ` [PATCH 02/12] perf_events: add Intel LBR MSR definitions Stephane Eranian
2011-10-06 14:49 ` [PATCH 03/12] perf_events: add Intel X86 LBR sharing logic Stephane Eranian
2011-10-06 14:49 ` [PATCH 04/12] perf_events: sync branch stack sampling with X86 precise_sampling Stephane Eranian
2011-10-06 17:25   ` Peter Zijlstra
2011-10-07 10:34     ` Stephane Eranian
2011-10-07 10:37       ` Peter Zijlstra
2011-10-06 14:49 ` [PATCH 05/12] perf_events: add LBR mappings for PERF_SAMPLE_BRANCH filters Stephane Eranian
2011-10-06 14:49 ` [PATCH 06/12] perf_events: implement PERF_SAMPLE_BRANCH for Intel X86 Stephane Eranian
2011-10-06 17:54   ` Peter Zijlstra
2011-10-06 18:05   ` Peter Zijlstra
2011-10-06 14:49 ` [PATCH 07/12] perf_events: add LBR software filter support " Stephane Eranian
2011-10-06 15:32   ` Andi Kleen
2011-10-06 16:43     ` Peter Zijlstra
2011-10-06 17:14       ` Andi Kleen
2011-10-10  6:08         ` Ingo Molnar
2011-10-10  9:39           ` Peter Zijlstra
2011-10-07  7:06       ` Masami Hiramatsu
2011-10-07 10:38     ` Stephane Eranian
2011-10-07 10:40       ` Stephane Eranian
2011-10-07 10:42         ` Peter Zijlstra
2011-10-07 10:49           ` Stephane Eranian
2011-10-07 11:18             ` Peter Zijlstra
2011-10-07 11:21             ` Peter Zijlstra
2011-10-07 11:54               ` Masami Hiramatsu
2011-10-07 13:31                 ` [PATCH] x86: Fix insn decoder for longer instruction Masami Hiramatsu
2011-10-10  7:04                   ` Ingo Molnar
2011-10-10  6:09                 ` [PATCH 07/12] perf_events: add LBR software filter support for Intel X86 Ingo Molnar
2011-10-10 14:05                   ` Masami Hiramatsu
2011-10-10 14:45                     ` Andi Kleen
2011-10-11 12:59                       ` Masami Hiramatsu
2011-10-12  7:06                         ` Ingo Molnar
2011-10-13 10:54                           ` Masami Hiramatsu
2011-10-13 11:01                           ` [RFC PATCH] x86: Add a sanity test of x86 decoder Masami Hiramatsu
2011-10-18  6:54                             ` Ingo Molnar [this message]
2011-10-19  4:29                               ` Masami Hiramatsu
2011-10-19  6:44                                 ` Ingo Molnar
2011-10-20 14:01                                   ` [RFC PATCH v2 1/2] " Masami Hiramatsu
2011-11-18 23:16                                     ` [tip:perf/core] x86, perf: Add a build-time sanity test to the " tip-bot for Masami Hiramatsu
2011-10-20 14:01                                   ` [RFC PATCH v2 2/2] [RESEND] x86: Fix insn decoder for longer instruction Masami Hiramatsu
2011-10-07 15:42             ` [PATCH 07/12] perf_events: add LBR software filter support for Intel X86 Andi Kleen
2011-10-07 11:25       ` Masami Hiramatsu
2011-10-07 11:40         ` Peter Zijlstra
2011-10-07 15:44           ` Andi Kleen
2011-10-07 15:09         ` Andi Kleen
2011-10-07 16:05           ` Peter Zijlstra
2011-10-06 14:49 ` [PATCH 08/12] perf_events: disable PERF_SAMPLE_BRANCH_* when not supported Stephane Eranian
2011-10-06 18:53   ` Peter Zijlstra
2011-10-06 14:49 ` [PATCH 09/12] perf_events: add hook to flush branch_stack on context switch Stephane Eranian
2011-10-06 14:49 ` [PATCH 10/12] perf: add code to support PERF_SAMPLE_BRANCH_STACK Stephane Eranian
2011-10-06 18:50   ` Peter Zijlstra
2011-10-07 10:25     ` Stephane Eranian
2011-10-07 10:27       ` Peter Zijlstra
2011-10-06 14:49 ` [PATCH 11/12] perf: add support for sampling taken branch to perf record Stephane Eranian
2011-10-06 14:49 ` [PATCH 12/12] perf: add support for taken branch sampling to perf report Stephane Eranian
2011-10-06 15:25 ` [PATCH 00/12] perf_events: add support for sampling taken branches Andi Kleen
2011-10-07 10:23   ` Stephane Eranian
2011-10-06 18:32 ` Peter Zijlstra
2011-10-06 21:41   ` Stephane Eranian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111018065453.GL16304@elte.hu \
    --to=mingo@elte.hu \
    --cc=acme@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=ming.m.lin@intel.com \
    --cc=peterz@infradead.org \
    --cc=ravitillo@lbl.gov \
    --cc=robert.richter@amd.com \
    --cc=tglx@linutronix.de \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.