users

users@lists.genode.org

2285 discussions

Re: Trying to understand how capabilities are implemented
by Albin Otterhäll 05 Sep '23

05 Sep '23

Hi Martin! Sorry for the late reply, toke some time to get a mail client up and running with my mail provider. Didn't want to send a reply using their web client. On 8/21/23 11:24, Martin Stein wrote: > On 19.08.23 03:35, Albin Otterhäll wrote: >> 1. The RPC object A is created inside the protection domain 1, which >> result in the object identity A being created by the kernel. >> >> 2. A has a name, which is a natural number. >> Q1: Is the RPC object's name the value of a class variable of type >> int? > > In short: Yes, you can consider it a simple integer that is known to > both the kernel and the affected user-land program. The name references > this object only within this one program (respectively protection domain). > > Just in case you're interested in some code background: > > In header [1] you can find the classes Rpc_object and Rpc_entrypoint - a > thread that is used for handling RPCs on RPC objects. An RPC object > initially comes without a capability (the objects name), but a > capability is created and returned when linking the object via > Rpc_entrypoint::manage to an entrypoint. At this point the object > becomes ready to be called from outside the program. > > As you can see in header [2], Capability has no members but inherits > from Untyped_capability, AKA Native_capability, which contains a pointer > _data. Now, this is where it becomes platform-specific. However, a very > simple case is the "base-hw" kernel. There, the _data pointer itself (as > long value) is used as local name of the object [4]. This long value is > the name that is registered in the domain's cap space inside the kernel > for that particular RPC object. Thanks for the code references and the explanation! >> 3. Protection domain 1 has a capability space insied the kernel. >> Q2: Is the protection domain seperate from the capability space in >> the kernel, and they're "connected" with some map somewhere? > > In general, this is very kernel-specific. However, I know the internals > only for the "base-hw" kernel. In this kernel, the cap space is not > separate from its protection domain. Each domain object [5] contains a > tree _cap_tree of all RPC object names known to this domain (see [6] for > more details). Okey! Didn't know that it could be different between the different kernels. Thought that they were abstracted out, but apparently not. :) >> Q3: Is the capability space a map between natural numbers and some >> form of address to the object identity? I.e. the map work similar to a >> set of OO references, there the keys are variable names; and the >> values are the memory addresses of object identities. > > Again very kernel-specific and, again, my knowledge about "base-hw": In > this kernel your depiction is very accurate. Each RPC object name is an > Object_identity_reference in the kernel and contains a pointer > Object_identity *_identity. Thanks for confirming! >> Q4: If the answer to Q3 is yes, does that mean that delegagion is >> some form of mechanism to share the adress of the object identity with >> other protection domains? > > If I understand you correctly, yes and no. To the user it looks like > sharing an address in OO but you might better think of it as sharing the > _ability_ to access the object. In contrast to address sharing, > delegation creates a new local name/reference for the object identity in > the target domain/cap space. In my domain the object might be referenced > by the name "3" while in a domain I have delegated to, the object might > be referenced by the name "987". However, even if delegation would > result in the same name "3", the link between this name and the object > is unique to the target domain as is that between my "3" and the object. > This is well illustrated by § 3.1 Figure 3 in the book. Is there a semantic difference between "sharing an address" and "sharing the ability to access the object"? I've looked at base/include/base/rpc_server.h and base/include/base/capability.h, but I couldn't see any parts about delegation (I don't have any experience with C++, so it's possible I've missed something obvious). > I hope that was helpful!? It was very helpful! Thank you! -- Albin Otterhäll

2 1

Announcement: Genode OS Framework version 23.08 released
by Norman Feske 24 Aug '23

24 Aug '23

I am happy to announce the release of Genode 23.08 today. https://genode.org/news/genode-os-framework-release-23.08 This version is primarily focused on two aspects of developer tooling. First, it introduces a new multi-component debug monitor that can be used as drop-in replacement for init to interact with the hosted components via the GDB protocol. We regard it as the gateway to smooth on-target debugging on Sculpt OS. Second, the Goa tool rapidly evolves into an all-encompassing alternative to Genode's traditional work flows for developing, porting, and publishing applications. The release introduces countless new productivity boosters, up to the ability to manage cross-dependencies between Goa projects. Besides these two prominent topics, we concentrated our efforts on code modernization, the retiring of legacies, and quality assurance. This involves the replacement of aged device drivers by completely new ones that leverage our modern DDE-Linux approach. E.g., there are new drivers for PC NICs as well as the USB host controllers of the Raspberry Pi and i.MX6. Summary of changes: - New multi-component debug monitor - Goa tool support for working with multiple projects - New NIC server for raw uplink connectivity - New PC network driver based on DDE-Linux - New USB host drivers for i.MX6 and Raspberry Pi - New PinePhone support for buttons and screensaver - New depot-remove component - Improved drivers for Intel GPU, Intel display, Wifi, and audio - Internal core and base-framework modernization The official release documentation covers all the details: https://genode.org/documentation/release-notes/23.08 Hoping you'll enjoy the new version, Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Announcement: Genode OS Framework version 23.05 released
by Christian Helmuth 22 Aug '23

22 Aug '23

Today we released Genode 23.05 as a colorful bouquet of new features, improvements, and fixes. The most prominent change for developers is the update of our tool chain to GCC 12, binutils 2.40, and GDB 13.1. The new GCC version gave us the opportunity to switch from C++17 to C++20 as default setting and benefit from modern C++ language features. Another noteworthy addition falling into the same category is the release of the evolving Goa tool for Sculpt 23.04, which now enables the use of existing SDKs like Lomiri or Rust's cargo for Genode. Our Linux device-driver environment (DDE), which enables the use of Linux drivers as Genode components was upgraded to Linux 6.1.20. For example, the DDE now powers our cross-platform Wifi stack that works for the PC and ARM platforms as the PinePhone alike. Further, we integrated the initial use of our custom base-hw microkernel as x86 hypervisor, a profoundly reworked block-encryption stack, and updates of supported third-party software like the seL4 kernel and VirtualBox. Last but not least, we published our annual documentation update in form of "Genode Foundations" and "Genode Platforms" books. The current release contains the following changes and new features: - Goa tool updated to Sculpt OS 23.04 - Ubuntu-Touch-UI toolkit - Initial support for Rust cargo - New tool chain based on GCC 12.3 - C++20 enabled by default - Annual documentation update - Uniform Wifi stack across PC and ARM platforms - Revision of Genode's custom block-encryption infrastructure - Linux device-driver environment updated to Linux 6.1.20 - Improved USB, Intel display, and NVMe drivers - VirtualBox 6.1.44 - Initial x86 virtualization via the base-hw microkernel - Updated seL4 microkernel to version 12.1 - NetBSD rump kernel on RISC-V Read the complete release documentation for the version 23.05 here https://genode.org/documentation/release-notes/23.05 Best regards -- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · https://genodians.org/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

3 3

Trying to understand how capabilities are implemented
by Martin Stein 21 Aug '23

21 Aug '23

Hi Albin! On 19.08.23 03:35, Albin Otterhäll wrote: > 1. The RPC object A is created inside the protection domain 1, which result in the object identity A being created by the kernel. > > 2. A has a name, which is a natural number. > Q1: Is the RPC object's name the value of a class variable of type int? In short: Yes, you can consider it a simple integer that is known to both the kernel and the affected user-land program. The name references this object only within this one program (respectively protection domain). Just in case you're interested in some code background: In header [1] you can find the classes Rpc_object and Rpc_entrypoint - a thread that is used for handling RPCs on RPC objects. An RPC object initially comes without a capability (the objects name), but a capability is created and returned when linking the object via Rpc_entrypoint::manage to an entrypoint. At this point the object becomes ready to be called from outside the program. As you can see in header [2], Capability has no members but inherits from Untyped_capability, AKA Native_capability, which contains a pointer _data. Now, this is where it becomes platform-specific. However, a very simple case is the "base-hw" kernel. There, the _data pointer itself (as long value) is used as local name of the object [4]. This long value is the name that is registered in the domain's cap space inside the kernel for that particular RPC object. > 3. Protection domain 1 has a capability space insied the kernel. > Q2: Is the protection domain seperate from the capability space in the kernel, and they're "connected" with some map somewhere? In general, this is very kernel-specific. However, I know the internals only for the "base-hw" kernel. In this kernel, the cap space is not separate from its protection domain. Each domain object [5] contains a tree _cap_tree of all RPC object names known to this domain (see [6] for more details). > Q3: Is the capability space a map between natural numbers and some form of address to the object identity? I.e. the map work similar to a set of OO references, there the keys are variable names; and the values are the memory addresses of object identities. Again very kernel-specific and, again, my knowledge about "base-hw": In this kernel your depiction is very accurate. Each RPC object name is an Object_identity_reference in the kernel and contains a pointer Object_identity *_identity. > Q4: If the answer to Q3 is yes, does that mean that delegagion is some form of mechanism to share the adress of the object identity with other protection domains? If I understand you correctly, yes and no. To the user it looks like sharing an address in OO but you might better think of it as sharing the _ability_ to access the object. In contrast to address sharing, delegation creates a new local name/reference for the object identity in the target domain/cap space. In my domain the object might be referenced by the name "3" while in a domain I have delegated to, the object might be referenced by the name "987". However, even if delegation would result in the same name "3", the link between this name and the object is unique to the target domain as is that between my "3" and the object. This is well illustrated by § 3.1 Figure 3 in the book. I hope that was helpful!? [1] base/include/base/rpc_server.h [2] base/include/base/capability.h [3] base/include/base/native_capability.h [4] base-hw/src/lib/base/capability.cc:59 [5] base-hw/src/core/kernel/pd.h [6] base-hw/src/core/kernel/object.h

1 0

Trying to understand how capabilities are implemented
by Albin Otterhäll 19 Aug '23

19 Aug '23

Hi! I'm currently reading through Genode: Foundations, and I've some questions regarding the implementation that came up while reading section 3.1. Can you please confirm, or correct me if I've misunderstood something? It will help me understanding the content of the subsequent chapters 1. The RPC object A is created inside the protection domain 1, which result in the object identity A being created by the kernel. 2. A has a name, which is a natural number. Q1: Is the RPC object's name the value of a class variable of type int? 3. Protection domain 1 has a capability space insied the kernel. Q2: Is the protection domain seperate from the capability space in the kernel, and they're "connected" with some map somewhere? Q3: Is the capability space a map between natural numbers and some form of address to the object identity? I.e. the map work similar to a set of OO references, there the keys are variable names; and the values are the memory addresses of object identities. Q4: If the answer to Q3 is yes, does that mean that delegagion is some form of mechanism to share the adress of the object identity with other protection domains? Thanks for the help! -- Albin Otterhäll

1 0

CCC Camp 2023
by Stefan Kalkowski 14 Aug '23

14 Aug '23

Hello genodians, tomorrow the CCC Camp 2023 starts officially at Ziegeleipark Mildenberg [1]. If you attend the camp and if you are interested in a chat about Genode topics, or like to have a look at Sculpt OS running on top of PC, MNT Reform2, or Pinephone, please give me a sign. I'll be there from Tuesday afternoon to Saturday evening. Looking forward to see some of you there! Best regards Stefan [1] https://events.ccc.de/category/camp-2023/ -- Stefan Kalkowski Genode labs https://github.com/skalk | https://genode.org

1 0

23.05 image is good, still need help
by Johnny Nunez 11 Aug '23

11 Aug '23

Hi Genodians, I was running the latest image 23.05 but i can't seem to install anything? I get a lot of Error: HTTP response code said error (code=404), fail.... the only Depot that seem to work was ssumpf , and this one has Vbox , all I need, but then Vbox calls for other packages too that genodelabs and cnuke are not able to connect to. I guess i will keep trying.

2 1

Screensaver for the PinePhone
by Norman Feske 02 Aug '23

02 Aug '23

To all Sculpt-OS-on-the-PinePhone testers, I have just published a new Sculpt OS image for the PinePhone that includes a screensaver mode to increase battery time. You can download the image with version 2023-06-30 at [1], or use Sculpt's built-in system update feature, selecting me (nfeske) as image provider, and download and install the latest entry of my index. [1] https://depot.genode.org/nfeske/image/ The screensaver kicks in after ten seconds of user inactivity in the administrative user interface. It also can be manually activated by pressing the power button. While the screen is blanked, a press of the power button enables the display again. Under the hood, Sculpt completely removes the drivers for the display and the touchscreen while the screen is blanked, which considerably reduces the power draw. The system also switches the CPU to economic mode while the screen is blanked. Here are some illustrative data points: Max brightness in performance mode: 2.8 W Max brightness in economic mode: 2.6 W Low brightness in economic mode: 1.7 W Screensaver: 1.0 W As a caveat, I noticed that the screen-flickering issue, we sporadically observed in the past, occurs quite often when returning from the screensaver (aka after restarting the drivers). The flickering disappears after a while. However, maybe this way of reproducing the issue gives us the chance to eventually solve it. Have fun with trying out the new image! Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 4

Feedback on 23.05
by ttcoder＠netcourrier.com 26 Jul '23

26 Jul '23

Fellow Genodians, what follows is a minor observation and two (more serious) questions. 1) Suspend/resume The introduction of that feature in 23.02 triggered some "geek lust" in this aging geek, and now with 23.05 I got around to attempting system integration of suspend/resume in my stack. In Qemu it seems to all work fine (after I realized the vesa and input driver need to be restarted, reading acpi_suspend.run more carefully). However on bare metal (admittely years old), S3-suspend works well, but at resume time, the screen remains black. I thought maybe if the video driver causes trouble, I can try the "back door" (vnc), to validate the concept that everything works except vesa, and confirm I need to revisit my integration of vesa_drv. So I tried to connect via VNC, but no go, coming back from suspend. Could be that the nic_driver needs to be restarted as well (I didn't handle that, I only restart vesa and ps2_drv currently). I could persist, but this is not a feature I really need (just wanted it for "bragging rights" :^) so I'll probably wait for newer Genode releases, in case it's a matter of waiting for Genode upgrades. Very cool to have that feature almost at reach though. 2) Launching apps A newbie question ! (yes even after 5 years I still have those :-) How to launch components (applications). Grepping through the Genode repo, I came up with: - use a sub init with a generous RAM alotment (2 GB), and drive its config ROM through a report_rom: a list of launched apps has to be maintained by a "third actor" (not the sub-init, and not any of the client apps that require launching a process, but rather some sort of stand-by "registrar"), and its job would be to re-generate the sub's config ROM whenever that list grows as a new app is launched. Problem is, what happens when the user *quits* an application ? When that occurs, the app is still part of the sub-init's config, so next time sub reads its config, it's going to re-launch it, right ? This would otherwise seem to fit the bill well, if not for that problem of un-desired app relaunch. Maybe I can solve that problem by sending notifications every time an app is quit (if it's quit cleanly rather than crashing, at least), and the notification recipient (probably the "registrar" ?) would remove the relevant snippet from the sub-init's config. - loader_session: seems close enough too, and simplier to use, but the README says the ram/caps of the created child will be substracted from the caller, instead of from the launcher (i.e. the opposite of a sub-init). But I want to do the reverse. - fork/exec from libc : same as launcher_session, but seemingly with the (additional) awkwardness of old-style UNIX, where fork() creates a full duplicate of the caller, at least until exec() is called (so the caller app would need to have twice as much ram/caps as it needs, even if it just spawns something tiny like /bin/ls !). - sandbox.h : couldn't find a "tutorial" style usage of it via grep -r sandbox repos/, but maybe I should dive right in and experiment until I understand the gist of it, using the more complex use-cases in the repos ? - anything I missed ? 3) capability leak in pthread_create() (regression in 23.05 ?) Seems my stack triggers some sort of corner case that it did'nt before. This is a little more mission-critical, though it's a small leak and I haven't seen it really impact my apps so far. Anyway the observed behavior is, in many cases, pthread_create() behaves as it always had, allocates a new capability for the created thread, which is returned when the thread ends. But in some scenarios, the cap is not returned, so I'm leaking a cap for each created thread, or pthread_create() allocates _two_ caps instead of one ; this seems to depend on how soon the spawned thread is scheduled (i.e. before or after libc returns from create). Could be that the "corner case" is in my stack, not in Genode, of course. What angle to take to debug that ? I should probably create a ticket to discuss that issue. Cédric

3 2

openssl v3.X port for Genode
by Duss Pirmin 20 Jul '23

20 Jul '23

Hello Genodians Just a quick heads-up to avoid duplicate work. We need openssl v3.X support for a project we are working on. Therefore I'm currently creating a port of openssl 3.1.1. As some APIs have changed or were entirely replaced by new ones, I'm naming the port openssl3 so each component can choose which API version to use. Currently, I can build x86_64 and arm_v8a versions of libcrypto3.lib.so and libssl3.lib.so. Support for 32-bit platforms isn't required for us at the moment, so we have yet to enable support for other platforms. We plan to upstream the port to genode or genode-world eventually. Please let me know if someone is interested in the port so we can do the remaining steps. The port itself is relatively similar to openssl 1.1. It mainly is updated file lists. Regards, Pirmin

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
229
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users