SELinux Archive mirror
 help / color / mirror / Atom feed
From: Steve Langasek <steve.langasek@canonical.com>
To: selinux@vger.kernel.org
Subject: [PATCH] Always build for LFS mode on 32-bit archs.
Date: Thu, 15 Feb 2024 16:18:42 -0800	[thread overview]
Message-ID: <20240216001843.24839-1-steve.langasek@canonical.com> (raw)

Hello,

In Debian and Ubuntu, we are working to move future releases of the OS on
32-bit architectures (predominantly: armhf AKA arm-linux-gnueabihf) to use
64-bit time_t natively in anticipation of the y2038 event horizon.

While for most libraries we are taking the approach to rebuild in-place with
changed compiler flags and declaring incompatibility with previous package
builds via the package manager, libselinux is a sufficiently core part of
the OS (as a dependency of the package manager itself) that this is not
tenable.

Therefore I propose the following patch to libselinux to make it dual-ABI
for the single LFS-sensitive entry point, congruent to the way glibc itself
handles such changes.

The particular implementation doesn't use as many asm extension / symbol
version map tricks as glibc to make "nice" symbol names in the resulting
binary, it just gives us matchpathcon_filespec_add() and
matchpathcon_filespec_add64() as entrypoints.  If there is a preference for
more glibc-style handling with symbol versions I am happy to rework to
accomodate.

As this problem has been discovered rather late in our transition process, I
have a bit of a time crunch on my side which is not your problem, but I
would ask that whether or not the patch is ready to land, we reach a
consensus ASAP on:

  - whether it is acceptable to introduce a new entry point for this on
    32-bit architectures
  - the name this new entry point should use (including symbol version)
  - that it is acceptable to upstream that we proceed on implementing this
    at the distro level in advance of the patch landing upstream.

Thanks!


             reply	other threads:[~2024-02-16  0:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-16  0:18 Steve Langasek [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-02-16  0:32 [PATCH] Always build for LFS mode on 32-bit archs Steve Langasek
2024-02-16  0:35 ` Steve Langasek
2024-02-17 21:54   ` Kees Cook
2024-02-18  3:08     ` Steve Langasek
2024-02-25  6:45       ` Steve Langasek
2024-02-26 17:52         ` Christian Göttsche
2024-02-27  7:00           ` Steve Langasek
2024-02-27 17:13             ` Christian Göttsche
2024-02-28  6:11               ` Steve Langasek
2024-02-28  9:20                 ` Petr Lautrbach
2024-03-03  8:00                   ` Steve Langasek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240216001843.24839-1-steve.langasek@canonical.com \
    --to=steve.langasek@canonical.com \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).