Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1688725 - 'import dmidecode' shouldn't access memory
Summary: 'import dmidecode' shouldn't access memory
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python-dmidecode
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: lijiang
QA Contact: Jeff Bastian
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-14 10:24 UTC by Jaroslav Škarvada
Modified: 2019-03-19 18:26 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)
Reproducer (deleted)
2019-03-14 10:25 UTC, Jaroslav Škarvada
no flags Details

Description Jaroslav Škarvada 2019-03-14 10:24:53 UTC
Description of problem:
Dmidecode is not supported on ppc64/ppc64le and just importing the python-dmidecode library results in strange behaviour.

Version-Release number of selected component (if applicable):
python-dmidecode-3.12.2-3.el7.ppc64le

How reproducible:
Always

Steps to Reproduce:
1. ./test.py
2. journalctl -b | grep test.py

Actual results:
** COLLECTED WARNINGS **
/dev/mem (mmap): Operation not permitted
No SMBIOS nor DMI entry point found, sorry.
** END OF WARNINGS **

bře 14 06:18:44 ibm-p8-kvm-09-guest-14.virt.pnr.lab.eng.rdu2.redhat.com kernel: Program test.py tried to access /dev/mem between f0000->100000.

Expected results:
No error

Additional info:
Maybe the library should be reworked not to access the /dev/mem just in the import and to check whether dmidecode is supported, but sufficient workaround is just not to ship the library on ppc64/ppc64le, it's useless there.

It's related to the bug 1688371.

Comment 2 Jaroslav Škarvada 2019-03-14 10:25:46 UTC
Created attachment 1543976 [details]
Reproducer

Comment 3 Jaroslav Škarvada 2019-03-14 13:25:01 UTC
The same problem happens on aarch64, so probably it shouldn't be shipped on non x86(64).

Comment 4 Jaroslav Škarvada 2019-03-14 13:27:10 UTC
It seems on RHEL-7 the spec has just:
ExcludeArch: s390x

I cannot see any exclude/exclusive keywordss on the RHEL-8, so the RHEL-8 is probably also affected.

Comment 5 Jaroslav Škarvada 2019-03-14 13:55:48 UTC
Maybe the dmidecode package is good for offline parsing, but just the 'import dmidecode' shouldn't access hardcoded memory addresses (see the reproducer).

Comment 6 Ondřej Lysoněk 2019-03-14 14:29:31 UTC
Ideally, the dmidecode module should not print anything to stdout/stderr under any circumstances. If it encounters an error, it should raise an exception instead. Also, IMHO it shouldn't do anything that requires privileges during import.

Comment 7 Jaroslav Škarvada 2019-03-18 12:30:17 UTC
(In reply to Ondřej Lysoněk from comment #6)
> Ideally, the dmidecode module should not print anything to stdout/stderr
> under any circumstances. If it encounters an error, it should raise an
> exception instead. Also, IMHO it shouldn't do anything that requires
> privileges during import.

+1 it shouldn't access the memory even on x86 during the import, this could lead to the following when running the reprodcuer as non-privileged:

** COLLECTED WARNINGS **
 /dev/mem (mmap): Operation not permitted

Comment 8 Jeff Bastian 2019-03-19 18:17:10 UTC
This is known bug 1509938 and, unfortunately, it will not be fixed since upstream has abandoned python-dmidecode.

We've been updating tools to use dmidecode directly instead of the python module.  See the dependencies attached to bug 1509938.

Ideally, dmidecode should be updated to have a machine-readable-output option like XML or JSON so that tools like subscription-manager and abrt do not need complex parsers.

Comment 9 Jeff Bastian 2019-03-19 18:26:48 UTC
Historically, tools like dmidecode had to scrub through the first 1MB of RAM to find the SMBIOS (DMI) tables.  Modern kernels export the tables in /sys/firmware/dmi/tables/* and /sys/firmware/dmi/entries/*, and dmidecode has been updated to read from /sys instead of /dev/mem.  But since the module python-dmidecode was abandoned, it was never updated to read from /sys, hence we have these bugs.


Note You need to log in before you can comment on or make changes to this bug.