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
| ||
|
Date: Mon, 27 Apr 2020 16:42:01 +0100 From: Daniel Thompson <daniel.thompson@...aro.org> To: Douglas Anderson <dianders@...omium.org> Cc: jason.wessel@...driver.com, gregkh@...uxfoundation.org, kgdb-bugreport@...ts.sourceforge.net, mingo@...hat.com, hpa@...or.com, bp@...en8.de, linux-serial@...r.kernel.org, agross@...nel.org, tglx@...utronix.de, frowand.list@...il.com, bjorn.andersson@...aro.org, jslaby@...e.com, catalin.marinas@....com, corbet@....net, will@...nel.org, Matt Mullins <mmullins@...com>, Nadav Amit <namit@...are.com>, Peter Zijlstra <peterz@...radead.org>, Rick Edgecombe <rick.p.edgecombe@...el.com>, linux-kernel@...r.kernel.org, x86@...nel.org Subject: Re: [PATCH v2 4/9] kgdb: Delay "kgdbwait" to dbg_late_init() by default On Tue, Apr 21, 2020 at 02:14:42PM -0700, Douglas Anderson wrote: > Using kgdb requires at least some level of architecture-level > initialization. If nothing else, it relies on the architecture to > pass breakpoints / crashes onto kgdb. > > On some architectures this all works super early, specifically it > starts working at some point in time before Linux parses > early_params's. On other architectures it doesn't. A survey of a few > platforms: > > a) x86: Presumably it all works early since "ekgdboc" is documented to > work here. > b) arm64: Catching crashes works; with a simple patch breakpoints can > also be made to work. > c) arm: Nothing in kgdb works until > paging_init() -> devicemaps_init() -> early_trap_init() > > Let's be conservative and, by default, process "kgdbwait" (which tells > the kernel to drop into the debugger ASAP at boot) a bit later at > dbg_late_init() time. If an architecture has tested it and wants to > re-enable super early debugging, they can implement the weak function > kgdb_arch_can_debug_early() to return true. We'll do this for x86 to > start. It should be noted that dbg_late_init() is still called quite > early in the system. > > Note that this patch doesn't affect when kgdb runs its init. If kgdb > is set to initialize early it will still initialize when parsing > early_params's. This patch _only_ inhibits the initial breakpoint > from "kgdbwait". This means: > > * Without any extra patches arm64 platforms will at least catch > crashes after kgdb inits. > * arm platforms will catch crashes (and could handle a hardcoded > kgdb_breakpoint()) any time after early_trap_init() runs, even > before dbg_late_init(). > > Signed-off-by: Douglas Anderson <dianders@...omium.org> > Cc: Thomas Gleixner <tglx@...utronix.de> > Cc: Ingo Molnar <mingo@...hat.com> > Cc: Borislav Petkov <bp@...en8.de> Overall this looks good but there is a small quibble below... > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > index b072aeb1fd78..7371517aeacc 100644 > --- a/include/linux/kgdb.h > +++ b/include/linux/kgdb.h > @@ -226,6 +226,28 @@ extern int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt); > */ > extern void kgdb_arch_late(void); > > +/** > + * kgdb_arch_can_debug_early - Check if OK to break before dbg_late_init() > + * > + * If an architecture can definitely handle entering the debugger when > + * early_param's are parsed then it can override this function to return > + * true. Otherwise if "kgdbwait" is passed on the kernel command line it > + * won't actually be processed until dbg_late_init() just after the call > + * to kgdb_arch_late() is made. > + * > + * NOTE: Even if this returns false we will still try to register kgdb to > + * handle breakpoints and crashes when early_params's are parsed, we just > + * won't act on the "kgdbwait" parameter until dbg_late_init(). If you > + * get a crash and try to drop into kgdb somewhere between these two > + * places you might or might not end up being able to use kgdb depending > + * on exactly how far along the architecture has initted. > + * > + * ALSO: dbg_late_init() is actually still fairly early in the system > + * boot process. > + * > + * Return: true if platform can handle kgdb early. > + */ > +extern bool kgdb_arch_can_debug_early(void); Does this need to be a function? It looks like all implementations are either return true or return false (e.g. CONFIG_ARCH_HAVE_EARLY_DEBUG would do the same thing). Daniel.
Powered by blists - more mailing lists