[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and accessors for TXT registers and heap
On 13/05/2025 6:05 pm, Sergii Dmytruk wrote: > diff --git a/xen/arch/x86/include/asm/intel-txt.h > b/xen/arch/x86/include/asm/intel-txt.h > new file mode 100644 > index 0000000000..07be43f557 > --- /dev/null > +++ b/xen/arch/x86/include/asm/intel-txt.h > @@ -0,0 +1,277 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > + Please have at least a one-liner introduction to what TXT is. Is there a stable URL for the TXT spec? (I can't spot an obvious one, googling around) > +#ifndef ASM__X86__INTEL_TXT_H > +#define ASM__X86__INTEL_TXT_H I realise this is what the documentation currently says, but we're just in the process of finalising some changes. Please make this X86_INTEL_TXT_H. > + > +/* > + * TXT configuration registers (offsets from TXT_{PUB, > PRIV}_CONFIG_REGS_BASE) > + */ > +#define TXT_PUB_CONFIG_REGS_BASE 0xfed30000U > +#define TXT_PRIV_CONFIG_REGS_BASE 0xfed20000U > + > +/* > + * The same set of registers is exposed twice (with different permissions) > and > + * they are allocated continuously with page alignment. > + */ > +#define NR_TXT_CONFIG_SIZE \ > + (TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE) Commit message needs to note that you're swapping NR_TXT_CONFIG_PAGES for NR_TXT_CONFIG_SIZE, hence the change in logic in tboot_protect_mem_regions(). > +#ifndef __ASSEMBLY__ > + > +/* Need to differentiate between pre- and post paging enabled. */ > +#ifdef __EARLY_SLAUNCH__ > +#include <xen/macros.h> > +#define _txt(x) _p(x) > +#else > +#include <xen/types.h> > +#include <asm/page.h> // __va() > +#define _txt(x) __va(x) > +#endif I have to admit that I'm rather suspicious of this, but I'm going to have to wait to see later patches before making a suggestion. (I highly suspect we'll want a fixmap entry). > + > +/* > + * Always use private space as some of registers are either read-only or not > + * present in public space. > + */ > +static inline uint64_t read_txt_reg(int reg_no) unsigned int reg I'd be tempted to name it simply txt_read(). I don't think the extra "_reg" is a helpful suffix, and it makes the APIs consistent with txt_reset(). But I expect others may have opinions here. > +{ > + volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no); > + return *reg; > +} > + > +static inline void write_txt_reg(int reg_no, uint64_t val) > +{ > + volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no); > + *reg = val; > + /* This serves as TXT register barrier */ > + (void)read_txt_reg(TXTCR_ESTS); What is this barrier for? It's not for anything in the CPU side of things, because UC accesses are strictly ordered. I presume it's for LPC bus ordering then, but making every write be a write/read pair seems very expensive. > +} > + > +static inline void txt_reset(uint32_t error) > +{ > + write_txt_reg(TXTCR_ERRORCODE, error); > + write_txt_reg(TXTCR_CMD_NO_SECRETS, 1); > + write_txt_reg(TXTCR_CMD_UNLOCK_MEM_CONFIG, 1); > + write_txt_reg(TXTCR_CMD_RESET, 1); > + while (1); for ( ;; ) cpu_relax(); please. Will the write to CMD_RESET try to initiate a platform reset, or will we just hang here forever? > +/* > + * Functions to extract data from the Intel TXT Heap Memory. The layout > + * of the heap is as follows: > + * +------------------------------------+ > + * | Size of Bios Data table (uint64_t) | > + * +------------------------------------+ > + * | Bios Data table | > + * +------------------------------------+ > + * | Size of OS MLE table (uint64_t) | > + * +------------------------------------+ > + * | OS MLE table | > + * +-------------------------------- + > + * | Size of OS SINIT table (uint64_t) | > + * +------------------------------------+ > + * | OS SINIT table | > + * +------------------------------------+ > + * | Size of SINIT MLE table (uint64_t) | > + * +------------------------------------+ > + * | SINIT MLE table | > + * +------------------------------------+ > + * > + * NOTE: the table size fields include the 8 byte size field itself. > + */ > +static inline uint64_t txt_bios_data_size(void *heap) > +{ > + return *((uint64_t *)heap) - sizeof(uint64_t); > +} This is quite horrible, but I presume this is as specified by TXT? To confirm, it's a tightly packed data structure where each of the 4 blobs is variable size? Are there any alignment requirements on the table sizes? I suspect not, given the __packed attributes. > diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c > index d5db60d335..8a573d8c79 100644 > --- a/xen/arch/x86/tboot.c > +++ b/xen/arch/x86/tboot.c > @@ -15,6 +15,7 @@ > #include <asm/tboot.h> > #include <asm/setup.h> > #include <asm/trampoline.h> > +#include <asm/intel-txt.h> > > #include <crypto/vmac.h> I'll send a prep patch to fix tboot.c, but we're trying to keep includes sorted (for sanity of backports). ~Andrew
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |