kernel linkers: Validate linker set on lookup

[kib]

I do not have objections, but I am curious, did you see real (corrupted) files with wrapped around linker sets?

We do not harden linkers against bad-formed objects, there is no point in doing so.

[zlei]

Fast response +1

In D39864#907436, @kib wrote:

I do not have objections, but I am curious, did you see real (corrupted) files with wrapped around linker sets?

I am inspired by @hselasky 's comment on D39638 :

#ifdef VIMAGE
static void
link_elf_propagate_vnets(linker_file_t lf)
{
	elf_file_t ef = (elf_file_t)lf;
	int size; // @hselasky Technically this variable should be "ssize_t".

	size = (uintptr_t)ef->vnet_stop - (uintptr_t)ef->vnet_start;
...
}

Ideally the var size should be size_t, if link_elf_lookup_set() can guaranty stop >= start.

I checked all consumers of link_elf_lookup_set() and the kernel can behaves good even stop < start. So this will not introduce any functional changes.
I produced some corrupted kmods via https://elfy.io/ and verified that.

I did not encounter this (real corrupted files), or someone did but the kernel still behaves good so they are ignored.

We do not harden linkers against bad-formed objects, there is no point in doing so.

I'm not getting that well. Do you mean validating bad-formed objects cost too much ? Or linkers are not responsible to validate ?

[kib]

In D39864#907443, @zlei wrote:

We do not harden linkers against bad-formed objects, there is no point in doing so.

I'm not getting that well. Do you mean validating bad-formed objects cost too much ? Or linkers are not responsible to validate ?

It is both to hard and meaningless. Suppose you got a corrupted module loaded, and kernel crashes. Next, suppose you loaded correctly formed module but with malicious code. Is there a difference? Simply do not load modules from untrusted places.