All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Rodrigo Rosenfeld Rosas <lbocseg@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: [Xenomai-core] Re: Manual interrupt handling by cli/sti instructions
Date: Wed, 05 Apr 2006 23:58:49 +0200	[thread overview]
Message-ID: <44343D99.1060900@domain.hid> (raw)
In-Reply-To: <200604041623.47796.lbocseg@domain.hid>

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.


      reply	other threads:[~2006-04-05 21:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-04 19:23 [Xenomai-core] Manual interrupt handling by cli/sti instructions Rodrigo Rosenfeld Rosas
2006-04-05 21:58 ` Philippe Gerum [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44343D99.1060900@domain.hid \
    --to=rpm@xenomai.org \
    --cc=lbocseg@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.