users April 2018

users@lists.genode.org

20 participants
15 discussions

Defence of "Microkernelization of Linux"
by Johannes Kliemann 13 May '18

13 May '18

Hello Genode folks, I want to invite you to the defence of my student thesis "Microkernelization of Linux" (and enabling native Genode driver support on base-linux). It will take place in the Andreas-Pfitzmann-Bau room 3105 at 11:00. Regards, Johannes Kliemann

2 4

interrupts on AMD hardware
by Nobody III 06 May '18

06 May '18

Has anyone gotten any Genode drivers to work on computers with AMD processors? The only one that I've gotten to work was fb_drv, which doesn't need to receive interrupts. The other 2 drivers that I've tried recently, usb_drv and ahci_drv, both hang. Has anyone had better compatibility here?

5 16

acpica issues
by Boris Mulder 25 Apr '18

25 Apr '18

Hi all, I tried diving into the acpica utility to check if I can make the state reports work on some of our machines. Currently I am testing it on the lenovo x250 and the hp 840 laptops. However, I am not sure how and if to proceed here. The current behaviour is as following: When the machine starts up, it produces the reports of acpi_ac and acpi_battery correctly. When I disconnect the power outlet, these reports do not get updated. instead, I do get acpi_ec report updates on some of the different events, such as connecting and disconnecting the laptop to AC. These events have different values on the different laptops. The ec report acpica produces on the hp840: [init -> acpi_report_rom] report 'acpica -> acpi_ec' [init -> acpi_report_rom] <acpi_ec> [init -> acpi_report_rom] <ec> [init -> acpi_report_rom] <data value="8" count="36">triggered</data> <-- this is added on a charge up event (it seems to trigger periodically when the battery is not full and AC is connected [init -> acpi_report_rom] <data value="9" count="53"/> <-- this is added on a charge down event (it seems to trigger periodically when the battery is not full) [init -> acpi_report_rom] <data value="6" count="2"/> <-- AC connect/disconnect event (this triggers once when disconnecting and once when connecting) [init -> acpi_report_rom] </ec> [init -> acpi_report_rom] </acpi_ec> on the x250: [init -> acpi_report_rom] report 'acpica -> acpi_ec' [init -> acpi_report_rom] <acpi_ec> [init -> acpi_report_rom] <ec> [init -> acpi_report_rom] <data value="38" count="1">triggered</data> <-- AC disconnect event (this triggers once when disconnecting) [init -> acpi_report_rom] <data value="77" count="1"/> <-- AC connect event (this triggers once when connecting) [init -> acpi_report_rom] <data value="39" count="1"/> <-- AC connect event (this also triggers once when connecting) [init -> acpi_report_rom] </ec> [init -> acpi_report_rom] </acpi_ec> Some observations: * The charge/discharge events do not work on the x250. * On the hp840 connecting and deconnecting share the same data value. * On both laptops, disconnecting and reconnecting the AC outlet only triggers the ec report once, and doing it again does not produce a report. Reconnecting AC a second time also seems to cause the charge events to stop being reported on the hp840. * The lid report only works on the hp840. * The power button works on the hp840 and only works on the x250 if you press it for a longer time (but not so long as to turn off the device). * Ideally, for some device, such as one of the above, we would like all of these reports to be updated correctly. I have some questions about this: * You mentioned in your issue about sculpt EA that the reports not getting updated are a known issue. Do you have any plans of fixing this in the future? * Do you think solutions to this issue are going to be device specific? Which parts are generally the same for different laptops? * Is the difference in handling of the events on these machines caused by the acpica C code not supporting these machines, or by the Genode code not supporting them? or both? * A workaround could be installing a timer and generating the initial reports periodically. Do you think this would be worth implementing or would fixing the problem be easier? * For device specific parts: suppose it works on your test setup, how should we proceed to make it work on other hardware? -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)

2 1

SMC Calls in Trustzone VMM Scenario
by Mauricio Gutierrez 23 Apr '18

23 Apr '18

Hello, I have been doing some work with the Genode Trustzone VMM scenario on my i.MX53 development board and I am having a bit of trouble understanding how the SMC calls work between the normal and secure world. Online you talk about how you implemented 6 calls in the modified normal world linux kernel but in the main for the tz_vmm I only found 4 different cases in the _handle_smc() function. In any case, I wanted to add my own call and was able to add it and check that the required arguments are passed correctly and everything so that part I think I understand. However, I need to do some of the handling in Monitor Mode and my understanding was that an SMC would throw your into monitor mode but it seems the handler operates in user mode? Since it is not privileged then I am not able to call a "cps #22" to switch to monitor mode. In an earlier thread I know you refer to the section "World switch between non-secure world and secure > world" in http://genode.org/documentation/articles/trustzone. But I am still uncertain as to how I could get my case in _handle_smc() to enter monitor mode so that I can play around with the NS bit without leaving secure world. I have been studying what happens when I call an smc, say "smc #4" from normal world. But I have not been able to exactly pin point, where is the entry point for such an exception in the Genode secure world call? What exactly happens once I make that call to secure world and where I can I find/follow the code? Is this covered somewhere in your book? I know about the mode_transitions.s file as well as the exception_vector.s and vm.cc files in repos/base-hw/src/core/spec/arm_v7/trustzone, it seems this is the entry point? But where does it go after we call the nonsecure_to_secure transition? Most importantly, I need to understand where is the code operating in monitor mode? Where does it end and where does it start? How can I tell? If I needed to write at least some part of my smc handler in monitor mode before it switches out, what is the best approach to doing that? I apologize for all the questions and would appreciate any help and guidance you can provide. Thank you, Mauricio

2 5

waiting for RPC method to be called
by Nobody III 22 Apr '18

22 Apr '18

How do I get a component to wait for an RPC method to be called? Can I use a semaphore, or will that block RPC calls? Do I need a thread dedicated to handling RPC? If so, should I create a new Rpc_entrypoint and tell it to manage the Rpc_object?

2 2

Genode::Slave::Policy::resolve_session_request() should be virtual
by Nobody III 20 Apr '18

20 Apr '18

Currently, Genode's Slave API is designed to create child components and request services from them. However, it does not allow the parent component to provide services to the child. Making Genode::Slave::Policy::resolve_session_request() virtual would fix this.

1 0

block device
by Duss Pirmin 20 Apr '18

20 Apr '18

Hello all I have a notebook with two relatively small SSDs. To use the sculpt scenario on it, I would like to use the two as one in a RAID 0 configuration. Is there already a possibility to do this, or should I implement a block device merger component that can be configured to join up multiple block sessions in to one? Best regards Pirmin

2 1

Placing Qt5 Windows on Genode Startup
by Johnathan Gohde 16 Apr '18

16 Apr '18

Hello, I've been trying to figure out how to give an initial window placement for Qt5 applications on startup. I've tried to mimic the example set in ported applications, like found in qt_launchpad/main.cpp:89, using a window.move(0,0) call in my application, but this doesn't place the window in the corner. Can anybody help me out or point me in the right direction? Thanks, -- Johnathan Gohde Senior Research Scientist Adventium Labs

2 1

preparing ports
by Roman Iten 13 Apr '18

13 Apr '18

Hi I have problems preparing some ports (on current master, d54f95d49): gnupg generate gnupg.hash Error: ports/ports/gnupg.port is out of date, expected de58de758b6ff17d573b5f17f5c8264693c1e6ff fatfs prepare port fatfs download http://www.elm-chan.org/fsw/ff/arc/ff13a.zip Error: Hash sum check for fatfs failed egl_api prepare port egl_api download https://www.khronos.org/registry/EGL/api/EGL/egl.h Error: Hash sum check for egl.h failed Can anybody help me? Thanks, Roman

2 1

Proposal for nic_tap component
by Martijn Verschoor 13 Apr '18

13 Apr '18

Hi everyone, I would like to pitch an idea to improve network protocol debugging on Genode. I value the verbosity option of the `nic_router` and the `nic_dump` components, but sometimes I'd like the ability delve deeper into packets, like I am used to with Wireshark. But extending the log based network debugging in Genode to reach that level of detail clearly doesn't make sense. Another option is to introduce an intercepting `nic_tap` component that implements a bump-in-the-interface between a Nic client and a Nic server and duplicates all packets between the client and the server to a dedicated Nic tap interface. A Nic client connected to the Nic tap interface is presented with all network packets, both up- and downstream, of the intercepted Nic session. The nic_tap is especially useful when running on real hardware. There are various ways to use the nic_tap. An obvious scenario is to setup an instance of VirtualBox with Linux and Wireshark that is routed to use the Nic tap. But it should also be possible to route the Nic tap to an external Nic interface (granted that you have a solution to tie two Nic clients together, but thatâs easy enough). In my view the nic_tap would be a valuable and complementing addition to the set of Genode network debugging tools. What do you think, would you benefit from such a component? -- Met vriendelijke groet / kind regards, Martijn Verschoor Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office) | +31 616 014 087 (mobile)

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users April 2018