[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 18:42:17 +0200

[Niels Möller]
> Jean-Charles Salzeber <address@hidden> writes:
>> This is exactly what is taken up in the L4 X2 ref manual:
>> | Pagefaults Three different types of pagefault can occur during ipc:
>> | pre-send, post-receive, and xfer pagefaults. Only xfer pagefault are
>> | critical from a security point of view.

>> So the question is: Is there any way to avoid denial of service if
>> a malicious client such send messages?

> I can see at least two different approaches:

> 1. Let xfer-timout=0 mean that the ipc should fail when the first
>    page fault happens. The communicating threads have to ensure that
>    their buffers are paged in before theipc call, and remain paged
>    in during the call. I think this is a minor change to the L4 API.

Does not need an API change.  It's all user-level defined policy;
i.e., an application can ask its pager to keep some memory pinned.

> 2. Use one server thread per user. Then any user can only DOS-attack
>    his or her own processes.

As I said in my original mail, this whole timeout problem would
probably not apply to most servers anyway.  If you can construct your
message in less than 64 words (message registers) you're fine.  If you
construct your message using mappings you're also fine.  Of course,
with mappings you might experience page faults on the mapped memory
(i.e., memory might be unmapped directly after being transferred).
This will have to be dealt with.  On the other hand, if you need to
handle large amounts of data (i.e., using mappings or long string
transferrs), you are probably going to do a more heavyweight operation
anyway, and chances are that handling the extra overhead of page
faults or timeouts then becomes negligible.

Bottom line: timeouts may or may not introduce a possibility for
denial of service attacks depending on the protocol agreed upon by the
two communicating parties.


reply via email to

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