linux-kernel - Re: [RFC PATCH 6/7] x86/kexec: Debugging support: Dump registers on exception

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: <3008CD3D-FF34-4FD1-83EB-DD74398685A5@zytor.com>
Date: Tue, 05 Nov 2024 14:08:35 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: David Woodhouse <dwmw2@...radead.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
        "jpoimboe@...nel.org" <jpoimboe@...nel.org>
CC: "horms@...nel.org" <horms@...nel.org>, "x86@...nel.org" <x86@...nel.org>,
        "bp@...en8.de" <bp@...en8.de>, "mingo@...hat.com" <mingo@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "kai.huang@...el.com" <kai.huang@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "nik.borisov@...e.com" <nik.borisov@...e.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: Re:  [RFC PATCH 6/7] x86/kexec: Debugging support: Dump registers on exception

On November 5, 2024 1:29:54 PM PST, David Woodhouse <dwmw2@...radead.org> wrote:
>On Tue, 2024-11-05 at 12:50 -0800, H. Peter Anvin wrote:
>> On November 5, 2024 12:38:10 PM PST, "Woodhouse, David" <dwmw@...zon.co.uk> wrote:
>> > On Sun, 2024-11-03 at 05:35 +0000, David Woodhouse wrote:
>> > > 
>> > > +
>> > > +/* Print the byte in %bl, clobber %rax */
>> > > +SYM_CODE_START_LOCAL_NOALIGN(pr_byte)
>> > > +       movb    %bl, %al
>> > > +       nop
>> > > +       andb    $0x0f, %al
>> > > +       addb    $0x30, %al
>> > > +       cmpb    $0x3a, %al
>> > > +       jb      1f
>> > > +       addb    $('a' - '0' - 10), %al
>> > > +1:     pr_char
>> > > +       ANNOTATE_UNRET_SAFE
>> > > +       ret
>> > > +SYM_CODE_END(pr_byte)
>> > > +
>> > 
>> > Obviously that function name (and comment) are wrong; fixed in my tree.
>> > at
>> > https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/kexec-debug
>> > 
>> > This function (and also pr_qword) are also what objtool is complaining
>> > about:
>> > 
>> > vmlinux.o: warning: objtool: relocate_range+0x2f6: unreachable instruction
>> > vmlinux.o: warning: objtool: relocate_range+0x305: unreachable instruction
>> > 
>> > I don't quite see why, because pr_qword() quite blatantly calls
>> > pr_nyblle(), as it's now named. And exc_handler() repeatedly calls
>> > pr_qword().
>> > 
>> > But most of the objtool annotations I've added here were just to make
>> > it shut up and build, without much though. Peter, Josh, any chance you
>> > can help me fix it up please?
>> > 
>> > It would also be really useful if objtool would let me have data inside
>> > a "code" segment, without complaining that it can't decode it as
>> > instructions — and without also failing to decode the first instruction
>> > of the *subsequent* function. I've put the GDT at the end to work
>> > around that, but it's a bit nasty.
>> 
>> code in the data *section* or *segment*? Either is nasty, though. That's what .rodata is for.
>
>This is the relocate_kernel() function in
>arch/x86/kernel/relocate_kernel_64.S
>
>It's copied into a separate page, called (in its original location) as
>a simple function from the kernel, changes %cr3 to set of identity-
>mapped page tables and jumps to its *identity-mapped* address, then
>copies all the right pages for kexec and jumps into the new kernel.
>
>So it's all in a single page, and currently it plays nasty tricks to
>store data after the code. Perhaps it *should* have its own code and
>data sections and a linker script to keep them together...

Yes, it should.