mboost-dp1
unknown
Det var godt nok lidt af en hardcore fejl spørgsmålet er bare om Intel vil æde det rådt og hvad deres udspil bliver har godt nok også haft samme problem når jeg sidder og programmer multitasking systemer som skal udveksle informationer mellem threads.
Problemet består i at nogle gang står der noget mærkeligt i de variabler som er delt mellem 2 eller n threads noget som slet ikke giver mening, som f.eks en file pointer som peger på 40 Bytes som er den position som file pointeren har efter læsning og så når man ryger over i en anden thread står der pluselig -xxx eller et eller andent helt opskurt tal som slet ikke giver mening.
Men dette er ikke tilfældet da disse variable ligger i en helt anden klasse og den enste tilgang du har til dem er Get() Set() og hvis en tråd er igang med at læse kan en anden ikke begynde at skrive og vis versa da Read har et wait state inbygget hvis write er igang det samme kan man ikke læse fra 2 threads da det samme wait state vil blive sat.
Problemet består i at nogle gang står der noget mærkeligt i de variabler som er delt mellem 2 eller n threads noget som slet ikke giver mening, som f.eks en file pointer som peger på 40 Bytes som er den position som file pointeren har efter læsning og så når man ryger over i en anden thread står der pluselig -xxx eller et eller andent helt opskurt tal som slet ikke giver mening.
Det kan godt være at der er nogle kloge Åger som nu sidder og siger ha ha naren har overskrevet sine egne variable og nu ved han det ikke.
Men dette er ikke tilfældet da disse variable ligger i en helt anden klasse og den enste tilgang du har til dem er Get() Set() og hvis en tråd er igang med at læse kan en anden ikke begynde at skrive og vis versa da Read har et wait state inbygget hvis write er igang det samme kan man ikke læse fra 2 threads da det samme wait state vil blive sat.
[slightly offtopic]
Hva, ikke noget public outrage endnu, ingen Y2K-like fanatics som der render rundt og bygger atombunkere (da de tror at en hacker stjæler den kryptografiske nøgle til atom affyrings systemerne), ingen teknikere som bliver overbetalt for at rette fejlen? Nå, så blev det alligevel en kedelig søndag.
[/slightly offtopic]
Rick Fleming, CTO at Digital Defense Inc.
Selvfølgelig er det en alvorlig fejl, men skal vi se, verdenen er der nok også imorgen. Så vidt jeg kan læse mig til så skal angrebet foretages af en der allerede er inde i systemet.
Det kan iøvrigt anbefales at læse artikelen i eweek: http://www.eweek.com/article2/0,1759,1815954,00.as...
Hva, ikke noget public outrage endnu, ingen Y2K-like fanatics som der render rundt og bygger atombunkere (da de tror at en hacker stjæler den kryptografiske nøgle til atom affyrings systemerne), ingen teknikere som bliver overbetalt for at rette fejlen? Nå, så blev det alligevel en kedelig søndag.
[/slightly offtopic]
"It would probably be easier to do a social engineering experiment and just walk in there and steal the damn box,"
Rick Fleming, CTO at Digital Defense Inc.
Selvfølgelig er det en alvorlig fejl, men skal vi se, verdenen er der nok også imorgen. Så vidt jeg kan læse mig til så skal angrebet foretages af en der allerede er inde i systemet.
Det kan iøvrigt anbefales at læse artikelen i eweek: http://www.eweek.com/article2/0,1759,1815954,00.as...
Intel, with which High said Percival shared a draft of the paper, has been working with operating system vendors to add safeguards against the type of attack, the Intel spokesman said.-as read in eweek
#2
Det er ikke brugbart bare at sige 'Det kan man forvente fra Intel' - for det kan man normalt IKKE forvente fra Intel. Hvis man ser bort fra prispolitik, reklamepropaganda osv, så laver Intel nogle glimrende produkter.
Men det ER hvad der kan ske, når et firma bliver presset til at finde på noget popsmart (HT) for at få sin position lidt foran den virkelige konkurrents (AMD) teknisk bedre løsninger. Så går det pludseligt hurtigt, og ikke alt bliver testet ordentligt.
Eller også har der, ligesom i et andet stort firma, siddet en udvikler og tænkt: "This might be a problem... ah... what the hell..." :)
Det er ikke brugbart bare at sige 'Det kan man forvente fra Intel' - for det kan man normalt IKKE forvente fra Intel. Hvis man ser bort fra prispolitik, reklamepropaganda osv, så laver Intel nogle glimrende produkter.
Men det ER hvad der kan ske, når et firma bliver presset til at finde på noget popsmart (HT) for at få sin position lidt foran den virkelige konkurrents (AMD) teknisk bedre løsninger. Så går det pludseligt hurtigt, og ikke alt bliver testet ordentligt.
Eller også har der, ligesom i et andet stort firma, siddet en udvikler og tænkt: "This might be a problem... ah... what the hell..." :)
Gad vide om Intel's ingienører nu får travlt; for mens den nuværende Pentium D (Smithfield) blot er 2 CPU'er pakket i én og derfor har hver sin cache, vil Intels "rigtige" dual kerne CPU'er (Dempsey som den første, ca. et år ud i fremtiden) dele en stor cache ligesom IBM's power4 gør det i dag.
#3
Fejlen er meget alvorlig, den kan forstærke samtlige andre fejl mange gange, normaltvist er et exploit i en ftp/http/whatever server, der giver dig adgang til en begrænset bruger (f.eks. nobody), ikke noget større problem, men hvis den bruger ligepludselig kan sidde og hive data fra systemet så er det ikke så heldigt.
Det her er en type af exploit som sandsynligvis vil blive udviklet en del på, og dermed vil man finde smarte måder at udnytte det på, hvorved rettighedseskalering hurtigt bliver en risiko.
Sandheden er at Intel skulle have et stort objekt i hovedet pga. det her, den slags designfejl hører ganske enkelt ikke hjemme i verdens mest solgte general purpose cpu'er.
Fejlen er meget alvorlig, den kan forstærke samtlige andre fejl mange gange, normaltvist er et exploit i en ftp/http/whatever server, der giver dig adgang til en begrænset bruger (f.eks. nobody), ikke noget større problem, men hvis den bruger ligepludselig kan sidde og hive data fra systemet så er det ikke så heldigt.
Det her er en type af exploit som sandsynligvis vil blive udviklet en del på, og dermed vil man finde smarte måder at udnytte det på, hvorved rettighedseskalering hurtigt bliver en risiko.
Sandheden er at Intel skulle have et stort objekt i hovedet pga. det her, den slags designfejl hører ganske enkelt ikke hjemme i verdens mest solgte general purpose cpu'er.
#6
Ja ok, så forstår jeg lidt bedre. Vil da give dig helt ret i at den slags designfejl ikke bør høre hjemme blandt de mest solgte general purpose cpu'er.
Der vil altid være fejl, så hvis du vil slå alle programmører /ingeniører der laver fejl med et stort objekt, så tror jeg at salget af hovedpine piller vil stige voldsomt.
Ja ok, så forstår jeg lidt bedre. Vil da give dig helt ret i at den slags designfejl ikke bør høre hjemme blandt de mest solgte general purpose cpu'er.
Der vil altid være fejl, så hvis du vil slå alle programmører /ingeniører der laver fejl med et stort objekt, så tror jeg at salget af hovedpine piller vil stige voldsomt.
#4 Intel har, så vidt jeg ved, verdens største og mest avancerede chipkvalitet test-center. Men denne fejl er svær at teste, der er ikke tale om en aritmetisk fejl i en ALU når meget store kommatal ganges, ligesom Intel's kendte Pentium havde.
Det er simpelthen en designfejl, og det må siges at være værre!
Det er simpelthen en designfejl, og det må siges at være værre!
#9 Ja men hvodan kan man ungå denne fejl, eller hvad kan man gøre for at udbedere denne fejl.
Jeg sidder selv og tænker lidt på en løsning men jeg må nok sige at jeg bryder mig ikke om smagen af denne løsning da denne sikkert vil give en masse går hår og mavesår.
Jeg sidder selv og tænker lidt på en løsning men jeg må nok sige at jeg bryder mig ikke om smagen af denne løsning da denne sikkert vil give en masse går hår og mavesår.
Tænk nu hvis:
At de kaldte alle Pentium 4 CPUer tilbage, og gav mig en ny helt gratis, desvære så blev de nød til at give mig en ny og bedre CPU, for de laver ikke de gamle mere.
At de kaldte alle Pentium 4 CPUer tilbage, og gav mig en ny helt gratis, desvære så blev de nød til at give mig en ny og bedre CPU, for de laver ikke de gamle mere.
#10 Tror der sidder mange og analyserer problemet og hvad der kan gøres. Som Colin kommer ind på i artiklen, er det kun i kernel schedualeren i operativsystemerne hvor konservative politikker kan afhjælpe problemet (mere eller mindre disable HT).
[Offtopic]
Godt man ikke er Dell supporter i disse dage, de har jo alt på et bræt.
[/Offtopic]
[Offtopic]
Godt man ikke er Dell supporter i disse dage, de har jo alt på et bræt.
[/Offtopic]
lidt sent den kom her, ved ikke om fejlen er specielt hardcore de fleste dataloger kunne tage sig sammen og finde ud af at udnytte den.
#1 jeps tænker lige præsis at du har tilgået et forkert hukommelses område,, den kan du sagtent gøre accessor funktioner eller ej hvis du forsøger dig med lowlevel manipulation eller er lidt for kreativ med dine pointer arithmetik vil dine c++ klasser som jeg går ud fra du koder i ikke yde meget data inkapsling.
multitråds programmer har en mængde fejlkilder især med de gode gammeldags kompilerede sprog som c++ og c.
Mht til fejlen/feauturen skal man ikke begynder at skide grønne grise, exploiten kræver at maskinen har flere brugere, medmindre man slf ligefrem selv kører et lytte program i hvilket tilfælde en hver anden exploit kan ramme en så ved ikke lige om desktop users skal slå ht fra ved deres private arbejds maskine som de er den eneste bruger af.
#1 jeps tænker lige præsis at du har tilgået et forkert hukommelses område,, den kan du sagtent gøre accessor funktioner eller ej hvis du forsøger dig med lowlevel manipulation eller er lidt for kreativ med dine pointer arithmetik vil dine c++ klasser som jeg går ud fra du koder i ikke yde meget data inkapsling.
multitråds programmer har en mængde fejlkilder især med de gode gammeldags kompilerede sprog som c++ og c.
Mht til fejlen/feauturen skal man ikke begynder at skide grønne grise, exploiten kræver at maskinen har flere brugere, medmindre man slf ligefrem selv kører et lytte program i hvilket tilfælde en hver anden exploit kan ramme en så ved ikke lige om desktop users skal slå ht fra ved deres private arbejds maskine som de er den eneste bruger af.
#1
Jeg har nu aldrig oplevet nogen problemer og din beskrivelse lyder stadig som et synkroniseringsproblem. Som Percival skriver er det jo ikke noget der "bare sker" så jeg tvivler på at denne brist har noget som helst med dit problem at gøre. Er du sikker på at al adgang til dine variable er semaforbeskyttet og at semaforen er initialiseret rigtigt? Nu ved jeg ikke hvilket sprog du skriver i men de fleste semaforimplementationer understøtter "tællesemaforer" der giver mulighed for at tillade X tråde at afvilke kode samtidig således af et kald til wait tæller semaforen én ned. Hvis så den er initialiseret forkert kan det være at dit kald til wait ikke er blokerende.
Generelt er det rimelig bad design, at sådan en ting kan foregå i hardware. Når man tænker på hvor mange ingienørtimer der går i design af sådan en arkitektur er det da mærkværdigt at der kan opstå sådan en fejl. Nu er det godt nok normalt op til operativsystemet at sørge for alle disse ting, men der bør være foranstaltninger i hardwaren der safeguarder mod disse ting.
Jeg har nu aldrig oplevet nogen problemer og din beskrivelse lyder stadig som et synkroniseringsproblem. Som Percival skriver er det jo ikke noget der "bare sker" så jeg tvivler på at denne brist har noget som helst med dit problem at gøre. Er du sikker på at al adgang til dine variable er semaforbeskyttet og at semaforen er initialiseret rigtigt? Nu ved jeg ikke hvilket sprog du skriver i men de fleste semaforimplementationer understøtter "tællesemaforer" der giver mulighed for at tillade X tråde at afvilke kode samtidig således af et kald til wait tæller semaforen én ned. Hvis så den er initialiseret forkert kan det være at dit kald til wait ikke er blokerende.
Generelt er det rimelig bad design, at sådan en ting kan foregå i hardware. Når man tænker på hvor mange ingienørtimer der går i design af sådan en arkitektur er det da mærkværdigt at der kan opstå sådan en fejl. Nu er det godt nok normalt op til operativsystemet at sørge for alle disse ting, men der bør være foranstaltninger i hardwaren der safeguarder mod disse ting.
...så ved ikke lige om desktop users skal slå ht fra ved deres private arbejds maskine...
Nej, det er så bare ironisk at HT netop er lavet til enterprise systemer med mange tråde, i single-thread spil (som er de desktop applikationer som stresser mest) hjælper HT jo ikke rigtig noget.
Så tilbage står HT som ingen effekt har på en typisk stresset desktop og som må slås fra på et enterprise system. Surt!
#15 Ja
Variablen står som tilstand Private det vil sige at det er kun Parent freind classes der kan rør denne variable eller Klassen selv og siden jeg ikke bruger parent freind metoder i mine klasser er jeg nødsaget til at bruge get og set funktioner i min kode dette minsker også fejlen at jeg prøver at smide noget forkert ind i disse variabler da jeg har check for at se havd programmet vil tilskrive variablen.
Og det jeg mener med fejlen er heller ikke at den kommer hvergang det er en latent fejl det vil sige den kommer en gang imellem, men programmet kan også køre i flere dage upåklageligt og uden nogle somhelst problemer, men så lige pluselig går der ged i det.
Variablen står som tilstand Private det vil sige at det er kun Parent freind classes der kan rør denne variable eller Klassen selv og siden jeg ikke bruger parent freind metoder i mine klasser er jeg nødsaget til at bruge get og set funktioner i min kode dette minsker også fejlen at jeg prøver at smide noget forkert ind i disse variabler da jeg har check for at se havd programmet vil tilskrive variablen.
Og det jeg mener med fejlen er heller ikke at den kommer hvergang det er en latent fejl det vil sige den kommer en gang imellem, men programmet kan også køre i flere dage upåklageligt og uden nogle somhelst problemer, men så lige pluselig går der ged i det.
#16
Jeg tror ikke der er nogle der er i tvivl om hvad HT er.
I det "lille" program som jeg har lavet kan jeg bla nævne at der er helt op til 16 tråde der kan køre på en gang der memory check, network check, process resource tildelings check, firewall check, opdaterings check, dette er kun nogle af de check som jeg køre
Jeg tror ikke der er nogle der er i tvivl om hvad HT er.
I det "lille" program som jeg har lavet kan jeg bla nævne at der er helt op til 16 tråde der kan køre på en gang der memory check, network check, process resource tildelings check, firewall check, opdaterings check, dette er kun nogle af de check som jeg køre
#17
Igen, er variablerne "volatile?" Det er en god idé at gøre for variabler der deles mellem tråde, for C/C++ er grundlæggende et single-threaded sprog. Og desuden så forhindrer private-access-systemet i C++ altså ikke anden kode i at tilgå dine variabler via pointeraritmetik - det giver bare compileren muligheden for at fange den slags ved compile-time, men det er trivielt at omgå:
#include <iostream>
class testclass
{
public:
testclass():
value(0)
{}
void print_value() {
std::cout << value << std::endl;
}
private:
int value;
};
int main()
{
testclass test;
test.print_value();
*reinterpret_cast<int*>(&test) = 1337;
test.print_value();
}
Dette outputter følgende når det køres:
0
1337
Voila! Private-beskyttelsen er brudt. Bemærk dog at koden er udefineret, det vil sige der er ingen garanti for at dette sker... men i praksis vil det (næsten) altid give førnævnte output.
Igen, er variablerne "volatile?" Det er en god idé at gøre for variabler der deles mellem tråde, for C/C++ er grundlæggende et single-threaded sprog. Og desuden så forhindrer private-access-systemet i C++ altså ikke anden kode i at tilgå dine variabler via pointeraritmetik - det giver bare compileren muligheden for at fange den slags ved compile-time, men det er trivielt at omgå:
#include <iostream>
class testclass
{
public:
testclass():
value(0)
{}
void print_value() {
std::cout << value << std::endl;
}
private:
int value;
};
int main()
{
testclass test;
test.print_value();
*reinterpret_cast<int*>(&test) = 1337;
test.print_value();
}
Dette outputter følgende når det køres:
0
1337
Voila! Private-beskyttelsen er brudt. Bemærk dog at koden er udefineret, det vil sige der er ingen garanti for at dette sker... men i praksis vil det (næsten) altid give førnævnte output.
#19 Du har ganske ret, det er jo så både charmen og det farlige ved disse sprog. Men man vil altid kunne ændre en variabel inden for samme process:
__asm MOV [test], 1337
Plejer iøvrigt ikke at bruge volatile, da det gør at compileren ikke kan optimere denne, vælger ligesom CrashOverride at bruge accessors med kritiske regioner.
__asm MOV [test], 1337
Plejer iøvrigt ikke at bruge volatile, da det gør at compileren ikke kan optimere denne, vælger ligesom CrashOverride at bruge accessors med kritiske regioner.
#19
rigtigt nok at der ikke er noget tab af information eller funny ram funktion der.
Men det jeg taler om er at 2-n threads komunikere med hinanden igennem et par variabler og en dialog platform og der går det nogle gang galt nogle gang er der sjove ting i variablerne og andre gange fungere det fint nogle gang kommer det an på hvor hårdt presset maskinen så som du ser er det forskelligt.
#20
Ja det er ikke næmt at lave et næmt portabelt program når man begynder at specificere det for meget prøver også så vidt det er mig muligt at lave det så jeg kan portere ca 75% af koden til Unix linux unden problere selv ved at det er et MFC program. det gør det godt nok lidt sværer men det er lykkedes for mig et par gange.
rigtigt nok at der ikke er noget tab af information eller funny ram funktion der.
Men det jeg taler om er at 2-n threads komunikere med hinanden igennem et par variabler og en dialog platform og der går det nogle gang galt nogle gang er der sjove ting i variablerne og andre gange fungere det fint nogle gang kommer det an på hvor hårdt presset maskinen så som du ser er det forskelligt.
#20
Ja det er ikke næmt at lave et næmt portabelt program når man begynder at specificere det for meget prøver også så vidt det er mig muligt at lave det så jeg kan portere ca 75% af koden til Unix linux unden problere selv ved at det er et MFC program. det gør det godt nok lidt sværer men det er lykkedes for mig et par gange.
CrashOverride: Du er jo naiv hvis du tror at multithreaded kode "bare laver fejl en gang imellem". Hvis det virkelig var sådan var der jo ingen systemer der virkede. Forstå dog at du har en designfejl i dit program. Læs en bog om concurrent programming, og forstå de forskellige synkroniseringsmekanismer. Forstå hvordan maskinen indenunder arbejder med hukommelsen og scheduling - eller lad være med at programmere flere tråde. Dine symptomer er klassiske for dårlig synkronisering, og dine argumenter for det modsatte tyder på manglende forståelse for det samme - og jeg vil garantere for at det kan bringes til at virke 100% hvis synkroniseringen implementeres korrekt.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund