`align_memory()` in hardware.py both modifies the first normal memory
region to adjust the base of it for alignment, and adds an extra
reserved region to our list of reserved regions. This then feeds
through `get_addrspace_exclude` which inverts the regions given
and turns it into the available "device memory" at user-level.
dev_mem = hardware.utils.memory.get_addrspace_exclude(
list(reserved) + phys_mem + kernel_devs, config)
Anything as an argument to this is not given as "device memory" by
the kernel. (It does not precisely match how the kernel works).
However, since `align_memory()` has adjusted both the phys_mem up
(which *would* have added this region as "device" memory) but also
added it to "reserved" region, which then made it disappear entirely,
as "reserved" regions are not exposed to userspace.
However, this **does not** match the behaviour of the kernel, as it was
not reserved, so this behaviour did not match the untypeds given to
userspace. This commit solves this by removing the extra reserved
region being added for that memory.
PR #1426 worked around this issue by removing the alignment on AArch64.
Whilst this fixed the issue that microkit was seeing, it just masked
the underlying issue. Reverting that PR, then applying this fix,
results in the following platform_gen.yaml:
devices:
- end: 0x1000000
start: 0x0
- end: 0xff800000
start: 0x3b400000
- end: 0xff841000
start: 0xff801000
- end: 0x100000000000
start: 0xff843000
memory:
- end: 0x3b400000
start: 0x1000000
Note especially the device region from 0x0 to 0x1000000; which is the
combination of the 0x0 to 0x1000 reserved region, and the 0x1000 to
0x1000000 reserved by the kernel's alignment requirement. Previously,
the platform_gen.yaml reported only the 0x0 to 0x1000 region,
devices:
- end: 0x1000
start: 0x0
- end: 0xff800000
start: 0x3b400000
- end: 0xff841000
start: 0xff801000
- end: 0x100000000000
start: 0xff843000
memory:
- end: 0x3b400000
start: 0x1000000
I will be following this commit up with a PR to instead make the
alignment-reserved region into a new memory region, since there's not
any reason why userspace can't use this memory.
This has been tested on a few platforms with sel4test and with
microkit on the pi4B.
Signed-off-by: julia <git.ts@trainwit.ch>
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
- Overview
- Doc Site
- seL4 libraries
- seL4Test
- Debugging guide
- Benchmarking guide
- Virtualization on seL4
- Host Build Dependencies
- Porting seL4
Community
- Open-source help and support:
See also the contact links on the seL4 website.
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 PDF version of the manual for the most recent release can be found here.
A web version of the API documentation is available as well.
Repository Overview
includeandsrc: C and ASM source code of seL4tools: build toolslibsel4: C bindings for the seL4 ABImanual: LaTeX sources of the seL4 reference manual
Build Instructions
See the seL4 website for build instructions.
Status
- Releases: list of available seL4 releases
- Roadmap: new features in development
- Hardware Support: information about hardware platform ports
- Kernel Options: information about available config options and features
License
See the file LICENSE.md.