Remove FPT_AEX_EXT.7 requirement completely

[woodbe]

While this has been an objective for a long time, based on several discussions/investigations I have had, this does not appear even remotely feasible with the current implementations that are available. The expectations of this requirement would seem to push towards a very limited-functionality device as opposed to the rich capabilities provided by mobile devices today.

I do not see how this requirement would ever be moved to mandatory, and no one has chosen to select it because of the issues surrounding the implementation and testing.

[lewyble]

@kgal - thoughts?

[kgal]

I think this requirement is okay. Heap protection mechanisms do exist (see

• https://www.usenix.org/legacy/events/woot11/tech/final_files/Novark.pdf, and
• https://www.ssrg.ece.vt.edu/papers/middleware19-slimguard.pdf
• https://web.cse.ohio-state.edu/~lin.3021/file/CCS17c.pdf

) . OpenBSD uses a mechism to protect its heap. iOS appears to provide heap protection but it seems to be only for debugging purposes. But I think they could extend it if Apple felt it was warranted.

I would make sure to define what is meant by "Runtime Environment". My mind immediately went to JREs, but after reading the tests section it looks like it could be anything that supports execution, including native enviornments using libc.

[woodbe]

So I totally agree with the definition of a runtime environment, having something more explicit about what that means would help if this is going to be kept.

To be clear, I didn't mean that these protections do not exist, just that they do not exist on mobile devices that I know of today (in production) that are validated to the MDF requirements. And our read on the requirements of protection (which would seem to not just be detection, but prevention, as well), would seem to need both OS and app support to be fully supported (such as the libc environment).

I guess my concern, to a large extent, is whether having this here is useful if there isn't a wide usage of it. Even here the only examples are OpenBSD and Mac OS X which is based on it, iOS isn't clear, and Linux support isn't clear (there is similar protection for the stack, not the heap, it seems), and I have no idea about Windows.

While I have always liked the concept of objective requirements to provide direction, having requirements that just sit there for a long time with no progress, seems like a waste of the potential usefulness of objective requirements (which was supposed to be that they would become mandatory at some point in the future). How long should an objective requirement remain in a PP until it either should be dropped (because the market isn't there or won't go there) or modified (to try to get closer to what is in market)?

[kgal]

Hmmm. I find myself agreeing with this argument. In general, I think it's safe to say that objective PP requirements don't really drive the direction of the mobile device evolution.

[woodbe]

To be honest, the main place that I would use as the counter to @kgal statement of objective requirements driving functionality would be auditing, but I would also say that from what I can actually see in the market, that particular change is a functional failure. The logging that is available does technically meet the requirements, but accessing it is not what (in most cases) anyone would consider to be enterprise-capable, and even where it is, it needs support for MDMs which is mostly lacking.

I am certainly happy for this to be say part of a v4 revision that could include a more specific in-depth review of all the objective requirements. At that point maybe as a TC we can determine whether they should be moved to mandatory, kept as they are, modified or completely dropped. I think this should be part of the lifecycle of the PPs, as I have actually spoken about before.