On Tue, May 5, 2020 at 5:19 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote: > > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor > > <natechancellor@xxxxxxxxx> wrote: > > > I believe these issues are one in the same. I did a reverse bisect with > > > Arnd's test case and converged on George's first patch: > > > > > > https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a > > > > > > I think that in lieu of this patch, we should have that patch and its > > > follow-up fix merged into 10.0.1. > > > > If this is fixed in 10.0.1, do we even need to patch the kernel at > > all? Or can we just leave it be, considering most organizations using > > clang know what they're getting into? I'd personally prefer the > > latter, so that we don't clutter things. > > I agree: I'd rather this was fixed in 10.0.1 (but if we do want a > kernel-side work-around for 10.0.0, I would suggest doing the version > check in the Kconfig for FORTIFY_SOURCE instead of in the Makefile, > as that's where these things are supposed to live these days). Indeed this belongs in the Makefile. I can send a patch adjusting that, if you want, but I think I'd rather do nothing and have a fix be rolled out in 10.0.1. Clang users should know what to expect in that regard. > (Though as was mentioned, it's likely that FORTIFY_SOURCE isn't working > _at all_ under Clang, so I may still send a patch to depend on !clang > just to avoid surprises until it's fixed, but I haven't had time to > chase down a solution yet.) That might be the most coherent thing to do, at least so that people don't get some false sense of mitigation. Jason