EndpointSecurity Framework performance penalty

Hi,

I have come to notice that when registering several clients on several authorization events (one for ES_EVENT_TYPE_AUTH_EXEC and another for ES_EVENT_TYPE_AUTH_CREATE for example), even when I immediately call `es_respond_auth_result` - I am getting a significant performance penalty, that wasn't there when doing the same operations in a Kernel Extension.

For example, compilation that used to take me less the 8 minutes, now takes me 10-11 minutes.


When running instruments I can see that most of the time is actually spent inside the authorization function (es_respond_auth_result) - am I doing something wrong here?

I saw the caching flag makes a small improvement (reduces compilation time to 9-10 minutes), but It's a bit of a problem to use it without knowing what's the actual effect of the caching - what parameters are actually cached? what events can I assume will not be shown again?


This performance impact makes this framework unusable - what customer would be willing to take that severe impact with a product using this framework?


Also opened a bug (FB7503995) about this issue.


Thanks.

Accepted Reply

It's been more than a month, with no answer on this or the bug I have opened.

Right. I didn’t respond here because you’d already done what I would’ve recommended, that is, file a bug report with details of your benchmark.

As to what’s going on with your bug, AFAICT it’s been dup’d internally to a bug that’s tracking the overall issue of ES performance (r. 57670701). I don’t have anything concrete to say about that right now.

Finally, re-reading your post today I noticed you asked a question about caching:

I saw the caching flag makes a small improvement … but it's a bit of a problem to use it without knowing what's the actual effect of the caching - what parameters are actually cached?

I presume you’re talking about the

cache
parameter to
es_respond_auth_result
and
es_respond_flags_result
? If so, I can’t answer this off the top of my head. My advice is that you open a DTS tech support incident so I can research this in depth.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

Hi @eskimo,

It's been more than a month, with no answer on this or the bug I have opened.


After moving from EndpointSecurity daemon to a SystemExtension, thing have gotten even worse, with compilation time of a test project raising from 8-9 minutes to 15-16 minutes (with minimum to none actions taken in between receiving the ES_EVENT_TYPE_AUTH_EXEC message and authorizing it).


Am I missing something? We cannot use the caching mechanism, untill we know what actually is being cached - if executable is changed, is cache invalidated? For Anti-virus/security products, this is kind of crucial.

Are you talking about compilation time or runtime? Even 8-9 minutes for compilation time would be an enormous project, completely unsuitable for a kernel extension. Or are you talking about rutime, because you referenced instruments?

It's been more than a month, with no answer on this or the bug I have opened.

Right. I didn’t respond here because you’d already done what I would’ve recommended, that is, file a bug report with details of your benchmark.

As to what’s going on with your bug, AFAICT it’s been dup’d internally to a bug that’s tracking the overall issue of ES performance (r. 57670701). I don’t have anything concrete to say about that right now.

Finally, re-reading your post today I noticed you asked a question about caching:

I saw the caching flag makes a small improvement … but it's a bit of a problem to use it without knowing what's the actual effect of the caching - what parameters are actually cached?

I presume you’re talking about the

cache
parameter to
es_respond_auth_result
and
es_respond_flags_result
? If so, I can’t answer this off the top of my head. My advice is that you open a DTS tech support incident so I can research this in depth.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"