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

Mon Jun 19 10:06:41 PDT 2017

+cfe-dev, as this concerns Clang.

I am also in favour of a source annotation approach in general, but I have
a few nitpicks on syntax.

- Can we use a name with "cfi" in it somewhere, so that it is clearer what
the purpose of the attribute is?
- I would prefer to remove the quotes and just have the arguments be
declaration references. To resolve circular references you can always
forward declare the classes, i.e.

class JSComponentMath;
class JSComponentImage;

__attribute__((compatible_vtable_layout(JSComponentMath, JSComponentImage)))
class ProxyClass{
public:
  ...
}

Peter

On Mon, Jun 19, 2017 at 8:16 AM, Enes Göktaş via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> As you noted the class links are actually of the whitelisting kind and not
> of the blacklisting kind. Doing this with an attribute is pretty
> interesting and sounds like a better fit to me.
> I think this could look something like:
>
> __attribute__((compatible_vtable_layout("JSComponentMath",
> "JSComponentImage")))
> class ProxyClass{
> public:
>   ...
> }
>
> Would this be more admissible?
>
>
>
> On Fri, Jun 16, 2017 at 8:55 PM, Evgenii Stepanov <eugenis at google.com>
> wrote:
> >
> > Well I find the changes necessary to support this exceptionally simple
> > and obviously safe. All additional risk is on the whitelist user side,
> > and it does not even compare with blanket whitelisting of libc++ ;)
> >
> > Having said that, source annotations should be preferred to whitelists
> > when possible. This could be a class __attribute__ declaring that the
> > class is layout-compatible with some other class.
> >
> > On Fri, Jun 16, 2017 at 11:06 AM, Kostya Serebryany <kcc at google.com>
> wrote:
> > > -krasin@
> > >
> > > On Fri, Jun 16, 2017 at 11:05 AM, Kostya Serebryany <kcc at google.com>
> wrote:
> > >>
> > >>
> > >>
> > >> On Thu, Jun 15, 2017 at 10:39 PM, Enes Göktaş <enes.goktas at gmail.com>
> > >> wrote:
> > >>>
> > >>> 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?
> > >>
> > >>
> > >> Yes. Take a look at other tests in llvm/projects/compiler-rt/test/cfi
> > >>
> > >> (I did not study your patch or tests in detail yet, and probably won't
> > >> have time until mid Jul. But others may)
> > >>
> > >> My major concern with any such patch is that it complicates the
> > >> implementation.
> > >> For many parts of compiler extra complexity is acceptable, but CFI is
> a
> > >> security mitigation feature and as such should be minimal.
> > >>
> > >> --kcc
> > >>
> > >>>
> > >>> 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
> > >>>>
> > >>>>
> > >>>
> > >>
> > >
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170619/08db9727/attachment.html>