Messages in this thread | | | From | Marco Elver <> | Date | Fri, 16 Oct 2020 15:31:28 +0200 | Subject | Re: [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64 |
| |
On Fri, 16 Oct 2020 at 15:17, 'Andrey Konovalov' via kasan-dev <kasan-dev@googlegroups.com> wrote: [...] > > > The intention with this kind of a high level switch is to hide the > > > implementation details. Arguably, we could add multiple switches that allow > > > to separately control each KASAN or MTE feature, but I'm not sure there's > > > much value in that. > > > > > > Does this make sense? Any preference regarding the name of the parameter > > > and its values? > > > > KASAN itself used to be a debugging tool only. So introducing an "on" > > mode which no longer follows this convention may be confusing. > > Yeah, perhaps "on" is not the best name here. > > > Instead, maybe the following might be less confusing: > > > > "full" - current "debug", normal KASAN, all debugging help available. > > "opt" - current "on", optimized mode for production. > > How about "prod" here?
SGTM.
[...] > > > > Should we somehow control whether to panic the kernel on a tag fault? > > > Another boot time parameter perhaps? > > > > It already respects panic_on_warn, correct? > > Yes, but Android is unlikely to enable panic_on_warn as they have > warnings happening all over. AFAIR Pixel 3/4 kernels actually have a > custom patch that enables kernel panic for KASAN crashes specifically > (even though they don't obviously use KASAN in production), and I > think it's better to provide a similar facility upstream. Maybe call > it panic_on_kasan or something?
Best would be if kasan= can take another option, e.g. "kasan=prod,panic". I think you can change the strcmp() to a str_has_prefix() for the checks for full/prod/on/off, and then check if what comes after it is ",panic".
Thanks, -- Marco
| |