"Virusbeskyttelse" i Athlon 64 og Prescott

[Tfosheim]

"Virusbeskyttelse" i Athlon 64 og Prescott

Athlon 64 og Prescott-prosessorer har en innebygget mekanisme som setter en effektiv stopper for alle såkalte "buffer overflow"-angrep.

 

Les artikkelen her

[panzerwolf]

Hmmm....

 

For håpe at det stopper der og ikke utvilkes eller misbrukes (Palladiums dommedagsbasuner høres i det fjerne). Da er det forholdsvis greit. Men kan det ikke være mulig at andre programmer ("snille") også kan tenkes å ha nytte av å kontrollere hurtigminnet?

[talisar]

Man kan kontrollere hurtigminnet fortsatt? Du blander cache og buffer her tror jeg:) Uten at jeg skal gå inn i en forklaring som går på programering osv.

 

Det eneste som skjer er at man setter at ting ikke kan kjøre fra minne som er merket for data kort og greit:) I utgangspunktet vet jo ikke cpuen om dataen den ser er data eller kjørbar kode. B4 13 CD 10 kan være enten data eller assembler kommandoene mov al,13h; int 10. (som setter skjermen til 320x200 i 8 bit farge) f.eks.

[panzerwolf]

Man kan kontrollere hurtigminnet fortsatt? Du blander cache og buffer her tror jeg:) Uten at jeg skal gå inn i en forklaring som går på programering osv.

 

Det eneste som skjer er at man setter at ting ikke kan kjøre fra minne som er merket for data kort og greit:) I utgangspunktet vet jo ikke cpuen om dataen den ser er data eller kjørbar kode. B4 13 CD 10 kan være enten data eller assembler kommandoene mov al,13h; int 10. (som setter skjermen til 320x200 i 8 bit farge) f.eks.

Mulig jeg gjør det, men trodde at buffer/cache/hurtigminne var det samme når vi snakker om prosessorer (og harddisker for den saks skyld) . Det jeg tenkte var om noen "snille" programmer kjører kode fra dette minnet og at disse programmene da ville få problemer. Har ingen erfaring med programmering (noe jeg ser du har)...

[ØysteinI]

Men dette er jo langt på vei å skjule programmeringsfeil i software. Håper ikke dette blir brukt som grunnlag for at de store programleverandørene blir enda dårligere på testing og feilsjekking av koden sin.

 

Idiotsikring fører bare til større idioter som klarer å omgå sikringene.

 

"Never underestimate the power of stupid people in large groups"

[GNUfan]

Dette er en god ting. Bufferoverflows er irriterende, og det er _MANGE_ huller som utnytter slike svakheter. Får håpe at developperne ikke driter i å programmere fint, men at denne sikringen kan hjelpe når 'krisen er ute'.

Mad Wolf Magnux:

En bufferoverflow går ut på at ett program skriver saker og ting utover bufferen sin. HVilket betyr at den skriver saker og ting på steder der den egentlig ikke har lov til det.

Dette er en _feil_, ikke ett _mål_ (jo, for de som lager exploits ). Alle programmer vil kunne _kjøre_ fra minnet, men ikke gjøre ting det ikke har lov til (Elendig forklart av en som ikke egentlig har kompetanse til å svare)

[panzerwolf]

Aha, så buffer i programvareforstand og ikke maskinvareforstand (som er heller min "greie") er tildelt minneplass et program/ en kode får?

[Knick Knack]

Men dette er jo langt på vei å skjule programmeringsfeil i software. Håper ikke dette blir brukt som grunnlag for at de store programleverandørene blir enda dårligere på testing og feilsjekking av koden sin.

 

Idiotsikring fører bare til større idioter som klarer å omgå sikringene.

 

"Never underestimate the power of stupid people in large groups"

Helt enig, men er det ikke slik at f.eks. Java er lagd for å unngå programmeringsfeil? Må jo være mye å hente på å lage programmeringsspråk som ikke er så fort gjort å gjøre feil i. Jeg har ikke programmert så mye, men merket meg at enkelte språk er mer utsatt for å lage feil i enn andre. Pascal husker jeg var rimelig kresen på koden, og det var passe greit å unngå "off by one errors". C++ er med sine pekere en ren jungel etter min mening og sikkert en viktig grunn til at vi har så mange buffer overflows. Fikk likevel den beste latteren da jeg leste en VB kode med følgende linje: "On error resume next" Det kan jo bare gå en vei!

Endret 13. januar 2004 av Knick Knack

[Martin Lie]

Aha, så buffer i programvareforstand og ikke maskinvareforstand (som er heller min "greie") er tildelt minneplass et program/en kode får?

Jepp, det er konseptet!

[Martin Lie]

(...) men er det ikke slik at f.eks. Java er lagd for å unngå programmeringsfeil? Må jo være mye å hente på å lage programmeringsspråk som ikke er så fort gjort å gjøre feil i. Jeg har ikke programmert så mye, men merket meg at enkelte språk er mer utsatt for å lage feil i enn andre. Pascal husker jeg var rimelig kresen på koden, og det var passe greit å unngå "off by one errors". C++ er med sine pekere en ren jungel etter min mening og sikkert en viktig grunn til at vi har så mange buffer overflows. (...)

Korrekt. Noen programmeringsspråk krever at kompilatoren tar seg av minneallokering og frigjøring (eks: Java, Perl, PHP, VB, TCL, etc.), og har dermed heller ingen kommandoer/intet syntax for disse operasjonene, og dermed ingen mulighet til å gjøre direkte feil.

 

"Old school"/hardcore-programmerere mener gjerne at dette fører til dårligere kompilert kode, på samme måte som HTML-kodere gjerne mener at WYSIWYG-editorer lager dårligere generert kode enn om man koder HTML for hånd. Noen programmerere drar det enda lengre, og mener man helst bør lage assembler-kode, altså kode på instruksjonsnivå for et spesifikk instruksjonssett (altså: for spesifikke prosessorer) og dermed i stor grad omgå hele kompilatoren. Etter hvert som tiden går blir dette et dårligere og dårligere argument, ettersom kompilator-teknologien blir stadig bedre, og i mange tilfeller nå klarer å optimalisere programmerings-koden din på en bedre måte enn du selv ville klart.

 

I eldre språk som C og C++ har man altså større kontroll, men dermed også større muligheter for å gjøre feil. Større kontroll kan imidlertid føre til økt hastighet, og dette samt historiske grunner er bakgrunnen for at de fleste operativ-systemer i dag fremdeles har C/C++-programmerte kjernekomponenter (eks: Unix, Linux, Windows inkl. WinXP, etc.), og derav også har større problemer med buffer overflows enn et Java-basert operativsystem i teorien ville hatt. Hm... Jeg lurer på om dette nye Java-OS-et til Sun (som jeg ikke husker navnet på) er fullstendig Java-basert!?

 

Uansett, dette er jo det klassiske problemet som går igjen innen mange områder teknologien berører: Skal man automatisere mest mulig, eller skal man ha mest mulig kontroll selv? De som fordyper seg innenfor hvert område (eks: digitalkameraer) mener stort sett at det er best å ha kontroll, mens bestemor hjemme i gyngestolen stort sett mener det er best med en enkelt knapp, som gjør alt på en gang.

 

Edit: Disclaimer: Arrester meg gjerne om noen av påstandene over ikke skulle være korrekte. De er fremstilt etter beste evne og min forståelse for hvordan ting henger sammen.

Endret 14. januar 2004 av Pureblade

[Knick Knack]

Om ikke arrestert så er du i allefall avslørt. 4. eller 5. år SIE6 skulle jeg anta? right?

 

"(..) (eks: digitalkameraer) (..)"

[the_lynx]

(...) men er det ikke slik at f.eks. Java er lagd for å unngå programmeringsfeil? Må jo være mye å hente på å lage programmeringsspråk som ikke er så fort gjort å gjøre feil i. Jeg har ikke programmert så mye, men merket meg at enkelte språk er mer utsatt for å lage feil i enn andre. Pascal husker jeg var rimelig kresen på koden, og det var passe greit å unngå "off by one errors". C++ er med sine pekere en ren jungel etter min mening og sikkert en viktig grunn til at vi har så mange buffer overflows. (...)

*masse tekst*

 

Et veldig bra svar Pureblade! Av det innlegget lærte jeg noe i dag også

[Martin Lie]

Om ikke arrestert så er du i allefall avslørt. 4. eller 5. år SIE6 skulle jeg anta? right?

Jeg skjønte ikke dette svaret. "SIE6" sier meg ingenting. Siden du snakker om "4. eller 5. år", kan det hende du snakker om utdanning? Og SI står kanskje for sivilingeniør (som vel har en ramme på 5 år?). Eller så er jeg helt på jordet her. Fint om du kommer med en oppklaring hvertfall, hehe.

 

the_lynx: Takker.

[avtrekkeren]

Om ikke arrestert så er du i allefall avslørt. 4. eller 5. år SIE6 skulle jeg anta? right?

Jeg skjønte ikke dette svaret. "SIE6" sier meg ingenting. Siden du snakker om "4. eller 5. år", kan det hende du snakker om utdanning? Og SI står kanskje for sivilingeniør (som vel har en ramme på 5 år?). Eller så er jeg helt på jordet her. Fint om du kommer med en oppklaring hvertfall, hehe.

 

the_lynx: Takker.

SI = Sivilingeniør

E6 = Europavei 6

 

Altså er det noe skummelt som vil skje med deg innen 4. eller 5. år på E6 av en sivilingeniør!

[dostojevski]

SIE6 = Linjekode for elektronikk på siv. ing. studiet på NTNU.

Sivilingeniørstudiet

Elektrofakultetet

Linje 6

Linje SIE3 - Teknisk kybernetikk

Linje SIE5 - Energi og miljø - Elektrisk energiteknikk

Linje SIE6 - Elektronikk

Linje SIE7 - Kommunikasjonsteknologi - Telematikk

Litt snålt at vi fremdeles bruker de gamle linjekodene etter at Elektrofakultetet gikk inn i historieboken....

 

-dostojevski (SIF2)

Endret 15. januar 2004 av dostojevski

[Martin Lie]

Aha! Takk for oppklaringen, dostojevski.

 

Må nok skuffe deg, Knick Knack. Jeg er bare vanlig ingeniør (snart). Data, som sådan, ved HiB (Høgskolen i Bergen). Men jeg er 3. års da, ferdig til sommeren. Har programmert en del år (privat), og dessuten jobbet som programmerer i 2 år før studiene da, om det hjelper?

 

(Og når det gjelder digitalkameraene, så tenkte jeg ikke på elektronikken i dem, men på bruken av dem; funksjoner og mulighet for å manuelt stille inn på ting vs. trykk-på-knappen-så-blir-det-bilde-serru. Jfr. akam.no-folkene vs. bestemor.)

Endret 15. januar 2004 av Pureblade

[Knick Knack]

OK er med. Tenkte du mente design av digitalkameraer. Siden eksemplet da virket litt far fetched så tenkte jeg du muligens hadde vært borti et fag som heter Enbrikke Systemer på NTNU. Går mye i digitale kameraer der... Samma det. Lykke til med hovedoppgaven!

[Martin Lie]

Jo, takk.