From mboxrd@z Thu Jan 1 00:00:00 1970 From: tycho@tycho.ws (Tycho Andersen) Date: Wed, 14 Feb 2018 15:13:28 -0700 Subject: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) In-Reply-To: References: <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> Message-ID: <20180214221328.glbrdib3wumve53z@cisco> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Wed, Feb 14, 2018 at 11:48:38AM -0800, Kees Cook wrote: > On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > > 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? Tycho -- 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