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;
Subject: Re: [RFC][PATCH 00/24] x86/pti: Defer CR3 switch to C code
To:     Dave Hansen <dave.hansen@intel.com>, tglx@linutronix.de,
        mingo@redhat.com, bp@alien8.de, 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
Cc:     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
References: <20201109144425.270789-1-alexandre.chartre@oracle.com>
 <8d9b6f38-5d98-dc91-cecc-36c7ab829c96@intel.com>
From:   Alexandre Chartre <alexandre.chartre@oracle.com>
Message-ID: <d816313f-38f8-bcf0-3411-cdcbe0457d8b@oracle.com>
Date:   Mon, 9 Nov 2020 20:53:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <8d9b6f38-5d98-dc91-cecc-36c7ab829c96@intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 11/9/20 8:35 PM, Dave Hansen wrote:
> On 11/9/20 6:44 AM, Alexandre Chartre wrote:
>>   - map more syscall, interrupt and exception entry code into the user
>>     page-table (map all noinstr code);
> 
> This seems like the thing we'd want to tag explicitly rather than make
> it implicit with 'noinstr' code.  Worst-case, shouldn't this be:
> 
> #define __entry_func	noinstr
> 
> or something?

Yes. I use the easy solution to just use noinstr because noinstr is mostly
use for entry functions. But if we want to use the user page-table beyond
the entry functions then we will definitively need a dedicated tag.

> I'd also like to see a lot more discussion about what the rules are for
> the C code and the compiler.  We can't, for instance, do a normal
> printk() in this entry functions.  Should we stick them in a special
> section and have objtool look for suspect patterns or references?
> 
> I'm most worried about things like this:
> 
> 	if (something_weird)
> 		pr_warn("this will oops the kernel\n");

That would be similar to noinstr which uses the .noinstr.text section, and if
I remember correctly objtool detects if a noinstr function calls a non-noinst.
Similarly here, an entry function should not call a non-entry function.

alex.