This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH/Merge Request] Vtable Verification feature.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Caroline Tice <cmtice at google dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, Benjamin De Kosnik <bkoz at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Benjamin De Kosnik <b dot dekosnik at gmail dot com>, Bhaskar Janakiraman <bjanakiraman at google dot com>, Jason Merrill <jason at redhat dot com>
- Date: Thu, 8 Aug 2013 23:01:51 +0000
- Subject: Re: [PATCH/Merge Request] Vtable Verification feature.
- References: <CABtf2+Q47X0Ld6byo8R96TTKuYPkOsKO7tADRRWVpFqHHTsfuw at mail dot gmail dot com> <20130801131950 dot 527bbf97 at oakwood> <CAD_=9DThid3P8ridA2OxP15L_KehaKzw=EGjSPwP=MT6vMAexg at mail dot gmail dot com> <CABtf2+TDrQObufSt4Zd46fjG6jH_XfuhRTeNJvsniP6BaCyEdg at mail dot gmail dot com> <CABtf2+Rn8Xn12xvWMx9FSBZ3EGaZQ77Qs-sh_z1XCxntsN9SVg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1308080028160 dot 26185 at digraph dot polyomino dot org dot uk> <CABtf2+S-eVmVxGO9ms7njhy=iHuL5T=uq-ONf_aUJZ9mX38HjQ at mail dot gmail dot com>
On Thu, 8 Aug 2013, Caroline Tice wrote:
> Actually if you ever want to use the feature with your compiler you
> should build your compiler with --enable-vtable-verify. This will, as
> you noted, insert calls in libstdc++ to build the verification data
> structures and to verify the virtual calls in libstdc++ itself.
> However libstdc++ itself contains 'stub' (do-nothing) versions of the
> functions that build the data structures and perform the verification.
> So if you want to turn on verification with libstdc++, you link it
> with libvtv (which contains the "real" versions of those functions)
> and if you don't want verification with libstdc++ you just don't link
> in libvtv. There is no need to multiple versions of libstdc++.
But presumably libstdc++ with the extra calls is less efficient than
libstdc++ without them, even if the calls are just to stub functions?
A GNU/Linux distributor would likely want to enable their users to use
this functionality, meaning distributing a GCC build with libvtv included
and a version of libstdc++ with the calls present for users who wish to
build programs (linking with libstdc++ and libvtv) for which the calls in
libstdc++ are checked. But they might not want to have even the stub
calls executed for all installed C++ programs. So it would seem natural
to provide both copies of libstdc++ - and desirable for this to be
possible without needing separate GCC builds.
> I supposed the libgcc files could be built all the time (on systems
> that support libvtv). Would there be any down side to this?
In my model, it's appropriate to build those independent of the libstdc++
configure option - and likewise to build everything in libvtv independent
of the configure option. There should be no need for the configure option
to affect anything other than, at most, libstdc++ - that is, the handling
of the option in other configure scripts should be removed, with the case
where the relevant support is built being enabled by default.
> For certain use cases the current working directory is not our
> preferred place to put the log files.
> I have recently submitted a patch that tries to use environment
> variables to determine where to put the log files. It first checks to
> see if the user has defined VTV_LOGS_DIR, in which case it will use
> that. If that fails, it tries to find and use HOME. If that also
> fails, it falls back on using the working directory. I hope that is
> I have modified the call to open to take O_NOFOLLOW, but O_EXCL will
> do the wrong thing, as we sometimes wish to append to the log files
> and O_EXCL fails if you attempt to open an existing file (according to
> the documentation I read).
The list of directories seems plausible (better than using /tmp, anyway).
Classically O_EXCL was needed in such cases (if the log might end up
getting written to a file in a directory also writable by an attacker) not
just because of symlink attacks but also because it was possible to create
a hard link to another user's file, with similar potential for attacks as
with symlinks. Nowadays systems are more likely to restrict such hard
link creation (but they are also likely to have similar restrictions to
make symlink attacks harder as well).
Joseph S. Myers