Hi,

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).

- Brendan