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