You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is the outcome of systemd/systemd#11974 (comment) (found via #3914, which is just for the Samsung 500C, which may or may not have other issues; this issue is specifically about the kernel issue parts across all 32-bit x86 Chromebooks with certain kernel versions, thus a separate issue).
Copying over the summary:
An upstream Linux bug broke ENOSYS being returned on invalid syscalls if sysenter was used.
It was fixed in upstream Linux 1 month later (and the bug apparently never made it into an upstream kernel release without the fix).
ChromiumOS cherry-picked the bug starting from their 3.8 release, but apparently forgot to cherry-pick the fix for years.
As a result systemd based Linux distributions in crouton chroots work for any 32-bit i686 ChromeOS that has uname -a < 3.8, break for everything above that until 3.18, where they should work again.
Unfortunately, many ChromeOS laptops (including the one I found this on) were end-of-lifed on versions within the broken range. For those, a workaround should be downgrading to a ChromeOS version that has a kernel <= 3.4. (Note that running unmaintained old kernels is generally insecure, but unfortunately booting custom kernels isn't easy on that range of devices either.)
This means that
Crouton will fail to install Linux distributions using systemd on Chromebooks with kernels 3.8, 3.10 or 3.14.
Even if systemd is not used, the underlying issue is a kernel bug that can also result in arbitrary behaviour of any other application.
I think we should
Put a note on Crouton's README about this
Figure out whether there's a workaround
for example, running applications under strace fixes the issue (as described)
a global workaround would be if we could tell glibc or the kernel to always use int 0x80 for system calls instead sysenter via the VDSO (I don't know if glibc provides an override for that)
(perhaps not the right place here to figure this one out:) Running on old kernels is a security problem; figure out how we can boot a real, new Linux kernel instead of Crouton chroots for the affected end-of-life'd devices, like ChrUbuntu did.
The text was updated successfully, but these errors were encountered:
Thanks for discovering this and for the thorough documentation.
While it would be super easy to cherry-pick that fixup patch in the chromeos kernel branches, none of the chromebooks that we still update are x86 32bit.
So landing the patch wouldn't really fix anything.
Basically, as long as we inject a /etc/machine-id before the systemd package is installed, it will turn systemd-machine-id-setup into a no-op and will allow the installation to bypass this problem.
That said, given how old these kernels are, I don't know if it's worth trying to submit a PR for this. But if someone comes across this in the future, please feel free to try patching in my commit above.
This is the outcome of systemd/systemd#11974 (comment) (found via #3914, which is just for the Samsung 500C, which may or may not have other issues; this issue is specifically about the kernel issue parts across all 32-bit x86 Chromebooks with certain kernel versions, thus a separate issue).
Copying over the summary:
ENOSYS
being returned on invalid syscalls ifsysenter
was used.systemd
based Linux distributions incrouton
chroots work for any 32-biti686
ChromeOS that hasuname -a
< 3.8, break for everything above that until 3.18, where they should work again.This means that
systemd
on Chromebooks with kernels 3.8, 3.10 or 3.14.I think we should
README
about thisstrace
fixes the issue (as described)int 0x80
for system calls insteadsysenter
via the VDSO (I don't know if glibc provides an override for that)ChrUbuntu
did.The text was updated successfully, but these errors were encountered: