V2 [PATCH] x86: Add --enable-cet=permissive

[H.J. Lu]

On Wed, Apr 29, 2020 at 2:58 PM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
>
> On 29/04/2020 17:46, Florian Weimer wrote:
> > * Adhemerval Zanella via Libc-alpha:
> >
> >> On 28/04/2020 18:52, H.J. Lu via Libc-alpha wrote:
> >>> When CET is enabled, it is an error to dlopen a non CET enabled shared
> >>> library in CET enabled application.  It may be desirable to make CET
> >>> permissive, that is disable CET when dlopening a non CET enabled shared
> >>> library.  With the new --enable-cet=permissive configure option, CET is
> >>> disabled when dlopening a non CET enabled shared library.
> >>
> >> Does not CET already provide a tunable to make it permissive? If the idea
> >> is to enable as de-facto for a distro bootstrap, why not make it default
> >> then?
> >
> > We currently do not have a way to set a tunable for SUID binaries.
> >
> > This means that it would be necessary to disable CET at the kernel or
> > hypervisor level if the system depends on pre-CET NSS or PAM modules
> > for its operation (or something else which is ultimately
> > dlopen-based).
>
> Doesn't disable CET on some modules defeat the very security effort? If so,
> why should it be a build option on glibc?

I consider it as a transitional build option for OSVs.  OSV should
use it only as the last resort.  I expect we will remove this option
a few years from now when all major pieces of OS are CET enabled.

Here is the updated patch against today's master.

Thanks.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x86-Add-enable-cet-permissive.patch
Type: text/x-patch
Size: 14460 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20200518/ed294a75/attachment-0001.bin>