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,


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



Xenomai-core mailing list

Reply via email to