diff --git a/base-codezero/doc/codezero.txt b/base-codezero/doc/codezero.txt index 30bd482a67..dabcbf06d6 100644 --- a/base-codezero/doc/codezero.txt +++ b/base-codezero/doc/codezero.txt @@ -12,7 +12,7 @@ It is developed by the British company B-Labs. :B-Labs website: - [http://b-labs.co.uk] + [http://b-labs.com] The Codezero kernel was first made publicly available in summer 2009. The latest version, documentation, and community resources are available at the diff --git a/base-foc/patches/foc_exregs_ret_state.patch b/base-foc/patches/foc_exregs_ret_state.patch new file mode 100644 index 0000000000..6902d34a2b --- /dev/null +++ b/base-foc/patches/foc_exregs_ret_state.patch @@ -0,0 +1,26 @@ +Index: kernel/fiasco/src/kern/ia32/thread-ia32.cpp +=================================================================== +--- kernel/fiasco/src/kern/ia32/thread-ia32.cpp (revision 38) ++++ kernel/fiasco/src/kern/ia32/thread-ia32.cpp (working copy) +@@ -90,7 +90,7 @@ + IMPLEMENT inline + Mword + Thread::user_flags() const +-{ return regs()->flags(); } ++{ return state() & Thread_ready; } + + + +Index: kernel/fiasco/src/kern/arm/thread-arm.cpp +=================================================================== +--- kernel/fiasco/src/kern/arm/thread-arm.cpp (revision 38) ++++ kernel/fiasco/src/kern/arm/thread-arm.cpp (working copy) +@@ -361,7 +361,7 @@ + IMPLEMENT inline + Mword + Thread::user_flags() const +-{ return 0; } ++{ return state() & Thread_ready; } + + IMPLEMENT inline NEEDS[Thread::exception_triggered] + void diff --git a/base-foc/patches/foc_single_step_x86.patch b/base-foc/patches/foc_single_step_x86.patch index 5bc8f16f9e..f7174b699a 100644 --- a/base-foc/patches/foc_single_step_x86.patch +++ b/base-foc/patches/foc_single_step_x86.patch @@ -204,15 +204,6 @@ Index: kernel/fiasco/src/kern/arm/thread-arm.cpp =================================================================== --- kernel/fiasco/src/kern/arm/thread-arm.cpp (revision 38) +++ kernel/fiasco/src/kern/arm/thread-arm.cpp (working copy) -@@ -361,7 +361,7 @@ - IMPLEMENT inline - Mword - Thread::user_flags() const --{ return 0; } -+{ return state() & Thread_ready; } - - IMPLEMENT inline NEEDS[Thread::exception_triggered] - void @@ -549,6 +549,10 @@ return (v[insn >> 28] >> (psr >> 28)) & 1; } diff --git a/base-foc/src/core/arm/platform_thread.cc b/base-foc/src/core/arm/platform_thread.cc deleted file mode 100644 index 5959c5b940..0000000000 --- a/base-foc/src/core/arm/platform_thread.cc +++ /dev/null @@ -1,25 +0,0 @@ -/* - * \brief Fiasco.OC thread facility (arm specifics) - * \author Stefan Kalkowski - * \date 2011-09-08 - */ - -/* - * Copyright (C) 2011 Genode Labs GmbH - * - * This file is part of the Genode OS framework, which is distributed - * under the terms of the GNU General Public License version 2. - */ - -/* Genode includes */ -#include -#include - -/* core includes */ -#include - - -bool Genode::Platform_thread::_in_syscall(Fiasco::l4_umword_t flags) -{ - return flags == 0; -} diff --git a/base-foc/src/core/arm/target.mk b/base-foc/src/core/arm/target.mk index 89dee1de3f..02f3eef9e3 100644 --- a/base-foc/src/core/arm/target.mk +++ b/base-foc/src/core/arm/target.mk @@ -1,7 +1,7 @@ include $(PRG_DIR)/../target.inc REQUIRES += arm -SRC_CC += arm/platform_arm.cc arm/platform_thread.cc +SRC_CC += arm/platform_arm.cc vpath io_port_session_component.cc $(GEN_CORE_DIR)/arm diff --git a/base-foc/src/core/platform_thread.cc b/base-foc/src/core/platform_thread.cc index 2288447b62..3ad8bfd615 100644 --- a/base-foc/src/core/platform_thread.cc +++ b/base-foc/src/core/platform_thread.cc @@ -98,7 +98,7 @@ void Platform_thread::pause() */ l4_thread_ex_regs_ret(_thread_cap.dst(), &_pager->state.ip, &_pager->state.sp, &flags); - bool in_syscall = _in_syscall(flags); + bool in_syscall = flags == 0; _pager->state.lock.unlock(); /** diff --git a/base-foc/src/core/x86/platform_thread.cc b/base-foc/src/core/x86/platform_thread.cc deleted file mode 100644 index da360874af..0000000000 --- a/base-foc/src/core/x86/platform_thread.cc +++ /dev/null @@ -1,27 +0,0 @@ -/* - * \brief Fiasco.OC thread facility (x86 specifics) - * \author Stefan Kalkowski - * \date 2011-09-08 - */ - -/* - * Copyright (C) 2011 Genode Labs GmbH - * - * This file is part of the Genode OS framework, which is distributed - * under the terms of the GNU General Public License version 2. - */ - -/* Genode includes */ -#include -#include - -/* core includes */ -#include - - -bool Genode::Platform_thread::_in_syscall(Fiasco::l4_umword_t flags) -{ - using namespace Genode; - - return flags & X86::IOPL; -} diff --git a/base-foc/src/core/x86/target.mk b/base-foc/src/core/x86/target.mk index 4a5ca470bf..6bb51354f6 100644 --- a/base-foc/src/core/x86/target.mk +++ b/base-foc/src/core/x86/target.mk @@ -1,8 +1,7 @@ include $(PRG_DIR)/../target.inc REQUIRES += x86 -SRC_CC += x86/platform_x86.cc \ - x86/platform_thread.cc +SRC_CC += x86/platform_x86.cc vpath io_port_session_component.cc $(GEN_CORE_DIR)/x86 diff --git a/base-linux/lib/import/import-lx_hybrid.mk b/base-linux/lib/import/import-lx_hybrid.mk index 0ee42b8108..d1608eda77 100644 --- a/base-linux/lib/import/import-lx_hybrid.mk +++ b/base-linux/lib/import/import-lx_hybrid.mk @@ -13,10 +13,14 @@ HOST_LIB_SEARCH_DIRS := $(shell cc -print-search-dirs | grep libraries |\ # # Add search path for 'limits.h' # -INC_DIR += $(shell echo "int main() {return 0;}" |\ - LANG=C $(CXX) -x c++ -v -E - 2>&1 |\ - sed '/^\#include <\.\.\.> search starts here:/,/^End of search list/!d' |\ - grep "include-fixed") +# We cannot simply extend 'INC_DIR' because this would give precedence to the +# host include search paths over Genode search path. The variable HOST_INC_DIR +# is appended to the include directory list. +# +HOST_INC_DIR += $(shell echo "int main() {return 0;}" |\ + LANG=C $(CXX) -x c++ -v -E - 2>&1 |\ + sed '/^\#include <\.\.\.> search starts here:/,/^End of search list/!d' |\ + grep "include-fixed") # # Add search paths for normal libraries diff --git a/base-linux/lib/import/import-syscall.mk b/base-linux/lib/import/import-syscall.mk index 6e66dc920f..4a5584ebfc 100644 --- a/base-linux/lib/import/import-syscall.mk +++ b/base-linux/lib/import/import-syscall.mk @@ -1,6 +1,6 @@ -INC_DIR += $(dir $(call select_from_repositories,src/platform/linux_syscalls.h)) -INC_DIR += /usr/include +HOST_INC_DIR += $(dir $(call select_from_repositories,src/platform/linux_syscalls.h)) +HOST_INC_DIR += /usr/include # needed for Ubuntu 11.04 -INC_DIR += /usr/include/i386-linux-gnu -INC_DIR += /usr/include/x86_64-linux-gnu +HOST_INC_DIR += /usr/include/i386-linux-gnu +HOST_INC_DIR += /usr/include/x86_64-linux-gnu diff --git a/base-linux/mk/spec-linux.mk b/base-linux/mk/spec-linux.mk index a09531af71..8c04c855b7 100644 --- a/base-linux/mk/spec-linux.mk +++ b/base-linux/mk/spec-linux.mk @@ -13,6 +13,5 @@ LD_TEXT_ADDR ?= 0x01000000 LD_SCRIPT_STATIC = $(call select_from_repositories,src/platform/genode.ld) \ $(call select_from_repositories,src/platform/context_area.nostdlib.ld) else -LD_SCRIPT_STATIC = $(LD_SCRIPT_DEFAULT) \ - $(call select_from_repositories,src/platform/context_area.stdlib.ld) +LD_SCRIPT_STATIC = endif diff --git a/base-linux/run/lx_hybrid_errno.run b/base-linux/run/lx_hybrid_errno.run new file mode 100644 index 0000000000..aec1386ebc --- /dev/null +++ b/base-linux/run/lx_hybrid_errno.run @@ -0,0 +1,48 @@ +# +# \brief Test thread-local errno works for hybrid Linux/Genode programs +# \author Norman Feske +# \date 2011-12-05 +# + +# +# Build +# + +build { core init test/lx_hybrid_errno } + +create_boot_directory + +# +# Generate config +# + +install_config { + + + + + + + + + + + + +} + +# +# Boot modules +# + +# generic modules +set boot_modules { core init test-lx_hybrid_errno } + +build_boot_image $boot_modules + +# +# Execute test case +# + +run_genode_until "--- finished thread-local errno test ---.*\n" 10 + diff --git a/base-linux/run/lx_hybrid_pthread_ipc.run b/base-linux/run/lx_hybrid_pthread_ipc.run new file mode 100644 index 0000000000..2554e97983 --- /dev/null +++ b/base-linux/run/lx_hybrid_pthread_ipc.run @@ -0,0 +1,48 @@ +# +# \brief Test IPC from pthread created outside of Genode +# \author Norman Feske +# \date 2011-12-20 +# + +# +# Build +# + +build { core init test/lx_hybrid_pthread_ipc } + +create_boot_directory + +# +# Generate config +# + +install_config { + + + + + + + + + + + + +} + +# +# Boot modules +# + +# generic modules +set boot_modules { core init test-lx_hybrid_pthread_ipc } + +build_boot_image $boot_modules + +# +# Execute test case +# + +run_genode_until "--- finished pthread IPC test ---.*\n" 10 + diff --git a/base-linux/src/base/env/rm_session_mmap.cc b/base-linux/src/base/env/rm_session_mmap.cc index 4e1c2439da..b5e122eb25 100644 --- a/base-linux/src/base/env/rm_session_mmap.cc +++ b/base-linux/src/base/env/rm_session_mmap.cc @@ -19,7 +19,7 @@ using namespace Genode; -static size_t dataspace_size(Dataspace_capability ds) +static Genode::size_t dataspace_size(Dataspace_capability ds) { if (ds.valid()) return Dataspace_client(ds).size(); @@ -42,8 +42,8 @@ static bool is_sub_rm_session(Dataspace_capability ds) } -static void *map_local(Dataspace_capability ds, size_t size, addr_t offset, - bool use_local_addr, addr_t local_addr) +static void *map_local(Dataspace_capability ds, Genode::size_t size, + addr_t offset, bool use_local_addr, addr_t local_addr) { Linux_dataspace::Filename fname = Linux_dataspace_client(ds).fname(); fname.buf[sizeof(fname.buf) - 1] = 0; diff --git a/base-linux/src/core/target.mk b/base-linux/src/core/target.mk index c2b11d79a1..6b4a0906da 100644 --- a/base-linux/src/core/target.mk +++ b/base-linux/src/core/target.mk @@ -1,30 +1,31 @@ -TARGET = core -REQUIRES = linux -LIBS = cxx ipc heap core_printf process lock raw_server syscall rpath +TARGET = core +REQUIRES = linux +LIBS = cxx ipc heap core_printf process lock raw_server syscall rpath -GEN_CORE_DIR = $(BASE_DIR)/src/core +GEN_CORE_DIR = $(BASE_DIR)/src/core -SRC_CC = main.cc \ - platform.cc \ - platform_thread.cc \ - ram_session_component.cc \ - ram_session_support.cc \ - rom_session_component.cc \ - cpu_session_component.cc \ - pd_session_component.cc \ - io_mem_session_component.cc \ - io_port_session_component.cc \ - signal_session_component.cc \ - signal_source_component.cc \ - thread.cc \ - thread_linux.cc \ - context_area.cc \ - debug.cc +SRC_CC = main.cc \ + platform.cc \ + platform_thread.cc \ + ram_session_component.cc \ + ram_session_support.cc \ + rom_session_component.cc \ + cpu_session_component.cc \ + pd_session_component.cc \ + io_mem_session_component.cc \ + io_port_session_component.cc \ + signal_session_component.cc \ + signal_source_component.cc \ + thread.cc \ + thread_linux.cc \ + context_area.cc \ + debug.cc -INC_DIR += $(REP_DIR)/src/core/include \ - $(GEN_CORE_DIR)/include \ - $(REP_DIR)/src/platform \ - /usr/include +INC_DIR += $(REP_DIR)/src/core/include \ + $(GEN_CORE_DIR)/include \ + $(REP_DIR)/src/platform + +HOST_INC_DIR += /usr/include vpath main.cc $(GEN_CORE_DIR) vpath thread.cc $(BASE_DIR)/src/base/thread diff --git a/base-linux/src/platform/_main_helper.h b/base-linux/src/platform/_main_helper.h index 8aa049a03f..3808233a2d 100644 --- a/base-linux/src/platform/_main_helper.h +++ b/base-linux/src/platform/_main_helper.h @@ -25,7 +25,7 @@ __attribute__((weak)) char **lx_environ = (char **)0; -static void main_thread_bootstrap() +static inline void main_thread_bootstrap() { using namespace Genode; diff --git a/base-linux/src/platform/lx_hybrid.cc b/base-linux/src/platform/lx_hybrid.cc index be843b3a68..a4c2463e95 100644 --- a/base-linux/src/platform/lx_hybrid.cc +++ b/base-linux/src/platform/lx_hybrid.cc @@ -45,7 +45,6 @@ extern char **lx_environ; */ __attribute__((constructor(101))) void lx_hybrid_init() { - main_thread_bootstrap(); lx_environ = environ; } @@ -77,6 +76,7 @@ __attribute__((constructor(101))) void lx_hybrid_init() /* Genode includes */ #include +#include /* libc includes */ #include @@ -149,7 +149,7 @@ namespace Genode { static void empty_signal_handler(int) { } -static void *thread_start(void *arg) +static void adopt_thread(Thread_meta_data *meta_data) { /* * Set signal handler such that canceled system calls get not @@ -158,7 +158,7 @@ static void *thread_start(void *arg) lx_sigaction(LX_SIGUSR1, empty_signal_handler); /* assign 'Thread_meta_data' pointer to TLS entry */ - pthread_setspecific(tls_key(), arg); + pthread_setspecific(tls_key(), meta_data); /* enable immediate cancellation when calling 'pthread_cancel' */ pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, 0); @@ -166,9 +166,17 @@ static void *thread_start(void *arg) /* * Initialize thread meta data */ + Native_thread &native_thread = meta_data->thread_base->tid(); + native_thread.tid = lx_gettid(); + native_thread.pid = lx_getpid(); +} + + +static void *thread_start(void *arg) +{ Thread_meta_data *meta_data = (Thread_meta_data *)arg; - meta_data->thread_base->tid().tid = lx_gettid(); - meta_data->thread_base->tid().pid = lx_getpid(); + + adopt_thread(meta_data); /* unblock 'Thread_base' constructor */ meta_data->construct_lock.unlock(); @@ -181,13 +189,52 @@ static void *thread_start(void *arg) } +extern "C" void *malloc(::size_t size); + + Thread_base *Thread_base::myself() { - void *tls = pthread_getspecific(tls_key()); + void * const tls = pthread_getspecific(tls_key()); - bool const is_main_thread = (tls == 0); + if (tls != 0) + return ((Thread_meta_data *)tls)->thread_base; - return is_main_thread ? 0 : ((Thread_meta_data *)tls)->thread_base; + bool const is_main_thread = (lx_getpid() == lx_gettid()); + if (is_main_thread) + return 0; + + /* + * The function was called from a thread created by other means than + * Genode's thread API. This may happen if a native Linux library creates + * threads via the pthread library. If such a thread calls Genode code, + * which then tries to perform IPC, the program fails because there exists + * no 'Thread_base' object. We recover from this unfortunate situation by + * creating a dummy 'Thread_base' object and associate it with the calling + * thread. + */ + + /* + * Create dummy 'Thread_base' object but suppress the execution of its + * constructor. If we called the constructor, we would create a new Genode + * thread, which is not what we want. For the allocation, we use glibc + * malloc because 'Genode::env()->heap()->alloc()' uses IPC. + * + * XXX Both the 'Thread_base' and 'Threadm_meta_data' objects are never + * freed. + */ + Thread_base *thread = (Thread_base *)malloc(sizeof(Thread_base)); + memset(thread, 0, sizeof(*thread)); + Thread_meta_data *meta_data = new Thread_meta_data(thread); + + /* + * Initialize 'Thread_base::_tid' using the default constructor of + * 'Native_thread'. This marks the client and server sockets as + * uninitialized and prompts the IPC framework to create those as needed. + */ + meta_data->thread_base->tid() = Native_thread(); + adopt_thread(meta_data); + + return thread; } @@ -203,14 +250,14 @@ void Thread_base::start() Thread_base::Thread_base(const char *name, size_t stack_size) : _list_element(this) { - _tid.meta_data = new Thread_meta_data(this); + _tid.meta_data = new (env()->heap()) Thread_meta_data(this); int const ret = pthread_create(&_tid.meta_data->pt, 0, thread_start, _tid.meta_data); if (ret) { PERR("pthread_create failed (returned %d, errno=%d)", ret, errno); - delete _tid.meta_data; + destroy(env()->heap(), _tid.meta_data); throw Context_alloc_failed(); } @@ -241,6 +288,6 @@ Thread_base::~Thread_base() ret, errno); } - delete _tid.meta_data; + destroy(env()->heap(), _tid.meta_data); _tid.meta_data = 0; } diff --git a/base-linux/src/test/lx_hybrid_pthread_ipc/main.cc b/base-linux/src/test/lx_hybrid_pthread_ipc/main.cc new file mode 100644 index 0000000000..e980c2f704 --- /dev/null +++ b/base-linux/src/test/lx_hybrid_pthread_ipc/main.cc @@ -0,0 +1,62 @@ +/* + * \brief Test for performing IPC from a pthread created outside of Genode + * \author Norman Feske + * \date 2011-12-20 + */ + +/* + * Copyright (C) 2011 Genode Labs GmbH + * + * This file is part of the Genode OS framework, which is distributed + * under the terms of the GNU General Public License version 2. + */ + +/* Genode includes */ +#include +#include + +/* libc includes */ +#include + + +static Genode::Lock *main_wait_lock() +{ + static Genode::Lock inst(Genode::Lock::LOCKED); + return &inst; +} + + +static void *pthread_entry(void *) +{ + PINF("first message"); + + /* + * Without the lazy initialization of 'Thread_base' objects for threads + * created w/o Genode's Thread API, the printing of the first message will + * never return because the IPC reply could not be delivered. + * + * With the on-demand creation of 'Thread_base' objects, the second message + * will appear in the LOG output. + */ + + PINF("second message"); + + main_wait_lock()->unlock(); + return 0; +} + + +int main(int, char **) +{ + Genode::printf("--- pthread IPC test ---\n"); + + /* create thread w/o Genode's thread API */ + pthread_t pth; + pthread_create(&pth, 0, pthread_entry, 0); + + /* wait until 'pthread_entry' finished */ + main_wait_lock()->lock(); + + Genode::printf("--- finished pthread IPC test ---\n"); + return 0; +} diff --git a/base-linux/src/test/lx_hybrid_pthread_ipc/target.mk b/base-linux/src/test/lx_hybrid_pthread_ipc/target.mk new file mode 100644 index 0000000000..6f404deb13 --- /dev/null +++ b/base-linux/src/test/lx_hybrid_pthread_ipc/target.mk @@ -0,0 +1,3 @@ +TARGET = test-lx_hybrid_pthread_ipc +SRC_CC = main.c +LIBS = env cxx thread lx_hybrid diff --git a/base/mk/dep_prg.mk b/base/mk/dep_prg.mk index a6184ef9c8..f7fc0664a5 100644 --- a/base/mk/dep_prg.mk +++ b/base/mk/dep_prg.mk @@ -14,6 +14,14 @@ select_from_repositories = $(firstword $(foreach REP,$(REPOSITORIES),$(wildcard PRG_DIR := $(dir $(TARGET_MK)) include $(TARGET_MK) +# +# Enforce use of 'lx_hybrid' library for all targets when 'always_hybrid' is +# enabled +# +ifeq ($(filter-out $(SPECS),always_hybrid),) +LIBS += lx_hybrid +endif + # # Include lib-import description files # diff --git a/base/mk/generic.mk b/base/mk/generic.mk index 93a7f0b5c1..b97de66e4b 100644 --- a/base/mk/generic.mk +++ b/base/mk/generic.mk @@ -52,7 +52,7 @@ endif %.o: %.s $(MSG_ASSEM)$@ - $(VERBOSE)$(AS) $(AS_OPT) $(INCLUDES) $< -o $@ + $(VERBOSE)$(CC) $(CC_DEF) $(CC_C_OPT) $(INCLUDES) -c $< -o $@ # # Compiling Ada source codes diff --git a/base/mk/global.mk b/base/mk/global.mk index b6b0d5e952..8c90be6649 100644 --- a/base/mk/global.mk +++ b/base/mk/global.mk @@ -155,6 +155,7 @@ ALL_INC_DIR += $(INC_DIR) ALL_INC_DIR += $(foreach DIR,$(REP_INC_DIR), $(foreach REP,$(REPOSITORIES),$(REP)/$(DIR))) ALL_INC_DIR += $(foreach REP,$(REPOSITORIES),$(REP)/include) ALL_INC_DIR += $(LIBGCC_INC_DIR) +ALL_INC_DIR += $(HOST_INC_DIR) INSTALL_DIR ?= diff --git a/base/mk/prg.mk b/base/mk/prg.mk index 55f4e182a3..e2faa0de88 100644 --- a/base/mk/prg.mk +++ b/base/mk/prg.mk @@ -30,6 +30,14 @@ select_from_repositories = $(firstword $(foreach REP,$(REPOSITORIES),$(wildcard PRG_DIR := $(REP_DIR)/src/$(PRG_REL_DIR) include $(PRG_DIR)/target.mk +# +# Enforce use of 'lx_hybrid' library for all targets when 'always_hybrid' is +# enabled +# +ifeq ($(filter-out $(SPECS),always_hybrid),) +LIBS += lx_hybrid +endif + # # Include lib-import description files # @@ -140,8 +148,9 @@ STATIC_LIBS := $(sort $(wildcard $(STATIC_LIBS))) # programs because the cxx functionality is already provided by the glibc. # ifeq ($(USE_HOST_LD_SCRIPT),yes) -STATIC_LIBS := $(filter-out $(LIB_CACHE_DIR)/thread/thread.lib.a, $(STATIC_LIBS)) -STATIC_LIBS := $(filter-out $(LIB_CACHE_DIR)/cxx/cxx.lib.a, $(STATIC_LIBS)) +STATIC_LIBS := $(filter-out $(LIB_CACHE_DIR)/startup/startup.lib.a, $(STATIC_LIBS)) +STATIC_LIBS := $(filter-out $(LIB_CACHE_DIR)/thread/thread.lib.a, $(STATIC_LIBS)) +STATIC_LIBS := $(filter-out $(LIB_CACHE_DIR)/cxx/cxx.lib.a, $(STATIC_LIBS)) endif # diff --git a/base/src/base/thread/thread.cc b/base/src/base/thread/thread.cc index cb1e4da1be..fcc11a93b0 100644 --- a/base/src/base/thread/thread.cc +++ b/base/src/base/thread/thread.cc @@ -168,7 +168,7 @@ void Thread_base::_free_context() void Thread_base::name(char *dst, size_t dst_len) { - snprintf(dst, min(dst_len, (size_t)Context::NAME_LEN), _context->name); + snprintf(dst, min(dst_len, (size_t)Context::NAME_LEN), "%s", _context->name); } diff --git a/base/src/core/rm_session_component.cc b/base/src/core/rm_session_component.cc index ec87a5a9af..e981021f5e 100644 --- a/base/src/core/rm_session_component.cc +++ b/base/src/core/rm_session_component.cc @@ -325,7 +325,7 @@ Rm_session_component::attach(Dataspace_capability ds_cap, size_t size, /* offset must be positive and page-aligned */ if (offset < 0 - || align_addr(offset, get_page_size_log2()) != (size_t)offset) + || align_addr(offset, get_page_size_log2()) != offset) throw Invalid_args(); /* check dataspace validity */ diff --git a/demo/src/app/scout/include/canvas.h b/demo/src/app/scout/include/canvas.h index e8b99ed6b5..18174a0e8d 100644 --- a/demo/src/app/scout/include/canvas.h +++ b/demo/src/app/scout/include/canvas.h @@ -46,8 +46,8 @@ class Canvas /* check against canvas boundaries */ if (_clip_x1 < 0) _clip_x1 = 0; if (_clip_y1 < 0) _clip_y1 = 0; - if (_clip_x2 >= _w && w > 0) _clip_x2 = _w - 1; - if (_clip_y2 >= _h && w > 0) _clip_y2 = _h - 1; + if (w > 0 && _clip_x2 > _w - 1) _clip_x2 = _w - 1; + if (h > 0 && _clip_y2 > _h - 1) _clip_y2 = _h - 1; } /** diff --git a/doc/Makefile b/doc/Makefile deleted file mode 100644 index 4d633d1ba4..0000000000 --- a/doc/Makefile +++ /dev/null @@ -1,38 +0,0 @@ -SHELL = bash - -all: directories.txt - -# -# The order of directories in the documentation can be expressed as dependencies. -# -../demo: ../base - -directories.txt: $(shell find .. -name README) Makefile - @echo "creating $@" - @echo "Directory structure of the Genode source tree" > $@ - @echo "#############################################" >> $@ - @echo >> $@ - @$(MAKE) --no-print-directory .. >> $@ - -DIRECTORIES = $(shell find .. -type d) - -.PHONY: $(DIRECTORIES) - -$(DIRECTORIES): - @if test -r $@/README; then \ - dir=$@; dir="$${dir:3}"; \ - if test -n "$$dir"; then \ - dir="'$$dir'"; \ - echo "$$dir"; \ - echo "$${dir//?/=}"; \ - echo; \ - fi; \ - cat $@/README; \ - echo; \ - echo; \ - fi; \ - recursion="$(shell find $@/* -mindepth 1 -name README -printf '%H\n')"; \ - if test "$$recursion"; then $(MAKE) --no-print-directory -s $$recursion; fi - -clean cleanall: - rm -f directories.txt diff --git a/doc/architecture.txt b/doc/architecture.txt new file mode 100644 index 0000000000..4786138a30 --- /dev/null +++ b/doc/architecture.txt @@ -0,0 +1,1037 @@ + + ==================================== + Design of the Genode OS Architecture + ==================================== + + + Norman Feske and Christian Helmuth + +Abstract +######## + +In the software world, high complexity of a problem solution comes along with a +high risk for bugs and vulnerabilities. +This correlation is particularly perturbing for todays commodity operating +systems with their tremendous complexity. +The numerous approaches to increase the user's confidence in the correct +functioning of software comprise exhaustive tests, code auditing, static code +analysis, and formal verification. +Such quality-assurance measures are either rather shallow or they scale badly +with increasing complexity. + +The operating-system design presented in this document focuses on the root of the +problem by providing means to minimize the underlying system complexity for +each security-sensitive application individually. +On the other hand, we want to enable multiple applications to execute on the +system at the same time whereas each application may have different functional +requirements from the operating system. +Todays operating systems provide a functional superset of the requirements of +all applications and thus, violate the principle of minimalism for each single +application. +We resolve the conflict between the principle of minimalism and the versatility +of the operating system by decomposing the operating system into small +components and by providing a way to execute those components isolated and +independent from each other. +Components can be device drivers, protocol stacks such as file systems and +network stacks, native applications, and containers for executing legacy +software. +Each application depends only on the functionality of a bounded set of +components that we call _application-specific_trusted_computing_base_(TCB)_. +If the TCBs of two applications are executed completely _isolated_ and +_independent_ from each other, we consider both TCBs as minimal. + +In practice however, we want to share physical resources between multiple applications +without sacrificing their independence. +Therefore, the operating-system design has to enable the assignment of physical +resources to each application and its TCB to maintain independence from other +applications. +Furthermore, rather than living in complete isolation, components require to +communicate with each other to cooperate. +The operating-system design must enable components to create other components +and get them to know each other while maintaining isolation from uninvolved +parts of the system. + +First, we narrow our goals and pose our mayor challenges in Section [Goals and Challenges]. +Section [Interfaces and Mechanisms] introduces our fundamental concepts and +protocols that apply to each component in the system. +In Section [Core - the root of the process tree], we present the one component +that is mandatory part of each TCB, enables the bootstrapping of the system, +and provides abstractions for the lowest-level resources. +We exercise the composition of the presented mechanisms by the means of process +creation in Section [Process creation]. +;Section [Framework infrastructure] + + +Goals and Challenges +#################### + +The Genode architecture is designed to accommodate the following types +of components in a secure manner concurrently on one machine: + +:Device drivers: + + Device drivers translate the facilities of raw physical devices to + device-class-specific interfaces to be used by other components. + They contain no security policies and provide their services + to only one client component per device. + +:Services that multiplex resources: + + To make one physical resource (e.g., a device) usable by multiple + components at the same time, the physical resource must be translated + to multiple virtual resources. For example, a + frame buffer provided by a device driver can only be used by one + client at the same time. A window system multiplexes this physical + resource to make it available to multiple clients. Other examples + are an audio mixer or a virtual network hub. + In contrast to a device driver, a _resource multiplexer_ deals with multiple + clients and therefore, plays a crucial role for maintaining the independence + and isolation of its clients from each other. + +:Protocol stacks: + + Protocol stacks translate low-level protocols to a higher and more applicable + level. + For example, a file system translates a block-device protocol to a file + abstraction, a TCP/IP stack translates network packets to a socket + abstraction, or a widget set maps high-level GUI elements to pixels. + Compared to resource multiplexers, protocol stacks are typically an + order of magnitude more complex. + Protocol stacks may also act as resource multiplexers. In this case however, + high complexity puts the independence and isolation of multiple + clients at a high risk. + Therefore, our design should enable the instantiation of protocol stacks per + application. + For example, instead of letting a security-sensitive application share one + TCP/IP stack with multiple other (untrusted) applications, it could use a + dedicated instance of a TCP/IP stack to increase its independence and + isolation from the other applications. + +:Containers for executing legacy software: + + A _legacy container_ provides an environment for the execution of existing + legacy software. This can be achieved by the means of a virtual machine + (e.g., a Java VM, a virtual PC), a compatible programming API (e.g., POSIX, + Qt), a language environment (e.g., LISP), or a script interpreter. + In the majority of cases, we regard legacy software as an untrusted black box. + One particular example for legacy software are untrusted legacy device drivers. + In this case, the container has to protect the physical hardware from + potentially malicious device accesses by the untrusted driver. + Legacy software may be extremely complex and resource demanding, for example + the Firefox web browser executed on top of the X window system and the Linux + kernel inside a virtualized PC. + In this case, the legacy container may locally implement sophisticated + resource-management techniques such as virtual memory. + +:Small custom security-sensitive applications: + + Alongside legacy software, small custom applications implement crucial + security-sensitive functionality. + In contrast to legacy software, which we mostly regard as untrusted anyway, + a low TCB complexity for custom applications is of extreme importance. + Given the special liability of such an application, it is very carefully + designed to have low complexity and require as little infrastructure as + possible. + A typical example is a cryptographic component that protects credentials + of the user. + Such an application does not require swapping (virtual memory), a POSIX API, + or a complete C library. + Instead, the main objectives of such an application are to avoid as much as + possible code from being included in its TCB and to keep its requirements at + a minimum. + +Our design must be able to create and destroy subsystems that are composed of +multiple such components. +The _isolation_ requirement as stated in the introduction raises the +question of how to organize the locality of name spaces and how to distribute +access from components to other components within the system. +The _independence_ requirement demands the assignment of physical resources +to components such that different applications do not interfere. +Instead of managing access control and physical resources from a central +place, we desire a distributed way for applying policy for trading and revocating +resources and for delegating rights. + + + +Interfaces and Mechanisms +######################### + +The system is structured as a tree. +The nodes of the tree are processes. +A node, for which sub-nodes exist, is called the _parent_ of these sub-nodes +(_children_). +The parent creates children out of its own resources and defines +their execution environment. +Each process can announce services to its parent. +The parent, in turn, can mediate such a service to its other children. +When a child is created, its parent provides the initial contact to the +outer world via the following interface: + +! void exit(int exit_value); +! +! Session_capability session(String service_name, +! String args); +! +! void close(Session_capability session_cap); +! +! int announce(String service_name, +! Root_capability service_root_cap); +! +! int transfer_quota(Session_capability to_session_cap, +! String amount); + + +:'exit': is called by a child to request its own termination. + +:'session': is called by a child to request a connection to the specified + service as known by its parent whereas 'service_name' is the name + of the desired service _interface_. + The way of resolving or even denying a 'session' request depends on + the policy of the parent. + The 'args' parameter contains construction arguments for the session + to be created. + In particular, 'args' contains a specification of resources that the + process is willing to donate to the server during the session lifetime. + +:'close': is called by a child to inform its parent that the specified + session is no longer needed. + The parent should close the session and hand back donated + resources to the child. + +:'announce': is called by a child to register a locally implemented + service at its parent. Hence, this child is a server. + +:'transfer_quota': enables a child to extend its resource donation + to the server that provides the specified session. + +We provide a detailed description and motivation for the different functions +in Sections [Servers] and [Quota]. + +Servers +======= + +Each process may implement services and announce them via the 'announce' +function of the parent interface. +When announcing a service, the server specifies a _root_ capability for +the implemented service. +The interface of the root capability enables the parent to create, configure, +and close sessions of the service: + +! Session_capability session(String args); +! +! int transfer_quota(Session_capability to_session_cap, +! String amount); +! +! void close(Session_capability session_cap); + + +[image announce 60%] + Announcement of a service by a child (server). + Colored circles at the edge of a component represent remotely accessible + objects. Small circles inside a component represent a reference (capability) + to a remote object. A cross-component reference to a remote object is + illustrated by a dashed arrow. An opaque arrow symbolizes a RPC call/return. + +Figure [announce] illustrates an announcement of a service. +Initially, each child has a capability to its parent. +After Child1 announces its service "Service", its parent knows the +root capability of this service under the local name 'srv1_r' and stores +the root capability with the announced service name in its _root_list_. +The root capability is intended to be used and kept by the parent only. + +[image request 60%] + Service request by a client. + +When a parent calls the 'session' function of the root interface of a server +child, the server creates a new client session and returns the corresponding +'client_session' capability. +This session capability provides the actual service-specific interface. +The parent can use it directly or it may pass it to other processes, in +particular to another child that requested the session. +In Figure [request], Child2 initiates the creation of a "Service" session +by a 'session' call at its parent capability (1). +The parent uses its root list to look up the root capability that matches the +service name "Service" (2) and calls the 'session' function at the +server (3). +Child1 being the server creates a new session ('session1') and returns the +session capability as result of the 'session' call (4). +The parent now knows the new session under the local name 'srv1_s1' (5) and +passes the session capability as return value of Child2's initial 'session' +call (6). +The parent maintains a _session_list_, which stores the interrelation between +children and their created sessions. +Now, Child2 has a direct communication channel to 'session1' provided by +the server (Child1) (7). + +The 'close' function of the root interface instructs the server to +destroy the specified session and to release all session-specific resources. + +; Mittels 'set_quota' kann der Parent einen Dienst anweisen, die Ressourcennutzung +; für eine angegebene 'client_session' zu begrenzen. Eine nähere Beschreibung des +; Ressourcen-Accountings erfolgt in Kapitel [Quota]. + +[image twolevels 80%] + Announcement and request of a service in a subsystem. + For simplicity, parent capabilities are not displayed. + +Even though the prior examples involved only one parent, +the announce-request mechanism can be used recursively for tree +structures of any depth and thus allow for partitioning +the system into subsystems that can cooperate with each other whereas +parents are always in complete control over the communication +and resource usage of their children (and their subsystems). + +Figure [twolevels] depicts a nested subsystem on the left. +Child1 announces its service named "Service" at its parent that, in turn, +announces a service named "Service" at the Grandparent. +The service names do not need to be identical. +Their meaning spans to their immediate parent only and there +may be a name remapping on each hierarchy level. +Each parent can decide itself whether to further announce +services of their children to the outer world or not. +The parent can announce Child1's service to the grandparent +by creating a new root capability to a local service that forwards +session-creation and closing requests to Child1. +Both Parent and Grandparent keep their local root lists. +In a second step, Parent2 initiates the creation of a session to +the service by issuing a 'session' request at the Grandparent (1). +Grandparent uses its root list to look up the service-providing child (from +Grandparent's local view) Parent1 (2). +Parent1 in turn, implements the service not by itself but delegates +the 'session' request to Child1 by calling the 'session' function +of the actual "Service" root interface (3). +The session capability, created by Child1 (4), can now be passed to Parent2 +as return value of nested 'session' calls (5, 6). +Each involved node keeps the local knowledge about the created session +such that later, the session can be closed in the same nested fashion. + +Quota +===== + +Each process that provides services to other processes consumes resources on +behalf of it clients. +Such a server requires memory to maintain session-specific state, processing +time to perform the actual service function, and eventually further system +resources (e.g., bus bandwidth) dependent on client requests. +To avoid denial-of-service problems, a server must not allocate such +resources from its own budget but let the client pay. +Therefore, a mechanism for donating resource quotas from the client to the +server is required. +Both client and server may be arbitrary nodes in the process tree. +In the following, we examine the trading of resource quotas within +the recursive system structure using memory as an example. + +When creating a child, the parent assigns a part of its own memory quota +to the new child. +During the lifetime of the child, the parent can further transfer +quota back and forth between the child's and its own account. +Because the parent creates its children out of its own resources, +it has a natural interest to correctly manage child quotas. +When a child requests a session to a service, it can bind a part +of its quota to the new session by specifying a resource donation +as an argument. +When receiving a session request, the parent has to distinct +three different cases, dependent on where the corresponding server +resides: + +:Parent provides service: + + If the parent provides the requested services by itself, + it transfers the donated amount of memory quota from the + requesting child's account to its own account to compensate + the session-specific memory allocation on behalf of its own + child. + +:Server is another child: + + If there exists a matching entry in the parent's root list, + the requested service is provided by another child (or a + node within the child subsystem). In this case, the parent + transfers the donated memory quota from the requesting child + to the service-providing child. + +:Delegation to grandparent: + + The parent may decide to delegate the session request to + its own parent because the requested service is provided by + a lower node of the process tree. + Thus, the parent will request a session on behalf of its child. + The grandparent neither knows nor cares about the actual + origin of the request and will simply decrease the memory + quota of the parent. + For this reason, the parent transfers the donated memory + quota from the requesting child to its own account before + calling the grandparent. + +This algorithm works recursively. +Once, the server receives the session request, it checks if +the donated memory quota suffices for storing the session-specific +data and, on success, creates the session. +If the initial quota donation turns out to be too scarce during +the lifetime of a session, the client may make further donations +via the 'transfer_quota' function of the parent interface that +works analogously. + +If a child requests to close a session, the parent must distinguish +the three cases as above. +Once, the server receives the session-close request from its parent, +it is responsible to release all resources that were used for this session. +After the server releases the session-specific resources, the +server's quota can be decreased to the prior state. +However, an ill-behaving server may fail to release those resources by malice +or caused by a bug. + +If the misbehaving service was provided by the parent himself, +it has the full authority to not hand back session-quota to +its child. +If the misbehaving service was provided by the grandparent, +the parent (and its whole subsystem) has to subordinate. +If, however, the service was provided by another child and the +child refuses to release resources, decreasing its quota after +closing the session will fail. +It is up to the policy of the parent to handle such a failure either by +punishing it (e.g., killing the misbehaving server) or by granting more of its +own quota. +Generally, misbehavior is against the server's own interests and +each server would obey the parent's 'close' request to avoid intervention. + + +Successive policy management +============================ + +For supporting a high variety of security policies for access control, we +require a way to bind properties and restrictions to sessions. For example, +a file service may want to restrict the access to files according to an +access-control policy that is specific for each client session. +On session creation, the 'session' call takes an 'args' argument that can be +used for that purpose. It is a list of tag-value pairs describing the session +properties. By convention, the list is ordered by attribute priority starting +with the most important property. +The server uses these 'args' as construction arguments for the new +session and enforces the security policy as expressed by 'args' accordingly. +Whereas the client defines its desired session-construction arguments, each +node that is incorporated in the session creation can alter these arguments in +any way and may add further properties. +This effectively enables each parent to impose any desired restrictions to +sessions created by its children. +This concept works recursively and enables each node in the process hierarchy +to control exactly the properties that it knows and cares about. As a side +note, the specification of resource donations as described in the Section +[Quota] is performed with the same mechanism. A resource donation is a property +of a session. + +[image incremental_restrictions] + Successive application of policies at the creation time of a new session. + +Figure [incremental_restrictions] shows an example scenario. A user +application issues the creation of a new session to the 'GUI' server and +specifies its wish for reading user input and using the string "Terminal" as +window label (1). +The parent of the user application is the user manager that introduces +user identities into the system and wants to ensure that each displayed window +gets tagged with the user and the executed program. Therefore, it overrides the +'label' attribute with more accurate information (2). Note that the modified +argument is now the head of the argument list. +The parent of the user manager, in turn, implements further policies. In the +example, Init's policy prohibits the user-manager subtree from reading +input (for example to disable access to the system beyond official working hours) +by redefining the 'input' attribute and leaving all other attributes unchanged (3). +The actual GUI server observes the final result of the successively changed +session-construction arguments (4) and it is responsible for enforcing the specified +policy for the lifetime of the session. +Once a session has been established, its properties are fixed and cannot be changed. + + +Core - the root of the process tree +################################### + +Core is the first user-level program that takes control when starting up the +system. It has access to the raw physical resources and converts them to +abstractions that enable multiple programs to use these resources. +In particular, core converts the physical address space to higher-level +containers called _dataspaces_. +A dataspace represents a contiguous physical address space region with an +arbitrary size (at page-size granularity). +Multiple processes can make the same dataspace accessible in their +local address spaces. +The system on top of core never deals with physical memory pages but +uses this uniform abstraction to work with memory, memory-mapped I/O +regions, and ROM areas. + +*Note:* _Using only contiguous dataspaces may lead to fragmentation of the_ +_physical address space. This property is, however, only required by_ +_a few rare cases (e.g., DMA transfers). Therefore, later versions of the_ +_design will support non-contiguous dataspaces._ + +Furthermore, core provides all prerequisites to bootstrap the process tree. +These prerequisites comprise services for creating processes and threads, +for allocating memory, for accessing boot-time-present files, and for managing +address-space layouts. +Core is almost free from policy. There are no configuration options. +The only policy of core is the startup of the init process to which core +grants all available resources. + +In the following, we explain the session interfaces of core's services in +detail. + + +RAM - allocator for physical memory +=================================== + +A RAM session is a quota-bounded allocator of blocks from physical memory. +There are no RAM-specific session-construction arguments. +Immediately after the creation of a RAM session, its quota is zero. +To make the RAM session functional, it must be loaded with quota from +another already existing RAM session, which we call the _reference account_. +The reference account of a RAM session can be defined initially via: +!int ref_account(Ram_session_capability ram_session_cap); +Once the reference account is defined, quota can be transferred back and +forth between the reference account and the new RAM session with: +!int transfer_quota(Ram_session_capability ram_session_cap, +! size_t amount); +Provided, the RAM session has enough quota, a dataspace of a given size +can be allocated with: +!Ram_dataspace_capability alloc(size_t size); +The result value of 'alloc' is a capability to the RAM-dataspace +object implemented in core. This capability can be communicated to other +processes and can be used to make the dataspace's physical-memory region +accessible from these processes. +An allocated dataspace can be released with: +!void free(Ram_dataspace_capability ds_cap); +The 'alloc' and 'free' calls track the used-quota information of the RAM +session accordingly. +Current statistical information about the quota limit and the +used quota can be retrieved by: +!size_t quota(); +!size_t used(); +Closing a RAM session implicitly destroys all allocated dataspaces. + + +ROM - boot-time-file access +=========================== + +A ROM session represents a boot-time-present read-only file. This may be a +module provided by the boot loader or a part of a static ROM image. On session +construction, a file identifier must be specified as a session argument using the +tag 'filename'. The available filenames are not fixed but depend on the actual +deployment. On some platforms, core may provide logical files for special memory +objects such as the GRUB multiboot info structure or a kernel info page. The +ROM session enables the actual read access to the file by exporting the file as +dataspace: +!Rom_dataspace_capability dataspace(); + + +IO_MEM - memory mapped I/O access +================================= + +With IO_MEM, core provides a dataspace abstraction for non-memory parts of the +physical address space such as memory-mapped I/O regions or BIOS areas. In +contrast to a memory block that is used for storing information of which the +physical location in memory is of no matter, a non-memory object has a special +semantics attached to its location within the physical address space. Its +location is either fixed (by standard) or can be determined at runtime, for +example by scanning the PCI bus for PCI resources. If the physical location of +such a non-memory object is known, an IO_MEM session can be created by +specifying 'base' and 'size' as session-construction arguments. +The IO_MEM session then provides the specified physical memory area as +dataspace: +!Io_mem_dataspace_capability dataspace(); + + +IO_PORT - access to I/O ports +============================= + +For platforms that rely on I/O ports for device access, core's IO_PORT service +enables fine-grained assignment of port ranges to individual processes. +Each IO_PORT session corresponds to the exclusive access right to a +port range as specified with the 'io_port_base' and 'io_port_size' +session-construction arguments. Core creates the new IO_PORT session +only if the specified port range does not overlap with an already existing +session. This ensures that each I/O port is driven by only one +process at a time. The IO_PORT session interface resembles the +physical I/O port access instructions. Reading from an I/O port +can be performed via an 8bit, 16bit, or 32bit access: +!unsigned char inb(unsigned short address); +!unsigned short inw(unsigned short address); +!unsigned inl(unsigned short address); +Vice versa, there exist functions for writing to an I/O port via +an 8bit, 16bit, or 32bit access: +!void outb(unsigned short address, unsigned char value); +!void outw(unsigned short address, unsigned short value); +!void outl(unsigned short address, unsigned value); +The address argument of I/O-port access functions are absolute +port addresses that must be within the port range of the session. + + +IRQ - handling device interrupts +================================ + +The IRQ service of core provides processes with an interface to +device interrupts. Each IRQ session corresponds to an attached +interrupt. The physical interrupt number is specified via the +'irq_number' session-construction argument. A physical interrupt +number can be attached to only one session. The IRQ session +interface provides a blocking function to wait for the next +interrupt: +!void wait_for_irq(); +While the 'wait_for_irq' function blocks, core unmasks the +interrupt corresponding to the IRQ session. +On function return, the corresponding interrupt line is masked +and acknowledged. + +;*Note:* _The interface of the IRQ service is going to be changed_ +;_with the planed addition of signals to the framework._ + + +RM - managing address space layouts +=================================== + +RM is a _region manager_ service that allows for constructing address space +layouts (_region map_) from dataspaces and that provides support for assigning +region maps to processes by paging the process' threads. +Each RM session corresponds to one region map. After creating a new RM session, +dataspaces can be attached to the region map via: +!void *attach(Dataspace_capability ds_cap, +! size_t size=0, off_t offset=0, +! bool use_local_addr = false, +! addr_t local_addr = 0); +The 'attach' function inserts the specified dataspace into the region map and +returns the actually used start position within the region map. +By using the default arguments, the region manager chooses an appropriate +position that is large enough to hold the whole dataspace. +Alternatively, the caller of 'attach' can attach any sub-range of the dataspace +at a specified target position to the region map by enabling 'use_local_addr' +and specifying an argument for 'local_addr'. Note that the interface allows for the +same dataspace to be attached not only to multiple region maps but also multiple +times to the same region map. +As the counterpart to 'attach', 'detach' removes dataspaces from the region map: +!void detach(void *local_addr); +The region manager determines the dataspace at the specified 'local_addr' (not +necessarily the start address) and removes the whole dataspace from the region +map. +To enable the use of a RM session by a process, we must associate it with +each thread running in the process. The function +!Thread_capability add_client(Thread_capability thread); +returns a thread capability for a _pager_ that handles the page faults of the +specified 'thread' according to the region map. +With subsequent page faults caused by the thread, the address-space layout +described by the region map becomes valid for the process that is executing the +thread. + + +CPU - allocator for processing time +=================================== + +A CPU session is an allocator for processing time that allows for the creation, +the control, and the destruction of threads of execution. +There are no session arguments used. +The functionality of starting and killing threads is provided by two functions: +!Thread_capability create_thread(const char* name); +!void kill_thread(Thread_capability thread_cap); +The 'create_thread' function takes a symbolic thread name (that is only used +for debugging purposes) and returns a capability to the new thread. +Furthermore, the CPU session provides the following functions for operating +on threads: +!int set_pager(Thread_capability thread_cap, +! Thread_capability pager_cap); + +!int cancel_blocking(Thread_capability thread_cap); + +!int start(Thread_capability thread_cap, +! addr_t ip, addr_t sp); + +!int state(Thread_capability thread, +! Thread_state *out_state); +The 'set_pager' function registers the thread's pager whereas 'pager_cap' +(obtained by calling 'add_client' at a RM session) refers to the RM session to +be used as the address-space layout. +For starting the actual execution of the thread, its initial instruction +pointer ('ip') and stack pointer ('sp') must be specified for the 'start' +operation. +In turn, the 'state' function provides the current thread state including +the current instruction pointer and stack pointer. +The 'cancel_blocking' function causes the specified thread to cancel a +currently executed blocking operation such as waiting for an incoming message +or acquiring a lock. This function is used by the framework for gracefully +destructing threads. + +*Note:* _Future versions of the CPU service will provide means to further control the_ +_thread during execution (e.g., pause, execution of only one instruction),_ +_acquiring more comprehensive thread state (current registers), and configuring_ +_scheduling parameters._ + + +PD - providing protection domains +================================= + +A PD session corresponds to a memory protection domain. Together +with one or more threads and an address-space layout (RM session), it forms a +process. +There are no session arguments. After session creation, the PD contains no +threads. Once a new thread has been created from a CPU session, it can be assigned +to the PD by calling: +! int bind_thread(Thread_capability thread); + + +CAP - allocator for capabilities +================================ + +A capability is a system-wide unique object identity that typically refers to a +remote object implemented by a service. For each object to be made remotely +accessible, the service creates a new capability associated with the local +object. CAP is a service to allocate and free capabilities: +! Capability alloc(Capability ep_cap); +! void free(Capability cap); +The 'alloc' function takes an entrypoint capability as argument, which is the +communication receiver for invocations of the new capability's RPC interface. + + +LOG - debug output facility +=========================== + +The LOG service is used by the lowest-level system components such as the init +process for printing debug output. +Each LOG session takes a 'label' string as session argument, +which is used to prefix the debug output of this session. +This enables developers to distinguish multiple producers of debug output. +The function +! size_t write(const char *string); +outputs the specified 'string' to the debug-output backend of core. + + +Process creation +################ + +The previous section presented the services implemented by core. +In this section, we show how to combine these basic mechanisms to create and +execute a process. +Process creation serves as a prime example for our general approach to first +provide very simple functional primitives and then solve complex problems using +a composition of these primitives. +We use slightly simplified pseudo code to illustrate this procedure. +The 'env()' object refers to the environment of the creating process, which +contains its RM session and RAM session. + +:Obtaining the executable ELF binary: + + If the binary is available as ROM object, we can access its data by creating + a ROM session with the binary's name as argument and attaching its dataspace + to our local address space: + !Rom_session_capability file_cap; + !file_cap = session("ROM", "filename=init"); + !Rom_dataspace_capability ds_cap; + !ds_cap = Rom_session_client(file_cap).dataspace(); + ! + !void *elf_addr = env()->rm_session()->attach(ds_cap); + + The variable 'elf_addr' now points to the start of the binary data. + +:ELF binary decoding and creation of the new region map: + + We create a new region map using the RM service: + !Rm_session_capability rm_cap; + !rm_cap = session("RM"); + !Rm_session_client rsc(rm_cap); + Initially, this region map is empty. + The ELF binary contains CODE, DATA, and BSS sections. + For each section, we add a dataspace to the region map. + For read-only CODE and DATA sections, we attach the corresponding ranges of + the original ELF dataspace ('ds_cap'): + !rsc.attach(ds_cap, size, offset, true, addr); + The 'size' and 'offset' arguments specify the location of the section within + the ELF image. The 'addr' argument defines the desired start position at the + region map. + For each BSS and DATA section, we allocate a read-and-writeable RAM dataspace + !Ram_dataspace_capability rw_cap; + !rw_cap = env()->ram_session()->alloc(section_size); + and assign its initial content (zero for BSS sections, copy of ELF DATA sections). + !void *sec_addr = env()->rm_session()->attach(rw_cap); + ! ... /* write to buffer at sec_addr */ + !env()->rm_session()->detach(sec_addr); + After iterating through all ELF sections, the region map of the new process + is completely initialized. + +:Creating the first thread: + + For creating the main thread of the new process, we create a + new CPU session from which we allocate the thread: + !CPU_session_capability cpu_cap = session("CPU"); + !Cpu_session_client csc(cpu_cap); + !Thread_capability thread_cap = csc.create_thread(); + When the thread starts its execution and fetches its first instruction, it + will immediately trigger a page fault. Therefore, we need to assign a + page-fault handler (pager) to the thread. With resolving subsequent page faults, the + pager will populate the address space in which the thread is executed with + memory mappings according to a region map: + !Thread_capability pager_cap = rsc.add_client(thread_cap); + !csc.set_pager(thread_cap, pager_cap); + +:Creating a protection domain: + + The new process' protection domain corresponds to a PD session: + !Pd_session_capability pd_cap = session("PD"); + !Pd_session_client pdsc(pd_cap); + +:Assigning the first thread to the protection domain: + + !pdsc.bind_thread(thread_cap); + +:Starting the execution: + + Now that we defined the relationship of the process' region map, its main + thread, and its address space, we can start the process by specifying the + initial instruction pointer and stack pointer as obtained from the ELF + binary. + !csc.start(thread_cap, ip, sp); + +; supplying the parent capability to the new process + + +Framework infrastructure +######################## + +Apart from the very fundamental mechanisms implemented by core, all +higher-level services have to be implemented as part of the process tree on top +of core. +There are a number of frameworks at hand that provide convenient interfaces to +be used by such components. +In this section, we outline the most important frameworks. + + +Communication +============= + +The basic mode of operation of our RPC framework is based on C++ streams. +It uses four different stream classes: 'Ipc_ostream' for sending messages, +'Ipc_istream' for receiving messages, 'Ipc_client' for performing RPC calls, +and 'Ipc_server' for dispatching RPC calls. In the following, we use +illustrative examples. + +:Sending a message: + + !Ipc_ostream sender(dst, &snd_buf); + !sender << a << b << IPC_SEND; + The object 'sender' is an output stream that is initialized with a + communication endpoint ('dst') and a message buffer ('snd_buf'). + For sending the message, we sequentially insert both arguments into the stream + to transform the arguments to a message and finally invoke the IPC mechanism of + the kernel by inserting the special object 'IPC_SEND'. + +:Receiving a message: + + !int a, b; + !Ipc_istream receiver(&rcv_buf); + !receiver >> IPC_WAIT >> a >> b; + For creating the 'receiver' input stream object, we specify a receive message + buffer as argument that can hold one incoming message. + By extracting the special object 'IPC_WAIT' from the receiver, we block for + a new message to be stored into 'rcv_buf'. + After returning from the blocking receive operation, we use the extraction + operator to _unmarshal_ the message argument by argument. + +:Performing a RPC call: + + !Ipc_client client(dst, &snd_buf, &rcv_buf); + !int result; + !client << OPCODE_FUNC1 << 1 << 2 + ! << IPC_CALL >> result; + The first argument is a constant that references one among + many server functions. + It is followed by the actual server-function arguments. + All arguments are marshalled into the 'snd_buf'. + When inserting the special object 'IPC_CALL' into the 'client' + stream, the client blocks for the result of the RPC. + After receiving the result message in 'rcv_buf', the RPC + results can be sequentially unmarshalled via the extraction + operator. Note that 'rcv_buf' and 'snd_buf' may use the + same backing store as both buffers are used interleaved. + +:Dispatching a RPC call: + + !Ipc_server server(&snd_buf, &rcv_buf); + !while (1) { + ! int opcode; + ! server >> IPC_REPLY_WAIT >> opcode; + ! switch (opcode) { + ! case OPCODE_FUNC1: + ! { + ! int a, b, ret; + ! server >> a >> b; + ! server << func1(a, b); + ! break; + ! } + ! .. + ! } + !} + The special object 'IPC_REPLY_WAIT' replies to the request of the previous + server-loop iteration with the message stored in 'snd_buf' (ignored for the + first iteration) and then waits for an incoming RPC request to be received + in 'rcv_buf'. + By convention, the first message argument contains the opcode to identify + the server function to handle the request. + After extracting the opcode from the 'server' stream, we branch into + a server-function-specific wrapper that reads the function arguments, calls the + actual server function, and inserts the function result into the 'server' stream. + The result message is to be delivered at the beginning of the next server-loop + iteration. + The two-stage argument-message parsing (the opcode to select the server function, + reading the server-function arguments) is simply done by subsequent extraction + operations. + + +Server framework +================ + +[image server_framework] + Relationships between the classes of the server object framework + +Each component that makes local objects remotely accessible to other components +has to provide means to dispatch RPC requests that refer to different objects. +This procedure highly depends on the mechanisms provided by the +underlying kernel. +The primary motivation of the server framework is to hide actual kernel +paradigms for communication, control flow, and the implementation of +local names (capabilities) behind a generic interface. +The server framework unifies the control flow of RPC dispatching and the mapping +between capabilities and local objects using the classes depicted in Figure [server_framework]. + +:'Object_pool': is an associative array that maps capabilities from/to local objects. + Because capabilities are protected kernel objects, the object pool's functionality + is supported by the kernel. + +*Note:* _On L4v2 and Linux, capabilities are not protected by the kernel but are_ +_implemented as unique IDs. On these base platforms, the object pool performs_ +_the simple mapping of such unique IDs to object pointers in the local_ +_address space._ + +:'Server_object': is an object-pool entry that contains a dispatch function. + To make a local object type available to remote components, the local + object type must inherit from 'Server_object' and provide the implementation + of the dispatch function as described in Section [Communication]. + +:'Server_entrypoint': is an object pool that acts as a logical communication entrypoint. + It can manage any number of server objects. When registering a server object to be + managed by a server entrypoint ('manage' method), a capability for this object + gets created. This capability can be communicated to other processes, + which can then use the server object's RPC interface. + +:'Server_activation': is the stack (or thread) to be used for handling RPC requests + of an entrypoint. + +*Note:* _On L4v2 and Linux, exactly one server activation must be attached to_ +_a server entrypoint. This implicates that RPC requests are handled in a_ +_strictly serialized manner and one blocking server function delays all_ +_other pending RPC requests referring the same server entrypoint. Concurrent handling_ +_of RPC requests should be realized with multiple (completely independent)_ +_server entrypoints._ + + +Process environment +=================== + +As described in Section [Interfaces and Mechanisms], a newly created process +can only communicate to its immediate parent via its parent capability. +This parent capability gets created "magically" dependent on the actual +platform. + +| For example, on the L4v2 platform, the parent writes the information about +| the parent capability to a defined position of the new process' address space +| after decoding the ELF image. On the Linux platform, the parent +| uses environment variables to communicate the parent capability to the +| child. + +Before entering the 'main' function of the new process, the process' startup +code 'crt0' is executed and initializes the _environment_ framework. +The environment contains RPC communication stubs for communicating with the +parent and the process' RM session, CPU session, PD session, and RAM +session. +Furthermore, the environment contains a heap that uses the process' RAM +session as backing store. +The environment can be used from the actual program by dereferencing the pointer +returned by the global function: +! Env *env(); + + +Child management +================ + +The class 'Child' provides a generic and extensible abstraction to unify the +creation of child processes, serve parent-interface requests, and to perform the +book keeping of open sessions. +Different access-control and resource-trading policies can be realized by +inheriting from this class and supplementing suitable parent-interface server +functions. + +A child process can be created by instantiating a 'Child' object: +!Child(const char *name, +! Dataspace_capability elf_ds_cap, +! Ram_session_capability ram_session_cap, +! Cpu_session_capability cpu_session_cap, +! Cap_session *cap_session, +! char *args[]) + +*NOTE:* _The 'name' parameter is only used for debugging._ +_The 'args' parameter is not yet supported._ + +;The 'Child' serves the parent interface for the new process by a distinct thread. + + +Heap partitioning +================= + +In Section [Goals and Challenges] where we introduced the different types of +components composing our system, we highlighted _resource multiplexers_ as +being critical for maintaining the isolation and independence of applications from +each other. +If a flawed resource multiplexer serves multiple clients at a time, information +may leak from one client to another (corrupting isolation) or different clients +may interfere in sharing limited physical resources (corrupting independence). +One particular limited resource that is typically shared among all +clients is the heap of the server. +If the server performs heap allocations on behalf of one client, this resource +may exhaust and renders the service unavailable to all other clients (denial of +service). +The resource-trading concept as presented in Section [Quota] enables clients to +donate memory quota to a server during the use of a session. +If the server's parent closes the session on request of the client, the donated +resources must be released by the server. +In order to comply with the request to avoid intervention by its parent, the +server must store the state of each session on dedicated dataspaces that can be +released independently from other sessions. +Instead of using one heap to hold anonymous memory allocations, the server +creates a _heap partition_ for each client and performs client-specific +allocations exclusively on the corresponding heap partition. +There exist two different classes to assist developers in partitioning the heap: +:'Heap': is an allocator that allocates chunks of memory as dataspaces from a + RAM session. Each chunk may hold multiple allocations. This kind of heap + corresponds loosely to a classical heap and can be used to allocate a high + number of small memory objects. The used backing store gets released on the + destruction of the heap. +:'Sliced_heap': is an allocator that uses a dedicated dataspace for each + allocation. Therefore, each allocated block can be released independently + from all other allocations. +The 'Sliced_heap' must be used to obtain the actual session objects and store +them in independent dataspaces. +Dynamic memory allocations during the lifetime of a session must be performed by +a 'Heap' as member of the session object. +When closing a session, the session object including the heap partition gets +destroyed and all backing-store dataspaces can be released without interfering +other clients. + + +Limitations and Outlook +####################### + +In its current incarnation, the design is subject to a number of limitations. +As a prime example for managing resources, we focused our work on physical +memory and ignored other prominent resource types such as processing time, bus +bandwidth, and network bandwidth. +We intend to apply the same methodology that we developed for physical memory to +other resource types analogously in later design revisions. +We do not cover features such as virtual-memory or transparent +copy-on-write support, which we regard as non-essential at the current stage. +At this point, we also do not provide specifics about the device-driver +infrastructure and legacy-software containers. +Note that the presented design does not fundamentally prevent the support +of these features. + diff --git a/doc/challenges.txt b/doc/challenges.txt new file mode 100644 index 0000000000..655b3fe444 --- /dev/null +++ b/doc/challenges.txt @@ -0,0 +1,501 @@ + + ======================================= + Future Challanges of the Genode project + ======================================= + + +Abstract +######## + +This document compiles various ideas to pursue in the context of Genode. It is +meant as source of inspiration for individuals who are interested in getting +involved with the project and for students who want to base their student +research projects on Genode. + + +Applications and library infrastructure +####################################### + +:Chrome web browser: + + The Chrome web browser promises to address the most pressing security + concerns of web application by isolation measures, in particular the + sandboxing of plugins and the confinement of individual web applications. As + we demonstrated with the Genode Live CD 10.11, Genode facilitates a more + natural way to pursue such techniques compared with current commodity + operating systems. Furthermore, the use of Genode as base platform for Chrome + would strengthen the web-browser security by dwarfing its trusted computing + base by two orders of magnitude compared to the use of Linux as base + platform. This would allow Chrome to be considered as a secure interface to + the web for use cases in the high-assurance domain. + +:Qemu or Virtual Box on Genode: + + Using Genode as hosting platform for virtual machines running in Qemu or + Virtual Box would enable the execution of security-sensitive functions (for + example cryptography) with a minimally-complex trusted computing base + beside running Windows on the same machine. + +:VNC server implementing Genode's framebuffer session interface: + + With 'Input' and 'Framebuffer', Genode provides two low-level interfaces + used by interactive applications. For example, the Nitpicker GUI server uses + these interfaces as a client and, in turn, exports multiple virtual + 'Framebuffer' and 'Input' interfaces to its clients. This enables a + highly modular use of applications such as the nesting of GUIs. By + implementing the 'Framebuffer' and 'Input' interfaces with a VNC server + implementation, all graphical workloads of Genode would become available over + the network. One immediate application of this implementation is the remote + testing of graphical Genode applications running on a headless server. + +:Tiled window manager: + + At Genode Labs, we pursue the goal to shape Genode into an general-purpose + operating system suitable for productive work. The feature set needed to + achieve this goal largely depends on the tools and applications daily used by + the Genode engineers. As one particularly important tool for being highly + productive, we identified a tiled user interface. Currently, all developers + at Genode Labs embrace either the Ion3 window manager or the tiled Terminator + terminal emulator. Hence, we desire to have a similar mode of user + interaction on Genode as well. The goal of this challenge is to identify the + most important usage patters and the implementation of a tiled GUI that + multiplexes the framebuffer into a set of tiled and tabbed virtual + framebuffers. + + Related to this work, the low-level 'Framebuffer' and 'Input' interfaces + should be subject to a revision, for example for enabling the flexible change + of framebuffer sizes as needed by a tiled user interface. + +:Interactive sound switchbox based on Genode's Audio_out session interface: + + Since version 10.05, Genode features a highly flexible configuration concept + that allows the arbitrary routing of session requests throughout the + hierarchic process structure. Even though primarily designed for expressing + mandatory-access control rules, the concept scales far beyond this use case. + For example, it can be used to run an arbitrary number of processes + implementing the same interface and connecting the different interface + implementations. One special case of this scenario is a chain of audio + filters with each using the 'Audio_out' session interface for both roles + client and server. Combined with the Nitpicker GUI server and Genode's + support for real-time priorities, this base techniques enable the creation of + flexible audio mixer / switchboard applications, which require dedicated + frameworks (e.g., Jack audio) on traditional operating systems. The goal of + this project is to create a show case implementation demonstrating the + feasibility for creating high-quality audio applications on Genode. + Furthermore, we wish for feedback regarding the current design of our bulk + streaming interface when used for low-latency applications. + +:PDF reader for E-Government use: + + A facility for reading PDF and E-Book documents is one of the indispensable + features Genode has to provide to be considered for general-purpose + computing. The goal of this work is to identify a suitable open-source PDF + engine and port it as native application to Genode. The challenging part is + to keep the complexity of this application as low as possible in order to + enable the use of this application as a trusted document reader. Further + ideas envision the use of PDF files as medium for sensitive documents + combined with measures for protecting the integrity of the displayed + information. For example, when processing contracts or similar sensitive + documents in E-Government scenarios, the consumer of such documents expects + the correct display of all the information as expressed by the creator of the + document. In the event of a compromised PDF engine or a man-in-the middle + attacker manipulating the PDF file, the consumer of the document requires a + way to identify such security breaches. In this context, running the PDF + engine in a sandboxed Genode subsystem has two incentives. First, the attack + surface for manipulating the PDF engine gets dramatically reduced, and + second, the integrity of the result of the PDF engine can be measured by an + independent trusted component facilitating Genode secure GUI server + (Nitpicker). + +:Graphical on-target IPC tracing tool using Qt4: + + Analysing the interaction of components of a multi-server operating system + such as Genode is important to discover bottlenecks of the system and for + debugging highly complex usage scenarios involving many processes. Currently, + Genode handles this problem with two approaches. First, Genode's + recursive structure enables the integration of a subsystem in a basic + OS setup featuring only those drivers and components used for the particular + subsystem. After the successful integration of such a subsystem, it can + be embedded into a far more complex application scenario without any changes. + With this approach, the subject to analyse can be kept at a reasonable level + at integration time. For debugging purposes, the current approach is using + the debugging facilities of the respective base platforms (e.g., using + GDB on Linux, the Fiasco kernel debugger, the OKL4 kernel debugger). + + However, in many cases, bottlenecks do not occur when integrating individual + sub systems but after integrating multiple of such subsystems into a large + application scenario. For such scenarios, existing debugging methodologies do + not scale. A tool is desired that is able to capture the relationships + between processes of a potentially large process hierarchy, to display + communication and control flows between those processes, and to visualize the + interaction of threads with the kernel's scheduler. + + Since Qt4 is available natively on Genode, the creation of both offline and + on-target analysis tools has become feasible. The first step of this project + is creating an interactive on-target tool, that displays the interaction + of communicating threads as captured on the running system. The tool should + work on a selected kernel that provides a facility for tracing IPC messages. + + +Application frameworks +###################### + +:Running the Meego application stack on Genode using Qt4: + + With Genode 11.02, Qt4 4.7.1 has become available. The most prominent feature + of this version is the new QML language to design GUIs using a declarative + language. This technique is targeted specifically to mobile applications and + other touch-based devices. The goal of this project is to run the Meego + application stack natively on Genode. First, the software components and + Meego-specific Linux customizations must be identified. For each such + component, it must be decided whether to port its code or to reimplement its + interface. The immediate goal of the first step is running one Meego example + application natively on Genode. + +:Python Qt4 bindings: + + With the Python interpreter and the port of the Qt4 framework, the principle + components for Python-based GUIs on Genode are available. However, the glue + between both components is missing. The incentive of this work is supplementing + our Python port with the modules needed for real applications and porting the + Qt4 bindings to Genode. This would bring Genode one step closer to executing + modern Python-based GUI applications (in particular KDE4 applications). + +:Evaluation of porting GTK+ to Genode: + + With Qt4, we have demonstrated the feasibility to run a highly-complex + application framework via Genode on a wide range of microkernels. That leaves + the question of looking into the other major toolkit in town, namely GTK+ as + used by Firefox and the Gnome desktop. + +:Cairographics: + + Cairo is a high-quality 2D vector graphics engine used by a large number of + open-source projects, in particular GTK+. Hence the port of Cairo is a + prerequisite for the GTK+ challenge. In addition, it would enable the + use of further libraries such as Poppler. + + +Device drivers +############## + +:Enhancing Gallium3D support: + + Genode 10.08 introduced Gallium3D including the GPU driver for Intel GMA + CPUs. With this initial version, we demonstrated that the powerful software + stack for running hardware-accelerated 3D applications can be deployed on + Genode. At the same time, it motivates us to reach out for even more + ambitious goals: + + First, the current approach executes the GPU driver alongside the complete + Gallium3D software stack and the application code in one address space. To + enable the use of multiple hardware-accelerated applications running at the + same time, the GPU driver must run separated from the Gallium3D code as done + on Linux. The preliminary interfaces for this decomposition are already in + place but there are several open questions. Most importantly, the page-fault + handling of buffer objects mapped in the application's address space. + + Second, we'd like to complement our current Intel GMA GPU driver with + interrupt-based synchronization, namely vblank handling. This requires an + understanding of the Intel GMA interrupt code and the enhancement of our + driver environment. + + Third, we desire the use of further Gallium3D drivers, in particular the + Nouveau and r300 drivers. The basic approach to bring these drivers to Genode + is the same as for Intel GMA but the respective driver environments are yet + to be developed. + + If you are interested in low-level graphics hacking, GPUs, and + high-performance graphics, this project is ideal to get you on track. + +:Split USB core from USB device drivers: + + Genode's current USB support is based on the Linux USB stack running as a + single process on Genode. This process includes the USB core logic, USB host + controller driver as well as the USB device drivers such as HID or USB + storage. This monolithic USB process is rather inflexible. Hence, we desire a + decomposition of this solution such that the USB host driver and each USB + device driver runs in a separate process. + +:IOMMU support on the NOVA Hypervisor: + + The NOVA hypervisor is the first open-source microkernel with thorough + support for IOMMUs, which principally enables the use of untrusted device + drivers alongside sensitive software on one machine. Without an IOMMU, each + device driver for a device that operates with DMA, is able to indirectly + access the whole physical memory through programming the device. With IOMMU, + the physical memory addressable by DMA operations can be restrained per + device. The goal of this challenge is to enhance Genode with I/O protection + when running on the NOVA kernel. This would clear the way towards reusing + complex untrusted device drivers running in dedicated device-driver OS + instances. + +:I/O Kit: + + I/O Kit is the device-driver framework as used by the Darwin operating + system, which forms the basis for Mac OS X. The port of I/O Kit would enable + the easy re-use of the library of I/O-Kit-based device drivers on Genode. As + foundation of this project, we recommend to use the DDE Kit API featured by + Genode. + +:Support for multi-touch input devices: + + The efforts towards enabling mobile application stacks such as Meego and + Android on Genode must be accompanied by a revision of Genode's 'Input' + session interface to accommodate multi-touch input devices. First, existing + APIs such as multi-touch support in X11, Qt4, and Android should be analysed. + Based on these findings, we expect a proposal for changing Genode's input + interface. The interface extension should be validated by a example driver + implementing the interface as well as an example applications. + + +System services +############### + +:Copy-on-write memory manager: + + Genode's managed dataspaces provide a generalized page-table concept, + enabling servers to provide on-demand paged memory objects (dataspaces) to + clients. This concept is showcased by the ISO9660 driver, which provides + on-demand paged ROM dataspaces to its clients. Depending on the access + pattern of the client, the ISO9660 server loads the used parts of the ROM + file from CDROM. Managed dataspaces principally allow for a wide variety of + interesting applications such as the transparent migration of non-local and + local memory in a NUMA system, sparse dataspaces, swapping, and copy-on-write + dataspaces. The goal of this project is a dataspace manager that implements + copy-on-write semantics combined with a merging technique optimizing the + memory footprint at runtime. Pages of two managed dataspaces that share the + same content should be provided via read-only page sharing. If one client + attempts to change the content of a shared page, a new physical copy of the + page get created. Vice versa, if the content of different pages converge, the + sharing should be re-established. This work is a follow-up of the diploma + thesis of Sebastian Sumpf + [http://os.inf.tu-dresden.de/papers_ps/sumpf-diplom.pdf - Cloning L4Linux]. + On the course of this project, the managed dataspace concept of Genode + will be refined, in particular regarding the creation of read-only + dataspaces from read-write dataspaces. + +:Using Haskell as systems-development language: + + The goal of this project is the application of functional programming + i.e., Haskell, for the implementation of low-level Genode components. + Implementing critical functionalities in such a high-level language instead + of a classical systems language such as C or C++ would pave the way towards + analyzing such components with formal methods. + + The use of Haskell for systems development was pioneered by the + [http://programatica.cs.pdx.edu/House/ - House Project]. A more recent + development is [http://halvm.org - HalVM] - a light-weight OS runtime for + Xen that is based on Haskell. + +:Dbus emulation: + + Dbus is a popular inter-process communication mechanism on Linux, which + enables user applications to respond to global system events and announce + state changes to other applications. It is extensively used by modern desktop + environments. To enable such applications to integrate well with Genode, a + Dbus emulation solution has to be developed. + +:Wayland: + + With the availability of Gallium3D on Genode, the prospect for incorporating + further projects of the Linux graphics ecosystem into Genode arises. + [http://wayland.freedesktop.org - Wayland] is a window server especially + designed to be used with Gallium3D. Its design has many similarities with + Genode's Nitpicker GUI server, in particular the decision to move window + handling policies to the client and thereby minimize the complexity of the + GUI server. Whereas Nitpicker was designed for high security, Wayland is + targeted to creating GUIs with fluid and tearless animations using + hardware-accelerated graphics. We believe that because of the many conceptual + parallels with Nitpicker, Wayland would fit very well into the Genode system. + However, as a prerequisite for this project, Genode's Gallium3D support must + be decomposed first. See the challenges regarding our Gallium3D support for + further information. + + +Runtime environments +#################### + +:Android's Dalvik VM natively on Genode: + + Dalvik is a Java virtual machine that is used for executing applications on + Android. By running Dalvik directly on Genode, the Linux kernel could be + removed from the trusted computing base of Android, facilitating the use of + this mobile OS in high-assurance settings. + +:Vancouver VMM for Genode on the NOVA hypervisor: + + Vancouver is the user-level virtual-machine monitor accompanying the NOVA + hypervisor. It combines a VT-based CPU virtualization with a rich set of + device models to run unmodified guest operating systems at near-native + performance. Since NOVA is a supported base platform of Genode, running + Vancouver in the dynamic Genode environment has become feasible. By running + Vancouver on Genode instead of NOVA's original static userland would open up + new use cases where the combination of faithful virtualization with dynamic + applications is desired. + + Genode 11.11 introduced the initial integration of Vancouver into Genode. + This version of Vancouver is able to bootstrap another kernel (e.g., + Fiasco.OC) within the virtual machine. However, several pieces are missing + for reaching the goal of running a fully-fledged Linux OS as guest. + +:Runtime for the D programming language: + + The D systems programming language was designed to overcome many gripes that + exists with C++. In particular, it introduces a sane syntax for meta + programming, supports unit tests, and contract-based programming. These + features make D a compelling language to explore when implementing OS + components. Even though D is a compiled language, it comes with a runtime + providing support for exception handling and garbage collection. The goal of + the project is to explore the use of D for Genode programs, porting the + runtime to Genode, adapting the Genode build system to accommodate D + programs, and interfacing D programs with other Genode components written in + C++. + + +Platforms +######### + +:Evaluation of MP scheduling models on different Genode base platforms: + + Several of Genode's supported base platforms come with multi-processor + support, i.e., Linux, NOVA, L4ka::Pistachio, Codezero, and Fiasco.OC. Each of + these kernels follows a different approach for utilizing multiple CPUs. For + example, Linux and Codezero manage the association of threads with CPUs + largely transparent for user-level programs. In contrast, NOVA makes the use + of multiple CPUs explicit and constraints the modes of IPC interaction of + threads running on different CPUs. Furthermore, kernels differ with regard to + thread migration and scheduling. The goal of this project is to identify ways + to support the SMP features of the respective kernels at Genode's API level + such that SMP can be easily utilized by Genode programs in a largely kernel + agnostic way. + +:Microkernelizing Linux: + + Thanks to Genode's generic interfaces for I/O access as provided by core, all + Genode device drivers including drivers ported from Linux and gPXE can be + executed as user-level components on all supported microkernels. However, so + far, we have not enabled the use of these device drivers on Linux as base + platform. The goal of this project is the systematic replacement of in-kernel + Linux device drivers by Genode processes running in user space, effectively + reducing the Linux kernel to a runtime for Genode's core process. But moving + drivers to Genode processes is just the beginning. By employing further + Genode functionality such as its native GUI, lwIP, and Noux, many protocol + stacks can effectively be removed from the Linux kernel. + + The goal of this project is to evaluate how small the Linux kernel can get + when used as a microkernel. + +:Support for the Genode FPGA Graphics SoC platform: + + With Genode 11.02, we introduced the first version of native support for the + MicroBlaze softcore CPU. With this foundation laid, we can proceed with + bringing GUI-based interactive Genode applications to FPGA-based SoC + platforms. As target SoC design, we aspire to use the open-source IP cores + provided by the + [http://genode-labs.com/products/fpga-graphics - Genode FPGA graphics project]. + +:Support for the HelenOS/Spark kernel: + + [http://www.helenos.org - HelenOS] is a microkernel-based multi-server OS + developed at the university of Prague. It is based on the Spark microkernel, + which runs on a wide variety of CPU architectures including Sparc, MIPS, and + PowerPC. This broad platform support makes Spark an interesting kernel to + look at alone. But a further motivation is the fact that Spark does not + follow the classical L4 road, providing a kernel API that comes with an own + terminology and different kernel primitives. This makes the mapping of + Spark's kernel API to Genode a challenging endeavour and would provide us + with feedback regarding the universality of Genode's internal interfaces. + Finally, this project has the potential to ignite a further collaboration + between the HelenOS and Genode communities. + +:Support for the seL4 kernel: + + The seL4 kernel developed by NICTA and OK-Labs is the first formally verified + microkernel. It runs on the x86 and ARM architectures and supports the + execution of a paravirtualized version of Linux on top. Even though seL4 is + proprietary technology, a free binary release and the specification of the + kernel API has been published early 2011. Being a capability-based kernel, + seL4 is in the line of the current-generation L4 kernels alongside NOVA and + Fiasco.OC. Genode already supports the latter two kernel, which hints at the + feasibility to support seL4 as well. Currently, the seL4 kernel comes with a + rather static user land, which is far from utilizing the full potential of + the kernel with regard to dynamic resource management. By adapting Genode to + seL4, a rich dynamic application workload would become available to this + kernel, which could potentially spawn interest in extending the formal + verification efforts at NICTA to the Genode system executing dynamic + real-world applications. + +:Support for the Barrelfish kernel: + + [http://barrelfish.org - `Barrelfish] is a so-called multi-kernel OS designed + for heterogeneous multi-processor systems. At its heart, it is a + microkernel-based multi-server OS. Its kernel provides different mechanisms + than L4-based kernels. Instead of managing threads in the kernel, there is a + mechanism for implementing preemptive multi-threading at user level. + Consequently, inter-process communication does not address threads but + protection domains. This makes the Barrelfish kernel a very interesting and + challenging target for running Genode. + +:Support for the XNU kernel (Darwin): + + XNU is the kernel used by Darwin and Mac OS X. It is derived from the + MACH microkernel and extended with a UNIX-like syscall API. Because the + kernel is used for Mac OS X, it could represent an industry-strength + base platform for Genode supporting all CPU features as used by Mac OS X. + +:Xen as kernel for Genode: + Using Xen as kernel for Genode would clear the way to remove the + overly complex Linux OS from the trusted computing base of Xen + guests OSes. + + Xen is a hypervisor that can host multiple virtual machines on one physical + machine. For driving physical devices and for virtual-machine management, Xen + relies on a privileged guest OS called Dom0. Currently, Linux is the + predominant choice to be used as Dom0, which implicates a trusted computing + base of millions of lines of code for the other guest OSes. + + Even though Xen was designed as hypervisor, a thorough analysis done by Julian + Stecklina concludes that Xen qualifies well as a kernel for Genode. For + example, Julian implemented a version of Genode's IPC framework that utilizes + Xen's communication mechanisms (event channels and shared memory). + +:Linux process containers for supporting Genode`s resource trading: + + Even though the Linux version of Genode is primarily meant as a development + platform, there exist interesting opportunities to explore when combining + Genode with Linux, in particular Linux' process containers. + Linux process containers provide a mechanism to partition physical resources, + foremost CPU time, between Linux processes. This raises the interesting + question of whether this mechanism could be used for a proper implementation + of Genode's resource trading on Linux. + [http://lwn.net/Articles/236038/ - Process containers introduction...] + + +Optimizations +############# + +:Low-latency audio streaming: + + Genode comes with an audio streaming interface called 'Audio_out' session. + It is based on a shared-memory packet stream accompanied with asynchronous + data-flow signals. For real-time audio processing involving chains of Genode + components, streams of audio data must be carried at low latency, imposing + constraints to buffer sizes and the modes of operation of the audio mixer and + audio drivers. The goal of this project is to create a holistic design of the + whole chain of audio processing, taking thread-scheduling into account. A + particular challenge is the mixed output of real-time (small buffer, low + latency) and non-real-time (larger buffer to compensate jitter, higher + latency) audio sources. + +:De-privileging the VESA graphics driver: + + The VESA graphics driver executes the graphics initialization code provided + by the graphics card via an x86 emulator. To initialize a graphics mode, this + code needs to access device hardware. Currently, we permit access to all + device registers requested by the graphics-card's code. These devices include + the system timer, the PCI configuration registers, and the interrupt + controller, which are critical for the proper operating of the kernel. The + goal of this work is to restrict the permissions of the VESA driver to a + minimum by virtualizing all devices but the actual graphics card. + diff --git a/doc/contributions.txt b/doc/contributions.txt new file mode 100644 index 0000000000..cd2f63825e --- /dev/null +++ b/doc/contributions.txt @@ -0,0 +1,63 @@ + + ====================== + Contributing to Genode + ====================== + + +If you like to improve Genode in any way, you're more than welcome to +contribute. A collection of ideas to enhance the current implementation can be +found at the [http:/about/challenges - Challenges] page. + +Genode is publicly licensed under the terms of the GNU GPL with Genode Labs +maintaining the right to also distribute derivates to customers under +negotiated licenses. [http:/about/licenses - Read more] about Genode Labs' +dual-licensing business model. Contributions from outside Genode Labs can only +be incorporated into Genode's mainline development if each individual +contributor expliticly grants the permission to redistribute his contributions +under non-GPL licenses. This can be done in two ways: + +# If you are planning a continuous involvement with the Genode development, + we recommend you to fill out and sign the + [http:gca.pdf - Genode Contributor's Agreement] (GCA). The GCA enables Genode + Labs to license Genode (including your contributions) under other licenses + than the GPL. The signed GCA covers all your future contributions. + +# Alternatively, if you don't want to sign the GCA, you may submit + your contributions under the [http:mit_license - MIT License]. This + license is liberal and permits Genode Labs to use your contributions + in open and closed-source projects. + +The major difference between both variants (and maybe an advantage of the GCA +for you) is: The GCA permits only Genode Labs to relicense your contributions +whereas the MIT license effectively puts your code into the public domain. + + +Development for Genode +###################### + +The Genode source code is available via file releases and a public source-code +repository (see the [http:/download - Download section] for details). Genode +Labs update the sources (incorporating community contributions) and announce +new Genode releases. Therefore, the source-code repository is not meant for +active development but for convenient source-code update and tracking of +changes between releases. + +The advantage of this approach is that only code that meets Genode Labs's +quality measures (tests, stability) becomes part of an official Genode release. +The second (more legal) argument is that Genode Labs is obliged to ensure all +contributions fit our dual-licensing model. + + +Submission of your contribution +############################### + +As soon as you developed a patch you regard valuable to share with the +community, submit it for incorporation. First, decide which of the above +contribution licensing variants fits your needs best. Then, accompany your +patch with a proper description of its changes and send it to the 'genode-main' +mailing list. Depending on your chosen licensing variant, you may have to state +that your source code is licensed under the MIT license. + +Please, follow the developer discussion and possibly improve your patch. The +integration into Genode may take some time for review and testing at Genode +Labs. diff --git a/doc/future_optimizations.txt b/doc/future_optimizations.txt deleted file mode 100644 index 86c74cdeed..0000000000 --- a/doc/future_optimizations.txt +++ /dev/null @@ -1,68 +0,0 @@ - - Future optimizations of Genode - - Norman Feske - -Abstract -######## - -This document outlines possible optimizations for Genode. -In the first place, Genode was meant as a feasibility study. -Therefore, optimizing performance and memory-consumption was -not a primary goal of the experiment. However, there exist -several ideas to improve these properties. These ideas are -definitely not to be regarded as ToDo items. Each idea should -only be conducted if it fixes a _real_ hotspot in the system -that was found by quantitative analysis. - - -Memory consumption -################## - -Currently, we use an AVL-tree-based best-fit memory allocator -('Allocator_avl') as Heap. Despite, this allocator was -intended to be used only for the root allocator for physical -memory inside Core, we use it as the basis for the current -heap implementation. This way, we can reuse the code, -reducing the overall code complexity. - -The AVL-tree-based allocator uses a meta-data entry of 32 -bytes per free or used memory block. This means that each -memory allocation from the heap introduces a meta-data -overhead of 32 up to 64 bytes. When allocating a lot of -small objects, this overhead is very high. - -:Question:: Is this issue a real bottleneck? - -Possible improvements are: - -* Using slab allocators for known allocation sizes. - Slab entries have a much smaller footprint. -* Creating a list-based allocator implementation for - the heap. This comes at the cost of additional - code complexity. - - -RPC Performance -############### - -We use C++ streams for RPC communication and therefore, -introduced run-time overhead for the dynamic marshaling. -Using an IDL compiler would improve the RPC performance. -Is the RPC performance a real performance problem? What -is the profile of RPC usage? (Number of RPCs per second, -Percentage of CPU time spent on RPCs, Secondary effects -for RPCs such as cache and TLB pollution). - - -Locking -####### - -On L4v2-Genode, locking is implemented via yielding spin locks. -We may consider a L4env-like lock implementation. - - -Misc -#### - -Take a look at include/util/string.h and judge by yourself :-) diff --git a/doc/news.txt b/doc/news.txt new file mode 100644 index 0000000000..157a2f4b70 --- /dev/null +++ b/doc/news.txt @@ -0,0 +1,964 @@ + + =========== + Genode News + =========== + + +New issue tracker at Github +########################### + +| To promote open development, the new issue tracker replaces both the public +| tracker at Sourceforge and the tracker formerly internal to Genode Labs. + +As promised earlier, Genode has got a new issue tracker at Github: + +:[http://github.com/genodelabs/genode/issues]: + +Please use this tracker to report and discuss Genode-related issues from now +on. The old public tracker at Sourceforge is still there but all issues have +been either closed or migrated to Github. + + +Steps towards an open development process | 2011-12-05 +###################################################### + +| Genode is going to embrace an open and transparent development process. + +Posted by Norman Feske at the Genode mailing list: + +Over the past four years, the Genode OS Framework has seen rapid progress. +Skimming over the release notes of the past releases makes me very proud. It is +clear that the project's development is going stronger than ever. However, at +the same time, I recognise that progress on a technical level is only one part +of a successful Open-Source project. A certainly even more important part is +the participation of a diverse community. This is where our project is vastly +underdeveloped. By continuing the development at status quo, Genode will +continue to steadily improve but it will not be able to capture a significant +position in the operating-systems world. Instead, it will possibly remain a +curiosity. Therefore, we Genode developers regard the transition of our work to +an open and transparent development process as the next big challenge we want +to tackle. + +Review of the situation +======================= + +Even though Genode is an Open-Source project, its development has been pursued +largely behind the closed doors of our company Genode Labs. The planning of the +road map, most technical discussions, issue tracking, and revision management +are used to be done within the company. There had been two reasons for this +policy namely the preservation of exclusivity and the efficiency of +coordination. + +Regarding the first reason, when we started our business, we desired to +preserve a certain degree of competitive advantage to ourselves by keeping some +information "protected" from the public eye. For example, revealing the +detailed history of the over 5000 source-code revisions of the project would +enable any outsider or competitor to deeply analyze the way of how our company +works. These concerns had been acknowledged by other startup companies with +statements in the line of "Open-Source has hurt our business". + +The second reason is the way of how humans intuitively work together in a +non-distributed environment such as a our small company. Instead of discussing +technical matters on a mailing list, it appears to be much easier and +presumably more efficient to engage in face-to-face conversations. The writeup +of our releases notes at regular intervals served us as an instrument to +recapture the rationale behind our discussions and document it. This worked +exceedingly well. In comparison, discussing every detail on a mailing list +seems to be inconvenient. + +Why do we desire a change? +========================== + +The answer to this question can be put quite simply as "to make the project +relevant". But it goes deeper than that. First, we see ourself as Free-Software +AND Open-Source advocates. I wholeheartedly disagree with statements that +suggest that Open Source is incompatible with having a business. For us, the +contrary is true. Without Free and Open-Source Software, there would be no +Genode Labs. The great wealth of the GNU software stack forms the basis of all +the tools we use every day and it plays a significant role for our passion to +develop software. Furthermore, Genode would not be of much value without all +the great building blocks in the form of existing Open-Source code that we +reuse in our context. Hence, it is our personal desire to contribute to the +Free and Open-Source software world and to intensify the collaboration with +other projects with the same spirit. + +We still see the preservation of a certain degree of exclusivity as important +for our dual-licensing business model. If we made Genode available under the +BSD license, there would be not point in pursuing this model. However, hiding +the development process from the public is not only poor-spirited but it +creates an artificial barrier for people who want to participate. The book +"Producing Open Source Software" (http://producingoss.com) by Karl Fogel was an +eye opener to us. + +Regarding the efficiency of collaboration, I have to admit that the statement +above about how great the current way works is really not well-founded - simply +because we haven't tried the alternative to discuss everything in public, yet. +Obviously, we are risking to spoil our presumed efficiency by changing the mode +of collaboration. On the other hand, by documenting the process of solving each +problem in the form of public mailing-list postings, we give everyone the +chance to contribute to and to learn from our findings. + +The next steps +============== + +We take the current release cycle as opportunity to execute our plan to open +the development process. Our coarse schedule is to migrate our internal issue +tracker to the public until mid of December. From this day on, all issues will +be tracked publicly. The place for all technical discussions will be the Genode +mailing list. Until mid of January, we will prepare a new public source-code +tree in the form of a Git repository that we will then use as mainline +development tree. + +As a further change of policy, we plan to include all documentation as found on +the website in the mainline repository and remove the Wiki. This way, +contributions to the documentation will be handled in the same way as code +contributions. + +I hope that our designated change is in the interest of all of you and I look +forward to see how it will impact the further progress of Genode. + +Best regards + +Norman + + +Genode OS Framework release 11.11 | 2011-11-29 +############################################## + +| With version 11.11, we explore a plethora of options of combining Genode with +| virtualization techniques. + +The overall theme of Genode 11.11 is the exploration of various levels of +virtualization, ranging from faithful virtualization, over paravirtualized +Linux, to custom variants of OS-level and application-level virtualization. The +latter approach is particularly related to Genode and provides us with a novel +approach to user-level debugging. + +Each of the experiments were conducted with concrete goals. The goal for +enabling faithful virtualization was to integrate the high-performance +Vancouver virtual machine monitor (VMM) into Genode. This VMM implementation +used to be tied to a NOVA-specific user land. With Genode 11.11, it becomes +apparent how this virtualization technology and Genode's component framework +can cross-fertilize. + +Our work on paravirtualized Linux was motivated by the goal to execute Android +as a node in Genode's process tree. Based on the L4Android project and L4Linux, +our work comprised the implementation of Genode-specific stub drivers for +L4Linux. This way, L4Linux can be tightly integrated with Genode interfaces for +block devices, framebuffer, input, UART, and network. + +With Noux, Genode brings along a custom OS-level virtualization approach aiming +at the execution of unmodified command-line based GNU software on Genode. The +immediate goal for this release was to develop Noux to a level that enables us +to run VIM as Genode sub system. This work involved extending the Noux runtime +as well as creating a terminal emulator. + +For the highest abstraction level of virtualization on Genode, we coined the +term application-level virtualization. Enabled by the sandboxing inherent to +Genode's architecture, we implemented a solution for user-level debugging via +the GNU debugger. The solution fits perfectly with the Genode architecture and +provides powerful debugging facilities without compromizing the security of the +system. + +[ title="Release notes for the Genode OS Framework 11.11" + +To learn more about those and many other improvements, please read on the +[http:/documentation/release-notes/11.11 - release notes of version 11.11...] + + +Android on top of Genode | 2011-09-27 +##################################### + +| With the new support for L4Android, the Android software stack can be used as +| Genode sub system. + +As of today, Google's Android OS is apparently one of the hottest topics in the +world of smartphones and tablets. Among the users of Genode, we recognise a +general interest in combining the framework with the Android platform. With L4Android there already +exists a special variant of the L4Linux kernel that is able execute the Android +software stack on top of the Fiasco.OC kernel. + +Our port of L4Linux to Genode in May has shown that L4Linux works well with +Genode. Since L4Android is derived from L4Linux, we were confident that we +could adapt L4LAndroid to Genode in a similar way. We are happy to report that +this feature has now become available at our subversion repository. With the +new support of L4Android on Genode, Android can be used on Genode on the +Fiasco.OC kernel on the IA32 architecture. For those of you who are eager to +experiment with L4Android on Genode, please find further information at the +top-level +[http://genode.svn.sourceforge.net/viewvc/genode/trunk/ports-foc/README - README] +file of the 'ports-foc' repository and share your results with us at the +[http:/community/mailing-lists - Genode mailing list]. + + +Genode OS Framework release 11.08 | 2011-08-17 +############################################## + +| Version 11.08 introduces a unified workflow for dealing with all microkernels +| supported by the framework. This way, application scenarios can be ported +| from one kernel to another in an instant. + +The Genode OS Framework aspires to provide a common ground for creating +microkernel-based operating systems, relieving developers from wasting efforts +in duplicating other people's work such as implementing basic device drivers, +tools, and application runtimes. Because in the microkernel domain, each +development poses different requirements, there is no single microkernel that +fits all purposes. Instead, there exist a plethora of different kernels, each +focused on different use cases. By supporting as many as 8 different kernels at +API level, Genode allows users of the framework to develop an application once +while preserving the freedom to pick the kernel that fits best with the use +case at hand. Still, each kernel uses to come with different tools, +configuration mechanisms, and boot concepts. Even though Genode programs can be +developed in a kernel-independent way, the deployment of such programs still +required profound insights into the peculiarities of the respective kernel. The +new version 11.08 of the framework addresses these concerns by providing a +unified workflow for all supported kernels. Downloading and using a different +kernel has become a matter of a few minutes and requires no prior knowledge +about the kernel. + +In addition to the new tooling support, the current release advances the +framework's block-device infrastructure and extends the support for ARM +platforms. There are several new drivers for peripheral devices such as AHCI, +SD-card, and IDE, a new block-partition service, and libc support for accessing +VFAT partitions. The ARM support has been extended to cover both L4Linux (on +Fiasco.OC) and Qt4 (ARMv6, ARMv7). Furthermore, the new version is accompanied +with a comprehensive documentation update. + +Read [http:documentation/release-notes/11.08 - the full story] +about the various improvements that come with the version 11.08... + + +Genode OS Framework release 11.05 | 2011-05-26 +############################################## + +| The Genode version 11.05 advances the Fiasco.OC platform support to the same +| level as the other fully-featured base platforms, enables the use of L4Linux +| with Genode, and introduces a brand new API for inter-process procedure calls. + +Fiasco.OC is a modern microkernel developed at the OS Group of the University +of Technology Dresden. It is highly regarded for two reasons, its comprehensive +support for different CPU architectures and the user-level variant of the Linux +kernel called L4Linux. Now, those advantages have become available to the users +of Genode. Thereby, new usage scenarios can be realized by combining the +L4Linux virtualization solution with Genode's rich set of components such as +Qt4, lwIP, and a growing number of device drivers. + +Our custom kernel implementation for MicroBlaze-based SoCs has undergone a +major upgrade to enable the implementation of user-level device drivers. To +make this platform easy to explore, the release is accompanied with a reference +SoC that is ready-to-use on the Xilinx Spartan3A Starter Kit. + +The most significant API-related change of the framework is a brand new API for +implementing remote procedure calls across process boundaries. The new RPC API +takes our experience during last 5 years of Genode development into +consideration and alleviates long standing shortcomings of the original +inter-process communication API. + +To pave the way towards the use of Genode for productive use, we have started +to explore ways to make standard debugging solutions available to Genode. Our +new GDB monitor implementation speaks the GDB protocol over TCP/IP and thereby +enables the GNU debugger to inspect a user-level Genode process via a remote +connection. + +Read the complete story about these and many more changes in the +[http:/documentation/release-notes/11.05 - release notes of version 11.05...] + + +Exciting challenges ahead | 2011-03-24 +###################################### + +| Explore more than 30 new Genode-related project proposals at our challenges +| wiki page + +With each new Genode release, the scope of feasible use cases for the framework +grows and motivates us to reach out for new ambitious goals. There is a +dedicated [http:/community/wiki/Challenges - Wiki page] for collecting those +ideas. After having released the version 11.02 of the framework, we took the +chance to reiterate the many ideas that popped up recently, ideas ranging from +the support of diverse potential base platforms, over creative combinations of +Genode with other Open-Source projects, to novel tools and applications. + +So if you are curious about what kinds of projects we have in mind in the mid +term, have fun browsing through the project proposals. If one of these topics +catches your interest, we'd be happy about you joining in with the development +or discussing those ideas at our [http:/community/mailing-lists - mailing list]. +Also, if you have additional ideas, please do not hesitate to tell us more. + +Discover the Wiki page about our +[http:/community/wiki/Challenges - future challenges...] + + +Norman Feske introduces Genode on YouTube | 2011-03-10 +###################################################### + +| Bas de Lange has published the footage of Norman Feske's talk at the Software +| Freedom Day 2010 in Amsterdam + +In his talk, Norman Feske sheds light on the background behind the company +Genode Labs, introduces the Genode OS architecture, and demonstrates the +concepts live. The talk was recorded at the +[http://www.softwarefreedomday.eu - Software Freedom Day 2010] event in +Amsterdam. Thanks to Bas the Lange for publishing the material. + +: +: +: +: +: +: +: + +[http://www.youtube.com/watch?v=Z1IMV3FJO7Q - Visit the YouTube page...] + + +Genode OS Framework release 11.02 | 2011-02-24 +############################################## + +| Version 11.02 of the framework adds support for the Fiasco.OC and NOVA v0.3 +| kernels as well as a new custom kernel platform targeted at softcore CPUs. +| Furthermore, we introduce the Noux execution environment for using GNU +| software natively on Genode. + +The Genode project takes another leap forward regarding the use of different +kernels as base platforms for using the framework. The new supported Fiasco.OC +kernel offers a rich feature set that is unmatched by any other open-source +microkernel. It works with the x86_32, x86_64, and ARM architectures, features +capability-based security, scales to multiple CPUs, and provides special +optimizations for running virtualized operating systems on top. Genode can now +leverage the advanced features of this kernel, in particular those related to +enforcing strict security policies. + +With NOVA and Fiasco.OC, there have now become two kernels available that are +capable of enforcing Genode's security architecture at kernel level. Speaking +of NOVA, we are happy to report to have upgraded Genode's NOVA support to +version 0.3 of the kernel. This version was released earlier this month and +brings many of the features we desired, the most important being the revocation +of resources. With the new version, NOVA has now become a base platforms that +supports the entire Genode API without compromises. + +In addition to broadening the support for existing kernels, we have started to +reach out into kernel land for running Genode on softcore CPU as found in +FPGA-based SoCs. Our custom kernel architecture achieves a further reduction of +TCB complexity by consolidating kernel functionality with Genode's user-level +core. The current implementation is able to run core and multiple instances of +nested init processes on the Xilinx MicroBlaze CPU. + +The most significant functional addition to the framework is a new execution +environment called Noux that enables running unmodified GNU software on top of +Genode. Even though in an early stage, Noux is already able to execute GNU +coreutils without requiring manual porting work. + +Read on about further details regarding the new kernel platforms, the vision +behind Noux, and many more improvements of the framework in the +[http:/documentation/release-notes/11.02 - release notes of version 11.02]. + + +Genode OS walk-through on YouTube | 2010-12-22 +############################################## + +| Check out our new screencast presenting the Genode Live CD 10.11. + +For those of you who like to get a glimpse of our recently released +Live CD but hesitate to download and boot the ISO image, we have +prepared the following screencast with a guided walk-through. Enjoy! + + +: +: +: +: +: +: +: + +[http://www.youtube.com/watch?v=CJdWOmajo_8 - Visit the YouTube page...] + +[http:/download/live-cds - Download the real thing...] + + +Genode OS Framework release 10.11 | 2010-11-30 +############################################## + +| With version 10.11, Genode has become able to run network drivers of the gPXE +| project, employ user-level on-demand paging, and use advanced graphics with +| the nitpicker GUI server. + +With the [http:/download/live-cds - recently published Live CD], the Genode +project has reached a new stage by integrating advanced device drivers, complex +protocol stacks, and real-world applications into one dynamic setup. The new +Genode release 10.11 bears fruit of the intensive effort that went into this +important milestone. There are improvements and functional additions all over +the code base. To highlight a few, we enhanced the Nitpicker GUI server to +support alpha blending, added an execution environment for running network +drivers of the gPXE project, completed the implementation of Genode's concept +for user-level page-fault handling, and further advanced the integration of the +paravirtualized Linux kernel with Genode's native interfaces for networking, +block-device access, graphics, and audio. + +Furthermore, the release comes with a number of new components such as a +virtual network bridge and a http-based block server, which can be combined +with the existing components to open up new use cases of the framework. + +Please enjoy the [http:/documentation/release-notes/10.11 - full description] +of all the improvements that come with version 10.11. + + +Genode Live Demonstration 2010-11 | 2010-11-16 +############################################## + +| The new Genode Live CD showcases the vast functional progress during the past +| year in a selection of five demos ranging from native Qt4/Webkit support to +| hardware-accelerated 3D graphics. + +Since the release of the previous Genode Live CD in September 2009, we focused +our development work on supporting native Qt4/Webkit applications, user-level +Linux, sound support, Mesa/Gallium3D, block drivers, and a networking stack. +Furthermore, we paid special attention to tightly integrate existing software +with native Genode features. Two prominent examples are the seamless +integration of a virtualized Linux desktop and the support for running complete +Genode subsystems as plugin in the Arora web browser. In response to several +requests to complement our regular source-code releases with a new bootable +live CD, we have now published a new version. + +You can now test drive the current version of Genode on your PC (or virtual +machine) to get an idea about where the development of the framework is +heading. + +[http:/download/live-cds - Download the new live CD] +featuring five setups showcasing our efforts of the past year. + + +Genode OS Framework release 10.08 | 2010-08-11 +############################################## + +| With Gallium3D, MadWifi, and a new block-driver infrastructure, the release +| 10.08 takes Genode's device-driver support to the next level. + +Wireless networking and hardware-accelerated graphics are commonly regarded as +two of the most sophisticated domains when it comes to device-driver support in +operating systems. We are proud to have taken the challenge to support these +device classes in the Genode OS Framework. The just released version 10.08 +comes with support for the Gallium3D software stack alongside the Intel +graphics execution manager, which enables Genode applications to perform +hardware-accelerated 3D graphics on Intel GMA platforms. Our port of the +MadWifi wireless stack pushes the limits of what can be done with our Linux +device-driver environment. Furthermore, we extended our device-driver-related +activities to block devices, resulting in a new block-device interface and an +ATAPI driver accompanied with an ISO 9660 file system. Apart from device +drivers, there are numerous other improvements such as the upgrade to Qt4.6.3 +and support for dynamic linking on platforms using ARM EABI. + +Please find more in-depth information in the detailed +[http:/documentation/release-notes/10.08 - release notes of version 10.08...]. + + +Genode OS Framework release 10.05 | 2010-05-27 +############################################## + +| The new version 10.05 adds support for mandatory access-control policies, +| introduces audio playback, and improves the integration of the paravirtualized +| OKLinux kernel with the framework. + +With the current release, we focused on functionality to broaden the +application area of the framework. The infrastructure of the framework has +advanced to a point that allows running a steadily growing number of typical +general-purpose applications directly on Genode. This is best illustrated by +the fully functional Arora web browser running as a native Genode process. +Still, there are a large number of usage scenarios that rely on Linux +applications. For this reason, we further improved the integration of the +paravirtualized OKLinux kernel with Genode. The new version adds support for +seamlessly integrating the X Window System running on OKLinux with the native +nitpicker GUI. For Genode developers, there is a new build system, which +significantly improves the build performance on multi-processor systems. + +Read on about these and many more improvements detailed in the +[http:/documentation/release-notes/10.05 - release notes of version 10.05...] + + +Adaptation to Codezero kernel v0.3 | 2010-04-06 +############################################### + +| The just released version 0.3 of the Codezero kernel adds support for the +| latest ARMv7 CPUs. The Genode OS Framework is now ready to be used with this +| new kernel version. + +Since version 10.02, the Genode OS Framework officially supports the version +0.2 of the [http://l4dev.org - Codezero microkernel] developed by +[http://b-labs.com - B-Labs]. The road map of this kernel promised +support for the latest ARM CPU cores. With the just released version 0.3, which +added support for ARMv7 CPU cores, the project lives up to this promise. In +addition to the extended CPU support, the new release adds important +functionality regarding device I/O, which prompted us to adapt Genode to the +new version. The adaptation to Codezero version 0.3 is now available at our +Subversion repository. To facilitate the use of Genode with Codezero, we +created a dedicated [http:/community/wiki/GenodeOnCodezero - Wiki page], +which provides up-to-date documentation about building and using Genode on this +kernel. + +Thanks to the Codezero developers for being extremely responsive to our +questions and feature requests! + +Learn more about +[http:/community/wiki/GenodeOnCodezero - using Genode with Codezero...] + + + +Genode OS Framework release 10.02 | 2010-02-24 +############################################## + +| Among a variety of platform-related improvements, the release 10.02 adds +| support for the NOVA and Codezero kernels and introduces a new concept for +| managing real-time priorities. + +Succeeding the previous feature-rich release, the Genode project took the +chance to focus on extending the base-platform support of the framework. We are +happy to report that we were able to complement the already broad range of +supported kernels by two new modern microkernels namely NOVA and Codezero, both +first released in 2009. Thereby, Genode provides a unified user-level +infrastructure that runs directly on those kernels as well as on Linux (32 bit +and 64 bit), OKL4v2 (x86 and ARMv4), L4/Fiasco, and L4ka::Pistachio. For +developers creating microkernel-based applications, the framework hides the +intricacies of the respective kernel. But it also strives to make the unique +capabilities of each base platform accessible to the user. For example, with +the new release, we made the real-time scheduling of OKL4 and L4ka::Pistachio +available to Genode applications. + +Read on the full story about our experiences with the new kernels and the many +[http:/documentation/release-notes/10.02 - improvements of the release 10.02...] + +[http:/download/latest-release - Download the latest release...] + + +Road map 2010 | 2010-01-04 +########################## + +| We have updated our road map with the planning of the year 2010. + +With the start of the new year, its time to pause for a moment, looking back +the progress we made during 2009, and planning the next steps. The overall +theme of 2009 was the creation of fundamental base functionality to make the +framework usable for practical applications. We are proud when revisiting the +long list of achievements introduced with the four releases of the past year: +Support for the OKL4 and l4ka::Pistachio kernels, Linux device-driver +environment, networking, USB input and storage, dynamic linking, Qt4 including +Webkit, and support for a paravirtualized Linux kernel. With this strong +foundation in place, its time to raise the bar again. + +[http:/about/road-map - Please read on about our updated road map for 2010...] + + +Genode OS Framework release 9.11 | 2009-11-25 +############################################# + +| With release 9.11 Genode gets Webkit, USB storage, TCP/IP stack, support for +| ARM, OKLinux and more ... + +For the project, the current release is a major leap towards the goal of Genode +to become a general-purpose OS platform. The addition of OKLinux - a +paravirtualized Linux kernel - to the distribution makes it possible to run +security-sensitive native Genode applications side by side with unmodified +Linux binaries. This particular version of Linux has no direct hardware access +but rather uses native Genode services as virtual hardware devices. With +respect to available device classes, we extended Genode's support to cover USB +storage and networking drivers. Moreover, the porting of the Light-weight IP +stack and Q4/Webkit now enables developers to create web applications on top of +Genode. Beside the new functionality, Genode's platform scope was broadened by +initial support of the ARM architecture. + +Read on about these and all additional changes in more detail in the +[http:/documentation/release-notes/9.11 - release notes for Genode 9.11...]. + + +Genode Live Demonstration 2009-09 | 2009-09-02 +############################################## + +| The latest release of the ready-to-boot Live CD image is available. + +The Live CD features the graphical demonstration of the Genode architecture, +known from the last Live CD. But this time it doesn't run on L4/Fiasco only. It +also can be started on top of the L4 microkernels OKL4 and Pistachio. Moreover, +it features QT4 application support and a para-virtualized Linux version +running on top of Genode. The Live CD runs directly on PC hardware and has been +tested on Qemu/KVM and VirtualBox. + +_Edit: We have further improved the performance of the L4/Fiasco and_ +_L4ka::Pistachio demos, and refined the presentation of the Qt4 demo._ + +[http:/download/live-cds - Download the updated Live-CD image...] + + +Genode OS Framework release 9.08 | 2009-08-19 +############################################# + +| The release 9.08 advances the portability of the operating-system framework +| to a new level. + +We have released the version 9.08 of the Genode OS Framework. The general theme +of this release has been refinement. We are particularly happy for having +resolved long standing concerns about our locking and signalling +implementations. The actual focus of our work during the last three months was +the unification of all supported base platforms resulting in many +generalizations of former platform-specific code. We managed to bring the code +for the Linux version very much in line with the supported L4 platforms, +reducing platform-specific source-code complexity and maintenance costs. +Feature-wise, the most important news are the port of the dynamic linker from +FreeBSD, the added support for thread-local storage, a much improved timer +service, and core extensions for running Linux on the OKL4 version of Genode. + +Read on about all the changes in the +[http:/documentation/release-notes/9.08 - release notes for Genode 9.08...] + + +Document about Genode's native Qt4 port available | 2009-07-06 +############################################################## + +| The document "Portierung von Qt auf Genode" (german) describes the +| undertaking of making the Qt4 framework natively available on Genode. Among +| many technical insights, it provides an overview about the integration with +| Genode's GUI, and explains how Qt4's low-level interfaces are mapped to +| native Genode functionality. + +Qt4 is a popular and versatile C++ framework for developing +platform-independent GUI applications. In addition to GUI-related +functionality, Qt4 covers a comprehensive library of data structures and +platform abstractions. It is widely used for both commercial and open-source +applications, most prominently, it serves as the foundation of the KDE project. + +Since the release 9.05, the official distribution of Genode supports Qt4 as a +regular feature. The document "Portierung von Qt auf Genode" _(german)_ +describes the challenging endeavor of porting this high-complexity C++ +framework to Genode. Major problems to overcome had been the missing C libary +(at the time when the project started), the integration of the Qt4 project +files with Genode's build system, the adaption of Qt4 to the basic primitives +provided by Genode, and the integration of Qt4 with Genode's GUI. In addition +to the mentioned technical insights, the document evaluates the achieved +solution with respect to compatibility and maintainability. + +[http://www.genode-labs.com/publications/qt4-on-genode-de-2009.pdf - Download the PDF...] + + +Genode OS Framework release 9.05 | 2009-05-27 +############################################# + +| With the release 9.05, we introduce the first fragments of USB support, +| update Qt to version 4.5.1, and add the OKL4 kernel as supported base +| platform. + +The new release continues the general theme to enhance our potential user base +by broadening the base-platform support and, at the same time, extending the +functionality of the framework. We have now added the OKL4 kernel to the +supported base platforms. OKL4 is a commercial-grade kernel developed by +[http://www.ok-labs.com - Open Kernel Labs] and primarily targeted at embedded +systems. Along with this integration work, we were able to further advance the +portability of Genode by generalizing much of former platform-dependent code. +On the feature side, we introduced the first parts of a USB stack, making +Linux' USB host-controller drivers and a human-interface device driver +available on Genode. As outlined in the release notes, there is also good +progress on executing Linux as a sub system of Genode. Furthermore, we have now +seamlessly integrated the support for the Qt application framework into the +Genode source tree and bumped the version to 4.5.1. + +Read on about the new features described int the +[http:/documentation/release-notes/9.05 - release notes...] + +[http:/download/latest-release - Download the release 9.05...] + +[http:/about/road-map - See our updated road map...] + + +Bringing Genode to the OKL4 kernel | 2009-05-06 +############################################### + +| We have enhanced the range of supported kernel platforms by bringing Genode +| to the OKL4 kernel developed by Open Kernel Labs. + +With the port of Genode to the OKL4 kernel, we have taken another step to reach +a broader user base of the framework.  In contrast to the already +supported microkernels L4ka::Pistachio and L4/Fiasco, the OKL4 kernel developed +by [http://ok-labs.com - Open Kernel Labs] is largely deployed in commercial +settings. Even though being a member of the L4 family of kernels, OKL4 has a +much modernized kernel API that fits quite well with the Genode architecture. +For example, OKL4 does not rely on an in-kernel mapping database, frees the IPC +operation from wall-clock timeouts, supports asynchronous notifications, and +provides kernel support for user-level synchronization. + +In the process of porting Genode to OKL4 version 2.1, we took the chance of +generalizing a lot of former L4-specific code such that the remaining +platform-specific code is now in the order of less than 2,000 lines of code for +each kernel platform. To ease future ports of the frameworks to other kernels, +we have documented our work in detail. If you are interested in learning more +about the OKL4 kernel from our perspective, or if you like to dive right into +the inner parts of the Genode OS Framework, read on about +[http:/documentation/articles/genode-on-okl4 - Bringing the Genode OS Framework to the OKL4 kernel...] + +The OKL4 version is available at our subversion repository and will be included +in the upcoming release 9.05. For further information about building and using +Genode on OKL4, please refer to the new +[http:/community/wiki/GenodeOnOKL4 - Genode on OKL4 Wiki page...] + + +Genode on 64-bit Linux kernels | 2009-04-17 +########################################### + +| Genode can now use both 32-bit as well as 64-bit versions of the Linux kernel +| as base platform. + +From the ground up, Genode was co-developed supporting Linux and L4 as base +platforms but the both versions were restricted to the 32-bit x86 architecture. +We have now expanded the Linux support to 64 bit. Because most of the adaptions +of Genode to 64 bit took place in generic code, we are now well prepared to +support future 64-bit versions of L4 kernels as well. The patch for adding 64 +bit support supplied by Christian Prochaska is now included in the current +version of the Genode subversion repository. + +[http:/download/subversion-repository - Access the Genode subversion repository...] + + +Christian Prochaska joins our project as regular developer | 2009-04-08 +####################################################################### + +| The developer of the Qt4 port for Genode joins Genode Labs to bring forward +| his Genode-related projects. + +As the original developer of the Qt4 port for Genode, Christian Proachaska has +gained long-time experience with running complex software on top of Genode. In +the future, he will leverage his skills to further advance his Qt4-related +work. Furthermore, he strives to improve the framework towards general-purpose +computing. Currently, he is working on adding 64-bit support to Genode. + + +Genode OS Framework release 9.02 | 2009-02-26 +############################################# + +| The version 9.02 of the Genode OS Framework introduces support for +| L4ka::Pistachio as base platform, a port of the Qt4 application framework, +| and networking. + +Whereas the focus of the previous release 8.11 was the refinement of Genode's +base API and the creation of the infrastructure needed to build real-world +applications, the new release 9.02 is focused on functional enhancements in two +directions. The first direction is broadening the number of possible base +platforms for the framework. At present, most microkernels bring along a custom +user land, which is closely tied to the particular kernel. Our vision is to +establish Genode as a common ground for developing applications, protocol +stacks, and device drivers in such a way that the software becomes easily +portable among different kernels. This release makes Genode available on the +L4ka::Pistachio kernel. Hence, software developed with the Genode API can now +run unmodified on Linux/x86, L4/Fiasco, and L4ka::Pistachio. In the second +direction, we are steadily advancing the functionality available on top of +Genode. With this release, we introduce a basic networking facility and support +for native Qt4 applications as major new features. Thanks to Genode's +portability, these features become automatically available on all supported +base platforms. + +Read on about the new features described in the +[http:/documentation/release-notes/9.02 - release notes...] + +[http:/download/latest-release - Download the Genode release 9.02...] + + +Port of libSDL to Genode | 2009-01-23 +##################################### + +| As announced on the Genode mailing list, the popular Simple Directmedia +| Library is being ported to Genode. A first version of the port and a demo +| application are already available. + +The [http://www.libsdl.org - Simple Directmedia Layer library] (libSDL) is a +very popular cross-platform media library that provides hardware abstractions +for graphics, input devices, and sound. It is often used as back end for games, +emulators, and media players. Also the Linux version of Genode relies on the +hardware abstractions provided by libSDL. + +As [http:/community/viewml?msg_name=4978DC53.3090409%40torfbruecke.net&forum_name=genode-main - announced on the Genode mailing list], +libSDL has been ported to Genode. At the current stage, the port supports +the video subsystem and the input handling for mouse and keyboard. With +libSDL now becoming available for Genode, it becomes much easier to make the +wealth of libSDL-based applications available on our platform. + +[http:/community/viewml?msg_name=4978DC53.3090409%40torfbruecke.net&forum_name=genode-main - Read the announcement...] + + +Genode on the L4ka::Pistachio kernel | 2008-12-18 +################################################# + +| The new L4ka::Pistachio version of the Genode OS Framework makes the unique +| features, performance, and stability of the L4::Pistachio kernel available +| for Genode's software stack. + +L4ka::Pistachio is the reference implementation of the L4 API version x.2 (also +referred to as version 4). With the port of Genode to L4ka::Pistachio conducted +by Julian Stecklina, this kernel has become available as a base platform for +Genode. The choice of leveraging the special characteristics of +L4ka::Pistachio, the Linux kernel, or L4/Fiasco has become just a matter of +recompilation. This way, software written against the Genode API can benefit +from the long-year research and development invested into L4ka::Pistachio by +the L4ka group at the University of Karlsruhe and the DiSy group at the +University of New South Wales. We have made the L4ka::Pistachio version of +Genode available at our public subversion repository. It will become a regular +part of Genode with the upcoming release as scheduled for February. The +instructions for building and using Genode with the L4ka::Pistachio kernel are +provided at our Genode-on-L4ka::Pistachio wiki page. + +[http:/community/wiki/GenodeOnL4kaPistachio">Learn more about Genode on L4ka::Pistachio...] + + +Public bug tracker available | 2008-12-12 +######################################### + +| Because we received several requests for a public bug tracker, we have now +| enabled the public tracker of our Sourceforge project. + +With the new bug tracker, we want to simplify the sharing and solving of issues +related to Genode in a coordinated fashion. If you discover things you like to +see improved in our code or documentation, please do not hesitate to share your +experiences and ideas by posting a bug. [http:/community - Community resources...] + + +Genode OS Framework release 8.11 | 2008-11-21 +############################################# + +| We are pleased to announce the release 8.11 of the Genode OS Framework +| introducing a new device-driver API, a C runtime, support for asynchronous +| notifications, and many improvements of the base API. + +With the new release 8.11, we are aiming at enabling Genode for real-world +applications that require custom device drivers and the reuse of existing +code.  Among the major improvements are a new device driver API that eases +the reuse of existing device drivers and a C runtime that facilitates the reuse +of a wealth of existing C library code on Genode. Furthermore, we extended the +base API by a number of exciting feature such as support for asynchronous +notifications, capability typification, and managed dataspaces. + +Learn more about all the new features and changes described in our comprehensive +[http:/documentation/release-notes/release_notes-08-11 - release notes...] + +[http:/download/latest-release - Download the release 8.11 of the Genode OS Framework...] + + +Ready-to-boot Live-CD image available | 2008-10-21 +################################################## + +| As a teaser for the upcoming release 8.11, we have compiled a Live-CD image +| showing off the current state of the Genode OS Framework. + +The Live CD features a fully graphical demonstration that presents the +fundamental concepts of the Genode architecture in an interactive fashion. It +runs directly on PC hardware and has been tested on Qemu and VirtualBox. +[http:/download/live-cds - Download the Live-CD image...] + + +New and exciting challenges ahead | 2008-09-19 +############################################## + +| To foster the involvement of developers interested in working on Genode, we +| have enhanced the compilation of future challenges in our Wiki by a number of +| interesting Genode-related projects to pursue. + +The Genode architecture inspires a large number of topics for research, +experimentation, and development. The +[http:/community/wiki/Challenges - challenges section of our Wiki] compiles a +number of existing ideas. We have now enhanced this compilation by a number of +further avenues that we find interesting to explore. For example, exploring +Linux process containers, running Genode on FPGA platforms, dynamic linking +support, de-privileging VESA, optimizing locking performance, and the port of +libSDL. Maybe some of you find these topics as thrilling as we do? If yes, +please feel welcome to pick up the ideas to start experimenting with Genode. + + +The Genode build system thoroughly examined | 2008-08-22 +######################################################## + +| In his paper "Empirical Comparison of SCons and GNU Make", Ludwig Hähne +| pursues the question of which build system to choose for an operating-system +| project such as ours. For his study, he took the Genode build system as a +| real-world use case. His results are not only valuable for our particular +| project but for everyone with an interest in build systems. + +For the Genode OS Framework, we consider flexibility, usability, reliability, +and scalability of the build infrastructure is crucial. When we started +project, we created a custom build infrastructure with a particular focus on +developer convenience. The effort already paid off for our daily work. The +current implementation relies on GNU Make as back end but we are aware that +there exist more modern approaches for building software, in particular there +is SCons. In his paper, Ludwig Hähne used the Genode build system as a use case +to compare SCons and GNU Make. He replicated our build system for the use of +SCons as back end and conducted comprehensive experiments. The empirical +results presented in the paper reveal a number of interesting issues, for +example the limited scalability of the current Genode build system with regard +to parallelism, and the memory consumption of SCons when used for large +projects. +[http://www.genode-labs.com/publications/scons-vs-make-2008.pdf - Download the PDF document...] + + +Genode ported to Syllable Server OS | 2008-08-22 +################################################ + +| The developers of the Syllable OS project have ported Genode to the +| Linux-based server version of Syllable OS. + +Syllable is a fully fledged free-software operating system that is mainly +targeted at desktop computers. Thanks to its long-year steady development, +there exists a large base of custom applications. As announced on the +[http://development.syllable.org/pages/index.html - website of the Syllable OS project], +Genode has been ported to the server version of Syllable OS. Kaj de Vos of the +Syllable project also considers the incorporation of Genode into the desktop +version of Syllable, which would be a very interesting synergy. + + +Genode OS Framework release 8.08 | 2008-08-06 +############################################# + +| We released the first official version of the Genode OS Framework. + +The initial version of the Genode OS Framework is available for download. For +naming our releases, we use the Ubuntu version-number scheme, which takes the +year as the major number and the month as minor number. Hence, the release is +called 8.08. It contains everything needed to execute an interactive graphical +demonstration scenario on Linux via libSDL or alternatively via L4/Fiasco on +bare PC hardware. +[http:/download/latest-release - Download the latest release...] + + +Project website launched | 2008-07-29 +##################################### + +| The launch of our comprehensive project website genode.org marks the begin of +| our effort to turn Genode into a community project. The initial release of the +| Genode OS framework is scheduled for the 6th of August. + +Today, we proudly launched the website of the Genode project +[http://www.genode.org - http://www.genode.org]. This website is the central +resource for people using or developing the Genode OS framework. It covers +the latest news about our progress, architectural and technical documentation, +a community-maintained wiki, mailing lists, information on accessing the +source-code, and much more. We sincerely hope that this website will draw the +attention of people who want bring forward the project together with us. + +We have scheduled the first official release of the Genode OS framework for the +6th August. Until then, we invite you to test-drive the beta-version of the +framework as provided at the [http://www.genode.org/download - download]. + + +Genode Labs founded | 2008-07-17 +################################ + +| The original authors of the Genode OS Framework start a company dedicated to +| promoting and advancing Genode. + +At 15th of May, the two former PhD students of the TU Dresden Operating Systems +group who developed the original vision behind the Genode architecture and who +created the present implementation of the Genode OS Framework started their +company Genode Labs. Genode Labs is committed to bring forward their novel OS +technology as a community project and to facilitate its application to +real-world problems. + + diff --git a/doc/release_notes-10-02.txt b/doc/release_notes-10-02.txt index 5d78eb5cb6..84d6d9e345 100644 --- a/doc/release_notes-10-02.txt +++ b/doc/release_notes-10-02.txt @@ -313,7 +313,7 @@ Codezero is a microkernel primarily targeted to ARM-based embedded systems. It is developed as an open-source project by a British company called B-Labs. :B-Labs website: - [http://b-labs.co.uk] + [http://b-labs.com] The Codezero kernel was first made publicly available in summer 2009. The latest version, documentation, and community resources are available at the diff --git a/doc/release_notes-11-11.txt b/doc/release_notes-11-11.txt index 15d3b30952..44b6e063ac 100644 --- a/doc/release_notes-11-11.txt +++ b/doc/release_notes-11-11.txt @@ -16,7 +16,7 @@ sight, this topic sounds like riding a dead horse because virtualization is widely regarded as commodity by now. However, because Genode has virtualization built right in the heart of its architecture, this topic gets a quite different spin. As described in Section [A Plethora of Levels of Virtualization], the -version 11.11 contains the results our exploration work about faithful +version 11.11 contains the results of our exploration work about faithful virtualization, paravirtualization, OS-level virtualization, and application-level virtualization. The latter category is particularly unique to Genode's architecture. @@ -173,7 +173,7 @@ Genode. This particular program is interesting for several technical reasons as well. First, in contrast to most command-line tools such as coreutils, it is interactive and implements its event loop via the 'select' system. This provided us with the incentive to implement 'select' in Noux. Second, with far -more than 100,000 lines of code, VIM not a toy but a highly complex and +more than 100,000 lines of code, VIM is not a toy but a highly complex and advanced UNIX tool. Third, its user interface is based on ncurses, which requires a fairly complete terminal emulator. Consequently, conducting the development of Noux implied working with and understanding several components @@ -246,7 +246,7 @@ observe and intercept all interactions between the process and core. In particular, GDB monitor gains access to all memory objects allocated from the debugging target's RAM session, it knows about the address space layout, and becomes aware of all threads created by the debugging target. Because, GDB -monitor does possess the actual capabilities to the debugging target's CPU +monitor does possess the actual capabilitiy to the debugging target's CPU session, it can execute control over those threads, i.e., pausing them or enabling single-stepping. By combining the information about the debugging target's address space layout and the access to its memory objects, GDB monitor @@ -352,7 +352,7 @@ session becomes ready to use. The Terminal::Connection waits for this signal at construction time. Furthermore, we extended the terminal session interface with the new 'avail()' and 'size()' functions. The 'avail()' function can be used to query for the availability of new characters. The 'size()' function -returns the size of the terminal (number of row and columns). +returns the size of the terminal (number of rows and columns). Dynamic linker @@ -661,7 +661,7 @@ adding the following line: ! QEMU_OPT = -enable-kvm -Unfortunately, it hardly depends on your Qemu version and configuration, +Unfortunately, it very much depends on your Qemu version and configuration, whether Fiasco.OC runs problem-free with KVM support enabled. If you encounter problems, try to use a limited KVM option with Qemu, like '-no-kvm-irqchip', or '-no-kvm-pit' instead of '-enable-kvm'. @@ -748,7 +748,7 @@ interface has been extended to reflect the whole register set of the corresponding thread depending to the underlying hardware platform. Moreover, you can now stop and resume a thread's execution. On the x86 platform, it has become possible to enable single-stepping mode for a specific thread. All -exceptions of a thread raises are now reflected to the exception handler of +exceptions a thread raises are now reflected to the exception handler of this thread. The exception handler can be set via the CPU-session interface. To support stop/resume, single stepping and breakpoints on ARM, we had to modify the Fiasco.OC kernel slightly. All patches to the Fiasco.OC kernel can be found @@ -905,7 +905,7 @@ stand in the way when building low-level system components. For example, the Hence, we have to turn it off when building Genode. However, some tool chains lack this option. So the attempt to turn it off produces an error. The most important problem with Linux tool chains is the dependency of their respective -GCC support libraries from the glibc. When not using a Linux glibc, as the case +GCC support libraries on the glibc. When not using a Linux glibc, as the case with Genode, this leads to manifold problems, most of them subtle and extremely hard to debug. For example, the support libraries expect the Linux way of implementing thread-local storage (using segment registers on x86_32). This @@ -931,7 +931,7 @@ reason we used the ARM tool chains provided by CodeSourcery. With Genode 11.11, we addressed the root of the tool-chain problem by completely decoupling the Genode tool chain from the host system that is used -to build it. The most important step was the removal of GCC's dependency from +to build it. The most important step was the removal of GCC's dependency on a C library, which is normally needed to build the GCC support libraries. We were able to remove the libc dependency by sneaking-in a small custom libc stub into the GCC build process. This stub comes in the form of the single header @@ -957,7 +957,7 @@ for x86 within your '/tmp/' directory, use the following commands: ! mkdir /tmp/tool_chain ! cd /tmp/tool_chain ! /tool/tool_chain x86 -After completing the build, you will be asked for the superuser password to +After completing the build, you will be asked for your user password to enable the installation of the result to '/usr/local/genode-gcc/'. Since we introduced GDB support into Genode, we added GDB in addition to GCC @@ -976,14 +976,14 @@ the dependency information between libraries and targets in the file '/var/libdeps'. This generated file contains make rules to be executed in the second build stage, which performs all compilation and linking steps. In contrast to the first stage, the work-intensive second stage can be -executed in parallel using '-j' argument of make. Because of the serialization +executed in parallel using the '-j' argument of make. Because of the serialization of the first build stage, it naturally does not profit from multiple CPUs. This should be no problem because the task of the first stage is simple and supposedly executed quickly. However, for large builds including many targets, we found the time needed for the first stage to become longer than expected. This prompted us to do a bit of profiling. -Tracing the 'execve' syscalls of first build stage via 'strace' evidenced that +Tracing the 'execve' syscalls of the first build stage via 'strace' evidenced that the echo commands used for creating the 'var/libdeps' file attributed significantly to the overall time because each echo involves the spawning of a shell. There are two counter measures: First, we eagerly detect already visited @@ -1005,4 +1005,4 @@ to clean up contribution code package-sensitive analog to the preparation of packages. If you don't want to tidy up the whole libports repository, but for instance just the LwIP code, just issue: -! 'make clean PKG=lwip +! make clean PKG=lwip diff --git a/doc/tool_chain.txt b/doc/tool_chain.txt new file mode 100644 index 0000000000..1a84c51709 --- /dev/null +++ b/doc/tool_chain.txt @@ -0,0 +1,125 @@ + + ================= + Genode tool chain + ================= + +The Genode OS framework depends on the GNU C++ compiler and tool chain. As +most GNU compilers shipped with standard Linux distributions include +distro-specific patches and configurations, these tools do not meet Genode's +special requirements (e.g., thread-local storage configuration). Therefore, +there exists a special tool chain adapted to the specific requirements of +Genode. + + +Recommended development platform +################################ + +We currently use [http://www.ubuntu.com/ - Ubuntu] 10.04 LTS and 11.04 on +servers and client machines. Hence, Genode should always build without trouble +on these platforms. + + +Unified tool chain +################## + +Starting with Genode version 11.11, there is a unified tool chain for all base +platforms and supported CPU architectures (x86_32, x86_64, and ARM). For Genode +development, we highly recommend the use of the official Genode tool chain. It +can be obtained in two ways: as pre-compiled binaries (for Linux-based x86_32 +host systems), or manually compiled: + +:Pre-compiled: + Our pre-compiled tool chain is runnable on Linux/x86_32. The archive will be + extracted to '/usr/local/genode-gcc'. To extract the archive, use the + following command: + ! sudo tar xPfj genode-toolchain-.tar.bz2 + The use of the 'P' option ensures that the tool chain will be installed at + the correct absolute path. + [http://sourceforge.net/projects/genode/files/genode-toolchain/ - Download the pre-compiled tool chain...] + +:Compile from source: + For those of you who prefer compiling the tool chain from source or for + obtaining a tool chain for x86_64, we provide a tool for downloading, + building, and installing the Genode tool chain. You find the tool in Genode's + source tree at 'tool/tool_chain'. For usage instructions, just start the tool + without arguments. + +In both cases, the tool chain will be installed to '/usr/local/genode-gcc'. All +tools are prefixed with 'genode-x86-' or 'genode-arm-' respectively such that +it is safe to add the installation directory to our 'PATH' variable (optional). +The Genode tool chain will be used by the Genode build system by default. If +you desire to use a different tool chain, create a file called 'tools.conf' in +the 'etc/' subdirectory of your build directory where you can define the +tool-chain prefix to be used: + +! CROSS_DEV_PREFIX = /path/to/your/custom/tool_chain/your-x86- + +However, we recommend you to stick with the official Genode tool chain. If you +see a valid reason not to use it, please contact us (e.g., via the mailing +list). + + +Background information - Why do we need a special tool chain? +############################################################# + +Early on in the genesis of Genode, we introduced a custom tool chain to +overcome several problems inherent to the use of standard tool chains installed +on Linux host platforms. + +First, GCC and binutils versions vary a lot between different Linux systems. +Testing the Genode code with all those different tool chains and constantly +adapting the code to the peculiarities of certain tool-chain versions is +infeasible and annoying. Second, Linux tool chains use certain features that +stand in the way when building low-level system components. For example, the +'-fstack-protector' option is enabled by default on some Linux distributions. +Hence, we have to turn it off when building Genode. However, some tool chains +lack this option. So the attempt to turn it off produces an error. The most +important problem with Linux tool chains is the dependency of their respective +GCC support libraries on the glibc. When not using a Linux glibc, as the case +with Genode, this leads to manifold problems, most of them subtle and extremely +hard to debug. For example, the support libraries expect the Linux way of +implementing thread-local storage (using segment registers on x86_32). This +code will simply crash on other kernels. Another example is the use of certain +C-library functions, which are not available on Genode. Hence, Genode provides +custom implementations of those functions (in the 'cxx' library). +Unfortunately, the set of functions used varies across tool-chain versions. For +these reasons, we introduced a custom configured tool chain where we mitigated +those problems by pinning the tools to certain versions and tweaking the +compiler configuration to our needs (i.e., preventing the use of Linux TLS). + +That said, the use a our custom configured tool chain was not free from +problems either. In particular, the script for creating the tool chain relied +on a libc being present on the host system. The header files of the libc would +be used to build the GCC support libraries. This introduced two problems. When +adding Genode's libc to the picture, which is based on FreeBSD's C library, the +expectations of the GCC support libraries did not match 100% with the semantics +implemented by Genode's libc (e.g., the handling of 'errno' differs). The +second problem is the limitation that the tool chain could only be built for +the platform that corresponds to the host. For example, on a Linux-x86_32 +system, it was not possible to build a x86_64 or ARM tool chain. For this +reason we used the ARM tool chains provided by CodeSourcery. + +With Genode 11.11, we addressed the root of the tool-chain problem by +completely decoupling the Genode tool chain from the host system that is used +to build it. The most important step was the removal of GCC's dependency on +a C library, which is normally needed to build the GCC support libraries. We +were able to remove the libc dependency by sneaking-in a small custom libc stub +into the GCC build process. This stub comes in the form of the single header +file 'tool/libgcc_libc_stub.h' and brings along all type definitions and +function declarations expected by the support-library code. Furthermore, we +removed all GNU-specific heuristics from the tool chain. Technically, the +Genode tool chain is a bare-metal tool chain. But in contrast to existing +bare-metal tool chains, C++ is fully supported. + +With the libc dependency out of the way, we are now free to build the tool +chain for arbitrary architectures, which brings us two immediate benefits. We +do no longer have to rely on the CodeSourcery tool chain for ARM. There is now +a 'genode-arm' tool chain using the same compiler configuration as used on x86. +The second benefit is the use of multiarch libs on the x86 platform. The +genode-x86 tool chain can be used for both x86_32 and x86_64, the latter being +the default. + +Since we introduced GDB support into Genode, we added GDB in addition to GCC +and binutils to the Genode tool chain. The version is supposed to match the one +expected by Genode's GDB facility, avoiding potential problems with mismatching +protocols between GDB monitor and GDB. diff --git a/os/run/ldso.run b/os/run/ldso.run index a01ae65d3a..472137ea9c 100644 --- a/os/run/ldso.run +++ b/os/run/ldso.run @@ -1,3 +1,7 @@ + +if {[have_spec always_hybrid]} { + puts "Run script does not support hybrid Linux/Genode."; exit 0 } + build "core init test/ldso" create_boot_directory diff --git a/tool/autopilot b/tool/autopilot index a0ee2796cf..cfae41dd40 100755 --- a/tool/autopilot +++ b/tool/autopilot @@ -305,7 +305,7 @@ foreach platform $platforms { # Print label identifying the specified test case to stderr # proc print_step_label { platform step } { - puts -nonewline stderr "[format {%-20s} $platform:] [format {%-20s} $step] " + puts -nonewline stderr "[format {%-20s} $platform:] [format {%-22s} $step] " } diff --git a/tool/builddir/etc/build.conf.generic b/tool/builddir/etc/build.conf.generic index 5412c8e0a1..9cb953f051 100644 --- a/tool/builddir/etc/build.conf.generic +++ b/tool/builddir/etc/build.conf.generic @@ -6,37 +6,3 @@ REPOSITORIES += $(GENODE_DIR)/base REPOSITORIES += $(GENODE_DIR)/os REPOSITORIES += $(GENODE_DIR)/demo - -## -## Optional repositories -## - -# -# Ports of popular open-source libraries and the C library -# -# Make sure to execute 'make prepare' in 'libports' prior building. -# -#REPOSITORIES += $(GENODE_DIR)/libports - -# -# Qt4 tool kit -# -# The 'qt4' repository depends on 'libc' and 'libports' -# Make sure to execute 'make prepare' in 'qt4' prior building. -# -#REPOSITORIES += $(GENODE_DIR)/qt4 - -# -# Ports of popular 3rd-party applications -# -# The 'ports' repository depends on 'libc', 'libports', and 'qt4'. -# Make sure to execute 'make prepare' in 'ports' prior building. -# -#REPOSITORIES += $(GENODE_DIR)/ports - -# -# High-level Genode-specific services and applications -# -# The 'gems' repository depends on 'libc', 'libports', and 'qt4'. -# -#REPOSITORIES += $(GENODE_DIR)/gems diff --git a/tool/builddir/etc/build.conf.lx_hybrid_x86 b/tool/builddir/etc/build.conf.lx_hybrid_x86 new file mode 100644 index 0000000000..06b8af6753 --- /dev/null +++ b/tool/builddir/etc/build.conf.lx_hybrid_x86 @@ -0,0 +1 @@ +REPOSITORIES = $(GENODE_DIR)/base-linux diff --git a/tool/builddir/etc/build.conf.optional b/tool/builddir/etc/build.conf.optional new file mode 100644 index 0000000000..9ea058afc6 --- /dev/null +++ b/tool/builddir/etc/build.conf.optional @@ -0,0 +1,34 @@ + +## +## Optional repositories +## + +# +# Ports of popular open-source libraries and the C library +# +# Make sure to execute 'make prepare' in 'libports' prior building. +# +#REPOSITORIES += $(GENODE_DIR)/libports + +# +# Qt4 tool kit +# +# The 'qt4' repository depends on 'libc' and 'libports' +# Make sure to execute 'make prepare' in 'qt4' prior building. +# +#REPOSITORIES += $(GENODE_DIR)/qt4 + +# +# Ports of popular 3rd-party applications +# +# The 'ports' repository depends on 'libc', 'libports', and 'qt4'. +# Make sure to execute 'make prepare' in 'ports' prior building. +# +#REPOSITORIES += $(GENODE_DIR)/ports + +# +# High-level Genode-specific services and applications +# +# The 'gems' repository depends on 'libc', 'libports', and 'qt4'. +# +#REPOSITORIES += $(GENODE_DIR)/gems diff --git a/tool/create_builddir b/tool/create_builddir index 5946565405..4f8ea0ea6a 100755 --- a/tool/create_builddir +++ b/tool/create_builddir @@ -21,9 +21,8 @@ usage: @echo " can be 'linux_x86', 'fiasco_x86', 'pistachio_x86'," @echo " 'okl4_x86', 'nova_x86', 'codezero_vpb926'," @echo " 'mb_s3a_starter_kit', foc_x86_32', 'foc_x86_64'," - @echo " ''foc_pbxa9', or 'foc_vea9x4'" - @echo " 'or 'foc_pbxa9'" - @echo " " + @echo " 'foc_pbxa9', 'foc_vea9x4', or 'lx_hybrid_x86'" + @echo @echo " is the location of the build directory to create" @echo @@ -78,6 +77,17 @@ $(BUILD_DIR)/etc/build.conf:: $(BUILD_CONF_PLATFORM) @cat $< >> $@ @cat $(BUILD_CONF).generic >> $@ +# +# Add optional repositories for all platforms except for lx_hybrid +# +# Those repositories rely on Genode's libc or contain device drivers. +# Both prerequisites are not available for hybrid Linux/Genode programs. +# +ifneq ($(PLATFORM),lx_hybrid_x86) +$(BUILD_DIR)/etc/build.conf:: + @cat $(BUILD_CONF).optional >> $@ +endif + # # Add 'ports-okl4' repository to OKL4 build directory # @@ -139,6 +149,10 @@ mb_s3a_starter_kit:: mb_ml507:: @echo "SPECS = genode mb_ml507" > $(BUILD_DIR)/etc/specs.conf +lx_hybrid_x86:: + @echo "CROSS_DEV_PREFIX =" > $(BUILD_DIR)/etc/tools.conf + @echo "SPECS += always_hybrid" >> $(BUILD_DIR)/etc/specs.conf + $(PLATFORM):: @echo "successfully created build directory at $(BUILD_DIR)"