malloc, free, strdup and kernel builds

[Mark Stevens <ma...@thepcsite.co.uk>]

So this post has been triggered by an issue I have just had using strdup in the OS components of a protected mode build.

For clarity I will be using the term OS for the kernel part of the build and application/app for the user part of the build.

The TLDR; is this design question:

Do we expect malloc and free to work with the relevant heaps?  So for the OS should they be working with the kernel heap and for apps they should be using the user heap?

I am trying to work out if the problem is with strdup or with malloc & free.


Investigation / background

My understanding of strdup is that any string generated should have its memory released using free, at least that is the way I have been using it for years.

The system under development uses a protected/kernel build with a memory protection unit.  We also have two heaps, one for the OS and one for the app.

At some point in the OS lifecycle we have the need to generate copies of strings.  These were generated using strdup.  At some point in the future these strings were released using free.  At a point further in the future the system crashed.

After some tracking it turns out that strdup was allocating memory using the kernel heap (the strings were duplicated in the OS) and then freed in the OS but the memory was being released to the user (Application) heap.  When this was then later allocated and used in user space the system would crash with a memory fault.

Investigation points to the fact that strdup uses lib_malloc which will call kmm_malloc in OS builds and malloc in app builds.

It also appears that malloc and free always work with the user heap.

I know that our build is a little old but looking at the sources this seems to be the case with the current release.  I am struggling to get the protected build working on a F767 board to verify if the problem is still present.

Regards,
Mark
_____________________________
Blog: blog.thepcsite.co.uk
Twitter: @nevynuk

Re: malloc, free, strdup and kernel builds

[Mark Stevens <ma...@thepcsite.co.uk>]

Thanks you for taking the time to respond.

I think I will look at providing kmm_strdup and submit a PR with the fix.  It will probably be safer to do this and reduce the possibly of disturbing existing code with changes to the definition of free.

Regards,
Mark
_____________________________
Blog: blog.thepcsite.co.uk
Twitter: @nevynuk





> On 21 Sep 2022, at 17:24, Gregory Nutt <sp...@gmail.com> wrote:
> 
> This does not seem like a technical issue but rather awkward usage/naming that is prone to misuse.
> 
> Yes, free() should be called to release the memory allocated by strdup. But applications cannot use the kernel heap and, for reasons of protection, the kernel should not store anything in the user-accessible application heap in Protected mode.  In Kernel mode, the application heap may not even be available to OS without switching the address environment.
> 
> So I think that a clean solution would be to fix the naming, either:  (1) rename the stdup used by the OS to kmm_strdup() with allocated memory freed by kmm_free(), or (2) conditionally redefine free() to be kmm_free() in the kernel portion of the build.
> 
> kmm_free() is already defined as free() in the FLAT build in include/nuttx/kmalloc.h
> 
> On 9/21/2022 9:59 AM, Mark Stevens wrote:
>> So this post has been triggered by an issue I have just had using strdup in the OS components of a protected mode build.
>> 
>> For clarity I will be using the term OS for the kernel part of the build and application/app for the user part of the build.
>> 
>> The TLDR; is this design question:
>> 
>> Do we expect malloc and free to work with the relevant heaps?  So for the OS should they be working with the kernel heap and for apps they should be using the user heap?
>> 
>> I am trying to work out if the problem is with strdup or with malloc & free.
>> 
>> 
>> Investigation / background
>> 
>> My understanding of strdup is that any string generated should have its memory released using free, at least that is the way I have been using it for years.
>> 
>> The system under development uses a protected/kernel build with a memory protection unit.  We also have two heaps, one for the OS and one for the app.
>> 
>> At some point in the OS lifecycle we have the need to generate copies of strings.  These were generated using strdup.  At some point in the future these strings were released using free.  At a point further in the future the system crashed.
>> 
>> After some tracking it turns out that strdup was allocating memory using the kernel heap (the strings were duplicated in the OS) and then freed in the OS but the memory was being released to the user (Application) heap.  When this was then later allocated and used in user space the system would crash with a memory fault.
>> 
>> Investigation points to the fact that strdup uses lib_malloc which will call kmm_malloc in OS builds and malloc in app builds.
>> 
>> It also appears that malloc and free always work with the user heap.
>> 
>> I know that our build is a little old but looking at the sources this seems to be the case with the current release.  I am struggling to get the protected build working on a F767 board to verify if the problem is still present.
>> 
>> Regards,
>> Mark
>> _____________________________
>> Blog: blog.thepcsite.co.uk
>> Twitter: @nevynuk
>> 
>> 
>> 
>> 
>> 
> 

Re: malloc, free, strdup and kernel builds

[Gregory Nutt <sp...@gmail.com>]

This does not seem like a technical issue but rather awkward 
usage/naming that is prone to misuse.

Yes, free() should be called to release the memory allocated by strdup. 
But applications cannot use the kernel heap and, for reasons of 
protection, the kernel should not store anything in the user-accessible 
application heap in Protected mode.  In Kernel mode, the application 
heap may not even be available to OS without switching the address 
environment.

So I think that a clean solution would be to fix the naming, either:  
(1) rename the stdup used by the OS to kmm_strdup() with allocated 
memory freed by kmm_free(), or (2) conditionally redefine free() to be 
kmm_free() in the kernel portion of the build.

kmm_free() is already defined as free() in the FLAT build in 
include/nuttx/kmalloc.h

On 9/21/2022 9:59 AM, Mark Stevens wrote:
> So this post has been triggered by an issue I have just had using strdup in the OS components of a protected mode build.
>
> For clarity I will be using the term OS for the kernel part of the build and application/app for the user part of the build.
>
> The TLDR; is this design question:
>
> Do we expect malloc and free to work with the relevant heaps?  So for the OS should they be working with the kernel heap and for apps they should be using the user heap?
>
> I am trying to work out if the problem is with strdup or with malloc & free.
>
>
> Investigation / background
>
> My understanding of strdup is that any string generated should have its memory released using free, at least that is the way I have been using it for years.
>
> The system under development uses a protected/kernel build with a memory protection unit.  We also have two heaps, one for the OS and one for the app.
>
> At some point in the OS lifecycle we have the need to generate copies of strings.  These were generated using strdup.  At some point in the future these strings were released using free.  At a point further in the future the system crashed.
>
> After some tracking it turns out that strdup was allocating memory using the kernel heap (the strings were duplicated in the OS) and then freed in the OS but the memory was being released to the user (Application) heap.  When this was then later allocated and used in user space the system would crash with a memory fault.
>
> Investigation points to the fact that strdup uses lib_malloc which will call kmm_malloc in OS builds and malloc in app builds.
>
> It also appears that malloc and free always work with the user heap.
>
> I know that our build is a little old but looking at the sources this seems to be the case with the current release.  I am struggling to get the protected build working on a F767 board to verify if the problem is still present.
>
> Regards,
> Mark
> _____________________________
> Blog: blog.thepcsite.co.uk
> Twitter: @nevynuk
>
>
>
>
>