linux-kernel - Re: [PATCH 9/9] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180315180731.mnbpqjte4wafnzd3@treble>
Date:   Thu, 15 Mar 2018 13:07:31 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     X86 ML <x86@...nel.org>, Andy Lutomirski <luto@...capital.net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 9/9] x86/dumpstack: Explain the reasoning for the
 prologue and buffer size

On Thu, Mar 15, 2018 at 04:44:48PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov <bp@...e.de>
> 
> 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 <bp@...e.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 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:

s/The/There/

> + *
> + * 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
> 

-- 
Josh