Re: [sv-cc] Proposal for Mantis 345 has been updated

Michael Rohleder <michael.rohleder@freescale.com> writes:
> a) I strongly believe that it is not a good idea to leave the number of 
> nested decryption envelopes that can
>    be processed as implementation specific; in fact I demand that there 
> is a minimum number of nestings
>    that shall be processed by any implementation. Without such a least 
> common denominator, we leave a
>    rat hole for incompatibilities I would like to avoid.

I think setting a minimum supported nesting limit is reasonable. It was
not flagged in the Encryption committee, and is not the subject of any
ballot comment. In 345, I am trying to stay within the scope of the
received ballot comment, and address only the changes necessary for VPI.

> b) I still have large concerns about the incompatibilities that might be 
> introduces by failing VPI functions
>     due to encryption of source code. There will be a lot of legacy code 
> that will not check for such cases
>     (bad style, but I am sure this exists). And having to do these kind 
> of checks in new code might also
>     introduce some runtime penalty I am not sure we can so easily neglect.
>     Therefore I would ask for bringing up some creative ideas how to 
> take both cases into account and
>     have some solutions for them. IMHO the performance impact of such 
> things will exceed the effect
>     of dynamic variables and here we already spent some on the 
> discussion of vpiValid, so why not here ???
> 
> If VPI would be a C++ interface, then I would suggest to have some 
> register function that results in creating
> a 'access to encrypted object' exception that my code could catch and 
> properly process. This would be an
> ideal solution (in my simple mind) for both problems, since its is not 
> very intrusive and has a low runtime
> overhead. But we are in C world now.  Bad luck.

We do not have many tools to avoid this particular problem. As Charles
pointed out, callback on error is one method. The vpiIsProtected
property can either be tested before calling code, or can be called
after failure. Checking after failure is probably better so that the
normal case is not made more costly.

/sjd