Announcement

Collapse
No announcement yet.

Google Calls On Companies To Devote More Engineers To Upstream Linux, Toolchains

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    I don't use Linux for its security benefits. It is more secure than Windows but I use Linux for wider app availability and Wine support and games. If I need a security focused os I use OpenBSD but that comes with setbacks like no linuxemulator anymore and no wine support. I've heard some of the microkernel OS projects are even more secure but obviously have even less mainstream support than the *BSDs.

    Comment


    • #22
      Originally posted by timofonic View Post

      That's not the issue.

      They blame something, yet only complain but not promote a pragmatical solution. It may seem as a subtle attack against Linux, they have an agenda with FuchsiaOS
      Fuchsia makes a lot more sense than Linux for a desktop and mobile operating system.

      Zircon's sane and stable ABI are things which especially appeal to hardware vendors. No SI and IHV wants to deal with drivers that break on every point Linux release and there is no reason why they should be blackmailed into opening and upstreaming their drivers id they don't want to.

      Comment


      • #23
        Originally posted by Sonadow View Post
        Zircon's sane and stable ABI are things which especially appeal to hardware vendors.
        Microkernels have a very long history and appeal inside certain communities. They are, of course, hard to get one's head around, especially those used to monolithic kernels such as Windows (or Linux), but they are the basis for things such as hurd, and even iOS.

        Comment


        • #24
          Originally posted by JackLilhammers View Post

          Perhaps you'll be right, but the list of the discontinued projects is not enough to make forecasts on the active ones.
          I think it is. Will a business invest in a new Google product if it sees a trend of many being killed after 2 years?

          I wonder how many people have avoided Stadia due to knowing how often and ruthlessly Google kills its products.

          Outside of search, email, youtube and android, I wouldnt be too sure any service will survive the chop. (incidentally I use all 4 of these).

          And when they survive, changes in ToS can kill you - the change of amount of storage on Google Photos was a massive thing, especially if you thought all your snaps were secure for life.

          Comment


          • #25
            There used to be people working on projects bringing great security improvements on top of Linux and providing the result to everyone at no cost: mainly PaXTeam, spender (Brad Spengler), ephox (Emese Revfy), etc. working on PaX and grsecurity, of course.
            spender has repeatedly made it abundantly clear that the reason why they stopped providing PaX/grsecurity at no cost, as they had been doing for about 16 years before, was the kernel hardening effort, because in practice, it caused the integration of outdated, and sometimes weakened, forks of (minor, at that) PaX/grsecurity defenses. This process created even more work for PaXTeam & spender to clean up the mess - effectively forcing them to free labor. It wasn't sustainable for people not working full time on these projects. Remind me who was - and still is - leading these mainline kernel hardening efforts ? Right, Google.

            Fast forward a bit over 4 years of commercial operation: not only at least spender was able to quit his former day job as a malware analyst to work full time on grsecurity, but Open Source Security, Inc has been able to hire at least minipli (Matthias Krause) to work full time on grsecurity. The feature gap with mainline has widened even further, with the advent of Respectre (a GCC plugin immensely superior to the whack-a-mole manual patching of Spectre gadgets used in mainline), AUTOSLAB, and other defenses found nowhere else. Open Source Security, Inc. is one of the sponsors for the work on Rust-GCC, BTW.
            Meanwhile, what I dub the "magic quintet" (MEMORY_UDEREF, KERNEXEC, CONSTIFY, RANDSTRUCT, RAP), which repeatedly stopped most published exploits for vulnerabilities whose high profile and impact earned them LWN articles, remains missing from mainline entirely (MEMORY_UDEREF, KERNEXEC, RAP) or in full-featured form (CONSTIFY, RANDSTRUCT). Heck, even MPROTECT is missing, with S.A.R.A. not being mainlined (and the relevant LSMs still not being stackable in kernels used by most people, anyway).

            IOW, Google's actions are among the causes of mainline Linux core security features mostly stagnating. Obviously, there are other well-known ones, especially Linus and like-minded people not taking security seriously. I still resent the refusal of KERNEXEC and MEMORY_UDEREF, which have effectively provided the functionality of modern hardware with SMEP/SMAP (x86) or PXN/PAN (ARM), but without hardware requirements (though PaX does use these hardware features when available in order to reduce the performance cost), for the most part of the past two decades. 5 years ago, such hardware was an overwheming majority in the real world, and is still common nowadays...

            As for microkernels: the L4 microkernel family, one of the most proeminent members thereof is the formally verified seL4 (on 32-bit ARM and now 64-bit RISC-V), is getting closer to 30 years. OKL4 was widely deployed in mobile phones.
            Oh, and OpenBSD security isn't that great. OpenBSD provided ASLR - invented by PaX - no less than about 5 years after both mainline Linux and Windows provided it (2008 wrt. 2003). spender has repeatedly lambasted OpenBSD for implementing weak versions of PaX defenses, e.g. OpenBSD W^X.
            Last edited by debrouxl; 04 August 2021, 03:57 AM. Reason: OpenBSD, thinko MPROTECT instead of MEMORY_UDEREF, other improvements

            Comment


            • #26
              Originally posted by Sonadow View Post

              Fuchsia makes a lot more sense than Linux for a desktop and mobile operating system.

              Zircon's sane and stable ABI are things which especially appeal to hardware vendors. No SI and IHV wants to deal with drivers that break on every point Linux release and there is no reason why they should be blackmailed into opening and upstreaming their drivers id they don't want to.
              I disagree. It's good for proprietary drivers., something most corporations love despite their fake Open Source love when they can save money with it.

              Obviously, they want to conquer desktop and mobile space with FuchsiaOS/Zircon.

              Comment


              • #27
                Originally posted by Sonadow View Post

                Fuchsia makes a lot more sense than Linux for a desktop and mobile operating system.

                Zircon's sane and stable ABI are things which especially appeal to hardware vendors. No SI and IHV wants to deal with drivers that break on every point Linux release and there is no reason why they should be blackmailed into opening and upstreaming their drivers id they don't want to.
                What does "blackmailed into opening and upstreaming" even mean? Hilarious. 😊.
                No one is forcing any IHW to contribute drivers for Linux at all. But of course if they insist on having their driver as an external binary blob instead of being part of the upstream kernel, then that is purely *their* decision. And if a non-existing "ABI" breaks that the driver is using, then that is their problem. Yes, you can not break an ABI if it's not there. Linux has never claimed to have some stable "Application Binary Interface" towards drivers so how can it break? Now, you may wish for Linux to have such an ABI to make it easier for proprietary drivers, but that does not make it so. Personally I have no sympathy for companies whining about the lack of a "stable driver ABI" to make it easier for them to distribute their binary blob for driver. Either they adapt and fix their driver every time it breaks, or they can open up and upstream the driver. Or if they don't want my money they can choose to leave Linux. You see, they have options. Hardly blackmailing.
                Last edited by tomas; 04 August 2021, 07:22 AM.

                Comment


                • #28
                  Personally I don't understand the reason for having a closed driver, we are in 2021 and a driver cannot be a state secret.
                  Among other things, most of the drivers are done with your ass.

                  Comment


                  • #29
                    Originally posted by Charlie68 View Post
                    Personally I don't understand the reason for having a closed driver, we are in 2021 and a driver cannot be a state secret.
                    Among other things, most of the drivers are done with your ass.
                    Agreed. The problem is that fsckers keep purchasing such products, fueling this crap business.

                    Comment


                    • #30
                      Originally posted by CommunityMember View Post

                      Microkernels have a very long history and appeal inside certain communities. They are, of course, hard to get one's head around, especially those used to monolithic kernels such as Windows (or Linux), but they are the basis for things such as hurd, and even iOS.
                      Windows use a hybrid kernel, not a monolithic one. As are the iOS kernel.
                      Last edited by F.Ultra; 04 August 2021, 10:14 AM.

                      Comment

                      Working...
                      X