It's yet to be determined what best practices will be, but I have a hunch SGX will be used along the following lines:
1) load an encrypted symmetric key into an enclave
2) decrypt the symmetric key in the enclave
3) create a private key in the enclave, and encrypt it with the symmetric key inside the enclave. Give the encrypted data back to the user for storage.
4) All operations using the private key (sign, decrypt) are marshaled to the SGX enclave. You'll give the enclave the encrypted private key and the operation to be performed, and the enclave will return the result. The private key is decrypted by the symmetric key inside the enclave, and unloaded from the enclave memory as soon as the operation is completed.
There's obviously some churn copying the encypted private key to the enclave each time, but the private key is typically used for very few operations until an ephemeral symmetric key is negotiated. If you're super-paranoid the ephemeral key can marshal its operations to the enclave, but I think most people will agree that the only thing you can realistically protect without sacrificing performance is the private key.
So you would load the symmetric key into the enclave out of band i.e via the BIOS or IPMI? Could this be use the encrypt filesystem or block devices using something like LUKs I wonder?
Around 100MB of physical RAM, to be shared among all enclaves active at a given time in the platform. Enclaves can be swapped out (if the OS/VMM is sophisticated enough), so in principle memory can be overbooked.
That's not a hardware limitation; SGX supports arbitrarily large enclaves. The encrypted region of physical memory has to be reserved during early boot (using the PRMRR_BASE and PRMRR_MASK MSRs), so typically it's a small portion of physical memory to avoid taking too much memory from the OS; however, that could be configured to be larger if needed.
And as you noted, SGX supports the kernel paging memory in and out of the enclave (encrypting it before giving it to the kernel to store), which allows for arbitrarily large enclaves regardless of the amount of reserved physical memory.
Typically you do want to minimize the amount of code that you put inside the enclave to minimize your attack surface and the amount of code you trust, but there isn't any architectural limitation on size.
