Skip to content
This repository has been archived by the owner on Jan 20, 2022. It is now read-only.

Memory protection is silently disabled on SGX #504

Closed
HW42 opened this issue Mar 8, 2019 · 5 comments
Closed

Memory protection is silently disabled on SGX #504

HW42 opened this issue Mar 8, 2019 · 5 comments

Comments

@HW42
Copy link
Contributor

HW42 commented Mar 8, 2019

Changing memory protection is not possible with SGX1 (see also #172 and #503). That's a hardware limitation. But _DkVirtualMemoryProtect just returns 0 (i.e. success). This seems to be dangerous since an application might rely on that a page access will fail. So I think we should return -PAL_ERROR_NOTSUPPORT or if this is really needed for compatibility we should at least have a warning that the user should review their application.

@mkow
Copy link
Member

mkow commented Mar 9, 2019

The solution with warning was already implemented as a part #385. See changes to Pal/src/host/Linux-SGX/db_memory.c in that PR.
I'm afraid that we can't simply return an error, changing memory permissions is not that uncommon in software (I think).

@donporter
Copy link
Contributor

I agree - although safer to return an error, this will likely break a lot of things.

I'd rather spend the effort getting SGX2/EDMM working.

Is there a particular use case you have for needing the error code?

@HW42
Copy link
Contributor Author

HW42 commented Mar 11, 2019

The solution with warning was already implemented as a part #385.

Nice.

I'm afraid that we can't simply return an error, changing memory permissions is not that uncommon in software (I think).

I expected this.

Is there a particular use case you have for needing the error code?

No. "Just" the gut feeling that there is software that, IMO rightfully, relies on correct mprotect behavior for something security sensitive.

@HW42
Copy link
Contributor Author

HW42 commented Mar 11, 2019

I'd rather spend the effort getting SGX2/EDMM working.

Maybe a bit off-topic, but just curious: So your plan is to drop SGX1 support, or at least make it only secondary? (I'm not trying so suggest preferences in one or the other direction, just asking what you plans here are)

@dimakuv
Copy link
Contributor

dimakuv commented Jul 14, 2021

As already mentioned previously, we have the warning: https://github.com/oscarlab/graphene/blob/4cb98219d8e302055587a8952c1102415a72ba42/Pal/src/host/Linux-SGX/db_memory.c#L79

We do return 0 (i.e., success), but this is better than returning an error code and breaking applications. SGX2/EDMM support is on its way (#2190), so the current solution seems fine. Closing.

@dimakuv dimakuv closed this as completed Jul 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants