• Dave Hansen's avatar
    x86/sgx: Clarify 'laundry_list' locking · 67655b57
    Dave Hansen authored
    Short Version:
    
    The SGX section->laundry_list structure is effectively thread-local, but
    declared next to some shared structures. Its semantics are clear as mud.
    Fix that. No functional changes. Compile tested only.
    
    Long Version:
    
    The SGX hardware keeps per-page metadata. This can provide things like
    permissions, integrity and replay protection. It also prevents things
    like having an enclave page mapped multiple times or shared between
    enclaves.
    
    But, that presents a problem for kexec()'d kernels (or any other kernel
    that does not run immediately after a hardware reset). This is because
    the last kernel may have been rude and forgotten to reset pages, which
    would trigger the "shared page" sanity check.
    
    To fix this, the SGX code "launders" the pages by running the EREMOVE
    instruction on all pages at boot. This is slow and can take a long
    time, so it is performed off in the SGX-specific ksgxd instead of being
    synchronous at boot. The init code hands the list of pages to launder in
    a per-SGX-section list: ->laundry_list. The only code to touch this list
    is the init code and ksgxd. This means that no locking is necessary for
    ->laundry_list.
    
    However, a lock is required for section->page_list, which is accessed
    while creating enclaves and by ksgxd. This lock (section->lock) is
    acquired by ksgxd while also processing ->laundry_list. It is easy to
    confuse the purpose of the locking as being for ->laundry_list and
    ->page_list.
    
    Rename ->laundry_list to ->init_laundry_list to make it clear that this
    is not normally used at runtime. Also add some comments clarifying the
    locking, and reorganize 'sgx_epc_section' to put 'lock' near the things
    it protects.
    
    Note: init_laundry_list is 128 bytes of wasted space at runtime. It
    could theoretically be dynamically allocated and then freed after
    the laundering process. But it would take nearly 128 bytes of extra
    instructions to do that.
    Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20201116222531.4834-1-dave.hansen@intel.com
    67655b57
main.c 17.5 KB