home *** CD-ROM | disk | FTP | other *** search
/ linuxmafia.com 2016 / linuxmafia.com.tar / linuxmafia.com / pub / linux / security / f00f / pentium-bug-fixed.txt < prev    next >
Internet Message Format  |  1997-11-16  |  3KB
  1. From myrddin.imat.com!miwok!news1.best.com!news.transmeta.com!torvalds Mon Nov 17 10:53:04 1997
  2. Path: myrddin.imat.com!miwok!news1.best.com!news.transmeta.com!torvalds
  3. From: torvalds@transmeta.com (Linus Torvalds)
  4. Newsgroups: comp.os.linux.development.system,comp.os.linux.advocacy,comp.os.linux.misc
  5. Subject: Re: F00F bug *fixed* in 2.0.x kernels
  6. Date: 15 Nov 1997 00:54:57 GMT
  7. Organization: Transmeta Corporation, Santa Clara, CA
  8. Lines: 52
  9. Message-ID: <64irt1$lnt$1@palladium.transmeta.com>
  10. References: <64guhu$p7k@news9.noc.netcom.net> <64i5sg$5mj$2@news.utrecht.NL.net>
  11. NNTP-Posting-Host: penguin.transmeta.com
  12. Xref: myrddin.imat.com comp.os.linux.development.system:45464 comp.os.linux.advocacy:104323 comp.os.linux.misc:155770
  13.  
  14. In article <64i5sg$5mj$2@news.utrecht.NL.net>,
  15. Toon Moene  <toon@moene.indiv.nluug.nl> wrote:
  16. >set-usenet-879492588@reality.samiam.org (Sam Trenholme) wrote:
  17. >
  18. >> The Linux developers have, again, done the impossible.  Within seven days
  19. >> of the serious FOOF bug in the Pentium being discovered, the kernel
  20. >> developers have not only figured out a software fix for the problem, but 
  21. >> have patches for *both* the 2.1.63 and the 2.0.31 kernels which make 
  22. >> Linux immune to the F00F bug.
  23. >
  24. >And the most interesting aspect of it is, of course, that Intel tried the 
  25. >good old road of keeping the Free Software Community out of it by only 
  26. >supplying a fix to BSDI.
  27. >
  28. >Long Live Reverse Engineering !
  29.  
  30. To be fair to Intel, I want to tell people that Intel (a) did approach
  31. me too, and that (b) the BSDi patch was in fact unauthorized by intel
  32. and had to be withdrawn by BSDi. 
  33.  
  34. So intel actually did pretty much do the correct thing this time.  Sure,
  35. they pissed me off a lot when I heard that BSDi had gotten the patch,
  36. but when it became clear that they hadn't _meant_ it that way, their
  37. approach was actually totally understandable. 
  38.  
  39. Essentially, they asked everybody to sign NDA's in order to let
  40. _everybody_ in on the fix to the problem, and not have anybody be the
  41. "first" one. 
  42.  
  43. Now, I personally think that asking people to sign NDA's for a bug that
  44. they themselves had introduced is pretty stupid, which was the reason I
  45. refused when they contacted me.  In this case, that turned out to be the
  46. right solution, because then when BSDi did make the patch available
  47. despite the NDA my hands weren't tied in any way. 
  48.  
  49. Note that we would probably have figured out the fix even without BSDi,
  50. although it might have taken a day or two more.  Ingo Molnar had already
  51. found another way to make the problem go away (with a very bad
  52. performance impact, admittedly), but there were people working on
  53. approaches that would probably eventually have ended up with what we
  54. have now anyway. 
  55.  
  56. As to today, intel seems to be quite open about the problem, and they
  57. have even given me their own patch for fixing this in 2.0.x (which does
  58. essentially the same thing that we already did, but with a few
  59. improvements actually). 
  60.  
  61. ftp.kernel.org has my latest 2.0.32 pre-patch in the directory
  62. "pub/linux/kernel/testing", and I'm just about to do another 2.1.x
  63. release with most of the obvious problems fixed. 
  64.  
  65.             Linus
  66.  
  67.