[llvm-dev] [CFI] Manually linking classes that have no inheritance link

[Enes Göktaş via llvm-dev]

Hi Kostya,

Please find attached the minimized motivation test.
I hope it is minimized enough. If not please let me know so I can try to
make it more minimal.
Were you expecting something like this?

Also I think the tests that I should provide along with the patch should be
in a special format right? I think I should be looking at
http://llvm.org/docs/DeveloperPolicy.html#test-cases, and
http://llvm.org/docs/TestingGuide.html for more information for adding
tests to the patch. Any other handy links by any chance?

--
Enes

On Thu, Jun 15, 2017 at 1:51 PM, Kostya Serebryany <kcc at google.com> wrote:

> Hi Enes,
>
> I usually find it nearly impossible to discuss complex issues likes this
> w/o having a minimized motivation test.
> Could you please provide such a test with one of the patches?
> (And in general, please try to provide tests with any patch)
>
> Thanks!
>
> --kcc
>
>
> On Thu, Jun 15, 2017 at 5:08 AM, Enes Göktaş <enes.goktas at gmail.com>
> wrote:
>
>> Hi,
>>
>> I would like to propose extending the Control-Flow Integrity (CFI)
>> mechanism in LLVM/Clang with a feature that allows users to explicitly link
>> classes that have no inheritance link. Usually, if one class is used at
>> locations in code where this class is not expected, this will create a CFI
>> error at runtime, assuming the application is built with CFI enabled.
>> However, in cases where the user has a complex code structure or design
>> that should allow this behavior, there is currently no solution but
>> disabling the CFI checks. Disabling the CFI checks is not a preferable
>> option when one wants to protect against memory corruption exploitation.
>>
>> This feature prevents the CFI errors by expanding the valid vtable sets
>> at virtual callsites with vtables of classes specified in a sanitizer
>> blacklist file by the user. This allows keeping the CFI checks enabled.
>>
>> When applying CFI to Firefox, I had to use this feature to solve the CFI
>> errors caused by XPCOM in Firefox. XPCOM is a fundamental technique in
>> Firefox and its design is so complex and intricate that changing XPCOM to
>> solve the CFI errors would be very difficult. XPCOM allows components to be
>> written in multiple languages and allows them being used from different
>> languages. For example, components implemented in JavaScript(JS) can be
>> used from C++ through their corresponding classes defined in C++. However,
>> it is worth mentioning that these classes are not implemented in C++ but in
>> JS. Behind the scenes, during runtime a generic proxy class is used for all
>> JS-component classes within the C++ code. This proxy class leads the
>> execution to the JS code.
>> When CFI is applied, the CFI checks at virtual callsites that have the
>> type of a JS-component class, fail, because at runtime the vtable of the
>> generic proxy class is used at these virtual callsites, while there is no
>> inheritance link between the JS-component and the generic proxy class.
>>
>> With the following patches I was able to specify the links between these
>> classes such that during compilation the vtable of the generic proxy class
>> was added to the vtable sets at virtual callsites with the type of the
>> JS-component classes:
>> - https://reviews.llvm.org/D34233
>> - https://reviews.llvm.org/D34231
>>
>> Without these patches, XPCOM would have to be significantly changed and
>> probably written from scratch. Simply making the JS-component classes a
>> descendant of the generic proxy class, or vice versa, is not an option,
>> because this would break the design. Making the generic proxy class a
>> descendant of the JS-component classes would result in a bad design in
>> which the proxy class inherits from tens of classes. Also the vtable of the
>> proxy class should overlay the structure of the JS-component vtables in a
>> very specific way. Making one a descendant of the other will break the
>> overlaying property.
>>
>> Kind regards,
>> Enes
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170615/c46805bb/attachment.html>
-------------- next part --------------
classlink:_ZTS15JSComponentMath=_ZTS10ProxyClass
classlink:_ZTS16JSComponentImage=_ZTS10ProxyClass
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jsmagic.h
Type: text/x-chdr
Size: 1602 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170615/c46805bb/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cpp
Type: text/x-c++src
Size: 1572 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170615/c46805bb/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compile_with_classlinks.sh
Type: application/x-sh
Size: 220 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170615/c46805bb/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compile_without_classlinks.sh
Type: application/x-sh
Size: 188 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170615/c46805bb/attachment-0001.sh>