[PATCH 04/12] sbbr/dmicheck: Add SMBIOS test cases as per SBBR.

[Leif Lindholm]

On Mon, Mar 06, 2017 at 11:56:22AM -0600, Supreeth Venkatesh wrote:
> On Fri, 2017-03-03 at 11:37 -0700, Jeffrey Hugo wrote:
> > This appears broken on my platform.  The standard dmitest works
> > fine. 
> > This test outputs:
> > 
> > PASSED: Test 1, SMBIOS30 Table Entry Point Checksum is valid.
> > PASSED: Test 1, SMBIOS30 Table Entry Point Length is valid.
> > Cannot mmap SMBIOS 3.0 table from 0000000004e50000..0000000004e529c4.
> > 
> > Test 2 of 3: Test DMI/SMBIOS3 tables for errors.
> > Cannot mmap SMBIOS 3.0 table from 0000000004e50000..0000000004e529c4.
> > 
> > Test 3 of 3: Test ARM SBBR SMBIOS structure requirements.
> > Cannot mmap SMBIOS 3.0 table from 0000000004e50000..0000000004e529c4.
> > 
> 
> Thank you very much for testing it on your platform. Appreciate it.
> As per earlier discussion, I think Leif or someone mentioned that "/sys
> is definitely the preferable method to access both ACPI and SMBIOS, and
> the only one that should be used on any ARM system."

/sys is the only valid access method on ARM systems you wish to not be
trivially DoS-able from userspace. I guess if people want to keep
/dev/mem available for development purposes, or are using kernels
predating the implementation of the complete /sys interface (4.2, I
think), it can make sense to keep the /dev/mem version around.

But I would hope it could move to being enabled only if configure is
run with --unsafe-memory-accesses, and even then only as a fallback.
Actually, I'll put such an RFC patch together to do just that.

But this also emphasises the importance of not duplicating code if at
all avoidable. The removal of the /dev/mem code path would have been
immediately obvious as a diff to the original file.

/
    Leif