linux-kernel - Re: [PATCH v5 11/11] intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171114204948.f6g2m62kx5gr5xtw@linux.intel.com>
Date:   Tue, 14 Nov 2017 22:49:48 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     intel-sgx-kernel-dev@...ts.01.org,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 11/11] intel_sgx: driver documentation

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
> > +  enclave. Essentially they define a signing key that does not require
> > +  EINITTOKEN to be let run.
> [SNIP]
> 
> What does that mean exactly?
> 
> OEM vendor BIOS can control how many enclaves user can launch and what
> signing key is loaded and lock down the feature control register so that
> no other signing keys are loaded?
> 
> Or am I misreading this?

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.

VMM/Hypervisor could potentially simulate such enviroment for guests.

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.

You could use this to write policy inside the LE. The current LE is
really simple "pass-through everything" but it could be refined to be
something more non-trivial.

The question is whether we want to allow this or not. If the answer is
no, a check can be added to the driver initialization code whether 17 is
set, and if not, it driver would fail to initialize.

I'm not too dilated to any direction concerning this question. I just
wrote a driver that is robust. This is where I need your feedback to do
the right thing.

> -- 
> Regards/Gruss,
>     Boris.

PS. I'll add a proper commit message. Sorry for not doing that before.

/Jarkko