On 2025-02-06 at 00:46:21 +0100, Andrey Konovalov wrote: >On Tue, Feb 4, 2025 at 6:37 PM Maciej Wieczor-Retman ><maciej.wieczor-retman@xxxxxxxxx> wrote: ... >> +choice >> + prompt "KASAN operation mode" >> + default KASAN_OPERATION_DEBUG >> + help >> + Choose between the mitigation or debug operation modes. >> + >> + The first one disables stacktrace saving and enables panic on error. >> + Faster memory allocation but less information. The second one is the >> + default where KASAN operates with full functionality. > >This is something that I thought about before and I think we should >_not_ add configuration options like these. The distinction between >debug and mitigation modes is something that's specific to a >particular user of the feature. Some might prefer to take the impact >of having stack traces enabled in a production environment to allow >debugging in-the-wild exploitation attempts. Also at some point in the >future, we will hopefully have production-grade stack traces [1], and >this would thus change the desired behavior of >KASAN_OPERATION_MITIGATION. > >We already have the kasan.stacktrace command-line parameter for >disabling stack trace collection. On top of that, if you prefer, we >could add a configuration option that changes the default value of >kasan_flag_stacktrace (but can still be overridden via the >kasan.stacktrace command-line parameter). Note though that by default, >stack traces should be turned on. > >[1] https://bugzilla.kernel.org/show_bug.cgi?id=211785 > Okay, I see your point. I'll drop the patch for now and rethink if messing with how stacktraces are enabled/disabled is worth it. > >_______________________________________________ >linux-riscv mailing list >linux-riscv@xxxxxxxxxxxxxxxxxxx >http://lists.infradead.org/mailman/listinfo/linux-riscv -- Kind regards Maciej Wieczór-Retman
