[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 22 Oct 2017 15:11:57 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Alexander Popov <alex.popov@...ux.com>
Cc: kernel-hardening@...ts.openwall.com, keescook@...omium.org,
pageexec@...email.hu, spender@...ecurity.net,
Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>,
tycho@...ker.com, Laura Abbott <labbott@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>,
"H . Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH RFC v5 0/5] Introduce the STACKLEAK feature and a test
for it
On Sun, Oct 22, 2017 at 03:22:48AM +0300, Alexander Popov wrote:
> These numbers were obtained for the 4th version of the patch series.
>
> Size of vmlinux (x86_64_defconfig):
> file size:
> - STACKLEAK disabled: 35014784 bytes
> - STACKLEAK enabled: 35044952 bytes (+0.086%)
> .text section size (calculated by size utility):
> - STACKLEAK disabled: 10752983
> - STACKLEAK enabled: 11062221 (+2.876%)
Why no runtime costs? This should not be hard to measure.
> Further work
> =============
>
> - Rewrite erase_kstack() in C (if Ingo Molnar insists).
Aside from legacy, is there any sane reason that stuff is in ASM? That
is, I too will insist it being in C unless you can provide good
arguments on why it needs be asm. All it does is memzero() right? And I
would think architectures already have fairly optimized implementations
of that around.
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.
