256-bit CheriBSD should refuse to load binary compiled for 128-bit

[arichardson]

I noticed that a GDB statically linked against the 128-bit sysroot would crash in memcpy when running on 256-bit CheriBSD

/tmp/gdb: ELF 64-bit MSB executable, MIPS, MIPS-IV with CHERI-128 version 1 (FreeBSD), statically linked, for FreeBSD 12.0 (1200033), FreeBSD-style, not stripped

The kernel should reject this binary instead of running it and crashing with an alignment violation.
It seems like this is only the case if EF_MIPS_ABI_CHERIABI is set but not for normal mips binaries that have EF_MIPS_MACH_CHERI128/EF_MIPS_MACH_CHERI256

[bsdjhb]

Amusingly what happens is that we do notice it is wrong and try to reject it, but eventually we fall through to the loop in sys/kern/imgact_elf.c around line 367 that just looks for a matching interpreter and it doesn't use the 'header_supported' method so it chooses the CheriABI brand anyway since 128 and 256 both use the same path to rtld. If we were to set BI_BRAND_NOTE_MANDATORY that would work around that. Hmmm, that has other implications. Perhaps it is better to honor 'header_supported' always.

[bsdjhb]

Also, I'm not sure a CheriABI gdb will work correctly. I've only tested building gdb as a plain MIPS binary.

[arichardson]

This is not a CheriABI binary but a pain MIPS one that happens to pull in memcpy from a 128bit sysroot. It is statically linked so it shouldn't have an interpreter string.

[bsdjhb]

Hmm, well, it's also true that we ran 128 bit binaries under 256 previously without failing correctly. :-/ I think for this case the default brand needs to have a header_supported check to reject these flags for mips.

[bsdjhb]

So I think we should only reject hybrid binaries with the wrong capability size then? That is, reject the 128 flag if on a 256 bit kernel and vice versa?

[bsdjhb]

bsdjhb@034e9ff if you want to test. The hybrid binaries I can find in CheriBSD don't have the flag set so aren't a good test.

[arichardson]

That commit fixes it for me. However, we are now printing a lot of warnings (3 for hybrid, 2 for purecap):

root@qemu-cheri128-alr48:/tmp # file pg_ctl.cheri256
pg_ctl.cheri256: ELF 64-bit MSB executable, MIPS, MIPS-IV with CHERI-256 (CheriABI) version 1 (FreeBSD), statically linked, for FreeBSD 12.0 (1200033), FreeBSD-style, not stripped

root@qemu-cheri128-alr48:/tmp # file pg_ctl.mips
pg_ctl.mips: ELF 64-bit MSB executable, MIPS, MIPS-IV with CHERI-256 version 1 (FreeBSD), statically linked, for FreeBSD 12.0 (1200033), FreeBSD-style, not stripped

root@qemu-cheri128-alr48:/tmp # ./pg_ctl.mips
warning: attempting to execute 256-bit hybrid binary '/tmp/pg_ctl.mips' on a 128-bit kernel
warning: attempting to execute 256-bit hybrid binary '/tmp/pg_ctl.mips' on a 128-bit kernel
warning: attempting to execute 256-bit hybrid binary '/tmp/pg_ctl.mips' on a 128-bit kernel
ELF binary type "9" not known.
./pg_ctl.mips: Exec format error. Binary file not executable.

root@qemu-cheri128-alr48:/tmp # ./pg_ctl.cheri256
warning: attempting to execute 256-bit CheriABI binary '/tmp/pg_ctl.cheri256' on a 128-bit kernel
warning: attempting to execute 256-bit CheriABI binary '/tmp/pg_ctl.cheri256' on a 128-bit kernel
ELF binary type "9" not known.
./pg_ctl.cheri256: Exec format error. Binary file not executable.

[bsdjhb]

Yes, the issue there is that imgact_elf.c will try the brand multiple times in the different loops. No other header_supported implementations try to output messages so they are ok to be called multiple times. We could perhaps put a 'ppsratecheck' condition on the printf to quiet it down.