tree 5645818a1cb37f89618a9d813b22e843f08e5672
parent 42f17cf6882d47483ba0b7205a56745201e8586c
author Maciej Żenczykowski <maze@google.com> 1708128267 +0000
committer Maciej Żenczykowski <maze@google.com> 1708130008 +0000

VTS: kernel_test: require x86 kernels to be 64-bit

We've got various issues with 32-bit x86 kernels:
- XFRM netlink UAPI is inconsistent
- there's some other (non-XFRM) netlink alignment/layout issues
- complete lack of test coverage
- eBPF ring buffers are not quite right (though it requires 5.8+)
- likely many other problems (I recall having run
  into problems with iptables user vs kernel bitness
  in the past as well, though those might have been fixed)

32-bit x86 kernel on cuttlefish has been non-bootable for
many many quarters (ran into it mid-way into the Android U
dev cycle IFIRC) due to AFAIK kernel bugs.

32-bit x86 in upstream Linux is *barely* getting any love,
is effectively on life support, and probably shouldn't be
relied upon to be functional (especially wrt. security issues).

AFAIK all (most?) Intel cpus have been 64-bit capable since
around the Core 2 Duo era (ie. mid-2006) and AMD is quite likely
even before that (since they came up with x86_64 architecture
in the first place).

Most other distributions are also dropping 32-bit kernel support.
For example for Fedora, IFIRC, v27 was the last one that worked
right on my Pentium III (we're now ~6 years later at v39).
[although, yes, Fedora is usually ahead of the curve]

It's entirely possible this won't actually affect anybody,
though of course we'll see...

In other words for *most* (if not all) x86 hardware out there it
should be possible to build/boot a 64-bit kernel - even if you then
run 32-bit userspace on top of that (like 32-bit cuttlefish does,
including the 'man personality' games it plays to pretend
to be 32-bit).

NOTE: this does *not* require 64-bit userspace (yet),
and doesn't affect ARM, where having a 32-bit kernel
is far less problematic, due to there being less ABI
differences between 32-bit and 64-bit (IFIRC a lot of
the really hairy issues stem from subtle differences
in 'long long' alignment inside of structs).

See also comments in:
  //system/core/libsysutils/src/NetlinkEvent.cpp
where we actually try to handle this correctly
(but there's no tests for it, and who knows
how many other places we've missed...)

Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia6d3cb9f1e6f8687ac8cdda113c6283688313749