[PSA] the LFS checks are coming in R108

43 views
Skip to first unread message

Mike Frysinger

unread,
Sep 8, 2022, 2:09:15 AM9/8/22
to chromium-os-dev
tl;dr: starting with R108, we'll enforce packages be built with LFS flags on 32-bit systems (i.e. ARM 32-bit userland).  newer packages missing the settings will fail to build with info as to why.

a recent bug in the selinux tools (http://b/242961867) was due to the package not being built with LFS flags.  this meant it couldn't process any files that were larger than 2 GiB ... like Chrome.

there are other ways that tools built w/out LFS can fail.  for example a filesystem that has 64-bit inode values -- programs can't even stat() them.  this doesn't seem to have hit us in CrOS yet, but as we add more storage to some devices and the stateful partition grows, i suspect it might be a bit of a ticking time bomb.  and one that might only affect some users in the field as the stateful fills up.

i've had a bug about this for a while, but wasn't putting too much time into it because it wasn't biting in a way we were actively seeing.
i finally dusted off the CLs to finish this up and they should be ready to land for R108.

there is a large list of existing packages that are known to be broken.  we'll file bugs for packages with owners to take a look at updating.
-mike

Manoj Gupta

unread,
Sep 8, 2022, 2:27:25 AM9/8/22
to Mike Frysinger, chromium-os-dev
Quick question:

Since LFS is added by build time flags, can we add them to default build flags [1] and reduce the chance of broken packages?


Thanks,
Manoj

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev

Mike Frysinger

unread,
Sep 8, 2022, 2:38:24 AM9/8/22
to Manoj Gupta, chromium-os-dev
i don't think that's safe.  it has the potential to change ABIs subtly (anything that uses off_t or struct stat) which is why debates in glibc to make it a default have always broken down.  even if it were safe, it would catch most cases, but it wouldn't catch all -- those flags would largely work for C/C++ only.

hence we've been delegating it to packages to opt-in after evaluation of their impact.  upstream packages often do this automatically via their own build systems, or are written to the relevant LFS APIs, or are aware enough to handle things.  platform2 for example does this.

y2k38 with 64-bit time_t will run into the same issue.  although i'm ignoring that, at least for the next few years, in the hope that we will only be doing 64-bit userlands by the time 2030 comes around.
-mike
Reply all
Reply to author
Forward
0 new messages