sel4 / musllibc

The seL4 microkernel

This project contains the source code of seL4 microkernel.

For details about the seL4 microkernel, including details about its formal correctness proof, please see the sel4.systems website and associated FAQ.

DOIs for citing recent releases of this repository:

• 

We welcome contributions to seL4. Please see the website for information on how to contribute.

This repository is usually not used in isolation, but as part of the build system in a larger project.

seL4 Basics

• Tutorials
• Documentation
• seL4 libraries
• seL4Test
• Debugging guide
• Benchmarking guide
• Virtualization on seL4
• Host Build Dependencies
• Porting seL4

Community

• Forums:
  • Discourse
  • seL4 Announce
  • seL4 Devel
• Suggested projects
• Community projects

See the contact links on the seL4 website for the full list.

Reporting security vulnerabilities

If you believe you have found a security vulnerability in seL4 or related software, we ask you to follow our vulnerability disclosure policy.

Manual

A hosted version of the manual for the most recent release can be found here.

A web version of the API can be found here

Repository Overview

• include and src: C and ASM source code of seL4
• tools: build tools
• libsel4: C bindings for the seL4 ABI
• manual: LaTeX sources of the seL4 reference manual

Build Instructions

See the seL4 website for build instructions.

Status

A list of releases and current project status can be found under seL4 releases.

• Roadmap: new features in development
• Hardware Support: information about hardware platform ports
• Kernel Features: information about available kernel features
• Userland Components and Drivers: available device drivers and userland components

License

See the file LICENSE.md.

musllibc's Issues

Current gcc complains about bad relocations for stdin_used etc.__

 musllibc/build-temp/stage/lib/libc.a(__stdio_exit.o): copy relocation against non-copyable protected symbol `__stdin_used'

with gcc 10 or later.

Fault in memalign leads to memory corruption

This issue was previously the subject a discussion on the devel mailing list. The conclusion of the discussion was the detection of a fault in the implementation of memalign that results in memory corruption.

Fault Summary:

The correctness of the memory allocation bookkeeping system relies upon the constraint that the minimum size of a memory 'chunk' is 4xsizeof(size_t). If this constraint is broken then bad things happen and the bookkeeping system becomes corrupted, specifically:

1. Arithmetic wrap-around of x occurs in the routines bin_index and bin_index_up within malloc.c. This can lead to chunks below the minimum size limit to be considered to be large unallocated chunks of memory. Subsequent allocation of these unallocated chunks (considered to be large but in reality tiny) allows previously allocated chunks to be re-used / overwritten.

2. The 'next' and 'prev' pointers held in an unallocated chunk (used to maintained a doubly linked list of unallocated chunks) that is below the minimum size limit may be overlayed with the bookkeeping of the following chunk.

The malloc routine enforces this minimum chunk size limit, however the code of the __memalign routine within memalign.c can break this minimum size constraint and therefore lead to corruption of the bookkeeping.

The __memalign routine works by malloc'ing sufficient memory to ensure the requested amount of memory is available, at the requested alignment, somewhere within the malloc'ed region. This means that there may be some unused memory allocated before the start of the aligned memory area. This is handled by splitting the chunk allocated by malloc into two chunks, a chunk of memory prior to the start of the aligned memory followed by a chunk that starts at the requested alignment. __memalign then calls 'free' on the first chunk which wasn't required. So far so good, however __memalign fails to enforce the minimum chunk size constraint on either of the two split chunks.

In our case the first chunk (the one to be freed) was only 16 bytes whilst 4xsizeof(size_t) is 32 bytes, thereby breaking the minimum chunk size constraint and so led to the detected corruption.

Proposed fix

The following patch to memalign has been tested and shown to resolve the identified weakness:

diff --git a/src/malloc/memalign.c b/src/malloc/memalign.c
index 006bd21c..c98963f0 100644
--- a/src/malloc/memalign.c
+++ b/src/malloc/memalign.c
@@ -21,6 +21,9 @@ void *__memalign(size_t align, size_t len)
                errno = ENOMEM;
                return NULL;
        }
+       else if (len < 4*sizeof(size_t))
+               /* Ensure the length of returned chunk meets the minimum limit. */
+               len = 4*sizeof(size_t);
 
        if (align <= 4*sizeof(size_t)) {
                if (!(mem = malloc(len)))
@@ -50,7 +53,29 @@ void *__memalign(size_t align, size_t len)
        ((size_t *)new)[-1] = header&7 | end-new;
        ((size_t *)end)[-2] = footer&7 | end-new;
 
-       free(mem);
+       if (new-mem >= 4*sizeof(size_t))
+               free(mem);
+       else {
+               /* The size of the region before 'new' is too small to be handled as a chunk
+                * so we cannot call 'free' on it. Instead we either discard the memory or
+                * transfer ownership of it to the previous chunk */
+               if (!(((size_t *)mem)[-2] & -8)) {
+                       /* mem->psize has no length, i.e. 'mem' is the first chunk in this mapped
+                        * region. In this case we simply discard the memory prior to 'new' by
+                        * making 'new' the first chunk of the mapped region. To do this we set
+                        * the length of new->psize to 0 with the 'in use' flag set, which equates
+                        * to simply setting its value to 1. */
+                       ((size_t *)new)[-2] = 1;
+               }
+               else {
+                       /* There is a previous chunk, assign ownership of the region before 'new'
+                        * to this previous chunk by increasing it's length. */
+                       unsigned char *pre = mem - (((size_t *)mem)[-2] & -8);
+                       ((size_t *)pre)[-1] += new-mem;
+                       ((size_t *)new)[-2] = ((size_t *)pre)[-1];
+               }
+       }
+
        return new;
 }

Improper Linking on x86_64 Target when Compiling w/ M1 MAC

I know compiling with ARM hosts isn't technically supported, but I've been able to compile images with only a single change to the kernel's gcc.cmake file.

Compiling the adder application for x86_64 gives images which fail when simulated and run on x86 hardware.

Caught cap fault in send phase at address 0
while trying to handle:
unknown syscall 0x10
in thread 0xffffff801fc08400 "rootserver" at address 0x41b9a5

Doing a decompilation, the instructions at 0x41b9a5 are:

000000000041b998 <__set_thread_area>:
  41b998:	48 89 fe             	mov    %rdi,%rsi
  41b99b:	bf 02 10 00 00       	mov    $0x1002,%edi
  41b9a0:	b8 9e 00 00 00       	mov    $0x9e,%eax
  41b9a5:	0f 05                	syscall 
  41b9a7:	c3                   	retq   

This tracks with the error print where seL4 can't handle the syscall.

The interesting this is that when decompiling a working image (compiled on an x86 host), the __set_thread_area function is this:

000000000041c28a <__set_thread_area>:
  41c28a:	48 89 fe             	mov    %rdi,%rsi
  41c28d:	bf cd 00 00 00       	mov    $0xcd,%edi
  41c292:	50                   	push   %rax
  41c293:	31 c0                	xor    %eax,%eax
  41c295:	ff 15 65 d2 b8 05    	call   *0x5b8d265(%rip)        # 5fa9500 <__sysinfo>
  41c29b:	5a                   	pop    %rdx
  41c29c:	c3                   	ret    

Which tracks with the x86_64_sel4 implementation of syscall.

I'm trying to get a working musllibc build directory to compare against, but does anyone have any ideas?

delete branch kent/wcsnrtombs-fix

delete branch kent/wcsnrtombs-fix, this has been merged.

CVE-2020-28928

Hi,

the musl libc v1.1.16 that this repo is based on is affected by CVE-2020-28928.

For further information please refer to:
https://musl.libc.org/
https://www.openwall.com/lists/musl/2020/11/19/1

Please update or patch this known vulnerability.

Thanks!

Dynamic linking of NEEDED with absolute path differs than that of glibc

Hello! First off, thank you for this project.

I am working on a tool that takes all the NEEDED from downstream shared object dependencies and lifts them to the top executable. I then change the NEEDED in the top executable to be absolute paths. This seems to work as expected in glibc.

Please use this example for demonstrations:

Here I have two shared objects libbar and libfoo, where foo depends on bar.

❯ patchelf --print-needed libbar.so
libc.so.6
❯ patchelf --print-soname libbar.so
libbar.so

❯ patchelf --print-needed libfoo.so
libbar.so
libc.so.6

I then add libbar and libfoo to another executable but reference them in NEEDED with explicit paths.

patchelf --print-needed tests/scratch/replace-add-needed/simple
/some-fixed-path/libbar.so
/some-fixed-path/libfoo.so
/lib/x86_64-linux-gnu/libc.so.6

glibc seems to happily link this and the executable runs.

ldd ./tests/scratch/replace-add-needed/simple
	linux-vdso.so.1 (0x00007ffc98d98000)
	/some-fixed-path/libbar.so (0x00007f269b6d3000)
	/some-fixed-path/llibfoo.so (0x00007f269b6ce000)
	/lib/x86_64-linux-gnu/libc.so.6 (0x00007f269b509000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f269c6e3000)

If I do the same however with musl it doesn't seem to link and complains about not finding libbar.so

ldd ./tests/scratch/replace-add-needed/simple 
	/lib/ld-musl-x86_64.so.1 (0x7f04dd7cd000)
	/some-fixed-path/libbar.so (0x7f04dc7bf000)
	/some-fixed-path/libfoo.so (0x7f04dc7ba000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f04dd7cd000)
Error loading shared library libbar.so: No such file or directory (needed by /some-fixed-path/libfoo.so)

CC @trws

The sel4 thread implementation, what pthread model is ?

Is user space thread, or 1:1 kernel thread(like Linux)? Can the threads be scheduled to different CPU core?

rebase musllibc on top of upstream master

Follow-up from a Mattermost suggestion from @kent-mcleod: rebase musllibc on top of upstream master. Might be worth trying a merge commit there to have sychronization point again.

gcc 10.2.0 complains getcwd() could return address of local variable

With gcc 10.2.0 I get this warning for getcwd()

.../libs/musllibc/src/unistd/getcwd.c: In function 'getcwd':
cc1: warning: function may return address of local variable [-Wreturn-local-addr]
...libs/musllibc/src/unistd/getcwd.c:9:7: note: declared here
    9 |  char tmp[PATH_MAX];
      |    

To be checked if this has been fixed in upstream musllibc already.