On Wed, Jul 17, 2024 at 11:16:56AM -0700, Linus Torvalds wrote:
> On Wed, 17 Jul 2024 at 10:23, Kees Cook <kees@xxxxxxxxxx> wrote:
> >
> > For this to be available for general distros, I still want to have a
> > bootparam to control this, otherwise this mitigation will never see much
> > testing as most kernel deployments don't build their own kernels. A
> > simple __ro_after_init variable can be used.
>
> Oh, btw, I looked at the FOLL_FORCE back in 2017 when we did this:
>
> 8ee74a91ac30 ("proc: try to remove use of FOLL_FORCE entirely")
>
> and then we had to undo that with
>
> f511c0b17b08 (""Yes, people use FOLL_FORCE ;)"")
>
> but at the time I also had an experimental patch that worked for me,
> but I seem to have only sent that out in private to the people
> involved with the original issue.
>
> And then that whole discussion petered out, and nothing happened.
>
> But maybe we can try again.
>
> In particular, while people piped up about other uses (see the quotes
> in that commit f511c0b17b08) they were fairly rare and specialized.
>
> The one *common* use was gdb.
>
> But my old diff from years ago mostly still applies, so I resurrected it.
>
> It basically restricts FOLL_FORCE to just ptracers.
>
> That's *not* good for some of the people that piped up back when (eg
> Julia JIT), but it might be a more palatable halfway state.
>
> In particular, this patch would make it easy to make that
> SECURITY_PROC_MEM_RESTRICT_FOLL_FORCE config option be a "choice"
> where you pick "never, ptrace, always" by just changing the rules in
> proc_is_ptracing().
So the original patch could be reduced to just the single tristate option
instead of 3 tristates? I think that would be a decent middle ground,
and IIUC, will still provide the coverage Chrome OS is looking for[1].
-Kees
[1] https://lore.kernel.org/lkml/CABi2SkWDwAU2ARyMVTeCqFeOXyQZn3hbkdWv-1OzzgG=MNoU8Q@xxxxxxxxxxxxxx/
--
Kees Cook
