Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-09-11 at 17:28 +0200, Laszlo Ersek wrote:
> 
[...]
> For me that's not so clear-cut. OVMF is frequently used as a UEFI
> development environment (it's better to brick a virtual machine than
> your physical dev platform...)

One flip side to this is that people often virtualize in order to continue
running their older platforms and applications, because upgrading them
would be difficult for whatever reason.

There's an obvious tension between that and the desire to use OVMF as a
development platform, but it seems to me that the developers are the ones
who can more readily be expected to mess with the defaults.

> , so upstream should embrace new UEFI
> features reasonably early, unless there are *grave* regressions.
> 
> One example I named was the properties table feature (new in UEFI-2.5).
> It would break Windows 7. Given the large number of users running
> Windows 7 on OVMF (mainly for GPU passthrough), such a regression would
> be serious.
> 
> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
> very old (and has a clear upgrade path)

Debian Wheezy is not very old, it's only a year older than RHEL7 (May 2013
vs June 2014) and only a bit older than two years in absolute terms. It is
also the subject of an LTS effort, which extends its lifetime to 2018.

For comparison Windows 7 (which you argue regressing would be serious) was
released in 2009 and there have been two major Windows releases since then.

Given that and with consideration between the desire to run older platforms
vs. a development environment it seems to me that Debian Wheezy has not yet
reached the threshold for being ignored or for saying to users "you must
now upgrade".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel