linux-kernel - Re: [PATCH] x86, boot: add hex output for debugging

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] [day] [month] [year] [list]

Date:	Fri, 31 Oct 2014 16:56:22 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Kees Cook <keescook@...omium.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>, Vivek Goyal <vgoyal@...hat.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Junjie Mao <eternal.n08@...il.com>
Subject: Re: [PATCH] x86, boot: add hex output for debugging

On Fri, Oct 31, 2014 at 01:55:33PM -0700, Kees Cook wrote:
> On Fri, Oct 31, 2014 at 1:33 PM,  <josh@...htriplett.org> wrote:
> > On Fri, Oct 31, 2014 at 09:20:37AM -0700, Kees Cook wrote:
> >> This is useful for reporting various addresses or other values while
> >> debugging early boot.
> >>
> >> Signed-off-by: Kees Cook <keescook@...omium.org>
> >
> > You haven't provided any user of this function.  I don't think this
> > should get merged without a caller (nor should an artificial caller be
> > added).  What's your use case for adding this?
> 
> I'll fix that.

Thanks.

> > Also, while I realize __putstr already has this problem, ideally all the
> > printing functions in this file should go in some separate source file
> > that gets omitted when !CONFIG_PRINTK (or possibly
> > !CONFIG_EARLY_PRINTK).
> 
> Hm, I don't agree: we need error_putstr, not just debug_putstr, and
> early_printk is just for serial console, where as __putstr works
> against the boot block's defined video area too, IIUC.

OK, that seems like a good argument that it shouldn't go under
EARLY_PRINTK.  However, for size-constrained systems that have nowhere
for the output to go at all, it still makes sense to compile all of the
printing infrastructure out of the decompression stub, especially since
that code itself does not get compressed and thus has a higher impact
than code in vmlinux.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/