netdev - Re: ABI breakage in sctp_event_subscribe (was [PATCH net-next 0/4] sctp: add some missing events from rfc5061)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200601104630.GQ182140@nataraja>
Date:   Mon, 1 Jun 2020 12:46:30 +0200
From:   Harald Welte <laforge@...monks.org>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc:     Xin Long <lucien.xin@...il.com>,
        network dev <netdev@...r.kernel.org>,
        linux-sctp@...r.kernel.org
Subject: Re: ABI breakage in sctp_event_subscribe (was [PATCH net-next 0/4]
 sctp: add some missing events from rfc5061)

Dear SCTP developers,

I have to get back to this bug.  It is slowly turning into a nightmare.

Not only affected it forwards/backwards compatibility of application binaries
during upgrades of a distribution, but it also affects the ability to run
containerized workloads with SCTP.  It's sort-of obvious but I didn't
realize it until now.

We are observing this problem now when we operate CentOS 8 based containers
on a Debian 9 based (docker) host.  Apparently the CentOS userland has a different
definition of the event structure (larger) than the Debian kernel has (smaller) -> boom.

>From my point of view, this bug is making it virtually impossible to run
containerized telecom workloads.  I guess most users are very
conservative and still running rather ancient kernels and/or
distributions, but as soon as they start upgrading their kernel to
anything that includes that patch to the SCTP events structure, the
nightmare starts.

To my knowledge, there is no infrastructure at all for a situation like this - neither
in the Docker universe nor in k8s..  You cannot build separate container
images depending on what the host OS/kernel is going to be.

And particularly, if you are not self-hosting your container runtimes
but running your containers on some kind of cloud infrastructure
provider, you have no control over what exact kernel version might be in
use there - and it also may change at any time at the discretion of the
cloud service provider.

On Fri, May 01, 2020 at 11:20:08AM -0300, Marcelo Ricardo Leitner wrote:
> That's what we want as well. Some breakage happened, yes, by mistake,
> and fixing that properly now, without breaking anything else, may be
> just impossible, unfortunatelly. But you can be sure that we are
> engaged on not doing it again.

I would actually seriously consider to roll that change back - not only
in the next kernel release but also in all stable kernel releases.  At least
the breakage then is constrained to a limited set of kernel versions.

Alternatively, I suggest to at least apply a patch to all supported
stable kernel series (picked up hopefully distributions) that makes those
older kernels accept a larger-length sctp_event_subscribe structure from
userspace, *if* any of the additional members are 0 (memcmp the
difference between old and new).

Regards,
	Harald
-- 
- Harald Welte <laforge@...monks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)