Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Cyborg)
  • No Skin
Collapse
Brand Logo

CIRCLE WITH A DOT

  1. Home
  2. Uncategorized
  3. Significant raise of reports (on the Linux Kernel Mailing List) https://lwn.net/Articles/1065620/

Significant raise of reports (on the Linux Kernel Mailing List) https://lwn.net/Articles/1065620/

Scheduled Pinned Locked Moved Uncategorized
45 Posts 21 Posters 0 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • linear@nya.socialL linear@nya.social
    @cwebber@social.coop we need microkernel based operating systems with capability-based security enforcement, isolation of components from each other as a baseline assumption, and formal verification of the whole thing at both the code and spec level, and we need all of this quite urgently
    fcbsd@hachyderm.ioF This user is from outside of this forum
    fcbsd@hachyderm.ioF This user is from outside of this forum
    fcbsd@hachyderm.io
    wrote last edited by
    #23

    @linear @cwebber I think that might be what CHERI is trying to achieve: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

    1 Reply Last reply
    0
    • navi@social.vlhl.devN navi@social.vlhl.dev
      @ska @dalias

      "decouple storage from structure" is one of the best things but when i first started trying to think about it more, it was hard to wrap my head around how to design things to work like that

      i feel like a page of example apis or a book or smth would be very helpful for new folks not familiar with it
      ska@social.treehouse.systemsS This user is from outside of this forum
      ska@social.treehouse.systemsS This user is from outside of this forum
      ska@social.treehouse.systems
      wrote last edited by
      #24

      @navi @dalias Yeah, the way most people write C with pointers everywhere - because that's what they've been taught - isn't very compatible with that. Again, it comes down to: the way we teach C is really, really bad.

      Will you co-author my C book, that I'll write when I retire from coding? (that probably means in two decades or more 😝)

      navi@social.vlhl.devN 1 Reply Last reply
      0
      • linear@nya.socialL linear@nya.social
        @dlakelan@mastodon.sdf.org @cwebber@social.coop i do not think that setting aside the formal verification is wise, and i also do not think it poses a technical barrier that we cannot surpass. especially since we already have formally verified microkernels with capability-based security that can be used today within full desktop operating systems

        what needs to happen is for people to put the pieces together and polish it into a system regular folks can actually use
        dlakelan@mastodon.sdf.orgD This user is from outside of this forum
        dlakelan@mastodon.sdf.orgD This user is from outside of this forum
        dlakelan@mastodon.sdf.org
        wrote last edited by
        #25

        @linear @cwebber

        If you mean formally verifying the microkernel itself... yeah. I'm good with that. Isn't L4 formally verified? If you mean formally verifying every userspace daemon... Nice to have but I'm not holding my breath.

        linear@nya.socialL 1 Reply Last reply
        0
        • jpetazzo@hachyderm.ioJ jpetazzo@hachyderm.io

          @dalias do you know of any book/article/... that would explain or describe how to design a general purpose kernel with that in mind? (I wonder what things like file descriptors, device handlers, etc would look like there!)

          dalias@hachyderm.ioD This user is from outside of this forum
          dalias@hachyderm.ioD This user is from outside of this forum
          dalias@hachyderm.io
          wrote last edited by
          #26

          @jpetazzo Sadly no. A lot of this is personal experience and stuff I'd *like* to write if I could be motivated to do so.. 🙃

          1 Reply Last reply
          0
          • dlakelan@mastodon.sdf.orgD dlakelan@mastodon.sdf.org

            @linear @cwebber

            If you mean formally verifying the microkernel itself... yeah. I'm good with that. Isn't L4 formally verified? If you mean formally verifying every userspace daemon... Nice to have but I'm not holding my breath.

            linear@nya.socialL This user is from outside of this forum
            linear@nya.socialL This user is from outside of this forum
            linear@nya.social
            wrote last edited by
            #27
            @dlakelan@mastodon.sdf.org @cwebber@social.coop kernel is the bare minimum, i'd also want verification of at least specs around the hardware abstraction layer and how hardware related daemons talk to everything else. but it should definitely be possible for common system components and daemons as well, and i think should be mandatory for trusted daemons that supervise or manage other untrusted ones

            i doubt everything will be formally verified, but it is nonetheless a goal that should be worked towards, while finding ways to develop standard practices and make it easier to apply everywhere
            linear@nya.socialL dlakelan@mastodon.sdf.orgD 2 Replies Last reply
            0
            • linear@nya.socialL linear@nya.social
              @dlakelan@mastodon.sdf.org @cwebber@social.coop kernel is the bare minimum, i'd also want verification of at least specs around the hardware abstraction layer and how hardware related daemons talk to everything else. but it should definitely be possible for common system components and daemons as well, and i think should be mandatory for trusted daemons that supervise or manage other untrusted ones

              i doubt everything will be formally verified, but it is nonetheless a goal that should be worked towards, while finding ways to develop standard practices and make it easier to apply everywhere
              linear@nya.socialL This user is from outside of this forum
              linear@nya.socialL This user is from outside of this forum
              linear@nya.social
              wrote last edited by
              #28
              @dlakelan@mastodon.sdf.org @cwebber@social.coop i'm glossing over a lot with the "trusted" vs "untrusted" here, and i recognize that. i've been thinking about this for the better part of a decade and conveying my mental model for this is not possible in a few pots in a social media thread

              i just have not had the motivation or resources to spend on taking existing work in seL4/genode and assembling it with other pieces into the thing i'd like, writing specs, finding people to collaborate with on this, etc. life is busy and i already have so many projects
              1 Reply Last reply
              0
              • linear@nya.socialL linear@nya.social
                @cwebber@social.coop we need microkernel based operating systems with capability-based security enforcement, isolation of components from each other as a baseline assumption, and formal verification of the whole thing at both the code and spec level, and we need all of this quite urgently
                betarays@p.changeme.fr.eu.orgB This user is from outside of this forum
                betarays@p.changeme.fr.eu.orgB This user is from outside of this forum
                betarays@p.changeme.fr.eu.org
                wrote last edited by
                #29

                @linear@nya.social @cwebber@social.coop SeL4?

                linear@nya.socialL 1 Reply Last reply
                0
                • linear@nya.socialL linear@nya.social
                  @dlakelan@mastodon.sdf.org @cwebber@social.coop kernel is the bare minimum, i'd also want verification of at least specs around the hardware abstraction layer and how hardware related daemons talk to everything else. but it should definitely be possible for common system components and daemons as well, and i think should be mandatory for trusted daemons that supervise or manage other untrusted ones

                  i doubt everything will be formally verified, but it is nonetheless a goal that should be worked towards, while finding ways to develop standard practices and make it easier to apply everywhere
                  dlakelan@mastodon.sdf.orgD This user is from outside of this forum
                  dlakelan@mastodon.sdf.orgD This user is from outside of this forum
                  dlakelan@mastodon.sdf.org
                  wrote last edited by
                  #30

                  @linear @cwebber

                  I agree it would be nice to have, but I honestly think it primarily prevents progress. We'd be wildly better off with microkernel OSes that are at the same level of hackiness as the Linux kernel, and maybe have decent interfaces that could get replaced piecemeal as people came up with alternative implementations in memory safe languages, and then maybe formally verified at a later date.

                  Right now, you have to be comfortable working in kernel space to even do anything

                  linear@nya.socialL 1 Reply Last reply
                  0
                  • betarays@p.changeme.fr.eu.orgB betarays@p.changeme.fr.eu.org

                    @linear@nya.social @cwebber@social.coop SeL4?

                    linear@nya.socialL This user is from outside of this forum
                    linear@nya.socialL This user is from outside of this forum
                    linear@nya.social
                    wrote last edited by
                    #31
                    @BetaRays@p.changeme.fr.eu.org @cwebber@social.coop this would be part of my vision, yes
                    1 Reply Last reply
                    0
                    • ska@social.treehouse.systemsS ska@social.treehouse.systems

                      @navi @dalias Yeah, the way most people write C with pointers everywhere - because that's what they've been taught - isn't very compatible with that. Again, it comes down to: the way we teach C is really, really bad.

                      Will you co-author my C book, that I'll write when I retire from coding? (that probably means in two decades or more 😝)

                      navi@social.vlhl.devN This user is from outside of this forum
                      navi@social.vlhl.devN This user is from outside of this forum
                      navi@social.vlhl.dev
                      wrote last edited by
                      #32
                      @ska @dalias

                      i'll 100% co-author that book
                      1 Reply Last reply
                      0
                      • dlakelan@mastodon.sdf.orgD dlakelan@mastodon.sdf.org

                        @linear @cwebber

                        I agree it would be nice to have, but I honestly think it primarily prevents progress. We'd be wildly better off with microkernel OSes that are at the same level of hackiness as the Linux kernel, and maybe have decent interfaces that could get replaced piecemeal as people came up with alternative implementations in memory safe languages, and then maybe formally verified at a later date.

                        Right now, you have to be comfortable working in kernel space to even do anything

                        linear@nya.socialL This user is from outside of this forum
                        linear@nya.socialL This user is from outside of this forum
                        linear@nya.social
                        wrote last edited by
                        #33
                        @dlakelan@mastodon.sdf.org @cwebber@social.coop right now, this minute, you can go download SculptOS and have a microkernel-based OS with capability security that can run on a laptop and use its iGPU and run a web browser and virtualize linux and build itself using the Genode framework it is based on. and you can use that framework to swap out the process-level-virtualization-based default microkernel (NOVA iirc) with the formally verified seL4 (or other L4 family kernels) and never have to care about the API/ABI differences between microkernels because it abstracts that for you, nor the code inside the kernel.
                        dlakelan@mastodon.sdf.orgD linear@nya.socialL 2 Replies Last reply
                        0
                        • cwebber@social.coopC cwebber@social.coop

                          Significant raise of reports (on the Linux Kernel Mailing List) https://lwn.net/Articles/1065620/

                          Here's something I think we all will have to contend with, whether you're an AIgen enthusiast or not: attacking is easier than defending, and these things don't get tired and they *are* very good at finding exploits. None of us will be able to ignore that, and we will probably have to listen to real genuine reports from them, even if we reject AIgen input.

                          However, I don't think that's actually the right solution, and I don't think it's sustainable. 🧵

                          btel@mastodon.socialB This user is from outside of this forum
                          btel@mastodon.socialB This user is from outside of this forum
                          btel@mastodon.social
                          wrote last edited by
                          #34

                          @cwebber "- people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx""

                          I am not sure how this is going to work. How can be sure that the newest update is not a troyan horse (cf. recent axios breach)?

                          richter@calamity.worldR 1 Reply Last reply
                          0
                          • linear@nya.socialL linear@nya.social
                            @dlakelan@mastodon.sdf.org @cwebber@social.coop right now, this minute, you can go download SculptOS and have a microkernel-based OS with capability security that can run on a laptop and use its iGPU and run a web browser and virtualize linux and build itself using the Genode framework it is based on. and you can use that framework to swap out the process-level-virtualization-based default microkernel (NOVA iirc) with the formally verified seL4 (or other L4 family kernels) and never have to care about the API/ABI differences between microkernels because it abstracts that for you, nor the code inside the kernel.
                            dlakelan@mastodon.sdf.orgD This user is from outside of this forum
                            dlakelan@mastodon.sdf.orgD This user is from outside of this forum
                            dlakelan@mastodon.sdf.org
                            wrote last edited by
                            #35

                            @linear @cwebber

                            That's cool! I honestly had not followed any of this. I might have to dedicate an older laptop I have no real use for to this just for fun.

                            1 Reply Last reply
                            0
                            • linear@nya.socialL linear@nya.social
                              @dlakelan@mastodon.sdf.org @cwebber@social.coop right now, this minute, you can go download SculptOS and have a microkernel-based OS with capability security that can run on a laptop and use its iGPU and run a web browser and virtualize linux and build itself using the Genode framework it is based on. and you can use that framework to swap out the process-level-virtualization-based default microkernel (NOVA iirc) with the formally verified seL4 (or other L4 family kernels) and never have to care about the API/ABI differences between microkernels because it abstracts that for you, nor the code inside the kernel.
                              linear@nya.socialL This user is from outside of this forum
                              linear@nya.socialL This user is from outside of this forum
                              linear@nya.social
                              wrote last edited by
                              #36
                              @dlakelan@mastodon.sdf.org @cwebber@social.coop this is to say, what you are asking for exists, and has existed in a usable state for well over a decade, and is in some cases more feature complete than some other open source operating systems that people use and even daily drive

                              you can run it on a pinephone, too
                              cwebber@social.coopC 1 Reply Last reply
                              0
                              • dlakelan@mastodon.sdf.orgD dlakelan@mastodon.sdf.org

                                @linear @cwebber

                                I'd set aside the formal verification requirement to get the rest of it. I really do think microkernels were the right way to go, it's just that in 1992 or whatever the consumer hardware wasn't up to the task. I think probably around 2005 or so the hardware started to be able to afford to do that. But that's approximately the time that VMs and containers took off. Now we have this giant mess.

                                kirtai@tech.lgbtK This user is from outside of this forum
                                kirtai@tech.lgbtK This user is from outside of this forum
                                kirtai@tech.lgbt
                                wrote last edited by
                                #37

                                @dlakelan @linear @cwebber
                                The Amiga had a very fast microkernel based OS in the 1980s, though memory protection was unfortunately not part of it.

                                Something like that in a memory safe language would be nice.

                                1 Reply Last reply
                                0
                                • btel@mastodon.socialB btel@mastodon.social

                                  @cwebber "- people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx""

                                  I am not sure how this is going to work. How can be sure that the newest update is not a troyan horse (cf. recent axios breach)?

                                  richter@calamity.worldR This user is from outside of this forum
                                  richter@calamity.worldR This user is from outside of this forum
                                  richter@calamity.world
                                  wrote last edited by
                                  #38

                                  @btel @cwebber I believe that lies in update cooldowns, IE, specific updates must have been publically viewable (and being tested by the public) for at least x time period before they can be picked up by downstream tools.

                                  1 Reply Last reply
                                  0
                                  • linear@nya.socialL linear@nya.social
                                    @dlakelan@mastodon.sdf.org @cwebber@social.coop this is to say, what you are asking for exists, and has existed in a usable state for well over a decade, and is in some cases more feature complete than some other open source operating systems that people use and even daily drive

                                    you can run it on a pinephone, too
                                    cwebber@social.coopC This user is from outside of this forum
                                    cwebber@social.coopC This user is from outside of this forum
                                    cwebber@social.coop
                                    wrote last edited by
                                    #39

                                    @linear @dlakelan I am aware of Sculpt / Genode and have run it on physical hardware before! I am also working on tech that is also part of the answer.

                                    There is real work happening! It's going to take multiple efforts from multiple angles to get there

                                    dlakelan@mastodon.sdf.orgD 1 Reply Last reply
                                    0
                                    • cwebber@social.coopC cwebber@social.coop

                                      I don't think human reviewers are going to be able to keep up with the number of vulnerabilities we're seeing appear. I really don't. Humans won't be able to review at scale, and I also think that there's serious risks for blindly accepting AIgen patches, which for critical infrastructure could also be a path to *inserting new* vulnerabilities.

                                      We need to attack this systemically.

                                      I have more to say. More later. But that's the gist for now.

                                      teajaygrey@snac.bsd.cafeT This user is from outside of this forum
                                      teajaygrey@snac.bsd.cafeT This user is from outside of this forum
                                      teajaygrey@snac.bsd.cafe
                                      wrote last edited by
                                      #40
                                      Also see: https://marc.info/?l=openbsd-tech&m=171817275920057&w=2

                                      (Wherein Theo de Raadt of OpenBSD responds to someone proposing 10,000 kernel changes due to A"I" identifying possible bugs; this was circa 2024. Thankfully, the individual who proposed such changes? Appears to have not updated their GitHub fork in the ensuing years.)
                                      1 Reply Last reply
                                      0
                                      • linear@nya.socialL linear@nya.social
                                        @cwebber@social.coop we need microkernel based operating systems with capability-based security enforcement, isolation of components from each other as a baseline assumption, and formal verification of the whole thing at both the code and spec level, and we need all of this quite urgently
                                        teajaygrey@snac.bsd.cafeT This user is from outside of this forum
                                        teajaygrey@snac.bsd.cafeT This user is from outside of this forum
                                        teajaygrey@snac.bsd.cafe
                                        wrote last edited by
                                        #41
                                        (se)L4 I think fits such criteria? It is already widely deployed (e.g. Apple's Secure Enclave).

                                        Problematically? I don't think any of the L4 kernels were "self hosting" last I checked? Maybe that has changed.

                                        BS such as that, would have received failing grades in the 1980s.

                                        Alas, we live in a different era now, where cross compiling is de rigueur even if it is awful in practice.

                                        If I had a wish granting fairy or whatever? I would totally task someone(s) to make the L4 microkernel family self-hosting, so it doesn't need a Linux to boot strap.

                                        CC: @cwebber@social.coop
                                        linear@nya.socialL 1 Reply Last reply
                                        0
                                        • teajaygrey@snac.bsd.cafeT teajaygrey@snac.bsd.cafe
                                          (se)L4 I think fits such criteria? It is already widely deployed (e.g. Apple's Secure Enclave).

                                          Problematically? I don't think any of the L4 kernels were "self hosting" last I checked? Maybe that has changed.

                                          BS such as that, would have received failing grades in the 1980s.

                                          Alas, we live in a different era now, where cross compiling is de rigueur even if it is awful in practice.

                                          If I had a wish granting fairy or whatever? I would totally task someone(s) to make the L4 microkernel family self-hosting, so it doesn't need a Linux to boot strap.

                                          CC: @cwebber@social.coop
                                          linear@nya.socialL This user is from outside of this forum
                                          linear@nya.socialL This user is from outside of this forum
                                          linear@nya.social
                                          wrote last edited by
                                          #42
                                          @teajaygrey@snac.bsd.cafe @cwebber@social.coop yes, see further downthread
                                          linear@nya.socialL 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups