From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 3.19 v2 3/3] x86: Enforce MAX_INSN_SIZE in the instruction decoder
Date: Tue, 13 Jan 2015 21:20:15 +0900 [thread overview]
Message-ID: <54B50D7F.2050604@hitachi.com> (raw)
In-Reply-To: <71a49f266444c8f918b895ecd70c91a6e59b011f.1421103159.git.luto@amacapital.net>
(2015/01/13 8:04), Andy Lutomirski wrote:
> The instruction decoder used to assume that the input buffer was
> exactly MAX_INSN_SIZE bytes long. Now that the input buffer has
> variable length, even if the input buffer is longer than
> MAX_INSN_SIZE, we should still reject instructions longer than
> MAX_INSN_SIZE, since a real CPU will reject them even if they're
> otherwise valid.
>
> Other than potentially confusing some of the decoder sanity checks,
> I'm not aware of any actual problems that omitting this check would
> cause.
>
> It's worth noting that MAX_INSN_SIZE is incorrectly set to 16. This
> patch doesn't change that. I'll submit a fix for that later.
Hm, this patch logic is OK, but the comment is a bit odd.
As you said, if the current code incorrectly set MAX_INSN_SIZE to 16,
the comment should not say "15" without changing MAX_INSN_SIZE itself.
Others are OK for me.
>
> Fixes: 6ba48ff46f76 x86: Remove arbitrary instruction size limit in instruction decoder
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>
> Arguably, the limit could be hard-coded as 15 instead of relying on the
> macro.
>
> arch/x86/lib/insn.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
> index 1313ae6b478b..c5912d7a4a15 100644
> --- a/arch/x86/lib/insn.c
> +++ b/arch/x86/lib/insn.c
> @@ -52,6 +52,13 @@
> */
> void insn_init(struct insn *insn, const void *kaddr, int buf_len, int x86_64)
> {
> + /*
> + * Instructions longer than 15 bytes are invalid even if the
I meant you'd better use MAX_INSN_SIZE instead of "15 bytes" here.
Thank you,
> + * input buffer is long enough to hold them.
> + */
> + if (buf_len > MAX_INSN_SIZE)
> + buf_len = MAX_INSN_SIZE;
> +
> memset(insn, 0, sizeof(*insn));
> insn->kaddr = kaddr;
> insn->end_kaddr = kaddr + buf_len;
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
prev parent reply other threads:[~2015-01-13 12:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-12 23:04 [PATCH 3.19 v2 0/3] x86, mpx: Instruction decoder fixes and hardening Andy Lutomirski
2015-01-12 23:04 ` [PATCH 3.19 v2 1/3] x86: Fix off-by-one in the instruction decoder length checks Andy Lutomirski
2015-01-12 23:13 ` Dave Hansen
2015-01-12 23:18 ` Andy Lutomirski
2015-01-12 23:04 ` [PATCH 3.19 v2 2/3] x86, mpx: Short-circuit the instruction decoder for unexpected opcodes Andy Lutomirski
2015-01-12 23:47 ` Dave Hansen
2015-01-12 23:57 ` Andy Lutomirski
2015-01-14 19:43 ` Dave Hansen
2015-01-14 20:24 ` Andy Lutomirski
2015-01-12 23:04 ` [PATCH 3.19 v2 3/3] x86: Enforce MAX_INSN_SIZE in the instruction decoder Andy Lutomirski
2015-01-13 12:20 ` Masami Hiramatsu [this message]
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=54B50D7F.2050604@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=x86@kernel.org \
/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.