I've been able to reproduce and analyse this issue.
The security error seems to be valid.
What actually happens is, that dmidecode does the following (strace):
> openat(AT_FDCWD, "/dev/mem"
> , O_RDONLY) = 3
> fstat(3, {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
> mmap(NULL, 65536, PROT_READ, MAP_SHARED, 3, 0xf0000) = 0xffff87770000
> --- SIGBUS {si_signo=SIGBUS, si_code=BUS_OBJERR, si_addr=0xffff87770000} ---
> +++ killed by SIGBUS +++
> Bus error
According to the dmidecode source code (dmidecode.c) this is some sort
of fallback mechanism for x86 and or x86_64. In any case that's not a valid
access on arm64.
I think this should not be done in dmidecode on non-x86 machines (maybe with
#ifdef __x86_64__ and friends).
> ...
> memory_scan:
>
> if
> (!(opt.flags & FLAG_QUIET))
> printf(
> "Scanning %s for entry point.\n"
> , opt.devmem);
> /* Fallback to memory scan (x86, x86_64) */
>
> if
> ((buf = mem_chunk(0xF0000, 0x10000, opt.devmem)) == NULL)
> {
> ret = 1;
>
> goto
> exit_free;
> }
> ...
The reason why the fallback is executed is that the kernel does not find DMI
and reports this during bootup as:
> [ 0.353729] DMI not present or invalid.
This is caused by the fact that the bootloader (U-Boot) does not have
EFI support enabled and thus does not provide the DMI.
This is something we will address.
