On Friday, July 30, 2021 at 8:57:53 AM UTC-6, Stephen Fuld wrote:

> Sure. But Specter attacks should be prevented in the hardware, and has
> nothing to do with write/execute permissions. My position is that Java
> script should be no less secure than any other language program.

Secure from what, and in what sense?

JavaScript is compiled from source on _your_ computer, whereas
programs you download were compiled on computers belonging to
the company responsible for the software.
That Joe Blow's computer is likely to be less secure than the
computers at Microsoft or Activision does not seem to be an
unreasonable suspicion.
Can an implementation of JavaScript really be designed to
make up for that?

John Savard

On 7/30/2021 6:41 AM, Anton Ertl wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> In My 66000 if both the W and the X bit are set in a PTE the HW takes a trap
>> due to the illegal condition. So in order to support both W and X permissions
>> the SW has to setup a trap handler which ping pongs the permissions back
>> and forth--leading them to quickly realize there HAS TO BE a better way to do
>> it.
>
> In Gforth we will just take the easy way: disable dynamic native code
> generation and revert to plain threaded code. The bottom line is a
> certain slowdown (e.g., a factor of 2 for fft on Skylake) and zero
> additional security, because Gforth can do everything machine language
> can do; most stuff out of the box, but the rest by constructing an
> appropriate binary and dynamically loading it.
>
> This restriction of My66000 might be a good fit for locked-down devices
> like the iPhone, where you can only run binaries blessed by Apple, and
> Apple in general does not bless language interpreters. However, as
> the Pegasus spyware demonstrates, even Apple's approach does not
> provide security, so the measures above are really about protecting
> Apple's app-store monopoly on iOS.
>
> It seems to me that those OSs that want to disable WX can do so
> without problems on existing hardware, e.g., by replying with EINVAL
> or (your approach) some trap to mmap(... PROT_EXEC|PROT_WRITE ...),
> and I guess there are quite a number of people who think that would be
> a good idea. But there is obviously enough software that would break,
> and while you are probably not alone in thinking that breaking such
> software is a good idea, it's not prevalent in Linux and Windows last
> time I looked. Baking this restriction into the hardware will just
> ensure that nobody will use it for a general-purpose computer.
>
> - anton
>

You seem to have a binary view of security: a system either is secure or
is not, and anything that doesn't make it secure is pointless.

This is a hopeless ambition: no system is proof against a pretty girl
with a suitcase or money, or a threatened loved one, or doctrinal
conversion. All we can hope to do a alter the costs and benefits.

Denying WX prevents many low-cost attacks. Yes, it can be worked around,
but at greater cost. Yes, it is annoying for some uses that
superficially resemble attacks, so it should be coupled with a more
secure way to accomplish dynamic code creation, such as a syscall to
switch an address range from W to X.

Like most of these cheap defenses, denying WX has a side benefit beyond
whatever security it brings: it blocks and reports a class of actions
that are not attacks but mere bugs. That brings value to all users,
whether they care about security or not.

Quadibloc <jsavard@ecn.ab.ca> writes:
>Even if Apple locked down its app store for reasons that were pure
>as the driven snow, that would not give it the ability to design a
>secure system that determined adversaries with funding and
>expertise could not subvert.

I am sure that Apple can design a system that such an adversary cannot
subvert. The question is if they can design a system with that
property that enough people want to buy.

Now, given that Apple does not want to go there, they obviously don't
lock down iOS to protect the security of their customers.

- 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 <jsavard@ecn.ab.ca> writes:
>>Even if Apple locked down its app store for reasons that were pure
>>as the driven snow, that would not give it the ability to design a
>>secure system that determined adversaries with funding and
>>expertise could not subvert.
>
> I am sure that Apple can design a system that such an adversary cannot
> subvert.

Apple could implement https://dilbert.com/strip/2010-09-21
of course, but...

> The question is if they can design a system with that
> property that enough people want to buy.

The question is if they could make a product resembling a smartphone
or a computer that is even marginally usable for anything at all,
and still cannot be subverted.

My answer would be "no", because Apple has not solved the halting
problem :-)

More seriously, they (like anybody else) use buggy compilers and
write buggy software with them, and even hardware is designed with
buggy software these days, so...

On 2021-07-30, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>>In My 66000 if both the W and the X bit are set in a PTE the HW takes a trap
>>due to the illegal condition. So in order to support both W and X permissions
>>the SW has to setup a trap handler which ping pongs the permissions back
>>and forth--leading them to quickly realize there HAS TO BE a better way to do
>>it.
>
> In Gforth we will just take the easy way: disable dynamic native code
> generation and revert to plain threaded code. The bottom line is a
> certain slowdown (e.g., a factor of 2 for fft on Skylake) and zero
> additional security, because Gforth can do everything machine language
> can do; most stuff out of the box, but the rest by constructing an
> appropriate binary and dynamically loading it.
>
> This restriction of My66000 might be a good fit for locked-down devices
> like the iPhone, where you can only run binaries blessed by Apple, and
> Apple in general does not bless language interpreters. However, as
> the Pegasus spyware demonstrates, even Apple's approach does not
> provide security, so the measures above are really about protecting
> Apple's app-store monopoly on iOS.
>
> It seems to me that those OSs that want to disable WX can do so
> without problems on existing hardware, e.g., by replying with EINVAL
> or (your approach) some trap to mmap(... PROT_EXEC|PROT_WRITE ...),
> and I guess there are quite a number of people who think that would be
> a good idea. But there is obviously enough software that would break,
> and while you are probably not alone in thinking that breaking such
> software is a good idea, it's not prevalent in Linux and Windows last
> time I looked. Baking this restriction into the hardware will just
> ensure that nobody will use it for a general-purpose computer.
>
> - anton
All JIT's will break, for example...

--
bmaxa now listens Ob-Neob Radio

On 2021-07-30, Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Friday, July 30, 2021 at 8:16:41 AM UTC-6, Anton Ertl wrote:
>
>> This restriction of My66000 might be a good fit for locked-down devices
>> like the iPhone, where you can only run binaries blessed by Apple, and
>> Apple in general does not bless language interpreters. However, as
>> the Pegasus spyware demonstrates, even Apple's approach does not
>> provide security, so the measures above are really about protecting
>> Apple's app-store monopoly on iOS.
>
> Yes, Apple seeks to preserve its highly profitable app store monopoly
> on iOS. That is first and foremost what the locked-down nature of iOS
> is about. I do not disagree with this claim.
>
> However, I do, very strongly, disagree with the claim that the fact that
> the... incidental security benefits... of Apple's policies are less than
> perfect, as the recent Pegasus debacle shows... is in any way
> _evidence_ of the motivation behind Apple's app store policies.

Well, csrutil disable from single user mode is mandatory if you
want anything to do with macOS. Intel is much worse. In order
to disable ME, you have to do some flash hacking :P
..

>
> Even if Apple locked down its app store for reasons that were pure
> as the driven snow, that would not give it the ability to design a
> secure system that determined adversaries with funding and
> expertise could not subvert.

Well their idea of security is to read 80GB from network drive,
then let binary run :P
>
> John Savard

--
bmaxa now listens Ob-Neob Radio

On 2021-07-30, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>>Even if Apple locked down its app store for reasons that were pure
>>as the driven snow, that would not give it the ability to design a
>>secure system that determined adversaries with funding and
>>expertise could not subvert.
>
> I am sure that Apple can design a system that such an adversary cannot
> subvert. The question is if they can design a system with that
> property that enough people want to buy.
>
> Now, given that Apple does not want to go there, they obviously don't
> lock down iOS to protect the security of their customers.
>
+1!
> - anton

--
bmaxa now listens Ob-Neob Radio

On 7/30/2021 9:17 AM, Quadibloc wrote:
> On Friday, July 30, 2021 at 8:57:53 AM UTC-6, Stephen Fuld wrote:
>
>> Sure. But Specter attacks should be prevented in the hardware, and has
>> nothing to do with write/execute permissions. My position is that Java
>> script should be no less secure than any other language program.
>
> Secure from what, and in what sense?
>
> JavaScript is compiled from source on _your_ computer, whereas
> programs you download were compiled on computers belonging to
> the company responsible for the software.
> That Joe Blow's computer is likely to be less secure than the
> computers at Microsoft or Activision does not seem to be an
> unreasonable suspicion.
> Can an implementation of JavaScript really be designed to
> make up for that?

I am not sure the security of the computer doing the compilation is the
major factor, unless you are thinking that the compiler itself gets
corrupted.

But see

https://www.zdnet.com/article/microsoft-is-testing-a-super-duper-secure-mode-for-its-edge-browser/

They seem to think it is the JIT process itself that is the problem. I
am not sure. I can see several possibilities for what the problem is.

1. The JIT process itself
2. Javascript the language
3. Anything compiled within a browser

Some combination of the above, or something else.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, August 5, 2021 at 2:23:01 PM UTC-5, Stephen Fuld wrote:
> On 7/30/2021 9:17 AM, Quadibloc wrote:
> > On Friday, July 30, 2021 at 8:57:53 AM UTC-6, Stephen Fuld wrote:
> >
> >> Sure. But Specter attacks should be prevented in the hardware, and has
> >> nothing to do with write/execute permissions. My position is that Java
> >> script should be no less secure than any other language program.
> >
> > Secure from what, and in what sense?
> >
> > JavaScript is compiled from source on _your_ computer, whereas
> > programs you download were compiled on computers belonging to
> > the company responsible for the software.
> > That Joe Blow's computer is likely to be less secure than the
> > computers at Microsoft or Activision does not seem to be an
> > unreasonable suspicion.
> > Can an implementation of JavaScript really be designed to
> > make up for that?
> I am not sure the security of the computer doing the compilation is the
> major factor, unless you are thinking that the compiler itself gets
> corrupted.
>
> But see
>
> https://www.zdnet.com/article/microsoft-is-testing-a-super-duper-secure-mode-for-its-edge-browser/
>
> They seem to think it is the JIT process itself that is the problem. I
> am not sure. I can see several possibilities for what the problem is.
>
> 1. The JIT process itself
> 2. Javascript the language
> 3. Anything compiled within a browser
<
The problem is the overhead of context switches. This causes developers to
put the JIT in the same context as the application.
<
The compiler needs to be in a different context.
Only compiler context has write access to the code memory,
the execution context only has execute access to the code memory.
>
> Some combination of the above, or something else.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 8/5/2021 1:11 PM, MitchAlsup wrote:
> On Thursday, August 5, 2021 at 2:23:01 PM UTC-5, Stephen Fuld wrote:
>> On 7/30/2021 9:17 AM, Quadibloc wrote:
>>> On Friday, July 30, 2021 at 8:57:53 AM UTC-6, Stephen Fuld wrote:
>>>
>>>> Sure. But Specter attacks should be prevented in the hardware, and has
>>>> nothing to do with write/execute permissions. My position is that Java
>>>> script should be no less secure than any other language program.
>>>
>>> Secure from what, and in what sense?
>>>
>>> JavaScript is compiled from source on _your_ computer, whereas
>>> programs you download were compiled on computers belonging to
>>> the company responsible for the software.
>>> That Joe Blow's computer is likely to be less secure than the
>>> computers at Microsoft or Activision does not seem to be an
>>> unreasonable suspicion.
>>> Can an implementation of JavaScript really be designed to
>>> make up for that?
>> I am not sure the security of the computer doing the compilation is the
>> major factor, unless you are thinking that the compiler itself gets
>> corrupted.
>>
>> But see
>>
>> https://www.zdnet.com/article/microsoft-is-testing-a-super-duper-secure-mode-for-its-edge-browser/
>>
>> They seem to think it is the JIT process itself that is the problem. I
>> am not sure. I can see several possibilities for what the problem is.
>>
>> 1. The JIT process itself
>> 2. Javascript the language
>> 3. Anything compiled within a browser
> <
> The problem is the overhead of context switches. This causes developers to
> put the JIT in the same context as the application.
> <
> The compiler needs to be in a different context.
> Only compiler context has write access to the code memory,
> the execution context only has execute access to the code memory.

While that may be a good way to catch the original error, it isn't the
cause of the error. It must be that the generated code is doing
something "wrong" that the same source code, when interpreted, doesn't do.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)