Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Alexandre Chartre <alexandre.chartre@oracle.com>,
        Borislav Petkov <bp@alien8.de>
Cc:     mingo@redhat.com, hpa@zytor.com, x86@kernel.org,
        dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org,
        linux-kernel@vger.kernel.org, thomas.lendacky@amd.com,
        jroedel@suse.de, konrad.wilk@oracle.com,
        jan.setjeeilers@oracle.com, junaids@google.com, oweisse@google.com,
        rppt@linux.vnet.ibm.com, graf@amazon.de, mgross@linux.intel.com,
        kuzuno@gmail.com
Subject: Re: [RFC][PATCH v2 00/21] x86/pti: Defer CR3 switch to C code
In-Reply-To: <692599af-53c8-7881-2bc7-8898085400cd@oracle.com>
References: <20201116144757.1920077-1-alexandre.chartre@oracle.com> <20201116202426.GF1131@zn.tnic> <692599af-53c8-7881-2bc7-8898085400cd@oracle.com>
Date:   Thu, 19 Nov 2020 20:32:42 +0100
Message-ID: <87a6vdp2g5.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Tue, Nov 17 2020 at 09:19, Alexandre Chartre wrote:
> On 11/16/20 9:24 PM, Borislav Petkov wrote:
>> On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
>> So PTI was added exactly to *not* have kernel memory mapped in the user
>> page table. You're partially reversing that...
>
> We are not reversing PTI, we are extending it.

You widen the exposure surface without providing an argument why it is safe.

> PTI removes all kernel mapping from the user page-table. However there's
> no issue with mapping some kernel data into the user page-table as long as
> these data have no sensitive information.

Define sensitive information. 

> Actually, PTI is already doing that but with a very limited scope. PTI adds
> into the user page-table some kernel mappings which are needed for userland
> to enter the kernel (such as the kernel entry text, the ESPFIX, the
> CPU_ENTRY_AREA_BASE...).
>
> So here, we are extending the PTI mapping so that we can execute more kernel
> code while using the user page-table; it's a kind of PTI on steroids.

Let's just look at a syscall:

noinstr long syscall_enter_from_user_mode(struct pt_regs *regs, long syscall)
{
	long ret;

	enter_from_user_mode(regs);
          lockdep_hardirqs_off();
          user_exit_irqoff();
          trace_hardirqs_off_finish();

So just looking at the 3 calls above, how are you going to guarantee
that everything these callchains touch is mapped into user space?

Not to talk about everything which comes after that.

Thanks,

        tglx