users

users@lists.genode.org

2285 discussions

fetchurl with lxip socket in separate vfs
by Stefan Thöni 03 Aug '18

03 Aug '18

Hello Genodians, I noticed that after switching from 18.05 to 18.06 a fetchurl component using an lxip socket in a separate vfs component couldn't resolve hostnames any more. Resolving still works when the lxip sockets is in the vfs of the fetchurl component itself. Is there any change in 18.06 that might lead to this problem? Best regards Stefan -- Freundliche Grüsse Stefan Thöni Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

1 0

Definition of ram quota
by Jan Siddartha Hussmann 01 Aug '18

01 Aug '18

Hello Genodeans I was wondering what the difference is when stating how much ram a component gets. There is the attribute version like in runtime: <runtime ram="1000M" caps="2600" binary="init"> or int the deploy config: <start name="vm1" ram="3400M" pkg="insidioussid/pkg/vm_slice/2018-06-06" version="1"> However starting a package inside a runtime it usually is like this: <start name="ram_fs"> <resource name="RAM" quantum="2M"/> ... What is the reason for these two different versions? Kind regards, Sid

2 1

vfs_cow
by Roman Iten 30 Jul '18

30 Jul '18

Hello I created a vfs package archive containing vfs and vfs_cow and start it within the sculpt runtime providing the following configuration: <config> <vfs> <dir name="immutable"> <fs label="template_data"/> </dir> <dir name="mutable"> <fs label="user_data"/> </dir> <dir name="cow"> <cow ro="/immutable" rw="/mutable"/> </dir> </vfs> <default-policy root="/cow" writeable="yes"/> </config> Then, I changed the "target" file system of the noux package to use the above copy-on-write file system to play around with it... First thing I noticed is that the directories and files of "template_data" are not populated. I guess that's a feature that is not yet or will not be implemented and for my use case it doesn't bother me right now. But when I open/write a file (that exists in template_data), cow_vfs writes the following output: [runtime -> cow_fs] Warning: COW: block for replication... [runtime -> cow_fs] Warning: COW: block for replication... ...and never unblocks afterwards. If immutable is something like </ram> or </inline ...>, it works as I would expect it. Is this a known limitation? Or can someone point me to the right direction to solve it? I love the idea of the vfs_cow component and I guess it may cover many other use cases! Cheers, Roman

2 4

Fullscreen VM in sculpt
by Pirmin Duss 25 Jul '18

25 Jul '18

Hello Genodeans I would like to use my virtual machine in fullscreen mode on my sculpt. If I'm interpreting the configuration of the floating_window_layouter correctly, the key combination [SCREEN]+[ENTER] will toggle the fullscreen mode of a window. Further there is a normally disabled configuration in /config/input_fliter that remaps the key [LEFTMETA] to [SCREEN]. However when I enable the remapping and start the wm and the virtual machine, pressing [LEFTMETA] and [ENTER] as described in the sequence of the layouter.config nothing happens. Do I need to change something else? Best regards, Pirmin

5 8

Sculpt - default partition GENODE*
by Tomasz Gajewski 21 Jul '18

21 Jul '18

In the documentation of Sculpt-TC there is: The storage dialog hosts a convenient "Default" button that allows one to toggle a partition label between "GENODE" and "GENODE*". I don't have such a button. Is it a bug in documentation, bug in code or there are some restrictions under which it should appear? Regards Tomasz Gajewski

2 2

Creating an IRQ session
by Harsha Sharma 20 Jul '18

20 Jul '18

Hello, I get the following error when child component issues a session request for IRQ session: Error: Binding IRQ to the ICU failed But parent returns a session capability and then Error: unavailable IRQ requested I just want to test implementing different kind of sessions. Any help will be really appreciated. Thank you so much for your time. Regards, Harsha Sharma

2 4

Error: ID space not empty at destruction time
by Stefan Thöni 20 Jul '18

20 Jul '18

Hello Genodians, when the verify tool is terminated by removal from the init config after having done its job both ram_fs used for public and depot yield an "Error: ID space not empty at destruction time". Should I worry about these errors? Bests Stefan -- Freundliche Grüsse Stefan Thöni Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 1

lxip vfs and RM-session
by Stefan Thöni 19 Jul '18

19 Jul '18

Hello Genodians, I'm currently trying to use a lxip stack in a vfs component (name tcpip) in a package in the sculpt runtime. This fails with the following error: [runtime] Warning: upd: no route to service "RM" [runtime -> upd -> tcpip] Error: RM-session creation failed (ram_quota=65536, cap_quota=2) [runtime -> upd -> tcpip] Error: __cxa_guard_abort called [runtime -> upd -> tcpip] Error: failed to create <lxip> VFS node [runtime -> upd -> tcpip] Error: dhcp="yes" The RM-session seems properly configured in both runtime and deploy. The "tcpip" vfs component then continues to run and accepts file system session, but obviously the socket part doesn't work. [runtime -> upd -> tcpip] session opened for 'subinit -> tcpip' at '/' [runtime -> upd -> subinit -> fetchurl] fetch https://... [runtime -> upd -> subinit -> fetchurl] Error: failed to open new socket at /tcpip/socket/udp/new_socket [runtime -> upd -> subinit -> fetchurl] Error: Couldn't resolve host name, failed to fetch https://... Any ideas what the problem with said RM-session could be? Bests Stefan -- Freundliche Grüsse Stefan Thöni Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 1

Re: Linker Issues in base-hw for an Armv8 Implementation
by Bob Stewart 19 Jul '18

19 Jul '18

Looks like my reply from yesterday got held up for being too long. Shorter version:- There is actually no error message indication why the linker failed. Assuming that it was because --build-id was expected later in the linker operations, I added the linker option -Wl, --build-id=none to the final image linker command in build_core. That resulted in the linker completing successfully and sensible image sizes being created as shown in the objdump output: objdump-p ../build/dragonboard/var/run/log.bootstrap|more ../build/dragonboard/var/run/log.bootstrap: file format elf64-little Program Header: LOAD off 0x0000000000001000 vaddr0x0000000081000000 paddr0x0000000081000000 align 2**12 filesz0x000000000003b840 memsz0x000000000003b840 flags r-x LOAD off 0x000000000003d000 vaddr0x000000008103c000 paddr0x000000008103c000 align 2**12 filesz0x00000000000041fc memsz0x000000000000d109 flags rw- LOAD off 0x00000000000411fc vaddr0x0000000000000000 paddr0x0000000000000000 align 2**12 filesz0x0000000000000000 memsz0x0000000000000000 flags r-- The executable image produced, image.elflooks okwith a quick scan using readelf. Sebastian, do you have any thoughts on why the linker gets upset with when the .note.gnu.build <http://note.gnu.build>-idsection is not discarded? Thanks, Bob Get Outlook for Android <https://aka.ms/ghei36> ------------------------------------------------------------------------ *From:* Bob Stewart <robjsstewart(a)gmail.com> *Sent:* Wednesday, July 18, 2018 1:55:02 PM *To:* users(a)lists.genode.org *Subject:* Re: Linker Issues in base-hw for an Armv8 Implementation There is actually no error message indication why the linker failed. Assuming that it was because --build-id was expected later in the linker operations, I added the linker option -Wl, --build-id=none to the final image linker command in build_core. That resulted in the linker completing successfully and sensible image sizes being created as shown in the objdump output: objdump -p ../build/dragonboard/var/run/log.bootstrap |more ../build/dragonboard/var/run/log.bootstrap: file format elf64-little Program Header: LOAD off 0x0000000000001000 vaddr 0x0000000081000000 paddr 0x0000000081000000 align 2**12 filesz 0x000000000003b840 memsz 0x000000000003b840 flags r-x LOAD off 0x000000000003d000 vaddr 0x000000008103c000 paddr 0x000000008103c000 align 2**12 filesz 0x00000000000041fc memsz 0x000000000000d109 flags rw- LOAD off 0x00000000000411fc vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12 filesz 0x0000000000000000 memsz 0x0000000000000000 flags r-- objdump -h ../build/dragonboard/var/run/log.bootstrap |more ../build/dragonboard/var/run/log.bootstrap: file format elf64-little Sections: Idx Name Size VMA LMA File off Algn 0 .text 0003b840 0000000081000000 0000000081000000 00001000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000718 000000008103c000 000000008103c000 0003d000 2**3 CONTENTS, ALLOC, LOAD, DATA 2 .got 000000e0 000000008103c718 000000008103c718 0003d718 2**3 CONTENTS, ALLOC, LOAD, DATA 3 .got.plt 00000018 000000008103c7f8 000000008103c7f8 0003d7f8 2**3 CONTENTS, ALLOC, LOAD, DATA 4 .eh_frame 00003084 000000008103c810 000000008103c810 0003d810 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gcc_except_table 00000968 000000008103f894 000000008103f894 00040894 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .bss 00008f09 0000000081040200 0000000081040200 000411fc 2**3 ALLOC The executable image produced, image.elf looks ok with a quick scan using readelf. Sebastian, do you have any thoughts on why the linker gets upset with when the .note.gnu.build-id section is not discarded? Thanks, Bob

1 0

Linker Issues in base-hw for an Armv8 Implementation
by Bob Stewart 18 Jul '18

18 Jul '18

Hi, I realize my issues are far from the current mostly-Sculpt roadmap, but perhaps someone can throw some light on my problems...at least I'm dealing with current hardware devoid of parallel ports :o I've been carefully creating a build structure in base-hw that will support armv8 and at least AArch64 over the past several months. I'm at the point where I have made all the architectural additions to support armv8 and the arm64 assembler which includes support for the assembler instruction changes from armv7, execution modes, and exception levels (only EL0 and EL1, initially). Everything builds for a cortex A-53 platform but fails in the final linking steps in two ways as described below. But first, my build tools are a copy of the Linaro toolchain, version 6.4.1, which used binutils 2.27, and my CROSS_DEV_PREFIX points to its location. I'm building in Genode 18.02 1. The final linking step fails initially with the "_impure_ptr" global not being resolved (see the build output in build_impure.log). Typically this global is supplied via libc, but Genode's special libc does not contain it. This global is a pointer to a structure that contains "errno" from failed C-code execution, along with some concurrency data for threading, if remember correctly. The pointer is only used in vterminate.cc which comes from the toolchain. In the currently used Genode toolchain the library supc++.o contains vterminate.o which is stripped, so the linker would not complain about the pointer. Is this by design because the process is about to die anyway when vterminate is called? To temporarily work around this problem I created a dummy void * _impure_ptr global in base/lib/cxx/misc.cc. The linker now continues and eventually completes. 2. The second problem is the size of the executable image files that the linker produces, several gigabytes! The actual memory image of the executable appears correct based on a dump of the section header but the header information shows that the File Offsets to the sections appears to be based off the link address. For example, in the creation of the boot image, build_core creates the binary log.bootstrap, the dump of which is: objdump -h ../build/dragonboard/var/run/log.bootstrap |more ../build/dragonboard/var/run/log.bootstrap: file format elf64-little Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 0000000000000000 0000000000000000 81042000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0003b840 0000000081000000 0000000081000000 81001000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .data 00000718 000000008103c000 000000008103c000 8103d000 2**3 CONTENTS, ALLOC, LOAD, DATA 3 .got 000000e0 000000008103c718 000000008103c718 8103d718 2**3 CONTENTS, ALLOC, LOAD, DATA 4 .got.plt 00000018 000000008103c7f8 000000008103c7f8 8103d7f8 2**3 CONTENTS, ALLOC, LOAD, DATA 5 .eh_frame 00003084 000000008103c810 000000008103c810 8103d810 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gcc_except_table 00000968 000000008103f894 000000008103f894 81040894 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .bss 00008f09 0000000081040200 0000000081040200 810411fc 2**3 ALLOC It would appear that all the "File off" values are the expected value plus the bootstrap_link_address which is 0x81000000. Additionally, there is no stack unwind sections present, that is .ARM.exid/extab. The linker script being used is base/src/ld/genode.ld, as it should be. I don't have sufficient knowledge about linker functioning to begin to understand how the File offset values are determined or how the c++ stack unwind section is added, or not. Any suggestions would be very helpful. Thanks, Bob Stewart

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users