Re: [OE-core] [PATCH v3 1/3] glibc: Upgrade to 2.35 (RFC)

["Mittal, Anuj" <anuj.mittal@intel.com>]

On Wed, 2022-02-16 at 10:22 +0100, Martin Jansa wrote:
> Ubuntu patched their docker.io package shortly after upgrading to
> glibc-2.34 in Ubuntu-21.10, see:
> http://changelogs.ubuntu.com/changelogs/pool/universe/d/docker.io/docker.io_20.10.7-0ubuntu5~20.04.2/changelog
> 
> docker.io (20.10.7-0ubuntu4) impish; urgency=medium
> 
>   * d/p/seccomp-add-support-for-clone3-syscall-in-default-
> policy.patch: Fix
>     failure with new glibc clone3 syscall adding it to the default
> seccomp
>     policy (LP: #1943049).
> 
>  -- Lucas Kanashiro <kanashiro@ubuntu.com>  Fri, 10 Sep 2021 15:34:38
> -0300
> 
> AFAIK Ubuntu isn't affected anymore, I've
> updated https://bugzilla.yoctoproject.org/show_bug.cgi?id=1711 and
> I'm fine with dropping the patch now (it was useful before, but now
> distributions had enough time to prepare for 2.34 changes).

In case the uninative upgrade is merged in stable/LTS branches, it
might start showing up failures for people building on older
distributions that aren't being updated any more.

Thanks,

Anuj

> 
> On Wed, Feb 16, 2022 at 9:31 AM hongxu <hongxu.jia@windriver.com>
> wrote:
> > From upstream docker github [1]
> > The issue was found in 20.10.7, the the fix was merged
> > in v20.10.10-rc1 [2]
> > From docker release notes, it was published in version 20.10.10 at
> > 2021-10-25[3]
> > 
> > In ubuntu 20.04.2, the docker version is 20.10.7 (20.10.7-
> > 0ubuntu1~20.04.2) [4],
> > 
> > From [5], Ubuntu 21.10 and Fedora 35 has the issue
> > 
> > [1] https://github.com/moby/moby/issues/42680
> > 
> > seccomp filter breaks latest glibc (in fedora rawhide) by blocking
> > clone3 with EPERM · Issue #42680 · moby/moby · GitHub
> > Client: Version: 20.10.7 API version: 1.41 Go version: go1.16.6 Git
> > commit: f0df350 Built: Mon Jul 26 16:34:29 2021 OS/Arch:
> > linux/amd64 Context: default Experimental ...
> > github.com
> > 
> > [2] 
> > https://github.com/moby/moby/commit/6835d15f5523063f0a04a86d4810a63
> > 7c6010d62
> > 
> > [20.10] update containerd binary to v1.4.10 · moby/moby@6835d15
> > - Update runc to v1.0.2 - Update hcsshim to v0.8.21 - Support
> > &quot;clone3&quot; in default seccomp profile - Fix panic in
> > metadata content writer on copy error Signed-off-by: Sebastiaan van
> > Stijn...
> > github.com
> > 
> > 
> > [3] https://docs.docker.com/engine/release-notes/#201010
> > Docker Engine release notes - Docker Documentation
> > Docker Engine release notes. This document describes the latest
> > changes, additions, known issues, and fixes for Docker Engine.
> > Note: The client and container runtime are now in separate packages
> > from the daemon in Docker Engine 18.09. Users should install and
> > update all three packages at the same time to get the latest patch
> > releases.
> > docs.docker.com
> > 
> > 
> > [4] 
> > https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1948361
> > Bug #1948361 “docker.io - error adding seccomp filter rule for s...
> > : Bugs : docker.io package : Ubuntu
> > Encountered the following error using the docker.io package in
> > focal-proposed running the autotest-client-
> > test/ubuntu_performance_deep_learning test. "docker: Error response
> > from daemon: failed to create shim: OCI runtime create failed:
> > container_linux.go:380: starting container process caused: error
> > adding seccomp filter rule for syscall clone3: permission denied:
> > unknown." This test essentially pulls down a nvidia tensorflow
> > docker container, runs the container and triggers the preloaded ...
> > bugs.launchpad.net
> > 
> > 
> > [5] 
> > https://pascalroeleven.nl/2021/09/09/ubuntu-21-10-and-fedora-35-in-
> > docker/
> > Ubuntu 21.10 and Fedora 35 in Docker – Pascal Roeleven
> > Here I am, back again with another post which I think the internet
> > needs. It took me days to figure it out and I can’t imagine there
> > aren’t more people who are running into the same issue.
> > pascalroeleven.nl
> > 
> > //Hongxu
> > From: Khem Raj <raj.khem@gmail.com>
> > Sent: Wednesday, February 16, 2022 12:08 PM
> > To: Jia, Hongxu <Hongxu.Jia@windriver.com>
> > Cc: Richard Purdie <richard.purdie@linuxfoundation.org>;
> > openembedded-core@lists.openembedded.org
> > <openembedded-core@lists.openembedded.org>
> > Subject: Re: [OE-core] [PATCH v3 1/3] glibc: Upgrade to 2.35 (RFC) 
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> > 
> > 
> > On Tue, Feb 15, 2022 at 6:28 PM Jia, Hongxu
> > <Hongxu.Jia@windriver.com> wrote:
> > > Hi khem,
> > > 
> > > Upstream glibc reject it because the latest docker has supported
> > > it[1], and upstream glibc does not backward compatibility with
> > > old docker[2]
> > > 
> > > In order to build Yocto with uninative in old docker, we need
> > > this local patch
> > 
> > How old is the docker and I assume
> > It’s some distribution needing it ? 
> > > 
> > > [1] 
> > > https://github.com/moby/moby/commit/9f6b562dd12ef7b1f9e2f8e6f2ab6
> > > 477790a6594
> > > 
> > > seccomp: add support for "clone3" syscall in default policy ·
> > > moby/moby@9f6b562
> > > If no seccomp policy is requested, then the built-in default
> > > policy in dockerd applies. This has no rule for
> > > &quot;clone3&quot; defined, nor any default errno defined. So
> > > when runc receives the con...
> > > github.com
> > > 
> > > 
> > > [2]
> > > https://sourceware.org/pipermail/libc-alpha/2021-August/130590.ht
> > > ml
> > > 
> > > //Hongxu
> > > From: Khem Raj <raj.khem@gmail.com>
> > > Sent: Wednesday, February 16, 2022 12:17 AM
> > > To: Jia, Hongxu <Hongxu.Jia@windriver.com>
> > > Cc: openembedded-core@lists.openembedded.org
> > > <openembedded-core@lists.openembedded.org>; Richard Purdie
> > > <richard.purdie@linuxfoundation.org>
> > > Subject: Re: [OE-core] [PATCH v3 1/3] glibc: Upgrade to 2.35
> > > (RFC) 
> > > [Please note: This e-mail is from an EXTERNAL e-mail address]
> > > 
> > > 
> > > On Tue, Feb 15, 2022 at 12:25 AM Jia, Hongxu
> > > <Hongxu.Jia@windriver.com> wrote:
> > > > 
> > > > On 2/9/22 06:53, Khem Raj wrote:
> > > > 
> > > > diff --git a/meta/recipes-core/glibc/glibc/0001-fix-create-
> > > > thread-failed-in-unprivileged-process-BZ-.patch b/meta/recipes-
> > > > core/glibc/glibc/0001-fix-create-thread-failed-in-unprivileged-
> > > > process-BZ-.patch
> > > > deleted file mode 100644
> > > > index 3283dd7ad8a..00000000000
> > > > --- a/meta/recipes-core/glibc/glibc/0001-fix-create-thread-
> > > > failed-in-unprivileged-process-BZ-.patch
> > > > +++ /dev/null
> > > > @@ -1,79 +0,0 @@
> > > > -From a8bc44936202692edcd82a48c07d7cf27d6ed8ee Mon Sep 17
> > > > 00:00:00 2001
> > > > -From: Hongxu Jia <hongxu.jia@windriver.com>
> > > > -Date: Sun, 29 Aug 2021 20:49:16 +0800
> > > > -Subject: [PATCH] fix create thread failed in unprivileged
> > > > process [BZ #28287]
> > > > -
> > > > -Since commit [d8ea0d0168 Add an internal wrapper for clone,
> > > > clone2 and clone3]
> > > > -applied, start a unprivileged container (docker run without --
> > > > privileged),
> > > > -it creates a thread failed in container.
> > > > -
> > > > -In commit d8ea0d0168, it calls __clone3 if HAVE_CLONE3_WAPPER
> > > > is defined.  If
> > > > -__clone3 returns -1 with ENOSYS, fall back to clone or clone2.
> > > > -
> > > > -As known from [1], cloneXXX fails with EPERM if
> > > > CLONE_NEWCGROUP,
> > > > -CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, or
> > > > CLONE_NEWUTS
> > > > -was specified by an unprivileged process (process without
> > > > CAP_SYS_ADMIN)
> > > > -
> > > > -[1] https://man7.org/linux/man-pages/man2/clone3.2.html
> > > > -
> > > > -So if __clone3 returns -1 with EPERM, fall back to clone or
> > > > clone2 could
> > > > -fix the issue. Here are the test steps:
> > > > -
> > > > 
> > > > Hi RP,
> > > > 
> > > > 
> > > > I found this local patch was removed from glibc, we have to get
> > > > it back and regenerate uninative to avoid the thread creation
> > > > failure in  unprivileged container
> > > > 
> > > 
> > > I intentionally dropped it since upstream glibc will not accept
> > > this
> > > patch since its not glibc problem but
> > > rather container runtime problem. Can you investigate that path
> > > before
> > > we reapply it. Maintaining a rejected patch is last thing we want
> > > to
> > > do.
> > > 
> > > > 
> > > > //Hongxu
> > 
> > 
> > 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#161772):
> https://lists.openembedded.org/g/openembedded-core/message/161772
> Mute This Topic: https://lists.openembedded.org/mt/89009276/3616702
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/openembedded-core/unsub [
> anuj.mittal@intel.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>