Remove Xen vga driver hacks

[osresearch]

Xen supports vga=current as a command line option, which appears to work in the absence of any hacks on the xen/drivers/video/vga.c file. This would simplify our porting to just the no-real-mode patches.

[tlaurion]

@osresearch : It is unclear to me if no-real-mode patch was included upstream into Xen/QubesOS? If not, why?

no-real-mode (x86)

= <boolean>

Do not execute real-mode bootstrap code when booting Xen. This option should not be used except for debugging. It will effectively disable the vga option, which relies on real mode to set the video mode.
SRC

That would provide the no-real-mode switch at hypervisor boot, since "vga=current" already fixes vga issues that needed xen patches from Heads.

That would greatly reduce the need from users to update Heads firmware as often as they need now, following Qubes security patches.

@flammit 's new UX would see a boot config change, could provide boot menu(m) as a result and prompt the user with a choice to set new default or boot actual config (y) since the stored and signed boot config is different then the one genrated on the fly from what was found on disk. The user would only need to resign config changes with it's OpenGnuPG card and set new config defaults, which would link to newly patched xen, kernel and initrd provided by Qubes recent security upgrade.

That, combined with #182 would suppress most actual needs of upgrading Heads, confining those upgrades to when Heads fixes it's own security bugs or add functionality.

@osresearch : Any link to discussions that justified upstream rejection of no-real-mode patch from QubesOS/Xen?

Thanks.

[osresearch]

no-real-mode was already part of Xen, although it still had a legacy dependency on the EBDA (Extended BIOS Data Area). I haven't tried vga=current to see if that eliminates the need for the patch.

It would be ideal to be able to boot stock Qubes' Xen, so this is worth tracking down.

Here is the xen-devel thread about the patch: https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg01195.html

[osresearch]

Andrew Cooper seemed interested in merging it:

Since this is the only mention I've seen of this setup since 2008, I understand that merging this patch into the Xen kernel might not be the highest priority. But for time travellers looking to boot Coreboot + Linux payload + kexec + Xen + Qubes on their Thinkpads, these patches might prove to be useful.

Going forwards, there are a number of usecases for booting Xen in non-legacy environments which have been proposed, and all would benefit from improvements such as these.

[tlaurion]

@osresearch

Are you in a position to submit patches?  If so, they would be very welcome.

~Andrew

Upstreaming for the win :) Andrew seems to only wait for input from that thread.

[tlaurion]

no-real-mode was already part of Xen, although it still had a legacy dependency on the EBDA (Extended BIOS Data Area). I haven't tried vga=current to see if that eliminates the need for the patch.

Modified this line with:
kexeccmd="$kexeccmd -l /boot/$firstval
Tested and system hangs.

@osresearch : Could you reply back to Andrew on the list so that he knows where he can get the current patches from? That would be a great advancement to heads for this patch be be upstreamed.

[osresearch]

This is too important to close with WONTFIX. I'll resubscribe to the Xen mailing list and see if we can make this happen in mainline.

[osresearch]

Interestingly, it turns out that this is not a corebot or Heads bug! kexec is to blame -- it is creating a segment at physical address 0x0 of 0x78 bytes, which is then padded to a page size of 0x1000 and memset. That zeros out the EBDA and other bios data at 0x40e and 0x413, causing the startup code in Xen's head.S to select a bad address for its trampoline.

One possible patch is this monstrosity. Thoughts?

diff -u --recursive clean/kexec-tools-2.0.16/kexec/kexec.c kexec-tools-2.0.16/ke
xec/kexec.c
--- clean/kexec-tools-2.0.16/kexec/kexec.c      2017-03-02 04:45:46.000000000 -0
500
+++ kexec-tools-2.0.16/kexec/kexec.c    2018-02-28 05:56:12.215000000 -0500
@@ -794,6 +794,19 @@
       if (sort_segments(&info) < 0) {
               return -1;
       }
+
+       // force segment 0 to have memsz == bufsz
+       // so that it won't overwrite EBDA
+       printf("hack ebda into segment 0!\n");
+       uint8_t * ebda = calloc(1, info.segment[0].memsz);
+       memcpy(ebda, info.segment[0].buf, info.segment[0].bufsz);
+       info.segment[0].bufsz = info.segment[0].memsz;
+       info.segment[0].buf = ebda;
+
+       // install some default EBDA values
+       *(uint16_t*)(ebda + 0x40e) = 0xF600; // segment
+       *(uint16_t*)(ebda + 0x413) = 0x400; // size
+
       /* if purgatory is loaded update it */
       update_purgatory(&info);
       if (entry)

[osresearch]

I'm hoping that the change to kexec will work around the Xen trampoline issue until the Xen team accepts the updated patches: https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg02696.html