Prevent addition overflow

[vicsn]

Motivation

We should avoid panics, this PR adds checking if additions are allowed in snarkVM. I could not find problematic subtraction cases.

For this, we should agree on the attack surface. I can imagine the following attack vectors:

• an attacker lets different nodes misinterpret a serialized object, which can happen if our flags are serialized last. Fortunately I haven't seen this anywhere.
• an attacker's frontend lets an honest user serialize a giant object so their local node panics, I don't think this is a huge issue
• an attacker lets an honest node deserialize a giant object so it panics. This might kill the network so we should prevent this. Nodes already seem to have a maximum message size, but as defense in depth I use saturating_add in serialized_size. Using checked_add there is tricky as it will change the serialized_size trait function signature all over the codebase, including in macros and for types which we know have a fixed size.

Test Plan

Our usual test suite

Related PRs

Merging into https://github.com/AleoHQ/snarkVM/pull/1499

[ljedrz]

A note on the maximum network message size: that size is stored in a length prefix, and only as many bytes can be read from the network in order to form a single inbound message. The implications for deserialization of individual objects are as follows:

• no message with a size greater than MAXIMUM_MESSAGE_SIZE can be accepted from the network
• if the length prefix indicates that the message is within bounds, but some object inside it suggests that there is a lot more bytes to read, it will just run out of bytes to process while deserializing, and the operation will fail

The main potential issue I can see (other than the potential overflows that this PR tackles) is pre-allocating too many bytes (if the collection length is stored as a u64 or a lower value, but with large items).

[vicsn]

The main potential issue I can see (other than the potential overflows that this PR tackles) is pre-allocating too many bytes (if the collection length is stored as a u64 or a lower value, but with large items).

Hmm good point! Continuing discussion of this elsewhere, as it ties into how to handle usize/u64/u32 in the codebase which I'll tackle further in a different PR.

[vicsn]

Closing as severely outdated