Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
On 2017-05-08 00:02, Richard Weinberger wrote: Ahh, *very* recent is the keyword then. ;) I was a bit confused since in your paper the overhead is less than 1%. Yes, only for very recent platforms (Skylake). While working on the paper we were surprised that we found overheads that small. What platforms did you test? We tested it on multiple platforms for stability, but we only ran longer performance tests on different Skylake i7-6700K systems we mentioned in the paper. i.e. how does it perform on recent AMD systems? Unfortunately, we don't have any AMD systems at hand. I'm also not sure how AMD is affected by the issue in the first place. Although unlikely, there is the possibility that the problem of KASLR information leakage through microarchitectural side channels might be Intel-specific.
Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Daniel, On Fri, May 5, 2017 at 9:40 AM, Daniel Gruss wrote: > I'm sure the overhead on older systems is larger than on recent systems. Just did a quick test on my main KVM host, a 8 core Intel(R) Xeon(R) CPU E3-1240 V2. KVM guests are 4.10 w/o CONFIG_KAISER and kvmconfig without CONFIG_PARAVIRT. Building a defconfig kernel within that guests is about 10% slower when CONFIG_KAISER is enabled. Is this expected? If it helps I can redo the same test also on bare metal. -- Thanks, //richard
Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Daniel, Am 07.05.2017 um 23:45 schrieb Daniel Gruss: >> Just did a quick test on my main KVM host, a 8 core Intel(R) Xeon(R) >> CPU E3-1240 V2. >> KVM guests are 4.10 w/o CONFIG_KAISER and kvmconfig without CONFIG_PARAVIRT. >> Building a defconfig kernel within that guests is about 10% slower >> when CONFIG_KAISER >> is enabled. > > Thank you for testing it! :) > >> Is this expected? > > It sounds plausible. First, I would expect any form of virtualization to > increase the overhead. Second, for the processor (Ivy Bridge), I would have > expected even higher > performance overheads. KAISER utilizes very recent performance improvements > in Intel processors... Ahh, *very* recent is the keyword then. ;) I was a bit confused since in your paper the overhead is less than 1%. What platforms did you test? i.e. how does it perform on recent AMD systems? Thanks, //richard
Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Just did a quick test on my main KVM host, a 8 core Intel(R) Xeon(R) CPU E3-1240 V2. KVM guests are 4.10 w/o CONFIG_KAISER and kvmconfig without CONFIG_PARAVIRT. Building a defconfig kernel within that guests is about 10% slower when CONFIG_KAISER is enabled. Thank you for testing it! :) Is this expected? It sounds plausible. First, I would expect any form of virtualization to increase the overhead. Second, for the processor (Ivy Bridge), I would have expected even higher performance overheads. KAISER utilizes very recent performance improvements in Intel processors... If it helps I can redo the same test also on bare metal. I'm not sure how we proceed here and if this would help, because I don't know what everyone expects. KAISER definitely introduces an overhead, no doubt about that. How much overhead it is depends on the specific hardware and may be very little on recent architectures and more on older machines. We are not proposing to enable KAISER by default, but to provide the config option to allow easy integration into hardened kernels where performance overheads may be acceptable (which depends on the specific use case and the specific hardware).
