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)

[Laszlo Ersek <lersek@xxxxxxxxxx>]

On 09/14/15 11:22, Ian Campbell wrote:
> 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.

Good points!

>> , 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".

I believe I could argue against both (*) and (**), but it would not be
productive. :)

Instead, what matters is the (now) clear, significant user demand for
turning off PcdSetNxForStack by default. I'll send a followup patch for
my series to that end.

And, sorry about the inconvenience the regression may have caused, of
course ;)

Thanks!
Laszlo


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