On Tue, Jun 03, 2025 at 10:03:31AM -0700, ross.philip...@oracle.com wrote: > > From: Krystian Hebel <krystian.he...@3mdeb.com> > > > > The tests validate that important parts of memory are protected against > > DMA attacks, including Xen and MBI. Modules can be tested later, when it > > is possible to report issues to a user before invoking TXT reset. > > > > TPM event log validation is temporarily disabled due to an issue with > > its allocation by bootloader (GRUB) which will need to be modified to > > address this. Ultimately event log will also have to be validated early > > as it is used immediately after these tests to hold MBI measurements. > > See larger comment in txt_verify_pmr_ranges(). > > > > Signed-off-by: Krystian Hebel <krystian.he...@3mdeb.com> > > Signed-off-by: Sergii Dmytruk <sergii.dmyt...@3mdeb.com> > > ---
> > +static inline int is_in_pmr(const struct txt_os_sinit_data *os_sinit, > > + uint64_t base, uint32_t size, int check_high) > > bool return val? Will change. > > + /* > > + * ACM checks that TXT heap and MLE memory is protected against DMA. > > We have > > + * to check if MBI and whole Xen memory is protected. The latter is > > done in > > + * case bootloader failed to set whole image as MLE and to make sure > > that > > + * both pre- and post-relocation code is protected. > > + */ > > + > > Is this the full list of entities that should be covered by PMRs? I am > thinking of entries in the SLR policy that should be covered. E.g. with > Linux we ensure setup_data entry blobs are covered before measuring. Xen's equivalent of setup_data is MBI which is checked below. Command-lines of Xen and modules are part of MBI as well. > > + /* Check if all of Xen before relocation is covered by PMR. */ > > + if ( !is_in_pmr(os_sinit, load_base_addr, xen_size, check_high_pmr) ) > > + txt_reset(SLAUNCH_ERROR_LO_PMR_MLE); > > + > > + /* Check if all of Xen after relocation is covered by PMR. */ > > + if ( load_base_addr != tgt_base_addr && > > + !is_in_pmr(os_sinit, tgt_base_addr, xen_size, check_high_pmr) ) > > + txt_reset(SLAUNCH_ERROR_LO_PMR_MLE); > > + > > + /* > > + * If present, check that MBI is covered by PMR. MBI starts with > > 'uint32_t > > + * total_size'. > > + */ > > + if ( info->boot_params_base != 0 && > > + !is_in_pmr(os_sinit, info->boot_params_base, > > + *(uint32_t *)(uintptr_t)info->boot_params_base, > > + check_high_pmr) ) > > + txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR); > > + /* Check if TPM event log (if present) is covered by PMR. */ > > + /* > > + * FIXME: currently commented out as GRUB allocates it in a hole > > between > > + * PMR and reserved RAM, due to 2MB resolution of PMR. There are no > > other > > + * easy-to-use DMA protection mechanisms that would allow to protect > > that > > + * part of memory. TPR (TXT DMA Protection Range) gives 1MB > > resolution, but > > + * it still wouldn't be enough. > > + * > > + * One possible solution would be for GRUB to allocate log at lower > > address, > > + * but this would further increase memory space fragmentation. Another > > + * option is to align PMR up instead of down, making PMR cover part of > > + * reserved region, but it is unclear what the consequences may be. > > The consequences depend on the firmware. The failure mode we used to see was > on some systems if the PMR covered certain areas marked as reserved, the > system will hang at boot. In this particular case, firmware was trying to > use an xHCI controller to get to the kb attached to use it at boot time. > When DMA to the host controller was blocked, the firmware was unhappy. We > have not seen this issue in a while and the current logic in the prologue > code just sets the upper bound to the highest RAM area below 4Gb which is > optimal. > > The most correct solution for PMRs is to read the VTd RMRR structures. These > can tell you what reserved regions should not be blocked like this (if any). > This will give more control over the best configuration for the PMRs and > what to avoid. This needs to be done in the prologue code and validated in > the DLME. > > And yea, TPR support too where available. > > Thanks > Ross I guess this needs checking whether it's still an issue. Regards
