From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932812AbeCOPr7 (ORCPT ); Thu, 15 Mar 2018 11:47:59 -0400 Received: from mail.skyhub.de ([5.9.137.197]:48032 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752687AbeCOPqi (ORCPT ); Thu, 15 Mar 2018 11:46:38 -0400 From: Borislav Petkov To: X86 ML Cc: Andy Lutomirski , Josh Poimboeuf , Linus Torvalds , Peter Zijlstra , LKML Subject: [PATCH 9/9] x86/dumpstack: Explain the reasoning for the prologue and buffer size Date: Thu, 15 Mar 2018 16:44:48 +0100 Message-Id: <20180315154448.16222-10-bp@alien8.de> X-Mailer: git-send-email 2.13.0 In-Reply-To: <20180315154448.16222-1-bp@alien8.de> References: <20180315154448.16222-1-bp@alien8.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Borislav Petkov The whole reasoning behind the amount of opcode bytes dumped and prologue length isn't very clear so let's hold down some of the reasons for why it is done the way it is. Signed-off-by: Borislav Petkov --- arch/x86/kernel/dumpstack.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index bb712ca99632..7ceba3c09ad7 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -70,6 +70,25 @@ static void printk_stack_address(unsigned long address, int reliable, printk("%s %s%pB\n", log_lvl, reliable ? "" : "? ", (void *)address); } +/* + * The are a couple of reasons for the 2/3rd prologue, courtesy of Linus: + * + * In case where we don't have the exact kernel image (which, if we did, we can + * simply disassemble and navigate to the RIP), the purpose of the bigger + * prologue is to have more context and to be able to correlate the code from + * the different toolchains better. + * + * In addition, it helps in recreating the register allocation of the failing + * kernel and thus make sense of the register dump. + * + * What is more, the additional complication of a variable length insn arch like + * x86 warrants having longer byte sequence before rIP so that the disassembler + * can "sync" up properly and find instruction boundaries when decoding the + * opcode bytes. + * + * Thus, the 2/3rds prologue and 64 byte OPCODE_BUFSIZE is just a random + * guesstimate in attempt to achieve all of the above. + */ void show_opcodes(u8 *rip, const char *loglvl) { #define OPCODE_BUFSIZE 64 -- 2.13.0