[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Vulnerabilities in Synchronous IPC Designs
From: |
Espen Skoglund |
Subject: |
Re: Vulnerabilities in Synchronous IPC Designs |
Date: |
Mon, 2 Jun 2003 13:29:32 +0200 |
[Jean-Charles Salzeber]
> Hi,
> As stand in
> http://www.eros-os.org/papers/IPC-Assurance.ps
> the L4 IPC system might be vulnerable to DoS attacks. What are your
> opinions about this?
Just had a quick glance at the paper. Here are some initial thoughts:
o Jonathan is talking about an 8 year old L4 API. While many
weaknesses has been identified and fixed in the new API, some of
the issues he addresses has not been dealt with yet.
o He mentions that segment registers are not reloaded on context
switches for the kernel with which we did performance
measurements. This is wrong. Segment registers must always be
reloaded when doing context switches on a kernel with small
spaces. (L4Ka::Pistachio currently does not implement this.)
o His claim about transparent interposition in the alternative IPC
redirection model being difficult is debatable.
o An L4 server would typically never use timeouts (i.e., it will use
zero-timeouts) for message transfer, and the claim that timeouts
pose a denial-of-service threat for servers is therefore dubious.
o I don't buy the argument about reproducibility. If you want
reproducibility of a program you must ensure that the whole system
state (including hardware) can be set to some initial state and
that the re-run of the program is handled exactly in the same
way at the hardware level. Given that this is not doable in
current systems, there is no way that exact reproducibility can be
guaranteed. There will always be some timing implications. It
might be that he talks about reproducibility at a different level
here, though.
o The Karslruhe group has worked on a another IPC model which
handles complete subsystem isolation, while still enabling
transparent interposition and having minimal performance overhead.
Unfortunately, the paper describing the model was not accepted
for publication. Should probably get around to polish it a bit
more and make a TR out of it one of these days.
Anyway, as I said, these are only initial thoughts. It might be that
I missed some key points. I suppose I'll have to read through the
paper more carefully.
eSk
- Vulnerabilities in Synchronous IPC Designs, Jean-Charles Salzeber, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs,
Espen Skoglund <=
- Re: Vulnerabilities in Synchronous IPC Designs, Jean-Charles Salzeber, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Niels Möller, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Espen Skoglund, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Marcus Brinkmann, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Espen Skoglund, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Marcus Brinkmann, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Espen Skoglund, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Marcus Brinkmann, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Andreas Haeberlen, 2003/06/03
- Re: Vulnerabilities in Synchronous IPC Designs, Marcus Brinkmann, 2003/06/03