linux-kernel - Re: [PATCH v3 0/9] MIPS: Unify low-level debugging functionalities

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]

Date: Sun, 26 May 2024 13:44:07 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, 
    linux-kernel@...r.kernel.org, 
    Philippe Mathieu-Daudé <philmd@...aro.org>
Subject: Re: [PATCH v3 0/9] MIPS: Unify low-level debugging functionalities

On Wed, 22 May 2024, Jiaxun Yang wrote:

> That being said, have you noticed that prom_putchar and early_printk is
> a non-extant on generic mach, ingenic, ralink etc? That's because we
> really don't want to introduce any platform specific UART code for
> early debugging on new platforms. With DEBUG_LL introduced by Arm it's
> only a Kconfig option to do the trick.

 IMHO that is however the logical thing to do.  And then you need no magic 
options to fiddle with and say a distribution kernel will dump whatever it 
has to say if something wrong has happened early on.

 IOW just wire `prom_putchar' as required, using C code preferably.  NB 
YAMON does have a `print' entry point for console output, so for the Malta 
platform you can trivially use just that, no need for messy ad hoc 8250 
code.

 As to intercepting exceptions, it depends.  Again YAMON does handle that 
and dumps the register state, so with the Malta you get the information 
required.  For less capable ones it might make sense, but it ISTM like a 
candidate for an independent change, and then again I fail to see why the 
handler has to be written in the assembly language rather than C.

  Maciej