| #
3f3af97d |
|
04-Aug-2015 |
David Howells <dhowells@redhat.com> |
ASN.1: Fix actions on CHOICE elements with IMPLICIT tags
In an ASN.1 description where there is a CHOICE construct that contains
elements with IMPLICIT tags that refer to constructed types, actions to be
taken on those elements should be conditional on the corresponding element
actually being matched. Currently, however, such actions are performed
unconditionally in the middle of processing the CHOICE.
For example, look at elements 'b' and 'e' here:
A ::= SEQUENCE {
CHOICE {
b [0] IMPLICIT B ({ do_XXXXXXXXXXXX_b }),
c [1] EXPLICIT C ({ do_XXXXXXXXXXXX_c }),
d [2] EXPLICIT B ({ do_XXXXXXXXXXXX_d }),
e [3] IMPLICIT C ({ do_XXXXXXXXXXXX_e }),
f [4] IMPLICIT INTEGER ({ do_XXXXXXXXXXXX_f })
}
} ({ do_XXXXXXXXXXXX_A })
B ::= SET OF OBJECT IDENTIFIER ({ do_XXXXXXXXXXXX_oid })
C ::= SET OF INTEGER ({ do_XXXXXXXXXXXX_int })
They each have an action (do_XXXXXXXXXXXX_b and do_XXXXXXXXXXXX_e) that
should only be processed if that element is matched.
The problem is that there's no easy place to hang the action off in the
subclause (type B for element 'b' and type C for element 'e') because
subclause opcode sequences can be shared.
To fix this, introduce a conditional action opcode(ASN1_OP_MAYBE_ACT) that
the decoder only processes if the preceding match was successful. This can
be seen in an excerpt from the output of the fixed ASN.1 compiler for the
above ASN.1 description:
[ 13] = ASN1_OP_COND_MATCH_JUMP_OR_SKIP, // e
[ 14] = _tagn(CONT, CONS, 3),
[ 15] = _jump_target(45), // --> C
[ 16] = ASN1_OP_MAYBE_ACT,
[ 17] = _action(ACT_do_XXXXXXXXXXXX_e),
In this, if the op at [13] is matched (ie. element 'e' above) then the
action at [16] will be performed. However, if the op at [13] doesn't match
or is skipped because it is conditional and some previous op matched, then
the action at [16] will be ignored.
Note that to make this work in the decoder, the ASN1_OP_RETURN op must set
the flag to indicate that a match happened. This is necessary because the
_jump_target() seen above introduces a subclause (in this case an object of
type 'C') which is likely to alter the flag. Setting the flag here is okay
because to process a subclause, a match must have happened and caused a
jump.
This cannot be tested with the code as it stands, but rather affects future
code.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
|
| #
4520c6a4 |
|
21-Sep-2012 |
David Howells <dhowells@redhat.com> |
X.509: Add simple ASN.1 grammar compiler
Add a simple ASN.1 grammar compiler. This produces a bytecode output that can
be fed to a decoder to inform the decoder how to interpret the ASN.1 stream it
is trying to parse.
Action functions can be specified in the grammar by interpolating:
({ foo })
after a type, for example:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING ({ do_key_data })
}
The decoder is expected to call these after matching this type and parsing the
contents if it is a constructed type.
The grammar compiler does not currently support the SET type (though it does
support SET OF) as I can't see a good way of tracking which members have been
encountered yet without using up extra stack space.
Currently, the grammar compiler will fail if more than 256 bytes of bytecode
would be produced or more than 256 actions have been specified as it uses
8-bit jump values and action indices to keep space usage down.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|