Newsgroup: it.comp.hardware.cpu
Titolo: Curiosita': protezione memoria

Ciao.
Nelle note del SP2 per WinXP, leggo che hanno "finalmente" (!)
implementato la protezione della memoria, impedendo l'esecuzione dai
segmenti dati. Purtroppo pero', dicono, la cosa funziona attualmente
solo sui processori a 64-bit, ma non e' escluso che in futuro escano
processori a 32 bit che consentano cio'.
Che io ricordi, questa protezione c'era gia' sui 286, quindi...
a) mi ricordo male/ho bevuto/ho le allucinazioni...
b) effettivamente c'e', ma non puo' essere utilizzata perche'...
c) MicroSoft per qualche motivo non vuole usarla...
d) c'e', ma e' scomoda e non la usa nessuno...
e) ...
Qualcuno sa dirmi qualcosa di piu' preciso?
Io credevo che questo meccanismo fosse gia' in uso in Windows...
qualcuno sa dirmi qualcosa riguardo agli altri sistemi operativi?
 bye & Thanks
	av.

 d) c'e', ma e' scomoda e non la usa nessuno...
Se parli della memoria protetta utilizzata in dos, mi sa che non centra
niente....


Ni.
Ora non ricordo esattamente cosa fosse la "memoria protetta" in DOS.
Ricordo pero' ad esempio che una volta provai a convertire un programma
che avevo scritto in Pascal da modalita' reale a DPMI e non ci riuscii
(ovvero lasciai perdere), perche' caricavo da disco dei pezzetti di
assembler precompilati e li eseguivo. Cio' non era piu' lecito, sotto
DPMI, proprio perche' non si potevano eseguire dati.
Questo per dire che, secondo me, un meccanismo che fa cio' che l'SP2
vuole in questi processori c'e'; mi chiedevo solo perche' non fosse
applicabile.
 bye & Thanks
	av.

 Che io ricordi, questa protezione c'era gia' sui 286, quindi...
Sono due tipi di protezione diversi, sia nel concetto sia nei meccanismi.
Nei 286 è stata implementata la protezione della memoria in lettura e
scrittura: in lettura, stabilendo spazi di indirizzamento distinti tra i
vari processi; in scrittura, abilitando un apposito flag nelle entry della
tabella delle pagine.
La nuova protezione presente sui K8 è invece una protezione
dall'esecuzione (se (E/R)IP punta a un'area di memoria protetta viene
sollevata un'eccezione). Questo si ottiene tramite un nuovo flag nelle
entry della tabella delle pagine.
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 processori a 32 bit che consentano cio'.
la protezione sarà software per le cpu che non la supportano hardware.
Lenny 

 entry della tabella delle pagine.
Eppure, riesumando da un libro che ho un vecchio esempio in assembler
286, viene data la seguente struttura da usare nelle GDT:
descrittore	STRUC
limite_seg	dw 0
base_lsb	dw 0
mase_msb	dw 0
dir_acc		db 0  ; byte dei diritti di accesso
		dw 0
descrittore	ENDS
....
accesso_cod	equ	10011011b ;byte dei diritti di accesso a segmenti di
codice
accesso_dati	equ	10010011b ;byte dei diritti di accesso a segmenti di
dati
E mi ricordo anche (come descritto in altro messaggio), che con questa
cosa mi ci scontrai...
 bye
	av.

 Che io ricordi, questa protezione c'era gia' sui 286, quindi...
Gli x86 attualmente supportano solo 2 protezioni per pagina di memoria
(in hardware): lettura e scrittura. La lettura implica anche il permesso
di esecuzione. Il problema e` che normalmente lo stack di un processo e`
marcato come leggile/scrivibile (e quindi implicitamente eseguibile);
con un buffer overflow e` possibile fare eseguire del codice "maligno"
[1] inserito nello stack sfruttando questa debolezza. Gli AMD64
introducono un'ulteriore bit per indicare la possibilita` di eseguire
codice contenuto in una data pagina di memoria; marcando lo stack come
non eseguibile si bloccano tutti gli attacchi di tipo buffer overflow
(ed e` questo che fa il service pack).
E` possibile emulare il bit mancante anche su x86 in software (linux ad
esempio lo fa, anche se la patch non e` nella mainline il codice e`
presente da molto tempo nei kernel della RH e negli -mm).
Forse tu ti stai confondendo con la generica "protezione della memoria"
(ie. indirizzamento virtuale).
Luca
[1] Esistono anche casi leciti di costruzione di codice sullo stack.
-- 
Home: 
http://kronoz.cjb.net
Se alla sera, dopo una strepitosa vittoria, guardandoti allo
specchio dovessi notare un secondo paio di palle, che il tuo 
cuore non si riempia d'orgoglio, perche` vuol dire che ti 
stanno inculando -- Saggio Cinese


Il meccanismo che inibiva l'esecuzione implementato dai 286 in su
operava a livello di descrittori di segmento, *ma non* a livello
di pagine di memoria.
A livello di pagine di memoria (supportate dai 386 in poi)
c'era solo la possibilita di marcarle come read-only
oppure di marcarle come riservate ad accesso privilegiato
(user oppure superuser).
Visto che le versioni a 32bit di windows usavano il modello
di indirizzamento "flat" (con tutti i segmenti che puntano
alla base dei 4GB di memoria indirizzabile linearmente
e con dimensione di segmento 4GB eccetto che per FS e GS
che vengono usati in altor modo da Windows), la protezione
di esecuzione a livello di segmento era praticamente inutile
(potevi modificare una zona di memoria
  indirizzandola tramite il registro di segmento DS
  e la eseguivi tramite il segmento CS)).
Con le cpu K8 (Opteron, Ahtlon64) AMD non ha fatto altro che
sfruttare un bit ancora non utilizzato nei descrittori di pagina
e lo ha usato come flag che stabilisce se si puo accedere alla pagina
per caricarne il contenuto nella cache istruzioni e/o
verso il decoder delle istruzioni.
L. Micheletto

Lenny wrote:

Ne dubito, l'unico modo per *approssimare* una protezione simile a livello
software sarebbe marcare come superuser page oppure come missing page
tutte le pagine di memoria utente in modo da far scattare un eccezione
ad ogni accesso/reload di una nuova pagina che oltre alle altre cose
controlli cosa sta per succedere (accedendo ad una "page table ombra").
A parte il fatto che questo abbasserebbe pesantemente le prestazioni
(anzi, piu che abbassarle le stroncherebbe) non si avrebbe neppure una
protezione allo stesso livello di quella hardware.
Semplicemente su cpu senza supporto dell'NX bit non ci sara' tale
tipo di protezione.
L. Micheletto

 verso il decoder delle istruzioni.
Ma questo e' trasparente al programma, o c'e' bisogno di uno sforzo
anche da parte del programmatore dell'applicativo?
 bye & Thanks
	av.

 controlli cosa sta per succedere (accedendo ad una "page table ombra").
Mi correggo, c'e' un alternativa piu semplice ed efficiente
(ecco cosa succede a scrivere andando di fretta).
Introdurre a livello di S.O. una descrizione delle aree di codice
(es: una lista di zone di memoria dove e' ammessa l'esecuzione
      oppure sfruttando il bit "non utilizzato" sui descrittori di pagina
      delle cpu che non supportano il bit NX)
e sfruttare la funzionalita "single step on branch" degli x86
per intercettare i branch, i jump e le altre eccezioni
in modo da controllare che il program counter non esca mai
dalle zone ammesse.
Ma anche questa soluzione influirebbe pesantemente sulle prestazioni
(*tutti*  i branch/jump/ecc.ecc. del codice "sotto controllo"
  avrebbero un aggravio superiore ad un branch mal predetto).
L. Micheletto

 Introdurre a livello di S.O. una descrizione delle aree di codice
Hai quasi descritto exec shield ;) Per una descrizione approfondita:
http://lwn.net/Articles/31032/
Luca
-- 
Home: 
http://kronoz.cjb.net
This message will self destruct in 5 seconds.

 anche da parte del programmatore dell'applicativo?
E' quasi sempre completamente trasparente al programma, le eccezioni
principali sono i casi in cui un programma o una dll "scrive" codice
nello stack o nello heap e poi lo esegue direttamente da li
( se invece carichi un programma o una dll ci pensa il S.O. a "marcare"
   le zone dove viene caricato del codice)
per questo c'e' la possibilita di disabilitare selettivamente l'NX check
(nel caso si utilizzino applicazioni "vecchie" che compilano
  al volo il codice).
In quei casi, per le nuove applicazioni o per quelle vecchie
che verranno aggiornate credo che vi sia la possibilita
(tramite una qualche funzione di sistema) di allocare "memoria eseguibile"
altrimenti per i compilatori JIT (sia la JVM che MS.Net) sarebbero dolori
idem per quei programmi che ad esempio per eseguire filtri molto complessi
o cose simili "ottimizzano" compilando il filtro al volo
in modo da trasformare in costanti i parametri ed eliminando
tutti jump condizionali "decisi a priori" dai parametri fissati
(un confronto tra due parametri "fissati" ed il jump su condizione
  dipendente da esso vengono trasformati in un jump non condizionale
  oppure eliminati totalmente in base al risultato del confronto
  "costante").
L. Micheletto