users

users@lists.genode.org

1 participants
2310 discussions

now you can run http web server based on golang in genode 21.11
by Alexander Tormasov 23 Dec '21

23 Dec '21

I have a progress in porting of golang from gcc 10.3 to genode 21.11. Seems that now it suitable for external testing. More details in https://github.com/tor-m6/genode-world/blob/21.11/src/test/go_app/README.go… In particular, it is possible to run most of the golang programs, including tcp network (http server from net/http package) in SMP mode (tested on 4 cpu) on genode for nova, foc and linux, run inside qemu (or on linux), for x86_64. May be some other platforms works as well (except sel4- see below). To run you need 2 repos: https://github.com/tor-m6/genode.git Need to checkout 21.11 branch - while it have only one commit introducing .go as a target for compilation. support code is in repos/world (don’t forget to uncomment it) https://github.com/tor-m6/genode-world.git (Need to checkout 21.11 branch) I successfully run some tests with channels/async goroutines - some of them (Like Hanoi towers or barber serving) inside https://github.com/tor-m6/genode-world/blob/21.11/src/test/go_app/main.go also you can run network code like this: package main import ( "fmt" "log" "net/http" ) func main() { http.HandleFunc("/", HelloServer) fmt.Println("Server started at port 80") log.Fatal(http.ListenAndServe(":80", nil)) } func HelloServer(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hello, %s!\n", r.URL.Path[1:]) } Future plan: - add arm64 support - check sel4 problem - add automated generation of part of run file (all shared libs/binaries need to appears in appropriate places to unwind process works correctly) - check performance problems on sel4 and foc (probably timeouts/timer, waits too long in the very beginning) - try to integrate it in native mode to create workable «go build» code inside genode as native compilation. Note1: currently it can’t run on x86_64 sel4 because during initial golang stack unwind process it touch stack guard page, deeply inside _Unwind_Backtrace libgcc function (not sure why - probably this is compiler flags/optimisation issue). Once I have workable version with different debug options… Note2: May be it worth to add patch below permanently to main genode? diff --git a/repos/base/mk/generic.mk b/repos/base/mk/generic.mk index 66e5c309c..aea75e342 100644 --- a/repos/base/mk/generic.mk +++ b/repos/base/mk/generic.mk @@ -7,7 +7,7 @@ # Collect object files and avoid duplicates (by using 'sort') # SRC_O += $(addprefix binary_,$(addsuffix .o,$(notdir $(SRC_BIN)))) -SRC = $(sort $(SRC_C) $(SRC_CC) $(SRC_ADB) $(SRC_ADS) $(SRC_RS) $(SRC_S) $(SRC_O)) +SRC = $(sort $(SRC_C) $(SRC_CC) $(SRC_ADB) $(SRC_ADS) $(SRC_RS) $(SRC_S) $(SRC_O) $(SRC_GO)) OBJECTS = $(addsuffix .o,$(basename $(SRC))) # @@ -69,6 +69,16 @@ endif $(MSG_ASSEM)$@ $(VERBOSE)$(CC) $(CC_DEF) $(CC_C_OPT) $(INCLUDES) -c $< -o $@ +# +# Compiling Go sources +# +%.o: %.go + $(MSG_COMP)$@ + $(VERBOSE)$(GOLANG) $(CUSTOM_GO_FLAGS) -c -o $@ $< + +CUSTOM_GO ?= $(CROSS_DEV_PREFIX)gccgo +GOLANG = $(CUSTOM_GO) + # # Compiling Ada source codes #

3 4

Genode and sign-conversion warnings.
by Piotr Tworek 21 Dec '21

21 Dec '21

Hello, Since Wconversion got enabled on Genode master branch I'm wondering if there are any plans WRT Wsign-conversion warnings? I presonally find it a bit strange GCC Wconversion does not also enable Wsign-conversion. IMO implicit conversions between signed and unsigned types are as often as bad as implicit conversion between types of different size. /ptw

2 2

CBE key encryption
by Stefan Thöni 19 Dec '21

19 Dec '21

Hello Genodians, we are still working to add hardware-based encryption to CBE. To this end, we have implemented a custom trust anchor and crypto engine. Generating a key, encrypting this key on behalf of cbe_init and decrypting it again on behalf of the vfs_cbe plugin works fine. But then the vfs_cbe requests to have a all zero key encrypted which due to the ICV added by hardware black key handling fails. We cannot seam to find out where the request originates or why vfs_cbe would ever encrypt any key, let alone a key of all zeros. Any pointer or idea would by very welcome. Kind regards Stefan

4 4

Silly Sculpt Build Problem
by John J. Karcher 16 Dec '21

16 Dec '21

Hello, Recent updates to Debian Unstable seem to be causing a few minor build problems in Genode. Automake being updated from 1.15 to 1.16 was simple to solve, but I have another problem that I'm not sure how to solve. Depending of whether I'm building a disk image or an ISO, I get one of the following errors: Error: 'e2mkdir' command could be not found. or: Error: 'xorriso' command could be not found. But both of those commands are available, and worked up until recently. Does anyone have any thoughts on what might cause this? Thanks! -- John J. Karcher devuser(a)alternateapproach.com

4 7

VFS plug-in that requires early libc initialization (for FUSE)
by ttcoder＠netcourrier.com 08 Dec '21

08 Dec '21

Hey Genode team, fellow Genodians, I'm trying to modify FUSE-server to become a VFS plug-in (see genode-world#193) but it seems "with_libc()" no longer works, when in a plug-in attached to the test-libc_vfs test harness: [init -> test-libc_vfs] ---->open_Dir [init -> test-libc_vfs] Error: Uncaught exception of type 'Libc::Kernel::Kernel_called_prior_initialization' [init -> test-libc_vfs] Warning: abort called - thread: ep Questions: --------- Seems a VFS plug-in is initialized first, before libc has had a chance to be initialized ? While digging in the code, here is what I can gather: in the previous incarnation of the code, where FUSE is an FS server, the server would call Libc::Component::construct() early, which would initialize the libc/kernel: kernel = *unmanaged_singleton<Libc::Kernel>(..) and then subsequent calls to libc would work. But now, the VFS plug-in (and its libc-using code) is called first. Is that the right explanation for my problem? Alternative explanation: maybe the libc framework from the _host_ component is not shared with its child VFS plug-in at all ? Tracing: ------- I then removed calls to libc, and added some tracing to the now free-flowing code, to get some sense of chronology, determine who is called when. The result was interesting: it seems when a VFS plug-in is instantiated, its hooks are called before anything else is called (I'm not the one calling them, as my code is still at an early "skeleton" stage yet, I make no call to opendir() etc, so someone else is doing that), including even before the host "Main" : [init -> test-libc_vfs] ---->open_Dir [init -> test-libc_vfs] ---->num_dirent [init -> test-libc_vfs] ---->directory [init -> test-libc_vfs] ---->directory [init -> acpi_drv] SMBIOS table (entry point: 0x165700 structures: 0xf5720) [init -> platform_drv] ECAM/MMCONF range 00000000:00000000.0-000000ff:0000001f.7 - addr [00000000b0000000,00000000c0000000) [init -> test-libc_vfs] test-libc-vfs: ctor of struct Main : reading config ROM [init -> test-libc_vfs] test-libc-vfs: entering with_libc() [init -> test-libc_vfs] test-libc-vfs: calling test() from libc context [init -> test-libc_vfs] ---->leaf_path [init -> test-libc_vfs] Error: Uncaught exception of type 'Test_failed' So based on that 'evidence' alone, it would seem the event chronology is somewhat like this: - test-harness is loaded by LD - LD looks for its plugins, loads them, and executes them first (even if they require libc) - test-harness / struct Main is called, initializing libc etc Maybe my FUSE plug-in should detect when libc is not yet initialized, reject all calls to its hooks done at that early time, and only honor them later on ? Cedric

2 3

RISC-V Genode availability ?
by Turlough Suilleabhain 08 Dec '21

08 Dec '21

Question: Is the RISC-V seL4 implementation only available for the Hensoldt Cyber MIG-V processor as Trentos-G or is that source tree branch intended for wider public release and other RISC-V processors ? Thank you in advance..

2 1

CfP: Microkernel and Component-based OS Devroom at FOSDEM 2022 (fwd)
by Christian Helmuth 07 Dec '21

07 Dec '21

Hey Genodians, FOSDEM 2022 will be an online event (again), but the traditional Microkernel devroom will be part of it. Thanks to Martin Decky for engagement! The original Call for Papers follows. Best regards Christian Date: Mon, 6 Dec 2021 16:55:45 +0100 From: Martin Decky <martin(a)decky.cz> To: microkernel-devroom(a)lists.fosdem.org Subject: CfP: Microkernel and Component-based OS Devroom at FOSDEM 2022 Microkernel and Component-based OS Devroom at FOSDEM 2022 CALL FOR PARTICIPATION On-line version of this CfP: http://fosdem.microkernel.info/ The developers and users of several free and open source microkernel-based and component-based operating systems will meet on-line as part of FOSDEM 2022 [1] and will share a developer room. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-based, unikernel-based, component-based operating systems and similar topics. The devroom has been preliminarily scheduled to Saturday February 5th 2022. The devroom will take place during European day hours. Possible topics of the devroom include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * languages, tools and toolchains used * enabling support for hardware (architectures, device drivers) and programming languages * development processes, debugging * maintenance, testing and release engineering * safety, security and robustness * trends and challenges * research and open questions * community and governance * use cases, experiences and status updates * best practices and lessons learned * demos This is a call for your participation. We kindly ask you to submit your proposals no later than on December 28th 2021. Please use the Pentabarf web site [2] to submit your proposals. If you already have a user account in Pentabarf, please do not create a new one. Addtionally, make sure to select the Microkernel and Component-based OS Devroom as the track when submitting your talk and include at least the following information in your proposal: * title of your talk * your full name * short abstract of your talk (one or two paragraphs) * duration of your talk (at least 20 minutes and no longer than 50 minutes) * your short bio * your photo The talks will be pre-recorded in advance in January and streamed automatically during the event. This means that you will need to complete and submit your talk recording by January 15th 2022. However, each speaker should be also present on-line just after the streaming of their talk for a live Q&A. You can specify your prefered time slot of your talk. The communication language of the devroom is English. The official devroom schedule (along with the accepted talks) will be announced on December 31st 2021 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM web site. For any comments, questions and suggestions (e.g. suggestions for a different type of event during the devroom), please do not hesitate to use the devroom's mailing list [3]. About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012 [4], this devroom has been a part of each following FOSDEM (with slight variations of the name). The focus gradually widened to include component-based, unikernel-based and other operating systems. By now, it has become a somewhat institutionalized tradition for the open source operating systems community and it is one of the few places where microkernel enthusiasts and people with different views on how operating systems should work meet regularly. To this date, over a dozen projects have participated in one way or another. Many of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Extraordinary Circumstances in 2022 (Again) Due to the extraordinary mode of organization of FOSDEM 2022 (being an on-line event again), the devroom talks will be required to be pre-recorded in January and streamed during the event (with a live Q&A). The talk videos will be published under Creative Commons license by FOSDEM. By submitting a recorded talk, the speaker agrees to have it made available publicly indefinitively. For organizational purposes, we also need contact information of the speakers of accepted talks. Please check the official CfP page [5] of the devroom regularly. We will keep updating it as technical guidelines will be set by the FOSDEM organizers. Microkernel Dinner Sadly, it will not be possible to arrange our traditional microkernel dinner and other in-person social gatherings in Brussels this time again. However, we plan a closing event of the devroom as a loose approximation of the microkernel dinner. The details will be announced later. We encourage the on-line participats to bring their own food and beverages. About FOSDEM FOSDEM [6] is a two-day event organized by volunteers to promote the widespread use of free and open source software. FOSDEM is widely recognized as one of the best such conferences worldwide. FOSDEM covers a wide spectrum of free and open source software and hardware projects and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and proposals. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. In recent years, FOSDEM has been hosting more than 5000 developers annually at the ULB Solbosch campus. Due to the circumstances, FOSDEM 2022 will be organized as an on-line event. The participation in FOSDEM is totally free, although the organizers gratefully accept donations and sponsorship. No registration is necessary, but attendees are expected to follow the FOSDEM's code of conduct [7]. Important Dates Recap * 2021-12-28: Deadline for talk proposal submission * 2021-12-31: Schedule published and speakers notified of acceptance * 2022-01-15: Deadline for talk pre-recoding submission * 2022-02-05: Devroom taking place on-line Contact In case of any comments, questions and suggestions, please do not hesitate to contact the devroom organizers via the devroom's mailing list [3]. The primary organizers of the devroom in 2022 are: * Sebastian Sumpf * Martin Decky Links [1] https://fosdem.org/2022/ [2] https://penta.fosdem.org/submission/FOSDEM22/ [3] https://lists.fosdem.org/listinfo/microkernel-devroom [4] https://archive.fosdem.org/2012/schedule/track/microkernel_os_devroom.html [5] http://fosdem.microkernel.info/ [6] https://fosdem.org/ [7] https://fosdem.org/2022/practical/conduct/ _______________________________________________ microkernel-devroom mailing list microkernel-devroom(a)lists.fosdem.org https://lists.fosdem.org/listinfo/microkernel-devroom ----- End forwarded message ----- -- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · https://www.genodians.org/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

[Proposal] How to work with passwords in genode
by Uwe 30 Nov '21

30 Nov '21

Hello all, I have done some work for specifying a way to use passwords to connect two instances of genode. The most work was done in minimalizing the codebase that is needed to implement all functionality. Nevertheless I'm not sure I have found the point of minimal (algorithmic) complexity. Therefore I want to describe the point found (with rationale) and listen to comments before doing further work in this direction. First I represent all strings in the protocol as their hashes turned into points on an elliptic curve. Rationale: Because curve points are needed anyway to encrypt the traffic between the two instances of genode and in this protocol at least partly represent the connected parties I want to reuse that in the password protocol. Second I want to associate every PD with a secret key, that is only available to that PD. For this I would propose that core should host an implementation of the PBKDF2 function with a fixed salt. This function should turn the trusted path of its client into a cryptographic random string. This string can then be used to produce individual and stable cryptographic keys in every component that uses this functionality. To reuse as much functionality as possible I would propose to use a ROM session with a special name ("keysalt" comes to mind) to implement this functionality. Rationale: I would expect that in the future many components will need to store cryptographic material from shutdown to boot. Therefore a central facility to help there could be advantagous. Third I want to be able to externally configure the connections with as much privacy as possible. That privacy comes in handy when it is needed to store passwords. Rationale: Especially in embedded there may not be a possibility to enter connection information. And I don't want to have to implement two different protocols for the same functionality. I think this makes this the most general description of my approach: Name all items (computer, components, user, passwords) with points on an elliptic curve with known logarithms. Connect them with a data structure that encrypts that connection in such a way that this connection is only visible to those who are connected, expressed as those who know the relevant logarithms. Now a little more detail: The most important information needed to understand the concept is the construction of the connecting data structure. It consists of three points on an elliptic curve. Two of them are simple. I will describe this structure by giving the algorithm to compute it. First you have the points A and B which name the proverbial Alice and Bob, the items which should be connected. You need to compute the points K,R and C which make up the data structure. 1. Choose a random point on the elliptic curve and name it R. (I said it was simple :-) 2. Choose a random scalar k, multiply it with the generator G and name the result K. (Two points down and hardly a sweat. And independend of A or B!) 3. Compute R-kA and call it D. 4. Also compute R-kB and call it E. 5. Hash D (with possibly some identifying string for Alice) to a scalar d. 6. Hash E (with possibly some identifying string for Bob) to a scalar e. 7. Compute k(eB+dA) and name this point C. The data structure consists of the points K,R and C and the identifying information used in the hash (possibly implicit). To use that information Alice (for example) computes this: 1. Compute R-aK and call it D. 2. Hash D (with identifying information) to scalar d. 3. Compute C-daK (where 'a' is the private key to A) and call it F. 4. Compute daF and call it M. M is the same point for both A and B but not for other keys. >From M there can be calculated a common key and a common string for connecting (for instance a channel on IRC). Over this a method for more direct communication (for instance DCC) can be negotiated. Of course encrypted. Or in the case of a password M can be used in a PAKE implementation. Now to the mapping of items to points: - component This component runs in a PD. That PD is associated (via "keysalt") with keying material. From this a public key can be calculated and that point will be the name of the component. - computer There needs to be a component that makes the computer available on the network. The key of this component is modified by multiplying with its own secret key to make a difference between the name of the computer and the name of any component. - user The users name string is hashed with the point that names the computer where the user is registered. That makes users name point unique even in case of the same name string. Because that scalar is not really secret the point derived from this can not be used as a key. Not even in the connection data described above. But it can be encrypted with ElGamal and used to lookup records in a database. - password The users name point is hashed together with the password string to a scalar. This scalar is divided by a random scalar and multiplied with the name point of the computer where the multiplicator is stored. The resulting point must be transfered together with the name point of the user to the computer where the multiplicator is stored. That computer looks up the record of the user with its name point. When it has found the record it checks the last access time and waits a little bit and returns the provisonally password point multiplied with the multiplicator. If no record is found the users name point is hashed together with some secret key to compute a fake multiplicator. In every case a point for the calculation of a password point is returned after a delay. (Rationale: By splitting the password and delaying the calculation a brute force attac is legthened into impractical times.) The returned point is then multiplied with the random scalar from above and the result is then hashed again with the password string to the password scalar. That password scalar is then multiplied with the generator point to obtain the password point. This password point is only used to generate a connecting data structure together with the component name point of the component that is authenticated to. And the password scalar is needed to open this connecting data structure. The connecting data structure is stored in a record together with the users name point and returned if questioned with the (encrypted) users name point. Rationale for making hashes dependent on points: In the password algorithm it protects against some esoteric cases of password theft. Maybe the connection data structure protects as well but I leave them in because double protection is better than faulty protection. And when this is implemented anyway I would want to use the same routine for all hashes and use the points for domain separation (or the string in case of M). It can also protect against faults in the hash algorithm. For instance SHA1 is broken, HMAC-SHA1 is not,last I heard. So I would opt for using the pattern of HMAC with the point as key. I hope I didn't overwhelm you with so many details. But I think they are needed to get an idea of the direction I think is the most advantageous. If you think the most advantageous lies in another direction entirely, please tell me so. If you need more details please ask. But I wont promise a satisfying answer in short time because I would have first to think about it. But I have some inkling of the direction(s) that are possible so a handwavey answer is possible in short time. So if you ask, please include some indication which way lay your preferences for the answer.

1 1

Announcement: Genode OS Framework version 21.11 released
by Norman Feske 30 Nov '21

30 Nov '21

Today, we released the version 21.11 of the Genode OS Framework: https://genode.org/news/genode-os-framework-release-21.11 During this release cycle, we focused on device drivers. Thanks to the new DDE-Linux approach featured by the previous release, we were able to transplant the display and touchscreen drivers for the Pinephone from the Linux kernel to Genode. The drivers are reused without modifications, but each one is sandboxed independently as a separate component. The i.MX8 SoC family enjoys the most comprehensive Genode support among the 64-bit ARM platforms. The new version advances the driver coverage further by the means of a new USB host-controller driver that improves the performance of isochronous devices like webcams, and a new GPU driver for the Vivante GPU. Speaking of GPUs, we maintained the steady pace of our work on hardware-accelerated graphics and are proud the announce the support for Intel Gen9 and newer GPUs by our custom Intel GPU multiplexer. The topics outlined above barely scratch the surface. For the whole picture, please enjoy skimming the release documentation linked below. The major improvement at a glance: - Modularization of Genode's board-support code base - Drivers - Interactive scenarios on the Pinephone (touch + graphics) - New USB driver for NXP i.MX8 - New Vivante GPU driver and etnaviv Mesa driver - New VirtIO input and framebuffer drivers - Hardware-accelerated graphics with Intel Gen9+ GPUs - New support for the Xilinx Zynq-based USRP E310 board - Feature completion of VirtualBox 6 - Sculpt OS for 64-bit ARM in addition to x86 - Audio and OpenGL support for libSDL2 - Automated boot-image creation for i.MX8, Zynq, Allwinner The full documentation of the changes is available here: https://genode.org/documentation/release-notes/21.11 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

Wacom Touchscreen / Pen Driver
by John J. Karcher 28 Nov '21

28 Nov '21

Hello, I was just wondering if anyone has had the itch to finish converting the Wacom touchscreen / pen driver, possibly with the benefit of the newer Linux driver conversion tools? I've tried a couple of times, but it's beyond my skill set (and time to learn). Thanks! -- John J. Karcher devuser(a)alternateapproach.com

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users