Revision history for seL4 For more information see the release notes at https://docs.sel4.systems/sel4_release/ This file should be word wrapped to 120 characters The upcoming release notes should indicate whether it is a SOURCE COMPATIBLE, BINARY COMPATIBLE or BREAKING change. As changes are added the compatibility information should be updated. --- Upcoming release: BINARY COMPATIBLE ## Changes ## Upgrade Notes --- 10.1.1 2018-11-12: BINARY COMPATIBLE ## Changes * Remove theoretical uninitialised variable use in infer_cpu_gic_id for binary translation validation ## Upgrade Notes * 10.1.0 has a known broken test in the proofs. 10.1.1 fixes this test. --- 10.1.0 2018-11-07: SOURCE COMPATIBLE ## Changes * structures in the boot info are not declared 'packed' - these were previously packed (in the GCC attribute sense) - some field lengths are tweaked to avoid padding - this is a source-compatible change * ARM platforms can now set the trigger of an IRQ Handler capability - seL4_IRQControl_GetTrigger allows users to obtain an IRQ Handler capability and set the trigger (edge or level) in the interrupt controller. * Initial support for NVIDIA Jetson TX2 (ARMv8a, Cortex A57) * AARCH64 support added for raspberry pi 3 platform. * Code generation now use jinja2 instead of tempita. * AARCH32 HYP support added for running multiple ARM VMs * AARCH32 HYP VCPU registers updated. * A new invocation for setting TLSBase on all platforms. - seL4_TCB_SetTLSBase * Kbuild/Kconfig/Makefile build system removed. --- 10.0.0 2018-05-28: BREAKING - Final version of the kernel which supports integration with Kbuild based projects - Future versions, including this one, provide a CMake based build system For more information see https://docs.sel4.systems/Developing/Building. ## Changes * x86 IO ports now have an explicit IOPortControl capability to gate their creation. IOPort capabilities may now only be created through the IOPortControl capability that is passed to the rootserver. Additionally IOPort capabilities may not be derived to have smaller ranges and the IOPortControl will not issue overlapping IOPorts * 32-bit support added for the initial prototype RISC-V architecture port ## Upgrade Notes * A rootserver must now create IOPort capabilities from the provided IOPortControl capability. As IOPorts can not have their ranges further restricted after creation it must create capabilities with the final desired granularity, remembering that since ranges cannot overlap you cannot issue a larger and smaller range that have any IO ports in common. --- 9.0.1 2018-04-18: BINARY COMPATIBLE ## Changes * On 64-bit architectures, the `label` field of `seL4_MessageInfo` is now 52 bits wide. User-level programs which use any of the following functions may break, if the program relies on these functions to mask the `label` field to the previous width of 20 bits. - `seL4_MessageInfo_new` - `seL4_MessageInfo_get_label` - `seL4_MessageInfo_set_label` * Initial prototype RISC-V architecture port. This port currently only supports running in 64-bit mode without FPU or or multicore support on the Spike simulation platform. There is *no verification* for this platform. ## Upgrade Notes --- 9.0.0 2018-04-11: BREAKING = Changes = * Debugging option on x86 for syscall interface to read/write MSRs (this is an, equally dangerous, alternative to dangerous code injection) * Mitigation for Meltdown (https://meltdownattack.com) on x86-64 implemented. Mitigation is via a form of kernel page table isolation through the use of a Static Kernel Image with Microstate (SKIM) window that is used for trapping to and from the kernel address space. This can be enabled/disabled through the build configuration depending on whether you are running on vulnerable hardware or not. * Mitigation for Spectre (https://spectreattack.com) on x86 against the kernel implemented. Default is software mitigation and is the best performing so users need to do nothing. This does *not* prevent user processes from exploiting each other. * x86 configuration option for performing branch prediction barrier on context switch to prevent Spectre style attacks between user processes using the indirect branch predictor * x86 configuration option for flushing the RSB on context switch to prevent Spectre style attacks between user processes using the RSB * Define extended bootinfo header for the x86 TSC frequency * x86 TSC frequency exported in extended bootinfo header * `archInfo` is no longer a member of the bootinfo struct. Its only use was for TSC frequency on x86, which can now be retrieved through the extended bootinfo * Invocations to set thread priority and maximum control priority (MCP) have changed. - For both invocations, users must now provide a TCB capability `auth` - The requested MCP/priority is checked against the MCP of the `auth` capability. - Previous behavior checked against the invoked TCB, which could be subject to the confused deputy problem. * seL4_TCB_Configure no longer takes prio, mcp as an argument. Instead these fields must be set separately with seL4_TCB_SetPriority and seL4_TCB_SetMCPriority. * seL4_TCB_SetPriority and seL4_TCB_SetMCPriority now take seL4_Word instead of seL4_Uint8. - seL4_MaxPrio remains at 255. * seL4_TCB_SetSchedParams is a new method where MCP and priority can be set in the same sytsem call. * Size of the TCB object is increased for some build configurations = Upgrade notes = * seL4_TCB_Configure calls that set priority should be changed to explicitly call seL4_TCB_SetSchedParams or SetPriority * seL4_TCB_Configure calls that set MCP should be changed to explicitly call seL4_TCB_SetSchedParams or seL4_TCB_SetMCPriority --- 8.0.0 2018-01-17 = Changes = * Support for additional zynq platform Zynq UltraScale+ MPSoC (Xilinx ZCU102, ARMv8a, Cortex A53) * Support for multiboot2 bootloaders on x86 (contributed change from Genode Labs) * Deprecate seL4_CapData_t type and functions related to it * A fastpath improvement means that when there are two runnable threads and the target thread is the highest priority in the scheduler, the fastpath will be hit. Previously the fastpath would not be used on IPC from a high priority thread to a low priority thread. * As a consequence of the above change, scheduling behaviour has changed in the case where a non-blocking IPC is sent between two same priority threads: the sender will be scheduled, rather than the destination. * Benchmarking support for armv8/aarch64 is now available. * Additional x86 extra bootinfo type for retrieving frame buffer information from multiboot 2 * Debugging option to export x86 Performance-Monitoring Counters to user level = Upgrade notes = * seL4_CapData_t should be replaced with just seL4_Word. Construction of badges should just be `x` instead of `seL4_CapData_Badge_new(x)` and guards should be `seL4_CNode_CapData_new(x, y)` instead of `seL4_CapData_Guard_new(x, y)` * Code that relied on non-blocking IPC to switch between threads of the same priority may break. --- 7.0.0 2017-09-05 = Changes = * Support for building standalone ia32 kernel added * ia32: Set sensible defaults for FS and GS selectors * aarch64: Use tpidrro_el0 for IPC buffer instead of tpidr_el0 * More seL4 manual documentation added for aarch64 object invocations * Default NUM_DOMAINS set to 16 for x86-64 standalone builds * libsel4: Return seL4_Error in invocation stubs in 8fb06eecff9 ''' This is a source code level breaking change ''' * Add a CMake based build system * x86: Increase TCB size for debug builds * libsel4: x86: Remove nested struct declarations ''' This is a source code level breaking change ''' * Bugfix: x86: Unmap pages when delete non final frame caps = Upgrade notes = * This release is not source compatible with previous releases. * seL4 invocations that previously returned long now return seL4_Error which is an enum. Our libraries have already been updated to reflect this change, but in other places where seL4 invocations are used directly, the return types will need to be updated to reflect this change. * On x86 some structs in the Bootinfo have been rearranged. This only affects seL4_VBEModeInfoBlock_t which is used if VESA BIOS Extensions (VBE) information is being used. = Known issues = * One of our tests is non-deterministicly becoming unresponsive on the SMP release build on the Sabre IMX.6 platform, which is a non verified configuration of the kernel. We are working on fixing this problem, and will likely do a point release once it is fixed. --- For previous releases see https://docs.sel4.systems/sel4_release/