[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240731155551.GF33588@noisy.programming.kicks-ass.net>
Date: Wed, 31 Jul 2024 17:55:51 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Guenter Roeck <linux@...ck-us.net>, Jens Axboe <axboe@...nel.dk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Peter Anvin <hpa@...or.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>
Subject: Re: Linux 6.11-rc1
On Wed, Jul 31, 2024 at 03:03:33PM +0200, Thomas Gleixner wrote:
> On Wed, Jul 31 2024 at 14:20, Peter Zijlstra wrote:
> > On Tue, Jul 30, 2024 at 01:24:34PM -0700, Guenter Roeck wrote:
> >> An interesting bit of information: The problem is seen with many,
> >> but not all CPUs. For example, I don't see it with athlon, n270, Dhyana,
> >> or EPYC. qemu32 is affected, but qemu64 is fine. But on the other side
> >> both kvm32 and kvm64 are affected.
> >
> > pti=off makes it go away, could be those CPU models don't have meltdown
> > and as such don't enable PTI.
>
> The AMD ones don't have meltdown and neither does n270 which is an
> in-order atom.
Right, so Thomas found that i386-pti fails to map the entire entry text.
Specifically pti_clone_pgtable() hard relies -- and does not verify --
that the start address is aligned to the given granularity.
Now, i386 does not align __entry_text_start, and so the termination
condition goes sideways and pte_clone_entry() does not always work right
and it becomes a games of code layout roulette.
Still trying to figure out what the right fix is. I've tried page
aligning the section and using PTE cloning, and that works -- mostly. If
you hit a source PMD the clone logic still does a PMD level clone and
that might not be what we want, see the alignment thing again.
Also, should we just kill PTI on 32bit perhaps?
Powered by blists - more mailing lists