linux-kernel - Re: Patches for REALLY TINY 386 kernels

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: <469AA8D4.2070206@zytor.com>
Date:	Sun, 15 Jul 2007 16:08:04 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jonathan Campbell <jon@...dgrounds.com>
CC:	linux-kernel@...r.kernel.org, torvalds@...nsmeta.com
Subject: Re: Patches for REALLY TINY 386 kernels

Jonathan Campbell wrote:
> I wrote a set of patches out of concern that even if you compile a 386
> kernel a lot of code irrelevent to legacy machines still remains. Things
> like the Pentium TSC register, DMI information, ESCD parsing, and the
> use of CPUID do not apply to these machines, but looking at System.map
> you can see they're still there.
> 
> Already with these patches I can compile a zImage kernel that is 450kb
> large (890kb decompressed) with a small initramfs payload, floppy and
> kernel module support, FPU emulation, that can successfully boot on an
> ancient 386 laptop with only 1MB of extended memory. Eventually what I'd
> like to have is the ability to compile a pure 386 kernel with all
> non-386 functions removed (and perhaps the same for 486 machines).
> 
> These patches were written against the vanilla 2.6.21.1 kernel. They
> will have no effect UNLESS you make menuconfig and explicitly enable
> them there.

These should all probably depend on EMBEDDED (which is the "allow
features to be disabled which would be dangerous for most people".)

CONFIG_X86_TSC, however, would be cleaner implemented by something like:

#ifdef CONFIG_X86_TSC
int disable_tsc;
#else
#define disable_tsc 1
#endif

... then gcc will optimize out the rest of the code.

The CPUID stuff hacks up the code quite a bt which makes it hard to
read.  Can you abstract any of that code so it doesn't get so ugly?

Stuff like:

+#ifndef CONFIG_X86_DONT_CPUID
 	if (cpu_has_fxsr) {
 		/*
 		 * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
@@ -1177,6 +1178,7 @@
 		set_in_cr4(X86_CR4_OSXMMEXCPT);
 		printk("done.\n");
 	}
+#endif

... is much better handled by forcing the value of the cpu_has_* macros
to zero, in which case gcc optimizes out the if clause.  The current git
HEAD has handling of constant cpu_* going the other way, but it should
be easy enough to extend.

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