sysent: Add sv_protect

[andrew]

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

[kib]

sys/kern/imgact_elf.c

1374–1377

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

[andrew]

Move sv_protect later and add it to __elfN(load_file)

[kib]

In D42440#968474, @andrew wrote:

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.

[andrew]

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.

[kib]

In D42440#968760, @andrew wrote:

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.

[andrew]

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.

[kib]

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

[andrew]

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

[kib]

sys/kern/imgact_elf.c

866

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

[andrew]

Use named flags