linux-kernel - Re: [PATCH] x86: fdiv bug detection fix

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: <489236E9.6060804@goop.org>
Date:	Thu, 31 Jul 2008 15:04:25 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Krzysztof Helt <krzysztof.h1@...pl>, hpa@...or.com,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] x86: fdiv bug detection fix

Andrew Morton wrote:
>>  		"fwait\n\t"
>>  		"fninit"
>> -		: "=m" (*&boot_cpu_data.fdiv_bug)
>> +		: "=m" (*&fdiv_bug)
>>  		: "m" (*&x), "m" (*&y));
>>     

This (*&foo) construct is strange.  Just "m" (foo) should be enough.

>> +
>> +	boot_cpu_data.fdiv_bug = fdiv_bug;
>>  	if (boot_cpu_data.fdiv_bug)
>>  		printk("Hmm, FPU with FDIV bug.\n");
>>  }
>>     
>
> hm, the code seems to have been that way for quite some time.  I wonder
> why nobody noticed this before.  
>   

It would trash f00f_bug, coma_bug and some padding.  You'd have to be 
running a Cyrix or Intel chip dating from somewhere around 1997-1998 to 
even be subject to those bugs, and even if you were, they wouldn't hurt 
day to day.  And if it snoops for those bugs after the fdiv bug, then 
they'd get updated properly anyway.

Change looks correct.

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