[Xenomai-core] Manual interrupt handling by cli/sti instructions

[Xenomai-core] Manual interrupt handling by cli/sti instructions

[Rodrigo Rosenfeld Rosas]

Hi Philippe,

Actually I think it is an Adeos issue, but it is also relevant for Xenomai.

Does Adeos have any protection (I do not know if it is even possible to) 
against a Linux module issuing a cli/sti code directly through arch specific 
code instead of through some Linux API. Putting it in other way, is it 
possible that a third-party module breaks out the determinism in the Xenomai 
domain?

Thanks in advance,

Rodrigo.

		
_______________________________________________________ 
Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. 
http://br.messenger.yahoo.com/

[Xenomai-core] Re: Manual interrupt handling by cli/sti instructions

[Philippe Gerum]

Rodrigo Rosenfeld Rosas wrote:
> Hi Philippe,
> 
> Actually I think it is an Adeos issue, but it is also relevant for Xenomai.
> 
> Does Adeos have any protection (I do not know if it is even possible to) 
> against a Linux module issuing a cli/sti code directly through arch specific 
> code instead of through some Linux API. Putting it in other way, is it 
> possible that a third-party module breaks out the determinism in the Xenomai 
> domain?

Yes, we cannot do much about misbehaving binary-only module or code 
which does not use the kernel API to control the interrupt mask at CPU 
level.

A way to deal with this on x86 would be to move the kernel code to a 
different protection ring than #0, so that using protected insns like 
cli/sti would beget an exception (provided no one fiddles with the iopl 
though), and route the hw masking/unmasking requests to the virtualized 
Adeos pipeline stall/unstall ops instead. Obviously, an awful lot of 
other issues would be raised by such move, such as dealing with other 
protected insns/accesses, and beyond that, all the mess people doing 
full O/S virtualization have to deal with on a daily basis.

Another way would be to play the "afterburing" game I guess, searching 
for cli/sti opcodes in the kernel/driver image and poking replacement 
code to do the same virtualization stuff, but the original opcodes are 
only 1-byte long, so some additional trickery would likely be needed, 
along with other issues the afterburning technique raises (e.g. you 
don't want to replace _all_ hw interrupt masking/unmasking in the image 
blindly).

> 
> Thanks in advance,
> 
> Rodrigo.
> 
> 		
> _______________________________________________________ 
> Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. 
> http://br.messenger.yahoo.com/
> 


-- 

Philippe.