project-everest / mitls-fstar

Verified implementation of TLS 1.3 in F*
https://www.mitls.org
Other
173 stars 16 forks source link

Garbage Collection #215

Closed CarolineMathieson closed 6 years ago

CarolineMathieson commented 6 years ago

After ffi_mitls_init () is called then ffi_mitls_config () is called repeatedly by all the apps running in the system, memory is allocated for each connection. If this memory is not freed because the app crashes or something else, then it will accumulate and then after a while the system will run out of memory.

What steps, if any, are taken by the dll to garbage collect the memory no longer used by any application?

Is a record kept of when the memory is allocated so that if it is not used for a long time it can be freed?

I would suggest that a garbage collector be added to the dll so that this can be done if the dll is to be used in kernel mode and running for significant periods of time.

BarryBo commented 6 years ago

FFI_mitls_configure() allocates a fresh heap region and makes allocations into it. It is the app's responsibility to free that memory by calling FFI_mitls_close().

In usermode, if the app that called FFI_mitls_configure() crashes before calling FFI_mitls_close(), then nothing is leaked, as the entire process address space is freed.

In kernelmode, the caller is responsible for avoiding a crash, and ensuring there is a matching FFI_mitls_close() call.

No GC is needed.