Re: Intel Core 2 - errata pulled?!?
At 11:01 AM 8/8/07, Nick Holland wrote: Asking Does OpenBSD support my new processor is usually missing the point. Ask if it supports your new COMPUTER. Better yet, get yourself one of those credit-card CDR blanks, drop cd42.iso on it, and carry it with you and find out, or on modern computers (duh, which we are talking about, right?), grab a USB flash drive, and put a test install on that, and you can boot the entire OS, test X, NIC, whatever, and grab a dmesg, drop it on disk and analyze it later. Excellent idea; except there is only one Lenovo laptop (its a C300) on display in computers stores in the city I live.
Re: Intel Core 2 - errata pulled?!?
Toni Mueller wrote: ... Leaving these aside, I just discovered that the i386 compatibility page does apparently not list _any_ current intel CPUs (eg. Pentium D), and the question about whether recent Xeons still classify as Xeon in this list has been raised. So, is it right to conclude that only current AMD CPUs are supported, and that recent intel CPUs are generally unsupported? from http://www.openbsd.org/i386.html : Everything that is a clone of the 486 or up should work fine. The issue is almost never the CPU itself, the issue is the surrounding support chips and firmware. There is much more to a computer than its processor. Asking Does OpenBSD support my new processor is usually missing the point. Ask if it supports your new COMPUTER. Better yet, get yourself one of those credit-card CDR blanks, drop cd42.iso on it, and carry it with you and find out, or on modern computers (duh, which we are talking about, right?), grab a USB flash drive, and put a test install on that, and you can boot the entire OS, test X, NIC, whatever, and grab a dmesg, drop it on disk and analyze it later. Nick.
Re: Intel Core 2 - errata pulled?!?
Hi, On Wed, 27.06.2007 at 11:08:16 -0600, Theo de Raadt [EMAIL PROTECTED] wrote: http://download.intel.com/design/processor/specupdt/31327914.pdf looks like intel pulled that paper. I'm unable to find it and would like to receive a private copy. An easier summary document for some people to read: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif I can read only about errors with number in the lower 30'ies on that image, which means, that I can't read about most in this list: Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare Leaving these aside, I just discovered that the i386 compatibility page does apparently not list _any_ current intel CPUs (eg. Pentium D), and the question about whether recent Xeons still classify as Xeon in this list has been raised. So, is it right to conclude that only current AMD CPUs are supported, and that recent intel CPUs are generally unsupported? While I generally like AMD better, I'd like to purchase an intel system with significant power (as a router, targetting 300kpps, that is), but don't know which one I should get. If you have an alternative suggestion for the best (in terms of power and reliability) AMD chip, I'm all ears, too. TIA! Best, --Toni++
Re: Intel Core 2 - errata pulled?!? [SOLVED]
Hi, On Tue, 07.08.2007 at 16:22:08 +0200, Toni Mueller [EMAIL PROTECTED] wrote: On Wed, 27.06.2007 at 11:08:16 -0600, Theo de Raadt [EMAIL PROTECTED] wrote: http://download.intel.com/design/processor/specupdt/31327914.pdf looks like intel pulled that paper. I'm unable to find it and would like to receive a private copy. it appears that the URL has been updated, and I was unable to find it. The current URL is http://download.intel.com/design/processor/specupdt/31327916.pdf Sorry for the noise. Best, --Toni++
Re: Intel Core 2 - errata pulled?!?
Toni Mueller [EMAIL PROTECTED] wrote: Leaving these aside, I just discovered that the i386 compatibility page does apparently not list _any_ current intel CPUs (eg. Pentium D), and the question about whether recent Xeons still classify as Xeon in this list has been raised. They are all supported and work fine, the web site simply does not keep up with intel's marketing department.
Re: Intel Core 2 - errata pulled?!?
Chris Cappuccio wrote: Toni Mueller [EMAIL PROTECTED] wrote: Leaving these aside, I just discovered that the i386 compatibility page does apparently not list _any_ current intel CPUs (eg. Pentium D), and the question about whether recent Xeons still classify as Xeon in this list has been raised. The OpenBSD server hardware compatibility list at: http://www.armorlogic.com/openbsd_information_server_compatibility_list.html is pretty decent in terms of having dmesg's from current widely deployed Intel and AMD servers.
Re: Intel Core 2 - round #2
bofh [EMAIL PROTECTED] writes: So, everyone picks up on the one thing that Linus fixed a while back, the TLB stuff. What about the rest of the bugs? The non-TLB crap? How is Art ignoring the relevance of the rest of the message? He just said, the TLB is just a minor issue, that the *OTHER* guys are ignoring the major stuff. I think that's what he said. He wasn't contradicting me, he was just amplifying my message. :) //art
Re: Intel Core 2 - round #2
On 12 Jul 2007 09:56:03 +0200, Artur Grabowski [EMAIL PROTECTED] wrote: I think that's what he said. He wasn't contradicting me, he was just amplifying my message. :) In that case, color me *blush* :) Apologies Jacob. -Tai -- This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation.
Intel Core 2 - round #2
Linus contradicts Theo on Intel TLB issue: http://blogs.zdnet.com/Ou/?p=559 Christoph
Re: Intel Core 2 - round #2
Christoph Egger [EMAIL PROTECTED] writes: Linus contradicts Theo on Intel TLB issue: http://blogs.zdnet.com/Ou/?p=559 No he doesn't. The article is confused and missed the whole point. The TLB issues are just one small part of what Theo was talking about, not even the most important one. Count the number of bugs in the errata. Only a very few of them deal with the TLB and most of those are easy to deal with and we've already had most of those right (the Core 2 problems we've been seeing are most likely caused by a different errata that the operating system can't do anything about, but I don't have any proof other than that updating the BIOS helps). The biggest, potentially exploitable, issues are other than the TLB issues. //art
Re: Intel Core 2 - round #2
On 11 Jul 2007 10:59:12 +0200, Artur Grabowski [EMAIL PROTECTED] wrote: Christoph Egger [EMAIL PROTECTED] writes: Linus contradicts Theo on Intel TLB issue: http://blogs.zdnet.com/Ou/?p=559 Count the number of bugs in the errata. Only a very few of them deal with the TLB and most of those are easy to deal with and we've already had I went and read the nice gif, there's actually another updated one somewhere on the site. If you looked at just the red ones, it's scary. There's even one with a math issue, there's one where the 2nd core does not obey the NX bit, etc. These are not TLB issues, and to me, looks scary. -- This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation.
Re: Intel Core 2 - round #2
Artur Grabowski wrote: Christoph Egger [EMAIL PROTECTED] writes: Linus contradicts Theo on Intel TLB issue: http://blogs.zdnet.com/Ou/?p=559 No he doesn't. The article is confused and missed the whole point. The TLB issues are just one small part of what Theo was talking about, not even the most important one. Count the number of bugs in the errata. Only a very few of them deal with the TLB and most of those are easy to deal with and we've already had most of those right (the Core 2 problems we've been seeing are most likely caused by a different errata that the operating system can't do anything about, but I don't have any proof other than that updating the BIOS helps). The biggest, potentially exploitable, issues are other than the TLB issues. classic computer geek argument technique: when someone presents a long-winded, obviously carefully thought-out argument you attack only the minor points that you can pick apart and ignore the relevance of the rest of the message. the term rathered comes to mind. cheers, jake //art --
Re: Intel Core 2 - round #2
On Wed, Jul 11, 2007 at 06:21:43PM -0500, Jacob Yocom-Piatt wrote: the term rathered comes to mind. what does it mean? jmc
Re: Intel Core 2 - round #2
On Thu, 12 Jul 2007, Jason McIntyre wrote: On Wed, Jul 11, 2007 at 06:21:43PM -0500, Jacob Yocom-Piatt wrote: the term rathered comes to mind. what does it mean? Dan Rather-ed JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: Intel Core 2 - round #2
On Wed, Jul 11, 2007 at 04:33:24PM -0700, John Mendenhall wrote: On Thu, 12 Jul 2007, Jason McIntyre wrote: On Wed, Jul 11, 2007 at 06:21:43PM -0500, Jacob Yocom-Piatt wrote: the term rathered comes to mind. what does it mean? Dan Rather-ed so i should have googled for it. i thought it was some horrible abuse of rather (except it is). ta jmc
Re: Intel Core 2 - round #2
On 7/11/07, Jacob Yocom-Piatt [EMAIL PROTECTED] wrote: Artur Grabowski wrote: The TLB issues are just one small part of what Theo was talking about, not even the most important one. Count the number of bugs in the errata. Only a very few of them deal with the TLB and most of those are easy to deal with and we've already had classic computer geek argument technique: when someone presents a long-winded, obviously carefully thought-out argument you attack only the minor points that you can pick apart and ignore the relevance of the rest of the message. I'm not sure what you mean. I read that interview. They're only concentrating on one item, TLB. That's all they talked about. IIRC, Theo never said TLB will assuredly be exploitable, he said some of the bugs will be. So, everyone picks up on the one thing that Linus fixed a while back, the TLB stuff. What about the rest of the bugs? The non-TLB crap? How is Art ignoring the relevance of the rest of the message? He just said, the TLB is just a minor issue, that the *OTHER* guys are ignoring the major stuff. the term rathered comes to mind. I would go for confused and not get the point. Probably throw in didn't read the original article properly, and didn't visit the referenced links as well. -- This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation.
Re: Intel Core 2
On Thu, 28 Jun 2007 15:34:05 +0100, Stuart Henderson [EMAIL PROTECTED] wrote: Lead is still permitted for some equipment (notably network infrastructure), http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32002L0095:EN:HT ML annex 7: - lead in solders for servers, storage and storage array systems (exemption granted until 2010), - lead in solders for network infrastructure equipment for switching, signalling, transmission as well as network management for telecommunication, For some reason I thought this only applied to telecommunications and medical equipment because of reliability concerns and long installed life. Are those the same reasons for including servers and storage? I suspect a lot of RoHS compliant parts will make it into exempted equipment just because of availability and difficult quality control but I would not expect this to cause any significant problems. I have not seen an exception for CdS photocells although many manufacturers have petitioned for one. Unfortunately there are a lot of esoteric applications for which they have no substitute short of complete reengineering and in some cases not even then. I expected at least the hermetically sealed ones to be exempted. http://sales.hamamatsu.com/en/products/solid-state-division/compound-semicond uctors/cds.php
Re: Intel Core 2
Hi, On 6/27/07, Theo de Raadt [EMAIL PROTECTED] wrote: Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. Full (current) errata from Intel: http://download.intel.com/design/processor/specupdt/31327914.pdf An easier summary document for some people to read: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif I don't know much about the recent history of these chips. Are there any good summaries around? don't know but I am not surprised. Intel get's kicked their butt by the AMD64 cpu's like never before. The pull out the old PIII Design modified by some other company for Low Energy and put the stuff into Laptops. But since their P4 crap can't keep up to amd. They force the same old thing into the Core CPUs. And hey, it works. They are low power and fast. But ... it's a patchwork cpu ... no new development ... not enough time to carefull test things ... structural and design flaws which can not be cared for etc... So basically this all is two PIII cores with lot's of additional logic and modifications turning it into the ultimate Franken Dualcore PIII on steroids. Of course people shouldn't really know that, they might be scared of the monster. Considering all this the CPU runs very well. Don't own one though and all the machines I care for are AMD since the AthlonXP came up. I might still buy a Laptop with it, since I will be the only user on it, the only bugs I care are those which crash the machine more often then I crash it when dropping it *g* but even there some VIA stuff hit's the marked which is quite promising and well, there's always the Zaurus. And then there is MIPS. If AMD/Intel are not carefull they might wakeup one day with mips all around. They pop up like mushrooms in corners where you don't expect them. -sm * Now please Sharp, get us a new zaurus with a bit more RAM and a higher resolution display.
Re: Intel Core 2
Constantine A. Murenin wrote: On 27/06/07, Jacob Yocom-Piatt [EMAIL PROTECTED] wrote: you make more money if your widgets break because your new widget is vastly improved. new packaging, same great defects! The best thing about computer parts randomly failing will hit us in a few years, due to RoHS directives: http://en.wikipedia.org/wiki/RoHS#Impact_on_reliability http://en.wikipedia.org/wiki/Whisker_%28metallurgy%29 Another problem that lead-free solders face is the growth of tin whiskers. These thin strands of tin can grow and make contact with an adjacent trace, developing a short circuit. Tin whiskers have already been responsible for at least one failure at a nuclear power plant. Other documented failures include satellites in orbit, aircraft in flight, and implanted medical pacemakers. Reliability decay of low-lead materials may be economically desirable for some consumer product companies because it provides a mechanism to enforce planned obsolescence and replacement. Ironically, this is the opposite of the claimed intent of RoHS legislation. C. uuhhh that's scary. Are you sure they haven't found a solution for that?
Re: Intel Core 2
rough translation from swedish to english of: http://strombergson.com/kryptoblog/?p=311 begin Intel Advannced Management Technology - Rootkit's for everyone intel just released a new x86 cpu, one new addition avaiding the news is the AMT (Active Management Technology) AMT is a technology intended to facilitate survailance, maintenance and control computers remotely. AMT allows for the following funcitons among others: * Monitor and control (filter) the network traffic - before/under the running operatingsystem * sending out patches to computers - even if they are turned off. * Control, upgrade, change, add and remove software * isolate and shutdown computers infected with viruses * control on/off of the power supply * re-route hdd access to a location on the network * re-route mouse, keyboard, screen and other extras to a location on the network AMT is based on functions in the chipset that allows chipsets to communicate with other chips out-of-band from the CPU, options include LAN, serial interfaces or a direct ethernet interface. image http://softwarecommunity.intel.com/UserFiles/en-us/figure_1(1).gif /image Ergo, there is a microcontroller in the MCU that is always on (as long as the system has power through the power supply) and can recieve and perform instructions even though the system appears to be turned off. The microcontroller is floating in a software environment that implements a huge number of service functions and gives customers the option to add their own functions translators note: does anyone remember the bios resident virus of mid to late 90's? end translators note. image http://softwarecommunity.intel.com/UserFiles/en-us/figure_2(1).gif /image one of the most important parts is the feature or function to communicate with the machine through a separate TCP/IP stack, in other words, even if there is a firewall or other security countermeasures in place protecting the operatingsystems TCP/IP stack, there is a side channel into the system. translators note: rant goes here end translators note. image http://softwarecommunity.intel.com/UserFiles/en-us/figure_3.gif /image So AMT gives systemowners and administrators brand new ways to monitor and control a large number of PC's. AMT will be shipped with a XML (SOAP) based system for managing and administrating AMT clients. But at the same time, the hair on my arms and raise thinking of what would happend should this technology be used for evil purposes. How easy would it be to detect and protect oneself from the rootkits that will sneak into AMT. Rutkowskas Blue Pill is in theory dangerously close. There are security functions in AMT to ensure this will not happend, namely Kerberos and Active Directory based authentication, further on the built in sidechannel TCP/IP stack offers TLS based communication. For those that want to know more about AMT link 1 there are several pages on intel's website link 2. There is also a developerskit (SDK) for AMT available free of change on intels site link 3 link 1 http://www.intel.com/technology/manage/iamt/ link 2 : http://www.intel.com/business/vpro/index.htm link 3 : http://www.intel.com/cd/ids/developer/asmo-na/eng/321157.htm On 6/27/07, Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: On Wed, Jun 27, 2007 at 04:25:08PM -0300, Leonardo Rodrigues wrote: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full .gif Show stopper Potentially Catastrophic Those are some warm and fuzzy words =) Geez, that's a whole lot of bugs... I never imagined that processors could be so bugged. Theo says that AMD is getting less helpful towards open source OS. Well, that's great. We only have 2 big proc developers for i386, and now those two are turning out crap products with diminishing documentation =( I wonder where this road will lead us. If you really want to know... http://strombergson.com/kryptoblog/?p=311 I'd really love to read a translation of that document, but it seems to say something along the lines of... Basically, the new Celeron seems to have a separate memory and process manager that can hide the thread and memory that does ... stuff. But the chip is creepier than that. If I am understanding Strvmbergson correctly, this chip is the first step in a brave new world where you have no clue what really goes on when you buy a chip. About Strombergson: Strvmbergson is one of Sweden's foremost experts on hardware design (ASIC) and keeps a couple of software patents too (trie sorting ip addresses for routing i.e). -- Or not. Today is Pungenday, the 32nd day of Confusion in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? [demime 1.01d removed an attachment of type application/pgp-signature] -- -- JPL
Intel Core 2 problems and OpenBSD Security
-- Forwarded message -- From: Theo de Raadt [EMAIL PROTECTED] Date: Jun 27, 2007 10:38 PM Subject: Intel Core 2 To: [EMAIL PROTECTED] Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold. Full (current) errata from Intel: http://download.intel.com/design/processor/specupdt/31327914.pdf - We bet there are many more errata not yet announced -- every month this file gets larger. - Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs. - Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined new ways to handle page tables (see page 58). - Some of these bugs are along the lines of buffer overflow; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences. - All of this is just unbelievable to many of us. An easier summary document for some people to read: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so. As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are. == For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries). == At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent. (While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too).
Re: Intel Core 2 problems and OpenBSD Security
On 6/28/07, Siju George [EMAIL PROTECTED] wrote: -- Forwarded message -- From: Theo de Raadt [EMAIL PROTECTED] Date: Jun 27, 2007 10:38 PM Subject: Intel Core 2 To: [EMAIL PROTECTED] Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. Sorry :-( this was supposed to go to the local BSD lists. apologies Siju
Re: Intel Core 2
http://www.theregister.com/2007/06/27/intel_core2_duo_bios_fix/ Intel has released a BIOS patch for Windows machines running Core 2 and Xeon 3000/5000 chips that addresses potential unpredictable system behavior. After reading the whole article, it sounds like Intel is attempting to address some of the many bugs the chips have. In their wisdom, it sounds like they are making it difficult to get these updates if you *don't* run wind0ze. I like this quote: I'll put it to you this way, [Intel spokesman] Knupffer said. I've got a core chip at home and I haven't updated. That doesn't say much. If it's a non-networked machine, who really needs *any* patches...
Re: Intel Core 2
On Thu, 28 Jun 2007 10:26:45 +0200, RedShift [EMAIL PROTECTED] wrote: Reliability decay of low-lead materials may be economically desirable for some consumer product companies because it provides a mechanism to enforce planned obsolescence and replacement. Ironically, this is the opposite of the claimed intent of RoHS legislation. uuhhh that's scary. Are you sure they haven't found a solution for that? The inexpensive solution is to use a minimum of 4% lead in the tin based solder but that goes against the purpose of RoHS even if more waste is produced do to early failure. There are other alloying agents which impede tin whisker growth but they tend to either add significantly to the cost or compromise other characteristics.
Re: Intel Core 2
On 2007/06/28 09:16, David W. Hess wrote: On Thu, 28 Jun 2007 10:26:45 +0200, RedShift [EMAIL PROTECTED] wrote: Reliability decay of low-lead materials may be economically desirable for some consumer product companies because it provides a mechanism to enforce planned obsolescence and replacement. Ironically, this is the opposite of the claimed intent of RoHS legislation. uuhhh that's scary. Are you sure they haven't found a solution for that? The inexpensive solution is to use a minimum of 4% lead in the tin based solder but that goes against the purpose of RoHS even if more waste is produced do to early failure. Lead is still permitted for some equipment (notably network infrastructure), http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32002L0095:EN:HTML annex 7: - lead in solders for servers, storage and storage array systems (exemption granted until 2010), - lead in solders for network infrastructure equipment for switching, signalling, transmission as well as network management for telecommunication, - lead in electronic ceramic parts (e.g. piezoelectronic devices).
Re: Intel Core 2
Thanks very much! On Thu, Jun 28, 2007 at 10:24:01AM +0200, Johan P. Lindstrvm wrote: rough translation from swedish to english of: ...
Intel Core 2
Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold. Full (current) errata from Intel: http://download.intel.com/design/processor/specupdt/31327914.pdf - We bet there are many more errata not yet announced -- every month this file gets larger. - Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs. - Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined new ways to handle page tables (see page 58). - Some of these bugs are along the lines of buffer overflow; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences. - All of this is just unbelievable to many of us. An easier summary document for some people to read: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so. As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are. For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries). At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent. (While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too).
Re: Intel Core 2
On 6/27/07, Theo de Raadt [EMAIL PROTECTED] wrote: At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent. (While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too). so what laptop would you recommend to buy? -- almir
Re: Intel Core 2
On 6/27/07, Theo de Raadt [EMAIL PROTECTED] wrote: At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent. (While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too). so what laptop would you recommend to buy? I don't make recommendations.
Re: Intel Core 2
As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold. Is it know how many bugs are fixed by the BIOS updates that many vendors are releasing? For example, http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-67648
Re: Intel Core 2
http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif Show stopper Potentially Catastrophic Those are some warm and fuzzy words =) Geez, that's a whole lot of bugs... I never imagined that processors could be so bugged. Theo says that AMD is getting less helpful towards open source OS. Well, that's great. We only have 2 big proc developers for i386, and now those two are turning out crap products with diminishing documentation =( I wonder where this road will lead us. -- An OpenBSD user... and that's all you need to know =) Please, send private emails to [EMAIL PROTECTED]
Re: Intel Core 2
On 6/27/07, Leonardo Rodrigues [EMAIL PROTECTED] wrote: Theo says that AMD is getting less helpful towards open source OS. Well, that's great. We only have 2 big proc developers for i386, and now those two are turning out crap products with diminishing documentation =( I wonder where this road will lead us. Well, there's always via, and I think we still like them... :) -- This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation.
Re: Intel Core 2
2007/6/27, Leonardo Rodrigues [EMAIL PROTECTED]: Theo says that AMD is getting less helpful towards open source OS. Well, that's great. We only have 2 big proc developers for i386, and now those two are turning out crap products with diminishing documentation =( I wonder where this road will lead us. To sparc64? ;) Anyway, what about Transmeta? -- Daniel 'Shinden' Horecki http://morr.pl
Re: Intel Core 2
On 27/06/07, Daniel Horecki [EMAIL PROTECTED] wrote: Anyway, what about Transmeta? Check the news: On February 7, 2007, Transmeta closed its engineering services departments and terminated 75 employees. The company announced that it would no longer develop and sell hardware, but would focus on the development and licensing of intellectual property. http://en.wikipedia.org/wiki/Transmeta C.
Re: Intel Core 2
On Wednesday 27 June 2007 13:08:16 Theo de Raadt wrote: Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold. When it becomes known that a fix/workaround is being horded and not distributed, I hope we hear of it quickly. It will be time for the user community to start talking with Intel. Or has this already started? --STeve Andre'
Re: Intel Core 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thus Leonardo Rodrigues [EMAIL PROTECTED] spake on Wed, 27 Jun 2007 16:25:08 -0300: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif Show stopper Potentially Catastrophic Those are some warm and fuzzy words =) Geez, that's a whole lot of bugs... I never imagined that processors could be so bugged. Theo says that AMD is getting less helpful towards open source OS. Well, that's great. We only have 2 big proc developers for i386, and now those two are turning out crap products with diminishing documentation =( I wonder where this road will lead us. MIPS64. Just wait for the chinese to save the world from Chipzilla :) (And yes, MIPS is a really nice design, btw) iD8DBQFGgs/P689t39h/zfARAhiVAJ9WNAVmt9Ncv98Kycm1/VJ6dJ6zfwCg5Apu vwVNYZxxmaLhOVCZeg8ySBc= =BzkT -END PGP SIGNATURE-
Re: Intel Core 2
On Wed, Jun 27, 2007 at 12:45:10PM -0600, Theo de Raadt wrote: On 6/27/07, Theo de Raadt [EMAIL PROTECTED] wrote: At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent. (While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too). so what laptop would you recommend to buy? I don't make recommendations. Ok, rephrase the question (and I don't do laptop): What computer/processor (any arch, not limited to i386) has the power to do typical desktop stuff (browse the web, watch DVDs, edit photos) and at the same time has been great to port/develop for? Anything other than the desktop stuff above works just fine on my 486 with OBSD (thanks again all). Other than Intel and AMD, is there a third CPU maker that makes good CPUs that work in systems that will then run OBSD? For example, I note that the IBM PowerPC is _not_ listed as a port and I know that there must be a reason for this. If there was such a vendor and a port didn't exist, perhaps a discussion on what a port would take would be in order? Just my 2c, and I already bought my new box for this decade (AMD Athlon 64). Doug.
Re: Intel Core 2
Ok, rephrase the question (and I don't do laptop): What computer/processor (any arch, not limited to i386) has the power to do typical desktop stuff (browse the web, watch DVDs, edit photos) and at the same time has been great to port/develop for? Anything other than the desktop stuff above works just fine on my 486 with OBSD (thanks again all). Other than Intel and AMD, is there a third CPU maker that makes good CPUs that work in systems that will then run OBSD? For example, I note that the IBM PowerPC is _not_ listed as a port and I know that there must be a reason for this. If there was such a vendor and a port didn't exist, perhaps a discussion on what a port would take would be in order? Just my 2c, and I already bought my new box for this decade (AMD Athlon 64). Doug. I am a little shocked there are so many serious issues with the dual core processors. Though, I do have a laptop with a duo core, running OBSD without any problems. What I will say; it is shocking, but for normal usage, most users will never notice these issues. What will not mean that I will ask the next time before I buy another computer Jan
Re: Intel Core 2
Lontronics Mailinglist account wrote: I am a little shocked there are so many serious issues with the dual core processors. when competition is involved companies develop products as quickly as they can to keep up with the joneses. if your product(s) lack the bells and whistles the competition has, joey bagoconsumer will not buy your stuff b/c he's been successfully brainwashed into thinking feature X will make his life better. for an average computer user multicore processing doesn't do a whole lot besides compensate for slugware-driven OSes that are built like amUrican cars, whose primary purpose is to build product dependency and require replacement 4-5 years down the road. same lesson henry ford learned with the model t applies to large-scale hardware manufacturing. you make more money if your widgets break because your new widget is vastly improved. new packaging, same great defects! cheers, jake Though, I do have a laptop with a duo core, running OBSD without any problems. What I will say; it is shocking, but for normal usage, most users will never notice these issues. What will not mean that I will ask the next time before I buy another computer Jan
Re: Intel Core 2
On 27/06/07, Jacob Yocom-Piatt [EMAIL PROTECTED] wrote: you make more money if your widgets break because your new widget is vastly improved. new packaging, same great defects! The best thing about computer parts randomly failing will hit us in a few years, due to RoHS directives: http://en.wikipedia.org/wiki/RoHS#Impact_on_reliability http://en.wikipedia.org/wiki/Whisker_%28metallurgy%29 Another problem that lead-free solders face is the growth of tin whiskers. These thin strands of tin can grow and make contact with an adjacent trace, developing a short circuit. Tin whiskers have already been responsible for at least one failure at a nuclear power plant. Other documented failures include satellites in orbit, aircraft in flight, and implanted medical pacemakers. Reliability decay of low-lead materials may be economically desirable for some consumer product companies because it provides a mechanism to enforce planned obsolescence and replacement. Ironically, this is the opposite of the claimed intent of RoHS legislation. C.
Re: Intel Core 2
On 6/27/07, Jacob Yocom-Piatt [EMAIL PROTECTED] wrote: when competition is involved companies develop products as quickly as they can to keep up with the joneses. if your product(s) lack the bells and whistles the competition has, joey bagoconsumer will not buy your stuff b/c he's been successfully brainwashed into thinking feature X will make his life better. for an average computer user multicore processing doesn't do a whole lot besides compensate for slugware-driven OSes that are built like amUrican cars, whose primary purpose is to build product dependency and require replacement 4-5 years down the road. same lesson henry ford learned with the model t applies to large-scale hardware manufacturing. you make more money if your widgets break because your new widget is vastly improved. new packaging, same great defects! But I need two cores because I want to run youtube AND the Explorer! Meanwhile, I think the real problem here is them not releasing much documentation on the problems to the public. Bugs will happen, yeah, some are pretty bad; and yeah, part of the cause of it is that they have unecessarily close deadlines (unecessarily in the sense that the world doesn't really need the next generation of processors real soon). But those are not the only reasons for a buggy hardware, it's also a matter of human limitation. It's unrealistic to think your hardware will be perfect. All in all, the intel's core 2 clearly is not prepared for some critical uses. That does not mean that you can't successfuly run it in your desktop or even some servers. You'll most likely have much more dangerous vulnerabilities in the software you're using anyway.
Re: Intel Core 2
On 6/27/07, Theo de Raadt [EMAIL PROTECTED] wrote: Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold. Full (current) errata from Intel: http://download.intel.com/design/processor/specupdt/31327914.pdf - We bet there are many more errata not yet announced -- every month this file gets larger. - Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs. - Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined new ways to handle page tables (see page 58). - Some of these bugs are along the lines of buffer overflow; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences. - All of this is just unbelievable to many of us. An easier summary document for some people to read: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so. As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are. For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries). At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent. (While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too). So who currently (if anybody) is cooperating nicely? This is a sad state of affairs.
Re: Intel Core 2
On 6/27/07, Theo de Raadt [EMAIL PROTECTED] wrote: Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. Full (current) errata from Intel: http://download.intel.com/design/processor/specupdt/31327914.pdf An easier summary document for some people to read: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif This summary is for the core duo, but the errata is for. How do you know the bugs are all the same? I mean, seeing as it's a large monopolistic corp, I'm sure many of the same mistakes were carried over, but all of them? I don't know much about the recent history of these chips. Are there any good summaries around? -Nick
Re: Intel Core 2
via C7 a C3 questions? they work well? they give support? thanks On 6/27/07, Nick Price [EMAIL PROTECTED] wrote: On 6/27/07, Theo de Raadt [EMAIL PROTECTED] wrote: Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold. Full (current) errata from Intel: http://download.intel.com/design/processor/specupdt/31327914.pdf - We bet there are many more errata not yet announced -- every month this file gets larger. - Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs. - Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined new ways to handle page tables (see page 58). - Some of these bugs are along the lines of buffer overflow; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences. - All of this is just unbelievable to many of us. An easier summary document for some people to read: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so. As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are. For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries). At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent. (While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too). So who currently (if anybody) is cooperating nicely? This is a sad state of affairs.
