chipsec integrity check

chipsec integrity check

[Healer64]

[-- Attachment #1: Type: text/plain, Size: 3711 bytes --]

I have been using chipsec as an integrity verification tool.  I know its not how it was intended to be used, but I'm not aware of any other tools that will do the kind of deep dive into BIOS and UEFI that chipsec does.  In theory any malware should leave some type of traces that would show up as changes in chipsec results.  The problem is that ordinary use may also make some changes, and I am having a hard time determining what types of changes should be expected from ordinary use.  I would appreciate any advice.

I have written some test scripts below:

#!/bin/bash
OUTPUT=/root/verify_certs.log
chipsec_util uefi var-read db d719b2cb-3d3a-4596-a3bc-dad00e67656f db.bin >> db.ascii
diff db.bin ./current/db.bin >> $OUTPUT
hexdump db.bin | diff - ./current/db.hex >> $OUTPUT
rm db.bin
rm db.ascii

#!/bin/bash
OUTPUT=/root/verify_efivars.log
chipsec_util uefi var-list
for x in `cat dir2`
do
sha256sum $x >> shasums.1
done
cat shasums.1 | sed s/\\/root\\/efi_variables.dir\\///g |  awk '{ print $2 , $1 }' | sort > shasums.tmp
rm shasums.1
diff shasums shasums.tmp >> $OUTPUT
diff efi_variables.lst ./current/efi_variables.lst >> $OUTPUT

#!/bin/bash
OUTPUT=/root/verify_chipsec
cd tmp
chipsec_util acpi list > acpi_list
chipsec_util acpi table APIC > acpi_table_APIC
chipsec_util acpi table BATB > acpi_table_BATB
chipsec_util acpi table BGRT > acpi_table_BGRT
chipsec_util acpi table CRAT > acpi_table_CRAT
chipsec_util acpi table DSDT > acpi_table_DSDT
chipsec_util acpi table FACP > acpi_table_FACP
chipsec_util acpi table FPDT > acpi_table_FPDT
chipsec_util acpi table HPET > acpi_table_HPET
chipsec_util acpi table MCFG > acpi_table_MCFG
chipsec_util acpi table MSDM > acpi_table_MSDM
chipsec_util acpi table SBST > acpi_table_SBST
chipsec_util acpi table SSDT > acpi_table_SSDT
chipsec_util acpi table TCPA > acpi_table_TCPA
chipsec_util acpi table TPM2 > acpi_table_TPM2
chipsec_util acpi table UEFI > acpi_table_UEFI
chipsec_util acpi table VFCT > acpi_table_VFCT
chipsec_util acpi table XSDT > acpi_table_XSDT
chipsec_util cmos dump > cmos_dump
chipsec_util ec dump > ec_dump
chipsec_util gdt > gdt
chipsec_util io list > io_list
chipsec_util iommu config GFXVTD > iommu_config_GFXVTD
chipsec_util iommu config VTD > iommu_config_VTD
chipsec_util iommu list > iommu_list
chipsec_util iommu status GFXVTD > iommu_status_GFXVTD
chipsec_util iommu status VTD > iommu_status_VTD
chipsec_util mmcfg > mmcfg
chipsec_util mmio dump DMIBAR > mmio_dump_DMIBAR
chipsec_util mmio dump GFXVTBAR > mmio_dump_GFXVTBAR
chipsec_util mmio dump GMADR > mmio_dump_GMADR
chipsec_util mmio dump GTTMMADR > mmio_dump_GTTMMADR
chipsec_util mmio dump HDABAR > mmio_dump_HDABAR
chipsec_util mmio dump HDBAR > mmio_dump_HDBAR
chipsec_util mmio dump MCHBAR > mmio_dump_MCHBAR
chipsec_util mmio dump MMCFG > mmio_dump_MMCFG
chipsec_util mmio dump PXPEPBAR > mmio_dump_PXPEPBAR
chipsec_util mmio dump RCBA > mmio_dump_RCBA
chipsec_util mmio dump RCBA_RTC > mmio_dump_RCBA_RTC
chipsec_util mmio dump SPIBAR > mmio_dump_SPIBAR
chipsec_util mmio dump VTBAR > mmio_dump_VTBAR
chipsec_util mmio list > mmio_list
chipsec_util pci dump > pci_dump
chipsec_util pci enumerate > pci_enumerate
chipsec_util pci xrom > pci_xrom
chipsec_util platform > chipsec_platform
chipsec_util spi info > spi_info
chipsec_util ucode id > ucode_id
for x in `cat testfiles`
do
echo -e "#####  $x  #####\\n" >> $OUTPUT
diff $x /root/current/$x >> $OUTPUT
grep -v elapsed $OUTPUT > $OUTPUT.log
rm $OUTPUT
done

The output log files are here:
https://pastebin.com/wV4wdPeW
https://pastebin.com/nBa3BwLb

Sent with [ProtonMail](https://protonmail.com) Secure Email.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5423 bytes --]

Re: chipsec integrity check

[cod]

[-- Attachment #1: Type: text/plain, Size: 4337 bytes --]

If a "malware" is inside your bios, you need to enumerate files inside
every EFI firmware volumes checking hash files with a backup copy of
firmware (or a copy from vendor)

On Tue, Nov 28, 2017 at 12:07 AM, Healer64 <Healer64@protonmail.com> wrote:

> I have been using chipsec as an integrity verification tool.  I know its
> not how it was intended to be used, but I'm not aware of any other tools
> that will do the kind of deep dive into BIOS and UEFI that chipsec does.
> In theory any malware should leave some type of traces that would show up
> as changes in chipsec results.  The problem is that ordinary use may also
> make some changes, and I am having a hard time determining what types of
> changes should be expected from ordinary use.  I would appreciate any
> advice.
>
> I have written some test scripts below:
>
> #!/bin/bash
> OUTPUT=/root/verify_certs.log
> chipsec_util uefi var-read db d719b2cb-3d3a-4596-a3bc-dad00e67656f db.bin
> >> db.ascii
> diff db.bin ./current/db.bin >> $OUTPUT
> hexdump db.bin | diff - ./current/db.hex >> $OUTPUT
> rm db.bin
> rm db.ascii
>
>
> #!/bin/bash
> OUTPUT=/root/verify_efivars.log
> chipsec_util uefi var-list
> for x in `cat dir2`
> do
> sha256sum $x >> shasums.1
> done
> cat shasums.1 | sed s/\\/root\\/efi_variables.dir\\///g |  awk '{ print
> $2 , $1 }' | sort > shasums.tmp
> rm shasums.1
> diff shasums shasums.tmp >> $OUTPUT
> diff efi_variables.lst ./current/efi_variables.lst >> $OUTPUT
>
>
> #!/bin/bash
> OUTPUT=/root/verify_chipsec
> cd tmp
> chipsec_util acpi list > acpi_list
> chipsec_util acpi table APIC > acpi_table_APIC
> chipsec_util acpi table BATB > acpi_table_BATB
> chipsec_util acpi table BGRT > acpi_table_BGRT
> chipsec_util acpi table CRAT > acpi_table_CRAT
> chipsec_util acpi table DSDT > acpi_table_DSDT
> chipsec_util acpi table FACP > acpi_table_FACP
> chipsec_util acpi table FPDT > acpi_table_FPDT
> chipsec_util acpi table HPET > acpi_table_HPET
> chipsec_util acpi table MCFG > acpi_table_MCFG
> chipsec_util acpi table MSDM > acpi_table_MSDM
> chipsec_util acpi table SBST > acpi_table_SBST
> chipsec_util acpi table SSDT > acpi_table_SSDT
> chipsec_util acpi table TCPA > acpi_table_TCPA
> chipsec_util acpi table TPM2 > acpi_table_TPM2
> chipsec_util acpi table UEFI > acpi_table_UEFI
> chipsec_util acpi table VFCT > acpi_table_VFCT
> chipsec_util acpi table XSDT > acpi_table_XSDT
> chipsec_util cmos dump > cmos_dump
> chipsec_util ec dump > ec_dump
> chipsec_util gdt > gdt
> chipsec_util io list > io_list
> chipsec_util iommu config GFXVTD > iommu_config_GFXVTD
> chipsec_util iommu config VTD > iommu_config_VTD
> chipsec_util iommu list > iommu_list
> chipsec_util iommu status GFXVTD > iommu_status_GFXVTD
> chipsec_util iommu status VTD > iommu_status_VTD
> chipsec_util mmcfg > mmcfg
> chipsec_util mmio dump DMIBAR > mmio_dump_DMIBAR
> chipsec_util mmio dump GFXVTBAR > mmio_dump_GFXVTBAR
> chipsec_util mmio dump GMADR > mmio_dump_GMADR
> chipsec_util mmio dump GTTMMADR > mmio_dump_GTTMMADR
> chipsec_util mmio dump HDABAR > mmio_dump_HDABAR
> chipsec_util mmio dump HDBAR > mmio_dump_HDBAR
> chipsec_util mmio dump MCHBAR > mmio_dump_MCHBAR
> chipsec_util mmio dump MMCFG > mmio_dump_MMCFG
> chipsec_util mmio dump PXPEPBAR > mmio_dump_PXPEPBAR
> chipsec_util mmio dump RCBA > mmio_dump_RCBA
> chipsec_util mmio dump RCBA_RTC > mmio_dump_RCBA_RTC
> chipsec_util mmio dump SPIBAR > mmio_dump_SPIBAR
> chipsec_util mmio dump VTBAR > mmio_dump_VTBAR
> chipsec_util mmio list > mmio_list
> chipsec_util pci dump > pci_dump
> chipsec_util pci enumerate > pci_enumerate
> chipsec_util pci xrom > pci_xrom
> chipsec_util platform > chipsec_platform
> chipsec_util spi info > spi_info
> chipsec_util ucode id > ucode_id
> for x in `cat testfiles`
> do
> echo -e "#####  $x  #####\\n" >> $OUTPUT
> diff $x /root/current/$x >> $OUTPUT
> grep -v elapsed $OUTPUT > $OUTPUT.log
> rm $OUTPUT
> done
>
>
> The output log files are here:
> https://pastebin.com/wV4wdPeW
> https://pastebin.com/nBa3BwLb
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
>
> _______________________________________________
> chipsec mailing list
> chipsec(a)lists.01.org
> https://lists.01.org/mailman/listinfo/chipsec
>
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 6437 bytes --]

Re: chipsec integrity check

[Bjorge, Erik C]

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

The IOMMU values may be wrong because we are looking at the wrong locations in MMIO space or other platform dependencies.  If you can send us the verbose log file (include the -v parameter) we should be able to see all of the register reads.  This will allow us to determine if it is a platform register layout.

The whitelist failure may be expected if you are having issues reading the SPI image on your platform.  I would not expect that no changes would be found though.  I would expect failures when reading the SPI image or verifying the whitelist.

Thanks,
-Erik

From: Healer64 [mailto:Healer64(a)protonmail.com]
Sent: Friday, December 15, 2017 8:32 AM
To: Bjorge, Erik C <erik.c.bjorge@intel.com>
Cc: chipsec(a)lists.01.org
Subject: RE: [chipsec] chipsec integrity check


Thanks, Erik that helps a great deal. I feel I understand much better what is happening in the hardware. I do still wonder about some of the flags that changed in the iommu vtd and gfx vtd. For example
 [04] RWBF             = 0 << Required Write-Buffer Flushing

Which changed from 1 to 0 and back to 1 again. Would something like that indicate a configuration change or a misread?
https://pastebin.com/KLea3gVf


I did use the chipsec whitelist function using the known good bios from the manufacturer and no changes to embedded executables were flagged, but just as a test I ran it again using a different version of the bios firmware than what is currently in use. Again no changes were found. I thought that was interesting. Maybe that version of the firmware didn't include an changes to embedded executables?

-------- Original Message --------
Subject: RE: [chipsec] chipsec integrity check
Local Time: December 11, 2017 1:11 PM
UTC Time: December 11, 2017 7:11 PM
From: erik.c.bjorge(a)intel.com<mailto:erik.c.bjorge@intel.com>
To: Healer64 <Healer64(a)protonmail.com<mailto:Healer64@protonmail.com>>
chipsec(a)lists.01.org<mailto:chipsec@lists.01.org> <chipsec(a)lists.01.org<mailto:chipsec@lists.01.org>>


The fact that this is an AMD system will cause issues with the chipsec results.  To properly run chipsec on a system you need to have a valid configuration file for the platform.  Even when using the -i flag a number of assumptions are made about the register layout of the platform.  To correctly support an AMD system a number of modifications would need to be made to chipsec as well as a configuration would need to be provided for that specific platform.  Because of these issues most hardware register accesses will be wrong.  You will need to ignore the MMIO register dumps and base addresses.

With that said some information is still valid but may still need some additional filtering.

UEFI Variable Data


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 9643 bytes --]

Re: chipsec integrity check

[Healer64]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

Thanks, Erik that helps a great deal. I feel I understand much better what is happening in the hardware. I do still wonder about some of the flags that changed in the iommu vtd and gfx vtd. For example
 [04] RWBF             = 0 << Required Write-Buffer Flushing

Which changed from 1 to 0 and back to 1 again. Would something like that indicate a configuration change or a misread?
https://pastebin.com/KLea3gVf

I did use the chipsec whitelist function using the known good bios from the manufacturer and no changes to embedded executables were flagged, but just as a test I ran it again using a different version of the bios firmware than what is currently in use. Again no changes were found. I thought that was interesting. Maybe that version of the firmware didn't include an changes to embedded executables?

> -------- Original Message --------
> Subject: RE: [chipsec] chipsec integrity check
> Local Time: December 11, 2017 1:11 PM
> UTC Time: December 11, 2017 7:11 PM
> From: erik.c.bjorge(a)intel.com
> To: Healer64 <Healer64@protonmail.com>
> chipsec(a)lists.01.org <chipsec@lists.01.org>
>
> The fact that this is an AMD system will cause issues with the chipsec results.  To properly run chipsec on a system you need to have a valid configuration file for the platform.  Even when using the -i flag a number of assumptions are made about the register layout of the platform.  To correctly support an AMD system a number of modifications would need to be made to chipsec as well as a configuration would need to be provided for that specific platform.  Because of these issues most hardware register accesses will be wrong.  You will need to ignore the MMIO register dumps and base addresses.
>
> With that said some information is still valid but may still need some additional filtering.
>
> UEFI Variable Data

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7497 bytes --]

Re: chipsec integrity check

[Bjorge, Erik C]

[-- Attachment #1: Type: text/plain, Size: 4569 bytes --]

The fact that this is an AMD system will cause issues with the chipsec results.  To properly run chipsec on a system you need to have a valid configuration file for the platform.  Even when using the -i flag a number of assumptions are made about the register layout of the platform.  To correctly support an AMD system a number of modifications would need to be made to chipsec as well as a configuration would need to be provided for that specific platform.  Because of these issues most hardware register accesses will be wrong.  You will need to ignore the MMIO register dumps and base addresses.

With that said some information is still valid but may still need some additional filtering.

UEFI Variable Data:
-TrEEPhysicalPresence - TPM2 related
-SMBIOSLOG000 - Looks like a SMBIOS event was logged.
-SctCsmMemoryMapVariable - This looks to be related to legacy OS support (Compatibility Support Module) and the memory map that was used to boot a legacy OS.  This is normally needed for S4 resume to keep the map consistent.
-ErrOutDev - Console redirection similar to stderr used by the UEFI Shell or UEFI boot loader.

PCI Dump:
Changes in these devices may be due to status registers or different device states.  You would have to have information about the device to handle command and status registers as these change during runtime.  All of these changes are outside the first 0x40 bytes so they will be device specific.

I hope this helps some.

Thanks,
-Erik

From: Healer64 [mailto:Healer64(a)protonmail.com]
Sent: Friday, December 1, 2017 11:33 AM
To: Bjorge, Erik C <erik.c.bjorge@intel.com>
Cc: chipsec(a)lists.01.org
Subject: RE: [chipsec] chipsec integrity check

Of course.  I did my own analysis which may save you some effort.

Of the efi variables which had changed from the baseline, very few additional changes were seen after a reboot into my normal OS then a reboot into the chipsec usb.  Only the ErrOutDev and SctCsmMemoryMapVariable changed and SctCsmMemoryMapVariable is a new variable not part of the baseline.

Here is a list of other changes that occurred with just the reboots mentioned above:
ec dump = changed
iommu config GFXVTD = BAR value changed, flags changed back to baseline
iommu config VTD = BAR value changed, some flags changed back to baseline but not all
iommu status GFXVTD = returned to baseline
iommu status VTD = changed
mmio dump DMIBAR = changed
mmio dump GFXVTBAR = returned to baseline except mmio register range
mmio dump GMADR = changed
mmio dump GTTMADR = changed
mmio dump HDABAR = changed
mmio dump HDBAR = no change
mmio dump MCHBAR = changed
mmio dump PXPEPBAR = changed
mmio dump VTBAR = changed
mmio list = changed
pci dump = changed

Also when doing the iommu dump config GFXVTD I do get errors from chipsec. I couldn't capture them.  They don't show up in the log and even redirecting standard out and standard error doesn't catch them, but I was able to copy one from the screen.
ioremap error for 0xde0c1000-0xdec2000, requested 0x10, got 0x0

Also it occured to me I should mention this is an AMD system and chipsec complains about an unsupported platform.  Most of the functions appear to work just fine even so, but it is possible it could have some affect on the results.




Sent with ProtonMail<https://protonmail.com> Secure Email.

-------- Original Message --------
Subject: RE: [chipsec] chipsec integrity check
Local Time: December 1, 2017 12:27 AM
UTC Time: December 1, 2017 12:27 AM
From: erik.c.bjorge(a)intel.com<mailto:erik.c.bjorge@intel.com>
To: Healer64 <Healer64(a)protonmail.com<mailto:Healer64@protonmail.com>>
chipsec(a)lists.01.org<mailto:chipsec@lists.01.org> <chipsec(a)lists.01.org<mailto:chipsec@lists.01.org>>


Thanks for sending the new logs.  Give us a day or so to look them over and see if we can find anything new.

Thanks,
-Erik

From: chipsec [mailto:chipsec-bounces(a)lists.01.org] On Behalf Of Healer64
Sent: Thursday, November 30, 2017 4:23 PM
To: Bjorge, Erik C <erik.c.bjorge(a)intel.com<mailto:erik.c.bjorge@intel.com>>
Cc: chipsec(a)lists.01.org<mailto:chipsec@lists.01.org>
Subject: Re: [chipsec] chipsec integrity check

After a reboot, I ran the tests again.  New log is here:
https://pastebin.com/XCHrYYJF
https://pastebin.com/NiYcnxGG

Just for kicks I did a diff of the 2 instances.

https://pastebin.com/KLea3gVf



Some of the BAR values have changed again.  No longer 0.  That seems odd.

Sent with ProtonMail<https://protonmail.com> Secure Email.




[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 15667 bytes --]

Re: chipsec integrity check

[Healer64]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

Of course.  I did my own analysis which may save you some effort.

Of the efi variables which had changed from the baseline, very few additional changes were seen after a reboot into my normal OS then a reboot into the chipsec usb.  Only the ErrOutDev and SctCsmMemoryMapVariable changed and SctCsmMemoryMapVariable is a new variable not part of the baseline.

Here is a list of other changes that occurred with just the reboots mentioned above:
ec dump = changed
iommu config GFXVTD = BAR value changed, flags changed back to baseline
iommu config VTD = BAR value changed, some flags changed back to baseline but not all
iommu status GFXVTD = returned to baseline
iommu status VTD = changed
mmio dump DMIBAR = changed
mmio dump GFXVTBAR = returned to baseline except mmio register range
mmio dump GMADR = changed
mmio dump GTTMADR = changed
mmio dump HDABAR = changed
mmio dump HDBAR = no change
mmio dump MCHBAR = changed
mmio dump PXPEPBAR = changed
mmio dump VTBAR = changed
mmio list = changed
pci dump = changed

Also when doing the iommu dump config GFXVTD I do get errors from chipsec. I couldn't capture them.  They don't show up in the log and even redirecting standard out and standard error doesn't catch them, but I was able to copy one from the screen.
ioremap error for 0xde0c1000-0xdec2000, requested 0x10, got 0x0

Also it occured to me I should mention this is an AMD system and chipsec complains about an unsupported platform.  Most of the functions appear to work just fine even so, but it is possible it could have some affect on the results.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

> -------- Original Message --------
> Subject: RE: [chipsec] chipsec integrity check
> Local Time: December 1, 2017 12:27 AM
> UTC Time: December 1, 2017 12:27 AM
> From: erik.c.bjorge(a)intel.com
> To: Healer64 <Healer64@protonmail.com>
> chipsec(a)lists.01.org <chipsec@lists.01.org>
>
> Thanks for sending the new logs.  Give us a day or so to look them over and see if we can find anything new.
>
> Thanks,
>
> -Erik
>
> []From: chipsec [mailto:chipsec-bounces(a)lists.01.org] On Behalf Of Healer64
> Sent: Thursday, November 30, 2017 4:23 PM
> To: Bjorge, Erik C <erik.c.bjorge@intel.com>
> Cc: chipsec(a)lists.01.org
> Subject: Re: [chipsec] chipsec integrity check
>
> After a reboot, I ran the tests again.  New log is here:
>
> https://pastebin.com/XCHrYYJF
>
> https://pastebin.com/NiYcnxGG
>
> Just for kicks I did a diff of the 2 instances.
>
> https://pastebin.com/KLea3gVf
>
> Some of the BAR values have changed again.  No longer 0.  That seems odd.
>
>>
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 6232 bytes --]

Re: chipsec integrity check

[Bjorge, Erik C]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Thanks for sending the new logs.  Give us a day or so to look them over and see if we can find anything new.

Thanks,
-Erik

From: chipsec [mailto:chipsec-bounces(a)lists.01.org] On Behalf Of Healer64
Sent: Thursday, November 30, 2017 4:23 PM
To: Bjorge, Erik C <erik.c.bjorge@intel.com>
Cc: chipsec(a)lists.01.org
Subject: Re: [chipsec] chipsec integrity check

After a reboot, I ran the tests again.  New log is here:
https://pastebin.com/XCHrYYJF
https://pastebin.com/NiYcnxGG

Just for kicks I did a diff of the 2 instances.

https://pastebin.com/KLea3gVf



Some of the BAR values have changed again.  No longer 0.  That seems odd.

Sent with ProtonMail<https://protonmail.com> Secure Email.



[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4800 bytes --]

Re: chipsec integrity check

[Healer64]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

After a reboot, I ran the tests again.  New log is here:
https://pastebin.com/XCHrYYJF
https://pastebin.com/NiYcnxGG

Just for kicks I did a diff of the 2 instances.

https://pastebin.com/KLea3gVf

Some of the BAR values have changed again.  No longer 0.  That seems odd.

>
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1059 bytes --]

Re: chipsec integrity check

[Healer64]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

The whitelisting looks very helpful. My original plan was to dump the complete firmware image for integrity checking but I was unable to get a good read due to some read locked areas even an external programmer couldn't read. So this makes for a good alternative.

Retesting after a reboot is also a good idea. I will try that and compare results. I didn't realize so much of the firmware was dynamic. I thought taking a single known good image would be enough.

The ACPI information also looks quite useful. I have played with fwts some but it is very complicated. Since the ACPI tables change frequently perhaps I should drop them from the test script.

To answer some of your questions, the test results were generated with version 1.3.0. I have built chipsec on a usb drive running centos 7.   Because of this, yes, I boot from different media between tests, hdd and usb.

The only changes between tests was normal use, ie reboots, os updates, software use. No suspect software has been installed, though finding out the python pypi repository had been compromised did give me a few worries. The reason for the test was a bios info screen popped up on boot which I found unusual because it normally only does that following a firmware update and I had not done one.

A few things stand out. You mention MMIO and IOMMU. There are certainly a lot of changes there including some flags that are switched between 0 and 1 so it appears the configuration has changed. I leave the BIOS in a static "secure" configuration. It was in this configuration for both runs, though I do have to enter the bios to enable usb boot to run chipsec, then after the run I disable it again. It seems that shouldn't matter but I can't be certain.  You mention some devices were reinitialized. Is this expected behavior? No firmware updates have taken place.

 Also I note pci dump has changed. There have been no hardware changes other than usb devices plugged and unplugged.

You mention the cmos changes are related to real time clock but what about ec dump changes?

Some of the efi variables stand out as well.
TrEEPhysicalPresence
SMBIOSELOG000
System
SctCsmMemoryMapVariable

Thanks greatly for your help and references. To a non specialist the complexity can seem overwhelming.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4963 bytes --]