Remove redundant sgx.nonpie_binary manifest option

[dimakuv]

Description of the changes

It is now unclear why we needed this manifest option in the first place (probably to work around a bug in very old SGX drivers that prohibited mmapping the enclave space from address 0x0).

As a side effect, Gramine enclave base address is always 0x0.

TODOs (if this PR passes CI):

• Same for gsc repo -- Remove redundant sgx.nonpie_binary manifest option gsc#133
• Same for examples repo -- Remove redundant sgx.nonpie_binary manifest option examples#54
• Same for contrib repo -- only in "Curated Apps" there, so I'm not touching and letting @jkr0103 decide when and how to do this change

How to test this PR?

CI is enough (our CI has all kinds of SGX drivers which was the original problem iiuc).

---

This change is 

[dimakuv]

Reviewable status: 0 of 53 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel)

a discussion (no related file):
Btw, GSC always sets sgx.nonpie_binary = true, and we never experienced any problems (and noone every complained): https://github.com/gramineproject/gsc/blob/246423a6f8e49279dfb45ab53e8fb9423d1ae2da/templates/entrypoint.common.manifest.template#L15

So this is yet another argument that removing this manifest option just works, and nothing will break (GSC is heavily used by many folks, on different SGX drivers including legacy one).

---

[dimakuv]

Jenkins, retest pkg-rpm-almalinux9 please ( Curl error (6): Couldn't resolve host name for https://mirrors.almalinux.org/mirrorlist/9/appstream, unrelated)

[kailun-qin]

Reviewed 42 of 53 files at r1.
Reviewable status: 42 of 53 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @dimakuv)

---

Documentation/devel/onboarding.rst line 268 at r1 (raw file):

     = true``. If you observe that memory addresses change constantly and hinder
     your debugging, set ``loader.insecure__disable_aslr = true``. But don't use
     the last two options in production; use them only for debugging and

these

Code quote:

the last

[dimakuv]

Reviewable status: 41 of 53 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @kailun-qin)

---

Documentation/devel/onboarding.rst line 268 at r1 (raw file):

Previously, kailun-qin (Kailun Qin) wrote…

these

Done.

[mkow]

Reviewed 52 of 53 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions, "fixup! " found in commit messages' one-liners (waiting on @kailun-qin)

---

pal/src/host/linux-sgx/host_main.c line 273 at r2 (raw file):

     * must cover code segment loaded at some hardcoded address (usually 0x400000), and heap cannot
     * start at zero (modern OSes do not allow this) */
    enclave->baseaddr = DEFAULT_ENCLAVE_BASE;

Actually, we should have probably done this long time ago as an anti-exploit mitigation: always having address 0 inside the enclave range makes it much harder to exploit NULL derefs, which are rather common.

[dimakuv]

Reviewable status: 50 of 53 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @kailun-qin and @mkow)

---

pal/src/host/linux-sgx/host_main.c line 273 at r2 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

Actually, we should have probably done this long time ago as an anti-exploit mitigation: always having address 0 inside the enclave range makes it much harder to exploit NULL derefs, which are rather common.

Yes.

[mkow]

Reviewed 3 of 3 files at r3, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @kailun-qin)

[dimakuv]

Dismissed @kailun-qin from a discussion.
Reviewable status: complete! all files reviewed, all discussions resolved