Preserve syscall flags for dynamically loaded syscalls

[guest-svmhdvn]

Summary

Using the https://github.com/google/capsicum-test/ suite, the PosixMqueue.CapModeForked test was failing due to an ECAPMODE after calling kmq_notify(). On further inspection, the following code from sys/kern/uipc_mqueue.c initialized the dynamically loaded syscall entry with sy_flags zeroed out:

static struct syscall_helper_data mq_syscalls[] = {
	SYSCALL_INIT_HELPER(kmq_open),
	SYSCALL_INIT_HELPER(kmq_setattr),
	SYSCALL_INIT_HELPER(kmq_timedsend),
	SYSCALL_INIT_HELPER(kmq_timedreceive),
	SYSCALL_INIT_HELPER(kmq_notify),
	SYSCALL_INIT_HELPER(kmq_unlink),
	SYSCALL_INIT_LAST
};

Not sure if this is the right way to go about this, please let me know.

[kib]

I think that the idea of the fix is sound, but technically I do not like it. Why sy_flags is copied from the bogus main syscall table into new sysent, while other fields are copied from the module-provided sysents ?

IMO what should be done is module sysent entries fixed to provide correct sy_flags. To achieve this, you might need to add e.g. SYSCALL_INIT_HELPER_F) macro which would take sy_flags argument in addition to the argument already taken by the SYSCALL_INIT_HELPER(), and initialize modules' syscall_helper_data tables with the correct flags.

[guest-svmhdvn]

Changed module syscall init helpers to initialize flags

[kib]

In D11576#239700, @smahadevan_freebsdfoundation.org wrote:

Changed module syscall init helpers to initialize flags

This looks good. Two more notes:

• compat32 helpers need same treatment
• I suggest to add a comment to capabilities.conf around the affected syscalls so that it is clear that flags might come from other place

[guest-svmhdvn]

• Added comment to sys/kern/capabilities.conf for more information on where the sysents are being initialized
• Added flags to SYSCALL32 initializers