oe-chipsec.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Bjorge, Erik C <erik.c.bjorge@intel.com>
To: chipsec@lists.01.org
Subject: Re: chipsec integrity check
Date: Mon, 11 Dec 2017 19:11:59 +0000	[thread overview]
Message-ID: <7FE3244EBB31F1449E4EC79CFE44E3F4A4C847D5@ORSMSX108.amr.corp.intel.com> (raw)
In-Reply-To: <LmNSBwrulsyeqM_NduX5YaqNxORrJwYyqlSENBczt5C-h38k5GJ875sS5nqSKH9b1Lk0Wei0dltgfY_GhmIQA1rJ_hHiGDgP6b1iyGCg9Co=@protonmail.com>

[-- 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 --]

  reply	other threads:[~2017-12-11 19:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <81566ee3ec07486cb8aa6d4bea467028@fmsmsx106.amr.corp.intel.com>
2017-12-01  0:27 ` chipsec integrity check Bjorge, Erik C
2017-12-01 19:32   ` Healer64
2017-12-11 19:11     ` Bjorge, Erik C [this message]
2017-12-15 16:32       ` Healer64
2017-12-19 18:47         ` Bjorge, Erik C
     [not found] <7FE3244EBB31F1449E4EC79CFE44E3F4A4C733FF@ORSMSX108.amr.corp.intel.com>
2017-11-30 14:52 ` Healer64
2017-12-01  0:23 ` Healer64
2017-11-27 23:07 Healer64
2017-11-29  7:48 ` cod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7FE3244EBB31F1449E4EC79CFE44E3F4A4C847D5@ORSMSX108.amr.corp.intel.com \
    --to=erik.c.bjorge@intel.com \
    --cc=chipsec@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).