[illumos-Developer] Proposal: Add memory clearing allocator to libnvpair

Samuel Younge Samuel.Younge at HolyRoyal.com
Wed Jan 26 18:11:12 PST 2011


Is there an easy way to keep referenced memory that affects the internals of IKE in a more protected space?

May you walk with God always,
<a href="mailto:Samuel.Younge at HolyRoyal.com">Samuel Younge</a><br />CEO-Founder and majority owner<br /><a href="http://holyroyal.com/">HolyRoyal Corporation - Advanced Internet and Systems Solutions</a><br /><a href="http://holyroyal.com/">http://www.HolyRoyal.com/</a><br />

On Jan 26, 2011, at 15:20, Garrett D'Amore <garrett at nexenta.com> wrote:

> Jason, I missed your original message.
> 
> That said, this sounds like an easy improvement.  I presume we are only
> talking about doing this for userland, and not for kernel space?
> 
> The reference passed into nvlist_xalloc is used to receive the pointer
> to the newly allocated structure.  Its done this way so that
> nvlist_alloc() and return different errnos on success.
> 
>    - Garrett
> 
> On Wed, 2011-01-26 at 14:52 -1000, Samuel Younge wrote:
>> It seems a bit troubling that nvlist_xalloc is accepting nvl as a reference rather than a value, but I cannot access my code base at the moment to be sure of this. What are your thoughts? Although, I like your intention of not leaving passwords pins key etc. hanging about.
>> 
>> 
>> 
>> On Jan 26, 2011, at 13:42, Jason King <jason.brian.king at gmail.com> wrote:
>> 
>>> Something that's hopefully minor and not controversial.  I was
>>> planning to do this for the work I'm doing with the IKEv2 support, but
>>> figured it's probably generally enough useful to live outside of it.
>>> 
>>> The libnvpair library (userland) normally uses the malloc/free
>>> commands for its memory requirements.  It also specifies a pluggable
>>> allocator interface for use with the nvlist_xalloc(3nvpair) and
>>> nvlist_xdup(3nvpair) function.  I would like to propose to add to
>>> libnvpair an allocator that zeros out the memory when allocated and
>>> freed.  This would be useful in situations where nvlists may contain
>>> sensitive information such as passwords/pins/keys/etc.
>>> 
>>> Specifically, add to libnvpair.h
>>> 
>>> extern nv_alloc_t *nv_alloc_zero;
>>> 
>>> Programs can then use (return codes elided for clarity):
>>> 
>>> nvlist_t *nvl;
>>> int flags = ...; /* NV_UNIQUE_NAME, NV_UNIQUE_NAME_TYPE or 0 */
>>> 
>>> nvlist_xalloc(&nvl, flags, nv_alloc_zero);
>>> ...
>>> add/remove data from nvlist
>>> ...
>>> nvlist_free(nvl);
>>> 
>>> And the memory used will be zeroed out before being returned to the
>>> system via free(3c).
>>> 
>>> _______________________________________________
>>> Developer mailing list
>>> Developer at lists.illumos.org
>>> http://lists.illumos.org/m/listinfo/developer
>> 
>> 
>> 
>> _______________________________________________
>> Developer mailing list
>> Developer at lists.illumos.org
>> http://lists.illumos.org/m/listinfo/developer
> 
> 





More information about the Developer mailing list