On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > On 06/25, Andy Lutomirski wrote: >> >> On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: >> > On 06/25, Andy Lutomirski wrote: >> >> >> >> Write the filter, then smp_mb (or maybe a weaker barrier is okay), >> >> then set the bit. >> > >> > Yes, exactly, this is what I meant. Plas rmb() in __secure_computing(). >> > >> > But I still can't understand the rest of your discussion about the >> > ordering we need ;) >> >> Let me try again from scratch. >> >> Currently there are three relevant variables: TIF_SECCOMP, >> seccomp.mode, and seccomp.filter. __secure_computing needs >> seccomp.mode and seccomp.filter to be in sync, and it wants (but >> doesn't really need) TIF_SECCOMP to be in sync as well. >> >> My suggestion is to rearrange it a bit. Move mode into seccomp.filter >> (so that filter == NULL implies no seccomp) and don't check This would require that we reimplement mode 1 seccomp via mode 2 filters. Which isn't too hard, but may add complexity. >> TIF_SECCOMP in secure_computing. Then turning on seccomp is entirely >> atomic except for the fact that the seccomp hooks won't be called if >> filter != NULL but !TIF_SECCOMP. This removes all ordering >> requirements. > > Ah, got it, thanks. Perhaps I missed somehing, but to me this looks like > unnecessary complication at first glance. > > We alredy have TIF_SECCOMP, we need it anyway, and we should only care > about the case when this bit is actually set, so that we can race with > the 1st call of __secure_computing(). > > Otherwise we are fine: we can miss the new filter anyway, ->mode can't > be changed it is already nonzero. > >> Alternatively, __secure_computing could still BUG_ON(!seccomp.filter). >> In that case, filter needs to be set before TIF_SECCOMP is set, but >> that's straightforward. > > Yep. And this is how seccomp_assign_mode() already works? It is called > after we change ->filter chain, it changes ->mode before set(TIF_SECCOMP) > just it lacks a barrier. Right, I think the best solution is to add the barrier. I was concerned that adding the read barrier in secure_computing would have a performance impact, though. -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
