[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crouton essentially broken on 32-bit x86 ChromeOS kernels > 3.4 and < 3.18 #4016

Closed
2 tasks
nh2 opened this issue Mar 18, 2019 · 2 comments · Fixed by #4320
Closed
2 tasks

Crouton essentially broken on 32-bit x86 ChromeOS kernels > 3.4 and < 3.18 #4016

nh2 opened this issue Mar 18, 2019 · 2 comments · Fixed by #4320

Comments

@nh2
Copy link
nh2 commented Mar 18, 2019

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.
@amstan
Copy link
amstan commented Mar 19, 2019

Hello again,

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.

@jichu4n
Copy link
Contributor
jichu4n commented Jul 21, 2020

Thanks so much to @nh2 for the thorough investigation on this! I was able to find a (rather crude) workaround for this issue based on your findings: https://github.com/jichu4n/crouton/commit/0c61fd0b7e115ba2d9d0a9d818287bfc27940203

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.

dnschneid added a commit that referenced this issue Jul 24, 2020
Pre-populate /etc/machine-id to work around systemd install error on certain kernels (issue #4016)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants