1. 26

  2. 9

    This throws away reproducible builds… Does this damage the idea of what you test is what you ship? Or is it increasing reliability by flushing out order problems.

    1. 5

      Yes, if there are bugs due to order (and there were), you won’t find them by always shipping the same order.

      1. 1

        I read this response as semi sarcastic (which is deserved even if that wasn’t intended). The way I worded the original statement was pretty poor because we know it does all of the above. I mainly intended to start some discussion.

        Rereading the notes, the ram disk build isn’t randomized so its clearly a flag anyway.

        1. 2

          People have been complaining that randomness makes debugging impossible for years, whether that be ASLR, or malloc, or even arc4random. Nevertheless, we have found ways to cope. So I think the concern is a little overwrought. The OpenBSD experience has been that in the long run it only ever makes software more reliable.

          Shipping what you test is merely a means to an end, delivering reliable software. It’s not an end in itself.

      2. 4

        No more than depending on a build id or a timestamp; both of which can be worked around by arranging to pass them in to the build. In this case a PRNG seed could be used to make a build reproducible when you need one of those.

        1. 2

          Perhaps some from column A and some from column B, in practice. I still think I would prefer reproducibility.

          1. 2

            Maybe pseudorandomness based on some seed? Then it would be “random” but also reproducible.

          2. 1

            Could do a non-random and random build. If there’s a problem, check it against non-random build to see if it’s the randomness. Then go from there with a bug report.

          3. 5

            Well, no kidding. Once you have randomized one thing, you should look at every part of your systems to determine if you can cost-effectively randomize them. That was step 2 in my obfuscation recommendation:


            I ended at the microcode, control/data synthesis, and gate characteristics in my studies of where to stop. I don’t know analog or RF so can’t go further down. This is a common cheat I use to find more techniques that will end up at conferences years later: take current Effect/Technique involved in Attribute or Situation; imagine as many of those as possible with same values you already know; go through each to filter in sanity-check style; examine remainder for potential risk or utility to prioritize. Then, come up with minimum way to achieve that goal in high priority. That’s how I noticed linker-oriented optimization many years ago after studying address and other obfuscation. It was a simpler find that just required me to name off each component in the build process along with word “randomization” and see if that made sense. Much like the Google searches trying to filter down to whats new and useful selectively modifying words. I then did it for OS stack, protocols, and hardware. Apply X to everything without zeal. Keep changing X while prioritizing on what’s worked previously during evaluation process. Easiest way to discover all kinds of shit.

            There’s quite a bit of research funding for this if anyone wants to try to get paid doing it in FOSS under the banners of “Moving Target Defense,” “Automated Diversity,” and maybe “Automated Obfuscation.” Along those lines, the first I found for low-level randomization was Elena Barrantes randomizing ISA of running apps in 2003. Cutting edge last I checked on such methods was ASSIST with 1.5% runtime overhead.



            So, seriously, take whatever you people are doing now, try to think about it for every other class of component, produce a list, and then build based on cost-benefit analysis of time invested versus what it might stop. Just do this periodically instead of every day since you have code to write and other important stuff to do. :) SPIN had type-safe linking in 2001. High-assurance security was manually checking it before that. ASLR came out around 2001. Ideally, permutations involving linker randomness should’ve been obvious by 2002. This supports my hypothesis of this field having a serious siloing and knowledge transfer problem. Anyway, there’s a technique to reduce it a bit. Combine with Google using lots of quotations, - filters, and optionally “TCB” for best results.

            1. [Comment removed by author]

              1. 8

                With typical ASLR, you only change the base, but relative offsets are all the same. It’s pretty easy to leak the base address, via about 100 means, and then you know where every symbol is. If the symbols are random, learning where sys_open() lives doesn’t tell you where disable_all_the_security() lives. (of course, since the kernel itself is world readable in /bsd, there may be more work to do. :))

                1. 7

                  kASLR randomizes the start of the kernel code/text at boot.

                  This technique varies the order of the object files as input to the linker, which should randomize the symbols within the text segment.

                  1. 3

                    It’s a similar strategy; just applying the randomness to more locations.