On Mon, May 31, 2021 at 6:59 PM Kuan-Ying Lee <kylee0686026@xxxxxxxxx> wrote: > > > > > > > +config KASAN_HW_TAGS_IDENTIFY > > > + bool "Enable memory corruption identification" > > > + depends on KASAN_HW_TAGS > > > + help > > > + This option enables best-effort identification of bug type > > > + (use-after-free or out-of-bounds) at the cost of increased > > > + memory consumption. > > > > Can we rename KASAN_SW_TAGS_IDENTIFY -> KASAN_TAGS_IDENTIFY in a > > separate patch and then use that? > > > > Or do we have a problem renaming this options if there are existing > > users of it? Using the single KASAN_TAGS_IDENTIFY config option is what I would like to see. Since this is a purely debugging feature for a less popular KASAN mode, I think renaming the config name is OK. > I tend to keep KASAN_SW_TAGS_IDENTIFY and KASAN_HW_TAGS_IDENTIFY > separately. > > We need these two configs to decide how many stacks we will store. You can define KASAN_NR_FREE_STACKS to different values depending on whether HW_TAGS or SW_TAGS is in use. I don't see a problem here. > If we store as many stacks as SW tag-based kasan does(5 stacks), we might > mistake out-of-bound issues for use-after-free sometime. Becuase HW > tag-based kasan only has 16 kinds of tags. When Out-of-bound issues happened, it might > find the same tag in the stack we just stored and mistake happened. > There is high probability that this mistake will happen.
