Do we also want some validation of e_phoff? I guess not since vn_rdwr() will return an error for short reads?

Should this use imgp->td?

Why exactly do we need the new imgp->phdrs field? It looks like the local variable is sufficient.

For the same reason as why we use LK_RETRY. The 'real' VFS calls return errors if anything went wrong.
In fact, even if vn_rdwr() does not return an error but partially read the phdrs, there should be no harm: the rest of the code must be prepared to parse invalid phdrs.

But vn_rdwr() returns EIO if the read was truncated.

the rest of the code must be prepared to parse invalid phdrs

I was more concerned about e_phoff itself: before, it was safe to assume that e_phoff < PAGE_SIZE, now it can be any 64-bit value. But in practice it is bounded by the file size, so probably this is not a real issue.

e.g., is it possible for these calculations to overflow now?

Isn't this assuming that the phdrs are in the first page?

I do not understand why would it be important. if e_phoff is arbitrary large, and file is big enough, what is the problem?

It is possible, but it should not matter. First, to wrap around, I believe that the segment mapping must wrap. Second, the effect is only a wrong AT_PHDRS provided to userspace.

Nonetheless, I added the wrapping check at the beginning of the function.

There is no problem, assuming that we check for overflow in the calculation hdr->e_phoff + hdr->e_phnum * hdr->e_phentsize.

I think m_phdrs can be uninitialized here.

Sorry, I see what you mean now, even if overflow happens, the only result is an invalid auxv entry.