The total size calculated for EPC can overflow u64 given the added up page
for SECS.  Further, the total size calculated for shmem can overflow even
when the EPC size stays within limits of u64, given that it adds the extra
space for 128 byte PCMD structures (one for each page).

Address this by pre-evaluating the micro-architectural requirement of
SGX: the address space size must be power of two. This is eventually
checked up by ECREATE but the pre-check has the additional benefit of
making sure that there is some space for additional data.

Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-sgx/c87e01a0-e7dd-4749-a348-0980d3444f04@stanley.mountain/
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
v2: Simply check the micro-architetural requirement in order to address
    Dave's comment:
    https://lore.kernel.org/linux-sgx/45e68dea-af6a-4b2a-8249-420f14de3424@intel.com/
---
 arch/x86/kernel/cpu/sgx/ioctl.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index b65ab214bdf5..fedd5f666b5e 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -64,6 +64,14 @@ static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
 	struct file *backing;
 	long ret;
 
+	/*
+	 * This is a micro-architectural requirement. ECREATE would detect this
+	 * too without mentionable overhead but this check guarantees also that
+	 * the space calculations for EPC and shmem allocations never overflow.
+	 */
+	if (!is_power_of_2(secs->size))
+		return -EINVAL;
+
 	va_page = sgx_encl_grow(encl, true);
 	if (IS_ERR(va_page))
 		return PTR_ERR(va_page);
-- 
2.48.1

On 3/4/25 16:06, Jarkko Sakkinen wrote:
> +	/*
> +	 * This is a micro-architectural requirement. ECREATE would detect this
> +	 * too without mentionable overhead but this check guarantees also that
> +	 * the space calculations for EPC and shmem allocations never overflow.
> +	 */
> +	if (!is_power_of_2(secs->size))
> +		return -EINVAL;

Isn't it a plain old documented architectural requirement?

On Tue, Mar 04, 2025 at 04:18:03PM -0800, Dave Hansen wrote:
> On 3/4/25 16:06, Jarkko Sakkinen wrote:
> > +	/*
> > +	 * This is a micro-architectural requirement. ECREATE would detect this
> > +	 * too without mentionable overhead but this check guarantees also that
> > +	 * the space calculations for EPC and shmem allocations never overflow.
> > +	 */
> > +	if (!is_power_of_2(secs->size))
> > +		return -EINVAL;
> 
> Isn't it a plain old documented architectural requirement?

Yes, but it requires some explanation why it exists here instead of
counting on ECREATE.

What do you suggest?

BR, Jarkko

On 3/4/25 16:19, Jarkko Sakkinen wrote:
> On Tue, Mar 04, 2025 at 04:18:03PM -0800, Dave Hansen wrote:
>> On 3/4/25 16:06, Jarkko Sakkinen wrote:
>>> +	/*
>>> +	 * This is a micro-architectural requirement. ECREATE would detect this
>>> +	 * too without mentionable overhead but this check guarantees also that
>>> +	 * the space calculations for EPC and shmem allocations never overflow.
>>> +	 */
>>> +	if (!is_power_of_2(secs->size))
>>> +		return -EINVAL;
>> Isn't it a plain old documented architectural requirement?
> Yes, but it requires some explanation why it exists here instead of
> counting on ECREATE.
> 
> What do you suggest?

	/*
	 * ECREATE would detect this too, but checking here also ensures
	 * that the 'encl_size' calculations below can never overflow.
	 */

On Tue, Mar 04, 2025 at 04:30:21PM -0800, Dave Hansen wrote:
> On 3/4/25 16:19, Jarkko Sakkinen wrote:
> > On Tue, Mar 04, 2025 at 04:18:03PM -0800, Dave Hansen wrote:
> >> On 3/4/25 16:06, Jarkko Sakkinen wrote:
> >>> +	/*
> >>> +	 * This is a micro-architectural requirement. ECREATE would detect this
> >>> +	 * too without mentionable overhead but this check guarantees also that
> >>> +	 * the space calculations for EPC and shmem allocations never overflow.
> >>> +	 */
> >>> +	if (!is_power_of_2(secs->size))
> >>> +		return -EINVAL;
> >> Isn't it a plain old documented architectural requirement?
> > Yes, but it requires some explanation why it exists here instead of
> > counting on ECREATE.
> > 
> > What do you suggest?
> 
> 	/*
> 	 * ECREATE would detect this too, but checking here also ensures
> 	 * that the 'encl_size' calculations below can never overflow.
> 	 */

Looks reasonable to me!

BR, Jarkko

On Wed, Mar 05, 2025 at 02:06:02AM +0200, Jarkko Sakkinen wrote:
> The total size calculated for EPC can overflow u64 given the added up page
> for SECS.  Further, the total size calculated for shmem can overflow even
> when the EPC size stays within limits of u64, given that it adds the extra
> space for 128 byte PCMD structures (one for each page).
> 
> Address this by pre-evaluating the micro-architectural requirement of
> SGX: the address space size must be power of two. This is eventually
> checked up by ECREATE but the pre-check has the additional benefit of
> making sure that there is some space for additional data.
> 
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/linux-sgx/c87e01a0-e7dd-4749-a348-0980d3444f04@stanley.mountain/
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Cc: stable@vger.kernel.org # v5.11+
Fixes: 888d24911787 ("x86/sgx: Add SGX_IOC_ENCLAVE_CREATE")

BR, Jarkko