On Tue, Feb 25, 2020, 10:03 PM Wes Turner wes.turner@gmail.com wrote:

Is there a reason the new manylinux does not just extend centos:6?

https://github.com/pypa/manylinux/blob/master/docker/glibc/README.rst :

Summary: Because of

https://mail.python.org/pipermail/wheel-builders/2016-December/000239.html, this a CentOS 6.10 Docker image that rebuilds glibc without vsyscall is necessary to reliably run manylinux2010 on 64-bit hosts. This requires building the image on a system with vsyscall=emulate but allows the resulting container to run on systems with vsyscall=none or vsyscall=emulate.

vsyscall is an antiquated optimization for a small number of

frequently-used system calls. A vsyscall-enabled Linux kernel maps a read-only page of data and system calls into a process' memory at a fixed address. These system calls can then be invoked by dereferencing a function pointers to fixed offsets in that page, saving a relatively expensive context switch. [1]

Unfortunately, because the code and its location in memory are fixed and

well-known, the vsyscall mechanism has become a source of gadgets for ROP attacks (specifically, Sigreturn-Oriented Programs). [2] Linux 3.1 introduced vsyscall emulation that prevents attackers from jumping into the middle of the system calls' code at the expense of speed, as well as the ability to disable it entirely. [3] [4] The vsyscall mechanism could not be eliminated at the time because glibc versions earlier than 2.14 contained hard-coded references to the fixed memory address, specifically in time(2). [5] These segfault when attempting to issue a vsyscall-optimized system call against a kernel that has disabled it.

To be precise, these are not uploaded at all - there's no hidden repository on quay.io AFAICT, and I'm an owner of the pypa team there.

The CI on the manylinux repo always builds both stages one after the other. They're split as an implementation detail - if I recall correctly, doing everything in one Dockerfile tended to hit a timeout on Travis. So I'm inclined to say that the intermediate image is not any kind of a public interface, and you should build it from the git repository if you need it.

Thomas

On Wed, Feb 26, 2020, at 9:12 AM, Sylvain Corlay wrote:

I am fine with there being a specific base image but I think that it should be pullable.

On Wed, Feb 26, 2020, 04:06 Wes Turner wes.turner@gmail.com wrote:

...

On Tue, Feb 25, 2020, 10:03 PM Wes Turner wes.turner@gmail.com wrote:

...

Is there a reason the new manylinux does not just extend centos:6?

https://github.com/pypa/manylinux/blob/master/docker/glibc/README.rst :

...

Summary: Because of https://mail.python.org/pipermail/wheel-builders/2016-December/000239.html, this a CentOS 6.10 Docker image that rebuilds glibc without vsyscall is necessary to reliably run manylinux2010 on 64-bit hosts. This requires building the image on a system with vsyscall=emulate but allows the resulting container to run on systems with vsyscall=none or vsyscall=emulate.

vsyscall is an antiquated optimization for a small number of frequently-used system calls. A vsyscall-enabled Linux kernel maps a read-only page of data and system calls into a process' memory at a fixed address. These system calls can then be invoked by dereferencing a function pointers to fixed offsets in that page, saving a relatively expensive context switch. [1]

Unfortunately, because the code and its location in memory are fixed and well-known, the vsyscall mechanism has become a source of gadgets for ROP attacks (specifically, Sigreturn-Oriented Programs). [2] Linux 3.1 introduced vsyscall emulation that prevents attackers from jumping into the middle of the system calls' code at the expense of speed, as well as the ability to disable it entirely. [3] [4] The vsyscall mechanism could not be eliminated at the time because glibc versions earlier than 2.14 contained hard-coded references to the fixed memory address, specifically in time(2). [5] These segfault when attempting to issue a vsyscall-optimized system call against a kernel that has disabled it.

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/T6KDL...

No problem. It is a bit confusing that it's tagged as though it's going to be uploaded.

On Thu, Feb 27, 2020, at 12:41 PM, Sylvain Corlay wrote:

Thanks Thomas, I was mistaken by the first line of the docker image which includes a full URL on quay.io

FROM quay.io/pypa/manylinux2010_centos-6-no-vsyscall

We will build this image ourself.

Best,

On Wed, Feb 26, 2020 at 10:38 AM Thomas Kluyver thomas@kluyver.me.uk wrote:

...

__ To be precise, these are not uploaded at all - there's no hidden repository on quay.io AFAICT, and I'm an owner of the pypa team there.

The CI on the manylinux repo always builds both stages one after the other. They're split as an implementation detail - if I recall correctly, doing everything in one Dockerfile tended to hit a timeout on Travis. So I'm inclined to say that the intermediate image is not any kind of a public interface, and you should build it from the git repository if you need it.

Thomas

On Wed, Feb 26, 2020, at 9:12 AM, Sylvain Corlay wrote:

...

I am fine with there being a specific base image but I think that it should be pullable.

On Wed, Feb 26, 2020, 04:06 Wes Turner wes.turner@gmail.com wrote:

...

On Tue, Feb 25, 2020, 10:03 PM Wes Turner wes.turner@gmail.com wrote:

...

Is there a reason the new manylinux does not just extend centos:6?

https://github.com/pypa/manylinux/blob/master/docker/glibc/README.rst :

...

Summary: Because of https://mail.python.org/pipermail/wheel-builders/2016-December/000239.html, this a CentOS 6.10 Docker image that rebuilds glibc without vsyscall is necessary to reliably run manylinux2010 on 64-bit hosts. This requires building the image on a system with vsyscall=emulate but allows the resulting container to run on systems with vsyscall=none or vsyscall=emulate.

vsyscall is an antiquated optimization for a small number of frequently-used system calls. A vsyscall-enabled Linux kernel maps a read-only page of data and system calls into a process' memory at a fixed address. These system calls can then be invoked by dereferencing a function pointers to fixed offsets in that page, saving a relatively expensive context switch. [1]

Unfortunately, because the code and its location in memory are fixed and well-known, the vsyscall mechanism has become a source of gadgets for ROP attacks (specifically, Sigreturn-Oriented Programs). [2] Linux 3.1 introduced vsyscall emulation that prevents attackers from jumping into the middle of the system calls' code at the expense of speed, as well as the ability to disable it entirely. [3] [4] The vsyscall mechanism could not be eliminated at the time because glibc versions earlier than 2.14 contained hard-coded references to the fixed memory address, specifically in time(2). [5] These segfault when attempting to issue a vsyscall-optimized system call against a kernel that has disabled it.

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/T6KDL...

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/OR3MY...