Newsgroup: it.comp.os.linux.development
Titolo: Come mai le istruzioni privilegiate generano trap?

Perchï¿œ l'esecuzione di una istruzione privilegiata da parte di un 
programma (fuori dal ring 0) genera una trap?
Insomma perchï¿œ tutte le architetture (x86, ia64...) producono 
un'eccezione quando si verifica la situazione che ho descritto sopra?
Grazie

 programma (fuori dal ring 0) genera una trap?
Perche' non deve eseguirla :)
Se un programma utente potesse eseguire normalmente istruzioni dedicate al
sistema operativo, potrebbe combinare di tutto -- prendere il controllo del
SO o di altri processi, cambiare/distruggere lo stato della macchina a 
piacimento, infrangere qualsiasi barriera di sicurezza...
Pleg

 sopra?
È una caratteristica della famiglia di processori x86, ampiamente 
sfruttata dai sistemi operativi per evitare che programmi di utente 
possano prendere il controllo della macchina.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 un'eccezione quando si verifica la situazione che ho descritto sopra?
Non è vero. Il processore 8086 non ha istruzioni 
privilegiate e quindi non ha questo comportamento. Invece 
il processore 80286 ha alcune istruzioni non privilegiate 
leggono registri privilegiati. Ovviamente su questi due 
processori non può girare Linux. Ritengo che nel caso del 
80286 questo sia un errore di progettazione.

 possano prendere il controllo della macchina.
In realtà avere diversi modi di funzionamento ed istruzioni 
privilegiate è proprio di tutti i processori che possono 
supportare un sistema operativo multiprogrammato. Quindi è 
esattamente il contrario. Non a caso primi  processori della 
famiglia x86 erano noti per non poter supportare un vero 
sistema operativo multiprogrammato (per lo meno fino all'
introduzione dell'i386 e di OS2).

 80286 questo sia un errore di progettazione.
x86 non aveva delle istruzioni privilegiate che non trappano? E per questo 
ad es VMware doveva fare dynamic binary translation per poterle gestire?
Non ricordo bene.
Pleg 

 Non ricordo bene.
A parte quel "trappano" per cui meriteresti di essere
fustigato sulla pubblica piazza ricordi bene. Il problema 
è con le istruzioni che leggono i quattro registri  relativi 
description table e la table selection state. Pur essendo
istruzioni che devono essere eseguiti solo al livello 0  
non generano una eccezione quando vengono usate 
livello diverso da 0, per cui processo può accorgersi di 
venir eseguito in una macchina virtuale esaminando 
questi registri.

 progettazione.
L'errore di progettazione fu la mancanza di poter commutare fra 
protected e real mode (in seguito disponibile nel 80386 pochi anni più 
tardi).  Tutto il resto era il frutto della tecnologia di quegli anni 
(l'80286 fu introdotto sul mercato nel 1982) e IMO di un errore di 
valutazione dei Intel che pensava che MS-DOS potesse seguirla su 
quella strada.


 limitazione di 1M di ram.
Non capisco come una versione non modificata di Linux possa girare dato ceh


 quella strada.
Ti ricordo che in quegli anni (ed anche prima) esistevano il 68000
il 68010 ed il 68020 che implementavano soluzioni e tecnologie
che in casa INTEL arrivarono dopo una dozzina d'anni.

mallin.shetland ha scritto:

E' proprio per la questione della virtualizzazione che ho posto la domanda.
Le istruzioni che lavorano su questi registri (operazioni eseguibili 
anche senza privilegi elevati) sono dette, almeno nella letteratura, 
istruzioni sensibili non privilegiate e sono causa dei problemi di 
virtualizzazione del processore dell'archittura  introdotta da Intel.
Ora, sapete come è stato gestita la questione relativa a queste 17 
istruzioni sensibili ma non privilegiate?
Oltre al non-root mode e al root mode.
Thank