Page MenuHomeFreeBSD

sysent: Add sv_protect
ClosedPublic

Authored by andrew on Nov 2 2023, 10:32 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 10 2024, 10:28 AM
Unknown Object (File)
Jan 30 2024, 7:11 AM
Unknown Object (File)
Jan 30 2024, 7:11 AM
Unknown Object (File)
Jan 26 2024, 8:47 PM
Unknown Object (File)
Jan 19 2024, 3:12 AM
Unknown Object (File)
Jan 18 2024, 1:21 PM
Unknown Object (File)
Jan 5 2024, 10:34 PM
Unknown Object (File)
Dec 23 2023, 3:36 AM
Subscribers

Details

Summary

To allow for architecture specific protections add sv_protect to struct
sysent. This can be used to apply these after the executable is loaded
into the new address space.

Sponsored by: Arm Ltd

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib added inline comments.
sys/kern/imgact_elf.c
1374–1377

May be move the call there? More data for imgp is initialized.

This revision is now accepted and ready to land.Nov 2 2023, 11:46 AM

Move sv_protect later and add it to __elfN(load_file)

This revision now requires review to proceed.Nov 2 2023, 2:32 PM

Move sv_protect later and add it to __elfN(load_file)

Why adding it to load_file? Now the callback is executing three times at least.

Why will it be called three times? It should only be called for the main executable, and in whichever load_file calls is successful.

I added it to load_file so the runtime linker will also be protected from when it starts executing.

Why will it be called three times? It should only be called for the main executable, and in whichever load_file calls is successful.

I added it to load_file so the runtime linker will also be protected from when it starts executing.

Yes, it will be called twice, but I do not understand why is it should be arranged that way. Call it after everything is mapped, i.e. both the binary and optional interpreter.

For BTI we need to parse the ELF file to read a note to decide if protection should be enabled for just the memory loaded from that file. Because of this it's easier to check if we should protect some address space on a per-file base to both check if we need to enable BTI, and for what memory it needs to be enabled.

Then would it be more logical to have two differently named callbacks, indicating their purpose?

I added a flag for the callback to know if it's from the main executable, or the interpreter.

sys/kern/imgact_elf.c
866

Can we name the constants? E.g. SV_PROTECT_IMAGE and SV_PROTECT_INTERP

This revision is now accepted and ready to land.Nov 6 2023, 4:01 PM
This revision was automatically updated to reflect the committed changes.