Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LinuxHelper: open the device with buffering=0 to avoid caching #2058

Merged
merged 1 commit into from
Feb 7, 2024

Conversation

cbayet
Copy link

@cbayet cbayet commented Feb 6, 2024

LinuxHelper: open the device with buffering=0 to avoid caching when reading physical memory

I am using chipsec to read and write physical memory, and particularly expect this memory to change because some devices use it for DMA.

On linux, the python helper linuxhelper.py opens the device "/dev/chipsec" without setting buffering=0. It implies that calling the read_physical_mem API will be cached if flush() is not called. flush() is only called when writing. So if I expect a change in the DMA, it will never occur until I use write_physical_mem.

I think the read/write accesses to the device and therefore to physical memory should never be cached by the python bindings.

It might have some performance impact on the tool, but I don't think this is the behavior expected.

@cbayet cbayet requested a review from a team as a code owner February 6, 2024 14:25
@@ -188,7 +188,8 @@

estr = "Unable to open chipsec device. Did you run as root/sudo and load the driver?\n {}"
try:
self.dev_fh = open(self.DEVICE_NAME, "rb+")
# Do not buffer access to physical memory...
self.dev_fh = open(self.DEVICE_NAME, "rb+", buffering=0)

Check warning

Code scanning / CodeQL

File is not always closed Warning

File is opened but is not closed.
@dscott90 dscott90 merged commit 7bdf194 into chipsec:main Feb 7, 2024
43 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants