Linear Address Spaces: Unsafe at any speed [article]

By: Brendan (btrotter.delete@this.gmail.com), July 1, 2022 1:24 pm
Room: Moderated Discussions
Hi,

dmcq (dmcq.delete@this.fano.co.uk) on July 1, 2022 6:06 am wrote:
> Brendan (btrotter.delete@this.gmail.com) on June 30, 2022 3:52 pm wrote:
> > dmcq (dmcq.delete@this.fano.co.uk) on June 30, 2022 11:20 am wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on June 30, 2022 11:09 am wrote:
> > > > Kester L (nobody.delete@this.nothing.com) on June 29, 2022 1:49 pm wrote:
> > > > > https://queue.acm.org/detail.cfm?id=3534854
> > > > >
> > > > >

> > > > > The linear address space as a concept is unsafe at any speed, and it badly needs mandatory CHERI
> > > > > seat belts. But even better would be to get rid of linear address spaces entirely and go back to
> > > > > the future, as successfully implemented in the Rational R1000 computer 30-plus years ago.
> > > > >

> > > > >
> > > > > Your thoughts on this article? I was under the impression that a lot of the 80s attempts
> > > > > at capability machines (or really, anything that wasn't trying to be a glorified PDP-11)
> > > > > floundered because of performance and cost issues (i.e. the Intel i432).
> > > >
> > > > My thoughts on the article itself is that it has a strong "marketing" smell. Let's
> > > > ignore the article's words and focus on the "safety vs. performance" question.
> > > >
> > > > You can split it into 2 very different problems:
> > > >
> > > > a) Reducing the amount of developer effort required to create correct and efficient software
> > > >
> > > > b) Maximizing the efficiency (performance per watt per $) for normal
> > > > users (not software developers) executing correct software
> > > >
> > > > For the former, the latter is mostly irrelevant. E.g. if you're running a specially instrumented
> > > > "debug version" (with lots of extra checks enabled) in a special environment (e.g. under valgrind)
> > > > and its 200 times slower, most developers simply won't have a reason to care.
> > > >
> > > > For the latter, the former is mostly irrelevant. The only thing you actually care about is protecting
> > > > everything (kernel, other processes) from untrusted (potentially deliberately malicious) code;
> > > > and for this you only care about the boundaries between "inside the process" and "outside the
> > > > process" (and you do not care about anything inside the process trashing anything else in the
> > > > process). For modern systems this is invariably done with paravirtualization - a process runs
> > > > inside its own virtual machine (with virtual memory, virtual CPUs/threads, highly abstracted virtual
> > > > IO like "open()" and "write()" instead of anything resembling physical devices).
> > > >
> > > > You can't/shouldn't combine these problems; because as soon as you do you're forcing a compromise (worse
> > > > safety for the former and/or worse efficiency for the latter). Anyone who doesn't seem to understand this
> > > > (e.g. CHERI designers) are trying to solve a problem without understanding the nature of the problem.
> > > >
> > > > However; there is some overlap. Good software developers try to create correct and efficient software (and
> > > > not just correct software). Anything intended to reduce the effort needed to create correct and efficient
> > > > software should/must be able to handle all the tricks that
> > > > could be used to improve the efficiency of correct
> > > > code. This includes using raw assembly language for highly specialized pieces; and self-modifying code and
> > > > run-time code generation; and improving locality by using a single memory allocation for several objects of
> > > > different types; and improving SIMD performance by using "structure
> > > > of arrays" instead of "array of structures/objects";
> > > > and recognizing that sometimes the same object has different types in different places (a pointer/reference
> > > > to a structure/object that is used as a raw integer when calculating a hash, a "big integer" in one place
> > > > that is an array of unsigned integers in another place, multiple inheritance, etc).
> > >
> > > I think your idea of 'normal users' needs a bit of refining.
> >
> > For "for normal users (not software developers)" I mean the 6+ billion people on the planet that
> > use computers without ever writing a single line of code themselves, without knowing how a computer
> > works, and without even knowing they're using a computer in some cases (e.g. driving a car).
> >
> > > I'm not sure there's many people left
> > > who a company would pay after they're allowed to do the sort of tricks you're talking about. Do you
> > > mean ners=ds who are just developing a program for themselves and waste their lives to no profit?
> >
> > All of those tricks happen in every computer I ever saw. The Linux kernel alone does most
> > of them (not sure if eBPF has advanced to the "run-time generated code" stage yet).
>
> 'Good developers try'. Well I can't argue with that. But do they succeed? And the Linux kernel has
> done a good job removing the masses of asm macros that were originally put in. The things you talk
> about are things that are being done by improving the language so making the faciities available
> in a less buggy way. Someone going around by hand changing an array of struct to a number of different
> arrays by hand is someone who is desperate.

Can you think of a single compiler or language that supports automatically converting "array of structures" into "structure of arrays" (and auto-detecting when it would be beneficial to do so)?

The fact is that how much a compiler can optimize is very limited (extremely good at trivial micro-optimizations; but extremely bad at fixing poor design decisions).

> They'll spend a lot of time on it and generate lots of
> bugs and yes it would be much better if there was software support in the language they were using
> instead. The only people who'd normally do that by hand are people with time to waste and are not
> concerned about bugs. Not good developers. You're mixing up desperation and desire.

No, you've fabricated a "premature optimization is always evil with no exceptions at all ever" straw-man and ignored what I'm saying.

Whether it's done by hand or done by compiler (or done by a shared library developer, or done by a a language's run-time, or ..) is irrelevant; and whether it's only done for a tiny niche (a performance critical 0.001% of software) or it's ubiquitous is irrelevant. In all cases you still want some assurance that it's correct before release (and don't care much about efficiency during pre-release testing), and still want efficiency after its released (and don't care much about assurances it's correct after you've already been assured). Any compromise between pre-release testing and post-release efficiency (e.g. CHERI) is undeniably inferior (for pre-release testing, or for post-release efficiency, or for both).

- Brendan
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Linear Address Spaces: Unsafe at any speed [article]Kester L2022/06/29 01:49 PM
  Linear Address Spaces: Unsafe at any speed [article]Rayla2022/06/29 02:14 PM
    Linear Address Spaces: Unsafe at any speed [article]Kester L2022/06/29 02:43 PM
      Not just worse-is-betterMark Roulo2022/06/29 03:21 PM
        Not just worse-is-better---2022/06/29 07:07 PM
  Linear Address Spaces: Unsafe at any speed [article]2022/06/30 12:08 AM
    Linear Address Spaces: Unsafe at any speed [article]Groo2022/06/30 12:56 PM
      Linear Address Spaces: Unsafe at any speed [article]Michael S2022/06/30 02:17 PM
  Linear Address Spaces: Unsafe at any speed [article]Eric Fink2022/06/30 01:43 AM
  Linear Address Spaces: Unsafe at any speed [article]dmcq2022/06/30 03:17 AM
  Linear Address Spaces: Unsafe at any speed [article]Adrian2022/06/30 05:36 AM
    Linear Address Spaces: Unsafe at any speed [article]anonymou52022/06/30 07:28 AM
      Linear Address Spaces: Unsafe at any speed [article]Anon42022/06/30 04:37 PM
        Linear Address Spaces: Unsafe at any speed [article]anonymou52022/06/30 06:19 PM
          Linear Address Spaces: Unsafe at any speed [article]dmcq2022/07/01 04:16 AM
            Linear Address Spaces: Unsafe at any speed [article]anonymou52022/07/01 05:40 AM
              Linear Address Spaces: Unsafe at any speed [article]dmcq2022/07/01 06:11 AM
                Linear Address Spaces: Unsafe at any speed [article]anonymou52022/07/01 08:09 AM
              Linear Address Spaces: Unsafe at any speed [article]dmcq2022/07/01 06:11 AM
                Why the duplicates?dmcq2022/07/01 06:18 AM
              Linear Address Spaces: Unsafe at any speed [article]2022/07/01 10:41 PM
    Linear Address Spaces: Unsafe at any speed [article]Foo_2022/06/30 07:43 AM
      Fragmentation: Both Size and LifetimeMark Roulo2022/06/30 08:25 AM
        Fragmentation: Both Size and Lifetime2022/06/30 10:09 AM
          Fragmentation: Both Size and Lifetimedmcq2022/06/30 11:12 AM
          Fragmentation: Both Size and LifetimeBrendan2022/06/30 04:08 PM
            Fragmentation: Both Size and Lifetime2022/07/02 03:12 AM
              Fragmentation: Both Size and LifetimeBrendan2022/07/02 01:56 PM
                Fragmentation: Both Size and Lifetime2022/07/04 05:34 AM
                  Fragmentation: Both Size and LifetimeBrendan2022/07/04 06:33 AM
                    Fragmentation: Both Size and Lifetime2022/07/04 07:35 AM
                      Fragmentation: Both Size and LifetimeBrendan2022/07/04 04:21 PM
                    Atom is just living at the Dunning-Krueger peakHeikki Kultala2022/07/04 09:26 AM
                      Atom is just living at the Dunning-Krueger peak2022/07/04 09:57 AM
      Linear Address Spaces: Unsafe at any speed [article]Adrian2022/06/30 08:31 AM
        Linear Address Spaces: Unsafe at any speed [article]Foo_2022/06/30 09:07 AM
          Linear Address Spaces: Unsafe at any speed [article]Adrian2022/06/30 09:43 AM
            Linear Address Spaces: Unsafe at any speed [article]Foo_2022/07/01 03:21 AM
              Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/01 09:58 PM
                Linear Address Spaces: Unsafe at any speed [article]Foo_2022/07/03 02:45 AM
                  Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/03 10:04 PM
                    Linear Address Spaces: Unsafe at any speed [article]ananon2022/07/04 02:35 AM
                    Linear Address Spaces: Unsafe at any speed [article]Foo_2022/07/04 03:11 AM
                      Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/05 01:36 AM
                    Linear Address Spaces: Unsafe at any speed [article]2022/07/04 04:18 AM
                    Linear Address Spaces: Unsafe at any speed [article]TAG2022/07/04 07:50 AM
                    Linear Address Spaces: Unsafe at any speed [article]Brendan2022/07/04 04:54 PM
                      Linear Address Spaces: Unsafe at any speed [article]Brendan2022/07/04 05:05 PM
                      Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/05 02:18 AM
                        Linear Address Spaces: Unsafe at any speed [article]Brendan2022/07/06 05:16 PM
                          Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/07 12:33 AM
        Linear Address Spaces: Unsafe at any speed [article]2022/06/30 10:40 AM
    Linear Address Spaces: Unsafe at any speed [article]---2022/06/30 08:28 AM
      Linear Address Spaces: Unsafe at any speed [article]Michael S2022/06/30 01:00 PM
    Linear Address Spaces: Unsafe at any speed [article]Jörn Engel2022/06/30 05:34 PM
      Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/01 12:55 AM
        Sorry, typo correctionAdrian2022/07/01 01:04 AM
        Linear Address Spaces: Unsafe at any speed [article]2022/07/01 04:01 AM
          Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/01 11:00 PM
            Linear Address Spaces: Unsafe at any speed [article]rwessel2022/07/02 07:16 AM
        Linear Address Spaces: Unsafe at any speed [article]Jörn Engel2022/07/01 09:40 AM
          Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/01 11:15 PM
  Linear Address Spaces: Unsafe at any speed [article]Brendan2022/06/30 11:09 AM
    Linear Address Spaces: Unsafe at any speed [article]dmcq2022/06/30 11:20 AM
      Linear Address Spaces: Unsafe at any speed [article]Brendan2022/06/30 03:52 PM
        Linear Address Spaces: Unsafe at any speed [article]dmcq2022/07/01 06:06 AM
          Linear Address Spaces: Unsafe at any speed [article]Brendan2022/07/01 01:24 PM
            Linear Address Spaces: Unsafe at any speed [article]rwessel2022/07/01 08:55 PM
  Linear Address Spaces - Free lunch?Björn Ragnar Björnsson2022/07/02 06:44 PM
    Linear Address Spaces - Free lunch?dmcq2022/07/03 04:30 AM
      Linear Address Spaces - Free lunch?Björn Ragnar Björnsson2022/07/03 04:50 PM
  Linear Address Spaces: Unsafe at any speed [article]Paul A. Clayton2022/07/18 07:49 AM
    Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/18 10:21 AM
      Linear Address Spaces: Unsafe at any speed [article]Brendan2022/07/18 03:11 PM
        Linear Address Spaces: Unsafe at any speed [article]anon22022/07/18 04:54 PM
          Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/18 10:22 PM
            Linear Address Spaces: Unsafe at any speed [article]Michael S2022/07/19 01:00 AM
              Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/19 05:50 AM
        Linear Address Spaces: Unsafe at any speed [article]Adrian2022/07/18 11:02 PM
          Linear Address Spaces: Unsafe at any speed [article]Brendan2022/07/19 08:29 PM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell avocado?