This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH/Merge Request] Vtable Verification feature.


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
> ok?
> 
> 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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]