On Thu, Feb 6, 2025 at 8:21 PM 'Christoph Lameter (Ampere)' via kasan-dev <kasan-dev@xxxxxxxxxxxxxxxx> wrote: > > I cannot share details since this information has not been released to be > public yet. I hear that a whitepaper will be coming soon to explain this > feature. The AmpereOne processors have been released a couple of months > ago. > > I also see that KASAN_HW_TAGS exist but this means that the tags can only > be used with CONFIG_KASAN which is a kernel configuration for debug > purposes. > > What we are interested in is a *production* implementation with minimal > software overhead that will be the default on ARM64 if the appropriate > hardware is detected. That in turn will hopefully allow other software > instrumentation that is currently used to keep small objects secure and in > turn creates overhead. Is there anything specific CONFIG_KASAN + CONFIG_KASAN_HW_TAGS do that is not good enough for a production environment? The last time I did some perf tests (a year+ ago on Pixel 8, I believe), the two expensive parts of CONFIG_KASAN_HW_TAGS were: 1. Collecting stack traces. Thus, this can now be disabled via kernel.stacktrace=off. And there's a tracking bug to add a production-grade implementation [1]; 2. Assigning memory tags to large allocations, specifically page_alloc allocations with large orders (AFAIR is was specifically assigning the tags, not checking them). Thus, this can now be controlled via kasan.page_alloc.sample(.order). There's definitely room for optimization and additional config options that cut down KASAN checks (for example, disabling tag checking of mempool allocations; although arguably, people might want to have this in a production environment.) Otherwise, it's unclear to me what a new production-grade MTE implementation would do different compared to KASAN_HW_TAGS. But if there's something, we can just adjust KASAN_HW_TAGS instead. [1] https://bugzilla.kernel.org/show_bug.cgi?id=211785
