On Tue, Nov 28, 2017 at 10:37:48PM +0200, Jarkko Sakkinen wrote:
> On Mon, Nov 27, 2017 at 09:03:39AM -0800, Sean Christopherson wrote:
> > I have a branch based on Jarkko's patches (I believe it's up-to-date with
> > v5)
> > that implements what I described. I'd be happy to send RFC patches if t
On Mon, Nov 27, 2017 at 09:03:39AM -0800, Sean Christopherson wrote:
> I have a branch based on Jarkko's patches (I believe it's up-to-date with v5)
> that implements what I described. I'd be happy to send RFC patches if that
> would help.
That would only slow things down. The code is easy to mov
+ Cc: KVM, Paolo and Radim
On Mon, 2017-11-27 at 09:03 -0800, Sean Christopherson wrote:
> On Tue, 2017-11-21 at 01:08 +0200, Jarkko Sakkinen wrote:
> >
> > On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote:
> > >
> > >
> > > This is architecural. From the cursory read of that ser
On Tue, 2017-11-21 at 01:08 +0200, Jarkko Sakkinen wrote:
> On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote:
> >
> > This is architecural. From the cursory read of that series it seems there
> > are two parts to it:
> >
> > 1) The actual core handling, which should be in arch/x8
On Fri, Nov 17, 2017 at 01:43:10PM -0800, Darren Hart wrote:
> This series will need to be updated per the comments received so far, as
> well as with commit messages and a complete Cc list *per patch* giving
> all required parties an opportunity to review.
>
> With respect to the obvious security
On 2017-11-22 03:00, Borislav Petkov wrote:
... and we're back full circle to my initial objection: firmware should
not be doing anything here. The user should.
Sure, and I agree. However, there is a difference between what it should
be doing and what hardware/firmware that you can buy today *
On Tue, Nov 21, 2017 at 04:27:45PM -0800, Jethro Beekman wrote:
> See http://www.spinics.net/lists/platform-driver-x86/msg13829.html under
> "Launch control". Essentially, firmware can make it so that user has no
> control over IA32_SGXLEPUBKEYHASHn value.
... and we're back full circle to my init
On 2017-11-21 16:10, Borislav Petkov wrote:
On Tue, Nov 21, 2017 at 03:45:31PM -0800, Jethro Beekman wrote:
Boris & Peter: this key has nothing to do with "trust" or "security".
But with what? Why is the firmware at all involved then?
See http://www.spinics.net/lists/platform-driver-x86/msg1
On Tue, Nov 21, 2017 at 03:45:31PM -0800, Jethro Beekman wrote:
> Boris & Peter: this key has nothing to do with "trust" or "security".
But with what? Why is the firmware at all involved then?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On 2017-11-21 04:47, Borislav Petkov wrote:
On Tue, Nov 21, 2017 at 02:38:54PM +0200, Jarkko Sakkinen wrote:
Try to start LE. If it doesn't start i.e. is signed with a different
root key than the one inside MSRs, then fail the initialization.
But what if the one inside the MSRs is from t
On Tue, Nov 21, 2017 at 02:38:54PM +0200, Jarkko Sakkinen wrote:
> Try to start LE. If it doesn't start i.e. is signed with a different
> root key than the one inside MSRs, then fail the initialization.
But what if the one inside the MSRs is from the fw vendor and I don't
trust it?
--
Regard
On Tue, Nov 21, 2017 at 12:46:23AM +0200, Jarkko Sakkinen wrote:
> On Wed, Nov 15, 2017 at 12:54:12PM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 14, 2017 at 10:49:48PM +0200, Jarkko Sakkinen wrote:
> > > In these cases IA32_FEATURE_CONTROL[17] would be zeroed before locking
> > > the feature cont
On Tue, Nov 21, 2017 at 01:41:45AM +0200, Jarkko Sakkinen wrote:
> In potential deployments of SGX, the owner could do this either in the
> firmware level or OS level depending whether the MSRs are configured as
> writable in the feature control.
>
> One option would be to have a config flag to de
On Mon, Nov 20, 2017 at 11:42:56PM +0100, Borislav Petkov wrote:
> On Tue, Nov 21, 2017 at 12:37:41AM +0200, Jarkko Sakkinen wrote:
> > Firmware cannot access the memory inside an enclave. CPU asserts every
> > memory access coming outside the enclave.
>
> But "firmware could potentially configure
On Fri, Nov 17, 2017 at 03:46:45PM -0800, Darren Hart wrote:
> On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote:
> > On Fri, 17 Nov 2017, Darren Hart wrote:
> >
> > @intel: I removed intel-sgx-kernel-...@lists.01.org from CC because I can
> > do without the silly moderation spam of
On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote:
> This is architecural. From the cursory read of that series it seems there
> are two parts to it:
>
> 1) The actual core handling, which should be in arch/x86 because that
> hardly qualifies as a 'platform' device driver.
>
On Wed, Nov 15, 2017 at 12:54:12PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 10:49:48PM +0200, Jarkko Sakkinen wrote:
> > In these cases IA32_FEATURE_CONTROL[17] would be zeroed before locking
> > the feature control, which would mean that the kernel could not write
> > new values with
On Tue, Nov 21, 2017 at 12:37:41AM +0200, Jarkko Sakkinen wrote:
> Firmware cannot access the memory inside an enclave. CPU asserts every
> memory access coming outside the enclave.
But "firmware could potentially configure the root key hash for the
enclave." How about the owner configures the roo
On Tue, Nov 14, 2017 at 10:53:27PM +0100, Borislav Petkov wrote:
> On Tue, Nov 14, 2017 at 10:49:48PM +0200, Jarkko Sakkinen wrote:
> > Pre-boot firmware could potentially configure the root key hash for the
> > enclave that signs launch tokens for other enclaves i.e. the launch
> > enclave that is
On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote:
> On Fri, 17 Nov 2017, Darren Hart wrote:
>
> @intel: I removed intel-sgx-kernel-...@lists.01.org from CC because I can
> do without the silly moderation spam of that list. Please disable that
> nonsense.
>
> > On Mon, Nov 13, 2017
On Fri, 17 Nov 2017, Darren Hart wrote:
@intel: I removed intel-sgx-kernel-...@lists.01.org from CC because I can
do without the silly moderation spam of that list. Please disable that
nonsense.
> On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:
> Is SGX considered architectural o
On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:
Please do not submit patches to LKML without a commit message. There is
*always* something you can provide to give the review additional context
to aid in their review of your code.
As Thomas has noted, the various maintainers have
On Tue, Nov 14, 2017 at 10:49:48PM +0200, Jarkko Sakkinen wrote:
> In these cases IA32_FEATURE_CONTROL[17] would be zeroed before locking
> the feature control, which would mean that the kernel could not write
> new values with wrmsr for the root key hash.
> The question is whether we want to allo
On Tue, Nov 14, 2017 at 10:49:48PM +0200, Jarkko Sakkinen wrote:
> Pre-boot firmware could potentially configure the root key hash for the
> enclave that signs launch tokens for other enclaves i.e. the launch
> enclave that is built and signed during the kbuild.
So how about firmware doesn't do an
On Tue, 2017-11-14 at 21:47 +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 14, 2017 at 04:01:05PM +1300, Kai Huang wrote:
> > Not sure whether you should talk about MEE staff here. They are not
> > in
> > SDM and (thus) may potentially be changed in the future.
>
> The use of MEE is documented in man
On Tue, Nov 14, 2017 at 09:36:47AM +0100, Borislav Petkov wrote:
> > +* **IA32_FEATURE_CONTROL[0]**: locks down the feature control register
> > +* **IA32_FEATURE_CONTROL[17]**: allow runtime reconfiguration of
> > + IA32_SGXLEPUBKEYHASHn MSRs that define MRSIGNER hash for the launch
> > + enclav
On Tue, Nov 14, 2017 at 04:01:05PM +1300, Kai Huang wrote:
> Not sure whether you should talk about MEE staff here. They are not in
> SDM and (thus) may potentially be changed in the future.
The use of MEE is documented in many places like
https://eprint.iacr.org/2016/204.pdf
I see no reason n
On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:
<--- and yeah, all those patches without a commit message, need one.
> Signed-off-by: Jarkko Sakkinen
> ---
> Documentation/index.rst | 1 +
> Documentation/x86/intel_sgx.rst | 131
>
On Mon, 2017-11-13 at 21:45 +0200, Jarkko Sakkinen wrote:
> Signed-off-by: Jarkko Sakkinen
> ---
> Documentation/index.rst | 1 +
> Documentation/x86/intel_sgx.rst | 131
>
> 2 files changed, 132 insertions(+)
> create mode 100644 Documentation/
Signed-off-by: Jarkko Sakkinen
---
Documentation/index.rst | 1 +
Documentation/x86/intel_sgx.rst | 131
2 files changed, 132 insertions(+)
create mode 100644 Documentation/x86/intel_sgx.rst
diff --git a/Documentation/index.rst b/Documentation/
30 matches
Mail list logo
