[HN Gopher] A Kernel Hacker Meets Fuchsia OS
___________________________________________________________________
A Kernel Hacker Meets Fuchsia OS
Author : chrisdinn
Score : 254 points
Date : 2022-05-24 21:39 UTC (1 days ago)
(HTM) web link (a13xp0p0v.github.io)
(TXT) w3m dump (a13xp0p0v.github.io)
| vander_elst wrote:
| Disclaimer: I made some contributions to Fuchsia and I am clearly
| biased.
|
| I am not sure why there's so much negativity around Fuchsia. From
| a technical point of view it's finally a serious attempt to do
| something new in the OS space. It might not be the right and
| perfect answer, but it might introduce new paradigms and maybe
| some fork of the project might be able to provide additional
| benefits for end users down the road. I know that there are lots
| of hobby/research projects trying out new stuff, but i think
| Fuchsia stands out because it might be able to land the
| innovation and make it accessible for a larger user base.
| [deleted]
| josephcsible wrote:
| > I am not sure why there's so much negativity around Fuchsia.
|
| Because the real reason for its existence seems to be to slowly
| kill open source, by not requiring hardware vendors to provide
| kernel/driver source anymore.
| IshKebab wrote:
| Nonsense. Linux already doesn't require hardware vendors to
| provide driver sources. Fuchsia just makes it easier to
| upgrade things when they don't.
| josephcsible wrote:
| > Linux already doesn't require hardware vendors to provide
| driver sources.
|
| Yes it does. The GPL literally does exactly that.
| pjmlp wrote:
| It is sooo successful on the Android, IoT ecosystems.
| josephcsible wrote:
| So just because some people have broken rules and gotten
| away with it so far, we should get rid of those rules for
| everyone?
| cogman10 wrote:
| Nobody has broken rules. The rules are simply permissive
| enough that you can still push out a Non-GPL drivers for
| a GPL mono-kernel.
|
| The Fuchsia design is good because it recognizes that
| reality and creates a world where patching the kernel
| doesn't require hardware vendors to rebuild their
| drivers.
| pjmlp wrote:
| Rules that can be broken in the open without consequences
| aren't rules.
|
| In any case, the transition to MIT based FOSS on embedded
| platforms like Zephyr, RTOS, NutX,... proves that it
| won't matter for much longer anyway.
| rvz wrote:
| > I am not sure why there's so much negativity around Fuchsia.
|
| Change is quite scary for some judging from the responses and
| there is finally a serious new OS that abandons the legacy Unix
| model and gives a refreshing approach to doing something new
| with support for only modern architectures.
|
| To see it already running Chrome, Flutter, and being deployed
| on a Nest Hub without the users noticing tells me it is likely
| going to be the base of ChromeOS first and then it will replace
| Android in a couple of years with all Flutter and Android apps
| all running on Day 1 on the first phone running Fuchsia.
|
| Won't be surprised to see Fuchsia on Chromebooks.
| kardianos wrote:
| I love so many ideas Fuchsia brings in. Blob storage as a
| primary FS type, software integrity, software archives that can
| naturally just pull blobs it requires from archives to name a
| few. A system that can as a first class, be atomically updated.
|
| I'm concerned that it may not get real use or that Google might
| poison the well it dug.
|
| But I would love to see it become a minimum viable
| desktop/embedded platform. But looking at CLs, sometimes the
| enemy of better/good is perfect.
| ncmncm wrote:
| If it were not such bad code, it would seem more valuable.
| michaelbrave wrote:
| I just don't trust google to not abandon it like it has most
| other things they made that I invested in. It's brand erosion
| same as what's happened with Blizzard, used to have a lot of
| trust, lots of disappointments later and now I go in skeptical.
|
| Personally I think Fuchsia is cool, and there is a lot to like,
| but I expect to hear it was killed by google anyday now.
| tomComb wrote:
| Yes, it may well be killed, but that's Ok - it's an
| experiment. But, yes, you need to take that into account
| before investing time in it. The other mistake that I think
| people make is assuming that because Google is a giant Corp.
| these things will move quickly, when in fact Google often
| puts small teams on non-critical projects.
| cogman10 wrote:
| 6 years of development and deployed to actual products is
| an experiment?
|
| The issue I have with Google is it's never clear to
| outsiders when projects are simply "experiments" that
| google is going to kill later. Dart, GWT, Angular Dart, for
| example, seemed like more than "experiments" yet google did
| a soft kill on Dart and effectively a hard kill on GWT.
|
| You learn that something is "an experiment" when all the
| sudden updates slow or stop and the mailing list stops
| getting responses.
|
| I don't trust google software because google bureaucracy is
| fickle and unpredictable.
| qubex wrote:
| This may show my age, but Fuchsia smells like BeOS meets
| OS/400.
|
| As to why there's so much negativity: no clue. I quite
| appreciate the idea of a blank slate devoid of cruft.
| hosteur wrote:
| > I am not sure why there's so much negativity around Fuchsia.
|
| Easy: this is not the future we want. We don't trust google. We
| don't want an OS designed to further their goal of total
| control and surveillance capitalism.
| daptaq wrote:
| > We don't want an OS designed to further their goal of total
| control and surveillance capitalism.
|
| What parts of the operating system design do this?
| josephcsible wrote:
| The license, by allowing proprietary forks.
| qubex wrote:
| It's hilarious. I've been around long enough to remember
| people not trusting IBM and heralding Microsoft as the
| underdog with bright principles. Then it became Google being
| the white prince on a unicorn telling Micro$oft to eff off.
| For about a decade now we're collectively in Not Trusting
| Google mode.
|
| "It's all just a little bit of history repeatin'."
| vander_elst wrote:
| But given that's open source shouldn't it be a bit better?
| If I don't agree with some parts of the OS I can fork the
| project and remove some stuff. Given that's open source you
| don't have to fully trust Google, you can check things
| yourself. I know I'm probably bring native, but I am hoping
| to see some changes in the space.
| bobthecowboy wrote:
| MIT means it's only open source for as long as Google
| feels like it should be (and only the parts they want to
| keep open). Older versions will still be around to fork
| from, but maintaining a fork of an OS is a pretty large
| task.
|
| Android is also open source, and is notably very
| difficult to simply fork and do your own thing _and then
| actually use the thing_ , unless you happen to be a
| handset maker.
|
| My OS entirely driven by Google? No thanks, they're
| making enough of a mess of the web (and Android lately,
| TBF).
| [deleted]
| Ruq wrote:
| It sounds like a _really_ bad idea to have all software
| "components" be resolved, downloaded, and executed from over the
| internet. Seems like a supply chain/waterhole attack just waiting
| to happen.
|
| Not to mention it would seem to sign away the devices ability to
| act autonomously or offline. Of course, with my views of Google,
| it seems very like them to design everything to constantly rely
| on them to even function.
|
| Correct me if I'm wrong on any of this.
| katbyte wrote:
| I would tend to agree, unless pinning is enforced/the default.
| turminal wrote:
| I think the idea is "ensuring software is always up to date",
| so no pinning by default.
| dhodell wrote:
| These things work in tandem: the base system is pinned, but
| can also be easily updated with an OTA. Packages existing
| outside that set are resolved on-demand, and are thus
| updated when components in a package are run after a new
| version is published to the package repository.
| metadat wrote:
| Until they drop support for your hardware... Then what
| happens?
| ketralnis wrote:
| You have to chuck it in the bin and buy a new one,
| obviously. That's the state of the startphone world
| today, if you want to keep up on security updates
| myko wrote:
| This is lamentable and I'd love to see longer periods of
| support for older devices, but I'm not sure what the
| ideal state is - beyond being able to install your own OS
| on your device, which will still require some level of
| support from someone.
|
| What's reasonable - 5 years of support? 10?
| fartcannon wrote:
| They're claiming its about trusting the code you run. Google,
| you're the source of the code I don't trust.
| londons_explore wrote:
| I like the idea of it being _possible_. Just because it 's a
| feature doesn't mean you have to use it.
|
| For one thing, I assume such a system would have the ability to
| pin certain versions/hashes. If I (the user) can pin a set of
| hashes that are allowed to run, then I don't care where the
| actual resources are downloaded from.
|
| Alternatively, if I can give a certificate I trust of someone
| else to give a 'realtime' list, that would also satisfy my
| needs.
| wittrock wrote:
| Hi there, I work on Fuchsia, specifically on our Software
| Delivery system [1].
|
| You hit on exactly the right point: it's _possible_ to
| download and run software on demand, but it's also possible
| (and recommended) for products to turn off that capability if
| it's not useful or valuable for their use case. We pin
| packages for the base system itself, as well as lots of
| configurations of products.
|
| The ability to run code on demand is really valuable for our
| development flows and quick prototyping: built a new test or
| experiment? No need to update your device, just try to run
| it, and it runs!
|
| [1]: https://fuchsia.dev/fuchsia-src/get-
| started/learn/intro/pack...
| erickt wrote:
| I also work on Fuchsia's Software delivery team.
|
| For some more detail on how we secure downloading
| components, we implement a concept called verified
| execution [1]. We establish a chain of trust from:
|
| * a hardware key (on hardware that supports it), which
| checks the signature of
|
| * the bootloader, which has a key baked into it and
| verifies that each boot slot has a properly signed vbmeta
| structure. This vbmeta then contains a hash of the zircon
| kernel, and the merkle root for the user space system image
| blob.
|
| * we boot up zircon, which eventually starts up blobfs, our
| content addressed file system. It then reads the system
| image from blobfs, and launches Component Manager and
| Package Cache (which implements a package filesystem on top
| of blobs).
|
| * package cache gets launched with the system image merkle
| from vbmeta, which allows us to know which packages are
| part of the base package set.
|
| * base packages are then launched upon demand.
|
| This establishes a direct line of trust from the hardware
| key to the base packages.
|
| For over the air updates and ephemerally resolved packages,
| we use The Update Framework [2] and Omaha [3] for our
| package repositories. Each entry contains the merkle root
| for the package metadata, which in turn bakes in the merkle
| roots for each blob in the packages. We bake in the public
| keys for TUF and Omaha into our system image. This allows
| us to indirectly verify from hardware up that we are
| fetching the correct software.
|
| [1]: https://fuchsia.dev/fuchsia-
| src/concepts/security/verified_e...
|
| [2]: https://theupdateframework.io/
|
| [3]: https://chromium.googlesource.com/chromium/src.git/+/m
| aster/...
| cptskippy wrote:
| This sounds like exactly the kind of enterprise OS running on
| Servers that Google wants for itself. Not something for
| consumer devices.
| guyzero wrote:
| You'll be surprised of the first commercial deployment of
| Fuchsia then:
| https://www.theverge.com/2021/8/18/22630245/google-
| fuchsia-o...
| cptskippy wrote:
| I guess that makes sense. Those screens are black boxes as
| far as the user is concerned and highly dependent on the
| cloud to even function.
|
| I guess I was thinking more Laptops and Phones.
| [deleted]
| azalemeth wrote:
| Fuchsia still makes me deeply nervous inside. I get that linux
| has plenty of problems, but it really feels like Google have
| started to write an OS for the purposes of (a) having better
| remote control over the software that users run, and (b) being
| able to be free of the GPL. Security is the panacea that lets
| this happen, but I'm really not sure that it will inherently be
| better: iOS has effectively this model and it hasn't stopped a
| large number of nation-state actors effectively abusing it for
| hiding rootkits on victim's phones. The trade off for this is
| flexibility: the only reason I use an Android phone is because I
| can, with the right 3rd party OS, actually have a linux-based
| pocket computer that trusts _me_ rather than its vendor.
| [deleted]
| staticassertion wrote:
| People say this about a lot of security things. Ultimately, a
| lot of security is about constraining systems, and that makes
| people nervous. When I got my first Android phone I could root
| it pretty trivially and run a fully customized ROM, these days
| it's not really practical on many devices.
|
| And for the same exact reason that I have less control over my
| phone, I also trust it radically more for my current threat
| model.
|
| iOS is maybe a counter-example. It relies a _lot_ more on the
| walled garden, which helps a ton with malware, but not as much
| with "legit app got owned".
|
| It's worth noting that you explicitly believe Android to be
| "free-er", even though I would say the average Android device
| is _safer_. The two things aren 't always at odds, and with
| Android it's also very device specific.
|
| Another good example is HSMs and TPMs. Many people fear that
| these devices are inherently untrustworthy, but they also drive
| a lot of important modern OS security.
|
| My position here is that Linux is something of a disaster with
| regards to security and it truly _can not_ get better for a
| number of pretty fundamental reasons. If I had Google money I
| 'd absolutely be investing in ways of removing Linux from my
| security boundaries - something they've already done to some
| extent with gvisor.
| josephcsible wrote:
| What do TPMs do that's actually important?
| turminal wrote:
| > People say this about a lot of security things
|
| Unfortunately those people are often correct.
| DashAnimal wrote:
| Please I beg you - don't let HN become another online
| discussion site. Aim for quality, give examples, don't just
| rely on vague comments that are meant to provoke emotion
| and nothing else.
| staticassertion wrote:
| After that first ~dozen words I gave an example, a counter
| example, and discussed why this is a somewhat fundamental
| issue.
| badRNG wrote:
| >When I got my first Android phone I could root it pretty
| trivially and run a fully customized ROM, these days it's not
| really practical on many devices.
|
| Some of the easiest phones to do this to today, namely the
| Pixel phones, are also some of the most secure stock Android
| phones on the market. Freedom and security are not mutually
| exclusive.
| dang wrote:
| Url changed from https://swarm.ptsecurity.com/a-kernel-hacker-
| meets-fuchsia-o..., which points to this.
| maverick74 wrote:
| Would be nice to see something like this on seL4 (in some OS like
| Sculpt, for example)
| qayxc wrote:
| That would be too hard, it's a kernel that's actually developed
| with security in mind and is subject to active research (e.g.
| by DARPA).
| kramerger wrote:
| If you try using sel4 in a project, you soon realise it is
| extremely limited and not at all useful for general purpose
| computers
| maverick74 wrote:
| And yet it works on Genode/Sculpt! :)
|
| (yes... it's also a very limited OS... maybe someday it
| gets a decent GUI and starts to get more attention)
| sydthrowaway wrote:
| In what way?
| exikyut wrote:
| Hmm. By _not_ providing a POSIX lemonade stand, would-be
| users are required to basically figure everything out for
| themselves; I wonder what the net impact of that is.
|
| On the one hand POSIX et al is effectively impossible to
| deploy in a secure way, so there is a reasonable argument
| for going back to the drawing board; but on the other hand
| there isn't really a well-defined go-to alternative How To
| Computer model that is friendly to provable security, so
| everyone has gets to reinvent that wheel every time
|
| Considering the contemporary status quo in terms of
| independently-implemented OS projects and platforms (eg, my
| ever-so-slightly-wobbly VxWorks-based TP-LINK consumer ADSL
| modem), I do wonder how good seL4 implementations end up
| working out in practice - the kernel might be rock solid,
| but what about all the bits on top of it, some of which
| presumably communicate with the outside world, consume
| various protocols, need to control the hardware in various
| ways (which includes relying upon reading the hardware
| state/status), etc?
| bitwize wrote:
| The great thing about Fuchsia is it's like a Google version of
| Plan 9.
|
| The bad thing about Fuchsia is it's like a _Google_ version of
| Plan 9.
| [deleted]
| dhodell wrote:
| Ironically, several folks who worked on Plan 9 later worked (or
| continue to work) at Google, although none of them worked on
| Fuchsia.
|
| <ramble> To me the major overlap between them is their designs
| are clearly informed by the contemporaneous shape of network
| architectures. Fuchsia is a take on what an OS design would be
| as a set of named microservices that can be routed. Plan 9
| noticed network topologies of compute labs and clusters weren't
| too different, and both graphs could be represented in
| filesystems. The major visible difference to me is that the
| visibility of routing is much more apparent in Plan 9 than it
| is in Fuchsia. It's still a little difficult to understand how
| and where capabilities propagate through the system.
|
| Implementation-wise, FIDL is a much different take than 9P2K.
| Though much simpler, 9P2K forces every API to exist via a
| filesystem interface (many of the higher level protocols also
| involve quite a lot of string passing) and struggles with
| throughput of streaming operations. Individual FIDL APIs might
| have similar problems, but the message encoding itself is
| relatively more efficient. </ramble>
| kramerger wrote:
| The bad thing about Fuchsiais that it's a Google product.
|
| They may decide to kill it next week and switch to XNU or
| symbian or templeos and no one would be surprised.
| ryandvm wrote:
| Google's proclivity for aggressively wiping the spaghetti off
| the wall is starting to work against it. I think maybe they
| need to start promising to open source any products they lose
| interest in.
| layer8 wrote:
| That's fine as long as it's open source and a self-contained
| local piece of software (as Fuchsia is). The problem with
| Google killing products is that they're closed source and/or
| require huge server resources and/or ML models.
| e3bc54b2 wrote:
| From what I've read Fuschia is not at all self-contained.
| The UI is fully driven by and targeted towards Google the
| search and ecosystem.
|
| But those write-ups were years ago and there hasn't been
| new reviews with much UI focus since then.
| surajrmal wrote:
| Operating Systems are not a very well defined subject.
| Linux doesn't include a UI layer for instance and that
| isn't considered a problem. Being tied to a particular
| experience limits the potential applications of the OS,
| so in many ways I would consider the lack of opinionated
| experience a good thing.
|
| There is now a UI experience available as part of Fuchsia
| in the workstation product, but I wouldn't overly index
| on it as it's just one take on what you could use Fuchsia
| to build.
| layer8 wrote:
| You're probably right, though for an OS that's the kind
| of dependency people would prefer to have removed anyway.
| jcranmer wrote:
| Something that I haven't seen brought up yet is the "weird C++
| vtable layout." This is actually the "relative vtable layout"
| that's first described here:
| https://bugs.llvm.org/show_bug.cgi?id=26723, and is usable in
| clang via the -fexperimental-relative-c++-abi-vtables option.
|
| The basic idea is that you don't need to waste a whole 64 bits
| for vtable entry, especially since you can usually assume that
| code within the same DSO will be within 32 bits of each other.
| So, instead, you do a 32-bit offset from a known address (the
| vtable's address) to get the function pointer, and in the rare
| case you need a cross-DSO entry, just emit a thunk for the symbol
| that's in the same DSO to get an address within 32 bits.
| ncmncm wrote:
| Space for vtables is almost always negligible, especially so on
| 64-bit targets. So the main effect of inflated vtables is cache
| footprint. But where that matters most, you probably shouldn't
| be doing virtual calls anyway.
|
| Compilers don't get to say what you compile. People care about
| the speed of bad code almost as much as good code, and
| sometimes more: what bad code wastes, the compiler might be
| able to give some of back.
|
| Code that has a preponderance of vtables is usually bad code
| written by Java transplants who haven't learned the right way
| to code C++. But that code has to run, too.
| pjmlp wrote:
| Before Java came into the world I remember Turbo Vision,
| Powerplant, CSet++, OWL, MFC, Motif++, VCL, Tools.h++,...
| dmitrygr wrote:
| The people who work on fuchsia are very good engineers - I've
| worked with many of them in person. But the project itself has
| always been a staff retention project. It only existed to keep
| said engineers from going to a competitor. I don't know how any
| understanding of fuchsia is possible without this crucial fact
| the_duke wrote:
| A company might persue projects for all kinds of reasons.
|
| As a research project to inform design design, as a long term
| bet and sure, for staff retention.
|
| You have more insight, but it's sort of hard for me to see even
| Google put that many millions into an OS and, more importantly,
| put it into production usage on actual hardware (Nest) if that
| were the case.
|
| One factor here is that Fuchsia is in direct competition with
| both Android and Chrome OS.
|
| Maligning it as just a staff retention project might serve
| those teams quite well... either as a coping mechanism or as a
| political tool to kill it off.
| tyingq wrote:
| Does that mean you don't believe it's going to replace
| Android/AOSP? It's in some Nest devices right now.
| summerlight wrote:
| Not sure if it's ever feasible to replace Android (it's going
| to take at least a decade even assuming that Google becomes
| serious) but I think ChromeOS seems a reasonable target. It's
| not going to be as spectacular as Android but a decently
| successful migration if done properly. At that moment, I
| guess people can make more serious investments into Fuchsia.
| carapace wrote:
| Plausible real-world applications make it more effective as a
| "staff retention project", eh?
| rvz wrote:
| I'm sure in the next 10 years it will replace both Android
| and ChromeOS. Starting with ChromeOS first, then Android
| itself.
|
| Otherwise, why is Fuchsia already running the Chrome web
| browser? [0]
|
| [0] https://9to5google.com/2022/03/04/full-google-chrome-
| browser...
| pjmlp wrote:
| Android is being ported into Fuchsia,
|
| https://android-review.googlesource.com/q/fuchsia
|
| What is more likely to happen is to replace Linux with the
| Fuchsia infrastructure.
| goodpoint wrote:
| Unlike Linux, Fuchsia is not under GPL. Another attempt at
| making Android less open.
| [deleted]
| forgotpwd16 wrote:
| >Unlike Linux, Fuchsia is not under GPL.
|
| It's under MIT (the kernel Zircon specifically since
| comparing with Linux). Whether a license allowing even more
| freedom is worse is arguable.
| goodpoint wrote:
| I know - it provides google the freedom to lock down the OS
| further and the freedom to implement proprietary drivers.
|
| Yay for arguable freedom.
| sydthrowaway wrote:
| This seems like sour grapes.
| baybal2 wrote:
| refulgentis wrote:
| So I have, this isn't true except in a facile way--"it felt to
| me like they would have left otherwise." It shipped, in an
| important way.
| ncmncm wrote:
| Wow, it is surprising how awful every last bit of Zircon code
| reproduced here is. I have to guess the rest is about as bad.
|
| This dreck would never pass code review at my shop.
| Jyaif wrote:
| I skimmed through the article and nothing stood out. Can you
| give an example of a piece of code you didn't like?
| ncmncm wrote:
| Every last bit of Zircon code he reproduced in the article
| was a woolly mess that the code's author (not the article's)
| should be ashamed of. That the author found it easy to code
| an exploit for a system he knew so little about shows that
| the code is not just woolly, but actually bad.
| goodpoint wrote:
| HN downvotes things based on the mood expressed rather than the
| technical content.
|
| It's becoming a kindergarten, really.
| SOLAR_FIELDS wrote:
| I didn't downvote but I think it's more because grandparent
| reads like a shallow offhand dismissal. Perhaps if GP
| provided examples of bad code and better ways to express them
| it would be a more productive comment.
| shkkmo wrote:
| I didn't see any actual technical content in that comment. I
| don't see any repliers commenting on tone but I do see a
| comment or remarking that they disagree with the technical
| assertion and asking for actual technical content to back it
| up.
|
| So I think your assumptions about the reasons for the down
| votes are inaccurate.
| ncmncm wrote:
| Downvote all you like, it is bad code all the same.
| PaulDavisThe1st wrote:
| If you said why, you'd be less likely to get downvoted. Hand-
| waving assertions of "that dreck" are not well judged.
| ncmncm wrote:
| Anybody who can look at the reproduced code and not recoil
| in disgust will be unlikely to understand a detailed
| criticism. Just read it!
| skavi wrote:
| I'd encourage you to have a go at explaining nonetheless.
| I'm sure there are at least a few critiques you have
| which many here would miss, even if they are competent.
| There's always value in code review, no?
| Teckla wrote:
| Speaking just for myself, after perusing Fuchsia source,
| the code seems eye-wateringly "clever," pretty much
| everywhere.
|
| I'm doubtful many people would be able to read it or
| contribute to it very effectively.
| binkHN wrote:
| Very nice right up on how unfinished and insecure Fuchsia is as a
| result of it being so unfinished.
| kernal wrote:
| >Very nice right up on how unfinished and insecure Fuchsia is
| as a result of it being so unfinished.
|
| Did you even read the write up? The only bug found was the
| ability to read the kernel log. Everything else was
| manufactured.
| binkHN wrote:
| You're kidding right? Did you miss the parts about KASLR
| being broken and syscalls with TODOs for missing validations?
| And the CVEs created in relation to these?
| kernal wrote:
| I saw one CVE (CVE-2022-0882) for the innocuous kernel log
| bug. How many CVE's did you see? As for the KASLR, this was
| a known issue to the Fuchsia devs.
|
| >This is a known-issue. KASLR support on the zircon kernel
| is just there so that it doesn't bit-rot. We are always
| picking up a static address instead of a dynamic one.
|
| >Once physboot rollout is complete, that should make it
| easier to support kaslr.
| staticassertion wrote:
| KASLR is a pretty meh mitigation. But yeah, "todo" around
| capability checking probably should have been a higher
| priority fix.
| Someone wrote:
| FTA: But to simplify my first security experiment with Fuchsia,
| I decided to disable SMAP and SMEP in the script starting QEMU
| and create the fake vtable in my exploit in the userspace
|
| I don't see them re-enabling it later, so yes, they found
| security problems, but they didn't show a complete attack,
| either.
| kerneis wrote:
| Also from the start they introduce a bug in the kernel (in
| the TimerDispatcher implementation), and this is the very bug
| they focus on and eventually write an exploit for.
|
| They explain why they do so, and the article is extremely
| valuable as a first step and tutorial to get started in
| Zircon kernel hacking. They also find some actual issues,
| including one CVE. But I disagree the article shows how
| "unsecure Fuchsia is as a result of being unfinished".
| raggi wrote:
| Was that your takeaway from reading it, or something else?
| binkHN wrote:
| My take away, but the author goes into a bit of detail on
| this.
| yellow_lead wrote:
| Unfinished might be a good excuse if it weren't running on Nest
| devices.
| tadfisher wrote:
| Nest devices don't run untrusted code. If you get code
| running on a Nest display, please let me know how, because
| I'd love to hack around on mine.
| mda wrote:
| "How insecure" a surprising conclusion based on a single
| exploit.
| 29athrowaway wrote:
| If you read the article it mentions that ASLR doesn't work,
| and it's treated as a "known bug".
| mda wrote:
| Do you assume I didn't read the article? Calling it
| insecure based on this is absurd.
| rvz wrote:
| Exactly I also find it slightly silly to immediately
| declare this 'insecure' in this case here.
|
| If it was directly end-to-end on say a Nest Hub running a
| release version of Fuchsia then that would be a more
| convincing here, as that would confirm that it can be
| deployed and the bug can be exploited in the wild and in
| production and not on a newly built developer version
| running in an emulator.
|
| The writeup of finding and exploiting this bug is
| impressive, but whether if you can use that exploit to
| _directly_ attack a production version of Fuchsia on a
| device like the Nest Hub is another thing, which is the
| same way security researchers do to break live versions
| of other OSes like macOS, Windows, Android and Linux.
| kerneis wrote:
| Kernel ASLR. User-space has ASLR enabled and working, in
| addition to shadow stacks and a number of other hardening
| techniques.
| binkHN wrote:
| The article also references syscalls that are marked with
| TODOs for validation of those calls.
| SpectralTheory wrote:
| Better than being insecure by design, I would think.
| ncmncm wrote:
| Insecure is insecure. Or did you mean unfixably insecure?
| coldtea wrote:
| Parent means infixably and/or intentionally insecure.
| goodpoint wrote:
| Unfinished does not justify unsecure!
|
| You start with something secure and rudimentary and add
| features over time.
|
| You don't start with something unsecure and then add security
| to it.
| ThePowerOfFuet wrote:
| The word you were looking for is _writeup_.
| ge96 wrote:
| It's weird in my later 20s I started doing this, writing
| homophones. I at least get my then/their/effect right still.
| 5e92cb50239222b wrote:
| I think this mostly happens to native English speakers for
| some unimaginable reason. I don't remember ever making this
| mistake (but do remember plenty others to make up for it),
| and can't imagine myself doing it. Yet it happens to native
| speakers all the time.
| arc-in-space wrote:
| I'm not native and I absolutely do this. 500 grams of
| flower...
| jsjohnst wrote:
| Funny, that fragment actually works as written in some
| contexts. :)
| exikyut wrote:
| Imagining that looks _very_ nice, TIL prettiness can be
| quantified /measured by weight :D
| MauranKilom wrote:
| > I don't remember ever making this mistake (but do
| remember plenty others to make up for it), and can't
| imagine myself doing it. Yet it happens to native
| speakers all the time.
|
| I used to think that, too. But now my fingers just type
| the words as I hear them spoken in my mind, and that
| seems to occasionally produce homophones.
|
| Kinda fascinating what this says about our language
| processing, to be honest!
| layer8 wrote:
| As a nonnative English speaker (actually mostly
| reader/writer/listener), I started doing that at some
| point (many years after English proficiency), to my own
| dismay.
| rosetremiere wrote:
| I would guess that the difference native/foreign is
| simply due to the way language is learned: for native
| speakers, it's first and mostly orally. This doesn't
| explain a later appearance of mistakes though...
| michaelmarkell wrote:
| I right a lot less now then I did as a kid, so maybe it's
| about just staying sharp
| [deleted]
| lelandfe wrote:
| You rays a good point!
| layer8 wrote:
| I believe "raze" would be the correct pronunciation. ;)
| Taywee wrote:
| Both are pronounced identically in American English at
| least.
| layer8 wrote:
| Huh, the IPA indeed seems to be the same, but I would
| argue that the "z" in "raze" is distinctly more voiced
| than the "s" in "rays".
| akavel wrote:
| Ah, this remains me of a classique in this field:
| https://youtu.be/OonDPGwAyfQ
| exikyut wrote:
| I was most disconcerted to find myself doing the same
| thing of late. It is _very_ curious; like my brain
| internally just couldn 't be bothered anymore to expend
| the energy to delineate _their_ and _there_ until I 'm in
| the process of actually typing. But that means the
| signalling fires a tad late, so I'm going back and fixing
| stuff.
| [deleted]
| dvh wrote:
| You see, this is how you do job interview, not waiting for some
| HR schmuck to ask you leetcode questions over the span of 6
| months.
| tech-historian wrote:
| Marketing yourself has always been, and will continue to be,
| valuable. This marketing can take many forms.
| [deleted]
| nine_k wrote:
| My takeaway from the article is that Fuchsia exposes a
| capability-based interface externally, but uses the old kind of
| privilege-checking inside the kernel. Once a single sloppy check
| was found, the game was over: a privilege escalation and planting
| of arbitrary code into the kernel followed.
|
| Did I miss anything?
| tyingq wrote:
| Not familiar with capability-based practices, but wouldn't
| there always be a _" if
| (has_this_capability(WHATEVER_CAPABILITY))"_ at the very
| bottom...one that could be sloppy? Doesn't something, somewhere
| do a comparison?
| nine_k wrote:
| Not necessarily.
|
| The core idea of capabilities is more like having a URL to a
| Web page. Using the URL (the capability), you can access the
| contents of the page. Inside the contents, you can possibly
| find other URLs (more privileges granted to you). But the URL
| happens to be something like an UUID, or a short link;
| looking at it, you cannot derive another URL (discover
| another "capability", not granted to you).
|
| In other words, a capability is like a key in a hash table,
| and unlike an index in an array.
| why_only_15 wrote:
| Interesting. Is this in practice implemented as just
| capabilities being large numbers so it's impractical to
| guess them, or does the kernel have a table with all of a
| process's capabilities and when a message is sent to a
| process with capabilities the kernel adds them to the
| table?
|
| That is -- are capabilities just pieces of data in a
| message you can detect and try to use, or do they have to
| be added explicitly to a message to send them
| formerly_proven wrote:
| You know a limited kind of capability - file descriptors
| (or kernel handles). Those are just a number that allow
| you to manipulate some object in a defined way. You can
| give this number to someone else, and they can't make use
| of it at all, you have to go ask the kernel (using e.g. a
| unix socket and ancillary messages) to pass the
| capability to another process.
| staticassertion wrote:
| That is sort of the opposite of a capability. In fact,
| files are capabilities exactly because you can hand off a
| file descriptor and, by virtue of that handle, you grant
| access.
|
| File systems _aren 't actually_ capability based
| (generally, in practice) because you can 'ls' and 'cd
| ../'. Otherwise they could be.
|
| Dropbox Paper is a good example of a capability based
| system. Anyone with a URL can perform actions on a page,
| but there is no way to _derive_ a URL without already
| having access to it, you must be told what it is. This is
| because the urls are sufficiently random so as to be
| unguessable.
| throwaway894345 wrote:
| Are capabilities rotated periodically? Or how do you deal
| with leaked values?
| Rusky wrote:
| It doesn't matter if the value is leaked, because it's
| meaningless to another process- like a file descriptor,
| it's just an entry in a table in the kernel, so it can
| only be used by the process it was granted to.
|
| (One process can request that the kernel transfer it to
| another process, which I guess you might be referring to?
| I'm not familiar with Fuchsia specifically here but
| generally speaking capability-based designs sometimes let
| you "revoke" a capability if that is something you need,
| though that's not really something you would need to do
| periodically.)
|
| The Dropbox approach is sort of a fuzzy emulation of
| this, by necessity, because it's a public internet
| service.
| staticassertion wrote:
| > It doesn't matter if the value is leaked, because it's
| meaningless to another process- like a file descriptor,
| it's just an entry in a table in the kernel, so it can
| only be used by the process it was granted to.
|
| No, this is incorrect. Let's just quote wikipedia,
|
| > A capability (known in some systems as a key) is a
| communicable, unforgeable token of authority.
|
| _communicable_. It is practically the whole point that
| you can say "hey, here's a capability I have, now you
| have it".
|
| Yes, it matters _deeply_ if a capability is leaked. To
| name something is to authorize something, in capabality
| land.
|
| No, you do not need to ask for it to be transferred. As
| with file descriptors in linux you can fork to delegate
| (or otherwise pass the handle around). Again, it is
| fundamental to capabilities _that the capability is the
| authorization_.
|
| Dropbox's approach is faithful. And, in order to deal
| with these limitations of capability systems, Paper
| supports ACLs _as well as_ capabilities. I think it 's
| going to be a huge problem if Fuschia doesn't, but I
| don't know what they do - certainly some sort of MAC is
| desirable.
| Rusky wrote:
| I think we're just talking past each other- by "leak" I
| was talking about something like accidentally sharing an
| fd number, not actually communicating the capability
| itself. This is how Dropbox's approach is a "fuzzy
| emulation"- you _can_ in principle forge a URL in a way
| that you could never forge a file handle.
|
| Obviously if you communicate the actual capability itself
| to someone you didn't intend to, that would be bad. But
| that's more of a question of API design- even fork is, in
| this sense, asking for the capability to be transferred.
| This is a very different problem than the one Dropbox
| has- no amount of random guessing, or side channel
| information leaks, or anything else like that, is going
| to land a capability in another process's kernel table.
| staticassertion wrote:
| Yes, accidentally sharing a capability is a leak. If I
| accidentally printed out a capability it would be
| 'leaked' and anyone who reads that capability now has
| obtained it an dcan use it.
|
| > you can in principle forge a URL in a way that you
| could never forge a file handle.
|
| Maybe it would be better to not talk about fs apis,
| because they're not really capability based, so I suspect
| that's the confusion.
|
| The point is that if someone has a capability, they _have
| that capability_. There is no additional access control
| or checking in a capability based system. You absolutely
| have to consider things like rotation and revocation.
| Rusky wrote:
| I'm specifically talking about Fuchsia and other kernel-
| based capabilities here. You fundamentally cannot print
| out that kind of capability in any way that matters- the
| only thing that determines whether a process has it is
| the table in the kernel, not whether it can produce a
| particular bit pattern.
|
| In this sense, fs APIs are a fine example, as long as you
| keep the ls/.. caveats in mind. If you have a file
| descriptor for something inaccessible through the global
| file system namespace, then the only way to grant that to
| another process is via specifically-designed APIs like
| domain sockets or fork.
|
| As I said in my first comment, there are of course other
| reasons you might want to revoke a capability. But unlike
| Dropbox URLs, true capabilities are unforgeable, so you
| don't need to rotate them out simply to make them harder
| to guess- they're already unguessable.
| staticassertion wrote:
| I think the short version is that you're just not talking
| about capabilities.
| Rusky wrote:
| How so? The line _you_ quoted from Wikipedia calls them
| unforgeable. If you can forge it (by printing it out and
| reading it back in from somewhere else, or by guessing a
| bit pattern) then surely it 's not a capability?
| throwaway894345 wrote:
| No, I just didn't realize that it wasn't useful to
| another process. I thought it was akin to a secret.
| staticassertion wrote:
| To be clear, the answer to your question is "yes, you
| need a way to revoke capabilities if you care about them
| leaking", and the user who responded to you is incorrect.
| staticassertion wrote:
| A leaked capability is indeed a critical failure. There
| are multiple ways to deal with that.
|
| 1. Revocation is pretty critical
|
| 2. Bounding of capabilities is great - "You have this
| right for N seconds", meaning that a leak is less
| devastating
|
| 3. _Not relying on capabilities_ is the best option.
| Capabilities are amazing, and a wonderful access control
| system. Their main benefit is that you can very naturally
| implement _extremely_ fine grained access control. The
| downside is that it becomes hard to reason about that
| access control statically. ACLs are bad at super fine
| grained access control, but they 're great for "I can
| look at a policy and know what this thing can/ can not
| do".
|
| Layering ACLs and capabilities is a match made in heaven.
| trasz wrote:
| >File systems aren't actually capability based
| (generally, in practice) because you can 'ls' and 'cd
| ../'. Otherwise they could be.
|
| That's precisely how it works in FreeBSD
| (https://www.freebsd.org/cgi/man.cgi?capsicum).
| staticassertion wrote:
| "generally, in practice"
|
| There's also openat on linux. My point is that the
| _general, practiced_ approach is not capability based.
| jamesr_ wrote:
| The kernel maintains a table of which handle values each
| process owns and uses that to check the capabilities of
| the calling process when handling a syscall. Sending a
| capability in a message updates this table as the
| ownership changes.
|
| We use (somewhat) large and non-dense numerical values
| for handle values to reduce the risk of accidental reuse
| of values.
| giyanani wrote:
| I'm not sure how fuschia does it, or how feature-based
| capabilities work, but Cheri[1] uses capabilities for
| memory management and isolation.
|
| It uses a couple of techniques, like wide/tagged
| pointers, object ids, and a special hardware managed bit
| to track illegal modifications.
|
| If I had to hazard a guess, those object ids are probably
| useful for general capability systems.
|
| I think apple (maybe as just an arm feature?) can do
| encrypted pointers, with a per application key tracked by
| the kernel.
|
| [1]
| https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
| zahllos wrote:
| > I think apple (maybe as just an arm feature?) can do
| encrypted pointers, with a per application key tracked by
| the kernel.
|
| ARM has added both pointer authentication codes and
| memory tagging extensions to their ISA, from (I think)
| ARMv8.5-A. Apple are the only ones to implement silicon
| that supports PAC that anyone can buy today but a) this
| will change fast and b) I might've missed something else.
|
| I wouldn't say "encrypt". You can still read what the
| pointer is, you just can't forge it. It is more like a
| message authentication code, or keyed hash. Confusingly,
| the ARM ISA suggests you use the block cipher QARMA, a
| lightweight block cipher of their design. This is not a
| mistake - from a crypto academic's perspective the
| distinction between block cipher and hash is not so easy
| to draw as it tends to be communicated: you can get a
| block cipher out of the SHA family of hash functions
| (called SHACAL) and so on. There was a line of work on
| finding a suitable family of permutations (e.g. Gimli)
| that could be hardware-accelerated and appropriate
| constructions built from that.
|
| tl;dr it is kinda a "signed pointer", and if you forge
| the pointer but get it wrong you don't get another chance
| because the CPU triggers a fault, so you can use lower
| security lightweight ciphers and still make exploitation
| very unreliable.
|
| Now Fuchsia:
|
| As to how Fuchsia does it, we can just look at the
| source:
|
| 1) https://fuchsia.googlesource.com/fuchsia/+/refs/heads/
| main/z... 2) https://fuchsia.googlesource.com/fuchsia/+/r
| efs/heads/main/z... 3) https://fuchsia.googlesource.com/f
| uchsia/+/refs/heads/main/z...
|
| For example. I don't think there's any magic here: the
| kernel maintains some structure to reference jobs, tasks
| or whatever we are calling our isolated privilege
| boundaries, in which the capabilities are described. On
| the face of it this "looks" a lot like the traditional
| permission-style system, but the key difference is that
| the root job will hand out capabilities to processes it
| has created. An example is probably the best way to
| proceed: on a linux system, you might decide your process
| needs to read `/system/sensitive_file`. To allow this to
| happen, you might grant access to the user using some
| other command: chown .../chmod ..., or you might set an
| selinux policy, semanage fcontext -a -t myprocess_t
| /system/sensitive_file. In a capability-based system,
| chmod/chown and even running the process as a user don't
| exist as concepts. You would need to use a process
| authorized to transfer a capability to your target
| process to access this file. In some ways, this is closer
| to selinux, in the sense that semanage fcontext updates
| policy, except that the policy is somewhat dynamic here:
| if your controlling process provides the capability, then
| the child process gets it.
|
| In a microkernel-based architecture, the idea is that
| "servers" (jobs that are arguably part of the system, but
| don't need to be in kernel) are similarly userspace
| processes subject to said capabilities also.
|
| Of course, some part of the code still needs to be
| privileged here, let's call it the "executive". This code
| is doing the capability enforcement, and if that code
| contains bugs, all bets are off, as always. You can't
| defend such code from itself, even with capabilities.
|
| The real disappointment is that Zircon is written in C++.
| Granted it was probably started before Rust was a thing,
| but while Ada/SPARK might be considered a bit
| unfashionable, it has some formal verification available,
| and if you're going for a software solution this should
| help reduce exploitable bugs. Personally I also wonder
| what about seL4 made it unsuitable for this: granted, it
| is not complete as a system, but neither is Zircon alone.
| pjmlp wrote:
| Apple isn't the only one, Oracle did it first with SPARC
| ADI on Solaris.
| zahllos wrote:
| True. I was mainly responding to the ARM encrypted
| pointers part with that bit. ARM also didn't invent
| memory tagging, which might also have come from SPARC ADI
| (I'm not sure), but they also plan to include that. QARMA
| itself looks to be designed by Qualcomm engineers:
| https://eprint.iacr.org/2016/444.pdf
|
| A lot of good stuff has come from SPARC :)
| throwawaymaths wrote:
| In theory you could do even better than that -- you could
| make capabilities cryptographically signed tokens, so
| that you don't need to ask the kernel to verify the
| validity of your request every time. If your chipset
| supports crypto intrinsics this will almost certainly be
| better than an interrupted syscall.
| jnwatson wrote:
| Not even theoretical. An early capability based OS called
| KeyKOS worked that way.
| staticassertion wrote:
| Yeah, reminds me of biscuits[0] - because they're based
| on asymmetric cryptography they can be delegated, but
| also attenuated. If you just use a uuid that's not really
| going to work as well, unless you're willing to go back
| to some authority to forge a new, lesser capability.
| jackdaniel wrote:
| It is more like:
|
| (caller_capabilities[WHATEVER_CAPABILITY])(...);
|
| when the capability is not present, then you get
| no_method_found or something similar.
| DannyBee wrote:
| Yes - you can't run untrusted native code in the first place
| outside of the emulator ;)
|
| That's why the bug says: "The overall impact of this bug is
| pretty minimal in our current set of supported products, since
| none support running untrusted native code, and if you can run
| your own code on the system, then (at present) you can also use
| other existing supported workflows to obtain kernel logs, but
| it does seem to be a useful stepping stone towards privilege
| escalation if you have already obtained code-exec in some
| process through another exploit."
|
| So while not awesome, also not possible on a real device right
| now without a code-exec exploit.
| londons_explore wrote:
| Don't forget that the use-after-free used was also artificial
| - ie. OP didn't discover one, he added a UAF bug to go
| exploit.
|
| The fact he got KASAN working and talks about fuzzing
| suggests he looked for one, but couldn't find one, which is a
| good sign.
| phlip9 wrote:
| From the article, it looks like the syzkaller fuzzer
| integration was stale and not working, so there might still
| be some juice to squeeze if someone can get that running
| again : )
| fay59 wrote:
| The intent of the post isn't to claim that any Fuschia device
| currently sold is vulnerable. Unless Fuschia never graduates
| to running third-party code, that seemed like the right
| assessment to me.
| DannyBee wrote:
| Sure - but he also added the vulnerability he exploited in
| the first place?
| fay59 wrote:
| That's not really a "but" to the comment, which was that
| you need to find one bug and it's game over. We've known
| for a long time that best practices aren't enough to
| prevent memory corruption in large enough C++ code bases,
| so it's likely a motivated attacker would eventually find
| something.
| DannyBee wrote:
| Sure - look i'm not gonna argue about C++ memory safety -
| i've funded and spent time trying to ensure we are
| funding figuring out how to get off of C++.
|
| I just assume C++ code is unsafe, because it's really
| really hard to make it safe.
|
| However, at the same time, the privilege escalation
| issues would have happened in any language - if you don't
| implement the check, you don't implement the check.
|
| (and you could make it equally automatic in most
| languages)
| fay59 wrote:
| What the missing access check protected was a stream of
| information that could defeat ASLR. If Zircon was written
| in a memory-safe language, that would have been the end
| of the issue. Logic bugs and missing access checks are
| still possible, but defeating them has fairly well
| definable consequences. Since Zircon isn't written in a
| memory-safe language, the author was able to use that to
| fully compromise the kernel instead. I don't mean that
| you can't write bugs in memory-safe languages, but in the
| end the attacker still has to play by your rules. With a
| memory safety bug, attackers play by no one's rules.
| ncmncm wrote:
| The code exploited was very, very far from any "best
| practice" in this decade, and probably the previous one.
| pjmlp wrote:
| Unfortunately still a common reality across many
| corporations.
| ouid wrote:
| The objective of computer security seems to have shifted from
| preventing someone else from running unauthoirzed software on
| your computer to preventing you from running unauthorized
| software on your computer. I would not describe this as security.
| fartcannon wrote:
| I think the fact that Apple is a multi trillion dollar company
| from using basically that move plus aggressive marketing itself
| as high value means I'd expect more to try it. Luckily Linux
| exists to prevent the complete Appleization of computing (even
| if we did already lose cell phones to greed).
| eklavya wrote:
| The computer doesn't know whether it's you or somebody
| pretending to be you. Unauthorised execution should be possible
| but should be off by default, that's 100% better for consumers.
|
| Sorry if I got your point wrong :)
| bregma wrote:
| We will do what we're told.
| zoul wrote:
| I would guess you have never worked as a technical suppport for
| your family's computers? Because even if I very much understand
| your point, not being able to run untrusted code absolutely is
| a security advancement in certain situations. It is SO
| refreshing and liberating to be able to say: Do whatever you
| want with it, it's very hard to damage on the software side.
| fartcannon wrote:
| Instead of ruining computing forever, you could just say no
| to your imaginary family of people incapable of learning.
| Boundaries!
| corrral wrote:
| You can really tell who lived through the era of 20
| stacked, all-unwanted browser "toolbars" and Bonzi Buddy
| and such, and who didn't.
|
| That didn't go away because people _learned_. And it never
| would have.
| fartcannon wrote:
| You want to limit what current and future generations of
| people can do with their computers because of something a
| computer illiterate grandma may have done in the 90s?
|
| No. Those people get newspapers and landlines.
| corrral wrote:
| You badly overestimate both the ability and interest of
| average people in learning to administrate their
| computers. They just want to get shit done and go do
| something else. Computers are a tool at best, and more
| often a super-annoying thing they have to deal with but
| hate every second of it.
|
| If they actually _like_ any of the computers around them,
| it 's probably the most locked-down ones: their phones
| and video game consoles.
|
| [EDIT] That is, you're way off in thinking it's only a
| bunch of soon-to-be-dead grandmas who have trouble
| operating computers that don't prevent them from fucking
| things up too badly. The "digital native" generations are
| barely better.
| fartcannon wrote:
| You can have a locked down mode. You can even sell it
| turned on by default. But to exclusively prevent everyone
| from using their computers as they see fit because you
| think some people are too stupid to handle it? I don't
| believe you actually want that. I believe that's an
| excuse to ensure Apple gets a cut of everything that
| happens on their soon to be landfill machines.
|
| If yes, man that's really dangerous thinking.
| corrral wrote:
| I have _almost_ zero interest in haxoring my phone, and
| just want it to always work and not let 3rd parties steal
| my info, automatically.
|
| And I'm a life-long computer geek who's done professional
| mobile development. Most people care even less than I do.
| They just want it to work, because computers aren't their
| life, they just use them to get stuff done, or when
| someone else tells them they have to. Would it be sort of
| nice to have the option to unlock it? Yes, _exclusively_
| so I could run pirated games in emulators more easily,
| which is the _only_ thing non-programmers I know with
| unlocked Android phones use all that freedom of theirs
| for. For most people, they 'd not pay even a couple
| dollars to have the unlock option. It's worth basically
| nothing to them, because _they do not have any actual use
| for it_. But sure, it 'd be nice. It's just not a big
| deal.
|
| > If yes, man that's really dangerous thinking.
|
| The NES had a DRM chip--a bad one, but still.
|
| Some computers have been appliances, and some have been
| programmers' machines, for a long time, and the sky
| hasn't fallen. The former have just eaten some of the use
| cases for the latter, where a fully-capable general-
| purpose computer was at least as much of a liability as a
| boon.
|
| Even Apple still makes normal-ass computers for people
| who need them. If your reaction to that statement is
| "pft, yeah, but they're clearly trying to get rid of
| those", well, people have been saying that for more than
| a decade, and it still hasn't happened and doesn't seem
| to be any closer, so... I'll believe it when I see it.
| fartcannon wrote:
| For one, being able to use your computer/phone like a
| computer isn't 'haxoring'. Jesus. And second, Apple _lets
| you_ now (mostly anyways), because people with sense
| still raise a stink. So, basically, you're welcome. Stop
| screwing it up for the rest of us.
| corrral wrote:
| What's getting screwed up? It's cheaper and easier than
| ever to acquire a wide-open computer platform. There are
| also more of them than ever. There's just also a couple
| new categories of computing appliance--which is _nowhere
| near_ being a new thing--that weren 't around before.
| josephcsible wrote:
| > There are also more of them than ever.
|
| This is super misleading. There's only slightly more
| wide-open platforms now than there ever were, but there's
| way, way more locked-down ones.
|
| > There's just also a couple new categories of computing
| appliance
|
| A couple?
| corrral wrote:
| > A couple?
|
| Yeah, I'm counting phones and tablets as two categories.
| But I'm also being really generous on how old something
| can be and still be "new" (15 years is quite a while, in
| tech) and not counting those as just an iteration
| (admittedly, a big one) on PalmOS devices and such.
| They're also much closer to being general-purpose devices
| than most other appliance-type machines (consoles,
| dedicated set-top boxes, et c.), occupying more of a
| middle ground between the two.
|
| I suppose you could add smart watches and make it three.
| Set-top boxes are at least 23 years old (TiVo), so
| stretch even generous definitions of "new", and we had
| closed-source non-user-modifiable DVD players well before
| that.
| fartcannon wrote:
| Phones and tablets are just locked down computers, not
| appliances. Do you want your laptop to be like that? Why
| not? Why is that any different than your tablet? Spoiler:
| It's not.
|
| Some people only have access to tablets and phones. Let
| them have the freedom we had to create something. With
| that freedom, maybe one of them grows up and creates the
| next Apple, only without the cruelty and greed.
|
| On top of that, it would reduce waste.
| corrral wrote:
| Again: it is cheaper and easier than ever to get a "real"
| computer. They're at thrift stores for like $50-100, with
| peripherals. Raspberry Pi alone has sold over thirty
| million units. If a bright kid with a good idea asked for
| one on HN I bet a dozen people would ship their extras to
| them _for free_. Computers are given away for free pretty
| regularly on Craigslist and Facebook and such. Old but
| functional laptops can be had for tens of dollars on
| Ebay. It is _wildly_ easier and cheaper to get into
| personal computing now than it was in the 80s, 90s, or
| even 00s. You can literally afford it by collecting loose
| change for a little while. A month of half-decent
| Internet service may well cost more than your entire
| computer set-up. This has been the _consistent_ trend and
| it shows no sign of reversing, even after 15 years of
| iPhoneOS /iOS.
|
| > the next Apple, only without the cruelty and greed.
|
| Sigh. Well, never mind, I'm out.
| [deleted]
| alexvoda wrote:
| Or you could just not give them admin rights and create
| limiter users for them. You do not have to surrender super-
| admin right to corporate overlords to solve this problem.
| jgerrish wrote:
| Ahh, the fix the "technical support" gambit. Good PR,
| connects with a sizable subset of the target.
|
| Susceptible to damage by inkjet cartridge DMCA attack.
|
| Replace by "email support", nobody likes spam, much harder to
| defend. They've been softening up people with the anti-social
| media work, so it's palatable.
|
| Good catch! I really am sorry if that's damaging or
| condescending, it's meant as a golden rule thing.
| pessimizer wrote:
| > Do whatever you want with it,
|
| That's the opposite of what is being said.
| Iolaum wrote:
| Agreed. However should Operating Systems for consumers only
| really cater to that use case? Because that is the problem
| IMO.
| fartcannon wrote:
| Yes, because the PR requires there be no ground given on
| this talking point.
| dekhn wrote:
| That's why I got my dad a chromebook. ChromeOS is a really
| well-engineered system- good enough that I never ever worried
| about security.
| goodpoint wrote:
| This is not what ouid wrote.
| ouid wrote:
| what kind of person who comments on hackernews doesnt do
| unpaid tech support for family members?
|
| yes, i do, and the thing that i mostly find is people paying
| for "legitimate products" that their computers can do for
| free with essentially no additional hassle. Apple and google
| arent in the business of protecting your naive family
| members, they are in the business of monopolizing the
| exploitation of your naive family members.
|
| Just yesterday i discovered that jpeg compression is broken
| in preview, and has been for years. The top result for what
| to do about it on the macos subreddit is to pay for image
| editing software.
|
| i suspect you of arguing in bad faith.
| grumbel wrote:
| That has nothing to do with untrusted code, but with how well
| programs are isolated from _each other_. You don 't have to
| restrict the user for that.
|
| Take the Web, we all run untrusted programs 24/7 there, every
| single snipped of Javascript is an untrusted program. Yet it
| neither does damage to our systems nor does it prevent the
| user from opening up the developer tools, hacking away on
| existing websites or making their own.
|
| The Web isn't perfect either, but it's worlds better than
| Android and Co.
| [deleted]
| goodpoint wrote:
| Just like DRM, TC and many more, it's about keeping vendors in
| power.
|
| The ones being sandboxed is the user.
| pjmlp wrote:
| It was always been like that in properly configured enterprise
| systems, that is why we used to connect to UNIX development
| servers, instead of having a worstation on each desk.
|
| And later moved into having workstation VMs accessed on the
| network as soon as PC virtualization catched with what
| mainframes have been doing for decades.
| skybrian wrote:
| We've learned that most software that we run on our computers
| shouldn't be completely trusted and most users can be tricked
| into running malicious software. Pretending that supply chain
| attacks don't exist isn't security either.
|
| The ability to sandbox software (with a lot of effort) means
| that you _can_ run software you don't trust. The web is built
| on this.
| [deleted]
| staticassertion wrote:
| How do you draw this conclusion from the article at all? In
| what way was this hacker 'restricted' ?
| salawat wrote:
| It absolutely is security. Job security. Enforced vendor
| dependence is all the rage.
|
| Try getting investor dosh without it. Not happening.
| [deleted]
| native_samples wrote:
| I think the more interesting thing here is the fact that so much
| code in their repository appears to be bit-rotted or half baked,
| despite being documented. KASLR is mentioned all over the place
| but doesn't work and the answer is "we know, it's there only to
| stop it bit-rotting". You need to patch the system to do kernel
| debugging because otherwise the toolchain hangs. Syscalls are
| documented as enforcing security rules yet the actual checks are
| //TODO comments (and they are still willing to assign CVEs so
| apparently they just forgot?!). The syzcaller tool is advertised
| as working with Fuschia, yet despite trying multiple different
| versions he can't even compile them due to API churn. Apparently
| downloading and executed a binary isn't even an option, despite
| their vision being that Fuschia is a sea of components downloaded
| and run from the internet.
|
| It's hard not to feel like maybe Google has lost the ability to
| develop operating systems. Fuschia has been in development for
| years now, it has no users outside of Google yet if you flick
| through their docs you'll notice a whole bunch of pages talking
| about deprecated components, migrations, etc. When I last looked
| at their docs, they read like it's been around for 20 years and
| has millions of apps, even though that's not true. Oh yeah and of
| course the giant BLM banners everywhere they have/used to have.
| Just checked, now those banners are replaced with "Honoring Asian
| Pacific American Heritage Month", lol. Apparently their vision of
| a futuristic OS is one in which every page in the docs has some
| random totally US centric bit of virtue signalling in it. No
| wonder they somehow can't even finish a _microkernel_ , a design
| that reduces performance in return for a much smaller syscall
| surface area.
| shp0ngle wrote:
| I think you are downvoted because you touch on the BLM/Asian
| Pacific stuff, which tickles people. But yeah you are also very
| right.
| ignoramous wrote:
| Just because they have those banners up doesn't mean those
| point to some latent reason for whatever is responsible for
| their woes. Granted it gives a window in to the culture of
| the Fuschia team at Google, but to me, personally, it doesn't
| come off as virtue-signalling at all but rather a conscious
| effort to put diversity and inclusion in the front and center
| of what they do. As another example, Google has had socio-
| political doodles for decades, but I never considered those
| as virtue-signalling.
| jeltz wrote:
| To me it comes off as inclusive of Americans while
| excluding the rest of the world. As a European I do not
| feel welcome, and I imagine people further from US culture
| feel even less welcome.
| skavi wrote:
| Would you mind going into why these banners make you feel
| unwelcome? Do you feel similarly about using the US
| Google homepage?
| native_samples wrote:
| It's relevant because it reflects their priorities and how
| they view developers.
|
| The giant banners say this: although these are technical
| docs you may need to do your job, the most important thing
| you must see above all is an announcement of how morally
| pure we (think we) are. Once isn't enough. On our blog
| isn't enough. It must be the biggest and most eyecatching
| thing on literally every single page of our documentation.
| This indicates a lack of respect for the time and attention
| of devs. The implementation is also incompetent - the
| banner text appears to have leaked into search result
| snippets, thus reducing the utility of their docs search
| engine.
|
| When Steve Ballmer jumped around on stage yelling
| "developers! developers! developers!" he was ridiculed
| because the outburst of energy seemed absurd and out of
| place for a CEO. But many of us appreciated the sentiment -
| that if you're developing an operating system then
| developers matter and their time/attention matters. Ballmer
| knew that. Platforms aren't chicken/egg situations where
| it's unclear what comes first. Apps come first. Users come
| for the apps. Then more apps come to follow those early
| adopter users, but ultimately, there had to be some apps to
| kick things off.
|
| When the first thing you see at the top of the Fuschia docs
| is something totally unrelated to programming / the reason
| you were at that site, and which is irrelevant to most of
| the world as well, this sends a powerful message that the
| Fuschia devs are:
|
| a. Staggeringly US centric. Their mindset isn't
| international at all. This is offputting to those of us
| outside the US. Fuschia's front page claims it's "an
| inclusive, open source effort". Not only have they never
| even tested it with a non-English locale, but they ignored
| the critical locale bug for so long other people had to
| fork the project to even _make the emulator start up_ for
| non-English users [1]. That 's about as non-inclusive as
| you can get yet is also absolutely predictable. Did we
| really need the blog to tell us that? Not really, we could
| guess it quite easily. The sort of people who demand such
| banners always seem to be hypocrites. It's called virtue
| _signalling_ for a reason - people who do it announce their
| principles but never seem to live by them.
|
| b. Not really rewarded for making developers happy. It
| reinforces a general impression about modern Google, that
| the personal success of the employees and executives is
| tied to things like the size of a giant black banner as
| much as whether their kernel is secure or their API docs
| are actually accurate.
|
| c. As such _extremely_ likely to manipulate their platform
| to prioritize the happiness of activists over that of
| developers. It 's a bold statement of ideological
| allegiance. Who in their right mind is going to write an
| app for Fuschia that's braver than a shopping cart when
| they see that? Nobody smart, because you can guess what
| will happen if Fuschia actually does get apps: half of them
| will end up banned for some inane, impossible to understand
| reason, probably related to mundane use of language that's
| inexplicably become unacceptable since yesterday in
| California. The financial risk of developing for this
| platform is huge.
|
| BTW: the Google doodles are pretty political these days,
| but in the beginning they were mostly reflecting things
| like national holidays.
|
| [1] https://github.com/assusdan/fuchsia-patches
| skavi wrote:
| You're comment and a sibling both express that these
| messages are off-putting to international audiences? Why
| is that?
|
| BLM originated in the US, but black people definitely
| experience racism elsewhere. The movement is not
| necessarily US exclusive.
|
| I've seen plenty of tech companies with Ukraine banners
| on their websites, and have not seen a single criticism.
| Wouldn't such banners exclude US developers under that
| logic?
| Banana699 wrote:
| >You're comment and a sibling both express that these
| messages are off-putting to international audiences?
|
| Non-American distinct from both of them here: They're
| right.
|
| >black people definitely experience racism elsewhere
|
| Persuambly you think BLM is a generic "Racism Bad"
| message, so 3 things to say about this
|
| 1- BLM is not a generic "Racism Bad" message. It's the
| name of a movement whose leaders used donor money to
| accumulate personal wealth. It's the chant used by
| protestors who burned down homes and stole from people's
| business. It's the motto that people who write books to
| argue that disputing a racism accusation is a sign of
| guilt and fragility. I consider myself a non-racist, and
| this movement is not the kind of things I support.
|
| 2- The kinds of people and media outlets who support BLM
| tends to be selective and hypocritical. Wouldn't an
| honest person who shout "BLM" when a black man is killed
| by a police officer, wouldn't that person also be
| obligated to shout "White Lives Matter", WLM, when white
| innocents are killed by a black criminal because of their
| race ? This last event happens to be a real thing that
| actually happened (https://en.wikipedia.org/wiki/Waukesha
| _Christmas_parade_atta...), by a self-confessed black
| terrorist. Searching for "Black Supremacy", the only
| response in the first page is a short Wikipedia page, the
| rest is articles talking about _White Supremacy_ instead.
| I have a feeling things are not so balanced here.
|
| 3- Even granting that BLM is a good moral cause to
| support, how is it relevant to a tech document ? Let us
| grant the following causes are all worthy of moral
| solidarity ["Climate Change", "China's Treatment of
| Uyghur Muslims", "Sexual Harrasment", "Child Abuse",
| "Animal Cruelty"]. All of the elements of this list are
| morally abhorrent things to me that I want to prevent or
| reverse. Now, where and when should I say this? at my
| home? to each and every one of my friends or family ? at
| work ? on the street ? Is there any time and place where
| I can safely lie down and not speak about atrocities, for
| once?
|
| >I've seen plenty of tech companies with Ukraine banners
| on their websites
|
| I'm very very annoyed by this too. Seeing Github and
| JetBrains issue a statment about this conflict is the
| most pathetic, hypocritical and forced thing I have seen
| in a very long while.
|
| Point 3 above applies to it straightforawrdly with no
| explanation, point 1 and 2 also apply as follows
|
| 1- Pro-Ukraine sentiment isn't a neutral "War Bad"
| message, it usually encodes within it pretty dubious and
| very partisan assertions, such as the belief that all
| Russians are to - and should be - blame and punish for
| Putin's action, as well as unhealthy and fanatic support
| for the Ukrainian government and its actions.
|
| 2- Tons of countries, everywhere and all the time, have
| experinced invasions and other illegal military actions.
| The example off the top of my head is Yemen. Children
| dying of starvation, civilaians bombed and hospitals
| wrecked, *Since 2015*. Did any of those companies issue
| statments then ? Let's forget about the past. Do we have
| a right to expect those companies to protest every single
| war and illegal military actions, regardless of the
| position of US politicians and US foreign policy, in the
| future?
| skavi wrote:
| I do feel that BLM is a worthy cause to support. This is
| mainly because I feel the movement can be seen separately
| from any formal organizations or individual people. I
| understand how you may disagree.
|
| Regardless, the real disagreement seems to be in where it
| is appropriate to represent the movements you believe in.
|
| Even granting that a technical document page may not be
| the best place for such advertising, I still do not
| understand why the presence of these messages would
| offend an international audience.
|
| If they are truly irrelevant, then surely it should be at
| worst unsightly?
| Banana699 wrote:
| >then surely it should be at worst unsightly?
|
| What me and other people are trying to get across to you,
| is that you only feel this way because you support the
| cause.
|
| The practice of filling every place and institution with
| your partisan beliefs is a sign of disrespect,
| essentially a power move. "You're here to read up on an
| OS, but joke on you, you actually can't escape the all-
| pervasive hand of my religion. Here's some propaganda
| diet before you read anything".
|
| To know what that feels, imagine if every time a mainland
| Chinese scientist published an academic paper they were
| forced to write at the end "Long Live The CCP" with big
| bold letters. Or imagine if every time a Muslim scientist
| published a paper they must write "In The Name Of Allah,
| God Of All Creation" in the beginning. Etc... Can you see
| why this is ridiculous to a non-communist or a non-Muslim
| ?
|
| Why is this ridiculous belief-signalling an expression of
| power ? 2 reasons :
|
| 1- Like I said above, it asserts existence in a space
| where its competitors don't. No Christian, Jew or Hindu
| declares their religion in the academic papers they
| author, it feels fair that Muslims also shouldn't, it's
| like an unspoken agreement on keeping Academia free of an
| irrelevant controversial subject that gets people riled
| up and generates more heat than light. When Muslims (in
| the hypothetical world) violate this, it's a unilateral
| violation of the agreement that signals power and
| superiority. "Rules Don't Apply To Us". It's a fighting
| stance.
|
| In the concrete case we're discussing here, only
| progressive tech companies signal their beliefs in this
| vulgar way, no conservative tech firm have ever put "Blue
| Lives Matter" or "Make America Great Again" on their
| technical docs, although there are tens of millions of
| people who believe just as sincerly as you that those
| causes represent worthy and moral goals. The reason sane
| well-adjusted people refrain from expressing politics and
| religion in workplaces is because of common sense social
| protocols and unspoken consensus, when you break those,
| you're deliberately asserting power and inviting
| challenge.
|
| 2- It's probably forced. Just like the vast majority of
| Chinese scientists or Muslim scientists would probably do
| the above hypothetical signalling out of fear (of being
| labelled a traitor and a heretic, respectively), the vast
| majority of people in progressive-dominated social
| bubbles probably virtue-signal out of fear, rather than
| any geniune conviction. It's morally disgusting to force
| people to express beliefs they don't actually hold, or
| hold in lesser intensity than being forced to express.
| It's tyranny 101, straight from 1984.
| native_samples wrote:
| _" I've seen plenty of tech companies with Ukraine
| banners on their websites, and have not seen a single
| criticism"_
|
| The Ukraine banners are dumb. They have no place in
| technical docs. Like everyone else I want them to win
| their war, but spamming blue and yellow flags everywhere
| isn't going to help achieve that. Moreover the murky
| nature of their military alliances (Azov etc) makes it
| hardly a Disney movie-esque conflict with pure good and
| pure evil.
|
| You see no complaints because why bother? The sort of
| people who do that never care if their actions are
| unpopular with other people, in fact they take a perverse
| joy in it.
| goodpoint wrote:
| > Steve Ballmer ... was ridiculed because the outburst of
| energy ...
|
| It was much, much worse than that.
|
| Putting aside the crass yelling and dancing; also putting
| aside any rumor of cocaine abuse; putting aside how
| cultish it looks...
|
| Having a large crowd of adults yelling "dentists!
| dentists!" or be it lawyers, accountants, etc in a frenzy
| would be seen as very unprofessional.
|
| > But many of us appreciated the sentiment
|
| I hope not.
|
| > It's called virtue signalling for a reason - people who
| do it announce their principles but never seem to live by
| them
|
| And how do you know that? Some people can be
| hypocritical, yes.
|
| Are all people with principles hypocritical?
| tester756 wrote:
| I think you're attacking weakest points of his comment,
| tbf.
| goodpoint wrote:
| So?
| jimbob45 wrote:
| >Having a large crowd of adults yelling "dentists!
| dentists!" or be it lawyers, accountants, etc in a frenzy
| would be seen as very unprofessional.
|
| If the CEO of a large dental organization has the balls
| to go on stage and yell, "Hygienists! Hygienists!
| Hygienists!", it shows that he's willing to prostrate
| himself to show his commitment to the company he serves.
| People appreciate that. There are certainly enough CEOs
| ignoring the needs and desires of their employees sitting
| inside their ivory towers these days. We don't need more
| of them.
| Banana699 wrote:
| >Are all people with principles hypocritical?
|
| I think the issue here is not "People With Principles",
| but "People With Principles They Are Dying To Tell You
| About". This makes the standard for judging you much much
| higher : You not only think those principles are superior
| to a lot of other competing ones, You not only advocate
| (sometimes, a lot of times to be honest, obnoxiously) for
| those principles, You do all of those things in times and
| places where it doesn't make much sense, and right in the
| middle of other people who might very well disagree with
| you to heaven and back on those things but choose to stay
| silent and cooperate with you on unrelated matters
| nonetheless, cooperation which you break and impede by
| loudly and non-ceaseingly declaring views they find
| disagreeable. This makes the people around you,
| understandbly, model you as the truest possible
| expression of an X-ism follower: you're at least as
| sincere as any other X-ist, so any failings or deviation
| from you principles you have or do is something that the
| whole X-ism movement along with all its followers also
| have or do.
|
| I'm biased against what typical US progressives advocate
| for, so I will choose one of my own principles to make an
| example of.
|
| I'm a (still booting up) vegetarian, I try not to eat any
| meat for ethical reasons. I did manage to successfully
| banish meat from my food for about 2 years now, but I'm
| not strong-willed enough yet to stop eating marine life.
| (Technically this makes me not a vegetarian at all, but
| the weird-sounding word "Pescetarian", but "vegetarian"
| is more well known and more in alignment with my mental
| self-image and future plans.) Now, if I started
| advocating for vegetarianism very loudly and in every
| single chance and place I find, not only will this make
| some people very annoyed, but they will start asking :
| What sort of life do you lead by following this principle
| you're very passionate about ? If my life deviates from
| my principles (and it does), I expect people will be even
| more annoyed, outraged even, and become resistent to and
| critical of my advocacy. A similar thing happens with
| nearly every major religion or religion-like ideology,
| which vegetarianism and progressivism indeed are.
| ignoramous wrote:
| > _It 's relevant because it reflects their priorities
| and how they view developers._
|
| Yes, that they constantly think about diversity and
| inclusion. Though, I agree that encouraging workplace /
| employee activism is a tricky slippery slope. Companies
| like coinbase and basecamp eschew it, for instance.
|
| Re: _a_ : You gotta start somewhere. Besides, work to add
| a banner is probably a one-day / one-week low-hanging
| fruit, whereas i18n is not. In comparing those, you're
| comparing something that takes months to deride something
| that probably took hours to build and ship.
|
| Re: _b_ : Not privvy to today's culture at Google, so
| can't say for sure other than speculate.
|
| Re: _c_ : You view that as a bad thing. Such markers
| (drastic measures as it may seem to _you_ ) is how any of
| this changes. As a thought-experiment / deriving example
| from tech: do you oppose DNS encryption (a drastic
| measure in many a eyes [0]) because it nullifies existing
| cheaper surveillance apparatus deployed by schools,
| corps, governments; or do you embrace it and firmly want
| Browser and OS vendors to push forward with it?
|
| [0] https://www.zdnet.com/article/uk-isp-group-names-
| mozilla-int...
| staticassertion wrote:
| Building an OS takes time, they're doing it incrementally, the
| bugs were known and even had issues for them already. I
| wouldn't draw any crazy conclusions from this research, this is
| a hacker's exploration of a foreign OS, which is very
| interesting, but isn't something I'd draw _judgments_ from.
| xmodem wrote:
| Or maybe it's just that building a kernel, network stack, etc
| from scratch, and getting it to the point where it's stable,
| secure, sufficiently performant, compatible etc, compared to
| what's already out there is a massive undertaking - microkernel
| or not - and they just need more time.
|
| Let's not forget that Android didn't even have smooth 60fps
| scrolling until well into the 2010s.
| dec0dedab0de wrote:
| _It 's hard not to feel like maybe Google has lost the ability
| to develop operating systems._
|
| Did they ever have that ability? I know they did a bunch of
| work for Android/Chrome OS. But both of those are Linux, have
| they tried to develop an OS from scratch before fuschia?
| native_samples wrote:
| Yes. Android is sufficiently different from a stock Linux
| distro that it absolutely counts as a unique operating
| system. ChromeOS is also unique in interesting ways, although
| less successful. It's certainly a production quality OS.
|
| Perhaps more importantly, both of those are complete and have
| real users who found value in them.
| kllrnohj wrote:
| > ChromeOS is also unique in interesting ways, although
| less successful.
|
| Chrome OS absolutely dominates the education market. So
| less successful than Android, sure (but so is literally
| every other OS at this point), but still very successful.
| pjmlp wrote:
| That is an US phenomenon though.
|
| It can be hardly seen in European countries, and I bet
| other continents are hardly different.
| pjmlp wrote:
| Android and Chrome OS use the Linux _kernel_ , that is all.
|
| Everything else, including driver subsystem (Android docs
| even calls classic Linux drivers legacy), doesn't have
| anything to do with GNU/Linux.
___________________________________________________________________
(page generated 2022-05-25 23:01 UTC)