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.
