opnsense-src/crypto/README-sparse_array.md
Enji Cooper e4520c8bd1 openssl: Vendor import of OpenSSL-3.0.8
Summary:

Release notes can be found at
https://www.openssl.org/news/openssl-3.0-notes.html .

Obtained from:  https://www.openssl.org/source/openssl-3.0.8.tar.gz
Differential Revision:	https://reviews.freebsd.org/D38835

Test Plan:
```
$ git status
On branch vendor/openssl-3.0
nothing to commit, working tree clean
$ (cd ..; fetch http://www.openssl.org/source/openssl-${OSSLVER}.tar.gz http://www.openssl.org/source/openssl-${OSSLVER}.tar.gz.asc)
openssl-3.0.8.tar.gz                                    14 MB 4507 kBps    04s
openssl-3.0.8.tar.gz.asc                               833  B   10 MBps    00s
$ set | egrep '(XLIST|OSSLVER)='
OSSLVER=3.0.8
XLIST=FREEBSD-Xlist
$ gpg --list-keys
/home/ngie/.gnupg/pubring.kbx
-----------------------------
pub   rsa4096 2014-10-04 [SC]
      7953AC1FBC3DC8B3B292393ED5E9E43F7DF9EE8C
uid           [ unknown] Richard Levitte <richard@levitte.org>
uid           [ unknown] Richard Levitte <levitte@lp.se>
uid           [ unknown] Richard Levitte <levitte@openssl.org>
sub   rsa4096 2014-10-04 [E]

$ gpg --verify openssl-${OSSLVER}.tar.gz.asc openssl-${OSSLVER}.tar.gz
gpg: Signature made Tue Feb  7 05:43:55 2023 PST
gpg:                using RSA key 7953AC1FBC3DC8B3B292393ED5E9E43F7DF9EE8C
gpg: Good signature from "Richard Levitte <richard@levitte.org>" [unknown]
gpg:                 aka "Richard Levitte <levitte@lp.se>" [unknown]
gpg:                 aka "Richard Levitte <levitte@openssl.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7953 AC1F BC3D C8B3 B292  393E D5E9 E43F 7DF9 EE8C
$ (cd vendor.checkout/; git status; find . -type f -or -type l | cut -c 3- | sort > ../old)
On branch vendor/openssl-3.0
nothing to commit, working tree clean
$ tar -x -X $XLIST -f ../openssl-${OSSLVER}.tar.gz -C ..
$ rsync --exclude FREEBSD.* --delete -avzz ../openssl-${OSSLVER}/* .
$ cat .git
gitdir: /home/ngie/git/freebsd-src/.git/worktrees/vendor.checkout
$ diff -arq ../openssl-3.0.8  .
Only in .: .git
Only in .: FREEBSD-Xlist
Only in .: FREEBSD-upgrade
$ git status FREEBSD*
On branch vendor/openssl-3.0
nothing to commit, working tree clean
$
```

Reviewers: emaste, jkim

Subscribers: imp, andrew, dab

Differential Revision: https://reviews.freebsd.org/D38835
2023-03-06 12:41:29 -08:00

5.6 KiB

Sparse Arrays

The sparse_array.c file contains an implementation of a sparse array that attempts to be both space and time efficient.

The sparse array is represented using a tree structure. Each node in the tree contains a block of pointers to either the user supplied leaf values or to another node.

There are a number of parameters used to define the block size:

OPENSSL_SA_BLOCK_BITS   Specifies the number of bits covered by each block
SA_BLOCK_MAX            Specifies the number of pointers in each block
SA_BLOCK_MASK           Specifies a bit mask to perform modulo block size
SA_BLOCK_MAX_LEVELS     Indicates the maximum possible height of the tree

These constants are inter-related:

SA_BLOCK_MAX        = 2 ^ OPENSSL_SA_BLOCK_BITS
SA_BLOCK_MASK       = SA_BLOCK_MAX - 1
SA_BLOCK_MAX_LEVELS = number of bits in size_t divided by
                      OPENSSL_SA_BLOCK_BITS rounded up to the next multiple
                      of OPENSSL_SA_BLOCK_BITS

OPENSSL_SA_BLOCK_BITS can be defined at compile time and this overrides the built in setting.

As a space and performance optimisation, the height of the tree is usually less than the maximum possible height. Only sufficient height is allocated to accommodate the largest index added to the data structure.

The largest index used to add a value to the array determines the tree height:

    +----------------------+---------------------+
    | Largest Added Index  |   Height of Tree    |
    +----------------------+---------------------+
    | SA_BLOCK_MAX     - 1 |          1          |
    | SA_BLOCK_MAX ^ 2 - 1 |          2          |
    | SA_BLOCK_MAX ^ 3 - 1 |          3          |
    | ...                  |          ...        |
    | size_t max           | SA_BLOCK_MAX_LEVELS |
    +----------------------+---------------------+

The tree height is dynamically increased as needed based on additions.

An empty tree is represented by a NULL root pointer. Inserting a value at index 0 results in the allocation of a top level node full of null pointers except for the single pointer to the user's data (N = SA_BLOCK_MAX for brevity):

    +----+
    |Root|
    |Node|
    +-+--+
      |
      |
      |
      v
    +-+-+---+---+---+---+
    | 0 | 1 | 2 |...|N-1|
    |   |nil|nil|...|nil|
    +-+-+---+---+---+---+
      |
      |
      |
      v
    +-+--+
    |User|
    |Data|
    +----+
Index 0

Inserting at element 2N+1 creates a new root node and pushes down the old root node. It then creates a second second level node to hold the pointer to the user's new data:

    +----+
    |Root|
    |Node|
    +-+--+
      |
      |
      |
      v
    +-+-+---+---+---+---+
    | 0 | 1 | 2 |...|N-1|
    |   |nil|   |...|nil|
    +-+-+---+-+-+---+---+
      |       |
      |       +------------------+
      |                          |
      v                          v
    +-+-+---+---+---+---+      +-+-+---+---+---+---+
    | 0 | 1 | 2 |...|N-1|      | 0 | 1 | 2 |...|N-1|
    |nil|   |nil|...|nil|      |nil|   |nil|...|nil|
    +-+-+---+---+---+---+      +---+-+-+---+---+---+
      |                              |
      |                              |
      |                              |
      v                              v
    +-+--+                         +-+--+
    |User|                         |User|
    |Data|                         |Data|
    +----+                         +----+
Index 0                       Index 2N+1

The nodes themselves are allocated in a sparse manner. Only nodes which exist along a path from the root of the tree to an added leaf will be allocated. The complexity is hidden and nodes are allocated on an as needed basis. Because the data is expected to be sparse this doesn't result in a large waste of space.

Values can be removed from the sparse array by setting their index position to NULL. The data structure does not attempt to reclaim nodes or reduce the height of the tree on removal. For example, now setting index 0 to NULL would result in:

    +----+
    |Root|
    |Node|
    +-+--+
      |
      |
      |
      v
    +-+-+---+---+---+---+
    | 0 | 1 | 2 |...|N-1|
    |   |nil|   |...|nil|
    +-+-+---+-+-+---+---+
      |       |
      |       +------------------+
      |                          |
      v                          v
    +-+-+---+---+---+---+      +-+-+---+---+---+---+
    | 0 | 1 | 2 |...|N-1|      | 0 | 1 | 2 |...|N-1|
    |nil|nil|nil|...|nil|      |nil|   |nil|...|nil|
    +---+---+---+---+---+      +---+-+-+---+---+---+
                                     |
                                     |
                                     |
                                     v
                                   +-+--+
                                   |User|
                                   |Data|
                                   +----+
                              Index 2N+1

Accesses to elements in the sparse array take O(log n) time where n is the largest element. The base of the logarithm is SA_BLOCK_MAX, so for moderately small indices (e.g. NIDs), single level (constant time) access is achievable. Space usage is O(minimum(m, n log(n)) where m is the number of elements in the array.

Note: sparse arrays only include pointers to types. Thus, SPARSE_ARRAY_OF(char) can be used to store a string.