NX Bit anche per Intel

NX Bit anche per Intel

Nel terzo trimestre dell'anno Intel ha intenzione di implementare la tencologia di sicurezza NX Bit

di pubblicata il , alle 18:04 nel canale Processori
Intel
 
64 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
leoneazzurro07 Luglio 2004, 19:29 #11
Come i 64 bit c'erano nell'Alpha...
Chiaramente qui si parla di processori x86
Lucrezio07 Luglio 2004, 19:43 #12
Le fonti hanno sottolineato che i processori desktop Pentium 4, Celeron D e Nocona con supporto NX Bit sarà disponibile nel terzo trimestre dell'anno
in questa frase c'è qualcosa che nn va...
riguardo a questo NX nn sarà un buon precedente per palladium?
Ikitt_Claw07 Luglio 2004, 20:25 #13
Originariamente inviato da Lucrezio
riguardo a questo NX nn sarà un buon precedente per palladium?


Se e` quello che dichiarano, no.
repne scasb07 Luglio 2004, 20:27 #14
Ikitt_Claw07 Luglio 2004, 20:31 #15
Originariamente inviato da repne scasb
La novita' consiste nel fatto che finora il condizionamento dell'esecuzione in funzione del modello di mappatura della RAM si
era visto sono in achitetture inefficienti (sia RISC che Vliw).


Qualche dettaglio in piu` su questa inefficienza? E` un fatto di design?

quanto tempo impiega una CPU per verificare che CS:EIP sta in RO?


Il tempo di un lookup ulteriore nel TLB nel caso medio, suppongo
repne scasb07 Luglio 2004, 21:19 #16
magilvia07 Luglio 2004, 22:37 #17
Da questo punto di vista il NO_EXECUTE non
permettera' piu' la possibilita' di scrivere codice automodificante; in sostanta tutto cio' rappresentera' una certa perdita di
efficienza per il software che fa della velocita' un fattore critico, non solo per quanto riguarda la possibilita' del codice
assembly di automodificarsi,

Infatti questo è male. Ho letto su www.doom9.org di un utente che ha il service pack 2 e virtuadub (un noto programma fortemente ottimizzato per l'editing video) va in errore sembra proprio a causa di codice assembler automodificante. Ora considerando che occorrono ore e ore per fare editing video se ciò dovesse essere confermato vorrà dire che non potremo più contare su tale codice ottimizzato aumentando i già lunghi tempi di video editing.
jappilas07 Luglio 2004, 22:47 #18
quello che avevo sentito era che in realtà il codice automodificante sarebbe stato "bandito" anche se non ufficialmente , cioè deprecato, e che lo stesso kernel di NT non ne consentirebbe l' esecuzione...
e ciò da anni, per limitare la pericolosità dei virus (soprattutto quelli polimorfici, che nel decennio scorso andavano abb di moda) e di programmi scritti in modo "sporco" ...

...può anche essere che fossero tutte storie ...
bertoz8507 Luglio 2004, 23:15 #19
cmq Ikitt_claw & "repne scasb" (MITICO!!) è sempre un piacere leggervi, non sarò l'ultimo scemo sulla terra in fatto di PC ma voi ne sapete veramente troppaa!!! sapete che un tempo (ma anche oggi) famiglie intere muoiono stranamente perchè sapevano troppe cose?? non vorrei che vi succedesse anche a voi

cmq siete dei grandi!!!!
^TiGeRShArK^08 Luglio 2004, 00:20 #20
ma ke io sappia il codice automodificante era utilizzato solo in ambiti molto particolari quali demo tecnologiche (tipo quelle ke in 64 kb fanno una marea di animazioni 3d x intenderci) e ke cmq serviva solo a contenere le dimensioni complessive del file e non ad aumentarne la velocità....
in effetti non riesco proprio ad immaginare una situazione in cui il code morphing possa postare ad incrementi prestazionali anzikè a peggioramenti....
se qualcuno mi ilumina mi fa un grooso piacere....

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^