On Fri, Jul 03, 2020 at 09:48:14PM +0000, Andersen, John wrote:
Is there a plan for fixing this for real? I'm wondering if there is a sane weakening of this feature that still allows things like kexec.
I'm pretty sure kexec can be fixed. I had it working at one point, I'm currently in the process of revalidating this. The issue was though that kexec only worked within the guest, not on the physical host, which I suspect is related to the need for supervisor pages to be mapped, which seems to be required before enabling SMAP (based on what I'd seen with the selftests and unittests). I was also just blindly turning on the bits without checking for support when I'd tried this, so that could have been the issue too.
I think most of the changes for just blindly enabling the bits were in relocate_kernel, secondary_startup_64, and startup_32.
So I have a naive fix for kexec which has only been tested to work under KVM. When tested on a physical host, it did not boot when SMAP or UMIP were set. Undoubtedly it's not the correct way to do this, as it skips CPU feature identification, opting instead for blindly setting the bits. The physical host I tested this on does not have UMIP so that's likely why it failed to boot when UMIP gets set blindly. Within kvm-unit-tests, the test for SMAP maps memory as supervisor pages before enabling SMAP. I suspect this is why setting SMAP blindly causes the physical host not to boot.
Within trampoline_32bit_src() if I add more instructions I get an error about "attempt to move .org backwards", which as I understand it means there are only so many instructions allowed in each of those functions.
My suspicion is that someone with more knowledge of this area has a good idea on how best to handle this. Feedback would be much appreciated.
You can simply increase the value of TRAMPOLINE_32BIT_CODE_SIZE in pgtable.h, assuming you don't need a very large increase. There's one page available for code + stack at present.