Class File error handling for users

[Øystein Myhre Andersen]

As I mentioned before, I had problems with the error message "stack size
mismatch" at an early stage of my implementation.
I didn't think the message was good enough. At least the message could
state the sizes.
Later I got a hint about a suitable transform to monitor the stack.
I chose instead to add dummy jumps to enforce the error earlier.

I have no problem with this today

Is it a good idea to add more explanation to the error messages.

- Øystein Myhre Andersen

On Thu, May 16, 2024 at 3:32 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> I think it would be worthwhile to try to characterize the sorts of
> validation that we do and do not perform, so that users don’t think “they
> caught error A but not error B” is purely a result of inconsistent
> implementation.
>
> > On May 14, 2024, at 7:57 PM, liangchenblue at gmail.com wrote:
> >
> > Hello ClassFile API programmers,
> > I noticed that recently ClassFile API has quite a few bugs caused by our
> minimal validation policies, such as JDK-8331940, JDK-8331655, JDK-8331320,
> JDK-8330684. They are mostly caused by us not defending against malicious
> values that conform to the CF structure (so they avoid IAE).
> >
> > I believe our policy of minimal validation (i.e. only validating data
> that's required to build our API model, such as bci for Label, cp index +
> type for PoolEntry, etc.) is on the correct path for minimal performance
> impact. Yet the occurrences of these bugs may have an implication on user
> code, that users might frequently encounter such bugs like we did too,
> especially for bound attributes lazily reading from malicious class files
> and returning unsanitized primitive types.
> >
> > As a solution to such problems, I recommend we put up a note in the
> package info of ClassFile API, telling users that they should sanitize
> input class files. Our API already took a step in this direction, that we
> throw IAE for structurally malformed class files; users should realize that
> such IAEs only happen with lazy expansion, and should perform extra
> validations and throw IAE to further validate correctness of Class Files.
> >
> > Do you think this validation problem is valid? And if so, would this
> solution mitigate this issue? I don't think my solution is perfect and am
> open to input.
> >
> > Chen Liang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20240516/62457f2c/attachment.htm>