On Fri, Aug 3, 2018 at 11:23 AM, Will Deacon <will.deacon@xxxxxxx> wrote: > On Wed, Aug 01, 2018 at 06:52:09PM +0200, Dmitry Vyukov wrote: >> On Wed, Aug 1, 2018 at 6:35 PM, Will Deacon <will.deacon@xxxxxxx> wrote: >> > Thanks for tracking these cases down and going through each of them. The >> > obvious follow-up question is: how do we ensure that we keep on top of >> > this in mainline? Are you going to repeat your experiment at every kernel >> > release or every -rc or something else? I really can't see how we can >> > maintain this in the long run, especially given that the coverage we have >> > is only dynamic -- do you have an idea of how much coverage you're actually >> > getting for, say, a defconfig+modules build? >> > >> > I'd really like to enable pointer tagging in the kernel, I'm just still >> > failing to see how we can do it in a controlled manner where we can reason >> > about the semantic changes using something other than a best-effort, >> > case-by-case basis which is likely to be fragile and error-prone. >> > Unfortunately, if that's all we have, then this gets relegated to a >> > debug feature, which sort of defeats the point in my opinion. >> >> Well, in some cases there is no other way as resorting to dynamic testing. >> How do we ensure that kernel does not dereference NULL pointers, does >> not access objects after free or out of bounds? Nohow. And, yes, it's >> constant maintenance burden resolved via dynamic testing. > > ... and the advantage of NULL pointer issues is that you're likely to see > them as a synchronous exception at runtime, regardless of architecture and > regardless of Kconfig options. With pointer tagging, that's certainly not > the case, and so I don't think we can just treat issues there like we do for > NULL pointers. Well, let's take use-after-frees, out-of-bounds, info leaks, data races is a good example, deadlocks and just logical bugs... > If you want to enable khwasan in "production" and since enabling it > could potentially change the behaviour of existing code paths, the > run-time validation space doubles as we'd need to get the same code > coverage with and without the feature being enabled. This is true for just any change in configs, sysctls or just a different workload. Any of this can enable new code, exiting code working differently, or just working with data in new states. And we have tens of thousands of bugs, so blindly deploying anything new to production without proper testing is a bad idea. It's not specific to HWASAN in any way. And when you enable HWASAN you actually do mean to retest everything as hard as possible. And in the end we do not seem to have any action points here, right?
