linux-kernel - [tip:x86/cleanups] x86/dumpstack: Explain the reasoning for the prologue and buffer size

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] [day] [month] [year] [list]

Message-ID: <tip-4dba072cd097f35fa8f77c49d909ada2b079a4c4@git.kernel.org>
Date:   Thu, 26 Apr 2018 07:22:50 -0700
From:   tip-bot for Borislav Petkov <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     jpoimboe@...hat.com, torvalds@...ux-foundation.org,
        peterz@...radead.org, tglx@...utronix.de, hpa@...or.com,
        mingo@...nel.org, luto@...capital.net,
        linux-kernel@...r.kernel.org, bp@...e.de
Subject: [tip:x86/cleanups] x86/dumpstack: Explain the reasoning for the
 prologue and buffer size

Commit-ID:  4dba072cd097f35fa8f77c49d909ada2b079a4c4
Gitweb:     https://git.kernel.org/tip/4dba072cd097f35fa8f77c49d909ada2b079a4c4
Author:     Borislav Petkov <bp@...e.de>
AuthorDate: Tue, 17 Apr 2018 18:11:24 +0200
Committer:  Thomas Gleixner <tglx@...utronix.de>
CommitDate: Thu, 26 Apr 2018 16:15:28 +0200

x86/dumpstack: Explain the reasoning for the prologue and buffer size

The whole reasoning behind the amount of opcode bytes dumped and prologue
length isn't very clear so write down some of the reasons for why it is
done the way it is.

Signed-off-by: Borislav Petkov <bp@...e.de>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Lutomirski <luto@...capital.net>
Link: https://lkml.kernel.org/r/20180417161124.5294-10-bp@alien8.de

---
 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 ee344030fd0a..666a284116ac 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -72,6 +72,25 @@ static void printk_stack_address(unsigned long address, int reliable,
 	printk("%s %s%pB\n", log_lvl, reliable ? "" : "? ", (void *)address);
 }
 
+/*
+ * There 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)
 {
 	unsigned int code_prologue = OPCODE_BUFSIZE * 2 / 3;