(2015/01/16 0:22), Andy Lutomirski wrote: > On Jan 15, 2015 4:37 AM, "Masami Hiramatsu" > <[email protected]> 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 <[email protected]> >>> --- >>> 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: [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
