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

["Zeng, Star" <star.zeng@xxxxxxxxx>]

On 2015/9/9 19:30, Laszlo Ersek wrote:
> On 09/09/15 13:07, Ian Campbell wrote:
> > On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote:
> >
> > Thanks for all the info, I think I get it (although its not clear to me
> > whether how an app can claim to be UEFI 2.5 capable and what the transition
> > plan for legacy applications was going to be).
> >
> > > ... The question could be then if grub (in Wheezy) should be adapted to
> > > UEFI-2.5 (if that's possible)
> > I don't know either I'm afraid.
> >
> > [...]
> > > Hmmm. Actually, I'm torn about the default for PcdSetNxForStack.
> > I have a question: What attack vector is setting the stack as Nx in OVMF
> > (or even UEFI generally) trying to protect against? Or is this being done
> > for a reason other than security?
> I think it is being done for security, generally speaking (ie. as far as
> edk2 and the UEFI spec are concerned).
>
> Specifically for OVMF, I wrote the patch because Paolo suggested it,
> after (I think) he saw Star's feature patch on the edk2 mailing list. I
> thought it was a good suggestion, even in case we had no particular
> attack in mind: OVMF is frequently used as a UEFI development / test
> bed, and we try to enable new edk2 / UEFI features in it, unless the
> firmware size increase would be large, or something would break. (In
> which cases we usually bracket the new feature with build time flags.)
>
> I did consider regressions while writing this patch. In the commit
> message I mentioned "-cpu <model>,-nx" as a way to turn of NX support in
> the virtual CPU (which the edk2 feature dynamically detects and depends
> on), should anything break. I did not expect two things: (a) old grub
> actually executes stuff from the stack, (b) Xen has no way (?) to
> disable NX in a VCPU (or maybe that would be detrimental for other reasons).
>
> > I understand why it is done for kernels and apps, but where does the
> > untrusted element which is being protected against come from when running
> > UEFI?
> I'm sure this is explained in the five ECR documents attached to Mantis
> ticket 1224:
>
> https://mantis.uefi.org/mantis/view.php?id=1224
>
> Unfortunately, I don't think I can just publish those ECRs here (or dump
> the mantis ticket).
>
> I have no clue why UEFI development is so secretive. I had been annoyed
> by not seeing mantis tickets myself (and thereby missing the
> justification behind new UEFI features), so at some point I applied for
> "non-voter, observer-only" membership in both the PIWG and the USWG, and
> I got them. (I'm fuzzy on the details if this was helped by my being
> @redhat.com -- it probably was.)
>
> Perhaps you can also apply for membership (and read the ECRs on the
> ticket), or hopefully Star (who implemented the feature) could summarize
> the purpose here?
According to the mantis, the idea should come from 
http://www.uefi.org/sites/default/files/resources/3_-_UEFI_Summit_-_Security_Defenses_PTEC.pdf 
and adopted by USWG to UEFI has more abilities to provide defense in depth.
> (I won't try, based on the ECRs, because that will unavoidably put me in
> the position where I have to explain and defend the feature. Thanks, but
> no, thanks :))
>
> Cheers
> Laszlo
Thanks,
Star

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