BIND 10 #781: Define cryptographic API

BIND 10 Development do-not-reply at isc.org
Sat Apr 23 00:21:21 UTC 2011


#781: Define cryptographic API
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20110503
  blocker                            |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Now, about the new/delete issue.

 Apparently we've been talking about slightly different things, so Let
 me use an absurd example to highlight my point.

 Consider a library that returns a bare pointer to class Foo object
 (after new'ing the object):

 {{{
 // in the library header file:
 class Foo; // forward declaration
 Foo* createFoo();

 // in the library implementation file:
 Foo*
 createFoo() {
     return (new Foo());
 }
 }}}

 Also consider an external program (an executable that uses the library
 or a dynamically loadable third party module or something) that does:

 {{{
 void
 operator delete(void* ptr) {
     // do some fancy stuff, e.g., assuming a trailing padding at the
     // end of the allocated memory to check buffer overrun, and abort
     // the program if the assumption isn't met.
 }

 void
 someFunction() {
    Foo* foo = createFoo();

    // play with foo for a while

    delete foo;
 }
 }}}

 Then, at the point of 'delete foo', the externally defined operator
 delete will be called, and an unexpected result will happen.

 Of course, this is absurd (the program should have defined operator
 new, too if it wants to customize delete), but if the external program
 is built independently from the library (by a different
 (version/vendor of) compiler, using a different (version/vendor) of
 standard C++ library, or a different setting for the same compiler
 (debug/release mode, etc)), essentially the same thing can happen in a
 more implicit way.  This is the point of my concern.

 To avoid this scenario, we can provide a separate deleter function:

 {{{
 // in the library header
 void deleteFoo(Foo* ptr_to_foo);

 // in the library implementation file:
 void
 deleteFoo(Foo* ptr_to_foo) {
     delete ptr_to_foo;
 }
 }}}

 And have the application call deleteFoo() instead of 'delete'ing the
 bare pointer directly (we could even force it if we want, by defining
 a deleter object and making the Foo destructor private, but it's
 probably too much).  In addition, we can combine it with
 boost::shared_ptr so that the caller doesn't have to care about
 releasing the resource:

 {{{
 typedef boost::shared_ptr<Foo> FooPtr;

 FooPtr
 createFoo() {
    return (FooPtr(createFoo(), deleteFoo));
 }
 }}}

 Or, if we like to give the caller more flexibility, we could give them
 a bare pointer, suggesting the use of a smart pointer this way at
 their side.

 Such a problem is not specific to the cryptolink API; it applies to
 any relationship between a third party application that uses BIND 10
 libraries.  But since I heard this API will be used with an external
 loadable module, and I thought it might be developed and built
 separately from BIND 10, I thought the risk was higher in this case,
 and am suggesting a safer approach.  In this case, the API is not
 supposed to be very fast (because the underlying crypto stuff will be
 quite heavy anyway), so the overhead of the indirection wouldn't be an
 issue.  Also, since the deleter function is quite trivial and simple,
 I think it's a good deal here.

 Another "solution" is to declare we request any program that uses
 libcryptolink use the compatible delete to the new used in
 libcryptolink and do nothing specific.  If you prefer this approach, I
 don't necessarily object to it at this moment; do this that way and
 move forward for now, and discuss it at the dev list and/or biweekly
 call.  The risk I'm concerned about is not an immediate one, so we
 have time to decide (and completing the whole TSIG things sooner would
 be more important).

-- 
Ticket URL: <http://bind10.isc.org/ticket/781#comment:28>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list