Re: [sv-cc] Proposal uploaded for handling IP Encryption

Hi all,

after having read this, this seems to be pretty straightforward to me. I 
am just (a little concerned) about the stability/performance issues this 
addition might imply:
 - any existing code will very likely NOT check for vpiIsProtected 
property, and as a result will very likely fail at various levels
 - new code will very likely have to check for this property before 
doing any access. This is performance drain, which we should not neglect.
    Or is the intention to have this check in the error routine, so you 
only check after the fact ?

Just loud thinking now:
Would it make sense to (further) add a callback that is being executed 
(after being registered) upon an attempt to access a protected object.
This call must receive some indication about the offending function 
(vpi_handle..., vpi_iterate), its arguments, and might even have the
opportunity to change the return value to something senseful (e.g. a 
dummy 'this is a protected block' object) that can be safely processed
by old code.
BUT As said, just loud thinking.

there are also some minor comments:

CHANGE
The number of nested decryption envelopes that can be processed is 
implementation-specified. Code that is contained within a decryption 
envelope is said to be protected.
TO
The number of nested decryption envelopes that can be processed is 
implementation-specified*; any implementation shall be able to process 
at a minimum 8 levels of nesting*. Code that is contained within a 
decryption envelope is said to be protected.

/REASON: these kind of implementation specifics open up a huge potential 
source for incompatibilites. Let's define some lowest common denominator./

CHANGE

Using *vpi_get(vpiIsProtected, <object_handle>) *returns an boolean 
constant which indicates whether the object represents code contained in 
a decryption envelope. /If/ the object is protected, unless otherwise 
specified, access to object relationships and properties shall be an 
error. Access to the vpiType property and the vpiIsProtected property of 
a protected object shall be permitted.

TO

Using *vpi_get(vpiIsProtected, <object_handle>) *returns an boolean 
constant which indicates whether the object represents code contained in 
a decryption envelope. *When *the object is protected, unless otherwise 
specified, access to object relationships and properties shall be an 
error. Access to the vpiType property and the vpiIsProtected property of 
a protected object shall be permitted.

Should we say, what is the return value of vpiIsProtected when the 
object is protected: TRUE if protected, FALSE if not ?

Best regards,
-Michael


Steven J. Dovich wrote:

>Mantis #345 has a draft proposal attached.
>
>/sjd
>
>  
>


-- 

NOTE: The content of this message may contain personal views 
      which are not neccessarily the views of Freescale, unless specifically stated.
 
         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Freescale Semiconductor     Fax: +49-89-92103-680 |( \
    / / |      Freescale Halbleiter Deutschland GmbH        | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@freescale.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

The information contained in this email has been classified as:
General Business Information                     ( )
Freescale Internal Use Only         ( )
Freescale Confidential Proprietary  ( )


*** This note may contain Freescale Confidential Proprietary or Freescale Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. 
    Thank you! ***