By: dmcq (dmcq.delete@this.fano.co.uk), June 30, 2022 11:20 am
Room: Moderated Discussions
Brendan (btrotter.delete@this.gmail.com) on June 30, 2022 11:09 am wrote:
> Hi,
>
> Kester L (nobody.delete@this.nothing.com) on June 29, 2022 1:49 pm wrote:
> > https://queue.acm.org/detail.cfm?id=3534854
> >
> >
> >
> > 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).
>
> - Brendan
I think your idea of 'normal users' needs a bit of refining. 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?
> Hi,
>
> 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).
>
> - Brendan
I think your idea of 'normal users' needs a bit of refining. 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?
