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: <10f2dec7afbbff6570007495185ce1c4144e446b.camel@infradead.org>
Date: Tue, 05 Nov 2024 18:43:44 -0800
From: David Woodhouse <dwmw2@...radead.org>
To: "H. Peter Anvin" <hpa@...or.com>, "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 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.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)