On 08/02/2018 04:52 PM, Catalin Marinas wrote: > >> If somebody has a practical idea how to detect these statically, let's >> do it. Otherwise let's go with the traditional solution to this -- >> dynamic testing. The patch series show that the problem is not a >> disaster and we won't need to change just every line of kernel code. > > It's indeed not a disaster but we had to do this exercise to find out > whether there are better ways of detecting where untagging is necessary. > > 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. I wouldn't say it's > a blocker for khwasan, more like something to be aware of. > > The awareness is a bit of a problem as the normal programmer would have > to pay more attention to conversions between pointer and long. Given > that this is an arm64-only feature, we have a risk of khwasan-triggered > bugs being introduced in generic code in the future (hence the > suggestion of some static checker, if possible). I don't see how we can implement such checker. There is no simple rule which defines when we need to remove the tag and when we can leave it in place. The cast to long have nothing to do with the need to remove the tag. If pointers compared for sorting objects, or lock ordering, than having tags is fine and it doesn't matter whether pointers compared as 'unsigned long' or as 'void *'. If developer needs to check whether the pointer is in linear mapping, than tag has to be removed. But again, it doesn't matter if pointer is 'unsigned long' or 'void *'. Either way, the tag has to go away.
