On Tue, Jul 28, 2020 at 03:53:51PM +0100, Szabolcs Nagy wrote: > The 07/28/2020 12:08, Dave Martin wrote: > > On Mon, Jul 27, 2020 at 05:36:35PM +0100, Szabolcs Nagy wrote: > > > a solution is to introduce a flag like SECCOMP_FILTER_FLAG_TSYNC > > > that means the prctl is for all threads in the process not just > > > for the current one. however the exact semantics is not obvious > > > if there are inconsistent settings in different threads or user > > > code tries to use the prctl concurrently: first checking then > > > setting the mte state via separate prctl calls is racy. but if > > > the userspace contract for enabling mte limits who and when can > > > call the prctl then i think the simple sync flag approach works. > > > > > > (the sync flag should apply to all prctl settings: tagged addr > > > syscall abi, mte check fault mode, irg tag excludes. ideally it > > > would work for getting the process wide state and it would fail > > > in case of inconsistent settings.) > > > > If going down this route, perhaps we could have sets of settings: > > so for each setting we have a process-wide value and a per-thread > > value, with defines rules about how they combine. > > > > Since MTE is a debugging feature, we might be able to be less aggressive > > about synchronisation than in the SECCOMP case. > > separate process-wide and per-thread value > works for me and i expect most uses will > be process wide settings. The problem with the thread synchronisation is, unlike SECCOMP, that we need to update the SCTLR_EL1.TCF0 field across all the CPUs that may run threads of the current process. I haven't convinced myself that this is race-free without heavy locking. If we go for some heavy mechanism like stop_machine(), that opens the kernel to DoS attacks from user. Still investigating if something like membarrier() would be sufficient. SECCOMP gets away with this as it only needs to set some variable without IPI'ing the other CPUs. > i don't think mte is less of a security > feature than seccomp. Well, MTE is probabilistic, SECCOMP seems to be more precise ;). > if linux does not want to add a per process > setting then only libc will be able to opt-in > to mte and only at very early in the startup > process (before executing any user code that > may start threads). this is not out of question, > but i think it limits the usage and deployment > options. There is also the risk that we try to be too flexible at this stage without a real use-case. -- Catalin
