Re: pentium bug

Re: pentium bug

[Joshua Weage]

> This means that anybody can crash anytime any OS that runs under a
Pentium CPU.
> As the poster said, no special permissions are needed, the pentium runs
under
> ring 3 permissions!!!! user space
> 
> This means that no secure system can ever be built that uses the pentium
CPU. No
> protected system. The OS receives NO TRAP!!!

	So what is the problem with a hard reboot?  Your system will not be
insecure, it will just crash.  The same thing can be done to a sun
workstation, not quite as quick, but it is possible to force a hard reboot
with no other available options to get the system back up.

Josh

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: pentium bug

[Alex]

On Sat, 8 Nov 1997, Joshua Weage wrote:

> > This means that anybody can crash anytime any OS that runs under a
> Pentium CPU.
> > As the poster said, no special permissions are needed, the pentium runs
> under
> > ring 3 permissions!!!! user space
> > 
> > This means that no secure system can ever be built that uses the pentium
> CPU. No
> > protected system. The OS receives NO TRAP!!!
> 
> 	So what is the problem with a hard reboot?  Your system will not be
> insecure, it will just crash.  The same thing can be done to a sun
> workstation, not quite as quick, but it is possible to force a hard reboot
> with no other available options to get the system back up.

With filesystems other than FAT{16|32}, this can lead to data loss due to 
filesystem corruption, which is a problem.  On any system this can lead to
loss of whatever data is in ram, before your system crashes, on a server
like system this can also force costly downtime.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: pentium bug

[Ron G. Minnich]

On Sat, 8 Nov 1997, Joshua Weage wrote:
> 	So what is the problem with a hard reboot?  Your system will not be
> insecure, it will just crash.  The same thing can be done to a sun
> workstation, not quite as quick, but it is possible to force a hard reboot
> with no other available options to get the system back up.

it's not a crash. it does not go to hard reboot. It locks up tighter than
a drum. The only way to get the machine going again is to walk over to
the reset button and push it. A crash or reboot would be a much better
failure, believe me. 

This is a bit of a problem for many scenarios, proof left to reader. 

ron
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Pentium bug

[Peter Dalgaard BSA]

Alex <garbanzo@hooked.net> writes:

> Last I heard the two patches/fixes available had major pitfalls.  From
> what I've seen, I'd agree.  The Linux fix is an ugly hack, and the BSDI
> one (last I saw), forgot all about vm86 mode. *yich*.  I hope (but doubt)
> that MS will incorporate a better fix into 95 NT and 98.

Last I've seen, the Linux "hack" was identical to the official Intel
workaround... 

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Pentium bug

[Alex]

On Sat, 15 Nov 1997, root wrote:

> For Linux users, it may be interesting to know that Linus Torwalds has added
> a patch to Linux that solves the newly discovered bug with a software
> correction as proposed by Intel.

Last I heard the two patches/fixes available had major pitfalls.  From
what I've seen, I'd agree.  The Linux fix is an ugly hack, and the BSDI
one (last I saw), forgot all about vm86 mode. *yich*.  I hope (but doubt)
that MS will incorporate a better fix into 95 NT and 98.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Pentium bug

[root]

For Linux users, it may be interesting to know that Linus Torwalds has added
a patch to Linux that solves the newly discovered bug with a software correction
as proposed by Intel.

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: pentium bug

[Joshua Weage]

>On Sat, 8 Nov 1997, Joshua Weage wrote:
>> So what is the problem with a hard reboot?  Your system will not be
>> insecure, it will just crash.  The same thing can be done to a sun
>> workstation, not quite as quick, but it is possible to force a hard
reboot
>> with no other available options to get the system back up.
>
>it's not a crash. it does not go to hard reboot. It locks up tighter than
>a drum. The only way to get the machine going again is to walk over to
>the reset button and push it. A crash or reboot would be a much better
>failure, believe me.


    I guess I wasn't clear.  What I meant was that it required someone to
hard reboot the server, it did not reboot itself.  SDRC I-DEAS is notorious
for locking up machines.  UNIX os's without process limits are quite easy to
bring down also.

Josh


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: pentium bug

[Joshua Weage]

>> So what is the problem with a hard reboot?  Your system will not be
>> insecure, it will just crash.  The same thing can be done to a sun
>> workstation, not quite as quick, but it is possible to force a hard
reboot
>> with no other available options to get the system back up.
>
>With filesystems other than FAT{16|32}, this can lead to data loss due to
>filesystem corruption, which is a problem.  On any system this can lead to
>loss of whatever data is in ram, before your system crashes, on a server
>like system this can also force costly downtime.


    I realize that it can cause file corruption, but like I said above, it
is possible to crash UNIX based systems also.  No system is 100% crash free,
it is just easier to cause crashes on certain types of systems.

Josh


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: pentium bug

[Tim Iverson]

See inline comments.

+----------------
| From: root@jacob.remcomp.fr (root)
| Subject: pentium bug
| To: gnu-win32@cygnus.com
| Date: Sat, 8 Nov 1997 17:19:42 +0100 (MET)
| 
...
| Then, I ported the code to my old faithful 486-DX33 with linux. Compiled it.
| When it run it traps with 'illegal instruction'

Not surprising.  This is a "lock cmpxchg8b eax" instruction, which is new
to the Pentium series and also nonsensical.

| This means that anybody can crash anytime any OS that runs under a Pentium.
...
| This means that no secure system can ever be built that uses the pentium CPU. No
| protected system. The OS receives NO TRAP!!!

Yup, this is *very* bad news for all those ISPs out there on pentiums.

| Bugs are impossible to avoid. Not even with huge corporations like Intel.
| I will *not* start screaming at Intel now. Myself, I have done more bugs
| than Intel ever will. As somene said before:
| 
| Those that are free of sin, throw the first stone...

Well, personally, I'd fire the engineer responsible for that instruction.
Illegal instruction trap tests are fairly basic and whomever designed that
instruction should have insisted and ensured that the illegal sequences
were properly included in the regression tests.

Bugs that folks can work around are forgivable.  Bugs that require the
wholesale recall of an entire product line?  Uh, this is a little more
than just an "oops, sorry."

Hmmm, wholesale recall is probably a bit harsh -- if you're not trying to
run a secure site (eg.  you're just using the pentium for a single-user
workstation), then there really isn't too much to worry about.

Hehe.  My secure system is still on a 486, simply 'cuz a 486/66 with
FreeBSD beats a P5/200 running Windows 95.  I'll need to demand a fix when
it comes time to upgrade to the next MS OS, which no doubt will run even
slower and thus need a faster processor, but at least I have some time to
wait for Intel to get a replacement program in place.  I suspect 90% of
pentium users can also afford to wait.


- Tim Iverson
  iverson@lionheart.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

pentium bug

[root]

This morning I received this message from this list:

> 
> There is a SERIOUS bug in all pentium CPUs. The following 
> code will crash any machine running on a pentium CPU, MMX or no 
> MMX, any speed, regardless of OS (crash as in instant seize, hard 
> reboot the only cure):
> 
> char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
> 
> main ()
> {
>        void (*f)() = x;
>        f();
> }
> 
> This require no special permissions to run, it works fine with
> average-joe-userspace permissions. I have verified this, it works.
> Demand a new CPU from Intel.
> 

I received this message this morning from the gnu-win32 list. Curious, I
compiled that under Linux OS. Linux freezed. Dead. Without *any* warning.

My machine is a Genuine Intel 166 MHZ Pentium MMX.

Then I rebooted Windows NT. Compiled it with my compiler system (lcc-win32).
Windows NT freezed. DEAD. Without *any* warning.

Then, I ported the code to my old faithful 486-DX33 with linux. Compiled it.
When it run it traps with 'illegal instruction'

This means that anybody can crash anytime any OS that runs under a Pentium CPU.
As the poster said, no special permissions are needed, the pentium runs under
ring 3 permissions!!!! user space

This means that no secure system can ever be built that uses the pentium CPU. No
protected system. The OS receives NO TRAP!!!

This is absolutely incredible. 

Bugs are impossible to avoid. Not even with huge corporations like Intel.
I will *not* start screaming at Intel now. Myself, I have done more bugs
than Intel ever will. As somene said before:

Those that are free of sin, throw the first stone...

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".