On Mon, Jul 11, 2016 at 1:30 AM, Dmitry Vyukov <[email protected]> wrote: > On Sun, Jul 10, 2016 at 2:47 PM, Andy Lutomirski <[email protected]> wrote: >> Hi all- >> >> I found two nasty issues with virtually mapped stacks if KASAN is >> enabled. The first issue is a crash: the first non-init stack is >> allocated and accessed before KASAN initializes its zero shadow >> AFAICT, which means that we switch to that stack and then blow up when >> we start recursively faulting on failed accesses to the shadow. >> >> The second issue is that, even if we survive (we initialize the zero >> shadow on time), KASAN will fail to protect hte stack. >> >> For now, I just disabled use of virtually mapped stacks if KASAN is >> on. Do you have any easy ideas to fix it? > > > Hi Andy, > > What is "virtually mapped stacks"? How are they enabled?
It's a patchset I'm working on, and I'm hoping to get them in to 4.8. They're only supported (so far) on x86, and they're enabled by a config option. The init task has a conventional stack, but all other stacks are vmalloced. > KASAN does not have real shadow for vmalloc range. Fixing this will > probably involve allocating real shadow memory for that range which > will increase memory consumption. > You said that you disabled the virtually mapped stacks, which means > that it is not a critical feature for your environment. When is it > supposed to be used? What are the benefits? For now I am leaning > towards automatically disabling virtually mapped stacks when KASAN is > enabled. That's what I'm doing right now. Enabling virtually mapped stacks gives reliably stack overflow detection and avoids needing higher-order pages. It's certainly not a critical feature, but it's nice, and supporting both it and KASAN at the same time would be nice. --Andy
