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;
Date:   Tue, 26 May 2020 16:27:39 -0400
From:   Sasha Levin <sashal@kernel.org>
To:     Don Porter <porter@cs.unc.edu>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        Andi Kleen <ak@linux.intel.com>, 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
Message-ID: <20200526202739.GG33628@sasha-vm>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c5fffcd1-c262-7046-a047-67de2bbccd78@cs.unc.edu>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, May 26, 2020 at 08:42:09AM -0400, Don Porter wrote:
>On 5/22/20 8:45 PM, Thomas Gleixner wrote:
>>let me clarify, that despite your intentions:
>>
>>     - there is not a single word in any paper, slide deck, documentation
>>       etc. which mentions that loading this module and enabling FSGSBASE
>>       behind the kernels back is a fully unpriviledged root hole.
>>
>>     - the module lacks a big fat warning emitted to dmesg, that this
>>       turns the host kernel into a complete security disaster.
>>
>>     - the module fails to set the TAINT_CRAP flag when initialized.
>>
>>This shows a pretty obvious discrepancy between intention and action.
>
>I think there is a significant misunderstanding here.  This line of 
>research assumes the kernel is already compromised and behaving 
>adversarially toward a more trusted application.  Thus, the attack 
>surface under scrutiny in these projects is between the enclave and 
>the rest of the system.  Not that we want kernels to be rooted, or 
>make this easier, but exploits happen in practice.
>
>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.

You really have to look beyond just what Graphene guarantees at this
point; it does not live on it's own island and it's success isn't
measured purely based on how well it handles it's threat model.

Yes, the threat model assumes the kernel was rooted, but you don't go
off and set the root password to '12345678' on those machines, right?
Attackers would be more than happy to run botnets, spam mailers, and
host child porn on your servers if you give them the opportunity, let's
not do that.

>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. 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.

I'm really worried about the disconnect between how you view the current
state of Graphene (and the industry) vs Intel and the various cloud
providers.

You keep suggesting that its just past the academic research state,
while Intel and the big cloud providers are already pushing it to
external customers.  Every one of those cloud providers has a preview/GA
secure enclave offering.

-- 
Thanks,
Sasha