tree 38a33897b22a19017b34d9e2cb3731c89cc01317
parent a2a9e34d164e90fc08d35fd097a164b9101d72ef
author Andrey Konovalov <andreyknvl@google.com> 1673399986 +0100
committer Treehugger Robot <treehugger-gerrit@google.com> 1673641670 +0000

ANDROID: gki_defconfig: sample large page_alloc allocations with HW_TAGS KASAN

Add kasan.page_alloc.sample=10 to CONFIG_CMDLINE in gki_defconfig to make
Hardware Tag-Based (MTE) KASAN tag only one out of every 10 page_alloc
allocations with the order equal or larger than 3, which the omitted
default value for the kasan.page_alloc.sample.order parameter.

As Hardware Tag-Based KASAN is intended to be used in production, its
performance impact is crucial. As page_alloc allocations tend to be big,
tagging and checking all such allocations can introduce a significant
slowdown.

When running a local loopback test on a testing MTE-enabled device in sync
mode, enabling Hardware Tag-Based KASAN introduces a ~50% slowdown.
Setting kasan.page_alloc.sampling to a value higher than 1 allows to lower
the slowdown. The performance improvement saturates around the sampling
interval value of 10 with the default sampling page order of 3, see
b/238286329. This lowers the slowdown to ~20%.  The slowdown in real
scenarios involving the network will likely be better.

Enabling page_alloc sampling has a downside: KASAN misses bad accesses to
a page_alloc allocation that has not been tagged. This lowers the value
of KASAN as a security mitigation.

However, based on measuring the number of page_alloc allocations of
different orders during boot in a test build, sampling with the default
kasan.page_alloc.sample.order value affects only ~7% of allocations. The
rest ~93% of allocations are still checked deterministically.

Bug: 238286329
Bug: 264310057
Change-Id: Idfc8600d1f7cc7af28482ff2c8e8ad5ad5948058
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>