Message Validation

[Jon Gosting]

Thank you for your reply.  What you said makes sense.  It appears that a
better solution than avoiding message validation by using "trusted peer"
mode would be to make message validation more efficient for large arrays of
bytes, integers, etc.

When the function, validate_body_helper, in dbus-marshal-validate.c
encounters an array it will call validate_body_helper for every element of
the array.  There is a "FIX ME" comment on line 423 that suggests avoiding
this function call when the element type is a fixed-size type.  When I made
this change and ran some benchmarks, I found that sending a large byte array
took approximately the same time regardless of whether the element type was
declared as bytes or as integers with the number of elements changed to 1/4
of the original number.  The execution time also was essentially the same as
when running in "trusted peer" mode.  With large arrays, the time saved can
be significant.

I am working with the 1.2.4 release.  This was a pretty simple change and
there do not appear to be any side effects or loss of security.  In the case
of validating an array of bytes, calling validate_body_helper doesn't appear
to do anything.  For other fixed-size types, it checks that the alignment is
correct.  However, you already check the alignment of the first element when
you discover that the current type is DBUS_TYPE_ARRAY, so iterating through
the rest of the array to perform this check does not appear to have any
value.

Should I submit a patch for this in bugzilla or is there a reason why this
change hasn't already been made that I missed?

Thanks,

Jon

On Wed, Oct 8, 2008 at 4:12 AM, Havoc Pennington <hp at pobox.com> wrote:

> Hi,
>
> On Tue, Oct 7, 2008 at 1:14 PM, Jon Gosting <yukarionsen at gmail.com> wrote:
> > 1.  I noticed that some of the execution time in the scenario described
> > above is in the dbus-daemon.  I suspect that it is also caused by message
> > validation, but didn't see where this was happening in the code.  Is
> there a
> > similar change that I can make in the dbus-daemon code to put it into
> > "trusted peer" mode?
>
> dbus-daemon uses libdbus, so the libdbus change also affects it.
>
> > 2.  Are there any plans to make this a configuration option (either
> > compile-time or run-time) in the future?
>
> I don't know if that makes sense; it's more just a profiling hack to
> illustrate where some of the performance cost is. I'd be a little
> afraid of people (or linux distributions) enabling it by default and
> creating a huge security problem.
>
> Havoc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20081009/8bcdb7ad/attachment.htm