Understanding Host Storage in Suricata: How Data Areas Are Allocated and Managed

Suricata employs various storage types for small thread-sharing spaces, such as Host storage. This data area is used to store shared data when implementing the threshold option:

threshold option-> type threshold , track by_dst, count 5, seconds 60

This means that only after hitting 5 times within one minute will an alert be generated. The timestamp and hit count are stored in this small, locked namespace. Locking is necessary because multiple threads will read and write to this area simultaneously, and naming means that the data area types can be distinguished.

1. Storage registration

The storage data area is summed up using a registration function, storing the digest of the data areas that need to be created. This step does not involve real space allocation.

For example, storag_list->”threshold 20 bytes mallco free”->”test 8 bytes myalloc my free”->… …

2. Host storage

The real creation of the data area requires the use of the structure Host. I understand it as a kind of key. Upon power-on, some host objects will be pre-allocated. Creating a host object does not only allocate sizeof(host) but also allocates several void* in excess. The number corresponds to the registered storage data area. Later, this host can find each data area through the offset sizeof(host)+id. Each host will allocate its own data area without interfering with each other. Because Host objects are locked, obtaining a host will involve operations like HostGetHostFromHash and HostRelease.

3. Host storage allocation data area process

The Host object is responsible for reading and writing the data area. It can call the registered malloc to allocate a number of bytes of size, or it can be set as a pointer to another data area.