re: Avoid subobject overread when setting IDRn

[jrtc27]

Summary

IDR0-IDR5 can be read byte-by-byte but must be written to as 4-byte
words. The current code to do this is rather clunky and ends up reading
past the end of the union's eaddr member due to MAC addresses only being
6 bytes. In practice this ends up being fine because the align_dummy
member will pad the union to a multiple of 4 bytes, but this is dodgy,
and on CHERI with subobject bounds enforcement enabled, as is done in
CheriBSD's pure-capability kernel, will trap.

Instead, make the buffer in use the right size, just use an array of
uint32_t's rather than a char buffer that's then cast to uint32_t * to
simplify it in the process, and zero-initialise it first to avoid
reading uninitialised data in the trailing bytes.

Found by: CHERI

[jhb]

sys/dev/re/if_re.c

3196–3197

If you just bzero(idr, sizeof(idr)) before the bcopy, is the compiler smart enough to realize the first 6 bytes are overwritten and only zero the last two bytes? (I've kind of assumed compilers do figure that out nowadays.) If so, I think doing that might be easier to read.

[jrtc27]

sys/dev/re/if_re.c

3196–3197

If the pointer to the buffer leaks it seems Clang does get a bit confused and becomes marginally worse one way round, but only by one or two instructions. If you give it a more "full" example and actually pass the contents not a pointer to the contents then Clang just turns it into what you'd hope to get, whilst GCC fails equally miserably for both ways round: https://godbolt.org/z/Ynad3z3Ma

So yeah this can just be a full bzero first.

[jrtc27]

Swap bzero and bcopy order for simplicity