/uapi/asm/sgx.h | 11 +
>> arch/x86/kernel/cpu/sgx/ioctl.c | 81
>> ++++-
>> tools/testing/selftests/sgx/defines.h | 1 +
>> tools/testing/selftests/sgx/load.c | 57 +++
>> tools/testing/selftests/sgx/main.h | 1 +
>> tools/testing/selftests/sgx/sigstruct.c | 43 -
>> 6 files changed, 154 insertions(+), 40 deletions(-)
>>
>> --
>> 2.7.4
>>
>>
>
> /Jarkko
>
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
On 2021-04-12 18:47, Dave Hansen wrote:
> On 4/12/21 9:41 AM, Jethro Beekman wrote:
>> Yes this still doesn't let one execute all possible ECREATE, EADD, EEXTEND,
>> EINIT sequences.
>
> OK, so we're going in circles now.
>
> I don't believe we necessarily *WANT* or
On 2021-04-12 18:40, Dave Hansen wrote:
> On 4/12/21 8:58 AM, Jethro Beekman wrote:
>> On 2021-04-12 17:36, Dave Hansen wrote:
>>> On 4/12/21 1:59 AM, Raoul Strackx wrote:
>>>> This patch set adds a new ioctl to enable userspace to execute EEXTEND
>>>&g
tl:
- execute EADD on any address
- execute EADD on any address followed by 16× EEXTEND for that address span
Could you be more specific on how you're suggesting that the current ioctl is
modified to in addition support the following?
- execute EEXTEND on any address
--
Jethro Beekman | Fortanix
On 2021-04-02 22:48, Dave Hansen wrote:
> On 4/2/21 1:20 PM, Jethro Beekman wrote:
>> On 2021-04-02 21:50, Dave Hansen wrote:
>>> Again, how does this save space?
>>>
>>> Are you literally talking about the temporary cost of allocating *one* page?
>>
On 2021-04-04 18:04, Jarkko Sakkinen wrote:
> On Fri, Apr 02, 2021 at 08:31:19PM +0200, Jethro Beekman wrote:
>> On 2021-04-02 17:53, Dave Hansen wrote:
>>> On 4/2/21 1:38 AM, Jethro Beekman wrote:
>>>>> So, we're talking here about pages that have been EEADDED, b
On 2021-04-02 21:50, Dave Hansen wrote:
>
> On 4/2/21 12:38 PM, Jethro Beekman wrote:
>> On 2021-04-02 20:42, Dave Hansen wrote:
>>> On 4/2/21 11:31 AM, Jethro Beekman wrote:
>>>> On 2021-04-02 17:53, Dave Hansen wrote:
>>>>> But,
On 2021-04-02 20:42, Dave Hansen wrote:
> On 4/2/21 11:31 AM, Jethro Beekman wrote:
>> On 2021-04-02 17:53, Dave Hansen wrote:
>>> On 4/2/21 1:38 AM, Jethro Beekman wrote:
>>>>> So, we're talking here about pages that have been EEADDED, but for
>>>>
On 2021-04-02 17:53, Dave Hansen wrote:
> On 4/2/21 1:38 AM, Jethro Beekman wrote:
>>> So, we're talking here about pages that have been EEADDED, but for
>>> which we do not want to include the entire contents of the page?
>>> Do these contents always include the
age, or can the holes be
> anywhere?
Holes can be anywhere, and EEXTEND calls need not be sequential in memory
address or even relate to the most recently EADDed page.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
d to pass a 16-bit bitset of which of the 16
256-byte parts of a 4096-byte page to measure. This was removed at some point
in favor of a separate ioctl to be added later. That is this. See the
discussion linked in the cover letter.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
to char bus_id[15] in 2007 in the
> commit bb0958544f3c ("ACPI: use more understandable bus_id for ACPI devices")
>
> Fix the issue by changing the field bus_id to const char *, and use
> kstrdup_const() to initialize it.
>
> Signed-off-by: Dexuan Cui
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=210449
Tested-By: Jethro Beekman
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
This regression (boot failure) is now in 5.11.0-rc2
--
Jethro Beekman | Fortanix
Forwarded Message
Subject: [Bug 210449] New: acpi_device_add: buffer overflow in strcpy
Date: Wed, 02 Dec 2020 02:16:38 -0800
From: bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org
> x86/fault: Add helper function to sanitize error code
> x86/traps: Attempt to fixup exceptions in vDSO before signaling
> x86/vdso: Implement a vDSO for Intel SGX enclave call
I tested Jarkko's public git master branch at the time of writing (patch
number, commit):
01 3dbc95
for SystemV ABI" but
with sgx_enclave_run.user_handler=NULL, R12~R15 *will* get clobbered when
__vdso_sgx_enter_enclave returns from an SGX AEX. IMO this makes the whole "try
to be like System V ABI" rather useless, but I suppose it doesn't matter too
much.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
isters. This makes it possible to declare the vDSO as a C
> prototype, but other than that there is no specific support for SystemV
> ABI. Things like storing XSAVE are the responsibility of the enclave and
> the runtime.
>
> Suggested-by: Andy Lutomirski
> Acked-by: Jethro Beekman
isters. This makes it possible to declare the vDSO as a C
> prototype, but other than that there is no specific support for SystemV
> ABI. Things like storing XSAVE are the responsibility of the enclave and
> the runtime.
>
> Suggested-by: Andy Lutomirski
> Acked-by: Jethro Beekman
lue over enclave memory. RAND means
that the KEYID field from the KEYREQUEST is included in the derivation (as
noted in the source row of the table you looked at).
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
+__u64 tcs;
>> +__u64 user_handler;
>> +__u64 user_data;
>> +__u32 leaf;
>
> I am still very strongly opposed to omitting exit_reason. It is not at all
> difficult to imagine scenarios where 'leaf' alone is insufficient for the
> caller or its handler to deduce why the CPU exited the enclave. E.g. see
> Jethro's request for intercepting interrupts.
Not entirely sure what this has to do with my request, I just expect to see
leaf=ERESUME in this case, I think? E.g. as you would see in EAX when calling
ENCLU.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
hen so be it.
Good enough for me.
On 2020-09-26 00:29, Sean Christopherson wrote:
> We do have this confidence, because it's required by the current version
> of the VDSO.
Do you mean “it's required by the current version of the VDSO” and nobody has
complained about it?
> But the callback is optional...
Yup.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
On 2020-09-25 13:17, Jarkko Sakkinen wrote:
> On Fri, Sep 25, 2020 at 10:39:58AM +0200, Jethro Beekman wrote:
>> On 2020-09-25 03:00, Jarkko Sakkinen wrote:
>>> End result:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x8
s parameter passing registers in the ABI. This is
intentional to make the vDSO function usable in applications that use the
current flexibility of ENCLU.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
for “reasons”, but if after you've written them once it still
doesn't work, clearly either 1) an “unhelpful” VMM is actively messing with the
MSRs which I'd say is at best a VMM bug or 2) there was an EPC reset and your
enclave is now invalid anyway, so no need to EINIT.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
one place to another.
>
Agreed that BPF doesn't make things better.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
d be
“interpret IRQ exit as a normal exit” and let it be handled the same as any
other exit based on whether an exit handler fnptr was passed or not.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
On 2020-07-14 11:56, Jarkko Sakkinen wrote:
> On Tue, Jul 14, 2020 at 09:30:03AM +0200, Jethro Beekman wrote:
>> On 2020-07-07 05:37, Jarkko Sakkinen wrote:
>>> From: Sean Christopherson
>>>
>>> An SGX runtime must be aware of the exceptions, which happen ins
es not follow System V x86-64 ABI.
>
> Suggested-by: Andy Lutomirski
> Acked-by: Jethro Beekman
> Tested-by: Jethro Beekman
> Signed-off-by: Sean Christopherson
> Co-developed-by: Cedric Xing
> Signed-off-by: Cedric Xing
> Signed-off-by: Jarkko Sakkinen
> ---
> arc
Looks like we missed the boat for 5.8. Can we get this ready for 5.9?
--
Jethro Beekman | Fortanix
On 2020-06-01 09:51, Jarkko Sakkinen wrote:
> Intel(R) SGX is a set of CPU instructions that can be used by applications
> to set aside private regions of code and data. The code o
On 2020-05-14 00:14, Jarkko Sakkinen wrote:
> General question: maybe it would be easiest that I issue a pull request
> once everyone feels that the series is ready to be pulled and stop sending
> new versions of the series?
Sounds good
--
Jethro Beekman | Fortanix
smime.p7s
Descr
On 2020-04-30 10:23, Jarkko Sakkinen wrote:
> On Thu, Apr 30, 2020 at 09:19:48AM +0200, Jethro Beekman wrote:
>> On 2020-04-30 05:46, Jarkko Sakkinen wrote:
>>> On Wed, Apr 29, 2020 at 05:27:48PM +0200, Jethro Beekman wrote:
>>>> On 2020-04-21 23:52, Jarkko Sakk
On 2020-04-30 05:46, Jarkko Sakkinen wrote:
> On Wed, Apr 29, 2020 at 05:27:48PM +0200, Jethro Beekman wrote:
>> On 2020-04-21 23:52, Jarkko Sakkinen wrote:
>>> Intel(R) SGX is a set of CPU instructions that can be used by applications
>>> to set aside private regions
e kernel can
> decide what enclaves it wants run. The implementation does not create
> any bottlenecks to support read-only MSRs later on.
>
> You can tell if your CPU supports SGX by looking into /proc/cpuinfo:
>
> cat /proc/cpuinfo | grep sgx
Let's merge this.
--
Jethro
On 2019-10-01 17:30, Roopa Prabhu wrote:
> On Sun, Sep 29, 2019 at 11:27 PM Jethro Beekman wrote:
>>
>> When using rule-based routing to send traffic via VXLAN, a routing
>> loop may occur. Say you have the following routing setup:
>>
>> ip rule add from all fw
.
Signed-off-by: Jethro Beekman
---
drivers/net/vxlan.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 3d9bcc9..f9ed1b7 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2236,7 +2236,6 @@ static struct rtable *vxlan_get_route(struct
On 2019-09-16 11:19, Mika Westerberg wrote:
> On Mon, Sep 16, 2019 at 09:12:50AM +0000, Jethro Beekman wrote:
>> On 2019-09-16 11:11, Mika Westerberg wrote:
>>> Hi,
>>>
>>> On Sun, Sep 15, 2019 at 08:41:55PM +, Jethro Beekman wrote:
>>>> Could
On 2019-09-16 11:11, Mika Westerberg wrote:
> Hi,
>
> On Sun, Sep 15, 2019 at 08:41:55PM +0000, Jethro Beekman wrote:
>> Could someone please review this?
>>
>> On 2019-09-04 03:15, Jethro Beekman wrote:
>>> Some flash controllers don't have a softw
Could someone please review this?
On 2019-09-04 03:15, Jethro Beekman wrote:
> Some flash controllers don't have a software sequencer. Avoid
> configuring the register addresses for it, and double check
> everywhere that its not accidentally trying to be used.
>
> Every use of
function.
Signed-off-by: Jethro Beekman
---
drivers/mtd/spi-nor/intel-spi.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index 1ccf23f..195cdca 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
Now that SPI flash controllers without a software sequencer are
supported, it's trivial to add support for CNL and its PCI ID.
Values from
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/300-series-chipset-pch-datasheet-vol-2.pdf
Signed-off-by: Jethro Beekman
v2 changes:
* Fix whitespace.
* Link to datasheet.
Jethro Beekman (2):
mtd: spi-nor: intel-spi: support chips without software sequencer
mtd: spi-nor: intel-spi: add support for Intel Cannon Lake SPI flash
drivers/mtd/spi-nor/intel-spi-pci.c | 5 +
drivers/mtd/spi-nor/intel-spi.c
sheet-vol-2.pdf
. If you have more accurate information, please let me know.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
(apologies, resending without S/MIME signature)
Now that SPI flash controllers without a software sequencer are
supported, it's trivial to add support for CNL and its PCI ID.
Signed-off-by: Jethro Beekman
---
drivers/mtd/spi-nor/intel-spi-pci.c | 5 +
drivers/mtd/spi-nor/intel
Now that SPI flash controllers without a software sequencer are
supported, it's trivial to add support for CNL and its PCI ID.
Signed-off-by: Jethro Beekman
---
drivers/mtd/spi-nor/intel-spi-pci.c | 5 +
drivers/mtd/spi-nor/intel-spi.c | 11 +++
include/linux
function.
Signed-off-by: Jethro Beekman
---
drivers/mtd/spi-nor/intel-spi.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/spi-nor/intel-spi.c
b/drivers/mtd/spi-nor/intel-spi.c
index 1ccf23f..195cdca 100644
--- a/drivers/mtd/spi-nor/intel
ECPM permissions are mentioned in SDM EADD instruction operation. PTE I
don't know.
--
Jethro Beekman | Fortanix
On 2019-08-07 08:17, Jarkko Sakkinen wrote:
On Wed, Aug 07, 2019 at 06:15:34PM +0300, Jarkko Sakkinen wrote:
On Mon, Jul 29, 2019 at 11:17:57AM +, Ayoun, Serge wrote
lug. In effect, the device is now parentless.
I think you also missed in the changelog that you're now checking page
permissions in EADD.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
nfrastructure does not support dependencies on loadable modules.
* Separating EPC swapping from the driver once it has been tightly
coupled to the driver is non-trivial (speaking from experience).
Some of these points seem stale now.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
On 2019-05-21 08:19, Jarkko Sakkinen wrote:
We could even disallow mmap() before EINIT done.
This would be extremely annoying in software because now you have to
save the all the page permissions somewhere between EADD and mprotect.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S
of a file puts significant restrictions on the enclave's on-disk
representation.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
On 2019-05-10 10:54, Dave Hansen wrote:
On 5/10/19 10:37 AM, Jethro Beekman wrote:
It does assume a specific format, namely, that the memory layout
(including page types/permissions) of the enclave can be represented in
a "flat file" on disk, or at least that the enclave memory conten
source for EPC. Then SGX specific hooks/policies could be supported easily.
How do you think?
-Cedric
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
sgx_enclave_add_page)
#define SGX_IOC_ENCLAVE_INIT \
_IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
+#define SGX_IOC_ENCLAVE_SET_ATTRIBUTE \
+ _IOW(SGX_MAGIC, 0x03, struct sgx_enclave_set_attribute)
Need to update Documentation/ioctl/ioctl-number.txt as well
--
Jethro Beekman
On 2019-04-23 17:26, Sean Christopherson wrote:
On Tue, Apr 23, 2019 at 11:29:24PM +, Jethro Beekman wrote:
On 2019-04-22 14:58, Sean Christopherson wrote:
Now that the core SGX code is approaching stability, I'd like to start
sending RFCs for the EPC virtualization and KVM bits to hash
ld require
non-trivial changes to the core SGX code for the proposed virtualization
implementation. I'd strongly prefer to get it out of the way before
sending the KVM RFCs.
What kind of changes? Wouldn't KVM just be another consumer of the same
API used by the driver?
--
Jethro Beekman | For
On 2019-04-22 09:26, Andy Lutomirski wrote:
On Apr 19, 2019, at 2:56 PM, Jethro Beekman wrote:
This works fine with v20 as-is. However, consider the equivalent of the
PT-based flow:
mmap(PROT_READ|PROT_EXEC)
ioctl(EADD) <-- no error!
Indeed!
It's not me that's working around the LSM, i
g appropriate page-table permissions
even on the SGX instructions that don't do it themselves. Just make any
implicit memory access look like a regular memory access and now
everyone is on the same page (pun intended).
--
Jethro Beekman | Fortanix
case you describe.
--
Jethro Beekman | Fortanix
Jethro Beekman | Fortanix
On 2019-04-19 14:15, Andy Lutomirski wrote:
>
>
>
>
>> On Apr 19, 2019, at 1:54 PM, Jethro Beekman wrote:
>>
>>> On 2019-04-19 13:50, Thomas Gleixner wrote:
>>>> On Fri, 19 Apr 2019, Jethro Beekman wrote:
>
On 2019-04-19 13:46, Jethro Beekman wrote:
> On 2019-04-19 13:39, Thomas Gleixner wrote:
>> On Fri, 19 Apr 2019, Jethro Beekman wrote:
>>
>>> On 2019-04-19 08:27, Andy Lutomirski wrote:
>>>> There are many,
>>>> many Linux systems that enforce a poli
On 2019-04-19 13:50, Thomas Gleixner wrote:
> On Fri, 19 Apr 2019, Jethro Beekman wrote:
>> On 2019-04-19 13:39, Thomas Gleixner wrote:
>>> On Fri, 19 Apr 2019, Jethro Beekman wrote:
>>>
>>>> On 2019-04-19 08:27, Andy Lutomirski wrote:
>>>>>
On 2019-04-19 13:39, Thomas Gleixner wrote:
> On Fri, 19 Apr 2019, Jethro Beekman wrote:
>
>> On 2019-04-19 08:27, Andy Lutomirski wrote:
>>> There are many,
>>> many Linux systems that enforce a policy that *all* executable text
>>> needs to come from a
xecutable.
How is this implemented on those systems? AFAIK there's no kernel config
option that changes the semantics of mmap as you describe.
--
Jethro Beekman | Fortanix
/blob/6a0b5ac71f8d16f04e0376f3b2168e80c773dd23/sdk/trts/trts.cpp#L125-L140
Regarding "almost all existing enclaves to date", enclaves built with
the Fortanix toolchain don't touch the untrusted stack.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
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
fd;
};
What is this for?
#endif /* _UAPI_ASM_X86_SGX_H */
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
for @regs and clear it at the end.
+2: pop %rbx
+ pop %r12
+ pop %r13
+ pop %r14
+ pop %r15
+ pop %rbp
+ ret
x86-64 ABI requires that you call CLD here (enclave may set it).
--
Jethro Beekman | Fortanix
smime.p7s
Description: S
On 2018-12-08 00:14, Dave Hansen wrote:
On 12/7/18 10:15 AM, Jethro Beekman wrote:
This is not sufficient to support the Fortanix SGX ABI calling
convention, which was designed to be mostly compatible with the SysV
64-bit calling convention. The following registers need to be passed
On 2018-12-08 00:14, Dave Hansen wrote:
On 12/7/18 10:15 AM, Jethro Beekman wrote:
This is not sufficient to support the Fortanix SGX ABI calling
convention, which was designed to be mostly compatible with the SysV
64-bit calling convention. The following registers need to be passed
application/library/enclave combination installs
a signal handler and calls ENCLU directly, that would still work. Of
course, using the vDSO will be very strongly recommended.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
application/library/enclave combination installs
a signal handler and calls ENCLU directly, that would still work. Of
course, using the vDSO will be very strongly recommended.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
to an enclave from userspace: RDI, RSI, RDX, R8, R9, R10. The following
registers need to be passed out from an enclave to userspace: RDI, RSI,
RDX, R8, R9.
You can find the ABI specification at
https://github.com/fortanix/rust-sgx/blob/master/doc/FORTANIX-SGX-ABI.md#enclave-calling-convention
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
to an enclave from userspace: RDI, RSI, RDX, R8, R9, R10. The following
registers need to be passed out from an enclave to userspace: RDI, RSI,
RDX, R8, R9.
You can find the ABI specification at
https://github.com/fortanix/rust-sgx/blob/master/doc/FORTANIX-SGX-ABI.md#enclave-calling-convention
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
to deliver the exception as a regular signal to the process, or whether
to set the special registers values for userspace and just continue
executing the process manually?
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
to deliver the exception as a regular signal to the process, or whether
to set the special registers values for userspace and just continue
executing the process manually?
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
to build this as a module for other
users of SGX. What is the swapping patch and why doesn't allow building
as a module?
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
to build this as a module for other
users of SGX. What is the swapping patch and why doesn't allow building
as a module?
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
whether to set special
registers or send a signal?
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
whether to set special
registers or send a signal?
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
will contain ENCLU_LEAF_ERESUME (0x3). On EEXIT, %rax will
contain ENCLU_LEAF_EEXIT (0x4).
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
will contain ENCLU_LEAF_ERESUME (0x3). On EEXIT, %rax will
contain ENCLU_LEAF_EEXIT (0x4).
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
return ret;
+ }
+
+ sgx_nr_epc_sections++;
+ }
+
+ if (!sgx_nr_epc_sections) {
+ pr_err("sgx: There are zero EPC sections.\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
return ret;
+ }
+
+ sgx_nr_epc_sections++;
+ }
+
+ if (!sgx_nr_epc_sections) {
+ pr_err("sgx: There are zero EPC sections.\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
On 2018-11-02 10:01, Andy Lutomirski wrote:
On Fri, Nov 2, 2018 at 9:56 AM Jethro Beekman wrote:
On 2018-11-02 09:52, Sean Christopherson wrote:
On Fri, Nov 02, 2018 at 04:37:10PM +, Jethro Beekman wrote:
On 2018-11-02 09:30, Sean Christopherson wrote:
... The intended convention
On 2018-11-02 10:01, Andy Lutomirski wrote:
On Fri, Nov 2, 2018 at 9:56 AM Jethro Beekman wrote:
On 2018-11-02 09:52, Sean Christopherson wrote:
On Fri, Nov 02, 2018 at 04:37:10PM +, Jethro Beekman wrote:
On 2018-11-02 09:30, Sean Christopherson wrote:
... The intended convention
On 2018-11-02 09:52, Sean Christopherson wrote:
On Fri, Nov 02, 2018 at 04:37:10PM +, Jethro Beekman wrote:
On 2018-11-02 09:30, Sean Christopherson wrote:
... The intended convention for EENTER is to have an ENCLU at the AEX target ...
... to further enforce that the AEX target needs
On 2018-11-02 09:52, Sean Christopherson wrote:
On Fri, Nov 02, 2018 at 04:37:10PM +, Jethro Beekman wrote:
On 2018-11-02 09:30, Sean Christopherson wrote:
... The intended convention for EENTER is to have an ENCLU at the AEX target ...
... to further enforce that the AEX target needs
On 2018-11-02 09:30, Sean Christopherson wrote:
... The intended convention for EENTER is to have an ENCLU at the AEX target ...
... to further enforce that the AEX target needs to be ENCLU.
Some SGX runtimes may want to use a different AEX target.
--
Jethro Beekman | Fortanix
smime.p7s
On 2018-11-02 09:30, Sean Christopherson wrote:
... The intended convention for EENTER is to have an ENCLU at the AEX target ...
... to further enforce that the AEX target needs to be ENCLU.
Some SGX runtimes may want to use a different AEX target.
--
Jethro Beekman | Fortanix
smime.p7s
ABI), such that most registers are
passed between user space and enclave space untouched. Basically, only
RAX, RBX, RCX are available as input and output registers.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
ABI), such that most registers are
passed between user space and enclave space untouched. Basically, only
RAX, RBX, RCX are available as input and output registers.
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
On 2018-07-03 11:19, Jarkko Sakkinen wrote:
+/* IOCTL return values */
+#define SGX_POWER_LOST_ENCLAVE 0x4000
+#define SGX_LE_ROLLBACK0x4001
I don't think SGX_LE_ROLLBACK is used anymore.
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME
On 2018-07-03 11:19, Jarkko Sakkinen wrote:
+/* IOCTL return values */
+#define SGX_POWER_LOST_ENCLAVE 0x4000
+#define SGX_LE_ROLLBACK0x4001
I don't think SGX_LE_ROLLBACK is used anymore.
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME
On 2018-06-20 11:16, Jethro Beekman wrote:
> This last bit is also repeated in different words in Table 35-2 and
> Section 42.2.2. The MSRs are *not writable* before the write-lock bit
> itself is locked. Meaning the MSRs are either locked with Intel's key
> hash, or not l
On 2018-06-20 11:16, Jethro Beekman wrote:
> This last bit is also repeated in different words in Table 35-2 and
> Section 42.2.2. The MSRs are *not writable* before the write-lock bit
> itself is locked. Meaning the MSRs are either locked with Intel's key
> hash, or not l
h enclave live entirely within that UEFI module?
On 2017-03-17 09:15, Jethro Beekman wrote:
> While collecting my thoughts about the issue I read through the
> documentation again and it seems that it will not be possible for a
> platform to lock in a non-Intel hash at all. From S
h enclave live entirely within that UEFI module?
On 2017-03-17 09:15, Jethro Beekman wrote:
> While collecting my thoughts about the issue I read through the
> documentation again and it seems that it will not be possible for a
> platform to lock in a non-Intel hash at all. From S
On 2018-06-19 07:08, Jarkko Sakkinen wrote:
On Fri, Jun 08, 2018 at 11:21:48AM -0700, Jethro Beekman wrote:
On 2018-06-08 10:09, Jarkko Sakkinen wrote:
+/*
+ * Writing the LE hash MSRs is extraordinarily expensive, e.g.
+ * 3-4x slower than normal MSRs, so we use a per-cpu cache to
+ * track
On 2018-06-19 07:08, Jarkko Sakkinen wrote:
On Fri, Jun 08, 2018 at 11:21:48AM -0700, Jethro Beekman wrote:
On 2018-06-08 10:09, Jarkko Sakkinen wrote:
+/*
+ * Writing the LE hash MSRs is extraordinarily expensive, e.g.
+ * 3-4x slower than normal MSRs, so we use a per-cpu cache to
+ * track
to be identical
+ * across cpus, so we'd have to run code all all cpus to properly
+ * init the cache. All in all, the complexity and overhead of
+ * initializing the cache is not justified.
+ */
+static DEFINE_PER_CPU(u64 [4], sgx_le_pubkey_hash_cache);
--
Jethro Beekman | Fortanix
smime.p7s
to be identical
+ * across cpus, so we'd have to run code all all cpus to properly
+ * init the cache. All in all, the complexity and overhead of
+ * initializing the cache is not justified.
+ */
+static DEFINE_PER_CPU(u64 [4], sgx_le_pubkey_hash_cache);
--
Jethro Beekman | Fortanix
smime.p7s
1 - 100 of 134 matches
Mail list logo
