[HN Gopher] Running unmodified Linux programs on Fuchsia
___________________________________________________________________
Running unmodified Linux programs on Fuchsia
Author : lyssue
Score : 102 points
Date : 2021-02-11 17:43 UTC (5 hours ago)
(HTM) web link (fuchsia-review.googlesource.com)
(TXT) w3m dump (fuchsia-review.googlesource.com)
| andy_ppp wrote:
| Could they not just support .snap or whatever the container as an
| app system of the day is?
| tyingq wrote:
| I assume it means coming up with a reasonable emulation of
| signals, fork(), etc. Something similar to how WSL1 works,
| since Fuchsia is significantly different from POSIX in some
| areas.
| h_anna_h wrote:
| Do you know where we could read about the internals of
| Fuchsia?
| tyingq wrote:
| Some of it is here: https://fuchsia.googlesource.com/docs/+
| /refs/heads/sandbox/j...
|
| You can see, though, large parts are TBD.
| fredgrott wrote:
| yes but are they not re-using the MS put it a container
| strategy of how they handle the differences between their
| specific kernel and hoe Linux kernel and Unix POSIX
| standards are implemented?
| bestorworse wrote:
| This wouldn't solve the problem. It would push the problem one
| level lower.
| dlojudice wrote:
| Does anyone know how different a Fuchsia program is from a Linux
| program? OS APIs, memory model, security model, etc.
| linuxftw wrote:
| Fuchsia's not a real thing and it's never going to be. You
| don't have to worry about it, it's just a make-work project for
| some people at google to feel cool.
| dane-pgp wrote:
| More likely, Google have done threat modelling of their
| entire business and worked out that if there was ever some
| legal problem with using Linux (like the infamous SCO case),
| the amount of economic damage it would do to them would be
| more than whatever resources they are spending on coming up
| with an alternative (which will hopefully never need to be
| used).
|
| Also, just as Chrome gave them a seat at the table of web
| standardisation, and a chance to try new ideas that didn't
| have to go through Mozilla's approval process, having a
| kernel of their own allows them to influence the OS design
| space in ways that are more aligned to their business goals,
| and without needing Linus's approval.
| linuxftw wrote:
| They can use BSD to build whatever they want if they're
| worried about the GPL.
|
| I think that someone at google built fuschia for the sake
| of building it. Their core business is still search, that's
| all Android is. If they launch their own fuschia based
| handset, people are unlikely to switch, OEMs are unlikely
| to switch. It's just a failed concept.
| cycloptic wrote:
| See some of the sibling comments, fuchsia is BSD-licensed
| and has a new design not based on any Unix.
| linuxftw wrote:
| I'm talking about BSD the operating system concerning the
| OP's assertion of managing risk.
|
| Last I checked (years ago), the userspace was implemented
| partially with musl, which reads
|
| > 'musl, pronounced like the word "mussel", is an MIT-
| licensed implementation of the standard C library
| targetting the Linux syscall API,
|
| Now, they're announcing running Linux programs on
| Fuchsia. Sure seems to me they're implementing a Unix-
| like system, even if their kernel was written from
| scratch.
|
| The BSD world doesn't consider the userspace very
| separate from the kernel space, it's all part of a single
| system.
|
| I would argue it's very much 'based on Unix' as soon as
| they start adding POSIX APIs. They're adding POSIX APIs
| because they work.
| cycloptic wrote:
| They're using a fork of musl for compatibility that omits
| some things: https://fuchsia.dev/fuchsia-
| src/concepts/system/libc
|
| >Fuchsia does not require that programs use libc's ABI.
| Programs are free to use their own libc, or to do
| without.
|
| As has been said in other comments, it's not much
| different from Wine or Linux emulation in FreeBSD.
| rvz wrote:
| I can take it from your username that you feel that Fuchsia
| is a threat to your beloved Linux Desktop to the point of
| having complete denial that the project is not real. It's OK
| to be scared.
|
| But I'm afraid you have to someday accept that some of Big
| Tech is 'using' Linux as a stop gap to either create their
| own proprietary subsystems around it or a completely new OS
| compatible with Android for which they pretend 'they care'
| about Linux.
|
| They only care if it's only for their interests as we can
| evidently see for Fuchsia Android support and WSL2 GPU
| hardware acceleration support.
| linuxftw wrote:
| Just the opposite. I don't think Fuchsia is much of
| anything at all, let alone a threat.
|
| As far as Big Tech, EEE is a legitimate concern.
|
| As far as Google, they've demonstrated countless times
| they're not to be trusted. If someone does business with
| them, they are being foolish. Fortunately, outside of
| search and chrome, they're not very competent, so they're
| not much of a threat.
| saagarjha wrote:
| It's fairly different; the OS is built on capabilities and
| exposing its system API via libc. By default applications get
| nothing. Resources are objects. IPC is done using a wire format
| called FIDL.
| CameronNemo wrote:
| If they do, they are likely a google engineer.
| lima wrote:
| ... aaand a Google engineer showed up to answer the question.
| The beauty of HN :)
| tyingq wrote:
| This covers some of that.
| https://fuchsia.googlesource.com/docs/+/refs/heads/sandbox/j...
| abarth wrote:
| The memory model is similar (a flat, linear address space). The
| OS APIs are quite different. Fuchsia's OS APIs are designed
| around an object-capability discipline. For example, almost all
| the syscalls take a zx_handle_t as their first argument, which
| means they are operations on an object the process has
| previously been granted access explicitly. In Linux, many OS
| APIs operate on the "ambient" environment rather than on a
| specific kernel object.
|
| Disclosure: I work on Fuchsia.
| itissid wrote:
| is this like Wine https://en.wikipedia.org/wiki/Wine_(software)?
| CarelessExpert wrote:
| Yeah, though a more direct analog might be FreeBSD's emulation
| layer:
| https://docs.freebsd.org/doc/9.0-RELEASE/usr/share/doc/freeb...
| abarth wrote:
| There are some similarities. The main difference is that Wine
| is mostly in-process whereas, in this design is mostly out-of-
| process. I'll add a section on Wine to the "prior art" section
| of the doc.
|
| Disclosure: I wrote the doc linked above.
| swiley wrote:
| Android putting graphics drivers outside the kernel and not under
| the GPL has created enough of a disaster. I don't look forward to
| the day when everyone is running a kernel that doesn't force SoC
| manufactures to share even the most basic drivers.
| marcodiego wrote:
| Android has been a mostly positive thing for linux, but it
| could be much more if so google desired. Google had the
| influence and power position to force many important drivers to
| become blob-free or open source (GPU, VPU, GSM modems, wifi,
| bluetooth), but it looks like they just didn't care.
| swiley wrote:
| It had the opportunity to be a positive thing for Linux but I
| would argue it really hasn't been. Your comment makes a good
| point: Google had the power to fix a lot of this but didn't.
| coldtea wrote:
| Do they seem like caring otherwise?
| dleslie wrote:
| Android has been one of the most negative contributors to
| general computing.
|
| We entered the new millennium with the concept that most
| computers could use most extension hardware with (relatively)
| little effort, and you could upgrade your computer's basic
| operating system at will; even change it to another one
| entirely.
|
| I'd love to update my still-decent Android phones that have
| long since stopped receiving security updates, but I can't.
| This is objectively inferior, a massive regression from
| general computing.
| znpy wrote:
| > We entered the new millennium with the concept that most
| computers could use most extension hardware with
| (relatively) little effort, and you could upgrade your
| computer's basic operating system at will; even change it
| to another one entirely.
|
| > I'd love to update my still-decent Android phones that
| have long since stopped receiving security updates, but I
| can't. This is objectively inferior, a massive regression
| from general computing.
|
| this is one of the smelliest BS i've read on hn in the last
| year or two. phones before android were not upgradable AT
| ALL. if you were lucky, you could put a bigger memory card,
| and that was it.
|
| nowadays you can access most of the sources of the os for
| your average android smartphone, you can rebuild the os and
| reflash it yourself. doing such thigs was a basically just
| wet dream in early 2000s.
| dleslie wrote:
| > phones before android were not upgradable AT ALL.
|
| They weren't general computing devices. They were for
| making phone calls, sending SMS messages, and tracking
| contacts. The security risk profile did not include
| access to social media accounts and/or online banking.
|
| For many folks, and a growing many folks, their phones
| are now their primary computing devices. For many folks,
| their primary computing devices no longer receive
| security updates.
|
| > you can rebuild the os and reflash it yourself.
|
| Tell me how I do that if I cannot root the phone.
| edent wrote:
| Err... The Nokia N series received frequent updates
| before Android ever came along. Blackberry constantly
| updated its OS.
|
| Sure, some carriers restricted updates - but that's still
| a problem Android faces.
| Mediterraneo10 wrote:
| The Nokia N900 got its last official update in November
| 2010, if I recall correctly. It had only been launched a
| year and a half before. Yes, there was then a community
| effort to improve some of the userspace, but the device
| was eternally stuck on a 2.6 kernel due to blobs. I loved
| my N900, but let's not pretend Nokia made their hardware
| future-proof.
| swiley wrote:
| PostmarketOS still runs on it.
| 533474 wrote:
| He did not say that phones were upgradable; he mentioned
| 'computing devices'. Calling another comment dumb does
| not help your argument.
| dathinab wrote:
| > but it looks like they just didn't care.
|
| Which is the funny thing, given how much closed source
| drivers have hurt android as far as I can tell.
| captainmuon wrote:
| It's not a problem in the Windows world that drivers are not
| open source. I think rather than forcing them to put the
| drivers under GPL, we should fix the fact that embedded systems
| always need custom images.
|
| On x86, you can just grab a Windows or Linux .iso and it will
| enumerate all hardware via PnP and install the appropriate
| drivers. This is something that is sorely missing in the Arm
| world. Instead you get semi-closed BSPs, source code thrown
| over the wall, and you have to write your own device-tree files
| and often kernel code to get something to run. SSBA is a start
| but only targeting the server market.
| jraph wrote:
| > It's not a problem in the Windows world that drivers are
| not open source
|
| Yes it is. Let alone the inability to study the source code
| and other goodness of open source, there are old drivers that
| are not maintained anymore and that can't run on newer
| versions of Windows, where hardware that is not maintained
| anymore by the manufacturer still works on Linux because the
| open source driver can still be adapted to run on newer
| versions.
| pjmlp wrote:
| Pity it doesn't apply to all cards supported by AMD open
| source drivers.
| scaladev wrote:
| Maybe it's not a problem for you if you upgrade your hardware
| frequently (and don't care that it stops working on newer
| versions of Windows because the vendor couldn't give a shit
| about keeping the driver up to date), and buy exclusively
| high quality (and high price) parts. I had enough fun with
| Realtek / GPU drivers (from all three major vendors) on
| Windows to hate the very concept of a proprietary driver to
| the end of my life.
|
| The very same hardware somehow works perfectly fine on Linux.
| No kernel panics (not a single one in 12+ years of running it
| on Realtek crap), no intermittent connectivity problems, no
| weird GPU bugs, nothing of the sort.
| pjmlp wrote:
| My netbook still has working drivers for Windows 10 with
| DX11 and GL 4.1 support, whereas the super cool open source
| AMD driver doesn't offer anything better than GL 3.3 with
| hardware video decoding that kind of works on full moons.
| diegocg wrote:
| I have working hardware that is no longer usable under
| Windows because drivers no longer work. Hardware companies
| have no interest supporting old hardware and they drop
| support in a few years. I recently got a new computer at work
| with a part that it's already considered "legacy" in the
| vendor's web site.
|
| Closed source drivers are a nightmare for users.
| d1zzy wrote:
| Hmm, makes me wonder if it's feasible (for really popular
| hardware where there is sufficient interest) to just port
| the open source Linux drivers over to Windows kernel and
| release it under GPL. Maybe even charge some money for the
| effort/to be able to download the installation kit (as I
| think there may be costs involved in getting access to the
| Windows kernel driver development kit that would allow to
| build the driver).
| dleslie wrote:
| > It's not a problem in the Windows world that drivers are
| not open source.
|
| It absolutely is a problem. There is plenty of not-that-old
| hardware that will only work on previous versions of windows.
|
| There's also _mountains_ of _terrible_ binary drivers that
| cause serious stability concerns.
| adambyrtek wrote:
| Broken binary drivers was also one of the main causes of
| the "blue screen of death" which gave certain versions of
| Windows such a bad reputation.
| marcodiego wrote:
| It is a problem on windows too. I've seem various devices
| that simply stopped working when you updated from win9x to
| XP, from XP to 7 from 7 to ...
|
| Proprietary drivers are a problem wherever they exist.
| d1zzy wrote:
| Spoken as someone that is not struggling to run older
| hardware on modern Windows. Windows 10 likes to screw up my
| audio (Creative X-Fi Titanium) every major update. No
| problems on Linux with updating the kernel almost every week
| for many years now.
| spijdar wrote:
| We're already there, anyway. Proprietary drivers are super
| common not just in Android, but across embedded devices
| everywhere.
|
| Some companies just flagrantly violate the GPL, and little ever
| comes of it.
|
| Others ship minimal shims in the kernel, and put the
| proprietary bits in userland code or some such. This seems to
| be more common, where vendors will _technically_ release their
| kernel fork, but the code will be obfuscated or just generally
| useless without the proprietary blob that goes with it.
|
| I'd much rather the kernel just have a stable ABI so these
| kernels could at least be freely updated instead of being stuck
| with the hacked together fork with its proprietary shims.
| solidangle wrote:
| > As we expand the universe of software we wish to run on
| Fuchsia, we are encountering software that we wish to run on
| Fuchsia that we do not have the ability to recompile. For
| example, Android applications contain native code modules that
| have been compiled for Linux. In order to run this software on
| Fuchsia, we need to be able to run binaries without modifying
| them.
|
| This seems to be new (circumstantial) evidence that Fuchsia is
| supposed to eventually replace Linux in Android.
| rvz wrote:
| Well it's what has been always said about those who wanted to
| replace Windows: A Windows replacement _must_ be able to either
| run Windows applications / games (Like running WINE on Linux)
| or have the same officially supported native version of this
| application / game. (mostly like macOS)
|
| What we can clearly see here is that an Android replacement
| _must_ be able to either run Android apps / games or have the
| same officially supported version of this said app / game,
| (Like Adobe Photoshop Express or Pokemon GO for iOS or Android
| or 'New Platform')
|
| The first route is the quickest for them to support the
| existing Android app ecosystem from day 1 or the alternative is
| to rewrite these apps for this new OS platform which takes
| years. The former route was the obvious choice for them.
| rblatz wrote:
| Wasn't the ability to run Windows apps one of the reasons
| OS/2 failed? If you had to support both you just wrote a
| windows app.
| Sophistifunk wrote:
| It's necessary, but not sufficient. You still need a reason
| for users to switch to your platform, but you remove a big
| reason not to.
| benley wrote:
| Sure, but I think a more apt comparison in this context
| would be to Windows NT, given that Android and Fuchsia are
| both made by the same company: the ability to run win16
| apps was crucial to its initial success. If every existing
| Windows 3.1 app had to be rewritten and rebuilt to work on
| NT at all, it would have been a much more difficult
| migration.
| diggernet wrote:
| I've seen exactly that argument used for why Purism and
| Pine phones should not be able to run Android apps. But I'm
| sorry, as much as I would like to migrate to one of those,
| it's simply not going to happen if it means ending up with
| a phone that cannot run various important apps.
|
| Yes, supporting apps for a competing platform gives some
| developers a convenient excuse to not develop for your
| platform specifically. But you still get the benefit of
| their work for the other platform. And not supporting those
| apps gives users a solid reason to not use your platform at
| all.
| Wowfunhappy wrote:
| Wouldn't the increasing dominance of mobile platforms and
| prevalence of macOS be a counterexample to theory?
|
| It depends on how you define "replace", I suppose, but
| Windows really seems to have less and less importance in a
| lot of spaces.
| oldgradstudent wrote:
| > A Windows replacement must be able to either run Windows
| applications / games
|
| This was true even for Microsoft.
|
| Windows NT/2000/XP was effectively a new operating system
| that was able to run Windows applications.
|
| Microsoft worked very hard to reproduce old bugs and
| undefined behaviors so that old binaries will continue
| working on the new Windows.
| jayd16 wrote:
| Could also simply be for bootstrapping or even for ChromeOS
| which currently supports Linux and Android apps.
| marcodiego wrote:
| Every time I hear "something something run unmodified linux
| programs something something" I get an ambiguous feeling. Part of
| me fears a EEE and part of me hopes that people will simply just
| target linux.
| coldtea wrote:
| I get the opposite fear. That people will simply just target
| linux, and we'll have another millenium of UNIX+POSIX
| monoculture imposed with no room for alternative designs...
| h_anna_h wrote:
| Given that there are stadia games that do not run on linux I
| would not be too hopeful.
| tyingq wrote:
| Seems like the proposal itself would be better to link to:
| https://fuchsia.googlesource.com/fuchsia/+/2940d6f300031e852...
| hencq wrote:
| Very interesting. So it's very similar to WSL on Windows (not
| WSL2), where it translates Linux syscalls into the appropriate
| Zircon ones.
|
| From the proposal:
|
| > An important cautionary lesson we should draw from WSL1 is
| that the performance of starnix will hinge on the performance
| of the underlying system services that starnix exposes to the
| client program. For example, we will need to provide a file
| system implementation with comparable performance to ext4 if we
| want Linux software to perform well on Fuchsia.
| d1zzy wrote:
| BTW you can get a Linux syscalls interception/translation on
| Linux too with something like gVisor.
| chasil wrote:
| Windows NT was also originally implemented with translation
| layers for OS/2 and POSIX.
|
| The WSL is a revival of the POSIX layer.
|
| "Broad software compatibility was initially achieved with
| support for several API "personalities", including Windows
| API, POSIX, and OS/2 APIs - the latter two were phased out
| starting with Windows XP."
|
| https://en.wikipedia.org/wiki/Windows_NT
| skissane wrote:
| > The WSL is a revival of the POSIX layer.
|
| Even WSL1 is technically very different from the old POSIX
| layer. The old POSIX layer used classic NT processes and
| POSIX APIs were routed in user space to NT syscalls via
| ntdll. WSL1 uses lightweight picoprocesses and implements
| the Linux syscall API in-kernel, rather than doing POSIX
| API to NT syscall mapping in user-space. Windows NT POSIX
| (and Interix/SFU/SUA) are conceptually much closer to
| Cygwin than to WSL1.
| zamalek wrote:
| These userspace runners seem pretty revolutionary, especially
| their ability to catch syscalls. As I understand it, this is
| what WINE is trying to add to Linux (so that they can correctly
| emulate Windows calls for some DRM/anti-cheat).
|
| This is very, very, cool stuff. It positions Fuschia as
| approximate to a lingua franca OS.
| tlamponi wrote:
| They already merged that in Linux, available in upcoming 5.11
| Kernel release.
|
| https://www.kernel.org/doc/html/latest/admin-
| guide/syscall-u...
| lima wrote:
| Nice. Does anyone know how this differs from using KVM for
| this like gVisor does?
| zamalek wrote:
| So far as WINE is concerned:
|
| At the end of the day, x86 is x86. Different operating
| systems use different loaders/dynamic linkers, different
| filesystem layouts, different APIs, but still the same
| machine code and still the same calling conventions.
| WINE, in a nutshell, merely presents the Windows
| environment (by wrapping Linux calls in Windows calls) to
| an executable that is running otherwise natively, there
| isn't a virtual machine or an emulator involved. There is
| no sandbox or security (as that is a non-goal).
|
| The problem is that various DRM and anti-cheat products
| use undocumented Windows syscalls to do their job, and
| syscalls are something that you can't just wrap with a
| function. This extension will allow WINE to ask Linux to
| send it unhandled syscalls (via SIGSYS), so that it can
| emulate them (making it a misnomer for the first time).
| monocasa wrote:
| > but still the same machine code and still the same
| calling conventions.
|
| The Linux and Windows calling conventions are pretty
| different.
| zamalek wrote:
| Oof, you're right. Still, it's merely a transition from
| one convention to another.
| pyb wrote:
| It's an old technique. Similar runners exist for Solaris and
| Minix
| ampdepolymerase wrote:
| Windows NT?
| zamalek wrote:
| Unfortunately you can no longer create syscalls in NT
| subsystems (XP was the last time that was possible). I
| assume you have to be Microsoft, or a specially privileged
| partner with source access, in order to do that.
| gorbypark wrote:
| At one point Fuchsia was using parts of gVisor, which is a
| userland linux kernel implemented in Go (to secure containers) as
| part of their network stack. Does anyone know if gVisor is being
| used for this as well?
| oscargrouch wrote:
| The idea is t run a binary in userspace called 'starnix' that
| will work as a glue between the linux syscalls and the fuchsia
| kernel.
|
| This is possible given they designed it in a micro-kernel like
| fashion, where things are more modular and a lot more can be
| done straight from the userspace without going for the
| expensive 0 ring barrier.
|
| From the docs:
|
| > Rather than running Linux binaries in a virtual machine,
| `starnix` creates a _Linux runtime_ natively in Fuchsia.
| Specifically, Linux program can be wrapped with a _component
| manifest_ that identifies `starnix` as the _runner_ for that
| component. Rather than using the _ELF Runner_ directly, the
| binary for the Linux program is given to `starnix` to run.
|
| > In order to execute a given Linux binary, `starnix` manually
| creates a `zx::process` with an initial memory layout that
| matches the Linux ABI. For example, `starnix` populates `argv`
| and `environ` for the program as data on the stack of the
| initial thread (along with the `aux` vector) rather than as a
| message on the bootstrap channel, as this data is populated in
| the Fuchsia System ABI.
| saagarjha wrote:
| I wonder if this is here for Android compatibility. A Linux ABI,
| a JVM, and some magic and you've got the entire Android ecosystem
| running on Fuchsia.
| bestorworse wrote:
| IMHO this is the main objective. They even mention in the RFC
| the case of running Android native code.
| neophyt3 wrote:
| JVM? I suppose android apps dont run on jvm, it has dex/art vm,
| isnt' it?
___________________________________________________________________
(page generated 2021-02-11 23:01 UTC)