linux-kernel - Re: [tip:x86/cpu] x86, msr: change msr-reg.o to obj-y, and export its symbols

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4AA33D83.6000401@zytor.com>
Date:	Sat, 05 Sep 2009 21:41:39 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <petkovbb@...glemail.com>, mingo@...hat.com,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/cpu] x86, msr: change msr-reg.o to obj-y, and export
 its symbols

On 09/05/2009 02:57 AM, Borislav Petkov wrote:
> On Fri, Sep 04, 2009 at 05:06:47PM +0000, tip-bot for H. Peter Anvin wrote:
>> x86, msr: change msr-reg.o to obj-y, and export its symbols
>>
>> Change msr-reg.o to obj-y (it will be included in virtually every
>> kernel since it is used by the initialization code for AMD processors)
> 
> Yeah, about that, I'm wondering whether a more fine grained
> Kconfig suboptions would be appropriate here. Currently,
> <arch/x86/kernel/cpu/{intel,amd}.c> are sprinkled with the
> 
> if (c->x86 == XX) { apply quirks }
> 
> thingies and we could put those into their own files which are
> built/linked only when enabled. Before that, you would have chosen
> the CPU vendor and the CPU family thus pulling only the related
> quirks/fixes. Distros will of course need to enable all of them. Then,
> all those different families quirks should be iterated over in a manner
> similar to the initcall mechanism.
> 
> Anyways, just an idea - it could be dumb overengineering but on a
> first glance it will organize/simplify the quirks code, reduce kernel
> image proper, get rid of Kconfig options like CONFIG_X86_F00F_BUG,
> vendor-specific cpuinfo_x86 members like fdiv_bug, f00f_bug, coma_bug,
> and [add another good reason here :)].
> 

Ultimately the right thing to do would be to have the linker do these
kinds of things.  This is easy enough when one deals with things that
have to be linked into the kernel binary, but the msr-reg issue is that
both the kernel proper and a module depend on the same thing... making
it a lib means the module doesn't get it.

All of this gets ugly, and I felt it wasn't enough code to worry about
in this case.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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