linux/tools/testing/selftests/sgx/defines.h

82 lines
1.5 KiB
C
Raw Permalink Normal View History

/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright(c) 2016-20 Intel Corporation.
*/
#ifndef DEFINES_H
#define DEFINES_H
#include <stdint.h>
#define PAGE_SIZE 4096
#define PAGE_MASK (~(PAGE_SIZE - 1))
#define __aligned(x) __attribute__((__aligned__(x)))
#define __packed __attribute__((packed))
#define __used __attribute__((used))
#define __section(x)__attribute__((__section__(x)))
#include "../../../../arch/x86/include/asm/sgx.h"
#include "../../../../arch/x86/include/asm/enclu.h"
#include "../../../../arch/x86/include/uapi/asm/sgx.h"
enum encl_op_type {
ENCL_OP_PUT_TO_BUFFER,
ENCL_OP_GET_FROM_BUFFER,
ENCL_OP_PUT_TO_ADDRESS,
ENCL_OP_GET_FROM_ADDRESS,
ENCL_OP_NOP,
selftests/sgx: Add test for EPCM permission changes EPCM permission changes could be made from within (to relax permissions) or out (to restrict permissions) the enclave. Kernel support is needed when permissions are restricted to be able to call the privileged ENCLS[EMODPR] instruction. EPCM permissions can be relaxed via ENCLU[EMODPE] from within the enclave but the enclave still depends on the kernel to install PTEs with the needed permissions. Add a test that exercises a few of the enclave page permission flows: 1) Test starts with a RW (from enclave and kernel perspective) enclave page that is mapped via a RW VMA. 2) Use the SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS ioctl() to restrict the enclave (EPCM) page permissions to read-only. 3) Run ENCLU[EACCEPT] from within the enclave to accept the new page permissions. 4) Attempt to write to the enclave page from within the enclave - this should fail with a page fault on the EPCM permissions since the page table entry continues to allow RW access. 5) Restore EPCM permissions to RW by running ENCLU[EMODPE] from within the enclave. 6) Attempt to write to the enclave page from within the enclave - this should succeed since both EPCM and PTE permissions allow this access. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/2617bf2b2d1e27ca1d0096e1192ae5896baf3f80.1652137848.git.reinette.chatre@intel.com
2022-05-10 11:08:58 -07:00
ENCL_OP_EACCEPT,
ENCL_OP_EMODPE,
ENCL_OP_INIT_TCS_PAGE,
ENCL_OP_MAX,
};
struct encl_op_header {
uint64_t type;
};
struct encl_op_put_to_buf {
struct encl_op_header header;
uint64_t value;
};
struct encl_op_get_from_buf {
struct encl_op_header header;
uint64_t value;
};
struct encl_op_put_to_addr {
struct encl_op_header header;
uint64_t value;
uint64_t addr;
};
struct encl_op_get_from_addr {
struct encl_op_header header;
uint64_t value;
uint64_t addr;
};
selftests/sgx: Add test for EPCM permission changes EPCM permission changes could be made from within (to relax permissions) or out (to restrict permissions) the enclave. Kernel support is needed when permissions are restricted to be able to call the privileged ENCLS[EMODPR] instruction. EPCM permissions can be relaxed via ENCLU[EMODPE] from within the enclave but the enclave still depends on the kernel to install PTEs with the needed permissions. Add a test that exercises a few of the enclave page permission flows: 1) Test starts with a RW (from enclave and kernel perspective) enclave page that is mapped via a RW VMA. 2) Use the SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS ioctl() to restrict the enclave (EPCM) page permissions to read-only. 3) Run ENCLU[EACCEPT] from within the enclave to accept the new page permissions. 4) Attempt to write to the enclave page from within the enclave - this should fail with a page fault on the EPCM permissions since the page table entry continues to allow RW access. 5) Restore EPCM permissions to RW by running ENCLU[EMODPE] from within the enclave. 6) Attempt to write to the enclave page from within the enclave - this should succeed since both EPCM and PTE permissions allow this access. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/2617bf2b2d1e27ca1d0096e1192ae5896baf3f80.1652137848.git.reinette.chatre@intel.com
2022-05-10 11:08:58 -07:00
struct encl_op_eaccept {
struct encl_op_header header;
uint64_t epc_addr;
uint64_t flags;
uint64_t ret;
};
struct encl_op_emodpe {
struct encl_op_header header;
uint64_t epc_addr;
uint64_t flags;
};
struct encl_op_init_tcs_page {
struct encl_op_header header;
uint64_t tcs_page;
uint64_t ssa;
uint64_t entry;
};
#endif /* DEFINES_H */