[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some other memory considerations.
From: |
Marcus Brinkmann |
Subject: |
Re: some other memory considerations. |
Date: |
Tue, 26 Oct 2004 14:54:54 +0200 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Tue, 26 Oct 2004 14:08:03 +0200,
Bas Wijnen <address@hidden> wrote:
> L4 allows it, indeed. However, our current ideas of the Hurd don't. In
> fact, they don't allow it even if you are a pager.
Let's say that our design should not rely on this being possible.
> Mapping memory to an other task costs kernel memory. Therefore, it can
> be used for a denial of service attack against the system. Because of
> that, it must be a restricted operation, which can only be performed by
> trusted tasks (and will in practice only be performed by physmem, I
> think.) Note also that pagers are not trusted tasks. So for a pager to
> map memory to a task, it has to ask physmem to do it. Granting memory
> is not a problem, and will be allowed. I'm not sure if it would be used
> much, though.
Granting memory across address spaces is probably OK, but I am not
sure. In any case, the only thing we need (and can allow) is granting
memory within your own address space (ie, change the vaddr of a mapping).
Marcus
- making paging decisions, Marcus Brinkmann, 2004/10/25
- some other memory considerations., Rian Hunter, 2004/10/26
- Re: some other memory considerations., Espen Skoglund, 2004/10/26
- Re: some other memory considerations., Rian Hunter, 2004/10/26
- Re: some other memory considerations., Marcus Brinkmann, 2004/10/26
- Re: some other memory considerations., Bas Wijnen, 2004/10/26
- Re: some other memory considerations., Marcus Brinkmann, 2004/10/26
Re: some other memory considerations., Marcus Brinkmann, 2004/10/26