[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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)
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? (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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |