l4-hackers October 2005

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

23 participants
23 discussions

Re: What happens on timeslice overrun?
by Udo A. Steinberg 23 Nov '05

23 Nov '05

On Sun, 14 Aug 2005 22:16:09 +0200 Rene Wittmann (RW) wrote: RW> I have 2 questions on the RT part in DROPS: RW> RW> 1.) I have 2 RT working threads, each with 3 timeslices: RW> Thread 1: period=10ms RW> ts1=30ms prio1=50 RW> ts2=10ms prio2=30 RW> ts3=20ms prio3=50 RW> RW> Thread 2: period=10ms RW> ts1=20ms prio1=40 RW> ts2=5ms prio2=30 RW> ts3=10ms prio3=40 RW> RW> Assume both threads … [View More]are ready at the same time. RW> So thread 1 starts and does its work until it RW> releases the voluntarily or it's preempted by RW> its preempter-thread. So say it releases RW> voluntarily after 20ms. When you say "it's preempted by its preempter thread", do you mean the situation when a preempter with a higher priority than the current thread receives a preemption IPC from the kernel and thus preempts the current thread? RW> Who will get the left 10ms? I guess nobody. When a thread is preempted (that means it gets involuntarily descheduled), the remaining time quantum is saved and later restored when the thread is scheduled again. If the thread yields its scheduling context (that means it voluntarily gives it away), the time quantum is no longer available to the thread. A yield can happen in two ways depending on the target thread id specified: 1) if the target ID is the NIL_ID, then the thread yields its active scheduling context to noone - the time is effectively gone. This is what next_reservation does. Note that the kernel checks the user-specified ID, to guard against the case where a thread wants to yield its active scheduling context and the time quantum on that scheduling context expires simultaneously. 2) if the target ID is a valid thread ID in the system, then the action depends on whether the specified thread is ready to run: a) if it is, then the current thread donates the current scheduling context to the specified thread and that thread then becomes the current thread. This is similar to what happens during a donating IPC. b) if the specified thread is not ready, then the current scheduling context is gone, similar to 1) RW> Or can I assign my left time to a specific RW> thread, say ts2 of thread 1, that is has 20ms RW> after recognizing that ts1 was finished 10ms RW> earlier?I could do with l4_rt_change_timeslice(), RW> but this would probably not work for the the RW> current period! (or yes?) A thread can yield the current scheduling context to another thread as described in 2a) above. Note that the thread will yield the current scheduling context (which may not necessarily be the thread's own active scheduling context). As an example consider: A sends a donating IPC to B, now B runs on A's scheduling context. If B yields to C, then C will run on A's time and B will not donate its own scheduling context. If the current scheduling context is in fact the active scheduling context of the donating thread, then realize that the donating thread will likely encounter a timeslice overrun soon after the yield (the donatee will consume the time quantum until it runs out). If you'd rather avoid that, then the donatee will have to yield the scheduling context back to the owner (the original donator) who then has to yield it to noone. Changes to the time quantum of a scheduling context are only visible the next time that scheduling context becomes the current scheduling context. That means if you change the current scheduling context, then the change will not be visible immediately. RW> 2.) Consider we have a deadline miss. And we say RW> l4_rt_next_period(): would it wait for the beginning RW> of the next (which means: RW> period 1: deadline miss RW> period 2: call next period (because we think we're RW> still in period 1)+ wait to end of period RW> period 3: normal work) RW> Or do I have to care that we do not call RW> l4_rt_next_period() in case of a deadline miss? If your thread misses its deadline right before it wanted to call l4_rt_next_period, then l4_rt_next_period blocks the thread until the end of the new period started due to the deadline miss. Since this is likely not what the thread intended to do, it's the preempter's job to handle that situation, e.g. by ex_regs'ing the thread out of it's l4_rt_next_period call. RW> BTW: I compiled the fiasco-kernel with apic+one shot RW> mode. But this should not be relevant for my question. It is indeed not relevant. -Udo. [View Less]

3 11

l4linux26 @ fiasco-ux w/ dietlibc
by Marko Wolf 02 Nov '05

02 Nov '05

Hi! I tried running l4linux26 on fiasco-ux compiled from the actual CVS with the dietlibc using the following script: fiasco -t 32768 \ -G800x600@16 \ -m 512 \ -R roottask \ -l names \ -l log \ -l dm_phys \ -l simple_ts -t 380 \ -l fuxfprov -n9 \ -l rtc-ux -n10 \ -l l4exec \ -l l4dope-ux \ -l "loader run l4linux26.cfg" Unfortunatly, l4linux causes a null pointer exceptions (see attached log). I tried various kernel compiler options with always the same error. Any idea for the … [View More]

3 12

fiasco for ARM
by Shakthi Kannan 31 Oct '05

31 Oct '05

Greetings! Couple of questions: 1. Will we be getting an announcement in the mailing list when fiasco moves with uclibc and dietlibc without oskit support? 2. What is the current status of fiasco for ARM (cores 9 and above)? The FAQ mentions only about x86 with i486 and above, but, I found some ARM relevant code in l4sys/include-x2/L4API-l4x2/l4/arm. Is there anyone working with fiasco for ARM? Thanks, SK -- Shakthi Kannan, MS Software Engineer, Specsoft (Hexaware Technologies) [E]: … [View More]

4 4

L4Linux without Con or DoPe?
by Marcel Selhorst 28 Oct '05

28 Oct '05

Hi Hackers, is there a way to use L4Linux without Con or Dope? In detail, I want to boot L4Linux and give a Linux-framebuffer (not the l4fb!) the control of the videocard, so that the console has direct hw-access. Best regards, Marcel Selhorst

2 2

bootstrap + module
by Christoph Mueller 27 Oct '05

27 Oct '05

Hello, I am reusing some code from dde_linux/examples/sound. But I use bootstrap instead of rmgr. Where do I find correct syntax for menu.lst to specify an additional module (sample.pcm) for my server? The syntax from dde_linux/examples/sound/menu.lst uses RMGR. I think, I have to give a parameter to bootstrap that I can access the additional module in my server. syntax from example: >title sounddrv-foo > kernel (nd)/tftpboot/USER/rmgr -sigma0 task modname "sounddrv-foo" module > … [View More]

3 2

Re: Capability Authentication
by Marcus Völp 21 Oct '05

21 Oct '05

Hi, this is a reply to an email I found in the l4-hurd mail archive [http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00020.html]. I'm not on the list, sorry. On Fri, 2005-10-07 at 23:01 -0400, Jonathan S. Shapiro wrote: >/ > > And, do we need the second one / >/ > > to be provided by idl4? I say, usually the server will not trust its / >/ > > client and this it's useless, as the server will not use the new handle./ >/ / >/ You are making an incorrect … [View More]assumption. In general, what you say is/ >/ true, but if the server can authenticate the validity of a capability,/ >/ there is no reason not to use it./ ... The more general solution comes from something we call a "constructor". A "foo constructor" is a server that knows how to create new copies of the "foo" program. Every constructor inserts a unique, unforgeable, and undisclosable capability into the process structure of the process that it creates. This capability is called the "brand". Each constructor uses a different brand from all other constructors. In EROS, there is a kernel capability that performs (approximately) the following operation: interface ProcessTool extends key { bool identify(entry_cap_t someProc, cap_t brand); } Given an entry capability to a process and a second capability, the kernel checks whether the second capability is equal to the existing brand in the process. If so, it returns true, else it returns false. By construction, only constructors hold ProcessTool capabilities. However, if you hold a capability to a foo constructor, and you also hold an entry capability, you can turn to the foo constructor and ask "is this an entry capability to some process that you created?" That is: is it an entry capability to an authentic instance of "foo"? This authentication pattern is enormously important for many of the security arrangements that we are able to achieve in EROS. One of my largest concerns about L4sec is that the L4sec team does not (yet) see that this operation is important. Without an operation like this, it is impossible (or at least, we do not see how) to build robust third-party trust contracts. Jonathan, yes so far L4.Sec does not support such an operation. We thought about (I think Bernard Kauer and Marcus Brinkmann already had a discussion on this topic on l4-hackers) adding a compare operation on endpoints which allows you to match identity of two endpoint capability (compare permissions provided). So far we are not sure whether such an operation is really needed or whether you want to construct systems the way you do. The fundamental issue is that a potentially trusted capability is handed to a server by a not completely trusted source (the client C). We thought briefly about two general solutions to this problem: 1) obtain a version of this capability from a trusted source, or, 2) prepare and defend against potential misbehavior of the invoked server. ad 1: This solution assumes a network of trusted "name"-servers and protocols that require the client C in order to share a capability with some other process S that it establishes this sharing with the target of the capability (D). C can do so by giving its name to S to D and asking D to share the rights S can then request a capability to D from its trusted nameservers and ask for the shared capability provided it trusts D. Please keep in mind that we did not build such a system yet and that it is only a preliminary and potentially not working solution. ad 2: Alternatively the server can prepare to defend against misbehavior of D. In L4.Sec the receiver of an IPC controls the location where an incoming message is placed. Thus it can select an area of its address space so that even if D replies with bogus content, S is not harmed. It remains, however, the problem of blocking S. An easy way to defend against blocking attacks is to fork of a thread for this particular client's request and let it invoke the pot. untrusted capability on behalf of the client. Other thread invoking the same server are not affected by this blocking. Again please keep in mind that both are preliminary solutions. We have still to construct a system on top of L4.Sec. Also please note that L4.Sec is not a fixed API but has experimental status and that we welcome both suggestions for improvement and requirements. However, you will find that features will be added only if they cannot be implemented on top of L4.Sec with a reasonable effort. This is one of the fundamental rules which in my opinion contributed to the success of L4. So please apologize my stubbornness in this point. Compare might be such a feature which will get added if we find no way to achieve what Jonathan listed in his mail. Best regards Marcus Völp -- Marcus Völp TU-Dresden Department of Computer Science Institute for System Architecture Tel: +49 (351) 463-38350 Fax: +49 (351) 463-38284 [View Less]

4 7

Module arguments
by Marcel Selhorst 20 Oct '05

20 Oct '05

Hello L4-Hackers, I have a problem regarding the loading of modules: If I want to load a module and put the regarding entry into the menu.lst including parameters for the module, the module cannot be found in the memory. For example, I have the entry: module (nd)/hddencrypter --with-password-dialog or module (nd)/ramdisk --with-password-dialog (the --with-password-dialog is an argument, which forces GRUB to prompt for a password and afterwards replaces the --with-password-dialog with a … [View More]

2 7

L4.Sec Preliminary Microkernel Reference Manual
by Bernhard Kauer 19 Oct '05

19 Oct '05

The operating system's group at Technische Universit?t Dresden is pleased to announce the first draft of the L4.Sec Preliminary Microkernel Reference Manual. The document can be found at http://os.inf.tu-dresden.de/L4/L4.Sec/ L4.Sec is a specification of a next generation microkernel interface targeted to co-host user-level servers implementing security-critical functionality next to untrusted and potentially malicious software. Bernhard Kauer

1 0

RE: Sawmill's dataspaces and the Hurd's physmem
by yuan Darwin-r62832 19 Oct '05

19 Oct '05

Hi Neal, Thanks for your detailed information. > Physical memory management needn't be an all or nothing deal. Certainly, an application might wish to completely > manage the paging policy and its address space layout, however, I tend to think that this is the exception. And as > we will provide a POSIX personality, we need to have some sort of default VM manager. About general VM manager, what I really mean is just the "default VM manager". However, the question is still there:… [View More]

2 1

RE: Sawmill's dataspaces and the Hurd's physmem
by yuan Darwin-r62832 19 Oct '05

19 Oct '05

Hi Neal, By reading the document of Hurd(VMM), I guess I had a misunderstanding about Hurd's approach. Sorry for bothering. Best Regards, Darwin -----Original Message----- From: Neal H. Walfield [mailto:neal@walfield.org] Sent: Tuesday, October 18, 2005 9:40 PM To: yuan Darwin-r62832 Cc: l4-hackers(a)os.inf.tu-dresden.de; l4-hurd(a)gnu.org Subject: Re: Sawmill's dataspaces and the Hurd's physmem At Tue, 18 Oct 2005 19:42:27 +0800, yuan Darwin-r62832 wrote: > I think these 2 approachs … [View More]are not incompatible. Here are the reasons, > > 1. In Hurd's approach, every application could manage its own > physical memory. However, for most of application developers, they > don't want to take care of the VM replacement policy. To solve this > problem, Hurd has to provide a general VM server to be the pager of > this kind of applications. However, as the philosophy of Hurd, should > this applications trust this server? Physical memory management needn't be an all or nothing deal. Certainly, an application might wish to completely manage the paging policy and its address space layout, however, I tend to think that this is the exception. And as we will provide a POSIX personality, we need to have some sort of default VM manager. The solution that I've opted for is a library based one: a default memory management library will, for instance, implement an LRU based eviction scheme and require no application input. For many applications this will be appropriate and sufficient. Those applications wishing to take complete control will also be able to completely replace the library. I think that some applications can provide useful hints in relatively concise ways. A document viewer, for instance xpdf, might want to cache previously rendered pages. It does not make sense to send these to swap if rereading the data and rerendering is cheaper. In this case, the application can attach a function to drain the cache to a library provided hook which is called when there is memory pressure. I think that this small type of change may offer dramatic results. Moreover, if the change is highly isolated (which in this case seems feasible), it will be easily accepted upstream. An even less invasive hint would be to set some environment variables. Clearly we wouldn't expect most users to set these but an application's packager could based on observed behavior. In the case of e.g. grep or cat we might want to set the read ahead parameter to "very aggressive". If a developper so desires, a more aggressive, but more invasive approach, can also be adopted. Instead of using malloc and free, the application can use a slab allocator. I think this can only be effectively done if the slab allocator participates in the eviction scheme. Again, this is possible in our case with a number of library provided hooks but not for user applications running on a traditional Unix-like core. This can be made backwards compatible by having the configure script check for the required mechanisms and if they are not available then to redefine slab_alloc and slab_free to malloc and free. > 2. In Sawmill's DS approach, every task(AS) has a specific thread > named "region mapper" to be the pager of other threads. It captures > the page fault, then decide to forward it to corresponding server, and > get mapped. So from the higher level point of view, these servers are > the pagers of the task. If Hurd application should trust that general > VM pager, the applications using Sawmill's DS framework should trust > these servers as well. I hope it is now clear that there is no general VM server. > 3. Relative to Sawmill's approach, Hurd provides a clear & great > physical memory server, which makes the whole physical memory of > platform could be fairly used by all of the servers & applications. > > Therefore, we can use Hurd's physmem server as the central > controller. Sawmill's DSMs apply physical memory from it. The > applications who wanna use Sawmill's approach could still walk on > their own way. For some applications who wanna manage their own > physical memory, they can apply memory from physmem server directly. I see a number of problems with SawMill's dataspaces. The root of this thread is the presentation of a potential security flaw in the design of dataspaces. (Whether this is important or not depends on the assumed trust model and security goals.) Another is that as far as I can tell paging decisions are made towards the root of a dataspace hierarchy and not at the applications themselves. Hopefully it is clear why I've choosen to reject this scheme. Thanks, Neal [View Less]

1 0

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 October 2005