Network Working Group Richard Price, Siemens/Roke Manor
INTERNET-DRAFT Abigail Surtees, Siemens/Roke Manor
Expires: April 2003
October 25, 2002
SigComp Torture Tests
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@ietf.org.
Abstract
This document provides a set of "torture tests" for implementers of
the SigComp protocol. The torture tests check each of the SigComp
Universal Decompressor Virtual Machine instructions in turn, focusing
in particular on the boundary and error cases that are not generally
encountered when running well-behaved compression algorithms.
Price et al. [Page 1]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
Table of contents
1. Introduction..................................................2
2. Terminology...................................................2
3. Torture tests.................................................2
4. Security considerations.......................................20
5. Authors' addresses............................................20
6. References....................................................20
Appendix A: UDVM bytecode for the torture tests...................21
1. Introduction
This document provides a set of torture tests for implementers of the
SigComp protocol [SIGCOMP]. The idea behind SigComp is to standardize
a Universal Decompressor Virtual Machine (UDVM) that can be
programmed to understand the output of many well-known compressors
including DEFLATE and LZW. The bytecode for the chosen decompressor
is uploaded to the UDVM as part of the SigComp message flow.
The SigComp User Guide [USERGUIDE] offers a number of different
algorithms that can be used by the SigComp protocol. However, the
bytecode for the corresponding decompressors is relatively well
behaved and does not test the boundary and error cases that may
potentially be exploited by malicious SigComp messages.
The draft is divided into a number of sections, each containing a
piece of code designed to test one or more UDVM instructions. The
specific boundary and error cases tested by the bytecode are also
listed, as is the expected output of the code.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].
3. Torture tests
The following sections each provide code to test one or more UDVM
instructions. In the interests of readability the code is given using
the SigComp assembly language: a description of how to convert this
assembly code into UDVM bytecode can be found in the SigComp User
Guide [USERGUIDE].
The raw UDVM bytecode for each torture test is given in Appendix A.
Each section also lists the number of UDVM cycles required to execute
the code. Note that this figure only takes into account the cost of
Price et al. [Page 2]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
executing each UDVM instruction (in particular it ignores the fact
that the UDVM can gain extra cycles as a result of inputting more
data).
3.1. Bit manipulation
This section gives assembly code to test the AND, OR, NOT, LSHIFT and
RSHIFT instructions. When the instructions have a multitype operand
the code tests the case where the multitype contains a fixed integer
value, and the case where it contains a memory address at which the
2-byte operand value can be found. In addition the code is designed
to test that the following boundary cases have been correctly
implemented:
1. The instructions overwrite themselves with the result of the bit
manipulation operation.
2. The LSHIFT or RSHIFT instructions shift bits beyond the 2-byte
boundary, in which case the bits must be discarded.
3. The UDVM registers byte_copy_left and byte_copy_right are used to
store the results of the bit manipulation operations. Since no byte
copying is taking place these registers should behave in exactly the
same manner as ordinary UDVM memory addresses.
at (64)
:a pad (2)
:b pad (2)
at (128)
JUMP (start)
at (255)
:start
AND ($start, 21845)
OR ($a, 42)
NOT ($b)
LSHIFT ($a, 3)
RSHIFT ($b, 65535)
OUTPUT (64, 4)
AND ($a, $start)
OR ($a, $a)
NOT ($a)
LSHIFT ($b, $a)
RSHIFT ($a, $b)
Price et al. [Page 3]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
OUTPUT (64, 4)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
The expected output of the code is 0x0150 0000 febf 0000. Executing
the code should cost a total of 22 UDVM cycles.
3.2. Arithmetic
This section gives assembly code to test the ADD, SUBTRACT, MULTIPLY,
DIVIDE and REMAINDER instructions. The code is designed to test that
the following boundary cases have been correctly implemented:
1. The instructions overwrite themselves with the result of the
arithmetic operation.
2. The result does not lie between 0 and 2^16 - 1 inclusive, in which
case it must be taken modulo 2^16.
3. The divisor in the DIVIDE or REMAINDER instructions is 0 (in which
case decompression failure should occur).
at (64)
:a pad (2)
:b pad (2)
:type pad (1)
:type_lsb pad (1)
at (128)
INPUT-BYTES (1, type_lsb, !)
SUBTRACT ($type, 1)
JUMP (start)
at (255)
:start
ADD ($start, 63809)
SUBTRACT ($a, 1)
MULTIPLY ($a, 1001)
DIVIDE ($a, 101)
REMAINDER ($a, 11)
OUTPUT (64, 4)
ADD ($b, $start)
SUBTRACT ($b, $type)
MULTIPLY ($b, $b)
DIVIDE ($a, $b)
Price et al. [Page 4]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
REMAINDER ($b, $type)
OUTPUT (64, 4)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
If the compressed message is 0x00 then the expected output of the
code is 0x0000 0000 0000 0004 and the execution cost should be 25
UDVM cycles. However, if the compressed message is 0x01 or 0x02 then
decompression failure should occur.
3.3. Sorting
This section gives assembly code to test the SORT-ASCENDING and SORT-
DESCENDING instructions. The code is designed to test that the
following boundary cases have been correctly implemented:
1. The sorting instructions sort integers with the same value, in
which case the original ordering of the integers must be preserved.
at (128)
SORT-DESCENDING (256, 2, 23)
SORT-ASCENDING (256, 2, 23)
OUTPUT (302, 45)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
at (256)
word (10, 10, 17, 7, 22, 3, 3, 3, 19, 1, 16, 14, 8, 2, 13, 20, 18,
23, 15, 21, 12, 6, 9)
word (28263, 8297, 30057, 8308, 26996, 11296, 31087, 29991, 8275,
18031, 28263, 24864, 30066, 29284, 28448, 29807, 28206, 11776, 28773,
28704, 28276, 29285, 28265)
The expected output of the code is 0x466f 7264 2c20 796f 7527 7265
2074 7572 6e69 6e67 2069 6e74 6f20 6120 7065 6e67 7569 6e2e 2053 746f
7020 6974 2e, and the expected number of cycles required is 279.
3.4. SHA-1
This section gives assembly code to test the SHA-1 instruction. The
code performs four tests on the SHA-1 algorithm itself, and
additionally checks the following boundary cases specific to the
UDVM:
1. The input string for the SHA-1 hash is obtained by byte copying
over an area of the UDVM memory.
2. The SHA-1 hash overwrites its own input string.
Price et al. [Page 5]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:hash_value pad (20)
at (128)
SHA-1 (test_one, 3, hash_value)
OUTPUT (hash_value, 20)
SHA-1 (test_two, 56, hash_value)
OUTPUT (hash_value, 20)
LOAD (byte_copy_left, test_three)
LOAD (byte_copy_right, test_four)
SHA-1 (test_three, 65535, hash_value)
OUTPUT (hash_value, 20)
LOAD (byte_copy_left, test_four)
LOAD (byte_copy_right, test_end)
SHA-1 (test_four, 640, test_four)
OUTPUT (test_four, 20)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
:test_one
byte (97, 98, 99)
:test_two
byte (97, 98, 99, 100, 98, 99, 100, 101, 99, 100, 101, 102, 100, 101,
102, 103, 101, 102, 103, 104, 102, 103, 104, 105, 103, 104, 105, 106,
104, 105, 106, 107, 105, 106, 107, 108, 106, 107, 108, 109, 107, 108,
109, 110, 108, 109, 110, 111, 109, 110, 111, 112, 110, 111, 112, 113)
:test_three
byte (97)
:test_four
byte (48, 49, 50, 51, 52, 53, 54, 55)
:test_end
The expected output of the code is as follows:
Price et al. [Page 6]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
0xa999 3e36 4706 816a ba3e 2571 7850 c26c 9cd0 d89d
0x8498 3e44 1c3b d26e baae 4aa1 f951 29e5 e546 70f1
0xe1d0 a18d 43d3 a689 af08 8e15 6bd0 434a a0c8 31fc
0x4f46 0452 ebb5 6393 4f46 0452 ebb5 6393 4f46 0452
Executing the code is expected to cost a total of 66327 UDVM cycles.
3.5. LOAD and MULTILOAD
This section gives assembly code to test the LOAD and MULTILOAD
instructions. The code is designed to test the following boundary
cases:
1. The MULTILOAD instruction overwrites itself, any of its operands,
or any memory addresses referenced by its operands (in which case
decompression failure should occur).
at (64)
:start pad (1)
:start_lsb pad (1)
at (128)
set (location_a, 128)
set (location_b, 132)
LOAD (128, 132)
LOAD (130, $location_a)
LOAD ($location_a, 134)
LOAD ($location_b, $location_b)
OUTPUT (128, 8)
INPUT-BYTES (1, start_lsb, !)
MULTIPLY ($start, 2)
ADD ($start, 60)
MULTILOAD ($start, 3, overlap_start, overlap_end, 128)
:position
set (overlap_start, (position - 7))
MULTILOAD ($start, 4, 42, 128, $location_a, $location_b)
:end
set (overlap_end, (end - 1))
OUTPUT (128, 8)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
Price et al. [Page 7]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
If the compressed message is 0x00 then the expected output of the
code is 0x0084 0084 0086 0086 002a 0080 002a 002a, and the expected
cost of executing the code is 36 UDVM cycles. However, if the
compressed message is 0x01 or 0x02 then decompression failure is
expected to occur while executing the second MULTILOAD instruction.
This section gives assembly code to test the COPY instruction. The
code is designed to test that the following boundary cases have been
correctly implemented:
1. The COPY instruction copies data from both outside the circular
buffer and inside the circular buffer within the same operation.
2. The COPY instruction performs byte-by-byte copying (i.e. some of
the later bytes to be copied are themselves written into the UDVM
memory by the COPY instruction currently being executed).
3. The COPY instruction overwrites itself.
4. The COPY instruction overwrites the UDVM registers byte_copy_left
and byte_copy_right.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
at (128)
LOAD (32, 16384)
LOAD (byte_copy_left, 64)
LOAD (byte_copy_right, 128)
COPY (32, 128, 33)
LOAD (64, 16640)
COPY (64, 76, 65)
OUTPUT (32, 109)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
The expected output of the code is 32 consecutive instances of 0x40
(the ASCII character "@") followed by 77 consecutive instances of
0x41 (the ASCII character "A"). Executing the code should cost a
total of 321 UDVM cycles.
Price et al. [Page 8]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
3.7. COPY-LITERAL and COPY-OFFSET
This section gives assembly code to test the COPY-LITERAL and COPY-
OFFSET instructions. The code is designed to test similar boundary
cases to the code for the COPY instruction, as well as the following
condition specific to COPY-LITERAL and COPY-OFFSET:
1. The COPY-LITERAL or COPY-OFFSET instruction overwrites the value
of its destination or offset operand.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:destination pad (2)
:offset pad (2)
at (128)
LOAD (32, 16384)
LOAD (byte_copy_left, 64)
LOAD (byte_copy_right, 128)
LOAD (destination, 33)
COPY-LITERAL (32, 128, $destination)
COPY-LITERAL (68, 8, $destination)
LOAD (byte_copy_left, 66)
LOAD (byte_copy_right, 74)
COPY-OFFSET (8, 6, $destination)
LOAD ($offset, 1)
COPY-OFFSET ($offset, 5 ,$destination)
OUTPUT (32, 48)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
The expected output of the code is 32 instances of 0x40 followed by
0x0042 004a 0074 4040 4040 004a 0074 4040. The expected cost of
executing the code is 208 UDVM cycles.
N.B. This uses the corrected cost for COPY-OFFSET, which is 1 +
length not 1 + length + offset.
Price et al. [Page 9]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
3.8. MEMSET
This section gives assembly code to test the MEMSET instruction. The
code is designed to test that the following boundary cases have been
correctly implemented:
1. The MEMSET instruction overwrites the registers byte_copy_left and
byte_copy_right.
2. The output values of the MEMSET instruction do not lie between 0
and 255 inclusive (in which case they must be taken modulo 2^8).
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
at (128)
LOAD (byte_copy_left, 128)
LOAD (byte_copy_right, 129)
MEMSET (64, 129, 0, 1)
MEMSET (129, 15, 64, 15)
OUTPUT (128, 16)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
The expected output of the code is 0x8040 4f5e 6d7c 8b9a a9b8 c7d6
e5f4 0312. Executing the code is expected to cost 166 UDVM cycles.
This section gives assembly code to test the CRC instruction. The
code does not test any specific boundary cases (as there do not
appear to be any) but focuses instead on verifying the CRC algorithm.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:crc_value pad (2)
:crc_string_a pad (24)
:crc_string_b pad (20)
at (128)
MEMSET (crc_string_a, 24, 1, 1)
MEMSET (crc_string_b, 20, 128, 1)
INPUT-BYTES (2, crc_value, !)
Price et al. [Page 10]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
CRC ($crc_value, crc_string_a, 44, !)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
If the compressed message is 0x62cb then the code should successfully
terminate with no output, and with a total execution cost of 95 UDVM
cycles. For different 2-byte compressed messages the code should
terminate with a decompression failure.
3.10. INPUT-BITS
This section gives assembly code to test the INPUT-BITS instruction.
The code is designed to test that the following boundary cases have
been correctly implemented:
1. The INPUT-BITS instruction changes between any of the four
possible bit orderings defined by the input_bit_order register.
2. The INPUT-BITS instruction inputs 0 bits.
3. The INPUT-BITS instruction requests data that lies beyond the end
of the compressed message.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:result pad (2)
at (128)
:start
INPUT-BITS ($input_bit_order, result, end_of_message)
OUTPUT (result, 2)
ADD ($input_bit_order, 1)
REMAINDER ($input_bit_order, 7)
ADD ($input_bit_order, 1)
JUMP (start)
:end_of_message
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
An example compressed message is 0x932e ac71, which decompresses to
give the output 0x0000 0002 0002 0013 0000 0003 001a 0038. Executing
the code should cost 66 UDVM cycles.
Price et al. [Page 11]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
3.11. INPUT-HUFFMAN
This section gives assembly code to test the INPUT-HUFFMAN
instruction. The code is designed to test that the following boundary
cases have been correctly implemented:
1. The INPUT-HUFFMAN instruction changes between any of the four
possible bit orderings defined by the input_bit_order register.
2. The INPUT-HUFFMAN instruction inputs 0 bits.
3. The INPUT-HUFFMAN instruction requests data that lies beyond the
end of the compressed message.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:result pad (2)
at (128)
:start
INPUT-HUFFMAN (result, end_of_message, 2, $input_bit_order, 0,
$input_bit_order, $input_bit_order, $input_bit_order, 0, 65535, 0)
OUTPUT (result, 2)
ADD ($input_bit_order, 1)
REMAINDER ($input_bit_order, 7)
ADD ($input_bit_order, 1)
JUMP (start)
:end_of_message
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
An example compressed message is 0x932e ac71 66d8 6f, which
decompresses to give the output 0x0000 0003 0008 04d7 0002 0003 0399
30fe. Executing the code should cost 84 UDVM cycles.
3.12. INPUT-BYTES
This section gives assembly code to test the INPUT-BYTES instruction.
The code is designed to test that the following boundary cases have
been correctly implemented:
1. The INPUT-BYTES instruction inputs 0 bytes.
Price et al. [Page 12]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
2. The INPUT-BYTES instruction requests data that lies beyond the end
of the compressed message.
3. The INPUT-BYTES instruction is used after part of a byte has been
inputted (e.g. by the INPUT-BITS instruction).
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:result pad (2)
:output_start pad (4)
:output_end
at (128)
LOAD (byte_copy_left, output_start)
LOAD (byte_copy_right, output_end)
:start
INPUT-BITS ($input_bit_order, result, end_of_message)
OUTPUT (result, 2)
ADD ($input_bit_order, 2)
REMAINDER ($input_bit_order, 7)
INPUT-BYTES ($input_bit_order, output_start, end_of_message)
OUTPUT (output_start, $input_bit_order)
ADD ($input_bit_order, 1)
JUMP (start)
:end_of_message
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
An example compressed message is 0x932e ac71 66d8 6fb1 592b dc9a 9734
d847 a733 874e 1bcb cd51 b5dc 9659 9d6a, which decompresses to give
the output 0x0000 932e 0001 b166 d86f b100 1a2b 0003 9a97 34d8 0007
0001 3387 4e00 08dc 9651 b5dc 9600 599d 6a. Executing the code should
cost 130 UDVM cycles.
3.13. Stack manipulation
This section gives assembly code to test the PUSH, POP, CALL and
RETURN instructions. The code is designed to test that the following
boundary cases have been correctly implemented:
Price et al. [Page 13]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
1. The stack manipulation instructions overwrite the UDVM register
stack_location.
2. The stack manipulation instructions overwrite themselves.
3. The CALL instruction specifies a reference operand rather than an
absolute value.
4. The PUSH instruction pushes the value contained in stack_fill onto
the stack.
5. The stack_location register contains an odd integer.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:stack_location pad (2)
:next_address pad (2)
at (128)
LOAD (stack_location, 64)
PUSH (2)
PUSH ($64)
PUSH (66)
OUTPUT (64, 8)
POP (64)
POP ($stack_location)
POP (stack_location)
OUTPUT (64, 8)
JUMP (address_a)
at (192)
:address_a
LOAD (next_address, address_c)
SUBTRACT ($next_address, address_b)
CALL (address_b)
at (256)
:address_b
CALL ($next_address)
Price et al. [Page 14]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
at (320)
:address_c
LOAD (stack_location, 383)
LOAD (383, 26)
MULTILOAD (432, 3, 1, 49153, 32768)
RETURN
at (448)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
The expected output of the code is 0x0003 0002 0001 0042 0042 0000
0001 0001, and a total of 39 UDVM cycles are expected to be used.
3.14. Program flow
This section gives assembly code to test the JUMP, COMPARE and SWITCH
instructions. The code is designed to test that the following
boundary cases have been correctly implemented:
1. The address operands are specified as references to memory
addresses rather than as absolute values.
at (64)
:next_address pad (2)
:counter pad (1)
:counter_lsb pad (1)
:switch_counter pad (2)
at (128)
LOAD (switch_counter, 4)
:address_a
LOAD (next_address, address_c)
SUBTRACT ($next_address, address_b)
OUTPUT (counter_lsb, 1)
:address_b
JUMP ($next_address)
:address_c
ADD ($counter, 1)
LOAD (next_address, address_a)
SUBTRACT ($next_address, address_d)
Price et al. [Page 15]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
OUTPUT (counter_lsb, 1)
:address_d
COMPARE ($counter, 6, $next_address, address_c, address_e)
:address_e
SUBTRACT ($switch_counter, 1)
LOAD (next_address, address_a)
SUBTRACT ($next_address, address_f)
OUTPUT (counter_lsb, 1)
:address_f
SWITCH (4, $switch_counter, address_g, $next_address, address_c,
address_e)
:address_g
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
The expected output of the code is 0x0001 0102 0203 0304 0405 0506
0707 0708 0808 0909, and a total of 131 UDVM cycles are expected to
be used.
3.15. State creation
This section gives assembly code to test the STATE-CREATE and STATE-
FREE instructions. The code is designed to test that the following
boundary cases have been correctly implemented:
1. An item of state is created that duplicates an existing state
item.
2. An item of state is freed when the state has not been created.
3. An item of state is created and then freed by the same message.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:states pad (1)
:states_lsb pad (1)
set (state_length, 10)
at (128)
INPUT-BYTES (1, states_lsb, !)
Price et al. [Page 16]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
:test_one
LSHIFT ($states, 13)
COMPARE ($states, 32768, test_two, create_state_a, create_state_a)
:create_state_a
STATE-CREATE (state_length, state_address, 0, 20, 0)
:test_two
LSHIFT ($states, 1)
COMPARE ($states, 32768, test_three, free_state, free_state)
:free_state
STATE-FREE (state_identifier, 6)
:test_three
LSHIFT ($states, 1)
COMPARE ($states, 32768, end, create_state_b, create_state_b)
:create_state_b
END-MESSAGE (0, 0, state_length, state_address, 0, 20, 0)
:end
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
at (512)
:state_address
byte (34, 162, 6, 4, 22, 224, 116, 101, 115, 116)
:state_identifier
byte (32, 84, 55, 65, 83, 248, 254, 122, 106, 151, 203, 121, 224, 24,
194, 221, 214, 143, 254, 155)
Upon reaching the END-MESSAGE instruction the UDVM does not output
any decompressed data, but instead may make one or more state
creation or state free requests to the state handler. Assuming that
the application does not veto the state creation request (and that
sufficient state memory is available) the code should result in
either 0 or 1 new state items being created in the chosen
compartment.
Price et al. [Page 17]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
The following table lists eight different 1-byte compressed messages
and whether the message should cause a new state item to be created
in the compartment. The number of UDVM cycles required to execute the
code is also given:
Compressed message: State item in compartment: UDVM cycles:
0x00 No 9
0x01 Yes 19
0x02 No 10
0x03 Yes 20
0x04 Yes 20
0x05 Yes 30
0x06 No 21
0x07 Yes 31
3.16. STATE-ACCESS
This section gives assembly code to test the STATE-ACCESS
instruction. The code is designed to test that the following boundary
cases have been correctly implemented:
1. A subset of the bytes contained in a state item are copied to the
UDVM memory.
2. Bytes are copied from beyond the end of the state value.
3. The state_instruction operand is set to 0.
4. The state cannot be accessed because the partial state identifier
is too short.
5. The state identifier is overwritten by the state item being
accessed.
The code assumes that the state item created in the previous section
is available to the state handler.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:type pad (1)
:type_lsb pad (1)
:state_value pad (4)
at (128)
INPUT-BYTES (1, type_lsb, !)
COMPARE ($type, 1, execute_state, extract_state, error_conditions)
Price et al. [Page 18]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
:execute_state
STATE-ACCESS (state_identifier, 20, 0, 0, 0, 512)
:extract_state
STATE-ACCESS (state_identifier, 20, 6, 4, state_value, 0)
OUTPUT (state_value, 4)
JUMP (end)
:error_conditions
COMPARE ($type, 3, state_not_found, id_too_short, state_too_short)
:state_not_found
STATE-ACCESS (128, 20, 0, 0, 0, 0)
JUMP (end)
:id_too_short
STATE-ACCESS (state_identifier, 19, 6, 4, state_value, 0)
JUMP (end)
:state_too_short
STATE-ACCESS (state_identifier, 20, 6, 5, state_value, 0)
JUMP (end)
at (484)
:end
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
at (512)
:state_identifier
byte (32, 84, 55, 65, 83, 248, 254, 122, 106, 151, 203, 121, 224, 24,
194, 221, 214, 143, 254, 155)
If the compressed message is 0x00 then the expected output of the
code is 0x7465 7374 and a total of 21 UDVM cycles are expected to be
used. If the compressed message is 0x01 then the code should also
output 0x7465 7374 but in this case using a total of 15 UDVM cycles.
If the compressed message is 0x03, 0x04 or 0x05 then decompression
failure should occur.
Price et al. [Page 19]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
4. Security considerations
This draft describes implementation options for the SigComp protocol
[SIGCOMP]. Consequently the security considerations for this draft
match those of SigComp.
5. Authors' addresses
Richard Price Tel: +44 1794 833681
Email: richard.price@roke.co.uk
Abigail Surtees Tel: +44 1794 833131
Email: abigail.surtees@roke.co.uk
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
6. References
[SIGCOMP] "Signaling Compression (SigComp)", R. Price et al.,
<draft-ietf-rohc-sigcomp-07.txt>, June 2002
[USERGUIDE] "SigComp User Guide", R. Price et al.,
<draft-price-rohc-sigcomp-user-guide-01.txt>, October
2002
[RFC-2026] "The Internet Standards Process - Revision 3", Scott
Bradner, Internet Engineering Task Force, October 1996
[RFC-2119] "Key words for use in RFCs to Indicate Requirement
Levels", Scott Bradner, Internet Engineering Task Force,
March 1997
Price et al. [Page 20]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
Appendix A: UDVM bytecode for the torture tests
The following sections list the UDVM bytecode generated for each
test. The bytecode is presented in the form of a complete SigComp
message, including the appropriate header and any compressed data
required by the code.
Note that the different assemblers can output different bytecode for
the same piece of assembly code, so a valid assembler can produce
results different from those presented below. However, the following
bytecode should always generate the same results on any UDVM.
A.1. Bit manipulation
0xf80a 7116 a07f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x01c0 00ff 8055 5502 202a 0321 0420 0305 21ff 2286 0401 20c0 ff02
0x2060 0320 0421 6005 2061 2286 0423
A.2. Arithmetic
0xf80a a11c 01a0 459f 9f07 2201 16a0 7600 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x06c0 00ff 9941 0720 0108 20a3 e909 20a0 650a 200b 2286 0406 21c0
0xff07 2162 0821 6109 2061 0a21 6222 8604 2300
A.3. Sorting
0xf80d c10c 8802 170b 8802 1722 a12e 2d23 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0a00 0a00 1100 0700 1600 0300 0300 0300 1300 0100 1000 0e00
0x0800 0200 0d00 1400 1200 1700 0f00 1500 0c00 0600 096e 6720 6975
0x6920 7469 7420 2c79 6f75 2720 5346 6f6e 6761 2075 7272 646f 2074
0x6f6e 2e2e 0070 6570 206e 7472 656e 69
A.4. SHA-1
0xf808 710d a0c3 03a0 4422 a044 140d a0c6 38a0 4422 a044 140e 86a0
0xfe0e a042 a0ff 0da0 feff a044 22a0 4414 0e86 a0ff 0ea0 42a1 070d
0xa0ff a280 a0ff 22a0 ff14 2300 0000 0000 0000 6162 6361 6263 6462
0x6364 6563 6465 6664 6566 6765 6667 6866 6768 6967 6869 6a68 696a
0x6b69 6a6b 6c6a 6b6c 6d6b 6c6d 6e6c 6d6e 6f6d 6e6f 706e 6f70 7161
Price et al. [Page 21]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
0x3031 3233 3435 3637
A.5. LOAD and MULTILOAD
0xf803 710e 87a0 840e a082 c080 0ec0 80a0 860e c084 c084 2287 081c
0x01a0 419f 8908 2002 0620 3c0f 6003 a0a3 a0b2 870f 6004 2a87 c080
0xc084 2287 0823 00
0xf801 e10e 208e 0e86 860e a042 8712 2087 210e 8680 4100 1286 a04c
0xa041 2220 a06d 23
A.7. COPY-LITERAL and COPY-OFFSET
0xf802 f10e 208e 0e86 860e a042 870e a044 2113 2087 2213 a044 0822
0x0e86 a042 0ea0 42a0 4a14 0806 220e 6301 1463 0522 2220 3023
A.8. MEMSET
0xf801 810e 8687 0ea0 42a0 8115 86a0 8100 0115 a081 0f86 0f22 8710
0x23
0xf801 a115 a046 1801 0115 a05e 1487 011c 02a0 449f 931b 62a0 462c
0x9f8d 2362 cb
A.10. INPUT-BITS
0xf801 511d 62a0 4614 22a0 4602 0622 010a 2207 0622 0116 ee23 932e
0xac71
A.11. INPUT-HUFFMAN
0xf801 d11e a046 1c02 6200 6262 6200 ff00 22a0 4602 0622 010a 2207
0x0622 0116 e623 932e ac71 66d8 6f
A.12. INPUT-BYTES
0x1d62 a046 1d22 a046 0206 2202 0a22 071c 62a0 480e 22a0 4862 0622
0x0116 e523 932e ac71 66d8 6fb1 592b dc9a 9734 d847 a733 874e 1bcb
0xcd51 b5dc 9659 9d6a
A.13. Stack manipulation
0xf814 110e a046 8610 0210 6010 a042 2286 0811 8611 6311 a046 2286
0x0816 2800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 000e a048 a140 0724 8818 3800
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Price et al. [Page 22]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
0x0018 6400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 000e a046 a17f 0ea1 7f1a 0fa1 b003
0x0180 c001 8f19 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0023
A.14. Program flow
0xf803 f10e a044 040e 86a0 9207 20a0 9022 a043 0116 6006 2101 0e86
0xa084 0720 a0a1 22a0 4301 1761 0660 f106 0722 010e 86a0 8407 20a0
0xb622 a043 011a 0462 0860 9fdc f123
A.15. State creation
0xf819 e11c 01a0 459f 9f04 220d 1762 8f0c 0606 200a 8900 1400 0422
0x0117 628f 0a06 0621 a20a 0604 2201 1762 8f0e 0606 2300 000a 8900
0x1400 2300 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0022 a206
0x0416 e074 6573 7420 5437 4153 f8fe 7a6a 97cb 79e0 18c2 ddd6 8ffe
0x9b00
A.16. STATE-ACCESS
0xf819 411c 01a0 459f 9f17 6201 060d 1c1f 8914 0000 0089 1f89 1406
0x04a0 4600 22a0 4604 16a1 4517 6203 0610 1b1f 8714 0000 0000 16a1
0x351f 8913 0604 a046 0016 a12a 1f89 1406 05a0 4600 16a1 1f00 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0023 0000 0000
Price et al. [Page 23]
INTERNET-DRAFT SigComp Torture Tests October 25, 2002
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0020 5437
0x4153 f8fe 7a6a 97cb 79e0 18c2 ddd6 8ffe 9b00
Price et al. [Page 24]