On 13/06/2019 16:57, Catalin Marinas wrote:
On Thu, Jun 13, 2019 at 04:45:54PM +0100, Vincenzo Frascino wrote:
On 13/06/2019 16:35, Catalin Marinas wrote:
On Thu, Jun 13, 2019 at 12:16:59PM +0100, Dave P Martin wrote:
On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
+/*
- Control the relaxed ABI allowing tagged user addresses into the kernel.
- */
+static unsigned int tagged_addr_prctl_allowed = 1;
+long set_tagged_addr_ctrl(unsigned long arg) +{
- if (!tagged_addr_prctl_allowed)
return -EINVAL;So, tagging can actually be locked on by having a process enable it and then some possibly unrelated process clearing tagged_addr_prctl_allowed. That feels a bit weird.
The problem is that if you disable the ABI globally, lots of applications would crash. This sysctl is meant as a way to disable the opt-in to the TBI ABI. Another option would be a kernel command line option (I'm not keen on a Kconfig option).
Why you are not keen on a Kconfig option?
Because I don't want to rebuild the kernel/reboot just to be able to test how user space handles the ABI opt-in. I'm ok with a Kconfig option to disable this globally in addition to a run-time option (if actually needed, I'm not sure).
There might be scenarios (i.e. embedded) in which this is not needed, hence having a config option (maybe Y by default) that removes from the kernel the whole feature would be good, obviously in conjunction with the run-time option.
Based on my previous review, if we move out the code from process.c in its own independent file when the Kconfig option is turned off we could remove the entire object from the kernel (this would remove the sysctl and let still the prctl return -EINVAL).
These changes though could be done successively with a separate patch set, if the Kconfig is meant to be Y by default.