[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]