....is love, sweet love. That's the only thing that there's just too little
of.

At least according to Hal David, and Burt Bacharach.

My original Concertina architecture was originally intended just to
illustrate how computers work, and then I decided to illustrate
almost every feature some computer somewhere ever had by throwing them
all in.

Concertina II was intended to be a bit more practical. But it wasn't
really designed primarily for commercial success.

I designed it to show what I would like to see - so it is still going
to have lots of features, if not _quite_ as many as the original
Concertina. IBM-format Decimal Floating Point. Character string
instructions. Cray-like vector instructions.

I threw in a block structure to allow pseudo-immediates, since I
agreed with Mitch that using immediates for constants is a good
idea with memory access being so slow these days. Even if the
way that made sense for me to implement them was one Mitch
quite reasonably found really awful.

And I also put in VLIW - based on the arguments in favor of the
Mill architecture, I felt that if being lightweight and avoiding
OoO but still being efficient is a good thing, then offering
this capability in a more conventional architecture, less
radically innovative than the Mill, might serve a purpose.

But none of this stuff is what people really want to see from
a new computer architecture. (In fact, they don't _want_ a
new computer architecture, they want to run their old Windows
programs in peace!)

What new improved capability _would_ have people beating
down the doors to get their hands on processors with a novel
architecture? To me, it's obvious. If somebody could
design a processor that would power computers that were
*much more secure* than today's computers, *that* is what
would be extremely attractive.

Is the problem really in the processor, though? Maybe the
problem is mostly in the software. Perhaps hardware outside
the processor - like having one hard disk read-only unless
a physical switch was turned to allow software to be installed
on drive C: - is what we need.

Mitch Alsup noted that on his design, there is no bit in the
status word that gets turned on to allow supervisor or privileged
or kernel mode; instead, program code allowed to run privileged
instructions is specified as such within the memory management
unit.

To me, it seemed like this approach had a fundamental problem,
although I'm sure Mitch figured out a way to deal with it.

Because you can always turn privileged mode off, but never on,
except through an interrupt or an interrupt-like mechanism
such as a supervisor call, when the computer is turned on, it
has to start from privileged mode. And memory management is
complicated, and needs to be set up before it can be used.

A workaround is to make 'raw' memory capable of running
privileged instructions, but then that means people who
don't want to bother with memory management don't have a
security mechanism.

So, while I felt his idea was useful, I would be tempted
to do things differently: have a privilege bit, but then
also have a feature that can be enabled that only allows
privileged code to run in code segments designated by the
memory descriptors given to the MMU.

Since the most insidious attack on a computer is to corrupt
its BIOS, or the boot sectors of its hard drive, a security
mechanism that could work when a computer is started up
would be attractive.

Modern microprocessors include the feature of executing
encrypted programs; the purpose of this is to allow
copy-protection schemes for things like movies and music
to work; the code is hidden from being disassembled, and
can't be tampered with or have its functionality duplicated.

This doesn't help security, though; a virus writer could
use the same public keys of the microprocessor maker
to hide parts of a virus from analysis. (But when something
is known to be a virus, and not an implementation of HDMI
encryption, the microprocessor maker will gladly decrypt
it for antivirus developers...)

In any case, this has inspired me to think of a feature to
add to Concertina II. Add a new kind of header block, which
must be the very first one, which contains an encrypted
checksum of the rest of the block - which must be valid for
the block to be allowed to execute. A mode exists where
only blocks with such a checksum can be executed.

The idea is to provide the following facilities:

Supply the computer with an encryption key.

Set the computer so that on bootup it is in the
mode only allowing execution of this checksummed code.

Have the computer add checksums to blocks, according
to an encryption key supplied when this is used, _not_
the one set inside the computer for validation, which
is only used for the purpose of validation.

With this:

The code to be executed is visible, and can be checked
to ensure it is the desired code;

A virus seeking to replace that code with its own can't
simply ask the computer to add checksums to its own
code.

A pin on the CPU will need to be used so that physical
access to the computer is required to change the
encryption/validation code it uses to a new one.

And to make replacing the BIOS with one with a new
encryption key for the checksums possible, the original
non-checksummed BIOS with which the machine is shipped
needs to be in ROM; the idea is that the Flash memory
used for updated BIOSes, which can be checksummed, can
be switched away from, and the mode requiring checksummed
code on bootup can be turned off, with physical access
to the machine, to allow a switchover to checksummed
code with a new key.

John Savard

Quadibloc wrote:

> ....is love, sweet love. That's the only thing that there's just too little
> of.

> At least according to Hal David, and Burt Bacharach.

A people will happily go to war when the Hope in Peace is worse.
MitchAlsup 12/13/2023

> My original Concertina architecture was originally intended just to
> illustrate how computers work, and then I decided to illustrate
> almost every feature some computer somewhere ever had by throwing them
> all in.

> Concertina II was intended to be a bit more practical. But it wasn't
> really designed primarily for commercial success.

> I designed it to show what I would like to see - so it is still going
> to have lots of features, if not _quite_ as many as the original
> Concertina. IBM-format Decimal Floating Point. Character string
> instructions. Cray-like vector instructions.

> I threw in a block structure to allow pseudo-immediates, since I
> agreed with Mitch that using immediates for constants is a good
> idea with memory access being so slow these days. Even if the
> way that made sense for me to implement them was one Mitch
> quite reasonably found really awful.

> And I also put in VLIW - based on the arguments in favor of the
> Mill architecture, I felt that if being lightweight and avoiding
> OoO but still being efficient is a good thing, then offering
> this capability in a more conventional architecture, less
> radically innovative than the Mill, might serve a purpose.

> But none of this stuff is what people really want to see from
> a new computer architecture. (In fact, they don't _want_ a
> new computer architecture, they want to run their old Windows
> programs in peace!)

Apparently, people to not want the interiors of their automobiles
to look like their computer desk either (based on sales).

> What new improved capability _would_ have people beating
> down the doors to get their hands on processors with a novel
> architecture? To me, it's obvious. If somebody could
> design a processor that would power computers that were
> *much more secure* than today's computers, *that* is what
> would be extremely attractive.

My 66000 is not sensitive to the vast majority of current attack
strategies {rowhammer, Spectré, Meltdown, RoP, buffer overflows,
...}.

> Is the problem really in the processor, though? Maybe the
> problem is mostly in the software. Perhaps hardware outside
> the processor - like having one hard disk read-only unless
> a physical switch was turned to allow software to be installed
> on drive C: - is what we need.

> Mitch Alsup noted that on his design, there is no bit in the
> status word that gets turned on to allow supervisor or privileged
> or kernel mode; instead, program code allowed to run privileged
> instructions is specified as such within the memory management
> unit.

> To me, it seemed like this approach had a fundamental problem,
> although I'm sure Mitch figured out a way to deal with it.

> Because you can always turn privileged mode off, but never on,
> except through an interrupt or an interrupt-like mechanism
> such as a supervisor call, when the computer is turned on, it
> has to start from privileged mode. And memory management is
> complicated, and needs to be set up before it can be used.

No, but there does need to be a couple of cache lines in ROM
that define the state of the core(s) after reset is removed.
This data will provide Root Pointers for the various privilege
levels, various IPs, and random other configuration data. The
core will still have to enumerate PCIe, find, configure, and
initialize DRAM, load boot device drivers, and load the initial
system image.

> A workaround is to make 'raw' memory capable of running
> privileged instructions, but then that means people who
> don't want to bother with memory management don't have a
> security mechanism.

Let them burn. Their impudence will get them in the end.

> So, while I felt his idea was useful, I would be tempted
> to do things differently: have a privilege bit, but then
> also have a feature that can be enabled that only allows
> privileged code to run in code segments designated by the
> memory descriptors given to the MMU.

My 66000, instead, gives each privilege level its own
virtual address space.

> Since the most insidious attack on a computer is to corrupt
> its BIOS, or the boot sectors of its hard drive, a security
> mechanism that could work when a computer is started up
> would be attractive.

My 66000 comes out of reset with its MMUs turned on, its
privilege stack setup, and its priority interrupt system
enabled. it uses this ROM MMU to direct L1 and L2 to provide
storage for HLL code with DRAM is being found, configured,
initialized and a pool of DRAM pages built.

> Modern microprocessors include the feature of executing
> encrypted programs; the purpose of this is to allow
> copy-protection schemes for things like movies and music
> to work; the code is hidden from being disassembled, and
> can't be tampered with or have its functionality duplicated.

My 66000 has a means by which an application (without privilege)
can request Guest OS services and not allow GuestOS to examine
its memory. We call these applications "Paranoid". Obviously
only a subset of GuestOS service Calls will work, but files
and sockets do. I/O Devices have access to application memory
that GuestOS does not.

This prevents GuestOS from reading keys or secrets from an
application rather than needing another mode (SEM, AMD-V, ...)
Of course application cannot access GuestOS memory it does
not even have visibility to GuestOS root pointer.
{Hint:: GuestOS and application do not NECESSARILY share
an address space TLB entries, ASIDs--yet GuestOS can access
non paranoid application virtual memory. -- No Global bit}

> This doesn't help security, though; a virus writer could
> use the same public keys of the microprocessor maker
> to hide parts of a virus from analysis. (But when something
> is known to be a virus, and not an implementation of HDMI
> encryption, the microprocessor maker will gladly decrypt
> it for antivirus developers...)

> In any case, this has inspired me to think of a feature to
> add to Concertina II. Add a new kind of header block, which
> must be the very first one, which contains an encrypted
> checksum of the rest of the block - which must be valid for
> the block to be allowed to execute. A mode exists where
> only blocks with such a checksum can be executed.

This is one reason you cannot allow writable and executable
in the same PTE. My 66000 HW checks this.

> The idea is to provide the following facilities:

> Supply the computer with an encryption key.

Maybe more like an infinite set of encryption keys.

> Set the computer so that on bootup it is in the
> mode only allowing execution of this checksummed code.

Easily done if it comes out of reset with its MMU turned on.

On Thu, 14 Dec 2023 18:34:10 +0000, MitchAlsup wrote:

> This is one reason you cannot allow writable and executable in the same
> PTE. My 66000 HW checks this.

This is a very sound principle.

Of course, computers must allow executable programs to be loaded into
memory from the disk, but that just means that, now, loader programs
need to include a call to the operating system to change the status of
the memory into which a program has been loaded.

So the effect of this elementary precaution is to break any legacy
programs that do JIT compilation, for example. So this interferes with
making the x86/x86-64 platform secure.

Which helps to remind me of a very important fact: while I mentioned
adding a very _minor_ security feature to Concertina II here, which
happens to make use of the block format of program code, to permit
making certain types of fine-grained security a bit more convenient...

what is the really _important_ security enhancement that computers need?

In my opinion, it's better, more effective, sandboxing of Web browsers,
E-mail clients, and other Internet-facing applications. And when I've
been previously thinking about this, I noticed that one class of
applications - which is not connected with most of the security risk -
stands in the way of using some possible mechanisms for this purpose.

A lot of computer games - a class of applications which typically
require access to the full computational power of the computer - also
are connected to the Internet, so that players can interact and can't
cheat because actual gameplay takes place on servers, while the game
clients take care of game graphics.

If it's just browsers and E-mail clients, having those run in a
"sandbox" that also has a lot less performance than the real computer
is not a problem.

Is the CPU even the place for sandboxing? A genuinely effective
sandbox would involve a physical separation between the protected
computer and the one connected to the Internet, after all. But that
isn't convenient...

John Savard

MitchAlsup wrote:
> Quadibloc wrote:
>
>> In any case, this has inspired me to think of a feature to
>> add to Concertina II. Add a new kind of header block, which
>> must be the very first one, which contains an encrypted
>> checksum of the rest of the block - which must be valid for
>> the block to be allowed to execute. A mode exists where
>> only blocks with such a checksum can be executed.
>
> This is one reason you cannot allow writable and executable
> in the same PTE. My 66000 HW checks this.

Not supporting RWE as a valid PTE permission won't stop anything.
It just means that on My66k an OS has to use trap and emulate
to a accomplish the same end result. All that does is make
certain things more expensive on that platform.

Whether to support RWE is a decision that should be left to the OS,
implemented through its privileging mechanisms and authorized
on a per-user or per-app basis for individual memory sections.

Quadibloc <quadibloc@servername.invalid> writes:
>On Thu, 14 Dec 2023 18:34:10 +0000, MitchAlsup wrote:
>
>> This is one reason you cannot allow writable and executable in the same
>> PTE. My 66000 HW checks this.
>
>This is a very sound principle.

Every modern translation table system from x86 through ARM have
at least one way to mark writable pages as no-execute. It's not a new feature.

The JIT folks have all adapted to this.

Quadibloc wrote:

> On Thu, 14 Dec 2023 18:34:10 +0000, MitchAlsup wrote:

>> This is one reason you cannot allow writable and executable in the same
>> PTE. My 66000 HW checks this.

> This is a very sound principle.

> Of course, computers must allow executable programs to be loaded into
> memory from the disk, but that just means that, now, loader programs
> need to include a call to the operating system to change the status of
> the memory into which a program has been loaded.

> So the effect of this elementary precaution is to break any legacy
> programs that do JIT compilation, for example. So this interferes with
> making the x86/x86-64 platform secure.

The JiTer is in a different address space and has access to the common
JiTpool with write permission. The JiTpool is executable in the applications
using JiT. The transition between address spaces is on the order of 10
cycles. This is VASTLY more secure than allowing malicious JiT user
write access to the JiTed instruction space.

> Which helps to remind me of a very important fact: while I mentioned
> adding a very _minor_ security feature to Concertina II here, which
> happens to make use of the block format of program code, to permit
> making certain types of fine-grained security a bit more convenient...

> what is the really _important_ security enhancement that computers need?

> In my opinion, it's better, more effective, sandboxing of Web browsers,
> E-mail clients, and other Internet-facing applications. And when I've
> been previously thinking about this, I noticed that one class of
> applications - which is not connected with most of the security risk -
> stands in the way of using some possible mechanisms for this purpose.

Make the sandbox a completely different virtual address space.

> A lot of computer games - a class of applications which typically
> require access to the full computational power of the computer - also
> are connected to the Internet, so that players can interact and can't
> cheat because actual gameplay takes place on servers, while the game
> clients take care of game graphics.

> If it's just browsers and E-mail clients, having those run in a
> "sandbox" that also has a lot less performance than the real computer
> is not a problem.

Not when a context switch is 10-cycles.

You see, that is the problem, context switch (to a different VAS) is
currently 1000 cycles and "all these performant issues arise". Those
performant issues vanish when context switch is 10-cycles (without
needing an excursion through the OS.).

> Is the CPU even the place for sandboxing? A genuinely effective
> sandbox would involve a physical separation between the protected
> computer and the one connected to the Internet, after all. But that
> isn't convenient...

With 10-cycle context switches, you can run the sandbox where those
cores are only provided indirect access to the internet through an
IPI-like mechanism (also 10-cycles).

When a real hard context switch remains 10-cycless, you an run the
secure sandbox under a different HyperVisor that provides no illusion
of internet access. Still 10-cycles.

> John Savard

On Fri, 15 Dec 2023 17:10:36 +0000, MitchAlsup wrote:
> Quadibloc wrote:

>> Is the CPU even the place for sandboxing? A genuinely effective sandbox
>> would involve a physical separation between the protected computer and
>> the one connected to the Internet, after all. But that isn't
>> convenient...
>
> With 10-cycle context switches, you can run the sandbox where those
> cores are only provided indirect access to the internet through an
> IPI-like mechanism (also 10-cycles).
>
> When a real hard context switch remains 10-cycless, you an run the
> secure sandbox under a different HyperVisor that provides no illusion of
> internet access. Still 10-cycles.

It's certainly true that if you can have faster context switches,
you can use context switches more often with less loss of performance.

One obvious mechanism that some old computers used was to have a
separate set of registers for the 'other' state, instead of saving
and restoring registers from memory. So, yes, we certainly know
how to do that.

To me, though, the problem is that of course you can have context A
and context B, but how do we make the untrusted context secure, so
that it doesn't just find some vulnerability somewhere that wasn't
anticipated to affect or spy on the privileged context?

It's in a different address space, because the MMU put it there? Great,
that _should_ work, but we've already had cases of malware surmounting
the barriers between virtual machines under a hypervisor, for example.

If using a *virtual machine* won't give you a secure sandbox, then I
despair of anything else giving you a secure sandbox on a single computer.

And, worse, even if one had a perfect secure sandbox, it wouldn't
completely solve the security problem. Because one of the things
that you use the Internet for is to download programs to run on
your "good" computer. So the sandbox runs JavaScript and stuff like
that, but there's still a link between it and the computer we
want to keep secure, so that stuff can be downloaded.

And the stuff that's downloaded can be corrupted - on the server,
or inside the sandbox where the bad things are locked up!

These meditations lead me to the conclusion that there's no
really simple solution that can easily be seen to be perfect.

To give computers even a fighting chance to be more secure, then,
it seems the result will have to be more like this:

- Even the "good" computer, that runs the programs that need its
full speed and power, will still need to run antivirus programs
and have mitigations. Perimiter security that does away with the
need for this is not possible.

- The Internet-facing computer needs to be made highly resistant
to being compromised. An old idea from the early Bell Electronic
Switching System seems to be what is appropriate here: this
computer should be physically unable to ever write to the memory
it uses for (primary) executable code, that is, the programs
that handle Internet access, its own local operating system, and
so on; instead, that computer's software gets loaded into its
memory by the "good" computer shielded behind it.

It still gets to run "secondary" executable code - JavaScript and
the like - and because that's so dangerous, the secondary computer,
instead of being thought of as the sandbox, should still have
the kind of software sandbox functionality that processors do
nowadays. But, wait - we already know those sandboxes _can_ be
compromised. So, while what is mentioned so far creates a second
line of defense, which is nice, it's not really a "solution", since
the lines of defense can be compromised one at a time.

So you need one other thing. A good mechanism, external to the
Internet-facing computer, which can detect if something has been
compromised on that computer. For example, a technique like
rowhammer could compromise the program memory in it that
it doesn't even have a read connection to! (Of course, here, using
special memory, even if slower and/or more expensive, that avoids
rowhammer is another measure that I think is warranted.)

So the idea, I guess, so far is this:

For routine stuff - JavaScript that executes to give web sites more
functionality - that stuff stays outside the "real" computer, thus
making a large reduction in the risk.
Some functionality requires things to go from the Internet to the
"good" computer to be executed, but if the amount of that is limited,
then one can restrict that to trusted sources: i.e. reputable
game publishers, trusted repositories of software for download.

That keeps the danger down to a "dull roar"; no longer will sending a
bad E-mail to a computer or getting it to look at a bad web site let
a miscreant take over the computer. Social engineering, where a user
is led to trust the _wrong_ software repository, of course, is still
going to be possible. That couldn't be eliminated without compromising
the usability and power of the computer (of course, for special
purposes, such a compromise may be admissible; i.e. locked down
Chromebooks or iOS devices lent out by schools to their students and
stuff like that).

So now you've heard my philosophy on security. (And that guy who
made philosophy a dirty word here disappeared for real about the time
of the spam onslaught. So that ill wind blew some good.)

John Savard

On Fri, 15 Dec 2023 22:39:15 +0000, Quadibloc wrote:

> If using a *virtual machine* won't give you a secure sandbox, then I
> despair of anything else giving you a secure sandbox on a single
> computer.

So, instead, my answer boils down to this:

Yo dawg! I heard you like computers, so I put a computer in your
computer so that you can compute (securely) while you compute (with
untrusted code).

John Savard

On 12/15/2023 8:53 AM, EricP wrote:
> MitchAlsup wrote:
>> Quadibloc wrote:
>>
>>> In any case, this has inspired me to think of a feature to
>>> add to Concertina II. Add a new kind of header block, which
>>> must be the very first one, which contains an encrypted
>>> checksum of the rest of the block - which must be valid for
>>> the block to be allowed to execute. A mode exists where
>>> only blocks with such a checksum can be executed.
>>
>> This is one reason you cannot allow writable and executable
>> in the same PTE. My 66000 HW checks this.
>
> Not supporting RWE as a valid PTE permission won't stop anything.
> It just means that on My66k an OS has to use trap and emulate
> to a accomplish the same end result. All that does is make
> certain things more expensive on that platform.
>
> Whether to support RWE is a decision that should be left to the OS,
> implemented through its privileging mechanisms and authorized
> on a per-user or per-app basis for individual memory sections.
>

Agreed.

There are some targets where double-mapping is needed for RWE use-cases,
but this doesn't really solve anything apart from making JITs annoying
(and this sort of thing doesn't really seem to have caught on).

RWE should not be a default though:
Executable sections can be R+X;
Data sections and heap can be R/W.

OTOH, in my project, I had added a "tk_malloc_cat()" function (also
"_malloc_cat()"), which is given a magic "cat" value that can specify
various special cases:
RWE memory;
GlobalAlloc memory;
...

This allows the memory manager to parcel out these special cases, while
keeping the usual malloc/free interface (though, each category has its
own free-lists), and "tk_free()"/"free()" will return the object to the
appropriate free list.

Besides JITs, a major use-case for RWE memory is implementing things
like lambdas and similar (and allowing them to present themselves as
normal C function pointers).

On Fri, 15 Dec 2023 09:53:14 -0500, EricP wrote:

> Not supporting RWE as a valid PTE permission won't stop anything. It
> just means that on My66k an OS has to use trap and emulate to a
> accomplish the same end result. All that does is make certain things
> more expensive on that platform.
>
> Whether to support RWE is a decision that should be left to the OS,
> implemented through its privileging mechanisms and authorized on a
> per-user or per-app basis for individual memory sections.

Although I tend to agree with you, I also think that allowing write
permission and execute permission at the same time is highly
dangerous. So I would both deprecate that option, and put extra
security safeguards around it so that if malware found a vulnerability
in the operating system, it still wouldn't be able to turn that mode
on.

Here, making it so that once access to write plus execute is turned off,
it can't be turned on again without a reboot seems appropriate. (Or
"potentially on", because forcing the system to boot with this enabled
isn't a good idea either. So there would be three states: RWE available,
but off; RWE on; RWE turned permanently off until reboot. From the third
state, there is no return to the first two.)

John Savard

Quadibloc wrote:
> On Fri, 15 Dec 2023 09:53:14 -0500, EricP wrote:
>
>> Not supporting RWE as a valid PTE permission won't stop anything. It
>> just means that on My66k an OS has to use trap and emulate to a
>> accomplish the same end result. All that does is make certain things
>> more expensive on that platform.
>>
>> Whether to support RWE is a decision that should be left to the OS,
>> implemented through its privileging mechanisms and authorized on a
>> per-user or per-app basis for individual memory sections.
>
> Although I tend to agree with you, I also think that allowing write
> permission and execute permission at the same time is highly
> dangerous. So I would both deprecate that option, and put extra
> security safeguards around it so that if malware found a vulnerability
> in the operating system, it still wouldn't be able to turn that mode
> on.
>
> Here, making it so that once access to write plus execute is turned off,
> it can't be turned on again without a reboot seems appropriate. (Or
> "potentially on", because forcing the system to boot with this enabled
> isn't a good idea either. So there would be three states: RWE available,
> but off; RWE on; RWE turned permanently off until reboot. From the third
> state, there is no return to the first two.)
>
> John Savard
>

Did you take a course in customer abusive design or something?
Who is it you think you are going to sell this feature to?

Quadibloc <quadibloc@servername.invalid> writes:
>Although I tend to agree with you, I also think that allowing write
>permission and execute permission at the same time is highly
>dangerous.

Security theatre!

Gforth uses mmap(... RWX ...) for the area where it generates native
code. Now on MacOS on Apple Silicon (MacOS on Intel works fine) that
mmap() fails, which means that currently the development version of
Gforth does not work. When I work around this misfeature of MacOS on
Apple Silicon (by disabling native code generation), Gforth will run
around a factor of 2 slower on MacOS than on Linux.

Ok, you might say, the additional security is worth that to you. But
note that either variant can write to every byte in the process, jump
to every executable byte in the process, and perform all the system
activities supported by Gforth (including writing files and then
calling chmod on them and invoking them, and compiling and running C
code). That's because Gforth implements a general-purpose programming
language that's supposed to be able to do all these things. So this
security "feature" of MacOS on Apple Silicon does not make Gforth any
more secure.

Well, you might say, but at least Gforth does not run on MacOS on
Apple Silicon now. But it does, in the latest released version, which
happens to be able to work around this misfeature automatically. It's
still not any more secure.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Sat, 16 Dec 2023 11:54:40 -0500, EricP wrote:
> Quadibloc wrote:

>> Here, making it so that once access to write plus execute is turned
>> off,
>> it can't be turned on again without a reboot seems appropriate. (Or
>> "potentially on", because forcing the system to boot with this enabled
>> isn't a good idea either. So there would be three states: RWE
>> available,
>> but off; RWE on; RWE turned permanently off until reboot. From the
>> third state, there is no return to the first two.)

> Did you take a course in customer abusive design or something?
> Who is it you think you are going to sell this feature to?

Well, Mitch proposes making it completely and absolutely impossible
for memory to both contain code that can currently be executed, and
for it to be writeable, at the same time.

I recognized the logic behind this. Yet, there are cases when this
would be a problem. So I felt that an option might be to dial the
security just a tiny notch down:

Make it _possible_ to have an operating system that did allow
read and execute at the same time, but _also_ make it possible for
an operating system not to allow it - in a way that can't be
subverted. The only way to change that being disabled is to reboot
into a different operating system that does allow it.

John Savard

On Sat, 16 Dec 2023 17:33:48 +0000, Anton Ertl wrote:
> Quadibloc <quadibloc@servername.invalid> writes:

>>Although I tend to agree with you, I also think that allowing write
>>permission and execute permission at the same time is highly dangerous.

> Security theatre!
>
> Gforth uses mmap(... RWX ...) for the area where it generates native
> code. Now on MacOS on Apple Silicon (MacOS on Intel works fine) that
> mmap() fails, which means that currently the development version of
> Gforth does not work. When I work around this misfeature of MacOS on
> Apple Silicon (by disabling native code generation), Gforth will run
> around a factor of 2 slower on MacOS than on Linux.

This is an argument you need to have with Mitch, rather than
with me. I lack the expertise to really assess how valuable not allowing
write and execute at the same time is; it certainly seems potentially
dangerous, so I went along with Mitch.

At the same time, there might be a demand for having both write and execute
in some cases - such as GForth. So I decided on allowing write/execute to
be disabled - with re-enebling it requiring a reboot. Those who fear
write/execute because of security then have a situation that's almost as
good as the processor not supporting it at all, but those who want it
have the option of using an operating system that runs with it allowed.

The situation on older computers, where being able to write and
execute together was just the norm, makes things easier for malware
to tamper with code. So it's clearly bad. If, instead, you have to
request that new blocks of memory be created with write/execute, then
JIT programs can run, but this can't be used to tamper with existing code
in memory - maybe that's good enough, and anything more is just
security theatre.

But hackers have been able to get around all sorts of security features
in computers.

John Savard

Quadibloc wrote:

> On Sat, 16 Dec 2023 11:54:40 -0500, EricP wrote:
>> Quadibloc wrote:

>>> Here, making it so that once access to write plus execute is turned
>>> off,
>>> it can't be turned on again without a reboot seems appropriate. (Or
>>> "potentially on", because forcing the system to boot with this enabled
>>> isn't a good idea either. So there would be three states: RWE
>>> available,
>>> but off; RWE on; RWE turned permanently off until reboot. From the
>>> third state, there is no return to the first two.)

>> Did you take a course in customer abusive design or something?
>> Who is it you think you are going to sell this feature to?

> Well, Mitch proposes making it completely and absolutely impossible
> for memory to both contain code that can currently be executed, and
> for it to be writeable, at the same time.

I go even further:: GOT is read-only to the application using dynamic
linking--so malicious applications cannot reprogram GOT into a RoP
attack strategy.

> I recognized the logic behind this. Yet, there are cases when this
> would be a problem. So I felt that an option might be to dial the
> security just a tiny notch down:

Context switching in 10-cycles is the cure to the perceived problems.

> Make it _possible_ to have an operating system that did allow
> read and execute at the same time, but _also_ make it possible for
> an operating system not to allow it - in a way that can't be
> subverted. The only way to change that being disabled is to reboot
> into a different operating system that does allow it.

> John Savard

On Sat, 16 Dec 2023 23:58:02 +0000, Quadibloc wrote:

> At the same time, there might be a demand for having both write and
> execute in some cases - such as GForth. So I decided on allowing
> write/execute to be disabled - with re-enebling it requiring a reboot.
> Those who fear write/execute because of security then have a situation
> that's almost as good as the processor not supporting it at all, but
> those who want it have the option of using an operating system that runs
> with it allowed.

But what if the next best thing isn't good enough?

> But hackers have been able to get around all sorts of security features
> in computers.

So if the CPU normally gets set, by the BIOS, or by boot-up code in the
OS, into a mode that doesn't allow write plus execute... and can't be
exited short of a reboot...

well, then, the hacker just has to corrupt the BIOS or early boot-up
code so that it never gets into that mode into the first place, if writing
executable code in memory is the next step in taking over the system!

Hmm. How do I take care of this?

Well, I've _already_ noted that *a pin on the CPU* might be used to
cause it to start up in a mode where it will refuse to execute ANY
instructions unless they're in blocks protected by encrypted
checksums!

So perhaps we need to dedicate _another_ pin on the CPU to mandating
another security mode. If the user wishes to only run operating systems
where write plus execute is hard disabled, then... ground that pin
or whatever, and it tells the CPU:

do not allow exiting the checksummed blocks only mode unless write
plus execute has been disabled!

That will stop any attempt to bring back write plus execute to a system
intended to exclude it!

John Savard

On Sun, 17 Dec 2023 04:20:28 +0000, Quadibloc wrote:

> So perhaps we need to dedicate _another_ pin on the CPU to mandating
> another security mode. If the user wishes to only run operating systems
> where write plus execute is hard disabled, then... ground that pin or
> whatever, and it tells the CPU:
>
> do not allow exiting the checksummed blocks only mode unless write plus
> execute has been disabled!

Silly me. This is more complicated than simply using that pin to
completely disable write plus execute.

John Savard

On Sun, 17 Dec 2023 01:17:14 +0000, MitchAlsup wrote:

> Context switching in 10-cycles is the cure to the perceived problems.

Yes, for a new architecture.

For an existing architecture, such as x86/x86-64, though, an OS
call to switch from allowing write to allowing execute is something
that would need to be added to a program using JIT compilation
that was written before the write/execute disable security feature
was added.

John Savard

Quadibloc <quadibloc@servername.invalid> writes:
>On Sat, 16 Dec 2023 17:33:48 +0000, Anton Ertl wrote:
>> Quadibloc <quadibloc@servername.invalid> writes:
>
>>>Although I tend to agree with you, I also think that allowing write
>>>permission and execute permission at the same time is highly dangerous.
>
>> Security theatre!
>>
>> Gforth uses mmap(... RWX ...) for the area where it generates native
>> code. Now on MacOS on Apple Silicon (MacOS on Intel works fine) that
>> mmap() fails, which means that currently the development version of
>> Gforth does not work. When I work around this misfeature of MacOS on
>> Apple Silicon (by disabling native code generation), Gforth will run
>> around a factor of 2 slower on MacOS than on Linux.
>
>This is an argument you need to have with Mitch, rather than
>with me.

This is a newsgroup, he can read and react on my posting as well as
you and others.

>I lack the expertise to really assess how valuable not allowing
>write and execute at the same time is; it certainly seems potentially
>dangerous, so I went along with Mitch.

The point I was making is that in the case of Gforth, it does not add
any danger that is not already there. If you let an untrusted user
run Gforth, it's like allowing that user to run non-suid binaries that
that user supplied.

Thanks to return-oriented or jump-oriented programming, even normal
applications can do pretty much everything without needing RWX. In
recent times CPU manufacturers have added features for making these
techniques harder to use, but for anything using a virtual-machine
interpreter (e.g., Gforth), these features are unlikely to help,
because they provide a Turing-complete set of routines that you can
jump to, and typically enough OS functions for an attack.

So better sabotage interpreters, too? Goodbye, CPython, bash etc.
Instead, like Mitch Alsup and Apple suggest, provide a twisty maze of
passages for a JIT compiler writer to follow (different passages for
Apple and My66000), and hope that the JIT compiler writers follow this
passage while the attackers will not.

I don't think this will work, either: E.g., an attacker could
overwrite VM code before it is JIT-compiled, and presto, they again
can do anything the VM can do, like with the interpreter.

Bottom line: W^X does not add security, it adds security theatre.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Quadibloc <quadibloc@servername.invalid> writes:
>The situation on older computers, where being able to write and
>execute together was just the norm, makes things easier for malware
>to tamper with code.

It is the norm.

How does it make things easier for attackers to tamper with code? For
15-20 years, malloc() has allocated everything RW (no X), data and BSS
segments are RW, and code segments are RX. So any plain C program
(and stuff based on that) never sees RWX memory.

Those programs that perform mmap(... RWX ...) need it for a reason,
typically for things like JIT compilation. And as I explained in
<2023Dec17.091623@mips.complang.tuwien.ac.at>, disabling RWX makes
life worse for the authors or users of these programs, but does not
prevent attacks from succeeding.

>If, instead, you have to
>request that new blocks of memory be created with write/execute, then
>JIT programs can run, but this can't be used to tamper with existing code
>in memory - maybe that's good enough, and anything more is just
>security theatre.

That's the usual situation nowadays, no need to cripple the hardware
for it; the exception is MacOS on Apple silicon, and this was done
without crippling the hardware, as demonstrated by Linux and by the
twisty passage that Apple wants JIT authors to follow.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Quadibloc <quadibloc@servername.invalid> writes:
>Well, I've _already_ noted that *a pin on the CPU* might be used to
>cause it to start up in a mode where it will refuse to execute ANY
>instructions unless they're in blocks protected by encrypted
>checksums!

Of course freely programmable computers are not in the interest of
everyone. In particular, not in the interests of providers of
"consumer product" type things like the Playstation and the iPhone.
Sony and Apple want to be the gatekeepers for the software that runs
one their customer's computers (but of course, Sony and Apple think
these are their (Sony's and Apple's) computers); and they are charging
a pretty hefty toll at the gate, and don't want anyone to bypass the
gate and supply their costomers (and they want to turn the customers
into an exclusive possession) with software in some other way.

Therefore they have done such things for a long time. And other
business types also like this kind of business model, so we have had
such a misfeature, called "Secure Boot" in PCs for quite some time,
and it is quite a bit more elaborated than what you have outlined.

However, PC customers have not been as willing to let themselves be
chained by an overlord as game console or smartphone customers, so the
overlord has been moving slowly in the PC space, but it has been
moving: For Windows 11 to be installable a TPM (a hardware feature to
make the system airtight) is required, and IIRC for Windows on ARM
Microsoft requires Secure Boot to be enabled.

How many more years before all software that we run on our (not
Microsoft's) PCs has to go through the toll gates of Microsoft?

In any case, what you are imagining has already been imagined many
years ago, in more detail, and it has little to do with disabling RWX.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Quadibloc <quadibloc@servername.invalid> writes:
>>The situation on older computers, where being able to write and
>>execute together was just the norm, makes things easier for malware
>>to tamper with code.
>
> It is the norm.
>
> How does it make things easier for attackers to tamper with code? For
> 15-20 years, malloc() has allocated everything RW (no X), data and BSS
> segments are RW, and code segments are RX. So any plain C program
> (and stuff based on that) never sees RWX memory.

An example: executable stacks are the norm on Linux, for realizing
trampolines (gcc parlance for pointers to nested functions).
See https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html .

I believe that gcc now uses heap-allocated rwx pages on Darwin,
which I believe is allowed (but I would have to check details
to be sure).

So, an open question: How does one create a pointer to a nested
function in architectures which disallow rwx pages? Standard C
does not allow this, but languages like Fortran do, as does a
gcc extension (which clang does not support, AFAIK).

A Fortran example (sorry for the somewhat lengthy code, but
I wanted to make it self-contained).

module interf
implicit none
abstract interface
function to_zero (x)
real, intent(in) :: x
real :: to_zero
end function to_zero
end interface
interface
function search_zero (a, b, fun)
import
real, intent(in) :: a, b
procedure (to_zero) :: fun
end function search_zero
end interface
end module interf

program main
use interf
implicit none
real :: a, b, sol
read (*,*) a, b
sol = search_zero (a, b, my_to_zero)
print *,sol

contains
function my_to_zero(x)
real, intent(in) :: x
real :: my_to_zero
my_to_zero = cos(x-a-b**2)
end function my_to_zero
end program main

On Sun, 17 Dec 2023 08:16:23 +0000, Anton Ertl wrote:

> The point I was making is that in the case of Gforth, it does not add
> any danger that is not already there.

I'm not sure of the relevance of that objection.

Nobody is accusing GForth of having bugs in it. The problem is that
the feature of the CPU that is needed for GForth to run efficiently -
having memory to which both write and execute access is permitted
at the same time - is dangerous.

That doesn't depend on GForth itself being dangerous. It means the
computer is more open to attacks which don't involve the application
GForth at all.

John Savard

Thomas Koenig <tkoenig@netcologne.de> writes:
>An example: executable stacks are the norm on Linux, for realizing
>trampolines (gcc parlance for pointers to nested functions).
>See https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html .

Are they the norm?

I did "pmap <pid>|grep rwx" on a number of processes in Debian 11, and
came up empty (no rwx page) on a bash, an xterm, and an xrn process.
I have compiled xrn myself without giving a flag for suppressing rwx.
Finally, the fourth try brought up a process with two rwx memory areas
(out of >3000), but they were "[ anon ]", not "[ stack ]": firefox.
For Firefox with it's Javascript JIT I am not surprised.

I next did

cd /proc
grep -l rwx */maps

and it came up with one other process (out of 170) in addition to
Firefox: Xorg.

>I believe that gcc now uses heap-allocated rwx pages on Darwin,
>which I believe is allowed (but I would have to check details
>to be sure).

On MacOS on Intel mmap(... RWX ...) works without further ado, for
MacOS on Apple Silicon I have come across some documentation about the
hoops that Apple wants JIT compiler writers to jump through; but given
that I don't plan to, I don't remember any details.

>So, an open question: How does one create a pointer to a nested
>function in architectures which disallow rwx pages? Standard C
>does not allow this, but languages like Fortran do, as does a
>gcc extension (which clang does not support, AFAIK).

The classical approach has been to pass such a thing as two machine
words: one points to the code, the other to the environment. Of
course, in an ABI that's based on the idea of only passing a code
pointer (e.g., what you might design with standard C in mind), you
need to pass the environment pointer through the code pointer, which
is what trampolines give you. I think that if you want to do that,
you either have to implement trampolines (and need to write code for
that), or you have to use a different ABI (e.g., pass a pair, or pass
a data pointer as a function pointer).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Quadibloc <quadibloc@servername.invalid> writes:
>On Sun, 17 Dec 2023 08:16:23 +0000, Anton Ertl wrote:
>
>> The point I was making is that in the case of Gforth, it does not add
>> any danger that is not already there.
>
>I'm not sure of the relevance of that objection.
>
>Nobody is accusing GForth of having bugs in it. The problem is that
>the feature of the CPU that is needed for GForth to run efficiently -
>having memory to which both write and execute access is permitted
>at the same time - is dangerous.

I don't know what the bugs of Gforth have to do with it.

Concerning the feature, it is not any more dangerous than Gforth
already is (irrespective of bugs and irrespective of RWX pages),
because Gforth already provides all the power that any non-suid
process running as that user already has.

>It means the
>computer is more open to attacks which don't involve the application
>GForth at all.

It isn't. As mentioned earlier, only those processes that need them
get RWX areas. Those processes that do not have RWX areas are
certainly not "more open to attacks". And those that have RWX are
still just as open to attacks as without RWX. I have given the
example of Gforth.

For FireFox with its JavaScript and WebAssembly JIT compilers a
similar reasoning applies. The reasoning is more involved because
unlike Forth, JavaScript and WebAssembly are supposed to be
memory-safe. However, if some buffer overflow vulnerability
(typically in some library written in C) allows writing code in an RWX
area, it probably also allows overwriting the data in a way that
subverts memory safety.

For Xorg I don't know why it has an RWX area, but it has 86 areas
mapped R-X, which surely provide plenty of gadgets for ROP or JOP. It
even includes libLLVM-11, so yes, there is everything there that any
attacker can wish for, so the presence of the RWX area probably
provides no additional danger, either.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>