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:     Don Porter <porter@cs.unc.edu>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc:     Andi Kleen <ak@linux.intel.com>, Sasha Levin <sashal@kernel.org>,
        linux-kernel@vger.kernel.org, bp@alien8.de, luto@kernel.org,
        hpa@zytor.com, dave.hansen@intel.com, tony.luck@intel.com,
        ravi.v.shankar@intel.com, chang.seok.bae@intel.com
Subject: Re: [PATCH v12 00/18] Enable FSGSBASE instructions
In-Reply-To: <c5fffcd1-c262-7046-a047-67de2bbccd78@cs.unc.edu>
References: <20200511045311.4785-1-sashal@kernel.org> <0186c22a8a6be1516df0703c421faaa581041774.camel@linux.intel.com> <20200515164013.GF29995@sasha-vm> <c566b89cc3ef6c164160cc56a820abac3fd70839.camel@linux.intel.com> <20200518153407.GA499505@tassilo.jf.intel.com> <371e6a92cad25cbe7a8489785efa7d3457ecef3b.camel@linux.intel.com> <87v9ksvoaq.fsf@nanos.tec.linutronix.de> <20200519164853.GA19706@linux.intel.com> <7eb45e02-03bf-0af0-c915-794bf49d66d7@cs.unc.edu> <87h7w7qy18.fsf@nanos.tec.linutronix.de> <c5fffcd1-c262-7046-a047-67de2bbccd78@cs.unc.edu>
Date:   Thu, 28 May 2020 12:29:13 +0200
Message-ID: <87d06opd3a.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Don,

Don Porter <porter@cs.unc.edu> writes:
> On 5/22/20 8:45 PM, Thomas Gleixner wrote:
> The threat model for Graphene, and most SGX papers, is quite explicit: 
> we assume that Intel’s CPU package, the software in the enclave, and 
> possibly Intel’s Attestation Service (IAS) are the only trusted 
> components.  Any other software should be assumed compromised, and one 
> can even assume memory is physically tampered or that one has plugged in 
> an adversarial device. It is not a question of the limitations of the 
> kernel, the threat model assumes that the kernel is already rooted.

I'm well aware about that model and that the research is focussed on
this.

> For the community these papers are typically written to, this assumption 
> would be well understood.  And thus it is common to see code artifacts 
> that might emulate or even undermine security of untrusted
> components.

No disagreement here.

> Not appropriate for production use, but for the typical audience, this 
> risk would be understood.  And, initially, when people started using 
> Graphene, I checked who they were - almost exclusively SGX researchers 
> who would have this context.  It has only been recently that the 
> interest has grown to a level that these sorts of warnings need to be 
> revised for a more general audience.  But the point that we should 
> revise our readme and warnings for a more general audience is well
> taken.

The problem is that this has spread out. And it's not only Graphene.

As at least two different incarnations originate from Intel written by
two different Intel people, it's really on Intel to get the message out
that enabling FSGSBASE behind the kernels back is a horrible idea.

>> It's beyond hillarious that the renewed attempt to get FSGSBASE support
>> merged does not come from the company which has the main interest to get
>> this solved, i.e Intel.
>
> Yes!  I think we are in agreement that we expected Intel to upstream 
> this support - it is their product. I don’t see why I am personally 
> responsible to come to the aid of a multi-billion dollar corporation in 
> my free time, or that it is wrong to at least let them try first and see 
> how far they get.

You surely are not responsible. It's definitely Intel's fault.

> Until recently, we were doing proof-of-concept research, not product 
> development, and there are limited hours in the day.  I also hasten to 
> say that the product of research is an article, the software artifact 
> serves as documentation of the experiment.  In contrast, the product of 
> software development is software.  It takes significant time and effort 
> to convert one to the other.  Upstreaming code is of little scientific 
> interest.  But things have changed for our project; we had no users in 
> 2015 and we are now un-cutting corners that are appropriate for research 
> but inappropriate for production.  For a research artifact with an 
> audience that knew the risks, we shipped a module because it was easier 
> to maintain and install than a kernel patch.

I understand that and with a big fat warning and documentation from
start I wouldn't have complained so vehemently. 

> Also, there is a chicken-and-egg problem here: AFAIU a kernel patch 
> needs a userspace demonstration to motivate merging.  We can’t do a 
> userspace demonstration without this feature.  My main interest in 
> showing up for this discussion was to try to make the case that, 
> compared to 2015, there is a more convincing userspace demonstration and 
> larger population of interested users.

As one of the X86 maintainers I have to say that we were perfectly
willing to merge FSGSBASE even without the SGX background. There are
perfect other reasons to do so.

> As far as the patch and pull request, I personally think the right thing 
> to do is add the warnings you suggest, help test this or another kernel 
> patch, and advise users that patching their kernel is more secure than 
> this module.  I am not in favor of fully deleting the module, in the 
> interest of transparency and reproducibility.

Fair enough.

> Finally, I must rebut the claim that my research abuses public funds to 
> advertise for Intel.  I have been working on this problem since before I 
> knew SGX existed, and have been completely transparent regarding 
> subsequent collaborations with Intel.  I believe that understanding the 
> pros and cons of different techniques to harden an application against a 
> compromised kernel is in the public interest, and my research projects 
> have been reviewed and overseen according to standard practices at both 
> the university and US government funding agencies.  The expectations of 
> agencies in the US funding research are the paper, the insights, and 
> proof-of-concept software; converting proof-of-concept software into 
> production quality is generally considered a “nice to have”.

Sorry for that innuendo. Now that my anger and general frustration about
this whole disaster have calmed down, I surely would not write that
again.

Thanks,

        Thomas