These are all valid concerns.
On Mon, Apr 04, 2005 at 10:22:37AM +1000, Peter Chubb wrote:
> This is one thing that bothers me most about this approach. User
> code is invoked before acknowledging the interrupt to the interrupt
> controller. As a general rule, kernel code should not trust user code
> for its correct operation. If the ULI does not clear the interrupt,
> (because it is malicious, say) then there is a distinct possibility of
> DOS here.
The idea is that only trusted code by priviledged users will be run.
Let's assume for a moment that this isn't true. My understanding of the
IA64 code is the following.
- Interrupt handling ends up in __do_IRQ()
- __do_IRQ() ACKs the interrupt with an infrastructure provided function
- control passes to handle_IRQ_event()
- Each registered handler is run. These include traditional kernel drivers,
ULIs, etc
- control returns through __do_IRQ() to ia64_handle_irq()
- ia64_eoi() is called to lower the blocked interrupt class and allow the
interrupt to be handled again
> However, I think that the thing that bothers me *most* about SGI's ULI
> approach is that a full context switch is not done. The ULI runs as
> if it were in the interrupted process's context. `current' isn't
> changed, so it runs with the privileges of the interrupted process.
> The *way* it runs (CPU bound, presumably) will affect the scheduler's
> decisions about how to run the interrupted process in the next
> timeslice. For most interrupt handlers this won't matter, but it'd be
> relatively easy to construct a malicious one to slow particular
> processes.
Again the idea is that the handler function was registered by root or
some priviledged developer making a conscious decision. This is currently
protected by permissions on the /dev/uli file. If you'd like me to add
permission checks to the kernel functions I'd be happy to do it.
Another help here is that handlers can only run for a certain amount of
time. I think the arbitrarily chosen limit right now is ~10us. A handler
that has to do anything more than simple work should wake up a thread /
process to do so. I can make that time limit configurable if you'd like.
> Running at interrupted process provilege doesn't matter very much,
> because all system calls are mapped onto uli_syscall if you're running
> as a user-level interrupt. However, this severely limits what you can
> do in a handler. For example, you can't wake threads waiting on a
> futex (something we find very common in a user-level interrupt handler).
Currently its own semaphore approach is supported. If you'd like me to
switch it to use futexes I can do that.
Thanks,
Michael
--
Michael A. Raymond Office: (651) 683-3434
Core OS Group Real-Time System Software
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
