#
c2e0d56f |
| 04-Jun-2024 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Support BTI checking in most of the kernel
LLD has the -zbti-report=error argument to check if the BTI note is present when linking. To allow for this to be used when linking the kernel and m
arm64: Support BTI checking in most of the kernel
LLD has the -zbti-report=error argument to check if the BTI note is present when linking. To allow for this to be used when linking the kernel and modules: - Add the BTI note to the remaining assembly files - Mark ptrauth.c as protected by BTI - Disable -zbti-report for vmm hypervisor switching code as it's not used there.
The linux64 module doesn't build with the flag as it includes vdso code that doesn't include the note.
Reviewed by: imp, kib, emaste Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D45466
show more ...
|
#
94b09d38 |
| 11-May-2024 |
Alan Cox <alc@FreeBSD.org> |
arm64: map kernel using large pages when page size is 16K
When the page size is 16K, use ATTR_CONTIGUOUS to map the kernel code and data sections using 2M pages. Previously, they were mapped using
arm64: map kernel using large pages when page size is 16K
When the page size is 16K, use ATTR_CONTIGUOUS to map the kernel code and data sections using 2M pages. Previously, they were mapped using 16K pages.
Reviewed by: markj Tested by: markj Differential Revision: https://reviews.freebsd.org/D45162
show more ...
|
#
634dd430 |
| 24-Apr-2024 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Update the page table list in locore
The comment describing the page tables was out of date. Update it with the current list.
Sponsored by: Arm Ltd
|
#
719908c8 |
| 25-Apr-2024 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Merge common page table creation code
Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D45061
|
#
c78ebc69 |
| 29-Apr-2024 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Support a shared release for spin-table
When releasing multiple CPUs that share a release address we need them to wait for their turn to boot. Add a mechanism to do this by booting them until
arm64: Support a shared release for spin-table
When releasing multiple CPUs that share a release address we need them to wait for their turn to boot. Add a mechanism to do this by booting them until they enable the TLB before waiting their turn to enter init_secondary.
Reviewed by: jhibbits, kevans Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D45082
show more ...
|
#
801160f4 |
| 15-Feb-2024 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Rename drop_to_el1 to enter_kernel_el
In the future we may not drop to EL1, e.g. when we support FEAT_VHE where the kernel runs in EL2.
Reviewed by: emaste, imp Sponsored by: Arm Ltd Differe
arm64: Rename drop_to_el1 to enter_kernel_el
In the future we may not drop to EL1, e.g. when we support FEAT_VHE where the kernel runs in EL2.
Reviewed by: emaste, imp Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43976
show more ...
|
#
c6a6ec85 |
| 01-Mar-2024 |
Alfredo Mazzinghi <am2419@cl.cam.ac.uk> |
arm64: Fix typo in pagetable_l0_ttbr0_bootstrap symbol name
Obtained from: CheriBSD
|
#
37563d39 |
| 15-Feb-2024 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Use the new CurrentEL macros
Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43972
|
#
90372a9e |
| 26-Jan-2024 |
Mark Johnston <markj@FreeBSD.org> |
arm64: Remove pmap_san_bootstrap() and call kasan_init_early() directly
pmap_san_bootstrap() doesn't really do much, and it was hard-coding the the bootstrap stack size defined in locore.S. Moreove
arm64: Remove pmap_san_bootstrap() and call kasan_init_early() directly
pmap_san_bootstrap() doesn't really do much, and it was hard-coding the the bootstrap stack size defined in locore.S. Moreover, the name is a bit confusing given the existence of pmap_bootstrap_san(). Just remove it and call kasan_init_early() directly like we do on amd64. It will not be used by KMSAN in a forthcoming patch series.
No functional change intended.
MFC after: 1 week Sponsored by: Klara, Inc. Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D43403
show more ...
|
#
1b9096cd |
| 03-Oct-2023 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Set the Guarded Page flag in the kernel
Now the kernel and modules are built with branch protection we can enablethe Guarded Page flag in the page tables. This causes indirect branches to a l
arm64: Set the Guarded Page flag in the kernel
Now the kernel and modules are built with branch protection we can enablethe Guarded Page flag in the page tables. This causes indirect branches to a location without a correct landing pad instruction to raise an exception.
This should help mitigate some attacks where a function pointer is changed to point somewhere other than the start of the function, however it doesn't stop an attacker pointing it to an unintended function.
Reviewed by: alc, scottph (both earlier version), markj Sponsored by: Arm Ltd Sponsored by: The FreeBSD Foundation (earlier version) Differential Revision: https://reviews.freebsd.org/D42080
show more ...
|
#
f3a83b3a |
| 15-Nov-2023 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Remove an old comment
This was missed when removing kern_delta
Sponsored by: Arm Ltd
|
#
257b0445 |
| 15-Nov-2023 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Correct a comment in locore.S
We now use the physical address of get_load_phys_addr. Use it in a comment rather than the old symbol.
Sponsored by: Arm Ltd
|
#
61f14f1d |
| 13-Nov-2023 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Clean up finding our load address
Use the linker to pre-calculate the offset of a known symbol from KERNBASE, and use this to find the physical address KERNBASE should map to.
Sponsored by:
arm64: Clean up finding our load address
Use the linker to pre-calculate the offset of a known symbol from KERNBASE, and use this to find the physical address KERNBASE should map to.
Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D42568
show more ...
|
#
ba313626 |
| 13-Nov-2023 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Make kern_delta unneeded in the boot params
Use pmap_early_vtophys to translate from a virtual to physical where we were previously using the calculated delta. This means that, while we still
arm64: Make kern_delta unneeded in the boot params
Use pmap_early_vtophys to translate from a virtual to physical where we were previously using the calculated delta. This means that, while we still calculate it, we don't need to pass it to initarm or either pmap bootstrap functions.
While here remove an unneeded printf that indirectly used it or was related to the previous printf.
Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D42567
show more ...
|
#
7eb26be9 |
| 11-Nov-2023 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Use adrp + :lo12: to load globals from asm
When loading a global variable we can use a pseudo-instruction similar to "ldr, xn, =global" to load the address of the symbol. As this is unlikely
arm64: Use adrp + :lo12: to load globals from asm
When loading a global variable we can use a pseudo-instruction similar to "ldr, xn, =global" to load the address of the symbol. As this is unlikely to be supported by a mov instruction a pc-relative load is used, with the absolute address written at the end of the function so it will be loaded.
This load can be partially replaced with an adrp instruction. This generates the address, aligned to a 4k boundary, using a pc-relative addition. Because the address is 4k-aligned we then update reading the global variable using a load with the offset of the load the low 12-bits of the global. Arm64 assemblers have :lo12: to support this, e.g. "ldr xn, [xn, :lo12:global]".
The only remaining users of "ldr, xn, =global" that I can find are executed from the physical address space the kernel was loaded in and need an address in the kernels virtual address space. Because of this they can't use adrp.
Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D42565
show more ...
|
#
b9c0003f |
| 13-Nov-2023 |
Mark Johnston <markj@FreeBSD.org> |
arm64: Initialize x18 for APs earlier during boot
When KMSAN is configured, the instrumentation inserts calls to __msan_get_context_state() into all function prologues. The implementation dereferen
arm64: Initialize x18 for APs earlier during boot
When KMSAN is configured, the instrumentation inserts calls to __msan_get_context_state() into all function prologues. The implementation dereferences curthread and thus assumes that x18 points to the PCPU area. This applies in particular to init_secondary(), which currently is responsible for initializing x18 for APs.
Move initialization into locore to avoid this problem. No functional change intended.
Reviewed by: kib, andrew MFC after: 2 weeks Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D42533
show more ...
|
#
e1fe3470 |
| 04-Jul-2023 |
Alfonso Gregory <gfunni234@gmail.com> |
arm64: Save an instruction in locore.S
We can move and sub at the same time, so let's do that.
Reviewed by: andrew, kevans Pull Request: https://github.com/freebsd/freebsd-src/pull/794
|
#
4095e0bc |
| 09-Oct-2023 |
Konstantin Belousov <kib@FreeBSD.org> |
arm64 locore.S: fix typos
Reviewed by: jhb, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D42143
|
#
e340882d |
| 03-Oct-2023 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Add BTI landing pads to assembly functions
When we enable BTI iboth the first instruction in a function that could be called indirectly, and a branch within a function need a valid landing pa
arm64: Add BTI landing pads to assembly functions
When we enable BTI iboth the first instruction in a function that could be called indirectly, and a branch within a function need a valid landing pad instruction.
There are three options for these instructions: 1. A breakpoint instruction 2. A pointer authentication PACIASP/PACIBSP 3. A BTI instruction
Option 1 will raise a breakpoint exception so isn't useable in either cases. Option 2 could be used in some function entry cases, but needs to be paired with an authentication instruction, and is normally only used in non-leaf functions we can't use it in this case. This leaves option 3.
There are four variants of the instruction, the C variant is used on function entry and the J variant is for jumping within a function. There is also a JC that works with both and one with no target that works with neither.
Reviewed by: markj Sponsored by: Arm Ltd Sponsored by: The FreeBSD Foundation (earlier version) Differential Revision: https://reviews.freebsd.org/D42078
show more ...
|
#
450f731b |
| 05-Apr-2023 |
Andrew Turner <andrew@FreeBSD.org> |
Add BTI exceptions
We could hit these when executing code marked as using BTI but jumps to a non-branch target instruction.
Sponsored by: Arm Ltd Sponsored by: The FreeBSD Foundation Differential R
Add BTI exceptions
We could hit these when executing code marked as using BTI but jumps to a non-branch target instruction.
Sponsored by: Arm Ltd Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39450
show more ...
|
#
95ee2897 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
136b8bd6 |
| 22-May-2023 |
Christos Margiolis <christos@FreeBSD.org> |
arm64: use PSR_DAIF instead of each individual flag
No functional change intended.
Reviewed by: mhorne, andrew Approved by: markj (mentor) Differential Revision: https://reviews.freebsd.org/D40165
|
#
37c1ef5a |
| 17-May-2023 |
Andrew Turner <andrew@FreeBSD.org> |
Move the arm64 sigcode to .rodata
The kernel doesn't execute this code, it's only ever copied to userspace. Move it to .rodata as we don't need to modify it.
Sponsored by: Arm Ltd Differential Revi
Move the arm64 sigcode to .rodata
The kernel doesn't execute this code, it's only ever copied to userspace. Move it to .rodata as we don't need to modify it.
Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D39399
show more ...
|
#
1a3cb489 |
| 31-Mar-2023 |
Mark Johnston <markj@FreeBSD.org> |
arm64: Move the initial kernel stack out of the init_pagetables section
init_pagetables is mapped into the segment containing the BSS, but does not get zeroed by locore. It is used for bootstrap pa
arm64: Move the initial kernel stack out of the init_pagetables section
init_pagetables is mapped into the segment containing the BSS, but does not get zeroed by locore. It is used for bootstrap page table pages.
It happens that the bootstrap kernel stack is also placed in that section, but there's no reason it shouldn't live in the BSS, so move it there. No functional change intended.
Reviewed by: andrew MFC after: 1 week Sponsored by: Klara, Inc. Sponsored by: Juniper Networks Differential Revision: https://reviews.freebsd.org/D39367
show more ...
|
#
89c52f9d |
| 23-Mar-2023 |
Kyle Evans <kevans@FreeBSD.org> |
arm64: add KASAN support
This entails: - Marking some obvious candidates for __nosanitizeaddress - Similar trap frame markings as amd64, for similar reasons - Shadow map implementation
The shadow m
arm64: add KASAN support
This entails: - Marking some obvious candidates for __nosanitizeaddress - Similar trap frame markings as amd64, for similar reasons - Shadow map implementation
The shadow map implementation is roughly similar to what was done on amd64, with some exceptions. Attempting to use available space at preinit_map_va + PMAP_PREINIT_MAPPING_SIZE (up to the end of that range, as depicted in the physmap) results in odd failures, so we instead search the physmap for free regions that we can carve out, fragmenting the shadow map as necessary to try and fit as much as we need for the initial kernel map. pmap_bootstrap_san() is thus after pmap_bootstrap(), which still included some technically reserved areas of the memory map that needed to be included in the DMAP.
The odd failure noted above may be a bug, but I haven't investigated it all that much.
Initial work by mhorne with additional fixes from kevans and markj.
Reviewed by: andrew, markj Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D36701
show more ...
|