Re: [kernel-hardening] Self Introduction

[Ben Hutchings <ben.hutchings@codethink.co.uk>]

On Wed, 2016-01-13 at 11:31 +0000, Catalin Marinas wrote:
> + rmk (actually cc'ing him this time)
> 
> On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote:
> > On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote:
> > > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote:
> > >
> > >>> I haven't done any further improvements to them, nor have I received any
> > >>> feedback. I'll rebase them against latest kernel if anyone else is
> > >>> willing to test. I had a plan to run some benchmarks and see how
> > >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
> > >>> again for upstreaming but I haven't had the time.
> > >>
> > >>
> > >> David, getting back to something that might good to get your help
> > >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on
> > >> real hardware? (Are you familiar with the LKDTM tests for this[1]?)
> > >
> > >
> > > Sorry for the delay in getting back to you.  Been both moving and
> > > taking vacation.
> > >
> > > I'd like to test this.  I'm just trying to see if I can track down
> > > some hardware that'll boot LPAE.
> > 
> > Awesome! Thanks for the update.
> > 
> > Catalin, did you end up figuring out if your TTBR0 stuff was correct?
> > You'd mentioned you needed to check something about the
> > implementation?
> 
> Unfortunately, I checked with the ARM architecture folk. While the trick
> is probably fine on existing hardware, the architecture allows caching
> of the TTBCR bits (or their effect) in the TLB. Therefore changing the
> TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed
> to have an effect until the TLBs are invalidated. CPU implementations
> are allowed to rely on this, so we can't safely use it in Linux.
[...]

Could you whitelist the cores where this is known to work as intended?
Or is it not practical to enable/disable this PAN implementation at boot
time?

Ben.