RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2116444 - kernel: Backport vfork support for time namespaces
Summary: kernel: Backport vfork support for time namespaces
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: kernel
Version: 8.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Oleg Nesterov
QA Contact: Chunyu Hu
URL:
Whiteboard:
Depends On: 2116442
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-08-08 14:15 UTC by Florian Weimer
Modified: 2023-05-16 10:31 UTC (History)
3 users (show)

Fixed In Version: kernel-4.18.0-451.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2116442
Environment:
Last Closed: 2023-05-16 08:50:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/rhel/src/kernel rhel-8 merge_requests 4057 0 None None None 2023-01-06 15:14:19 UTC
Red Hat Issue Tracker RHELPLAN-130505 0 None None None 2022-08-08 14:23:14 UTC
Red Hat Product Errata RHSA-2023:2951 0 None None None 2023-05-16 08:51:00 UTC

Description Florian Weimer 2022-08-08 14:15:25 UTC
+++ This bug was initially created as a clone of Bug #2116442 +++

This commit

commit 769071ac9f20b6a447410c7eaa55d1a5233ef40c
Author: Andrei Vagin <avagin>
Date:   Tue Nov 12 01:26:52 2019 +0000

    ns: Introduce Time Namespace

added support for unshare(CLONE_NEWTIME), but the initial implementation was incompatible with vfork. This has been fixed in this commit (merged into Linux 6.0):

commit 133e2d3e81de5d9706cab2dd1d52d231c27382e5
Author: Andrei Vagin <avagin>
Date:   Sun Jun 12 23:07:22 2022 -0700

    fs/exec: allow to unshare a time namespace on vfork+exec
    
    Right now, a new process can't be forked in another time namespace
    if it shares mm with its parent. It is prohibited, because each time
    namespace has its own vvar page that is mapped into a process address
    space.
    
    When a process calls exec, it gets a new mm and so it could be "legal"
    to switch time namespace in that case. This was not implemented and
    now if we want to do this, we need to add another clone flag to not
    break backward compatibility.
    
    We don't have any user requests to switch times on exec except the
    vfork+exec combination, so there is no reason to add a new clone flag.
    As for vfork+exec, this should be safe to allow switching timens with
    the current clone flag. Right now, vfork (CLONE_VFORK | CLONE_VM) fails
    if a child is forked into another time namespace. With this change,
    vfork creates a new process in parent's timens, and the following exec
    does the actual switch to the target time namespace.
    
    Suggested-by: Florian Weimer <fweimer>
    Signed-off-by: Andrei Vagin <avagin>
    Acked-by: Christian Brauner (Microsoft) <brauner>
    Signed-off-by: Kees Cook <keescook>
    Link: https://lore.kernel.org/r/20220613060723.197407-1-avagin@gmail.com

Without this kernel change, we'd have to patch glibc and various other libraries that provide generic process-start facilities that are based on vfork, so that applications can call unshare(CLONE_NEWTIME) and still launch new processes.

Comment 2 Oleg Nesterov 2022-10-17 11:06:20 UTC
(In reply to Florian Weimer from comment #0)
>
> commit 133e2d3e81de5d9706cab2dd1d52d231c27382e5
> Author: Andrei Vagin <avagin>
> Date:   Sun Jun 12 23:07:22 2022 -0700
> 
>     fs/exec: allow to unshare a time namespace on vfork+exec
     
It turns out, we need to put this bz on hold.

Firstly, it is not that trivial to backport this patch as I thought,
but this is solvable.

The main problem is that this patch was reverted upstream, see the
commit 33a2d6bc3480f9f ("Revert "fs/exec: allow to unshare a time
namespace on vfork+exec"").

People are working on another version, I think we need to wait until
the new patch is merged upstream.

Comment 14 errata-xmlrpc 2023-05-16 08:50:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: kernel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2951


Note You need to log in before you can comment on or make changes to this bug.