[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proxy memory objects (was: Denial of service attack via libpager)
From: |
Olaf Buddenhagen |
Subject: |
Proxy memory objects (was: Denial of service attack via libpager) |
Date: |
Mon, 19 Sep 2016 17:32:27 +0200 |
User-agent: |
Mutt/1.6.0 (2016-04-01) |
Hi,
On Mon, Aug 29, 2016 at 11:15:48AM +0200, Richard Braun wrote:
> OK, this comes from the fact that io_map directly provides memory
> objects indeed... Do we actually want to pass them around ? How
> come calls like memory_object_init (specifically meant to be used
> between the kernel and the pager) can be made from any client ?
[...]
> If we consider Unix as a reference, then the map call uses a file
> descriptor. It's equivalent to a memory object because the translation
> is done privately in the kernel, but we could also change the
> mapping interface to provide some proxy object to the client,
> which could be thought of as an unprivileged memory object.
[...]
> The changes involved here are heavy, which is one reason we'd want
> to avoid them.
Note that we already have proxy memory objects is gnumach. (At least the
Debian variant -- don't know whether this ever went upstream.) It
currently only implements restrictions on write access (with Marcus'
original patch), and for offset/size (with my additions); but I suspect
it should be easy to also add restrictions on the management RPCs?
Note though that I never fully understood how the memory object
management protocol works and is used -- so no idea how that would
affect the Hurd as a whole...
-antrik-
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Proxy memory objects (was: Denial of service attack via libpager),
Olaf Buddenhagen <=