linux-kernel - Re: [PATCH v39 13/24] x86/sgx: Add SGX_IOC_ENCLAVE_ADD

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <564152e4-2334-2c82-1a12-4c980b08a944@intel.com>
Date:   Mon, 19 Oct 2020 14:44:19 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>, x86@...nel.org,
        linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jethro Beekman <jethro@...tanix.com>,
        Haitao Huang <haitao.huang@...ux.intel.com>,
        Chunyang Hui <sanqian.hcy@...fin.com>,
        Jordan Hand <jorhand@...ux.microsoft.com>,
        Nathaniel McCallum <npmccallum@...hat.com>,
        Seth Moore <sethmo@...gle.com>,
        Darren Kenny <darren.kenny@...cle.com>,
        Suresh Siddha <suresh.b.siddha@...el.com>,
        akpm@...ux-foundation.org, andriy.shevchenko@...ux.intel.com,
        asapek@...gle.com, bp@...en8.de, cedric.xing@...el.com,
        chenalexchen@...gle.com, conradparker@...gle.com,
        cyhanish@...gle.com, haitao.huang@...el.com, kai.huang@...el.com,
        kai.svahn@...el.com, kmoy@...gle.com, ludloff@...gle.com,
        luto@...nel.org, nhorman@...hat.com, puiterwijk@...hat.com,
        rientjes@...gle.com, tglx@...utronix.de, yaozhangx@...gle.com,
        mikko.ylinen@...el.com
Subject: Re: [PATCH v39 13/24] x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES

On 10/19/20 2:15 PM, Sean Christopherson wrote:
>>>> Yeah...  Don't we need to do another access_ok() check here, if we
>>>> needed one above since we are moving away from addrp.src?
>>> I don't think so because the page is pinned with get_user_pages().
>> No, get_user_pages() is orthogonal.
>>
>> Looking at this again, you _might_ be OK since you validated addp.length
>> against encl->size.  But, it's all very convoluted and doesn't look very
>> organized or obviously right.
> The easiest fix would be to have the existing access_ok() check the entire
> range, no?  Or am I missing something obvious?

In general, I want the actual userspace access to be as close as
possible and 1:1 with the access_ok() checks.  That way, it's blatantly
obvious that the pointers have been checked.

*But* get_user_pages() has access_ok() checks inside of its
implementation, which makes sense.  *But*, that begs the question of
what the top-level one was doing in the first place.  Maybe it was just
superfluous.

Either way, it still doesn't explain what this is doing:

> +       ret = get_user_pages(src, 1, 0, &src_page, NULL);
> +       if (ret < 1)
> +               return -EFAULT;
> +
> +       pginfo.secs = (unsigned long)sgx_get_epc_addr(encl->secs.epc_page);
> +       pginfo.addr = SGX_ENCL_PAGE_ADDR(encl_page);
> +       pginfo.metadata = (unsigned long)secinfo;
> +       pginfo.contents = (unsigned long)kmap_atomic(src_page);
> +
> +       ret = __eadd(&pginfo, sgx_get_epc_addr(epc_page));
> +
> +       kunmap_atomic((void *)pginfo.contents);

I think the point is to create a stable kernel alias address for
'src_page' so that any mucking with the userspace mapping doesn't screw
up the __eadd() and any failures aren't due to reclaim or MADV_DONTNEED.

If this isn't even touching the userspace mapping, it didn't need
access_ok() in the first place.