On Wed, Mar 1, 2023 at 6:00 PM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > Yes. I'm including Vincenzo's patch below (part of fixing some potential > strscpy() faults with its unaligned accesses eager reading; we'll get to > posting that eventually). You can add some arch_kasan_enable/disable() > macros on top and feel free to include the patch below. Ah, perfect! I'll send a patchset soon. Thanks! > Now, I wonder whether we should link those into kasan_disable_current(). > These functions only deal with the depth for KASAN_SW_TAGS but it would > make sense for KASAN_HW_TAGS to enable tag-check-override so that we > don't need to bother with a match-all tags on pointer dereferencing. Using these TCO routines requires having (at least) migration disabled, right? It's not a problem for KASAN reporting code, as it already disables preemption anyway. The question is with the other kasan_disable/enable_current() call sites. But as within all of them, the code does either a single access or a memcpy or something similar, I think we can disable preemption for that duration. On a related note, I recalled that we also have a bug about using supporting no_sanitize_address for HW_TAGS KASAN. And Peter suggested using TCO entry/exit instrumentation to resolve it [2]. However, we will also need to disable preemption for the duration of no_sanitize_address-annotated functions, and I'm not sure if it's a good idea to do that via compiler instrumentation. Any thoughts? In the mean time, I'll send a simpler patchset without converting all kasan_disable/enable_current(). [1] https://bugzilla.kernel.org/show_bug.cgi?id=212513 [2] https://bugzilla.kernel.org/show_bug.cgi?id=212513#c2
