[sv-champions] Re: Encryption proposal

Hi, Steve.

On Thu, 9 Dec 2004, Steven J. Dovich wrote:

> Shalom,
>
> Thanks for your feedback. It would have been useful to have it
> earlier in the process.

Unfortunately, my time has been too limited to be involved in everything.
And my expertise (and interest, frankly) in encryption is also limited.
Nor have I been able to participate much in the BTF meetings due to the
late hour in my time zone.

> > I have not looked seriously at the encryption proposal in the past.
> > Only over the last day or two did I look at it more carefully, though
> > still only rather quickly, and I have a number of concerns.
> >
> > First, the proposal to add a `pragma compiler directive to section 19 has
> > to be able to stand on its own, without any connection to encryption.
> > Strictly speaking, this is more properly in the scope of the regular BTF,
> > rather than the BTF-IP.
> >
> > This concerns me, because although your minutes say that it was shown to
> > the BTF, there is no record of any serious detailed discussion in the
> > BTF minutes. Did the BTF get a detailed proposal and discuss it?
> > I fear this part did not get a thorough review for consistency with
> > other parts of the Verilog LRM.
>
> While the Encryption committee was a subcommittee of the BTF, I
> attended those meetings to report and request guidance. I specifically
> requested that the BTF handle the pragma definition since that was
> more properly within their domain of expertise. I was given guidance
> and directed to handle the language issues in the Encryption committee.

Still, it is unfortunate that it was ont reviewed by the BTF.

 
> The resulting proposal for the `pragma directive is responsive to
> the specific comments I recieved in the BTF meeting. It is also
> the result of choices made by the Encryption committee with respect
> to dealing with existing non-standard directives.
>
>
> > Some of my specific concerns:
> >
> > I refer to the document filed in the SV DB as 314. It is labelled
> > CDN P1364e/D2.
> >
> > First, there is no description of the motivation or justification of
> > `pragma or the envisioned typical use models. That is, if I just read
> > this, I don't understand why you need `pragma.
> >
> > Example: You want 'protect'? So define `protect and `endprotect. Why
> > '`pragma protect'?
>
> Because `protect and `endprotect are existing non-standard directives
> that are reasonably widely deployed with differing semantics and
> interpretation. The committee felt it invited less confusion to
> use different directives for this new standard encryption scheme.
>
> Other directive names were discussed, and there was a conscious
> choice to specify a general extension mechanism that would solve
> the problem at hand, and also be useful for future extension by
> implementors and standards committees.

`protect is just an example.
`pragma is a general mechanism. It needs to be justified and the use model
described. Many tools defined their own directives. For example, Verilog-XL
defined `accelerate. You should show why this method of extending
directives is not adequate.

You should also show how the `pragma mechanism could help avoid conflicts
between private extensions. For example, if two different tools will define
"`pragma accelerate", then I still have a problem.

> > Jay Lawrence originally proposed `pragma in BTF 430. I speculate that
> > it was the source of this part of the proposal. But Jay's discussion
> > included a description of the need for and use of `pragma which is
> > missing here but needed. Ditto for why non-recognized pragmas should
> > be ignored instead of creating warnings or errors.
> >
> > (It's still not clear to me why 'protect' should be a pragma instead of
> > a regular compiler directive, though...)
> >
> > (Also, it is still not clear that unrecognized directives should not
> > generate at least a warning, which could help spotting mis-spelled
> > directives.)

This issue still requires a discussion.

 
> BTF 430 was not the seed, though this idea has been floating around
> in conversations for a while. In comparison with BTF 430, the grammar
> for the directive has been extended to better support the specification of
> pragma names like 'protect'.
>
> > The first sentence describes `pragma as 'a structured specification'.
> > Excuse me, but that is a meaningless buzz-phrase, at least without
> > a further explanation or at least an example. What makes it different
> > from other directives?
> >
> > Speaking of examples, this section definitely needs an example, preferably
> > more than one.
>
> Examples would certainly be in character for this standard. But I
> think that they can't be allowed to imply specification that is not
> actually there in the normative text. If the text is incomplete
> we need to address that. If it is complete but obtuse, then that
> is a different problem that we can word-smith around.

The minute that the actual pragma is not defined by the LRM,
there is no problem in giving an abstract example, even with meaningless
names. It certainly does not imply that the example is normative.

It is like the example of user-defined functions in 10.3.5.

Without an example, it is not clear how to use `pragma.

You could even use 'protect' as an example.

> > Regarding the syntax, it is not clear whether or where white space may
> > or may not appear in the form 'keyword=value' or within constant_expression.
>
> I would agree that this aspect requires some degree of interpretation.

For example, if the argument list is "1 -2", is that one constant_expression
("1-2") or two (1 and -2)?

 
> > And it is not clear what operands and operators may appear in
> > constant_expression in this context. I had wanted to propose extensions
> > to the preprocessing capabilities of Verilog by adding some CPP and Verilog
> > pre-processor directives like '`if <expression>' and `for, but I got stuck
> > on this very point, and I saw it was not possible to get to a solid formal
> > specification within the deadline.
>
> The choice of constant_expression was intended to be a connection to
> the BNF in Annex A. If there is some subtle reason why that would be
> inappropriate in the directive context, then this issue should be
> revisited.

Are all types of constants allowed? based, sized, etc?
What are the sizing and signing rules?
Are they the same as in Verilog text?
Parameters are presumably not allowed.
What about "constant system functions" (see enhancements BTF-387 and 390)?

> > 19.10.1 should be titled something like 'reset, resetall' instead of
> > 'Standard Pragmas'. (Aren't you proposing that 'protect' be a standard
> > pragma as well?)
>
> No objection. I consider this an editorial perogative, though the
> Working Group seems to want purview over these issues.
>
> > Examples are badly needed.
>
> See answer above.

It took me several reading to understand the intended syntax.
An example is essential.
 

> > The first sentence in 19.10.1 is very confusing, because you have not yet
> > said that the 'affected pragmas' appear as keywords of the reset pragma.
>
> Is this fixable by re-ordering the sentences in the paragraph or
> is the problem deeper than that?

Probably re-ordering and minor rewording is enough.

> > Moving on to Section 28, the question about where white space may and may
> > not appear is common to many of the items in this section.
>
> See answer above.
>
> > The syntaxes should appear as, instead of 'begin', as '`pragma protect begin'.
>
> They appear in isolation because they describe the requirements on
> the specific pragma keyword that is associated with the 'protect'
> pragma name. With a complete directive, that is by nature an example,
> as the intent is to permit compositing of adjacent protect pragma
> directives. For example:
>
> `pragma protect begin
> `pragma protect author="IEEE"
> `pragma protect data_method=rsa
>
> can be also represented as:
>
> `pragma protect begin author="IEEE" data_method=rsa
>
> Both forms have identical interpretation (clause 28 para 2).
> Since 28.3 describes the pragma keywords for 'protect' it only
> gives the syntax for the pragma keyword being described.

Good point. Such an example would be very helpful.

Note that the paragraph before 28.1 says that expressions preceding
begin 'are designated as envelope keywords', whereas expressions following
begin are 'content keywords'. But then 28.2 is titled 'Envelope directives',
which implies that they have to precede 'begin'.

> > 28.3.2 Description should be 28.3.2.2.
>
> Uncaught typo, thanks for spotting it.
>
> > 28.3.9.2 references other standards. They must be properly referenced,
> > probably in Annex H.
>
> No objection. The normative references are provided.

The IETF references need to be done in the proper format, with the required
information. It should not be the editor's job to obtain this information.

 
> > 28.3.11.2 and 28.3.21.2 reference a bunch of Encryption and Digest algorithms.
> > All need to be properly referenced.
>
> We spent considerable time trying to find a normative reference
> for the entire list. The fallback of local specification needs
> appropriate normative references to these algorithms.

I don't understand what you mean by this.
Some of these names I know, many I don't (Blowfish and Serpent, for example).
You have to supply references for them.

 
> > By the way, is support of encryption to be mandatory for compliance to
> > 1364-2005? I'm not sure how much support there will be for that among the
> > balloters.
>
> I think the text implies it is mandatory. I don't think this is a
> show-stopper though. The Encryption committee is not the right
> forum for that decision. That is a policy decision that is ultimately
> in the hands of the ballot group. We took one reasonable approach
> and are prepared to alter the policy if so requested by the Working
> Group or the Ballot Group.

I think it kills the last chance of anyone doing a 'hobbyist' implementation
of the language.

 
> > Annex I mentions Verilog-XL. I'm not sure you can do that, even if the Annex
> > is only normative.
> >
> > Annex I refers to 'the following pragmas', whereas in 28, they are called
> > 'pragma_keywords'. The distinction between pragma, pragma name, and pragma
> > keyword is important.
>
> Annex I is not at the quality level that I am comfortable with.
> I raised the option of omitting it from the approved proposal. The
> Encryption committee felt that there was critical informative
> content regarding use models that would otherwise be missing and
> voted to include it.

My issues remain.

 
> > As you can see, I think this still needs work.
> > I think there are still too many open issues.
>
> The degree of open issues and questions is a matter for the Working
> group to establish consensus on. We could continue to polish, but
> this was an item of substantial interest to the Working Group, which
> the Encryption committee has done their best to deliver in the
> time frame requested.
>
> The proposal is substantially improved over the donation. I fully
> expect to deal with additional changes in ballot, because there is
> a related effort in the VHDL committee that we need to coordinate
> with. They started from an equivalent donation and are discussing
> changes. I have provided them with this proposal and requested
> their current document in return. It would not be useful to industry
> if incompatible schemes are standardized.
>
> The Mantis "Encryption" category is where I expect to accumulate and
> address remaining issues and errata. The Encryption committee will
> be working through those issues as they are posted in an effort to
> accumulate corrections and clarifications for the next opportunity
> to amend the draft.

The question is whether to send to ballot something which we know needs
more work.

Thanks,
Shalom

>
> > Sorry if I sounded a bit harsh.
>
> You will have to try a lot harder. I still have a standing death
> threat over a compromise I successfully brokered between three
> working groups in IEEE POSIX effort.
>
>
> I hope my response is helpful in working through the proposal.
>
> /sjd
>

-- 
Shalom Bresticker                        Shalom.Bresticker @freescale.com
Design & Verification Methodology                    Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                 Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 5441478
  
[ ]Freescale Internal Use Only      [ ]Freescale Confidential Proprietary