Newsgroup: it.comp.lang.c++
Titolo: acquisire priorità sul sistema operativo

vorrei sapere se si può bypassare il sistema operativo raggiungendo il
pieno controllo della macchina, oppure se indipendentemente dal
linguaggio di programmazione (assembler, java, c, visual basic, perl,
phtton, eccetera) e dal sistema operativo (windows, linux, altri) si è
sempre costretti a sottostare al sistema operativo. Insomma, è
possibile acquisire la priorità sul sistema operativo?


Se ti scrivi tu un piccolo sistema operativo (e non è banale), sì.
Se vuoi utilizzarne uno esistente, devi sottostare alle regole del SO 
(ovviamente :-) ).
Per avere pieno controllo della macchina devi ovviamente usare linguaggi 
che te lo consentono. Linguaggi di basso livello come Assembly o C/C++, 
o anche alcuni linguaggi di alto livello hanno compilatori che generano 
codice macchina. (Con Linux hanno scritto anche alcuni moduli in Ocaml)
Linguaggi come Java che compilano verso bytecode, C# et simili che 
utilizzano compilatori Jit e linguaggi interpretati come Perl, php, 
ruby, python ecc. necessitano assolutamente di macchine virtuali e/o 
interpreti per girare.
I sistemi operativi rendono disponibile il controllo della macchina 
(fisica) a patto di scrivere un driver (usando un DDK nel caso di M$, o 
scrivendo un modulo per il kernel nel caso di *NIX) che agisce ad un 
livello inferiore, quindi può accedere direttamente all'hardware, può 
creare *grossi* danni (se non si presta attenzione) al computer e 
possono inchiodare il sistema a livello di kernel (BSOD, RSOD, Kernel 
panic).
PS: per fare prove in questo senso, ti consiglio fortemente l'uso di un 
emulatore come Qemu, Bochs (gratuiti, e Qemu è anche in grado di emulare 
piattaforme differenti come PowerPC, Arm ecc.) o VMWare et simili. In 
questo modo gli errori rimangono limitati ad un PC virtuale e non si 
ripercuotono sulla macchina.
PSK


Nemmeno in asm sfruttando l'int 80 si riesce (magari bloccando tutto) a 
passare la protezione del sys operativo


>
[...]
Quando chiami l'int 80, come l'int 33 (che era del mouse in dos), o int 
19 (che in dos faceva il reboot), continui a chiamare funzioni del BIOS 
o funzioni del SO o come succedeva nel DOS delle funzioni di programmi TSR.
E' logico che un SO sostituisca gli interrupt del BIOS che gli possono 
rompere le uova nel paniere con qualcosa più sotto il suo controllo. 
(l'80 non gestisce il disco?)
Andare sulla macchina non significa chiamare i vari int, ma scrivere sui 
bus, modificare i registri della CPU, dell'RTC, gestire direttamente la 
memoria centrale, quella video o memorie di altri dispositivi, gestire 
in maniera diretta il vettore degli interrupt per lavorare con i segnali 
di IRQ delle singole periferiche, gestire i trasferimenti dati con i 
DMA, e tanto altro ancora. Tutto ciò per cui i SO sono stati scritti.
Anche in àmbito embedded si tende ad utilizzare dei piccoli SO per non 
dover riscrivere ogni volta routine che permettano la gestione in 
multitasking o alcune gestioni di memoria.
In asm o in C, se lavori in DOS o ti scrivi tu un piccolo SO, puoi 
"sostituire" l'int 80. E senza neanche tanto sforzo. Farlo per metterci 
qualcosa che funziona senza fare danni, è un altro conto.
Ciao
Luca