* Add firmware data retrieval
* Apply suggestions from code review
* Remove FW info native versions from linux/win helpers and added results to info module
---------
Signed-off-by: Dan Scott <dan.scott@intel.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Nathaniel Mitchell <nathaniel.p.mitchell@intel.com>
There is no point in doing a lazy-import with
`chipsec.helper.linuxnative.cpuid`, as the `cpuid` function is almost
always called when starting chipsec, to display the banner.
Signed-off-by: Nicolas Iooss <nicolas.iooss_git@polytechnique.org>
When using chipsec.chipset Python module from an unprivileged user, the
Python interpreter crashes with a segmentation fault on an `outl`
instruction. This is because `iopl(3)` failed and the "legacy PCI"
implementation tried to write a value to an I/O port without being
allowed to.
Fix this by checking the return value of `iopl`.
While at it, enable using `error` in the C library, to properly report
the `EPERM` error.
While working on this code, it appeared that:
- `self.addr` was written twice in `PORTS`' constructor: once for the
`inl` implementation and another one for `outl`.
- Everytime `PORTS` or `LEGACY_PCI` objects were created, some memory
was allocated (with `mmap.mmap`) to run the helpers and this memory
was never freed.
- The global variables `IN_PORT` and `OUT_PORT` were defined as lists
but always used as bytes.
Fix these issues by spliting `self.addr` into two variables, by
introducing a class property which re-use previous `PORTS` instances
(making this class a singleton) and by making `IN_PORT` and `OUT_PORT`
directly `bytes`.
While at it, change the names to the usual camel case convention
(`PORTS` -> `Ports` and `LEGACY_PCI` -> `LegacyPci`) and add type hints.
Signed-off-by: Nicolas Iooss <nicolas.iooss_git@polytechnique.org>
Reading 64-bit MMIO registers does not work with Linux native helper.
For example:
$ ./chipsec_util.py --helper linuxnativehelper txt state
...
TXT Public Key Hash: 9c78f0d8000000002f47761c00000000164a66a90000000092e3144f00000000
This value comes from four 64-bit MMIO registers (`TXT_PUBLIC_KEY_0` to
`TXT_PUBLIC_KEY_3`). This is caused by `LinuxNativeHelper.read_mmio_reg`
assuming the size cannot be larger than 4. And it also assumes that the
physical address is always aligned on a 4-byte boundary.
Reading a value as a "32-bit integer" can be important for MMIO
registers, so do not change this case, when the physical address is
aligned. In practice:
- If `size == 1`, the result can be directly read from the mapping.
- Otherwise, if the address is aligned,
`region_mv.cast(defines.SIZE2FORMAT[size])` can be used to trigger an
atomic read of the requested size.
- In the unaligned case, the bytes are read from the memory view,
possibly one by one, and `defines.unpack1` is used to glue them back
to an integer.
Implement a similar logic in `write_mmio_reg` too. While at it, as the
`return 0` did not make much sense in this function, remove it.
With this commit:
$ ./chipsec_util.py --helper linuxnativehelper txt state
...
TXT Public Key Hash: 9c78f0d853de854a2f47761c72b86a11164a66a984c1aad792e3144fb71c2d11
Signed-off-by: Nicolas Iooss <nicolas.iooss_git@polytechnique.org>
Using `{buf:8X}` does not work in `LinuxNativeHelper.write_msr`: this
raises an expection
TypeError: unsupported format string passed to bytes.__format__
Use `{buf.hex()}` instead to format the bytes in the error message.
Signed-off-by: Nicolas Iooss <nicolas.iooss_git@polytechnique.org>
dscott90