back to article Google reveals another experimental operating system: KataOS

Google, one of very few tech companies willing to experiment with new operating systems, has unveiled KataOS for embedded machine learning devices. KataOS was announced along with Sparrow on the Google Open Source blog. KataOS is the operating system design and Sparrow is the reference implementation, as the Weston display …

  1. 3arn0wl

    Reinventing the wheel... for what purpose?

    I quite like what I've read of Kata, if only for the reassurance that the seL4 kernel brings. The only doubt in my mind is that Google might be data harvesting with it...?

    I guess the issue with both Kata and Fucsia is that, since neither are Linux based,

    - firmware blobs will need to be written and

    - apps are going to have to be ported to the platform...?

    And all that seems like a ton of work, when most people seem to be happy enough using Android/AOSP...

    1. Version 1.0 Silver badge
      Thumb Up

      Re: Reinventing the wheel... for what purpose?

      When I was a young guy I saw a great operating system written in PL/M (aka Programming Language for Microcomputers). The neat thing was that you could review it very easily to see how it worked.

      1. Liam Proven (Written by Reg staff) Silver badge

        Re: Reinventing the wheel... for what purpose?

        > operating system written in PL/M

        So... CP/M then?

    2. Paul Crawford Silver badge

      Re: Reinventing the wheel... for what purpose?

      Very much so. We have two major OS in current use: Windows & Linux, and they both have security issues of one form or another. (OK add iOS/Andoid for phones but they are closer)

      But the problem is one of complexity. Once you get a huge OS and layers of applications, especially legacy ones, to actually do anything that is wanted you have so many different reasons why properly securing it becomes all but impossible. Just look at MS printer nightmare recently for a can of worms they could not quite fix correctly. Re-write it all properly? Yes, riiiight...

      So for some jobs a properly secure micro kernel sounds like a great idea but would it make computing for us, the consumer, and more secure or will it be used for DRM taking away our freedoms? Would it stop ransomware/extortion code that runs with the victim user's privileges?

      1. DS999 Silver badge

        Re: Reinventing the wheel... for what purpose?

        Even if iOS used a provably secure kernel (it actually does use seL4, which runs on the Secure Element not the main CPU) all those layers of APIs and applications you mention would not be secure, and it would be impossible to make them provably secure.

        So you have your perfectly secure microkernel, with services like 'networking' running on it, and the microkernel remains secure but there are bugs in the networking service. You're still just as screwed as if there is a networking bug in a monolithic or hybrid kernel, so a microkernel isn't going to buy much in something as complex as a modern PC or smartphone.

        1. This post has been deleted by its author

          1. DS999 Silver badge

            Re: Reinventing the wheel... for what purpose?

            Yes but if you compromise networking you have compromised everything that matters in a modern device.

            1. This post has been deleted by its author

              1. DS999 Silver badge

                Re: Reinventing the wheel... for what purpose?

                There is not a whole lot of smartphone software that can run without a network (even for ads which are needed for 'free' ad supported software) but is still interesting to black hats to attack. I can't think of a single example, in fact.

        2. Dave 126 Silver badge

          Re: Reinventing the wheel... for what purpose?

          > Even if iOS used a provably secure kernel (it actually does use seL4, which runs on the Secure Element not the main CPU)

          I can't find a reliable source that Apple's T2 chip (secure enclave) uses seL4, other than a poorly written article that cites an ambiguously written sentence from a Reg article (perish the thought). As far as I can find, the T2 chip runs L4, but not seL4. If the most mature application to date for seL4 is a DARPA funded military drone from 2018, I'm suspecting that Apple's huge deployment of it would be bigger news.

          L4 is 'just' a microkernel, albeit a 3rd generation one built with security in mind. seL4 is a microkernel that has had a lot of difficult work put into it to prove mathematically that it meets its specifications. The difficulty of such proofs is why such microkernals are not more widespread, and seL4 is the only extant example.

          iOS doesn't use L4, but it coexists on a SoC that includes an enclave that uses L4.

        3. fpx

          Re: Reinventing the wheel... for what purpose?

          The difference is that it is *possible* to build a secure device on a provably secure microkernel. Of course you can still screw up security on any level.

          Don't confuse the security that is talked about here with freedom from viruses or malware on a PC. Secure microkernels are a big deal e.g., where safety is important, like in medical devices. You don't want them to fail just because of a hard to find bug in the OS.

    3. Anonymous Coward
      Anonymous Coward

      Re: Reinventing the wheel... for what purpose?

      This isn't about Android or "apps", it's about Google wanting to break into the market of spy devices that Amazon is currently dominating.

      No worries though, since it's a Google project that isn't related to "Search", it won't take off. For instance, "home" "Nest" is nearly unknown and there's a bazillion nest products. The Google's "IoT core" is basically a trope as it should be "GoT" because there's literally NOTHING in it that is for the general internet, it's %100 Google. This "new" (most likely re-rehashed) micro kernel won't make any of that not true, it will only further the Google agenda.

      I don't understand why anyone would willingly put one of these MegaCorp. spy devices in their home but, if you do.... if you do you might want to choose 1 that won't be discontinued next week.

      NOTE: The Google nest page still lists Stadia without letting you know it's going away. What does that tell you about the success of this future micro kernel if the existing kernel and products need deceitful advertising? https://store.google.com/intl/en/ideas/articles/curious-about-smart-home-devices-start-here/?hl=en-US

    4. Anonymous Coward
      Anonymous Coward

      Re: Reinventing the wheel... for what purpose?

      Because they can and because they will fund development costs using 'free money' due to not paying tax at the same rate as ordinary, smaller companies.

    5. Dave 126 Silver badge

      Re: Reinventing the wheel... for what purpose?

      > Reinventing the wheel... for what purpose?

      Mate, the wheels we use today are absolute garbage. They are prone to punctures, get stolen, and often fall off the cart completely. That is to say, the computing devices we use today are liable to be hacked, despite the huge cost, effort and inconvenience spent trying to thwart the bad guys. Oh yeah, and sometimes kit just crashes by itself.

      That's very not good as computing devices are used in ever more parts of our lives. In cars, pacemakers, video doorbells, military drones...

      So, back in 2006 work started on a microkernel, seL4, that could be formally verified to do what it is specified to do, that is, proven exactly as a mathematical theorem is proved. That was just the first step though, and this approach is hard. Very hard, but very necessary.

      A Google are building an OS atop this secure microkernel, a feat the developers of seL4 said was beyond themselves.

      Google want it run on in open source silicon, too. Since what's the point of a secure software stack if you can't trust the chip its running on?

      So, Google say it's for embedded devices with machine learning. Medical devices spring to mind. User authentication modules. Any bit of gear you need to have learn about you and don't want the information sent home to the mothership. Things like Apple's T2 chip are based on similar thinking.

    6. Liam Proven (Written by Reg staff) Silver badge

      Re: Reinventing the wheel... for what purpose?

      > firmware blobs will need to be written

      Well, yes, but if it only supports one or two specific RISC boards, then this will not be a big issue.

      1. Dave 126 Silver badge

        Re: Reinventing the wheel... for what purpose?

        The RISC boards in question are open source, so the firmware doesn't have to be blobby.

        Clearly this team within Google are thinking seriously about trust. It parallels efforts from DARPA.

  2. StrangerHereMyself Silver badge

    Building on top

    Building an Opearting System on top of an existing verified microkernel seems a lot more sensible than rolling our own (here's looking at you Fuchsia).

    1. Dave 126 Silver badge

      Re: Building on top

      Different applications. Writing formally verified drivers and software for KataOS will be hard work - worthwhile for a pacemaker or user identification module, but overkill for an audio player, or whatever Fuschia is for.

      1. StrangerHereMyself Silver badge

        Re: Building on top

        No, it isn't. I see no reason why seL4 can't be used for anything Fuschia's Zircon is being used for.

        Linux is a general operating system kernel and used in everything from spacecraft to desktops to servers to embedded kiosk to cars to nuclear power plants (I'm unsure about that last one, but in would surprise me in the least).

  3. karlkarl Silver badge

    "which uses Haskell and Python – as an abstraction layer to join the C and Rust layers together."

    Ugh. They are certainly revving up the technical debt at an early stage!

    Just bolt a tiny C compiler onto Rust, create an unsafe_c {} tag and be done with it.

    1. Mike 137 Silver badge

      "uses Haskell and Python – as an abstraction layer to join the C and Rust layers together"

      But what really interests me is the quality of the machine code derived from all this. That's the place the bugs matter at execution time.

  4. Bartholomew
    Happy

    Security Enhanced L4

    Good that it is Security Enhanced L4. For a minute there, I was scratching my head going L4 ... isn't that the kernel that (has really fantastic performance, basically because the kernel fully) trusts the user space. Security in L4 is the responsibility of the user space (L4 being different than seL4).

    I guess it is time to start reading up on seL4, it does sound fantastic. seL4 may be the first-ever general-purpose operating-system kernel that has been formally verified as being secure: seL4: Formal Verification of an OS Kernel(pdf). Which is probably why it is, I'm guessing "a specified requirement", in Boeing's drones sold to the military.

    1. Dave 126 Silver badge

      Re: Security Enhanced L4

      Yep, it's a big deal.

  5. 45RPM Silver badge

    I’m somewhat puzzled. I thought that Rust could replace C (and that C should be deprecated in favour of Rust). So why is C required at all in this new OS? As a showcase of new technology, why is old technology being used at all?

    1. Bartholomew

      If seL4 was fully rewritten in Rust who would pay for the analysis to prove that it was still secure (From Wikipedia "The proof provides a guarantee that the kernel's implementation is correct against its specification, and implies that it is free of implementation bugs such as deadlocks, livelocks, buffer overflows, arithmetic exceptions or use of uninitialised variables." and "The researchers state that the cost of formal software verification is lower than the cost of engineering traditional 'high-assurance' software despite providing much more reliable results. Specifically, the cost of one line of code during the development of seL4 was estimated at around US$400, compared to US$1,000 for traditional high-assurance systems.").

    2. Mike 137 Silver badge

      Not necessarily

      "I thought that Rust could replace C (and that C should be deprecated in favour of Rust)"

      Not necessarily (particularly across the board). Ultimately the security of the executable depends heavily on the quality of the compiler and library -- particularly when we're using highly optimising compilers and extensive libraries. Only machine level testing and verification is really sufficient under these conditions, as the executable probably will not entirely be expressed by the visible source. So the high level language used is an important part of the matter, but far from all of it.

  6. Abominator

    Its a google product

    So will be dead when it come out of Beta.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like