Depending on libc++

[danakj]

Hi Embedders,

I have a proposal to always depend on libc++ in Chromium. This only affects Linux, where we currently allow using libstdc++ when linking Chromium.

The choice of libstdc++ has a large security impact on Chromium, as we depend on the implementation details of libc++, and it will also restrict language interop in the future.

The GCC build will continue to be supported as it is today.

Design doc is here: https://docs.google.com/document/d/193ig0qeM23rK1yH6bW14O3zIgVztyKaY4R1XRwgmUFk/edit?usp=sharing

I'd welcome any feedback.

Thanks,

Dana

[José Dapena Paz]

Hi,

First, I added support some time ago to enable _GLIBCXX_ASSERTIONS in our libstdc++ builds. It should be enabled by default. But those assertions are still missing some checks in libstdc++ I think we do in libc++. So, first, maybe it would be nice to move to make libstdc++ do the same checks intensive hardening mode is doing in libc++. Not only for Chromium, but for any other application that wants to jump in using those checks.

Second: I am maintaining (o trying at least) the libstdc++ support in Chromium. But, honestly, I have been recommending people to move to libc++ and Clang as soon as possible, because otherwise people are not getting all the benefits of the testing/CI/fuzz/etc etc that we get from upstream Chromium project. I still think that all downstreams building Chromium themselves should be building the really supported toolchain. I would like to get feedback from them on why they would still keep GCC/libstdc++, increasing the risk for their users. Cost of building Clang + libc++ for distributions doest NOT justify honestly building Chromium with an unexpected toolchain.

Third: there is an important reason, specially for embedders, to use libstdc++: third party C++ libraries using STL in their public API. Requiring to build using libc++ implies also rebuilding those libraries in libc++ (or bridging the API so we do not have in the same files users of libc++ and libstdc++). There are several ways to mitigate this, but if libstdc++ support is going away, it would be nice to have some time for those embedders to be sure they are ready to use only libc++.

From my side, I would prefer to avoid immediately dropping libstdc++ support, and instead propose a deprecation plan. But that would be in case embedders explicitely ask for that. If nobody complains in some days... or weeks, then we could jump directly to disable the support. I will check with the downstreams I work with, to ask for their position.

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAHtyhaQMu4%2B6YwJfeEUa%3Dtap%2BGQr0Y%2B2xgoV3o6UyMQGfyeKVw%40mail.gmail.com.

[David McAllister]

We build using libstdc++ for Silk. We're in the process of moving to libc++ but that's probably a year away for us.I do think there is some value in allowing some level of support for libstdc++ though. Our build ran into https://issues.chromium.org/issues/341812566 which did not seem to have been caught by any of the standard build configurations.

[Tomasz Śniatowski]

Hi,

We have to sometimes deal with third party C++ libraries, only doing libstdc++, on our side. This is exactly the third concern mentioned a few days ago. A sudden hard switch would be a pain.

--

Tomasz

[danakj]

Thanks for the feedback, here and in the doc.

I am hearing that the concern here is just around lead time and roll out. So I will go ahead and start by adding a warning into the GN files when libc++ is not used, and we can move toward removing support in a few milestones.

Cheers,

Dana

--
--
-----
secu...@chromium.org is for discussing vulnerabilities and fixes in Chromium code.
Please protect Chromium users: DO NOT FORWARD this email or disclose its contents to third parties.
 
http://groups.google.com/a/chromium.org/group/security

To unsubscribe from this group and stop receiving emails from it, send an email to security+u...@chromium.org.

[danakj]

Please follow crbug.com/372852985 for updates and use it for providing more feedback if things go wrong along the way.

[Gabriel FORTE]

Hi,

The wording in the proposal is a bit misleading: it proposal specifically mentions libstdc++, but we can also (and we do here, for obvious binary size reasons) use libc++ linked dynamically.

However, use_custom_libcxx is also used to enforce static linking of //buildtools/third_party/libc++

Will there still be an option to link with an external libc++ ?

[Marshall Greenblatt]

On Thu, Nov 7, 2024 at 11:08 AM 'Gabriel FORTE' via Chromium Embedders <embedd...@chromium.org> wrote:

Hi,

The wording in the proposal is a bit misleading: it proposal specifically mentions libstdc++, but we can also (and we do here, for obvious binary size reasons) use libc++ linked dynamically.

However, use_custom_libcxx is also used to enforce static linking of //buildtools/third_party/libc++

Will there still be an option to link with an external libc++ ?

We also use use_custom_libcxx=true on Windows to link //base against MSVC libc++ (example). Hopefully that option won't be going away.

 

On Friday, October 11, 2024 at 4:15:17 PM UTC+2 danakj wrote:

Hi Embedders,

I have a proposal to always depend on libc++ in Chromium. This only affects Linux, where we currently allow using libstdc++ when linking Chromium.

The choice of libstdc++ has a large security impact on Chromium, as we depend on the implementation details of libc++, and it will also restrict language interop in the future.

The GCC build will continue to be supported as it is today.

Design doc is here: https://docs.google.com/document/d/193ig0qeM23rK1yH6bW14O3zIgVztyKaY4R1XRwgmUFk/edit?usp=sharing

I'd welcome any feedback.

Thanks,

Dana

--

You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/f22e509d-0630-45a7-b9f2-0aec33656cecn%40chromium.org.

[Marshall Greenblatt]

On Thu, Nov 7, 2024 at 11:48 AM Marshall Greenblatt <magree...@gmail.com> wrote:

On Thu, Nov 7, 2024 at 11:08 AM 'Gabriel FORTE' via Chromium Embedders <embedd...@chromium.org> wrote:

Hi,

The wording in the proposal is a bit misleading: it proposal specifically mentions libstdc++, but we can also (and we do here, for obvious binary size reasons) use libc++ linked dynamically.

However, use_custom_libcxx is also used to enforce static linking of //buildtools/third_party/libc++

Will there still be an option to link with an external libc++ ?

We also use use_custom_libcxx=true on Windows to link //base against MSVC libc++ (example). Hopefully that option won't be going away.

That should say use_custom_libcxx=false

[danakj]

On Thu, Nov 7, 2024 at 11:51 AM Marshall Greenblatt <magree...@gmail.com> wrote:

On Thu, Nov 7, 2024 at 11:48 AM Marshall Greenblatt <magree...@gmail.com> wrote:

On Thu, Nov 7, 2024 at 11:08 AM 'Gabriel FORTE' via Chromium Embedders <embedd...@chromium.org> wrote:

Hi,

The wording in the proposal is a bit misleading: it proposal specifically mentions libstdc++, but we can also (and we do here, for obvious binary size reasons) use libc++ linked dynamically.

However, use_custom_libcxx is also used to enforce static linking of //buildtools/third_party/libc++

Will there still be an option to link with an external libc++ ?

This is a good question. As long as the library is compiled with the same flags as Chromium uses (which would be required anyway for ABI correctness), it should not be an issue.

 

We also use use_custom_libcxx=true on Windows to link //base against MSVC libc++ (example). Hopefully that option won't be going away.

That should say use_custom_libcxx=false

For the reasons described in the document, including that Chromium is going to fail to compile in the future with MSVC stdlib (similar reasons as with libstdc++), support for libraries other than libc++ is going away.

 

 

 

On Friday, October 11, 2024 at 4:15:17 PM UTC+2 danakj wrote:

Hi Embedders,

I have a proposal to always depend on libc++ in Chromium. This only affects Linux, where we currently allow using libstdc++ when linking Chromium.

The choice of libstdc++ has a large security impact on Chromium, as we depend on the implementation details of libc++, and it will also restrict language interop in the future.

The GCC build will continue to be supported as it is today.

Design doc is here: https://docs.google.com/document/d/193ig0qeM23rK1yH6bW14O3zIgVztyKaY4R1XRwgmUFk/edit?usp=sharing

I'd welcome any feedback.

Thanks,

Dana

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/f22e509d-0630-45a7-b9f2-0aec33656cecn%40chromium.org.

--

--
-----
secu...@chromium.org is for discussing vulnerabilities and fixes in Chromium code.
Please protect Chromium users: DO NOT FORWARD this email or disclose its contents to third parties.
 
http://groups.google.com/a/chromium.org/group/security

To unsubscribe from this group and stop receiving emails from it, send an email to security+u...@chromium.org.

[Marshall Greenblatt]

On Thu, Nov 7, 2024 at 12:00 PM danakj <dan...@chromium.org> wrote:

On Thu, Nov 7, 2024 at 11:51 AM Marshall Greenblatt <magree...@gmail.com> wrote:

On Thu, Nov 7, 2024 at 11:48 AM Marshall Greenblatt <magree...@gmail.com> wrote:

On Thu, Nov 7, 2024 at 11:08 AM 'Gabriel FORTE' via Chromium Embedders <embedd...@chromium.org> wrote:

Hi,

The wording in the proposal is a bit misleading: it proposal specifically mentions libstdc++, but we can also (and we do here, for obvious binary size reasons) use libc++ linked dynamically.

However, use_custom_libcxx is also used to enforce static linking of //buildtools/third_party/libc++

Will there still be an option to link with an external libc++ ?

This is a good question. As long as the library is compiled with the same flags as Chromium uses (which would be required anyway for ABI correctness), it should not be an issue.

 

We also use use_custom_libcxx=true on Windows to link //base against MSVC libc++ (example). Hopefully that option won't be going away.

That should say use_custom_libcxx=false

For the reasons described in the document, including that Chromium is going to fail to compile in the future with MSVC stdlib (similar reasons as with libstdc++), support for libraries other than libc++ is going away.

Thanks for the clarification. This will be a significant problem for third-party applications that embed Chromium and wish to enable the sandbox on Windows (full details here). Do you have any recommendations on how we can support this use case moving forward?

 

 

 

 

On Friday, October 11, 2024 at 4:15:17 PM UTC+2 danakj wrote:

Hi Embedders,

I have a proposal to always depend on libc++ in Chromium. This only affects Linux, where we currently allow using libstdc++ when linking Chromium.

The choice of libstdc++ has a large security impact on Chromium, as we depend on the implementation details of libc++, and it will also restrict language interop in the future.

The GCC build will continue to be supported as it is today.

Design doc is here: https://docs.google.com/document/d/193ig0qeM23rK1yH6bW14O3zIgVztyKaY4R1XRwgmUFk/edit?usp=sharing

I'd welcome any feedback.

Thanks,

Dana

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/f22e509d-0630-45a7-b9f2-0aec33656cecn%40chromium.org.

--
--
-----
secu...@chromium.org is for discussing vulnerabilities and fixes in Chromium code.
Please protect Chromium users: DO NOT FORWARD this email or disclose its contents to third parties.
 
http://groups.google.com/a/chromium.org/group/security

To unsubscribe from this group and stop receiving emails from it, send an email to security+u...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAHtyhaQuSuDTx8Qvns5S32OzzJmNXUDeZ46hVbdb-tx0C-wOZw%40mail.gmail.com.