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 v4][PATCH part-1 0/7] ASI - Part I (ASI Infrastructure and
 PTI)
To:     Dave Hansen <dave.hansen@intel.com>, tglx@linutronix.de,
        mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
        dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org,
        x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc:     pbonzini@redhat.com, konrad.wilk@oracle.com,
        jan.setjeeilers@oracle.com, liran.alon@oracle.com,
        junaids@google.com, graf@amazon.de, rppt@linux.vnet.ibm.com,
        kuzuno@gmail.com, mgross@linux.intel.com
References: <20200504144939.11318-1-alexandre.chartre@oracle.com>
 <a65d6cbf-41de-3001-6792-21a4233d8467@intel.com>
From:   Alexandre Chartre <alexandre.chartre@oracle.com>
Message-ID: <bdfe70f7-2c61-092a-86d0-a7c71e6a3a8d@oracle.com>
Date:   Tue, 12 May 2020 21:25:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <a65d6cbf-41de-3001-6792-21a4233d8467@intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Hi Dave,

On 5/12/20 7:45 PM, Dave Hansen wrote:
> On 5/4/20 7:49 AM, Alexandre Chartre wrote:
>> This version 4 of the kernel Address Space Isolation (ASI) RFC. I have
>> broken it down into three distinct parts:
>>
>>   - Part I: ASI Infrastructure and PTI (this part)
>>   - Part II: Decorated Page-Table
>>   - Part III: ASI Test Driver and CLI
>>
>> Part I is similar to RFCv3 [3] with some small bug fixes. Parts II and III
>> extend the initial patchset: part II introduces decorated page-table in
>> order to provide convenient page-table management functions, and part III
>> provides a driver and CLI for testing ASI (using parts I and II).
> 
> These look interesting.  I haven't found any holes in your methods,
> although the interrupt depth tracking worries me a bit.  I tried and
> failed to do a similar thing with PTI in the NMI path, but you might
> have just bested me there. :)

Thanks for taking a look. I am glad it seems okay, I have run several tests
and was unable to have it fail (so far) while previous versions were easily
breakable.

> It's very interesting that you've been able to implement PTI underneath
> all of this, and the "test driver" is really entertaining!

Yeah, this a kind of PTI on steroid as part of the implementation was done
based on the PTI implementation but making it more generic. The test driver
has proven very useful for testing and debugging. I am currently using it
(with some extensions) for helping me define the KVM ASI: I can connect the
driver to a KVM ASI, dump the KVM ASI faults and dynamically add mappings;
this is very handy.

> That said, this is working in some of the nastiest corners of the x86
> code and this is going to take quite an investment to get reviewed.  I'm
> not *quite* sure it's all worth it.

I am also concerned about making changes in all these nasty corners. I am a
bit more confident now that it is working to implement PTI because PTI provides
a good stress test for ASI. I am also waiting for (and reviewing) all x86/entry
changes from tglx; this greatly cleans up the entry code and will hopefully help
for the integration of ASI. I will rebase as soon as these all changes are
integrated and check the benefit for ASI.

> So, this isn't being ignored, I'm just not quite sure what to do with
> it, yet.
> 

I am working on defining ASI for KVM. Hopefully this will provide a good
usage example, and make the changes more compelling.

Thanks.

alex.