Thread (44 messages) 44 messages, 11 authors, 2018-02-21

arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

From: Kees Cook <hidden>
Date: 2018-02-14 22:27:47
Also in: linux-arm-kernel, linux-mm, lkml

On Wed, Feb 14, 2018 at 2:13 PM, Tycho Andersen [off-list ref] wrote:
On Wed, Feb 14, 2018 at 11:48:38AM -0800, Kees Cook wrote:
quoted
On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott [off-list ref] wrote:
quoted
fixed. Modules yes are not fully protected. The conclusion from past
experience has been that we cannot safely break down larger page sizes
at runtime like x86 does. We could theoretically
add support for fixing up the alias if PAGE_POISONING is enabled but
I don't know who would actually use that in production. Performance
is very poor at that point.
XPFO forces 4K pages on the physmap[1] for similar reasons. I have no
doubt about performance changes, but I'd be curious to see real
numbers. Did anyone do benchmarks on just the huge/4K change? (Without
also the XPFO overhead?)

If this, XPFO, and PAGE_POISONING all need it, I think we have to
start a closer investigation. :)
I haven't but it shouldn't be too hard. What benchmarks are you
thinking?
Unless I'm looking at some specific micro benchmark, I tend to default
to looking at kernel build benchmarks but that gets pretty noisy.
Laura regularly uses hackbench, IIRC. I'm not finding the pastebin I
had for that, though.

I wonder if we need a benchmark subdirectory in tools/testing/, so we
could collect some of these common tools? All benchmarks are terrible,
but at least we'd have the same terrible benchmarks. :)

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help