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 jos...@codesourcery.com
