Allow using libkvm on kernel modules

[stevek]

Summary

The kernel has e_type in the ELF header as ET_EXEC, but kernel modules have e_type in the ELF header as ET_REL. If one wants to use kvm_open on a kernel module, then libkvm needs to allow for ET_REL in addition to ET_EXEC.

Test Plan

Tested with internal tools in Juniper which allow for digging into specific data structures given a vmcore and a kernel and its loaded modules.

[imp]

looks good to me. IIRC, this isn't true for every architecture, but there's no reason I know of to disallow it there.

[stevek]

In D13287#277145, @imp wrote:

looks good to me. IIRC, this isn't true for every architecture, but there's no reason I know of to disallow it there.

Yes, it looks like even for x86, 32-bit ends up with ET_DYN, so perhaps there should be more done here.
I'm thinking that we might need another argument for the KLD case. And have something like:

int
_kvm_probe_elf_kernel(kvm_t *kd, int class, int etype, int machine)
{

        return (kd->nlehdr.e_ident[EI_CLASS] == class &&
            (kd->nlehdr.e_type == ET_EXEC || kd->nlehdr.e_type == etype) &&
            kd->nlehdr.e_machine == machine);
}

With amd64 doing:
_kvm_probe_elf_kernel(kd, ELFCLASS64, ET_REL, EM_X86_64)
And i386 doing:
_kvm_probe_elf_kernel(kd, ELFCLASS32, ET_DYN, EM_386)

And also figure out what is appropriate for the other architectures.

[jhb]

PowerPC needs ET_DYN for the kernel IIRC, so I'd be inclined to just permit the different e_type's without the additional check on machine. However, I'm more curious what the use case is for passing a kld file (rather than a kernel) to libkvm? Much of libkvm really assumes it is working with a kernel (e.g. trying to decode page tables in a non-mini-dump, etc.)