Gå til innhold

Exit Palladium, NGSCB?


Anbefalte innlegg

Videoannonse
Annonse

Bra.

Det hadde vært bra om nå M$ tok et hint fra folk, og ikke prøver å tre uønskede ting over hodet til folk. Historien viser at slike metoder vanligvis ikke funker.

 

*host* *rambus* *host*

Lenke til kommentar

Første slag er vunnet!

 

Endelig en skikkelig gladnyhet! En av grunnen til navnebyttet fra Palladium til det mer politisk korrekte NGSCB, var vel gjerne at det ble kjent litt for fort hva det egentlig var for noe og at for mange ble klar over det.

 

MS har jo også stressa litt med dette fordi åpen kildekode er blitt mer og mer populært, og de måtte derfor få igjennom dette mens de enda har nesten monopol hos klientene. Men nå ser det altså ut til at de blir i verste fall forsinka!

 

:thumbs::w00t::thumbs:

 

(et annet forum jeg er på har party-smiley!)

Lenke til kommentar

Det virker som Microsoft dropper NGSCB til fordel for NX-bit ifølge CRN:

http://www.crn.com/sections/BreakingNews/d...ArticleID=49936

 

"Though Microsoft plans to use the NGSCB "compartmentalizing" technology in future versions of Windows, the company is moving swiftly to support No Execute (NX) security technology in newer AMD and Intel processors. NX reduces memory buffer overruns that many hackers exploit to insert malicious code into Windows and allows developers to mark pages as nonexecutable."

 

Alle AMD64-prosessorer støtter NX-bit, mens Intel først får støtte for det i nyere Xeon-proessorer som kommer senere i år :)

 

NX-bit er allerede støttet i Windows XP 64-Bit, og vil bli lagt til i Windows XP (32-Bit) med SP2, men dette har ingenting med NGSCB å gjøre bare så det er helt klart.

Endret av snorreh
Lenke til kommentar
Det virker som Microsoft dropper NGSCB til fordel for NX-bit ifølge CRN:

http://www.crn.com/sections/BreakingNews/d...ArticleID=49936

 

"Though Microsoft plans to use the NGSCB "compartmentalizing" technology in future versions of Windows, the company is moving swiftly to support No Execute (NX) security technology in newer AMD and Intel processors. NX reduces memory buffer overruns that many hackers exploit to insert malicious code into Windows and allows developers to mark pages as nonexecutable."

 

Alle AMD64-prosessorer støtter NX-bit, mens Intel først får støtte for det i nyere Xeon-proessorer som kommer senere i år :)

Jeg er ikke på langt nær like skeptisk til NX som 1984-opplegget fra MS, men håper ikke at NX utvikler seg noe særlig mer heller. Med en videreføring kan NX bli noe opplegg som MS har begynt på, men foreløpig er det faktisk trygt fordi kontrollen ligger ekte lokalt og kun på prosessor/minne-nivå i motsetning til Palladium/ NGSCB.

Lenke til kommentar
Alle AMD64-prosessorer støtter NX-bit, mens Intel først får støtte for det i nyere Xeon-proessorer som kommer senere i år :)

Det er akkurat det de IKKE kommer til å gjøre... :p NX-bitet er en av de får forskjellene på Intel og AMD sin implementasjon av AMD64 (x86-64)

 

Intel støtter NX-bit i Itanium (IA64)

Lenke til kommentar
Raptor' date='06/05/2004 : 13:19']
Alle AMD64-prosessorer støtter NX-bit, mens Intel først får støtte for det i nyere Xeon-proessorer som kommer senere i år :)

Det er akkurat det de IKKE kommer til å gjøre... :p NX-bitet er en av de får forskjellene på Intel og AMD sin implementasjon av AMD64 (x86-64)

 

Intel støtter NX-bit i Itanium (IA64)

Stemmer det :blush:

Lenke til kommentar
Alle AMD64-prosessorer støtter NX-bit, mens Intel først får støtte for det i nyere Xeon-proessorer som kommer senere i år :)

Noen som har linker til noen (gode) artikler om NX-bit? Og burde det ikke hete NX-flagg? :p

 

Deilig å se monsteret bli kvalt før fødselen forresten. Det kunne fort blitt Stygt™.

Lenke til kommentar
Noen som har linker til noen (gode) artikler om NX-bit? Og burde det ikke hete NX-flagg? :p

Eneste jeg foreløpig vet om er dette dokumentet (se s. 175):

http://www.amd.com/us-en/assets/content_ty..._docs/24593.pdf

 

5.6.1 No Execute (NX) Bit

The NX bit in the page-translation tables specifies whether instructions can be executed from the page. This bit is not checked during every instruction fetch. Instead, the NX bits in the page-translation-table entries are checked by the processor when the instruction TLB is loaded with a page translation. The processor attempts to load the translation into the instruction TLB when an instruction fetch misses the TLB. If a set NX bit is detected (indicating the page is not executable), a page-fault exception (#PF) occurs.

Lenke til kommentar

Oh joy :thumbup:

Ble rent svett da jeg leste om Palladium første gang, og begynte å se for meg diverse scenarier som at jeg fremdeles satt med min trofaste XP2400 og Windows 2k om ti år, men nå ser det heldigvis ikke ut til å skje da... Iallfall ikke på en stund. *phew*

Må si at jeg heller risikerer å få ett par ormer på maskina, framfor å overlate styringa til MS :scared:

Lenke til kommentar

Det står en del om NX-bit og Microsofts Data Execution Prevention (DEP) her:

http://www4.tomshardware.com/cpu/20040318/...on-fx53-06.html

 

Samt her:

http://user.cs.tu-berlin.de/~normanb/

http://msdn.microsoft.com/library/default....rityinxpsp2.asp

 

"Execution protection (NX, or no execute) is an operating system feature that relies on processor hardware to mark memory with an attribute indicating that code should not be executed from that memory. Execution protection functions on a per-virtual memory page basis, most often leveraging a bit in the page table entry (PTE) to mark the memory page.

 

Execution protection prevents code execution from data pages such as the default heap, various stacks, and memory pools. Protection can be applied in both user and kernel-mode. As execution protection prevents data execution from the stack, the specific exploit leveraged by the recent MSBlaster worm would have resulted in a memory access violation and termination of the process. On a system with execution protection, MSBlaster would have been limited to a Denial-of-Service (DOS) attack, but would not have had the ability to replicate and spread to other systems. This would have significantly limited the scope and impact of the worm. And although MSBlaster in its original form may have been less malicious, it should be noted that execution protection is by no means a comprehensive defense against all viruses, worms, and other malicious code."

Endret av snorreh
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...