On Fri, Oct 16, 2020 at 3:31 PM Marco Elver <elver@xxxxxxxxxx> wrote: > > On Fri, 16 Oct 2020 at 15:17, 'Andrey Konovalov' via kasan-dev > <kasan-dev@xxxxxxxxxxxxxxxx> 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 CC Kostya and Serban.
