l4-hackers January 2012

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

8 participants
8 discussions

Sharing I/O Memory
by Wesley Miaw 01 Feb '12

01 Feb '12

I have an L4 process requesting access to a large chunk (512MB) of physical RAM using l4sigma0_map_iomem(). I am not using l4sigma0_map_mem() because Fiasco is running in a different partition of physical RAM. I would like to then grant full read/write access to the same memory to a second L4 process, but I'm not sure how to do that. I believe from looking at the sigma0 code that any memory, I/O or RAM, can only be allocated to one L4 process at a time. It also doesn't look like clans have anything to do with this, other than the possibility of creating some shared memory for an IPC. But that's not really what I want to do, I want both L4 processes to directly access the memory. Is there some way to accomplish this? Thanks, -- Wesley Miaw wesley(a)wesman.net

2 7

RE: l4-hackers Digest, Vol 105, Issue 9
by jangwoo 29 Jan '12

29 Jan '12

Hi all. I have similar problem. Currently applications on linux can't use mmap of framebuffer(/dev/fb0). When apps access memory to get through mmap, it occurs page fault. Without goos, fbdrv of L4 cell, mag, l4fb drv in linux, etc on, Is there ways that it modify <linux lcd device driver> little bit as other linux device drivers In other words, could Apps use allocated memory in linux kernel? As a guide, Because of using dedicated frame buffer only in one cell(linux), it mustn't use things like goos, mag. thanks ------------------------------ Message: 1 Date: Tue, 24 Jan 2012 20:03:36 +0100 From: Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> To: l4-hackers(a)os.inf.tu-dresden.de Subject: Re: Fiasco.OC x86 IO port permission bitmap Message-ID: <20120124190336.GE2897(a)os.inf.tu-dresden.de> Content-Type: text/plain; charset=iso-8859-1 Hi, On Mon Jan 23, 2012 at 15:54:29 -0800, Daniel Waddington wrote: > I want to use the TSS I/O permission bit map to support fine grained > control of I/O access for user-level apps (x86 32 bit target). From > looking at the kernel code, I believe the bit map is switched out > per-process as part of the Context class (Space::_io_space) - > correct me if I am wrong. My query is how to set/clear the bits for > a given target task from a "root" task with sufficient privileges > (e.g., base caps and sigma0 caps). I could extend the kernel > scheduler protocol, but I don't want to do this if there is already > a clean way in place. IO-ports are handled similar to page-faults, i.e. they can be mapped to other tasks, and the pager receives io-page-faults when one of its clients accesses an IO-port without having it. For example look for L4_PROTO_IO_PAGE_FAULT and l4_iofpage(). Adam -- Adam adam(a)os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ------------------------------ Message: 2 Date: Tue, 24 Jan 2012 13:12:03 -0800 From: Daniel Waddington <d.waddington(a)samsung.com> To: Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> Cc: l4-hackers(a)os.inf.tu-dresden.de Subject: Re: Fiasco.OC x86 IO port permission bitmap Message-ID: <4F1F1EA3.7060309(a)samsung.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Hi Adam, I see. So it seems that you have to map all of the IO port space before getting IOPL raised to 3 (assuming Kconfig IO_PROT & !IO_PROT_3) and therefore the default mode of operation is a driver will map the whole space if it wants to use IO instructions directly. Is it right that you currently don't use the TSS IO bitmap to allow access to only specific IO ports with CPL > IOPL? Thanks Daniel On 01/24/2012 11:03 AM, Adam Lackorzynski wrote: > Hi, > > On Mon Jan 23, 2012 at 15:54:29 -0800, Daniel Waddington wrote: >> I want to use the TSS I/O permission bit map to support fine grained >> control of I/O access for user-level apps (x86 32 bit target). From >> looking at the kernel code, I believe the bit map is switched out >> per-process as part of the Context class (Space::_io_space) - >> correct me if I am wrong. My query is how to set/clear the bits for >> a given target task from a "root" task with sufficient privileges >> (e.g., base caps and sigma0 caps). I could extend the kernel >> scheduler protocol, but I don't want to do this if there is already >> a clean way in place. > IO-ports are handled similar to page-faults, i.e. they can be mapped to > other tasks, and the pager receives io-page-faults when one of its > clients accesses an IO-port without having it. For example look for > L4_PROTO_IO_PAGE_FAULT and l4_iofpage(). > > > Adam

3 2

Fiasco.OC x86 IO port permission bitmap
by Daniel Waddington 27 Jan '12

27 Jan '12

Hi, I want to use the TSS I/O permission bit map to support fine grained control of I/O access for user-level apps (x86 32 bit target). From looking at the kernel code, I believe the bit map is switched out per-process as part of the Context class (Space::_io_space) - correct me if I am wrong. My query is how to set/clear the bits for a given target task from a "root" task with sufficient privileges (e.g., base caps and sigma0 caps). I could extend the kernel scheduler protocol, but I don't want to do this if there is already a clean way in place. Thanks Daniel Waddington

2 4

Re: l4-hackers Digest, Vol 105, Issue 5
by Chen Tian 18 Jan '12

18 Jan '12

Hi Adam, I got another trace: Chen: caps_alloc for virt addr 0xf081f010 (index 0x1f01), new cap location 0xfec93000, [virt 0xf081f000-> mem 0xfec93000] in space 0xfedd7f08, s = 0x0 Chen: caps_alloc for virt addr 0xf081f000 (index 0x1f00), new cap location 0xfec92000, [virt 0xf081f000-> mem 0xfec92000] in space 0xfedd7f08, s = 0x0 thread 0xfed4c000: v_fabricate is false: (Obj_space) from [0xfedd7ef4/12], s_phys 0x0: 00001f01 size: 00000001 to [0xfedd7e9c/18] recv addr 0x1e8f KERNEL: Warning: nothing mapped: (Obj_space) from [0xfedd7ef4/12]: 00001f02 size: 00000001 to [0xfedd7e9c/18] recv addr 0x1e90 Chen: v_delete on cap 0xfecf33b4 for virt addr 0x1ef8 (entry addr 0xfec90f80) in space 0xfedd7f08 As you can see, the status variable "s" is Insert_OK for two invocations of caps_alloc. That means mem_space()->v_insert function is not safe either? Why two insertions are successful at the same time on the same virtual address? I have put a lock to protect l4_factory_create_xxx in my application and that seems to work. Best, Chen On Tue, Jan 17, 2012 at 3:00 AM, <l4-hackers-request(a)os.inf.tu-dresden.de>wrote: > Send l4-hackers mailing list submissions to > l4-hackers(a)os.inf.tu-dresden.de > > To subscribe or unsubscribe via the World Wide Web, visit > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > or, via email, send a message with subject or body 'help' to > l4-hackers-request(a)os.inf.tu-dresden.de > > You can reach the person managing the list at > l4-hackers-owner(a)os.inf.tu-dresden.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of l4-hackers digest..." > > > Today's Topics: > > 1. Re: race condition in obj_space-virt.cpp ? (Adam Lackorzynski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Jan 2012 23:54:07 +0100 > From: Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> > To: l4-hackers(a)os.inf.tu-dresden.de > Subject: Re: race condition in obj_space-virt.cpp ? > Message-ID: <20120116225406.GA6550(a)os.inf.tu-dresden.de> > Content-Type: text/plain; charset=iso-8859-1 > > > On Fri Jan 13, 2012 at 16:37:06 -0800, Chen Tian wrote: > > Hello, > > > > I observed a race condition in Fiasco.OC. My environment is very > > complicated, but basically I have multiple threads, and each thread keep > > creating kernel object via l4_factory_create_xxxx and map the object to a > > new task. > > > > Here is the trace I got: > > Thanks, we're looking into this. > > > > Adam > -- > Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ > > > > ------------------------------ > > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > > > End of l4-hackers Digest, Vol 105, Issue 5 > ****************************************** >

2 1

race condition in obj_space-virt.cpp ?
by Chen Tian 16 Jan '12

16 Jan '12

Hello, I observed a race condition in Fiasco.OC. My environment is very complicated, but basically I have multiple threads, and each thread keep creating kernel object via l4_factory_create_xxxx and map the object to a new task. Here is the trace I got: //printed from obj_space-virt.cpp in function caps_alloc: Chen: caps_alloc for virt addr 0xf0826000 (index 0x2600), new cap location 0xfeb04000, [virt 0xf0826000-> mem 0xfeb04000] in space 0xfedd7f08 Chen: caps_alloc for virt addr 0xf0826010 (index 0x2601), new cap location 0xfeb05000, [virt 0xf0826000-> mem 0xfeb05000] in space 0xfedd7f08 Chen: v_insert cap 0xfed5a6a0 (index 0x2600 (entry addr 0xfeb04000) in space 0xfedd7f08 Chen: v_insert cap 0xfeb000b4 (index 0x2601) (entry addr 0xfeb05010) in space 0xfedd7f08 //printed from map_util thread 0xfed4c000: v_fabricate is false: (Obj_space) from [0xfedd7ef4/12], s_phys 0x0: 00002601 size: 00000001 to [0xfedd7e9c/18] recv addr 0x2541 // then I got KERNEL: Warning: nothing mapped: (Obj_space) from [0xfedd7ef4/12]: 00002602 size: 00000001 to [0xfedd7e9c/18] recv addr 0x2542 Omnicore Panic: task map failed! Basically, different object index (2600 and 2601) causes two different page to be created and mapped to the same cap_table virtual address 0xf0826000. Although one of the mapping will fail, but the current logic did not return the correct address. The fix I put in to solve this problem is to add the following lines after the switch statement in caps_alloc function: if (s != Insert_ok ) { Mapped_allocator::allocator()->q_unaligned_free(ram_quota(), Config::PAGE_SIZE, mem); mem= alien_lookup(virt & ~(Config::PAGE_SIZE/sizeof(Entry)-1)); } Please let me know if this is correct. Thanks. Even with this fix, I still got another kernel "nothing mapped error" when I ask each thread not only to create and map kernel objects, but also to delete objects using l4_task_unmap. If I do not use l4_task_unmap, everything is fine. I am still investigating why, but I got a feeling that there may be other race conditions on the cap_table related operations. Best, Chen

2 1

L4Re build system
by Ivan Loskutov 09 Jan '12

09 Jan '12

Hello, Hackers! I have some questions about L4Re build system 1. How to build library from *.cpp files? The library building if I rename *.cpp files to *.cc but it not easy. I tried to modify mk-files, see attached patch. *.cpp files compiled but don't linked correctly, *.cpp files added to linker command. 2. How to correct add prebuild and postbuild rules to Makefile for prog and library roles? Thanks. -- Best Regards, Ivan Loskutov

2 1

Initial environnement issue
by Julien SIMONE 02 Jan '12

02 Jan '12

Hi hackers, Everytime I try to get a new free utcb in using L4re_env()->first_free_utcb, this call returns 0xffffffff. I think there is something wrong with the utcb_area... Do you think I forgot to initialize anything? Any idea? Best regards, Julien.

2 1

openssl port
by Ivan Loskutov 02 Jan '12

02 Jan '12

Hello, Hackers! I ported OpenSSL 1.0.0e for L4Re http://dl.dropbox.com/u/8558928/openssl.tar.bz2 I tested it on x86 and ARM.

2 1

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 2012