[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some other memory considerations.

From: Rian Hunter
Subject: Re: some other memory considerations.
Date: Tue, 26 Oct 2004 12:13:56 -0400
User-agent: Mozilla Thunderbird 0.8 (Macintosh/20040913)

Bas Wijnen wrote:

Espen Skoglund wrote:

[Rian Hunter]

By the way, is it even possible for two arbitrary tasks in L4 to map
memory to each other, assuming not one of them are pagers to the
other?  I'm not entirely sure but I don't think so.

Yes.  It is possible.

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.

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.


Ah, I see. Even if it was desired, how does a L4 task handle faults on pages that were mapped by another arbitrary task, when it faults to its pager? I'm assuming that the pagers are notified (either by the kernel or in some user protocol) whenever maps are granted to its client, or something like that.

Anyway, I guess I see how mapping operations will work: through physmem. Which does make loads of sense. But the HURD is bound to see lots and lots of page operations and optimizations, so physmem will have to be fiercely multi-threaded or fiercely well coded. Although I think this is a concern for when physmem is actually mature and supporting a full system.

reply via email to

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