[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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)



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.