linux-kernel - Re: [PATCH 3.19 v4 2/2] x86: Enforce maximum instruction size in the instruction decoder

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54B86334.9060507@hitachi.com>
Date:	Fri, 16 Jan 2015 10:02:44 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Dave Hansen <dave.hansen@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>
Subject: Re: [PATCH 3.19 v4 2/2] x86: Enforce maximum instruction size in
 the instruction decoder

(2015/01/16 0:22), Andy Lutomirski wrote:
> On Jan 15, 2015 4:37 AM, "Masami Hiramatsu"
> <masami.hiramatsu.pt@...achi.com> wrote:
>>
>> (2015/01/14 6:49), Andy Lutomirski wrote:
>>> x86 instructions cannot exceed 15 bytes, and the instruction decoder
>>> should enforce that.  Prior to 6ba48ff46f76, the instruction length
>>> limit was implicitly set to 16, which was an approximation of 15,
>>> but there is currently no limit at all.
>>>
>>> Fix the decoder to reject instructions that exceed 15 bytes.
>>> A subsequent patch (targetted for 3.20) will fix MAX_INSN_SIZE.
>>
>> Hmm, is there any problem to just change MAX_INSN_SIZE to 15?
> 
> I don't want to do that for 3.19.  It's kind of late.
> 
>>
>>> Other than potentially confusing some of the decoder sanity checks,
>>> I'm not aware of any actual problems that omitting this check would
>>> cause.
>>>
>>> Fixes: 6ba48ff46f76 x86: Remove arbitrary instruction size limit in instruction decoder
>>> Signed-off-by: Andy Lutomirski <luto@...capital.net>
>>> ---
>>>  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 2480978b31cc..7b80745d2c5a 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
>>> +      * input buffer is long enough to hold them.
>>> +      */
>>> +     if (buf_len > 15)
>>> +             buf_len = 15;
>>> +
>>
>> Without changing the MAX_INSN_SIZE, this looks very odd, since all other
>> code suppose that the max length of an instruction is 16 (MAX_INSN_SIZE)
>> except here.
> 
> I thought this was your suggestion.  Did I misunderstand?

Yes, what I meant about "15" was the the "15" in the comment.
So

+     /*
+      * Instructions longer than MAX_INSN_SIZE bytes are invalid even if the
+      * input buffer is long enough to hold them.
+      */
+     if (buf_len > MAX_INSN_SIZE)
+             buf_len = MAX_INSN_SIZE;

is acceptable.

> If you think the current code is okay for 3.19, I can fold the two
> patches together and send for 3.20.

If it does really cause a bug or a real problem, it must fix asap.
If not, I'd like to fix this issue with changing MAX_INSN_SIZE to 15.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/