Re: OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- From: Pat Welch <patubb@xxxxxxxxxxx>
- Date: Thu, 27 Apr 2006 14:52:51 -0700
Bela Lubkin wrote:
Bill Vermillion wrote:
If you want 64 bits stay away from AMD. They have optimized for
performance and left a security hole. OK for a desktop but
not what I'd recommend in a server.
That's an unfair characterization of the FreeBSD security announcement
you included (below).
The announcement describes a FreeBSD kernel security bug (of fairly low
impact) caused by a difference in processor behavior.
The CPU difference is _not_ a security hole by itself. It's FreeBSD's
handling of it that causes the hole.
The deleted "Solution" section that would have appeared in the
announcement surely says "update some bit of your system ...", i.e.
obtain the new code which is now aware of the CPU difference and does
this stuff differently.
Bela<
This is from a FreeBSD security announcment.
=============================================================================
FreeBSD-SA-06:14.fpu Security Advisory
The FreeBSD Project
Topic: FPU information disclosure
Category: core
Module: sys
Announced: 2006-04-19
Credits: Jan Beulich
Affects: All FreeBSD/i386 and FreeBSD/amd64 releases.
Corrected: 2006-04-19 07:00:35 UTC (RELENG_6, 6.1-STABLE)
2006-04-19 07:00:50 UTC (RELENG_6_1, 6.1-RELEASE)
2006-04-19 07:01:12 UTC (RELENG_6_0, 6.0-RELEASE-p7)
2006-04-19 07:01:30 UTC (RELENG_5, 5.5-STABLE)
2006-04-19 07:01:53 UTC (RELENG_5_4, 5.4-RELEASE-p14)
2006-04-19 07:02:23 UTC (RELENG_5_3, 5.3-RELEASE-p29)
2006-04-19 07:02:43 UTC (RELENG_4, 4.11-STABLE)
2006-04-19 07:03:01 UTC (RELENG_4_11, 4.11-RELEASE-p17)
2006-04-19 07:03:14 UTC (RELENG_4_10, 4.10-RELEASE-p23)
CVE Name: CVE-2006-1056
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>.
I. Background
The floating-point unit (FPU) of i386 and amd64 processors is derived from
the original 8087 floating-point co-processor. As a result, the FPU
contains the same debugging registers FOP, FIP, and FDP which store the
opcode, instruction address, and data address of the instruction most
recently executed by the FPU.
On processors implementing the "SSE" instruction set, a new pair of
instructions fxsave/fxrstor replaces the earlier fsave/frstor pair used
for saving and restoring the FPU state. These new instructions also
save and restore the contents of the additional registers used by SSE
instructions.
II. Problem Description
On "7th generation" and "8th generation" processors manufactured by AMD,
including the AMD Athlon, Duron, Athlon MP, Athlon XP, Athlon64, Athlon64
FX, Opteron, Turion, and Sempron, the fxsave and fxrstor instructions do
not save and restore the FOP, FIP, and FDP registers unless the exception
summary bit (ES) in the x87 status word is set to 1, indicating that an
unmasked x87 exception has occurred.
This behaviour is consistent with documentation provided by AMD, but is
different from processors from other vendors, which save and restore the
FOP, FIP, and FDP registers regardless of the value of the ES bit. As a
result of this discrepancy remaining unnoticed until now, the FreeBSD
kernel does not restore the contents of the FOP, FIP, and FDP registers
between context switches.
III. Impact
On affected processors, a local attacker can monitor the execution path
of a process which uses floating-point operations. This may allow an
attacker to steal cryptographic keys or other sensitive information.
IV. Workaround
No workaround is available, but systems which do not use AMD Athlon, Duron,
Athlon MP, Athlon XP, Athlon64, Athlon64 FX, Opteron, Turion, or Sempron
processors are not vulnerable.
V. Solution
[ rest deleted - wjv]
---------------------
AMD did reply to this, but I can't seem to find where I put the
reply.
So even though they documented this it works in a different manner
than the Intel chips. BSD had a patch to the kernel the next day
or so. I don't know which Linux kernels are affected.
If I can find the link to AMD's reply on this I"ll send it along,
but it was in a e-news letter and I probably didn't get that one
saved.
Bill
--
Bill Vermillion - bv @ wjv . com
Hi, Bela.
Whew! I have a 2 AMD64 servers and an AMD64 notebook here and at several clients and they have been ultra-reliable and very fast. Bills posting *almost* kicked me into oh-my-god mode :)
--
----------------------------------------------------
Pat Welch, UBB Computer Services, a WCS Affiliate
SCO Authorized Partner
Unix/Linux/Windows/Hardware Sales/Support
(209) 745-1401 Cell: (209) 251-9120
E-mail: patubb@xxxxxxxxxxx
----------------------------------------------------
.
- Follow-Ups:
- Re: OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- From: Bela Lubkin
- Re: OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- References:
- OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- From: XeniXman
- Re: OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- From: Pat Welch
- Re: OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- From: Bill Vermillion
- Re: OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- From: Bela Lubkin
- OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- Prev by Date: All kucenses are in use
- Next by Date: Re: Openserver 6.0.0... stty min 0 not acting the same as prior Openserver releases?
- Previous by thread: Re: OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- Next by thread: Re: OSR6 Processor confusion - P4 Xeon Extreme Hyper non-sense.
- Index(es):
Relevant Pages
|
