l4-hackers

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

2 participants
2880 discussions

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

Problems Compiling L4RE with L4Linux
by Or Becker 29 Mar '20

29 Mar '20

Hi, I'm trying to compile L4RE with L4Linux and execute it with qemu. I followed the Github tutorial but the default Ned script didn't work (since I'm using the L4Linux I guess), so I used a different Ned script I found online (In the future I will have multiple VMs so I thought to do it in advanced). My Ned script is simple: package.path = "rom/?.lua"; local L4 = require "L4"; local vmm = require "vmm"; vmm.start_vm({ id = 1, mem = 128, mon = false, rd = "rom/ramdisk-armv8.cpio.gz", fdt = "rom/virt-arm_virt.dtb", bootargs = "console=hvc0 earlyprintk=1 rdinit=/bin/sh", kernel = "rom/Image.gz", log = L4.Env.log }); But when I try to execute "make E=uvmm1 qemu", an error occurred: Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Calibrating timer loop... done. MDB: use page size: 30 MDB: use page size: 21 MDB: use page size: 12 SIGMA0: Hello! KIP @ 40003000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:40000000;40000fff] [0:40054000;400effff] [0:40109000;40117fff] [0:4011d000;4012ffff] [4:40130000;4017afff] [0:4017b000;40189fff] [4:4018a000;40197fff] [0:40198000;410fffff] [4:41100000;4264bfff] [0:4264c000;7effffff] IOMEM:---------------------- [0:0;3fffffff] [0:80000000;ffffffffffffffff] MOE: Hello world MOE: found 1009576 KByte free memory MOE: found RAM from 40000000 to 7f000000 MOE: allocated 1008 KByte for the page array @0x40198000 MOE: virtual user address space [0-7fffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [41100000-41197700] [C:107000] uvmm BOOTFS: [41198000-411c4e70] [C:109000] l4re BOOTFS: [411c5000-41246690] [C:10b000] ned BOOTFS: [41247000-412475ae] [C:10d000] virt-arm_virt.dtb BOOTFS: [41248000-41453600] [C:10f000] ramdisk-armv8.cpio.gz BOOTFS: [41454000-41454138] [C:111000] uvmm1.ned BOOTFS: [41455000-4264ba00] [C:113000] Image.gz MOE: cmdline: moe rom/uvmm1.ned MOE: Starting: rom/ned rom/uvmm1.ned MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/uvmm1.ned' lua error: rom/uvmm1.ned:4: module 'vmm' not found: no field package.preload['vmm'] no file 'rom/vmm.lua' no file '/usr/local/lib/lua/5.3/vmm.so' no file '/usr/local/lib/lua/5.3/loadall.so' no file './vmm.so'. qemu-system-aarch64: terminating on signal 2 Makefile:6: recipe for target 'do-all-make-goals' failed make: *** [do-all-make-goals] Interrupt I tried to add more paths to the package.path but the error stays the same (even if uvmm.lua exists in the path) Can you please help me? Thank you, Or

3 3

L4Re with GCC 9; Repositories and Roadmaps
by Paul Boddie 06 Feb '20

06 Feb '20

Hello and Happy New Year! Having been otherwise occupied so far this year, I decided to take the opportunity to revisit my L4 development environment that happens to use Debian unstable. It turns out that GCC 9 is now the supported toolchain version, and unfortunately, L4Re doesn't yet understand this new version. So, first of all, I wondered whether support for that is imminent. I did take a look at persuading the build system to work, but this seems to involve hunting down version-specific resources and defining new ones for the new version. I stopped when encountering some libstdc++ headers and wondering whether this isn't documented somewhere. = Repositories = It did occur to me that I might also be expecting updates for such things from the wrong channel. Since I have been using L4Re for a while, I still use the Subversion repositories made available from svn.l4re.org, referenced by the documentation on l4re.org. It seems that these repositories are not updated as frequently as the GitHub repositories, but maybe they serve as a kind of staging area for more stable releases. After giving up on using GCC 9, I decided to re-clone repositories in a Debian stable environment. This didn't go very well with the Subversion repositories: after a while of saturating my aging machine's I/O bandwidth, cloning (or checking out) tended to fail. The repomgr script, if re-run, seems to just delete everything and start again, so after a few tries I gave up. Meanwhile, using the GitHub repositories failed for different reasons. Previously, I have tended to get "index pack" and "missing object" errors with Git when cloning. There don't seem to be any decent remedies for this, with people suggesting tweaking compression, network, memory and other settings, manually fiddling with the "object database" and other such nonsense. The consensus might be that I do not have a powerful enough machine (only 1GB RAM) to clone even modestly-sized Git repositories. Nevertheless, it would be nice to be able to download some kind of release distribution. I somehow doubt that the world really needs to accommodate all the multi-gigabyte Linux kernel clones out there that differ by a few files, either. If I really want to version my modifications against the released code, I can always version control them myself (even using a more coherent version control system if I want). = Roadmaps = Such considerations led me to also consider what I have been wanting to use L4Re for and the notion of a roadmap, both my own and that of L4Re itself. It seems to me that L4Re, or parts of it, can form the basis of a usable system in its own right (as opposed to just hosting L4Linux). However, I don't see much development directed towards such a goal. (Actually, I don't really see much L4Re development at all.) It seems to me, as I may have mentioned before, that one crucial area of development that would be needed for my purposes is that of providing general- purpose filesystem support. To do that, it seems that a few separate issues need attention, amongst them the component architecture required to export file entries and contents to programs, and support in the C library so that programs can access files transparently. Since L4Re's filesystem support seems to require linking filesystem-specific libraries against programs and having those programs access filesystem data directly, as far as I can tell, a new component architecture is required. Meanwhile, it seems to me that uClibc, at least in the version offered by L4Re, does not offer a particularly coherent or convenient basis for integrating with such a component architecture. Consequently, I spent a fair amount of time last year investigating filesystem component architectures and alternative C library implementations. But I wouldn't mind knowing whether there are plans to remedy these deficiencies in L4Re or whether I should just plug away at such things by myself. (I can live with people saying that they don't care about the things that I happen to care about. No-one needs to make excuses here: even the Hurd people seem pretty unmotivated about getting people on board, although it can be said that within certain parameters, they at least have a system that meets their objectives to some degree.) = Some Thoughts = It rather looks like the amount of time I have to spend on L4Re-related development will be significantly reduced for the foreseeable future. In some respects, I feel that I have learned quite a bit, but in other respects, I feel that it has been a frustrating exercise to try and get up to speed with L4Re development. (And I hardly want to get started on my Fiasco development experience.) Although literature obviously exists about various L4 implementations, I don't feel that the documentation experience is coherent at all. Many of the pertinent details are also obscured by the focus on code-originating reference documentation. And where microkernel-based systems should be emphasising the nature of the interfaces between components, there instead seems to be a policy of hiding such details in the implementation details of various abstractions (implemented multiple times in an almost archaelogical fashion). Indeed, this latter policy is quite infuriating because it binds the developer to existing functionality and frameworks unnecessarily. So, when developing my components for low-end devices, I went along with L4Re framework classes due to an incomplete understanding of the IPC mechanisms (which also brought other irritations because those classes assume a more complete understanding), but also because interfacing with other components is not obvious when the protocols are squirreled away across multiple header and implementation files. I have even gone as far as to write my own interface description language tool to permit the generation of IPC code and to help emphasise component interfaces and protocols. It seems to me that a lot of the point in having systems that facilitate component-oriented architectures is to make such details explicit, as was indeed emphasised by projects like Spring. Otherwise, everyone might as well be writing stuff for frameworks in the Linux kernel. Anyway, I am sure that there are plenty of people developing for and enhancing L4Re who are content with their situation and what they are able to achieve. But I personally feel that opportunities are being missed to apply these technologies to areas where they would make a real (and, crucially, positive) difference. If anyone else (still reading by this point) is even vaguely interested in general-purpose operating system development on L4Re, it would be nice to hear from you. Paul

4 11

Compatibility of microkernel systems with legacy OSes; was L4Re with GCC 9; Repositories and Roadmaps
by Andrew Warkentin 30 Jan '20

30 Jan '20

On 1/28/20, Martin Decky <martin.decky(a)huawei.com> wrote: > > FYI: The microkernel-based OS Huawei is working on internally has Linux > compatibility (both from the syscall API and from the drivers point of view) > as one of its goals. > Is it natively Unix-like, or is the Linux compatibility layer some kind of containerized "penalty box" that doesn't really integrate into the system? Also, since you're not developing it publicly , that may limit its ability to compete with Linux, which of course has a completely open development model without copyright assignment. In addition, from one article I read, it sounded like even though it is going to be open source eventually, it was designed with the assumption that it would be running on tivoized devices with locked bootloaders, with no way for the user to get full control. > > GNU Hurd obviously also tries to be GNU/Linux compatible (not on the syscall > level, but on the glibc level). Many other microkernel-based systems (e.g. > Genode, just to name one) maintain their own adaptation layers for hosting > Linux device drivers. > >From what I understand, Hurd doesn't implement a lot of Linux-kernel-specific APIs. On 1/28/20, Paul Boddie <paul(a)boddie.org.uk> wrote: > > I actually think that most people agree with you on this, at least when > confronted with the notion for the first time. But I don't think such > considerations should overrule every other consideration: it reminds me of > people in the English-speaking world (particularly in my country of origin) > > who say that if they could be bothered to learn a foreign language, it would > > be "something like Spanish that a lot of people speak", justifying the > choice > in terms of all the millions of individual speakers with whom they could be > > having hypothetical conversations that, naturally, they wouldn't end up > having > anyway. > For my purposes, I would much rather have an OS that runs Linux programs natively rather than having to port every single application I want to run. > > Your project being this one: > > https://gitlab.com/uxrt > > Is there a summary of it anywhere? > This is the closest thing to a summary that I have at the moment: https://gitlab.com/uxrt/uxrt-toplevel/blob/master/architecture_notes > > I wonder whether people don't already rely on things like L4Linux for such > functionality. However, I don't personally think that having boxed-up driver > > frameworks is particularly elegant or plays to the strengths of > microkernel- > based paradigms. In L4Re, I found myself staring down bits of imported Linux > > kernel code and wondering whether things might not have been easier - and > most > certainly clearer - had something been developed independently. > Yes, it's true that it's maybe not the most elegant way to run drivers, but I think it's a worthwhile trade-off for broad hardware support. As far as UX/RT is concerned it's not really that big a sacrifice because it will have relatively little vertical modularization anyway (e.g. instead of separate disk filesystem, partition driver, and disk device driver processes, all three will be incorporated into a single "disk server" process, much as on QNX; this should improve performance over most other microkernel OSes while not really sacrificing much as far as security or error recovery). > > Of course, the real solution is to have a library of functionality that a > variety of systems could use. Then, we wouldn't need to pick over the > remains > of some other project. Being familiar with this industry over a couple of > decades, however, I am fully aware that people exhibit rather strong > tendencies to insist that such cooperation is not possible, usually because > of > something super-special that they insist that only they are doing. > I'd be willing to cooperate on such libraries as long as they don't place unnecessary burdens on client code.

3 9

Hardware-aided Trusted Computing devroom at FOSDEM
by Vasily A. Sartakov 12 Dec '19

12 Dec '19

Hello I would like to invite your to participate in a new devroom: Hardware-aided Trusted Computing. The devroom is devoted to open source projects on top of modern TEEs like Intel SGX, AMD SEV/SVE, Arm TrustZone. You can find the schedule here: https://fosdem.org/2020/schedule/track/hardware_aided_trusted_computing/ I hope this will be interesting for the community. See you at FOSDEM. -- Dr.-Eng. V. A. Sartakov

1 0

Filesystem Architectures with L4Re and L4-Based Systems
by Paul Boddie 02 Dec '19

02 Dec '19

Hello, As this list can attest, I previously spent a bit of time diving into the way dynamic linking is supported by L4Re to get shared mode programs working. This turned out to have a relatively simple fix related to symbols employed by GCC- generated code. But during this exercise, I gained some familiarity with the way libraries are loaded, and this appears to involve the virtual filesystem support, with the loader perusing the filesystem to access libraries, and with these being provided as modules by the "rom" filesystem. Since then, I've spent some time looking at how files are provided by filesystems and accessed by code that uses the conventional C or POSIX library interfaces. It raises a few questions about why things are done in a particular way in L4Re, and which approaches are in use for other L4-based systems, especially those that seek to provide general-purpose, multi-user solutions. What I think I now understand about the virtual filesystem support in L4Re is as follows. The virtual filesystem itself is a "client-side" construct, meaning that it resides within any given program. That programs have their own view of a filesystem is not too different from what the documentation about systems like the Hurd describes and advocates, and I suppose it is a tempting approach because it gives each program the flexibility to be customised in this regard. However, it seems that beyond the internal "mount tree" representation, configuration of the namespace hierarchy is largely done using the L4Re namespace concept, with namespaces acting as directories, and non-namespace objects within the hierarchy interpreted as particular file types. Apart from the interpretation of namespaces as directories, it seems that for the most part, dataspaces are employed to be interpreted as file objects. I will admit that I didn't really look very hard at how different systems provide file access before now, but what surprised me slightly was the apparent lack of delegation in L4Re. As far as I can tell, on systems based on kernels like Linux, the open library function will employ a system call to delegate the matter of finding the file and obtaining a way of accessing it to the familiar monolithic-kernel-plus-filesystems arrangement. On more "exotic" systems (than Linux) like Minix 3 or the Hurd, it appears that delegation to a virtual filesystem server [1] or servers [2] occurs to mediate access to specific files. Some systems like Inferno and Plan 9 employ protocols [3] to formalise the client-server relationship. I had almost expected to find similar things in L4Re, but I could only confirm their absence after reviewing the various VFS abstractions. One thing I wonder about is whether the current L4Re approach is able to satisfactorily deal with filesystem content that needs to serve different user entities, with content having different permission and ownership rights. It seems that the filesystem logic has to be available as a library within a program, which is not necessarily a problem. But to avoid filesystem content being completely exposed to the discretion of user programs (reminiscent of the problems with early Network File System implementations), the library would need to call out to other entities, which doesn't appear to be done with the current L4Re abstractions. One could implement support for, say, the ext3 filesystem in a library, operating on a dataspace provided at some kind of mountpoint in a directory (with the directory being provided by a namespace, of course) but it would be like giving a user program access to a block device in a traditional Unix-like system. Are there any articles about the design of L4Re that might explain the motivations here? And are there any accessible-but-detailed articles about other microkernel-based systems and the way in which they structure their filesystem architectures? I looked around on the TU-Dresden site for materials, but I didn't immediately find anything obviously relevant. Paul [1] https://wiki.minix3.org/doku.php?id=developersguide:vfsinternals [2] https://www.gnu.org/software/hurd/hurd-talk.html#pat [3] http://doc.cat-v.org/inferno/4th_edition/styx

1 1

Alignment checking on ARM
by Al Grant 26 Nov '19

26 Nov '19

I'm building L4 on ARM using GCC 7.4.0 on Cortex-A15. ARCH-arm/head.cc enables alignment checking (sets SCTLR.A=1), but we then see an alignment check fault in init_kip_f.cc. With the default compiler options, the GCC cross tools will assume alignment checking is _not_ enabled and will generate code that may use unaligned access. We can override this by compiling with -mno-unaligned-access. But it would be good to know what is intended. If the intention is to be able to run "mainstream" open-source code in userspace, i.e. build code using the standard Linux ABI, we ought to allow that, and not enable alignment checks in SCTLR. Some code will not be fixed by compiling -mno-unaligned-access (because it casts arbitrary unaligned pointers to word-sized types etc.) So my question is, what is the intention? (1) fault unaligned access in kernel and userspace (2) fault unaligned access in kernel but allow in userspace (3) allow unaligned access in kernel and userspace I'm assuming it can't be (3) as the bootstrap code explicitly enables alignment checking. (2) would be a good compromise, it would enable alignment checks which would pick up some possible faults in the kernel, but it would improve portability of ordinary open-source packages in userspace. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

2 1

Kernel Helpers segmentation fault
by Sateesh K 14 Nov '19

14 Nov '19

Hi, My setup is as follows: l4linux 4.19.0-l4 Fiasco.OC Raspberry Pi 3 Model B I am running a helloworld.go program which is causing the following stack trace. (gdb) bt full #0 0xffff0f60 in ?? () No symbol table info available. #1 0x0001143c in kernelCAS64 () at /usr/local/go/src/sync/atomic/asm_linux_arm.s:112 No locals. #2 0x0001103c in sync/atomic.loadUint64 (addr=0x10442080, val=48) at /usr/local/go/src/sync/atomic/64bit_arm.go:10 No locals. #3 0x00071f44 in internal/poll.(*fdMutex).rwlock (mu=0x10442080, read=false, ~r1=160) at /usr/local/go/src/internal/poll/fd_mutex.go:130 mutexBit.lo = 4 mutexMask.hi = 2147481600 mutexMask.lo = 0 mutexSema = 0x1044208c mutexWait.hi = 2048 mutexWait.lo = 0 #4 0x00072314 in internal/poll.(*FD).writeLock (fd=0x10442080, ~r0=...) at /usr/local/go/src/internal/poll/fd_mutex.go:237 No locals. #5 0x00072a94 in internal/poll.(*FD).Write (fd=0x10442080, p=..., ~r1=0, ~r2=...) at /usr/local/go/src/internal/poll/fd_unix.go:243 n = -1212420096 nn = 118 --Type <RET> for more, q to quit, c to continue without paging--c #6 0x00073958 in os.(*File).write (b=..., err=..., f=0x1040c0f0, n=2729821 44) at /usr/local/go/src/os/file_unix.go:243 No locals. #7 0x00072ffc in os.(*File).Write (b=..., err=..., f=0x1040c0f0, n=0) at /usr/local/go/src/os/file.go:144 err.data = 0x12c0e8 <fmt.ppFree> "" err.itab = 0x8b7a8 <fmt.Fprintln+20> "\004" ~r2.data = 0x10456014 "" ~r2.itab = 0x0 #8 0x0008b7fc in fmt.Fprintln (a=..., err=..., n=233960, w=...) at /usr/local/go/src/fmt/print.go:255 p = 0x10456080 #9 0x0008b888 in fmt.Println (a=..., err=..., n=0) at /usr/local/go/src/fmt/print.go:264 No locals. #10 0x000916c0 in main.main () at /home/pi/hello.go:6 No locals. On further analysis, I find that segmentation fault is at __kuser_cmpxchg64. I have enabled CONFIG_KUSER_HELPERS=y when building the linux kernel. Any hint please on how to proceed. Best Regards, Sateesh Kalidas

3 3

← Newer
1
...
7
8
9
10
11
12
13
...
288
Older →

Jump to page:

2025

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