l4-hackers January 2004

l4-hackers@os.inf.tu-dresden.de

14 participants
15 discussions

task creation in l4ka
by Jan Doerrenbaecher 29 Jan '04

29 Jan '04

Hi List! I have a some trouble with the task creation in l4ka. What I want/should do, is creating a task within the root task without using the rmgr. That means, I have to copy the text area of the new task in some memory region and I also have to allocate some memory for the stack. After this, I want to create the new task with the `l4_new_task` call. The problem now is, that I only have pointers dependent on the local address space of root task which I can give as input. Since the … [View More]

2 1

Build DROPS on debian testing
by Frank Matthieß 21 Jan '04

21 Jan '04

i want to take a look on fiasko, drops, dope and get via cvs -d :pserver:guest@os.inf.tu-dresden.de:/home/remote-cvs checkout oskit oskit10 l4env linux22 l4 the latest source. With the "Building DROPS HOWTO" from may 2003 i startup. The "make" run described in "1 Quickstart - 3." failed, because the dependency to automake wasn't mentioned in "3.2 OS requirements". Now make breaks with: ... Making all in dce make[7]: Entering directory `/usr/local/src/drops/l4/tool/dice/src/parser/dce' byacc … [View More]

3 4

Some question about l4, l4ka
by Frank Matthieß 20 Jan '04

20 Jan '04

Hi, i want to evaluate l4. The first problem i have is to chose the 'right' l4 version. * There is a Dresden version "l4 v2" There is a Karlsruhe version "l4 x.2" * L4Linux is available from Dresden als 2.2.x L4Linux is available from Karlsruhe als 2.4.x Both seems to run on both l4 ipc protocolversion. * At Dresden they have basic parts of os specific components, called DROPS. Also a implementation of an windowmanager (DOpE). At Karlsruhe i don't see any additional os specific … [View More]

1 0

ANNOUNCE: L4Linux 2.4
by Volkmar Uhlig 13 Jan '04

13 Jan '04

The L4Ka team is pleased to announce the availability of L4Linux 2.4, which is a deprivileged Linux kernel running on an L4 microkernel. The release contains support for the L4Ka::Pistachio and Fiasco kernels. It supports the IA32 architecture and features multi-processor support on L4Ka::Pistachio. L4Linux is available via anonymous CVS. L4Linux is for the L4 developer community, and operating systems researchers and developers at large. L4Linux offers a great environment in which to … [View More]

1 0

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 07 Jan '04

07 Jan '04

> -----Original Message----- > From: Hermann Härtig [mailto:haertig@os.inf.tu-dresden.de] > Sent: Tuesday, January 06, 2004 11:07 AM > > BTW, the perception that Jochen Liedtke considered speed to dominate > everything else (see some earlier email) is simply rubbish. > Jonathan's statement "that performance cannot be used to justify > fundamental insecurity" could as well originate from Jochen Liedtke. The hitserver is an example where this perception is not … [View More]

4 3

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 06 Jan '04

06 Jan '04

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Monday, January 05, 2004 9:31 PM > > I believe that I have now asked twice for a URL to this specification. > Can you send me a URL? Otherwise we will continue to waste > each other's > time. Please accept my apologies that, in the absence of this > document, I may have done so. > > If it was on one of the L4 web sites, I failed to see it. On the l4ka.org homepage is … [View More]a link to the latest snap shot (right now rev. 5), or use that link: http://l4ka.org/projects/pistachio/l4-x2-r4.pdf. The V4 spec is solely maintained in Karlsruhe. > > You immediately run into replacement policy issues. > > If there is a faster way, great! But protection is not merely > a desire. It is a hard requirement. *Every* mechanism I know > about for achieving a protected interface carries a fundamental > cost somewhere. You can do it with address space traversal, or > you can accept the need for a replacement policy, or you can do > something else, but you are going to pay *somewhere*. Or you are able to selectively choose to pay for it. > My problem is that performance cannot be used to justify fundamental > insecurity. Speed at the cost of correctness is simply unacceptable. Agree in general, however there are application domains which don't want to give up speed for an unused security model. And you have to accept that those apps exist, even if _you_ are not interested in those. > > Here the argument is around IPC redirection (which is arguably > > expensive). By sticking an interceptor in between you know which > > mappings go in and out. That way you can control it. But I suspect > > that fine-grain control over mapping privileges makes sense. The > > question is what this granularity should be--page or mapping in general. > > From a security perspective, the problem is with the > presence of mapping operations at all. Mapping establishes a > high-speed, mutable channel, so it tends to undermine reference > monitors. Of course you can't allow to permanently establish a page mapping but have to interpose it. However, nobody promised to have a protocol-transparent reference monitor using page mappings.... > My preferred model is that performing a send with a mapping on a > disabled descriptor would be treated as an access violation, and a > suitable exception would be delivered to fault handler. I > don't want to pay any indirection cost for the legal (non-mapping) IPCs. See above. > > You can transparently drop the mapping if it is not > allowed. Since the > > guarantees whether a page is mapped or not come from the > pager hierarchy > > it is only as strong as all combined pagers. By adding a > > non-guaranteeing pager in the hierarchiy you are set. > > >From a security perspective, failing silently is *always* a > mistake. It > also makes virtualization difficult if somebody wishes to be backward > compatible with the interface later. You are describing a situation in > which a sender has done a known-illegal operation, but no fault is > generated? This doesn't seem like a good design. Why? You fault again--the client broke the protocol. You can define a protocol which does not allow page mappings. If anybody tries--too bad. Why do you care about virtualization and what virtualization do you have in mind? (I think it is more a Q of transparency.) > It is a big problem for the pager to be settable by the thread. There > are some systems in which this can be permitted, and other systems in > which it **must not** be permitted. Because there exists systems in > which this must not be permitted, the operation must (at a minimum) > involve invocation of a trusted party. > > Perhaps there is some third design possibility that I have not > considered carefully enough, but it appears to me that a > high-assurance system constructed on top of L4 must be built > exclusively using trusted pagers. While it is possible, in abstract, > to use untrusted pagers in a descriptor-based system (as EROS does), > the L4 map/grant operations don't appear to provide enough book-keeping > controls to be trusted. I guess you have to give a little more information about that--maybe on a whiteboard. It is neither clear to me why this is a *must* nor why an untrusted pager causes a problem. A Q regarding your hash/cache suggestion: how do you ensure that you can't use the cache as a covert channel without major performance losses? - Volkmar [View Less]

2 1

L4 and EROS
by David Denny 05 Jan '04

05 Jan '04

I have been wondering why "Eros" has invaded this list. This user's pov: L4 is a solid product which works well. I want to experiment with OS building and L4 has a robust base structure, as well as a friendly community and all the tools I need to stick my own silly things on top of it. I support L4. [ I'd support Eros if it had been built to the same level, never mind whatever "angels on pinhead" theoretical issues might occasionally surface. However, from my assessment of the website … [View More]

3 4

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 05 Jan '04

05 Jan '04

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Monday, January 05, 2004 4:56 PM > To: Volkmar Uhlig > Cc: rudykoot(a)mithrill.org; L4 Hackers List > Subject: L4, High Assurance, and Protection > > Issue 1: Need for Protected IPC > > On Thu, 2004-01-01 at 18:09, Volkmar Uhlig wrote: > > If it does not matter where the check code is executed > > (client/kernel/server) but only who gets accounted for the used … [View More]> > resources (CPU, cache, whatever) this is not the case. (I'm not > > claiming L4 can do that (yet).) > > In answer to Volkmar's question: it matters very > fundamentally where the > check is performed. It is the difference between mandatory and > discretionary controls. > > The current L4 IPC is discretionary: the sender can invoke anyone, and > the recipient checks the sender identity and decides whether to accept > the IPC. > > In such systems, it is a fundamental requirement that the reference > monitor be able to PREVENT (absolutely) communication between > processes that are under its control. If a sender S is not > permitted to send to a recipient R, the behavior must be exactly > as if the send was performed to a non-existent ID. Ok, I see that point. > The main change that is needed in L4 to resolve this is to define the > recipient-id and sender-id fields as opaque fields. Under > high-assurance requirements, the sender is not entitled to know how > many threads execute within the recipient. The sender-id and > recipient-id therefore must not encode "thread within process". > Similarly, it must not encode "process ID". I think there is some misconception around about L4's thread ids. In L4 V4 (X.2 is going to become V4 after maturing) threads and address spaces are completely independent of each other. Threads execute in an address spaces, but they can migrate. A thread ID is a communication-endpoint place holder. If you have, say, 100 threads in an address space and you want to hide that fact you can use a single thread serving as a distributer. Since we have local IPC the distribution can completely take place in user land without a kernel invocation. The worker can impersonate the distributer for the reply. > While I do not advocate any particular implementation strategy, let me > give an *example* of one that might suffice: a simple hash table. > Instead of using the PCB address as the process ID, the > kernel could use > H(sender kernel ID, requested-recipient-ID) as an index into a hash > table and perform a single indirection (and possible hash bucket > chasing) to find the process address. This is fundamentally the design > proposed by Trent several years ago. You immediately run into replacement policy issues. > 2: Restricted Mapping > > This is a very small issue, and there may be some way around it. > > In general, I like the map/grant model very much, but in some > systems it is necessary for the manager to know who has what mappings. > In these systems, having applications perform mappings directly to each > other creates a consistency problem. Here the argument is around IPC redirection (which is arguably expensive). By sticking an interceptor in between you know which mappings go in and out. That way you can control it. But I suspect that fine-grain control over mapping privileges makes sense. The question is what this granularity should be--page or mapping in general. > My preference would be to have *both* controls, because they serve > slightly different purposes. The first lets me virtualize the > map/grant operations (in order to keep manager metadata updated), > while the second prevents map recursion. > > The problem with the first method is that it requires protected > recipient descriptors. You can transparently drop the mapping if it is not allowed. Since the guarantees whether a page is mapped or not come from the pager hierarchy it is only as strong as all combined pagers. By adding a non-guaranteeing pager in the hierarchiy you are set. > The problem with implementing only the second method is: what > thread id should a page fault handler receive from a faulting thread? > Restricted or non-restricted? I can argue for either depending on what > kind of system I am trying to build. That raises the question whether the pager is privileged or not. Since the pager can be set by the thread the pager can be changed and the thread could elevate its privileges. Or did I misunderstand you? - Volkmar [View Less]

2 1

RE: IPC/Capabilities Overview
by Rudy Koot 05 Jan '04

05 Jan '04

>That is wrong. The direct lookup drastically reduces cache and TLB >footprint. For a full IPC we have to access two TCBs (which are >virtually mapped and have the stack in the same page) which costs two >TLB entries. The complete lookup is therefore a simple mask (plus maybe >a shift), a relative mov (e.g. mov 0xe0000000(%eax), %ebx) and a >compare. Overall costs therefore (on IA32): >- 2 TLB entries (but we need them anyway for the stack, they could be >reduced to … [View More]

2 1

RE: IPC/Capabilities Overview
by Volkmar Uhlig 05 Jan '04

05 Jan '04

Similar to Rudy I try to answer multiple mails at once. (Sorry for the long post!!!) First a general statement. It appears to me that goals are very different. As Rudy pointed out one of the main goals of L4 (at least pursued in Karlsruhe) is to have a universal and high performance uK. Universal here means that it is applicable to any domain. That also answers Rudy's question who is going to use a microkernel without a security model--anybody who does not require a security model. And … [View More]that may be your wrist watch, cell phone, or a medical appliance. Jonathan wrote: > Please consider that "clever" is a four letter word (a curse). All of > these optimizations are, in my opinion, justifiable reasons to fire a > programmer with a strongly negative recommendation. The resulting > systems are unmaintainable. > > Speed is not the primary goal. Efficient robustness (measured end to > end) is the primary goal. That maybe true for your research agenda. However, to investigate the limits of uK based systems I would be very disappointed if you wouldn't even consider these optimization. Then we are back to the good old MACH problem: uKs are inherently slow by nature, full stop. And, we are talking research here, not business (btw, I would fire those guys too). We may also simply not have the right tools to do that robust and efficiently today, but then we should look into better tools. > Excuse me, but this is utter nonsense. You are making a quantitative > argument using qualitative and unsubstantiated arguments. You (and I) > need numbers in order to evaluate this issue. > > The correct way to approach this is to ask: > > 1. What percentage of invocations dynamically incur the cost of > checking? > 2. What is the respective cost of this checking at user and at > supervisor level? > 3. Given that the supervisor-mode implementation *is* incurred by > all cases, what is the weighted cost of the mechanism in both > cases (user and supervisor). > > Once you have this calculation, you have a correct > engineering basis for making a decision. Good that we are on common ground now. We also have to agree on what system you and I have in mind and from that we can derive the overall costs. To me it seems you are implying a system design and claim that L4's lack of certain features makes it perform as good/bad or worse. However, by not having the feature in the kernel but in user land allows to modify it. Now the question changes to how efficiently can we implement it in user land compared to the in-kernel version. In the case it is part of the kernel you can't change it anymore which means you will always pay the cost whether you want or not. And here you also have to evaluate _all_ potential systems, even those without security requirements. > And I should acknowledge that I disagree with Volkmar very > fundamentally about the "performance uber alles" assumption. > Performance is important, but from a research perspective it > is *more* important to understand what the fundamental architectural > issues are. Once we do, we can step back and decide what to take > out. At the moment, we have no common base on which direct comparison > is possible. I think Jonathan misunderstood me on that. I think we have a set of core requirements for a kernel which are probably almost identical for EROS and L4. However, we have a different focus. And performance is still one of the main reasons why monolithic kernels are preferred over uKs. That does not mean that security is less important. > I don't think that the L4 kernel has all the answers, but I also think > that the EROS kernel does not have all the answers. Each, I think, has > important strengths. EROS lacks a certain elegance of minimality. L4 > (as I understand it today) lacks a credible story about security, access > control and denial of service. Perhaps it is time for both groups to > step back and make a serious attempt to learn from each other. I agree that one of the current weaknesses of L4 is its very rudimentary security model. And each L4 group seems to have its own perspective on how this should be solved. > From the conversations on this list, however, it appears to > me that the L4 research groups do not agree universally on what the > IPC control mechanism is, and this may be contributing to some > difficulty in the discussion. One group clearly advocates thread spaces. > Volkmar (if I understand him) currently advocates IPC indirection. The > two designs have very different implications for performance, implementation, > and security. No, I'm not advocating this. So far nobody has a reasonable cost-benefit analysis of the thread mappings and as long as that is the case I'm not in favor of anything. However, considering complexity and elegance of the different alternatives and the performance impact on a wide variety of hardware architectures (specifically MP and NUMA systems), I'm very skeptical about proposals which bind security principals on address spaces. That will just open another can of worms. The redirection model has the disadvantage of fundamentally changing the semantics of IPC. With a purely synchronous IPC model timing is a fundamental part of the communication protocol. Transparent interception is not possible since the message gets successfully delivered to the redirector, which, however, may discard it. This alters guarantees usually given by the kernel. > Volkmar's technique is quite elegant. The only problem I see > is that it places the burden of verification on the wrong party > -- it should be on the client. That is, the design invites DoS > attacks. If it does not matter where the check code is executed (client/kernel/server) but only who gets accounted for the used resources (CPU, cache, whatever) this is not the case. (I'm not claiming L4 can do that (yet).) > However, Volkmar is making an assumption that is problematic. He is > assuming that the passed ID is a pointer. From a security perspective > this is VERY bad. First, it invites memory attacks. Second, > it discloses information about the internal implementation of the server. > Third, it makes selective rescind of authority very hard to do. No, it can be an object handle which can be translated in some/any way (e.g. cryptographically modified, or a hash). The fundamental difference is that it is not a first class kernel object. This means you have the freedom to choose the appropriate encoding (which could be a pointer of course). > As a backwards compatibility matter, and as a validation of the L4 > nucleus, running Linux on an L4 is interesting. As a matter of future > research, and as a matter of forward-looking system > architecture, it is boring. Yes, I agree. However, a gradually decomposed Linux can answer many research questions without re-implementing a fully fledged OS. > The right forward-looking research question is: > > *Given* a fast nucleus in the style of L4, what is the most > effective way to structure a native operating environment? > What fundamental and novel leverage do such kernels provide? That was one of the goals of SawMill. ==== Rudy wrote: > Sorry, but I do not see how the version part could be used as > the server defined word. You can't have multiple versions > (read server defined words) of the same thread-id at the > same time. Correct. I had a different usage scenario in mind--sorry for confusions. > I believe these costs are exagerated. To convert a capability into > sender-id a simple table lookup can be used. This requires a single > TLB entry and a single L2 cache line (worst case). If IPC is frequent, > which is the case in which you want high performance, the TLB entry > is very likely to be present and probably even the L2 cache line. This assumes that you have a small TLB working set and small cache working set. However, if communication is frequent that also means that you are probably communicating to _many_ partners. And then you probably need a TLB entry per table which again increases the TLB footprint. That means the likelihood that you replace user-TLB entries goes up--the problem is the user's active working set you replace. ==== Jonathan wrote: > Volkmar is combining two things in one, and seems to be > forgetting that he does so. You are correct. Once you have the > capability, obtaining the target thread id is quite fast. No table > lookup is required. The capability is kernel-protected state, and can > simply contain a direct pointer to the recipient PCB. > > I think that the costs that Volkmar is identifying come from > the need to lookup the thread-id or capability in the thread mapping > space. That is, these are the costs of the address space traversal. > The costs are the same in either case (thread-id or capability). If you add a level of indirection (thread id or cap) that is the case. However, if you pay for a level of indirection anyhow, then it does not matter whether the name specifies a capability or a thread. I have the (maybe unreasonable) feeling that it should be possible to express both in one model with the same costs associated. > One of the features of EROS is an indirection object. This object can > stand in front of a start capability transparently. The client invokes > the indirection object capability rather than the start capability. > Given this construction, a service can selectively rescind that client > capability by destroying the indirection object. > > This is something that L4 presently has no means to do. Of course, L4 > does not need it, because it makes no assumption about controlling > client invocations at all. In the current L4 model this would be a proxy thread assuming that IPC is cheap and it happens infrequently. In the case of frequent redirection you would extend the IPC protocol to take the reconfiguration into account. This boils down to how much transparency do we want. Jonathan mentioned on the EROS list that transparent persistency is something which is not feasible. The same question can be asked in this case: is transparent redirection something we want/need? And are we willing to pay the overhead? One could construct a system, where communication can only be restricted (for enforcement) and apps must be able to dynamically re-configure. ==== Jonathan > In practice, I would use a cache for an L1 software probe > first in order to avoid all marginal TLB and cache misses > in the usual case, but this would result in high variance > of IPC times. Which means you add a new policy to the kernel, something we strictly try to avoid with L4. - Volkmar [View Less]

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers January 2004