[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4ec7b323-1de5-0de0-d196-4cb7f2d09ef4@linux.com>
Date: Sun, 22 Oct 2017 00:56:44 +0300
From: Alexander Popov <alex.popov@...ux.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Laura Abbott <labbott@...hat.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Kees Cook <keescook@...omium.org>, PaX Team <pageexec@...email.hu>,
Brad Spengler <spender@...ecurity.net>, Tycho Andersen <tycho@...ker.com>,
Mark Rutland <mark.rutland@....com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>, X86 ML <x86@...nel.org>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH RFC v4 0/3] Introduce the STACKLEAK feature and a test for
it
On 13.10.2017 20:26, Andy Lutomirski wrote:
> On Wed, Oct 11, 2017 at 9:29 AM, Alexander Popov <alex.popov@...ux.com> wrote:
>> On 11.10.2017 05:31, Andy Lutomirski wrote:
>>> On Oct 10, 2017, at 6:19 PM, Laura Abbott <labbott@...hat.com> wrote:
>>>> I tried this series with CVE-2017-14954 . That particular bug
>>>> is not helped here because the poisoning has already been
>>>> overwritten by other leaf functions. Given the call stack this
>>>> may be a particularly bad case but I'm wondering how common
>>>> this might be if we're only erasing at the end of a system
>>>> call. One previous copy_to_user which has to go through the
>>>> fault path can get fairly deep.
>>
>> Laura, thanks for your observation. I've tested Brad's PoC with STACKLEAK too
>> and see similar results. There is only one STACKLEAK_POISON value in the leaked
>> data. Other leaked data is put on the stack by the current syscall.
>>
>> I don't know any statistics on infoleaks and I can't say how many of them would
>> be neutralized by STACKLEAK. But, anyway, it is be better than nothing for those
>> who accept the STACKLEAK performance penalty.
>>
>>> On x86, the bad guys can force this is using 32-bit fast syscalls for *any*
>>> syscall. I suppose we could wipe the stack on the way out of exception
>>> handlers, too...
>>
>> Andy, excuse me, could you elaborate on that? Do you mean that there are some
>> more cases when erase_kstack() should be called?
>
> Kinda. I was thinking that certain exception handlers should erase
> their portion of the stack (i.e. from their entry frame to the bottom)
> when they return back to *kernel* mode.
Andy, if we return to the kernel mode, which profit would we make out of
cleaning exception stacks?
I've spent some time learning arch/x86/entry/. But, honestly, I need help with
checking that erase_kstack() is called at the right places.
Anyway, I'll shortly send the 5-th version of the STACKLEAK patch series. And
I'll include your idea into the "further work" section in the cover letter.
Thank you.
Best regards,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
