From owner-freebsd-bugs@FreeBSD.ORG Mon Jun 5 21:21:35 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A47D016B911 for ; Mon, 5 Jun 2006 21:10:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6030443D45 for ; Mon, 5 Jun 2006 21:10:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k55LAPnW061953 for ; Mon, 5 Jun 2006 21:10:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k55LAP0K061952; Mon, 5 Jun 2006 21:10:25 GMT (envelope-from gnats) Date: Mon, 5 Jun 2006 21:10:25 GMT Message-Id: <200606052110.k55LAP0K061952@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Rostislav Krasny Cc: Subject: Re: kern/98460 : [kernel] [patch] fpu_clean_state() cannot be disabled for not AMD processors, those are not vulnerable to FreeBSD-SA-06:14.fpu X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rostislav Krasny List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 21:21:36 -0000 The following reply was made to PR kern/98460; it has been noted by GNATS. From: Rostislav Krasny To: Bruce Evans Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/98460 : [kernel] [patch] fpu_clean_state() cannot be disabled for not AMD processors, those are not vulnerable to FreeBSD-SA-06:14.fpu Date: Tue, 6 Jun 2006 00:00:28 +0300 On Mon, 5 Jun 2006 08:25:06 +1000 (EST) Bruce Evans wrote: > On Sun, 4 Jun 2006, Rostislav Krasny wrote: > > > On Sun, 4 Jun 2006, Bruce Evans wrote: > > > The configuration should be dynamic and automatic, so that it doesn't > > > take changes to zillions of configuration files to implement and > > > document an option that almost no one will know to set. I think there > > > is a simple feature test for the AMD misfeature. > > > > David Xu had proposed something like that. But from Colin Percival's > > reply I understood that it is hard to be done effectively. See their > > discussion by the first URL in this PR. > > I don't see how it can be hard. Perhaps it is too CPU-dependent for > tests based on cpuid to be easy or future-proof, but a runtime test > in the probe would be easy. Here is a userland version. It gives the > expected result on the following systems P2(Celeron) (mine), P3 > (freefall), P4(Xeon) (nosedive), AthlonXP (mine) and Opteron (sledge). > It would crash on systems without FXSR. To be complete, the userland > version should repeat the test many times to reduce the chance of a > misprobe due to broken context switching clobbering the pointer > underneath it. The kernel version can check for FXSR more easily and > can just prevent context switching. > > %%% > #include > > #ifdef __amd64__ > #include > > static struct savefpu xmmstate; > #define en_fip en_rip > #else > #include > > static struct savexmm xmmstate; > #endif > > int > main(void) > { > /* Set up a fairly clean state with a zero last-instruction pointer. */ > asm("fninit"); > > /* Set the last-instruction pointer mod 2^32 to nonzero. */ > asm(".align 2,0x90; nop; fnop"); > > /* Try to see what the last-instruction pointer got changed to. */ > asm("fxsave xmmstate"); > > /* Have dubious AMD optimizations iff the change didn't get saved. */ > if (xmmstate.sv_env.en_fip == 0) { > printf("cpu_fxsr |= CPU_FXSR_NEEDCLEAN;\n"); > return (1); > } else { > printf("cpu_fxsr &= ~CPU_FXSR_NEEDCLEAN;\n"); > return (0); > } > } > %%% And then you want to call the fpu_clean_state() function conditionally, like in following example? if (cpu_fxsr & CPU_FXSR_NEEDCLEAN) fpu_clean_state(); But this looks same to what Davi Xu had proposed. Read what Colin Percival had replied about that proposition: http://lists.freebsd.org/pipermail/freebsd-current/2006-May/062683.html Eliminating the fpu_clean_state() by "options CPU_FXSAVE_NO_LEAK" could be used as a custom optimization. No one is obliged to use it, as well as many other CPU_* optimization options.