Page MenuHomeFreeBSD

arm64: Set the Guarded Page flag in the kernel

Authored by andrew on Oct 4 2023, 3:23 PM.
Referenced Files
F84280896: D42080.diff
Tue, May 21, 7:41 PM
Unknown Object (File)
Thu, May 2, 2:04 PM
Unknown Object (File)
Mon, Apr 29, 8:15 AM
Unknown Object (File)
Sat, Apr 27, 12:43 PM
Unknown Object (File)
Apr 14 2024, 11:05 PM
Unknown Object (File)
Jan 5 2024, 10:32 PM
Unknown Object (File)
Dec 25 2023, 5:20 PM
Unknown Object (File)
Dec 21 2023, 2:46 AM



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

Sponsored by: Arm Ltd
Sponsored by: The FreeBSD Foundation (earlier version)

Diff Detail

rG FreeBSD src repository
Lint Not Applicable
Tests Not Applicable

Event Timeline

Can you set this flag on intermediate translation table entries as well?

Can you set this flag on intermediate translation table entries as well?

No, it only exists in leaves.

For the most part, these changes are setting the guarded bit on mappings that are already no-execute. Is there a reason to do that? To be clear, I don't object to doing so. It just seems redundant.

This revision is now accepted and ready to land.Oct 8 2023, 7:43 PM

I put it on all entries as I though it would be safer. If we miss setting the *XN flags the kernel could still branch into data, however with the GP flag always set it's more difficult.

Looks good, my BTI capable machine continues booting with this applied.

Add pmap_bti_get and use it in functions that can create userspace mappings.
It will later be used to support userspace BTI.

This revision now requires review to proceed.Oct 17 2023, 11:17 AM

Please group this with other function prototypes below. Or, define the function together with pmap_pte_prot(), and then you don't need the forward declaration.


Do you need a __diagused annotation for va?


pmap_pte_bti() would be a better name in my opinion.


I agree. It's consistent with similar functions.

  • Rename pmap_bti_get to pmap_pte_bti
  • Move the pmap_pte_bti definition
  • Check and use pmap_pte_bti while locked to reduce the userspace support diff
  • Make the virtual address as __diagused
This revision is now accepted and ready to land.Nov 2 2023, 1:47 PM