users

users@lists.genode.org

1 participants
2310 discussions

Enabling secure boot on the USB armory
by 오지수 05 Oct '16

05 Oct '16

Hello I'm currently trying to boot Genode 15.02 on the USB Armory. [1] provides tutorial of secure boot on USB Armory. But, [1] only handle linux zImage. Is this possible to generate signed U-boot for Genode image? [1] https://github.com/inversepath/usbarmory/wiki/Secure-boot

3 3

Intel wifi driver
by Martijn Verschoor 03 Oct '16

03 Oct '16

Hi everyone, I’m trying to setup the wifi driver in Turmvilla like scenario’s but with little success. The driver spits out a fair amount of warnings and errors which obfuscates my view of what could be the main issue; thus I would like to reach out for help. A log of the turmvilla scenario (https://github.com/nfeske/genode/tree/turmvilla-16.05) running on a Lenovo x201 is attached. I get very similar results on x250’s. Can anyone point out to me what might be the problem? 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)

3 4

Netaidkit as an alternative wifi client
by Emery Hemingway 28 Sep '16

28 Sep '16

Hello list, I come not with a problem but a solution, My laptop shipped with a wireless card not supported by the Genode wifi driver, and replacing the card model raises an error from the BIOS (which raises some suspicions of firmware interaction). This is usually not a problem as I have plenty of ethernet endpoints in my house, but it is inconvenient when I want to move around. I discovered a few of the people I know in town have actually removed the wireless cards from their Linux laptops and instead use USB powered routers to connect to wifi. They recommended the NetAidKit to me, which I have been using without any problems. I connect to this small router through ethernet and the router acts as a wireless client. It is a solution with some physical bulk, but it pushes the complexity of wifi to the other side of my ethernet hardware. It costs 50 euro, a lot compared to simple client hardware, but it is a project I don't mind supporting. https://netaidkit.net/ Cheers, Emery

1 0

Page faults in managed dataspaces
by Denis Huber 27 Sep '16

27 Sep '16

Dear Genode Community, I want to implement a mechanism to monitor the access of a component to its address space. My idea is to implement a monitoring component which provides managed dataspaces to a target component. Each managed dataspace has several designated dataspaces (allocated, but not attached, and with a fixed location in the managed dataspace). I want to use several dataspaces to control the access range of the target component. Whenever the target component accesses an address in the managed dataspace, a page fault is triggered, because the managed dataspace has no dataspaces attached to it. The page fault is caught by a custom page fault handler. The page fault handler attaches the designated dataspace into the faulting managed dataspace and resolves the page fault. To test my concept I implemented a prototypical system with a monitoring component (called "ckpt") [1] and a target component [2]. [1] https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/b502… [2] https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/b502… The monitoring component provides a service [3] to receive a Thread capability to pause the target component before detaching the dataspace and resume after detaching and to provide a managed dataspace to the client. [3] https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/tree/b502… The monitoring component runs a main loop which pauses the client's main thread and detaches all attached dataspaces from the managed dataspace. The target component also runs a main loop which prints (reads) a number from the managed dataspace to the console and increments (writes) it in the managed dataspaces. The run script is found here [4]. [4] https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/b502… The scenario works for the first 3 iterations of the monitoring component: Every 4 seconds it detaches the dataspaces from the managed dataspace and afterwards resolves the page faults by attaching the dataspaces back. After the 3. iteration, the target component accesses the theoretically empty managed dataspaces, but does not trigger a page fault. In fact, it reads and writes to the designated dataspaces as if it was attached. By running the run script I get the following output: [init -> target] Initialization started [init -> target] Requesting session to Resource service [init -> ckpt] Initialization started [init -> ckpt] Creating page fault handler thread [init -> ckpt] Announcing Resource service [init -> target] Sending main thread cap [init -> target] Requesting dataspace cap [init -> target] Attaching dataspace cap [init -> target] Initialization ended [init -> target] Starting main loop Genode::Pager_entrypoint::entry()::<lambda(Genode::Pager_object*)>:Could not resolve pf=6000 ip=10034bc [init -> ckpt] Initialization ended [init -> ckpt] Starting main loop [init -> ckpt] Waiting for page faults [init -> ckpt] Handling page fault: READ_FAULT pf_addr=0x00000000 [init -> ckpt] attached sub_ds0 at address 0x00000000 [init -> ckpt] Waiting for page faults [init -> target] 0 [init -> target] 1 [init -> target] 2 [init -> target] 3 [init -> ckpt] Iteration #0 [init -> ckpt] valid thread [init -> ckpt] detaching sub_ds_cap0 [init -> ckpt] sub_ds_cap1 already detached Genode::Pager_entrypoint::entry()::<lambda(Genode::Pager_object*)>:Could not resolve pf=6000 ip=10034bc [init -> ckpt] Handling page fault: READ_FAULT pf_addr=0x00000000 [init -> ckpt] attached sub_ds0 at address 0x00000000 [init -> ckpt] Waiting for page faults [init -> target] 4 [init -> target] 5 [init -> target] 6 [init -> target] 7 [init -> ckpt] Iteration #1 [init -> ckpt] valid thread [init -> ckpt] detaching sub_ds_cap0 [init -> ckpt] sub_ds_cap1 already detached [init -> target] 8 [init -> target] 9 [init -> target] 10 [init -> target] 11 [init -> ckpt] Iteration #2 [init -> ckpt] valid thread [init -> ckpt] sub_ds_cap0 already detached [init -> ckpt] sub_ds_cap1 already detached [init -> target] 12 [init -> target] 13 As you can see: After "iteration #1" ended, no page fault was caused, although the target component printed and incremented the integer stored in the managed dataspace. Could it be, that the detach method was not executed correctly? Kind regards Denis

3 8

tar archive and sd_card partition
by John David 27 Sep '16

27 Sep '16

Hello, I have a libc program called my_test, and I want this program to access files from both an archive (myarchive.tar) and an sd_card partition. For this, I have tried to write a run script and run it, but no luck so far. Part of the configuration is below. I would greatly appreciate if you could help me on the configuration. <start name="sd_card_drv"> <resource name="RAM" quantum="20M"/> <provides><service name="Block"/></provides> </start> <start name="part_blk"> <resource name="RAM" quantum="10M" /> <provides><service name="Block" /></provides> <route> <service name="Block"><child name="sd_card_drv" /></service> <any-service><parent/><any-child/></any-service> </route> <config> <policy label="my_test" partition="2"/> </config> </start> <start name="my_test"> <resource name="RAM" quantum="10M"/> <route> <any-service> <child name="part_blk" /> <parent/> <any-child/> </any-service> </route> <config> <libc stdout="/dev/log" stderr="/dev/log" > <vfs> <dir name="dev"> <log/></dir> <tar name="myarchive.tar"/> </vfs> </libc> </config> </start> Thanks and best regards, John

2 1

Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules
by Paul Dufresne 24 Sep '16

24 Sep '16

I thought rebooting computer as soon has coming to boot line was for old low memories computer only, but I get it with nova.iso burnt on a CD on my Core 2 Duo, 2 GB (well 3 GB, but 2 Gb memory stick recognized as only 1 Gb + one other 1 Gb). Capture log with null-modem RS232: Bender: Hello World. Need 05df2000 bytes to relocate modules. Relocating to 7980d000: Copying 483168 bytes... Copying 460412 bytes... Copying 19947520 bytes... Copying 256000 bytes... Copying 552960 bytes... Copying 9390080 bytes... Copying 3553280 bytes... Copying 293864 bytes... Copying 93356 bytes... Copying 404216 bytes... Copying 435168 bytes... Copying 513708 bytes... Copying 422696 bytes... Copying 501760 bytes... Copying 876148 bytes... Copying 93612 bytes... Copying 303800 bytes... Copying 7323460 bytes... Copying 5039116 bytes... Copying 4994372 bytes... Copying 34148 bytes... Copying 229812 bytes... Copying 176200 bytes... Copying 157940 bytes... Copying 23572 bytes... Copying 1078412 bytes... Copying 616068 bytes... Copying 26033700 bytes... Copying 3222864 bytes... Copying 558540 bytes... Copying 434872 bytes... Copying 51200 bytes... Copying 879773 bytes... Copying 582 bytes... Copying 19768 bytes... Copying 94460 bytes... Copying 418916 bytes... Copying 478944 bytes... Copying 164608 bytes... Copying 457964 bytes... Copying 412840 bytes... Copying 544356 bytes... Copying 1253468 bytes... Copying 407104 bytes... Copying 453048 bytes... Copying 607380 bytes... Copying 419008 bytes... Copying 448912 bytes... Copying 381588 bytes... Copying 412840 bytes... Copying 411736 bytes... Copying 534440 bytes... Copying 9589 bytes... Copying 909276 bytes... Copying 114820 bytes... computer reboots here paul@...445...:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 microcode : 0x44 cpu MHz : 1860.497 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow dtherm bugs : bogomips : 3720.99 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 microcode : 0x44 cpu MHz : 1860.497 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow dtherm bugs : bogomips : 3721.29 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: paul@...445...:~$ cat /proc/meminfo MemTotal: 2041768 kB

3 20

Secure Image Processing using Genode
by Tiago Brito 23 Sep '16

23 Sep '16

Hi Genode enthusiasts, I'm a portuguese researcher finishing my Computer Science master degree. I developed a TrustZone-based project using Genode and the i.MX53 QSB. I have been accepted to the Workshop on Mobile and Cloud Security and Privacy (WMCSP) 2016 which is hosted in collaboration with the Symposium on Reliable Distributed Systems (SRDS). I'll leave the title and abstract of my work here. -------------------- Title: ARM TrustZone for Secure Image Processing on the Cloud Abstract: Nowadays, offloading storage and processing capacity to cloud servers is a growing trend. This happens because high storage capacity and powerful processors are expensive, whilst cloud services provide a cheaper, ongoing, and reliable solution. The problem with cloud-based solutions is that servers are highly accessible through the Internet and therefore considerably exposed to hackers and malware. In this paper, we design and implement Darkroom, a secure image processing service for the cloud leveraging ARM TrustZone technology. Our system enables users to securely process image data in a secure environment that prevents exposure of sensitive data to the operating system. We evaluate our system and observe that our solution adds a small overhead to image processing when compared to computer platforms that require the entire operating system to be trusted. -------------------- I'm going to present this project in Budapest at the Symposium 25th of September 2016 and I though you might be interested in knowing more about the project. Best regards, Tiago Brito

1 0

Nova multiboot v.1 flags == 0 ???
by Paul Dufresne 22 Sep '16

22 Sep '16

I think I have a problem with Nova multiboot specification. In https://github.com/udosteinberg/NOVA/blob/master/src/start.S : /* * Multiboot Header */ __boot_header: .long 0x1badb002 .long 0x0 .long -0x1badb002 This is multiboot v.1 (current version is 2). 3.1.1 The layout of Multiboot header ------------------------------------ The layout of the Multiboot header must be as follows: Offset Type Field Name Note 0 u32 magic required 4 u32 flags required 8 u32 checksum required 12 u32 header_addr if flags[16] is set 16 u32 load_addr if flags[16] is set 20 u32 load_end_addr if flags[16] is set 24 u32 bss_end_addr if flags[16] is set 28 u32 entry_addr if flags[16] is set 32 u32 mode_type if flags[2] is set 36 u32 width if flags[2] is set 40 u32 height if flags[2] is set 44 u32 depth if flags[2] is set ... 'magic' The field 'magic' is the magic number identifying the header, which must be the hexadecimal value '0x1BADB002'. 'flags' The field 'flags' specifies features that the OS image requests or requires of an boot loader. The problem is here, flags is 0 so it request nothing from the Boot Loader! 'checksum' The field 'checksum' is a 32-bit unsigned value which, when added to the other magic fields (i.e. 'magic' and 'flags'), must have a 32-bit unsigned sum of zero. So the result table returns have not much information you can trust to be there: The format of the Multiboot information structure (as defined so far) follows: +-------------------+ 0 | flags | (required) +-------------------+ 4 | mem_lower | (present if flags[0] is set) 8 | mem_upper | (present if flags[0] is set) +-------------------+ 12 | boot_device | (present if flags[1] is set) +-------------------+ 16 | cmdline | (present if flags[2] is set) +-------------------+ 20 | mods_count | (present if flags[3] is set) 24 | mods_addr | (present if flags[3] is set) +-------------------+ 28 - 40 | syms | (present if flags[4] or | | flags[5] is set) +-------------------+ 44 | mmap_length | (present if flags[6] is set) 48 | mmap_addr | (present if flags[6] is set) +-------------------+ 52 | drives_length | (present if flags[7] is set) 56 | drives_addr | (present if flags[7] is set) +-------------------+ 60 | config_table | (present if flags[8] is set) +-------------------+ 64 | boot_loader_name | (present if flags[9] is set) +-------------------+ 68 | apm_table | (present if flags[10] is set) +-------------------+ 72 | vbe_control_info | (present if flags[11] is set) 76 | vbe_mode_info | 80 | vbe_mode | 82 | vbe_interface_seg | 84 | vbe_interface_off | 86 | vbe_interface_len | +-------------------+ 88 | framebuffer_addr | (present if flags[12] is set) 96 | framebuffer_pitch | 100 | framebuffer_width | 104 | framebuffer_height| 108 | framebuffer_bpp | 109 | framebuffer_type | 110-115 | color_info | Or is it some code that change the flags and checksum somewhere? I guess flags[6] would be usefull to get memory map: If bit 6 in the 'flags' word is set, then the 'mmap_*' fields are valid, and indicate the address and length of a buffer containing a memory map of the machine provided by the BIOS. 'mmap_addr' is the address, and 'mmap_length' is the total size of the buffer. The buffer consists of one or more of the following size/structure pairs ('size' is really used for skipping to the next pair): +-------------------+ -4 | size | +-------------------+ 0 | base_addr | 8 | length | 16 | type | +-------------------+ where 'size' is the size of the associated structure in bytes, which can be greater than the minimum of 20 bytes. 'base_addr' is the starting address. 'length' is the size of the memory region in bytes. 'type' is the variety of address range represented, where a value of 1 indicates available RAM, value of 3 indicates usable memory holding ACPI information, value of 4 indicates reserved memory which needs to be preserved on hibernation, value of 5 indicates a memory which is occupied by defective RAM modules and all other values currently indicated a reserved area. Info is from: http://wiki.osdev.org/Multiboot More prrecisely External link near the end for: http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multibo… which give a texi file that I changed to txt with: $ makeinfo --plaintext --force multiboot.texi > multiboot.txt

2 1

My P4 Netvista works fine on real hardware with both nova and sel4 CD
by Paul Dufresne 21 Sep '16

21 Sep '16

I decided to test my computers in reverse side: P4 would test the CD Core 2 Duo would run minicom to capture log files. I was not expecting it to work, although I had some doubt because a quite older version was running on that P4. It appears both my CDs of Genode 16.08 (sel4.iso and nova.iso) have worked fine. I think that's the first time I was seeing running fine on real hardware. Well, I did saw the screen on one laptop I tried, but it was not accepting any input. Now, the monitor I use (well a relatively old Daenyx tv), was not working with my other Celeron D computer... and I was thinking it was EDID that was not use correctly, but now I begin to suspect ATI video card was not happy with Genode. I believe the P4 react better because of Intel 845 chipset it use. The biggest surprise is the P4 have only 512 Mb: MemTotal: 497928 kB cat /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.26GHz stepping : 4 microcode : 0xf cpu MHz : 2259.011 cache size : 512 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pebs bts bugs : bogomips : 4518.02 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 32 bits virtual power management: Well, I guess there is no need to include capture files.

1 0

boot loader did not provide information about modules
by Paul Dufresne 20 Sep '16

20 Sep '16

boot loader did not provide information about modules This is from my 'new' Core 2 Duo, booting Genode 16.08 sel4.iso on an usb key. I got it with a null-modem. I am attaching the full capture log file. I had the same symptoms on most computers I have tried... hanging on boot line doing nothing. might explains it a bit... but frankly I don't understand why (it works in VirtualBox).

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users