10 ms·

Guix Reduces Bootstrap Seed by Half

284 points by stargrave 7y ago

m4r35n357 7y ago
Fascinating stuff!
yourapostasy 7y ago
Dayum...just how far do the turtles go? Even when they reach full source bootstrap, are they ruminating over concerns about the firmware/BIOS? If those concerns are addressed with an equivalent bootstrap-seeded coreboot, then are there concerns with the silicon? I never even thought someone was taking this level of security seriously enough to actually put the effort into it, but I'm extremely glad to see they are. I can easily see high-security DevOps builds of secrets management stores driven by such a bootstrapped Guix to nearly indefinitely satisfy the provenance-type questions from the regulatory compliance teams I work with.
- secraetomani 7y ago
  > secrets management stores Maybe starting from something like an Arduino is a better route for that.
  - everlastingfan 7y ago
    Is Arduino firmware open? Are the PCB and chip designs open?
    - secraetomani 7y ago
      Even if not, way less stuff hiding in there than in your average computer. Remember that these days, Intel CPUs have web-servers embedded in them.
    - kragen 7y ago
      Yes, yes, and no. Also the compilation toolchain depends on GCC. Open silicon designs aren't enough; you need to be able to verify that the design correctly describes the physical hardware you are actually using.
- z29LiTp5qUC30n 7y ago
  well if you look at #bootstrappable's logs it looks like they are planning on building custom hardware out of TTL chips to eliminate all software/bios/firmware from the bootstrap; which when combined with libresilicon means no place for any attacks to hide.
  - nwah1 7y ago
    Unless Dennis Ritchie or Ken Thompson placed a "trusting trust" attack in the original C compiler, since virtually all modern code was compiled by something that was once compiled by it. (Ken Thompson coined the term and knows how to do it.)
    - newnewpdro 7y ago
      That's the whole point of these projects - they're preventing that type of attack. If you implement your bootstrap C compiler entirely in machine code for instance, it doesn't matter if the "original C compiler" is compromised, since it's not being compiled.
    - pdw 7y ago
      To counter that, they're working on a bootstrap chain that starts with a tiny 500 byte hex editor and ends with a compiler that can build the GNU toolchain.
  - everlastingfan 7y ago
    Well there is when you design signals that play on the physical properties of the silicon and the silicon design is known, think Rowhammer. The next level of this is making permanent modifications to the silicon, e.g. using focused RF signals to change the properties of individual transistors. Relying on security through obscurity is bad, but you need some obscurity. Passwords and keyfiles are ultimately a form of security through obscurity.
  - jtl999 7y ago
    >building custom hardware out of TTL chips to eliminate all software/bios/firmware from the bootstrap I'd be curious to learn more about this.
- everlastingfan 7y ago
  It's turtles all the way down. I'm ruminating on the potential for "regular" electric signals to carry quantum information, that's the next aspect of security to consider with quantum around the corner. So don't worry, there are and will be bigger things to worry about.
- chungy 7y ago
  Malicious firmware concerns might be alleviated with cross-compilation. There might be an assumption that firmware inserting untrusted code only actually inserts trusted code of its native architecture, though even this is no guarantee.
- orblivion 7y ago
  If you're worried enough, I think there's some trick where you use multiple different C compilers made by different organizations to build (let's say) gcc. Then you use all those gccs to rebuild gcc in a deterministic way. If all of those rebuilt gccs are byte-for-byte the same, then either it's safe, or all of the initial compilers you used were in cahoots. Depending on who you pick to start, that's arguably very unlikely.
  - thfuran 7y ago
    >If all of those rebuilt gccs are byte-for-byte the same Isn't that pretty unlikely even if all the compilers are uncompromised?
    - delroth 7y ago
      No, that's what reproducible builds are all about: https://reproducible-builds.org/ https://reproducible-builds.org/ Debian is currently sitting at around 93% of packages being reproducibly built. NixOS is close to 99% of the minimal install image set (https://r13y.com/ https://r13y.com/).
      - tjoff 7y ago
        Reproducible builds don't mean compiling with different compilers, or even different versions of the same compiler, to result in the same binary.
        comex 7y ago
        That's why you don't compare the GCC binaries built by different compilers. Instead, you use each of those GCC binaries (which may use different machine code but should implement the exact same functionality) to build another GCC, and you compare those binaries. That should result in identical binaries as long as GCC: - is deterministic, - does not invoke undefined behavior, and - was correctly compiled by the original compilers.
- mikelevins 7y ago
  There are researchers considering things all the way down to silicon. I worked on a contract for about a year and a half on a subproject of the research program described in this New York Times article: https://www.nytimes.com/2012/10/30/science/rethinking-the-computer-at-80.html The project I consulted on was an attempt at a comprehensive system design that replaced everything all the way down to and including the hardware. System software was written in Haskell and in a newly-designed language called Breeze that offered both static and dynamic typing. The dynamic typing was supported by tagged hardware with specialized instructions (that effort included Tom Knight, one of the original designers of Lisp Machines). The organizing principle was that every piece of code and data was owned by a well-defined system entity with well-defined permissions that were proven correct both statically and dynamically. For example, sending data to an endpoint that did not have the required authorization to receive it was a type error. The thinking was that the state of the art is so broken (from the point of view of data integrity and security) that it's necessary to start from scratch. The overarching project name, appropriately enough, was "Clean Slate". I don't know what they're up to now.
xvilka 7y ago
I wonder if they target RISC-V platform too. Or OpenPOWER (the case of Raptor Engineering).
- chungy 7y ago
  Seems to be only i686 and x86_64. It's a pretty small project all things considered, but I'm sure a porting effort would be appreciated.
  - tremon 7y ago
    from the article (default blurb added to the end of every blog post): it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.
    - Fnoord 7y ago
      FTA: > The Guix development branch we just merged introduces a reduced binary seed bootstrap for x86_64 and i686
- kragen 7y ago
  It isn't necessary for the original bootstrap seed to run on many platforms. Just at least one trustworthy one. From there we can cross-compile everything else.
  - xvilka 7y ago
    And x86 is the least trustworthy one. With all these hidden modes of execution from Intel and AMD...
- equalunique 7y ago
  The first step would be getting Mes[0] built for RISC-V / OpenPOWER. Want to give it a shot and let Guix devs know how it went? [0] https://www.gnu.org/software/mes/ https://www.gnu.org/software/mes/
atian 7y ago
Yeah startups are gonna need another way of financing fast if seed amounts keep going down. If anything the startup age is over on the west coast.
- moomin 7y ago
  When you only read the headline.
reacweb 7y ago
I do not understand. When I have started on linux, 25 floppies were enough for a full installation (including latex and X) on my big HD (120MB). How a striped down version of bash, coreutils&co and guile could require 120MB ?
- asutekku 7y ago
  There’s a bunch of more stuff available on it nowadays.
  - giancarlostoro 7y ago
    And lots of hardware drivers, for lots of potential hardware I assume as well. I bet Gentoo could be setup to be entirely minimal by removing uneeded things from the distro, not sure if it's known for that.
- secraetomani 7y ago
  And a typical install of Windows 95 was 55 MB. Which included a bunch of images, sounds, ...
  - oblio 7y ago
    > images 800x600 16 bit backgrounds and 16x16 16 bit icons... > sounds MIDI sounds... We're not living in 1995, anymore.
    - secraetomani 7y ago
      What, your C compiler includes high-definition image and audio files? What times to be alive...
      - oblio 7y ago
        He was comparing Win 95 to modern software. Also, as far as I know even stuff like compilers (if they want to support Unicode fully) have to pull in dependencies like ICU, which because of its symbol DB weighs about 30MB. That's another problem Win 95-era software didn't have to care about...
deleted 7y ago
[deleted]
gglitch 7y ago
Neat - MES Scheme is apparently named after Alan Kay's description of Lisp as the Maxwell's equations of software. https://gitlab.com/janneke/mes https://gitlab.com/janneke/mes
- equalunique 7y ago
  That information is also given on the GNU page: https://www.gnu.org/software/mes/ https://www.gnu.org/software/mes/
antoineMoPa 7y ago
Anyone using Guix in production? (Anyone using Guix?)
- uncletaco 7y ago
  Not in "production" but I use it on my personal laptop and desktop. I wanted to learn a scheme and I figured what better way than to dedicate all of my home computing time to configuring a system and crying myself to sleep trying to build firefox on it.
  - robto 7y ago
    If you get firefox working, please share your definition on the nonguix[0] repo. Lack of Firefox is what is currently holding me back from installing Guix on hardware. I don't know anything about package building, but I'd be happy to help collaborate if you need it. [0]https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
    - uncletaco 7y ago
      So two things: 1. I believe icecat is going to update pretty soon to version 68 to track with the latest esr, so perhaps in a week or so please check the main channel for an icecat version that should work with most, if not all, up to date extensions. 2. If I do get Firefox built and packaged then I’ll be more than happy to add it to the nonguix channel. Though I’m strongly considering just creating an unofficial icecat that keeps up with the latest version of Firefox like icecat on windows does. We’ll see what happens after these tears dry. Icecat is really just a set of scripts to strip out branding from Firefox and packages it with gnu shit, though the gnuzilla project provides the esr version for convenience.
    - dannyobrien 7y ago
      I use x11docker to run a recent firefox on Guix for now. https://github.com/mviereck/x11docker https://github.com/mviereck/x11docker
- garmaine 7y ago
archi42 7y ago
So the only trust anchor remaining are the kernel and the hardware. It seems an attacker has to build a kernel module that detects the bootstrapping process and injects the (self-replicating!) bad code while building the final gcc. I like the work, but I still don't think the kind of attack mitigated here is practical. OTOH it's nice to have the option (if I was to build/publish my own distribution I would use this as my trust anchor, plus some ancient hardware and Linux 2.4 CDs to build my own bootstrap environment; though as a random guy on the internet I am probably less trustable than e.g. the Debian people).

284 points by stargrave 7y ago

Fascinating stuff!

Dayum...just how far do the turtles go? Even when they reach full source bootstrap, are they ruminating over concerns about the firmware/BIOS? If those concerns are addressed with an equivalent bootstrap-seeded coreboot, then are there concerns with the silicon? I never even thought someone was taking this level of security seriously enough to actually put the effort into it, but I'm extremely glad to see they are. I can easily see high-security DevOps builds of secrets management stores driven by such a bootstrapped Guix to nearly indefinitely satisfy the provenance-type questions from the regulatory compliance teams I work with.

secraetomani 7y ago
> secrets management stores Maybe starting from something like an Arduino is a better route for that.
- everlastingfan 7y ago
  Is Arduino firmware open? Are the PCB and chip designs open?
  - secraetomani 7y ago
    Even if not, way less stuff hiding in there than in your average computer. Remember that these days, Intel CPUs have web-servers embedded in them.
  - kragen 7y ago
    Yes, yes, and no. Also the compilation toolchain depends on GCC. Open silicon designs aren't enough; you need to be able to verify that the design correctly describes the physical hardware you are actually using.
z29LiTp5qUC30n 7y ago
well if you look at #bootstrappable's logs it looks like they are planning on building custom hardware out of TTL chips to eliminate all software/bios/firmware from the bootstrap; which when combined with libresilicon means no place for any attacks to hide.
- nwah1 7y ago
  Unless Dennis Ritchie or Ken Thompson placed a "trusting trust" attack in the original C compiler, since virtually all modern code was compiled by something that was once compiled by it. (Ken Thompson coined the term and knows how to do it.)
  - newnewpdro 7y ago
    That's the whole point of these projects - they're preventing that type of attack. If you implement your bootstrap C compiler entirely in machine code for instance, it doesn't matter if the "original C compiler" is compromised, since it's not being compiled.
  - pdw 7y ago
    To counter that, they're working on a bootstrap chain that starts with a tiny 500 byte hex editor and ends with a compiler that can build the GNU toolchain.
- everlastingfan 7y ago
  Well there is when you design signals that play on the physical properties of the silicon and the silicon design is known, think Rowhammer. The next level of this is making permanent modifications to the silicon, e.g. using focused RF signals to change the properties of individual transistors. Relying on security through obscurity is bad, but you need some obscurity. Passwords and keyfiles are ultimately a form of security through obscurity.
- jtl999 7y ago
  >building custom hardware out of TTL chips to eliminate all software/bios/firmware from the bootstrap I'd be curious to learn more about this.
everlastingfan 7y ago
It's turtles all the way down. I'm ruminating on the potential for "regular" electric signals to carry quantum information, that's the next aspect of security to consider with quantum around the corner. So don't worry, there are and will be bigger things to worry about.
chungy 7y ago
Malicious firmware concerns might be alleviated with cross-compilation. There might be an assumption that firmware inserting untrusted code only actually inserts trusted code of its native architecture, though even this is no guarantee.
orblivion 7y ago
If you're worried enough, I think there's some trick where you use multiple different C compilers made by different organizations to build (let's say) gcc. Then you use all those gccs to rebuild gcc in a deterministic way. If all of those rebuilt gccs are byte-for-byte the same, then either it's safe, or all of the initial compilers you used were in cahoots. Depending on who you pick to start, that's arguably very unlikely.
- thfuran 7y ago
  >If all of those rebuilt gccs are byte-for-byte the same Isn't that pretty unlikely even if all the compilers are uncompromised?
  - delroth 7y ago
    No, that's what reproducible builds are all about: https://reproducible-builds.org/ https://reproducible-builds.org/ Debian is currently sitting at around 93% of packages being reproducibly built. NixOS is close to 99% of the minimal install image set (https://r13y.com/ https://r13y.com/).
    - tjoff 7y ago
      Reproducible builds don't mean compiling with different compilers, or even different versions of the same compiler, to result in the same binary.
      - comex 7y ago
        That's why you don't compare the GCC binaries built by different compilers. Instead, you use each of those GCC binaries (which may use different machine code but should implement the exact same functionality) to build another GCC, and you compare those binaries. That should result in identical binaries as long as GCC: - is deterministic, - does not invoke undefined behavior, and - was correctly compiled by the original compilers.
mikelevins 7y ago
There are researchers considering things all the way down to silicon. I worked on a contract for about a year and a half on a subproject of the research program described in this New York Times article: https://www.nytimes.com/2012/10/30/science/rethinking-the-computer-at-80.html The project I consulted on was an attempt at a comprehensive system design that replaced everything all the way down to and including the hardware. System software was written in Haskell and in a newly-designed language called Breeze that offered both static and dynamic typing. The dynamic typing was supported by tagged hardware with specialized instructions (that effort included Tom Knight, one of the original designers of Lisp Machines). The organizing principle was that every piece of code and data was owned by a well-defined system entity with well-defined permissions that were proven correct both statically and dynamically. For example, sending data to an endpoint that did not have the required authorization to receive it was a type error. The thinking was that the state of the art is so broken (from the point of view of data integrity and security) that it's necessary to start from scratch. The overarching project name, appropriately enough, was "Clean Slate". I don't know what they're up to now.

xvilka 7y ago

I wonder if they target RISC-V platform too. Or OpenPOWER (the case of Raptor Engineering).

chungy 7y ago
Seems to be only i686 and x86_64. It's a pretty small project all things considered, but I'm sure a porting effort would be appreciated.
- tremon 7y ago
  from the article (default blurb added to the end of every blog post): it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.
  - Fnoord 7y ago
    FTA: > The Guix development branch we just merged introduces a reduced binary seed bootstrap for x86_64 and i686
kragen 7y ago
It isn't necessary for the original bootstrap seed to run on many platforms. Just at least one trustworthy one. From there we can cross-compile everything else.
- xvilka 7y ago
  And x86 is the least trustworthy one. With all these hidden modes of execution from Intel and AMD...
equalunique 7y ago
The first step would be getting Mes[0] built for RISC-V / OpenPOWER. Want to give it a shot and let Guix devs know how it went? [0] https://www.gnu.org/software/mes/ https://www.gnu.org/software/mes/

atian 7y ago

Yeah startups are gonna need another way of financing fast if seed amounts keep going down. If anything the startup age is over on the west coast.

moomin 7y ago
When you only read the headline.

reacweb 7y ago

I do not understand. When I have started on linux, 25 floppies were enough for a full installation (including latex and X) on my big HD (120MB). How a striped down version of bash, coreutils&co and guile could require 120MB ?

asutekku 7y ago
There’s a bunch of more stuff available on it nowadays.
- giancarlostoro 7y ago
  And lots of hardware drivers, for lots of potential hardware I assume as well. I bet Gentoo could be setup to be entirely minimal by removing uneeded things from the distro, not sure if it's known for that.
secraetomani 7y ago
And a typical install of Windows 95 was 55 MB. Which included a bunch of images, sounds, ...
- oblio 7y ago
  > images 800x600 16 bit backgrounds and 16x16 16 bit icons... > sounds MIDI sounds... We're not living in 1995, anymore.
  - secraetomani 7y ago
    What, your C compiler includes high-definition image and audio files? What times to be alive...
    - oblio 7y ago
      He was comparing Win 95 to modern software. Also, as far as I know even stuff like compilers (if they want to support Unicode fully) have to pull in dependencies like ICU, which because of its symbol DB weighs about 30MB. That's another problem Win 95-era software didn't have to care about...

deleted 7y ago

[deleted]

gglitch 7y ago

Neat - MES Scheme is apparently named after Alan Kay's description of Lisp as the Maxwell's equations of software. https://gitlab.com/janneke/mes https://gitlab.com/janneke/mes

equalunique 7y ago
That information is also given on the GNU page: https://www.gnu.org/software/mes/ https://www.gnu.org/software/mes/

antoineMoPa 7y ago

Anyone using Guix in production? (Anyone using Guix?)

uncletaco 7y ago
Not in "production" but I use it on my personal laptop and desktop. I wanted to learn a scheme and I figured what better way than to dedicate all of my home computing time to configuring a system and crying myself to sleep trying to build firefox on it.
- robto 7y ago
  If you get firefox working, please share your definition on the nonguix[0] repo. Lack of Firefox is what is currently holding me back from installing Guix on hardware. I don't know anything about package building, but I'd be happy to help collaborate if you need it. [0]https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
  - uncletaco 7y ago
    So two things: 1. I believe icecat is going to update pretty soon to version 68 to track with the latest esr, so perhaps in a week or so please check the main channel for an icecat version that should work with most, if not all, up to date extensions. 2. If I do get Firefox built and packaged then I’ll be more than happy to add it to the nonguix channel. Though I’m strongly considering just creating an unofficial icecat that keeps up with the latest version of Firefox like icecat on windows does. We’ll see what happens after these tears dry. Icecat is really just a set of scripts to strip out branding from Firefox and packages it with gnu shit, though the gnuzilla project provides the esr version for convenience.
  - dannyobrien 7y ago
    I use x11docker to run a recent firefox on Guix for now. https://github.com/mviereck/x11docker https://github.com/mviereck/x11docker
garmaine 7y ago

archi42 7y ago

So the only trust anchor remaining are the kernel and the hardware. It seems an attacker has to build a kernel module that detects the bootstrapping process and injects the (self-replicating!) bad code while building the final gcc. I like the work, but I still don't think the kind of attack mitigated here is practical. OTOH it's nice to have the option (if I was to build/publish my own distribution I would use this as my trust anchor, plus some ancient hardware and Linux 2.4 CDs to build my own bootstrap environment; though as a random guy on the internet I am probably less trustable than e.g. the Debian people).