MAC: Use the current thread's user ABI to determine the layout of struct mac

[jhb]

Summary

This removes mac_label_copyin32() as mac_label_copyin() can now handle
both native and 32-bit struct mac objects.

Obtained from: CheriBSD
Sponsored by: AFRL, DARPA

[olce]

sys/security/mac/mac_syscalls.c

99

I would keep the original type for u_mac, as it is not a pointer to a struct mac for 32-bit processes, which could lead to programming errors.

In general, I think userland pointers in the kernel should always be of type void * to avoid inadvertent direct uses. The argument name (and herald comments) should be enough of a documentation for what kind of thing these pointers point to.

[jrtc27]

sys/security/mac/mac_syscalls.c

99

That’s the opposite of what makesyscalls.lua generates. Typed pointers are the style.

[olce]

sys/security/mac/mac_syscalls.c

99

makesyscalls.lua does not generate sub-routines to copy in sub-structures, and particularly sub-routines that can adapt to the ABI (thus supporting multiple types in input), so relating its output to the style of mac_label_copyin() is dubious. makesyscalls.lua generates one prototype per ABI, with indeed the proper type for arguments there but they are encapsulated in a per-syscall-specific structure.

The point here is precisely that there is a stronger reason than questionable consistency to actually *not* have a readily usable type: Avoid errors where userland pointers are directly used in the kernel. And I don't see any real drawback in doing that. Do you see some? Are there Cheri-specific ones?

The situation of syscall prototypes is slightly different because arguments appear as fields of a syscall-specific structure, so at least you have to use an indirection to get access to them, which is already a (more or less) visible indication that you're fetching a userland pointer. But it's only an advisory one; in this case also, the compiler won't prevent you to use a pointer argument directly, that's the link I would instead make between makesyscalls.lua and the situation here.

So I think we should actually either convert all of the pointer arguments to void * for kernel prototypes, or use a more clever scheme, ideally tagging such arguments with some attributes making it a compile error to dereference the pointer, but I don't know if that is readily possible (I seem to recall seeing something like __userland in Linux a while ago? I'll look that up). Note that this would concern all syscall entry points, e.g., the sys_*() functions (tagging the fields of their associated structure), but not necessarily the kern_*() or user_*() ones. But those last ones would anyway need to take a void * pointer or, better, some pointer to a union, in case they have to handle "polymorphic" pointers.