On Fri, Jan 11, 2019 at 03:19:56PM -0800, Sean Christopherson wrote:
> On Fri, Jan 11, 2019 at 02:58:26PM +0200, Jarkko Sakkinen wrote:
> > On Wed, Jan 09, 2019 at 08:31:37AM -0800, Sean Christopherson wrote:
> > > On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > > > On Tue, Jan
On Fri, Jan 11, 2019 at 02:58:26PM +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 09, 2019 at 08:31:37AM -0800, Sean Christopherson wrote:
> > On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > > On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
> > > wrote:
> > > >
> > > > Cleaner
On Thu, Jan 10, 2019 at 01:36:15PM -0800, Andy Lutomirski wrote:
> > Does it even matter if just leave EINITTOKENKEY attribute unprivileged
> > given that Linux requires that MSRs are writable? Maybe I'll just
> > whitelist that attribute to any enclave?
> >
>
> I would at least make it work like
On Fri, Jan 11, 2019 at 02:58:26PM +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 09, 2019 at 08:31:37AM -0800, Sean Christopherson wrote:
> > On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > > On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
> > > wrote:
> > > >
> > > > Cleaner
On Wed, Jan 09, 2019 at 08:31:37AM -0800, Sean Christopherson wrote:
> On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
> > wrote:
> > >
> > > Cleaner in the sense that it's faster to get basic support up and running
> > > sinc
On Thu, Jan 10, 2019 at 04:30:06PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 10, 2019 at 3:54 PM Sean Christopherson
> wrote:
> >
> > Sort of. A guest that is running under KVM (i.e. VMX) is much more
> > contained than a random userspace program. A rogue enclave in a VMX
> > guest can attack
On Thu, Jan 10, 2019 at 3:54 PM Sean Christopherson
wrote:
>
> On Thu, Jan 10, 2019 at 01:34:44PM -0800, Andy Lutomirski wrote:
> > >> On Jan 9, 2019, at 8:31 AM, Sean Christopherson
> > >> wrote:
> > >>
> > >> On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > >
> > >> I do th
On Thu, Jan 10, 2019 at 01:34:44PM -0800, Andy Lutomirski wrote:
> >> On Jan 9, 2019, at 8:31 AM, Sean Christopherson
> >> wrote:
> >>
> >> On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> >
> >> I do think it makes sense to have QEMU delegate the various ENCLS
> >> operations (
On Thu, 2019-01-10 at 13:34 -0800, Andy Lutomirski wrote:
> > > On Jan 9, 2019, at 8:31 AM, Sean Christopherson
> > > wrote:
> > >
> > > On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > > On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
> > > wrote:
> > > >
> > > > Cleane
On Thu, Jan 10, 2019 at 9:46 AM Jarkko Sakkinen
wrote:
>
> On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > I do think it makes sense to have QEMU delegate the various ENCLS
> > operations (especially EINIT) to the regular SGX interface, which will
> > mean that VM guests will
>> On Jan 9, 2019, at 8:31 AM, Sean Christopherson
>> wrote:
>>
>> On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
>> On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
>> wrote:
>>>
>>> Cleaner in the sense that it's faster to get basic support up and running
>>> since there ar
On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> I do think it makes sense to have QEMU delegate the various ENCLS
> operations (especially EINIT) to the regular SGX interface, which will
> mean that VM guests will have exactly the same access controls applied
> as regular user pr
On Tue, Jan 08, 2019 at 07:27:11PM +, Huang, Kai wrote:
> > >
> > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > opening a new instance of /dev/sgx for each encalve?
> >
> > Directly associating /dev/sgx with an enclave means /dev/sgx can't be used
> > to provide ioc
On Wed, Jan 09, 2019 at 04:21:19PM -0800, Huang, Kai wrote:
> > > > That's possible, but it has several downsides.
> > > >
> > > > - Duplicates a lot of code in KVM for managing memory regions.
> > >
> > > I don't see why there will be duplicated code. you can simply call
> > > __x86_set_memory_r
> > > That's possible, but it has several downsides.
> > >
> > > - Duplicates a lot of code in KVM for managing memory regions.
> >
> > I don't see why there will be duplicated code. you can simply call
> > __x86_set_memory_region to create private slot. It is KVM x86
> > equivalent to KVM_SET_US
On Tue, Jan 08, 2019 at 09:24:38PM -0800, Huang, Kai wrote:
> > On Tue, Jan 08, 2019 at 11:27:11AM -0800, Huang, Kai wrote:
> > > > >
> > > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > > > opening a new instance of /dev/sgx for each encalve?
> > > >
> > > > Directly a
On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
> wrote:
> >
> > Cleaner in the sense that it's faster to get basic support up and running
> > since there are fewer touchpoints, but there are long term ramifications
> > to cramm
On Thu, Jan 03, 2019 at 08:26:35AM -0800, Sean Christopherson wrote:
> What I was trying to explain is that the uapi isn't for KVM, it's for
> the userspace hypervisor, e.g. Qemu. Qemu will inform KVM of the
> resulting guest memory region so that KVM can configure its guest page
> tables accordin
> On Tue, Jan 08, 2019 at 11:27:11AM -0800, Huang, Kai wrote:
> > > >
> > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > > opening a new instance of /dev/sgx for each encalve?
> > >
> > > Directly associating /dev/sgx with an enclave means /dev/sgx can't
> > > be used t
On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
wrote:
>
> On Tue, Jan 08, 2019 at 11:27:11AM -0800, Huang, Kai wrote:
> > > >
> > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > > opening a new instance of /dev/sgx for each encalve?
> > >
> > > Directly associating
On Tue, Jan 08, 2019 at 11:27:11AM -0800, Huang, Kai wrote:
> > >
> > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > opening a new instance of /dev/sgx for each encalve?
> >
> > Directly associating /dev/sgx with an enclave means /dev/sgx can't be used
> > to provide ioc
> >
> > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > opening a new instance of /dev/sgx for each encalve?
>
> Directly associating /dev/sgx with an enclave means /dev/sgx can't be used
> to provide ioctl()'s for other SGX-related needs, e.g. to mmap() raw EPC and
> expose
On Wed, Jan 02, 2019 at 12:47:52PM -0800, Sean Christopherson wrote:
> On Sat, Dec 22, 2018 at 10:25:02AM +0200, Jarkko Sakkinen wrote:
> > On Sat, Dec 22, 2018 at 10:16:49AM +0200, Jarkko Sakkinen wrote:
> > > On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote:
> > > > On Wed, Dec 19,
On Sat, Dec 22, 2018 at 10:25:02AM +0200, Jarkko Sakkinen wrote:
> On Sat, Dec 22, 2018 at 10:16:49AM +0200, Jarkko Sakkinen wrote:
> > On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote:
> > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> > > > Can one of you expl
On Sun, Dec 23, 2018 at 12:41:49PM -0800, Andy Lutomirski wrote:
> Presumably sgx would create a bus and enumerate the devices as needed.
> Or I suppose these things could be platform or system devices. I’m not
> really a device model expert, and the one time I tried to implement a
> character devi
On Sun, Dec 23, 2018 at 12:42:48PM -0800, Andy Lutomirski wrote:
> On Sun, Dec 23, 2018 at 4:52 AM Jarkko Sakkinen
> wrote:
> >
> > On Sat, Dec 22, 2018 at 10:25:02AM +0200, Jarkko Sakkinen wrote:
> > > On Sat, Dec 22, 2018 at 10:16:49AM +0200, Jarkko Sakkinen wrote:
> > > > On Thu, Dec 20, 2018 a
On Sun, Dec 23, 2018 at 4:52 AM Jarkko Sakkinen
wrote:
>
> On Sat, Dec 22, 2018 at 10:25:02AM +0200, Jarkko Sakkinen wrote:
> > On Sat, Dec 22, 2018 at 10:16:49AM +0200, Jarkko Sakkinen wrote:
> > > On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote:
> > > > On Wed, Dec 19, 2018 at 06
> On Dec 21, 2018, at 11:24 AM, Sean Christopherson
> wrote:
>
> On Fri, Dec 21, 2018 at 09:12:46AM -0800, Andy Lutomirski wrote:
>>> On Dec 21, 2018, at 9:28 AM, Sean Christopherson
>>> wrote:
>>>
>>> On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> On Dec 19, 2018, at 6:
On Sat, Dec 22, 2018 at 10:25:02AM +0200, Jarkko Sakkinen wrote:
> On Sat, Dec 22, 2018 at 10:16:49AM +0200, Jarkko Sakkinen wrote:
> > On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote:
> > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> > > > Can one of you expl
On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > opening a new instance of /dev/sgx for each encalve?
>
> I think that fits better to the SCM
On Fri, Dec 21, 2018 at 09:12:46AM -0800, Andy Lutomirski wrote:
> /dev/sgx/enclave: Each instance is an enclave.
>
> /dev/sgx/epc: Used to get raw EPC for KVM. Might have different
> permissions, perhaps 0660 and group kvm.
>
> /dev/sgx/something_else: For when SGX v3 adds something else :)
Res
On Fri, Dec 21, 2018 at 10:24:54AM -0800, Sean Christopherson wrote:
> On Fri, Dec 21, 2018 at 09:12:46AM -0800, Andy Lutomirski wrote:
> > > On Dec 21, 2018, at 9:28 AM, Sean Christopherson
> > > wrote:
> > >
> > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> > >>> On Dec 1
On Fri, Dec 21, 2018 at 09:12:46AM -0800, Andy Lutomirski wrote:
> Hmm. I guess this makes some sense. My instinct would be to do it a
> little differently and have:
>
> /dev/sgx/enclave: Each instance is an enclave.
>
> /dev/sgx/epc: Used to get raw EPC for KVM. Might have different
> permissio
On Fri, Dec 21, 2018 at 09:12:46AM -0800, Andy Lutomirski wrote:
> > On Dec 21, 2018, at 9:28 AM, Sean Christopherson
> > wrote:
> >
> > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> >>> On Dec 19, 2018, at 6:45 AM, Sean Christopherson
> >>> wrote:
> >>>
> > On Wed, Dec
> On Dec 21, 2018, at 9:28 AM, Sean Christopherson
> wrote:
>
> On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
>>> On Dec 19, 2018, at 6:45 AM, Sean Christopherson
>>> wrote:
>>>
> On Wed, Dec 19, 2018 at 09:36:16AM +, Jethro Beekman wrote:
>>>
>>> I agree with Jethro,
On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> > On Dec 19, 2018, at 6:45 AM, Sean Christopherson
> > wrote:
> >
> >> On Wed, Dec 19, 2018 at 09:36:16AM +, Jethro Beekman wrote:
>
> > I agree with Jethro, passing the enclave_fd as a param is obnoxious.
> > And it means th
On Thu, Dec 20, 2018 at 04:06:38PM -0600, Dr. Greg wrote:
> On Thu, Dec 20, 2018 at 12:34:00PM +0200, Jarkko Sakkinen wrote:
>
> Good afternoon to everyone.
>
> > On Wed, Dec 19, 2018 at 08:43:43AM -0600, Dr. Greg wrote:
> > > I believe it is a silent response to the issues we were
> > > prosecut
On Thu, Dec 20, 2018 at 12:34:00PM +0200, Jarkko Sakkinen wrote:
Good afternoon to everyone.
> On Wed, Dec 19, 2018 at 08:43:43AM -0600, Dr. Greg wrote:
> > I believe it is a silent response to the issues we were
> > prosecuting 4-5 weeks ago, regarding the requirement for an SGX
> > driver on an
On Thu, Dec 20, 2018 at 03:12:13PM +0200, Jarkko Sakkinen wrote:
> On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote:
> > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > opening a new instan
On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > opening a new instance of /dev/sgx for each encalve?
>
> I think that fits better to the SCM
On Thu, Dec 20, 2018 at 01:08:46PM +0100, Arnd Bergmann wrote:
> On Wed, Dec 19, 2018 at 10:26 AM Jethro Beekman wrote:
> >
> > On 2018-12-19 13:28, Jarkko Sakkinen wrote:
> > > /**
> > > * struct sgx_enclave_add_page - parameter structure for the
> > > * %SGX_IOC_E
On Wed, Dec 19, 2018 at 10:26 AM Jethro Beekman wrote:
>
> On 2018-12-19 13:28, Jarkko Sakkinen wrote:
> > /**
> > * struct sgx_enclave_add_page - parameter structure for the
> > * %SGX_IOC_ENCLAVE_ADD_PAGE ioctl
> > * @eclave_fd:file handle to the enclave
On Wed, Dec 19, 2018 at 08:43:43AM -0600, Dr. Greg wrote:
> I believe it is a silent response to the issues we were prosecuting
> 4-5 weeks ago, regarding the requirement for an SGX driver on an FLC
> hardware platform to have some semblance of policy management to be
> relevant from a security/pri
On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> opening a new instance of /dev/sgx for each encalve?
I think that fits better to the SCM_RIGHTS scenario i.e. you could send
the enclav to a process that does not
On Wed, Dec 19, 2018 at 06:45:15AM -0800, Sean Christopherson wrote:
> I agree with Jethro, passing the enclave_fd as a param is obnoxious.
> And it means the user needs to open /dev/sgx to do anything with an
> enclave fd, e.g. the enclave fd might be passed to a builder thread,
Please note that
> On Dec 19, 2018, at 6:45 AM, Sean Christopherson
> wrote:
>
>> On Wed, Dec 19, 2018 at 09:36:16AM +, Jethro Beekman wrote:
> I agree with Jethro, passing the enclave_fd as a param is obnoxious.
> And it means the user needs to open /dev/sgx to do anything with an
> enclave fd, e.g. the enc
On Wed, Dec 19, 2018 at 08:41:12AM +, Jethro Beekman wrote:
Good morning, I everyone is weathering the pre-holiday season well.
> On 2018-12-19 13:28, Jarkko Sakkinen wrote:
> > * @eclave_fd: file handle to the enclave address space
> > * @attribute_fd:file handle of the att
On Wed, Dec 19, 2018 at 09:36:16AM +, Jethro Beekman wrote:
> On 2018-12-19 14:41, Jarkko Sakkinen wrote:
> >On Wed, Dec 19, 2018 at 08:41:12AM +, Jethro Beekman wrote:
> >>One weird thing is the departure from the normal mmap behavior that the
> >>memory mapping persists even if the origin
On Wed, Dec 19, 2018 at 09:36:16AM +, Jethro Beekman wrote:
> On 2018-12-19 14:41, Jarkko Sakkinen wrote:
> > On Wed, Dec 19, 2018 at 08:41:12AM +, Jethro Beekman wrote:
> > > One weird thing is the departure from the normal mmap behavior that the
> > > memory mapping persists even if the o
On 2018-12-19 14:41, Jarkko Sakkinen wrote:
On Wed, Dec 19, 2018 at 08:41:12AM +, Jethro Beekman wrote:
One weird thing is the departure from the normal mmap behavior that the
memory mapping persists even if the original fd is closed. (See man mmap:
"closing the file descriptor does not unma
On Wed, Dec 19, 2018 at 08:41:12AM +, Jethro Beekman wrote:
> One weird thing is the departure from the normal mmap behavior that the
> memory mapping persists even if the original fd is closed. (See man mmap:
> "closing the file descriptor does not unmap the region.")
The mmapped region and e
On 2018-12-19 13:28, Jarkko Sakkinen wrote:
I have pretty much figured out how to change the driver implementation
from VMA based to file based. Most of the code in the driver can be
reused with not that enormous changes. I think it is a clue that the
architecture is somewhat right because changi
I have pretty much figured out how to change the driver implementation
from VMA based to file based. Most of the code in the driver can be
reused with not that enormous changes. I think it is a clue that the
architecture is somewhat right because changing the driver this
radically does not seem to
53 matches
Mail list logo
