Discussing this with @osandov, and how to prevent incorrect usage, where the user specifies a vmlinux file that doesn't correspond to the vmcore file..

Omar suggested that the ideal solution would be to leverage the "build-id" that is generated during compilation. For example, if the "build-id" for the kernel that generated the vmcore was embedded in the vmcore, then we could read this "build-id" value, and then use it to determine the correct vmlinux to use. If the two "build-id" values from the vmcore and vmlinux files did not match, we could throw an error.

If we did it this way, this would ensure the solution works even for kernel's of the same version, but built with different compilation flags, features, etc. The problem though, is the vmcore file does not currently contain the "build-id" information. Thus, to adopt this approach, we'd first need to extend the kernel and/or vmcore file format, to embed the "build-id" into the vmcore file.

Until the vmcore file contains the "build-id", we think it'd be reasonable to leverage the "OSRELEASE" value as I mention in the bug report. Obviously this may not work for all cases, e.g. for two kernels of the same version but with different features enabled, but it would likely be better than nothing.

We'd also want to enable a way to disable any verification of the "OSRELEASE", in cases where the operator wants to ignore the check.