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: <B4EBAF27-5E42-4088-9857-DBCD0D19305C@zytor.com>
Date: Tue, 05 Nov 2024 18:47:13 -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 6:43:44 PM PST, David Woodhouse <dwmw2@...radead.org> wrote:
>On Tue, 2024-11-05 at 13:37 -0800, H. Peter Anvin wrote:
>> 
>> Looking at your code, you have a much bigger problem here:
>> 
>> +/*
>> + * This allows other types of serial ports to be used.
>> + *  - %al: Character to be printed (no clobber %rax)
>> + *  - %rdx: MMIO address or port.
>> + */
>> +.macro pr_char
>> +       outb    %al, %dx
>> +.endm
>> +
>> 
>> This will overflow your UART buffer very quickly since you are now 
>> dumping a whole bunch of data. The URT buffer -- if you even have one
>> and it is enabled -- is only 16 bytes in a standard 16550A UART. In 
>> older UARTs (or emulated older UARTs) you might not have a buffer at 
>> all. To print more than a handful of bytes, you need to poll for the 
>> THRE bit=1 (bit 5 of register 5).
>
>Emulated UARTs are generally fine because they don't really emulate the
>buffer at all. And when I originally wrote this it was purely a hack to
>debug an issue for myself, and used a different type of logging device
>altogether.
>
>But yeah, if this were to be used on bare metal 16550A it would indeed
>need to wait for space in the FIFO/THR.
>
>> What is the point of writing this code in assembly in the first place? A 
>> much more logical thing to do is to just push the registers you haven't 
>> pushed already onto the stack and call a C function to do the actual 
>> dumping? It isn't like it is in any shape, way or form performance critical.
>
>If we fix it up to use a proper linker script, that's slightly more
>feasible. As things stand, it's only really possible to do it in the
>existing asm file. 
>
>And it's only the core of the exception handler "function" which could
>be moved out to C; it didn't seem particularly worth bothering. Would
>be nice to have the IDT generated from C code *before* calling
>relocate_kernel() instead of inside relocate_kernel itself, perhaps,
>but I was also trying to keep the #define DEBUG version of the code
>fairly self-contained.
>
>

Yes, the linker script needs to happen. 

This is a case of doing it right vs doing it quickly.