linux-kernel - Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor

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: <m1slkfvinh.fsf@ebiederm.dsl.xmission.com>
Date:	Tue, 01 Aug 2006 22:57:54 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andi Kleen <ak@...e.de>
Cc:	linux-kernel@...r.kernel.org, Horms <horms@...ge.net.au>,
	Jan Kratochvil <lace@...kratochvil.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	Magnus Damm <magnus.damm@...il.com>,
	Vivek Goyal <vgoyal@...ibm.com>, Linda Wang <lwang@...hat.com>
Subject: Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor

Andi Kleen <ak@...e.de> writes:

>> > Actually the best way to reuse would be to first do 64bit uncompressor
>> > and linker directly, but short of that #includes would be fine too.
>> 
>> > Would be better to just pull in lib/string.c
>> 
>> Maybe.  Size is fairly important 
>
> Why is size important here?

For the same reason that we compress the kernel. ;)

This is the one chunk of code that we don't compress so every extra
byte makes our executable bigger.  Now I think the code size is
actually in the 32k - 64k range so as long as it is a minor change
it doesn't really matter.

The big pain with using lib/string.c and
arch/x86_64/kernel/early_printk.c is that it is significant change
in how the code of misc.c is constructed.  Which means some
serious reevaluation of all kinds of things need to be considered.
Making it a lot of work :)

One of the practical dangers is that we make it more likely
we can kill the boot by messing up the shared code.

I'm not certain what to think when even including normal
kernel headers causes problems.  It certainly makes me leery
of including normal kernel code.  But it might simplify some
of the problems too.

Whichever way I go scrutinizing that possibility carefully is
a lot of work.

Eric
-
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/