Try to reject adding virtual methods to xpidl interfaces in CDATA blocks
Categories
(Core :: XPCOM, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox104 | --- | fixed |
People
(Reporter: nika, Assigned: nika)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
In order for xpidl to correctly reflect interfaces between multiple languages, it needs to know the true layout of the interface's VTable so that it can reflect that VTable into both Rust and JS through XPConnect. If virtual methods are added to an XPIDL interface using a CDATA (%{C++) block, this throws off xpidl's ability to correctly handle this situation, and could lead to soundness issues.
This bug is to track adding a mechanism to xpidl to attempt to reject interfaces which add additional virtual methods using CDATA blocks. Non-virtual methods don't impact the layout of the VTable and so are OK.
It turns out we have a number of cases of methods being added in this way, which need to be fixed as well.
|
Assignee | |
Comment 1•3 years ago
|
||
We'll probably want to do something more accurate in the future with a
custom clang static analysis pass which validates that XPIDL interfaces
have the expected vtable and struct layout, however doing so would be
more involved than the string matching done in this patch.
In addition to checking for extra virtual methods, we'll likely also
want to check for data members on interfaces, and reject them unless the
class is marked as [builtinclass] in addition to some other attribute
which we'll need to add to prevent them from being implemented in Rust
(as c++ data members will not be reflected by the rust macro).
There were 2 instances of a comment which contained the word 'virtual'
within a CDATA block. These comments were moved out of the CDATA block
to avoid triggering the error.
|
||
Comment 3•3 years ago
|
||
| bugherder | ||
Description
•