linux-kernel - Re: [PATCH v2 4/6] selftests/sgx: Add SGX selftest augment_via_eaccept

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YxQntXMQfEZ/kZQT@kernel.org>
Date:   Sun, 4 Sep 2022 07:21:09 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Reinette Chatre <reinette.chatre@...el.com>
Cc:     linux-sgx@...r.kernel.org,
        Haitao Huang <haitao.huang@...ux.intel.com>,
        Vijay Dhanraj <vijay.dhanraj@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        Shuah Khan <shuah@...nel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 4/6] selftests/sgx: Add SGX selftest
 augment_via_eaccept_long

On Sun, Sep 04, 2022 at 07:02:08AM +0300, Jarkko Sakkinen wrote:
> On Fri, Sep 02, 2022 at 01:22:59AM +0300, Jarkko Sakkinen wrote:
> > > Is this test passing on your system? This version is missing the change to
> > > mrenclave_ecreate() that causes SGX_IOC_ENCLAVE_INIT to fail when I try it out.
> > 
> > I *did* get a pass in my test machine. Hmm... I'll check if
> > the kernel tree was out-of-sync, which could be the reason.
> > 
> > I do not compile kernel on that machine but have the kernel
> > tree for running selftests. So there is a possiblity for
> > a human error. Thanks for pointing this out.
> 
> Apparently, v1 and v2 break the encl->src_size calculation:
> the dynamic heap size is not added.
> 
> So, in order to revert sigstruct change:
> 
> diff --git a/tools/testing/selftests/sgx/load.c b/tools/testing/selftests/sgx/load.c
> index 47b2786d6a77..0e4e12e1e3eb 100644
> --- a/tools/testing/selftests/sgx/load.c
> +++ b/tools/testing/selftests/sgx/load.c
> @@ -172,7 +172,7 @@ uint64_t encl_get_entry(struct encl *encl, const char *symbol)
>  }
> 
>  bool encl_load(const char *path, struct encl *encl, unsigned long heap_size,
> -              unsigned long edmm_size)
> +              unsigned long dynamic_heap_size)
>  {
>         const char device_path[] = "/dev/sgx_enclave";
>         struct encl_segment *seg;
> @@ -299,9 +299,9 @@ bool encl_load(const char *path, struct encl *encl, unsigned long heap_size,
>         if (seg->src == MAP_FAILED)
>                 goto err;
> 
> -       encl->src_size = encl->segment_tbl[j].offset + encl->segment_tbl[j].size;
> +       encl->src_size = encl->segment_tbl[j].offset + encl->segment_tbl[j].size + dynamic_heap_size;
> 
> -       for (encl->encl_size = 4096; encl->encl_size < encl->src_size + edmm_size;)
> +       for (encl->encl_size = 4096; encl->encl_size < encl->src_size;)
>                 encl->encl_size <<= 1;

Actually, it is correct after all how Vijay changed it. We should use
the final pre-calculated enclave address range in sigstruct.c. It's the
re-calculation of that in sigstruct is a reminiscent of it being a
separate command-line utility, instead of calculating the sigstruct
on-fly. I.e. there has been sane reasons why it has been like that.

BR, Jarkko