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,
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:
> > > >
> > > >
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:
> > > >
> > > >
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
> > >
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
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:
> > > >
> > > >
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
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
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
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
> > >
> > > 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
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
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
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
> 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
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
> >
> > 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
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
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
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
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
> 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
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
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
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 :)
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
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
>
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,
> 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
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
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
> > >
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
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
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
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
> > > *
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
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
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
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
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
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
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
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
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
