l4-hackers July 2020

l4-hackers@os.inf.tu-dresden.de

7 participants
4 discussions

L4Re: Identifying the source location of a program exception
by Paul Boddie 01 Aug '20

01 Aug '20

Hello, Returning to L4Re investigations with newer hardware (hosting qemu on the amd64 architecture), I have been trying to debug some of my hastily written code that undoubtedly has a race condition lurking in it. Unfortunately, I cannot remember the way of discovering how to identify the source instruction responsible (if I ever really knew it to begin with). I get an error like this: L4Re[rm]: unhandled read page fault at 0x38 pc=0x3a8bd9 Previous experiences suggested that I might not get much sense out of the program counter value, and it was also suggested to me that I might try and use the kernel debugger to show the thread execution state. I dug up instructions to achieve this... 1. Modify pkg/l4re-core/l4re/util/include/region_mapping_svr_2 and pkg/l4re-core/l4re_kernel/server/src/region.cc to employ enter_kdebug invocations. 2. Add jdb = L4.Env.jdb in the capabilities section of the start or startv invocation that invokes the task in the appropriate .cfg file. 3. Run the system and wait for an exception to trigger the debugger. 4. Use the t<enter> command sequence to see the thread state. 5. Use <space> to enter the disassembly and see the supposedly problematic instruction. Unfortunately, this seems to add confusion. Firstly, I end up with a different location: ffffffff10455e98. Even if I assume that the actual location is 455e98, being somewhat near to the usual payload base address of 400000, it doesn't help me identify what the code is that resides there. Normally, I would attempt to use addr2line, nm or objdump to provide some kind of map, but I cannot see any correspondence between their output and these values. I also considered, since my code is dynamically linked, that I might need to get the linker to tell me a bit more about where it is positioning library code in memory. This was suggested in another context a couple of years ago: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2018/008274.html However, the only vaguely pertinent output I can find is this: _dl_protect_relro:124: RELRO protecting rom/libuc_c.so: start:0x3a6000, end:0x3a7000 _dl_protect_relro:124: RELRO protecting rom/libdl.so: start:0x3bf000, end:0x3c0000 If the 3a8bd9 value is meaningful, it evidently refers to something between these two regions, if these regions are valid. I thought that there was a more coherent summary of loaded objects, but I cannot find any details of that now. I imagine that there must be a simpler way of getting back to the source from exception addresses and would greatly appreciate being told (or reminded) what that is! Thanks in advance, Paul

3 4

uvmm support for AMD-V
by Andreas Steinmetzler 16 Jul '20

16 Jul '20

Hi, I followed the tutorials on github to get a basic L4re environment compiled and running (Hello World) on a embedded x86 board (more specifically APU2 https://www.pcengines.ch/apu2.htm). Everything worked fine - really nice tutorial. Next, I was using the single Linux VM guide to move on getting to more interesting stuff and uvmm stopped with the following error message "VMM: FATAL: Unsupported HW virtualization type.: Invalid request" While reading more of the documentation I looks to me that uvmm is not supporting AMD-V (last sentence in https://github.com/kernkonzept/uvmm/blob/master/doc/uvmm.dox). Wondering if there is a fundamental shortcoming of the AMD-V extensions or is it just missing because nobody worked on it? Thanks Andreas SeaBIOS (version rel-1.12.1.3-0-g300e8b7) Press F10 key now for boot menu Booting from Hard Disk... GRUB Loading /bootstrap /bootstrap -modaddr 0x01100000 Loading /fiasco fiasco -serial_esc Loading /sigma0 sigma0 Loading /moe moe rom/uvmm-basic.ned Loading /uvmm uvmm Loading /l4re l4re Loading /ned ned Loading /virt-pc.dtb virt-pc.dtb Loading /ramdisk-amd64.cpio.gz ramdisk-amd64.cpio.gz Loading /uvmm-basic.ned uvmm-basic.ned Loading /bzImage bzImage Done, booting... error: Can't get controller info. L4 Bootstrapper Build: #1 Tue Jul 14 23:45:16 CEST 2020, x86-64, 7.5.0 RAM: 0000000000000000 - 000000000009fbff: 639kB RAM: 0000000000100000 - 00000000dfe88fff: 3667492kB RAM: 0000000100000000 - 000000011effffff: 507904kB Total RAM: 4078MB Scanning fiasco -serial_esc Scanning sigma0 Scanning moe rom/uvmm-basic.ned need 424 bytes to copy MBI reserved 424 bytes at 0x2000 Moving up to 10 modules behind 1100000 moving module 09 { 1319000-1b4f02f } -> { 15c7000-1dfd02f } [8609840] moving module 07 { 109a000-13181ff } -> { 1348000-15c61ff } [2613760] moving module 05 { 1021000-10999ef } -> { 12cf000-13479ef } [494064] moving module 08 { 2cf000-2cf23a } -> { 12ce000-12ce23a } [571] moving module 06 { 2ce000-2ce732 } -> { 12cd000-12cd732 } [1843] moving module 04 { 2b0000-2cd72f } -> { 12af000-12cc72f } [120624] moving module 03 { 1d7000-2afb1f } -> { 11d6000-12aeb1f } [887584] moving module 02 { 194000-1d675f } -> { 1193000-11d575f } [272224] moving module 01 { 187000-19348f } -> { 1186000-119248f } [50320] moving module 00 { 101000-186b97 } -> { 1100000-1185b97 } [547736] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 400000 Regions of list 'regions' [ 0, fff] { 1000} Arch BIOS [ 1000, 1fff] { 1000} Kern fiasco [ 2000, 21a7] { 1a8} Root mbi_rt [ 9fc00, 9ffff] { 400} Arch BIOS [ f0000, fffff] { 10000} Arch BIOS [ 100000, 11247f] { 12480} Sigma0 sigma0 [ 140000, 17f9eb] { 3f9ec} Root moe [ 181030, 1930e7] { 120b8} Root moe [ 2d0400, 2e1257] { 10e58} Boot bootstrap [ 300000, 34afff] { 4b000} Kern fiasco [ 400000, 488fff] { 89000} Kern fiasco [ 1019000, 101efff] { 6000} Boot bootstrap-ptab64 [ 11d6000, 1dfd02f] { c27030} Root Module [ dfe89000, dfffffff] { 177000} Arch BIOS [ f8000000, fbffffff] { 4000000} Arch BIOS [ fed40000, fed44fff] { 5000} Arch BIOS found kernel options (via ELF) at 401000 Sigma0 config ip:00000000001004a0 sp:0000000000000000 Roottask config ip:00000000001418dd sp:0000000000000000 Starting kernel fiasco at 0000000000300910 Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on amd64 Rev: 69396db compiled with gcc 7.5.0 for x86-64 [] Build: #1 Wed Jul 15 00:09:32 CEST 2020 Performance-critical config option(s) detected: CONFIG_NDEBUG is off CONFIG_FINE_GRAINED_CPUTIME is on Superpages: yes Kmem:: TSS mem at 10fb5e000 (4096Bytes) ACPI: RSDP[0xf3af0] r02 OEM:COREv4 FPU0: SSE AVX ACPI: FACS phys=dfe9d240 virt=0x2009d240 ACPI: HW sig=0 Enable MSI support: chained IRQ mgr @ 0xffffffff10156d10 SERIAL ESC: allocated IRQ 4 for serial uart Not using serial hack in slow timer handler. CPU[0]: AuthenticAMD (16:30:1:0)[00730f01] Model: AMD GX-412TC SOC at 998MHz 32/512 Entry I TLB (4K pages) 8 Entry I TLB (4M pages) 40/512 Entry D TLB (4K pages) 8/256 Entry D TLB (4M pages) 32 KB L1 I Cache (2-way associative, 64 bytes per line) 32 KB L1 D Cache (8-way associative, 64 bytes per line) 2048 KB L2 U Cache (8-way associative, 64 bytes per line) Freeing init code/data: 16384 bytes (4 pages) SVM: enabled SVM: nested paging supported SVM: NASID: 8. MP: detecting APs... Calibrating timer loop... SVM: enabled SVM: enabled SVM: nested paging supported done. SVM: NASID: 8. SVM: enabled SVM: nested paging supported SVM: nested paging supported SVM: NASID: 8. SVM: NASID: 8. MDB: use page size: 30 MDB: use page size: 21 MDB: use page size: 12 SIGMA0: Hello! KIP @ 400000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:RWX:2000;2fff] [0:RWX:3000;9efff] [0:RWX:113000;13ffff] [4:R-X:140000;17ffff] [0:RWX:180000;180fff] [4:RW-:181000;193fff] [0:RWX:194000;3fffff] [0:RWX:485000;11d5fff] [4:RWX:11d6000;1dfdfff] [0:RWX:1dfe000;dfe88fff] [0:RWX:100000000;10fb4efff] IOMEM:---------------------- [0:RW-:0;fff] [0:RW-:9f000;fffff] [0:RW-:dfe89000;febfffff] [0:RW-:fec01000;fec1ffff] [0:RWX:fec21000;fedfffff] [0:RWX:fee01000;ffffffff] [0:RWX:11f000000;ffffffffffffffff] IO PORTS-------------------------- [0:RW-:0;fffffff] MOE: Hello world MOE: found 3912072 KByte free memory MOE: found RAM from 2000 to 10fb4f000 MOE: allocated 4347 KByte for the page array @0x485000 MOE: virtual user address space [0-7fffffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [11d6000-12aeb20] [C:107000] uvmm BOOTFS: [12af000-12cc730] [C:109000] l4re BOOTFS: [12cf000-13479f0] [C:10b000] ned BOOTFS: [12cd000-12cd733] [C:10d000] virt-pc.dtb BOOTFS: [1348000-15c6200] [C:10f000] ramdisk-amd64.cpio.gz BOOTFS: [12ce000-12ce23b] [C:111000] uvmm-basic.ned BOOTFS: [15c7000-1dfd030] [C:113000] bzImage MOE: cmdline: moe rom/uvmm-basic.ned MOE: Starting: rom/ned rom/uvmm-basic.ned MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/uvmm-basic.ned' VMM: FATAL: Unsupported HW virtualization type.: Invalid request

2 1

Access to Arm Trusted Firmware
by Stefan Kalkowski 14 Jul '20

14 Jul '20

Dear l4-hackers, I've seen that Fiasco.OC provides support for the i.MX8 SoC universe. I'm curious about whether the kernel provides any means to access the ARM Trusted Firmware (ATF) in general? (especially regarding the vendor-specific calls for powering different peripheral domains). I've seen some kind of platform control privilege for cpu powering if I understood it correctly. Is there something more generic available? I'm asking, because right now I write a platform driver for Genode running on the i.MX 8M with focus on the base-hw kernel. But if there is a way I would like to support Fiasco.OC as well. Thank you in advance for any clearing up & best regards Stefan -- Stefan Kalkowski Genode labs https://github.com/skalk | https://genode.org

2 3

Question on availability of 'Live Hacking - HW Enforced Virtualization Of Linux Home Gateway'
by Andreas Steinmetzler 14 Jul '20

14 Jul '20

Hi, not sure if this is the right forum to ask, but I came across the following presentation given @embedded World 2018 https://bringyourownit.com/2018/03/20/hardware-enforced-virtualization-of-l… and was wondering if the full presentation and the "live hacking" steps are available somewhere as I'm interested in doing more experiments in this direction? Or maybe there is some other similar write-up available which is describing something similar? Any pointers are highly appreciated. Thanks Andreas BTW: I tried to search the mailing list archive, but unfortunately I'm getting a 403 permission error :(.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers July 2020