On Tue, Dec 15, 2015 at 3:58 PM, Daniel Cashman <dcashman@xxxxxxxxxxx> wrote: > On 12/15/2015 07:00 AM, Stephen Smalley wrote: >> 1. I don't think it is the size of the context that is the concern but >> rather the fact that it is a variable-length string, whereas current >> binder commands use fixed-size arguments and encode the size in the >> command value (common for ioctls). Supporting passing a variable-length >> string would be a change to the protocol and would complicate the code. >> On the performance side, it means generating a context string from the >> secid and then copying it to userspace on each IPC (versus just getting >> the secid and putting that in the existing binder_transaction_data that >> is already copied to userspace). > > This is precisely the motivation for the original enquiry. Issue has > been brought up about changing the protocol, and concern has also been > strongly expressed about the overhead introduced by the string > operations, although this has not been measured. User-space would still > need to do something intelligent with the secid, which would involve its > own lookup and caching, but the idea is that this wouldn't be done with > the binder lock held. > >> 2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks >> might exist with and without the current patch that copies the context >> string. > > Yes, this needs to be done. This issue was brought up as part of > discussion regarding a proposed change to the binder driver to add the > context string to each transaction. An outcome of that discussion was, > "before we go too far into this, let's see the reaction upstream to > exposing the secid." Based on the reaction here (upstream), I think > it's my responsibility to push forward the string-based change and get > the appropriate perf numbers so that a meaningful comparison can be made. The existing, variable length string based approach is going to be your easiest path forward with respect to the kernel, although it may turn out to be a non-starter from a binder point of view. I just want to reiterate that I'm not against the idea of exposing the secid tokens, but not necessarily in their current form; we will probably want to revisit the idea of a persistent secid and consider the impact to any future stacking work. -- paul moore www.paul-moore.com _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
