Cyrus IMAP Server: Sieve Bytecode

Motivation

The motivation behind moving to Sieve Bytecode is severalfold:

• Parsing a script at each execution is expensive computationally
• Lex/Yacc are costly in terms of memory usage and executable size, whereas a bytecode parser is much lighter weight.
• Using bytecode can simplify the code for the execution phase, which is far more frequently occurring than the upload/compile phase.
• Rewriting a significant part of the sieve execution framework forces a decent amount of refactoring on what has traditionally been a problematic part of the Cyrus code base. There is still work to do in this area.

Overall Bytecode Format

In the final bytecode, each opcode/parameter is aligned on a 4-byte boundary. Strings are NUL-terminated (and padded to a 4-byte boundary as needed).

Ideally, we'd have all integers in network byte order, so as to make the scripts portable, but version 1 does not have this feature.

At the beginning of the file, there is a magic header to identify it as a bytecode file, and a 4 byte version number. Immediately following the version number are the opcodes that relate to the script.

Generation

A Sieve Bytecode file is generated in three "passes":

• Generate a parse tree using lex/yacc from the sieve script. (addr.y, addr-lex.l, sieve.y, sieve-lex.l).
• Serialize the parse tree into an intermediate form, where strings are held separate from the rest of the representation. (bc_generate.c)
• Serialize the intermediate form into the final bytecode. (bc_emit.c)

The intermediate form is an array of bytecode_t unions, with strings located elsewhere in memory. The entry point is bc_generate: sieve_generate_bytecode() / bc_action_generate().

bc_action_generate traverses the commandlist_t tree and emits opcodes in sequence.

Simple actions (STOP, DISCARD, KEEP, MARK, UNMARK) have no arguments, and processing proceeds directly.

More complicated options have a sequence of arguments that are emitted following the initial opcode.

For example, single argument commands such as REJECT, FILEINTO, REDIRECT are followed by a bytecode_t for a string's length, and then a bytecode_t which contains a pointer to a string.

Commands such as ADDFLAG, SETFLAG, REMOVEFLAG, which take a stringlist, format the stringlist as (using bc_stringlist_generate):

{Number of Strings}{String 1 Length}{String 1 Ptr}{String 2 Length}....

So their resulting final output would appear as:

{Opcode}{...stringlist from above...}

Even more complicated action opcodes (vacation, notify) etc, may take a sequence of integer values (flags), stringlists, or individual strings. These are more specifically documented in the code.

This leaves us with the IF keyword (and tests). In the pass 1 form, IF appears as the following bytecode_t structures:

{IF opcode}
{Beginning of the then block}
{End of the then block / beginning of the else block}
{End of the else block / -1 for no else block}
{....test opcodes....}
{....'then' action opcodes....}
{....'else' action opcodes.... [optional]}

Test opcodes are generated by the bc_test_generate function, which is very similar to bc_action_generate (tests without arguments are just opcodes, tests with arguments have them serialized into place directly following the original opcode). Test lists are represented as {number of tests}{address of the end of the list}{test 1}{test 2}.

In the third pass, strings are serialized into place, and if statement jumps are resolved to actual addresses within the file This is done in bc_emit: sieve_emit_bytecode / bc_action_emit.

This results in a totally serialized representation, using byte offsets within the file instead of indexes into the array of bytecode_t's. In addition to the manipulations that are necessary to do this, there are several other changes in format.

Two new opcodes exist: NULL and JUMP (which performs an unconditional jump).

Stringlists and testslists now include a precomputed byte length of the entire list, so it can be skipped over as needed.

So as to be executable without a stack, the IF statements are designed as follows:

{IF opcode}
{....test block....}
{JUMP (location of false condition) }
{....then block....}
{(if there is an else) JUMP (end of else block)}
{(if there is an else) .... else block ....}

The idea being that if the test is true, the instruction pointer should move to the then block, otherwise the else block will be hit automatically (due to the unconditional jump).

Evaluation

The evaluation routines are in bc_eval.c, the basic idea is that we can simply mmap the bytecode, run straight through it, and complete the processing without maintaining a stack.

The processing is done by overlaying a bytecode_input_t array over the mmap. This allows addressing elements within the file to be simple. There is an instruction pointer which is incremented as each action is performed, or as actions/tests are skipped.

Of special note in bc_eval.c is the unwrap_string function which will pull a string out of the bytecode, and return the instruction pointer at the end of the string.

Other things to consider

The Bytecode can be extended to contain other extensions. This could require regeneration of older scripts. In many cases this can be avoided by putting the new commands at the end of the proper enum in bytecode.h