[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] x86: use fixed read-only IDT



On Tue, Apr 9, 2013 at 5:14 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 04/09/2013 09:39 AM, Kees Cook wrote:
>> -
>>  static void __cpuinit intel_smp_check(struct cpuinfo_x86 *c)
>>  {
>>       /* calling is from identify_secondary_cpu() ? */
>> @@ -206,8 +192,7 @@ static void __cpuinit intel_workarounds(struct 
>> cpuinfo_x86 *c)
>>       /*
>>        * All current models of Pentium and Pentium with MMX technology CPUs
>>        * have the F0 0F bug, which lets nonprivileged users lock up the
>> -      * system.
>> -      * Note that the workaround only should be initialized once...
>> +      * system. Announce that the fault handler will be checking for it.
>>        */
>>       c->f00f_bug = 0;
>>       if (!paravirt_enabled() && c->x86 == 5) {
>> @@ -215,7 +200,6 @@ static void __cpuinit intel_workarounds(struct 
>> cpuinfo_x86 *c)
>>
>>               c->f00f_bug = 1;
>>               if (!f00f_workaround_enabled) {
>> -                     trap_init_f00f_bug();
>>                       printk(KERN_NOTICE "Intel Pentium with F0 0F bug - 
>> workaround enabled.\n");
>>                       f00f_workaround_enabled = 1;
>>               }
>
> Why do we care about this message anymore?  It provides no relevant user
> information, the flag itself is already in /proc/cpuinfo, and the
> message is likely to be wrong since all it does is look for an Intel CPU
> with family == 5.

I have no objection to removing it, but with CONFIG_F00F_BUG, the trap
handler does still do some checking, and I figured this message was
there to notify people about it.

-Kees

--
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.