Smalltalk › Squeak › Squeak VM

ChromeOS/ARM/Cog problem

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

timrowledge

ChromeOS/ARM/Cog problem

At our CampSmalltalk over the weekend Ken Dickey & I were trying to make CogSpur run on his Acer ARM/Chromebook/ChromeOS machine. At first I thought we simply had the same problem that required me to rewrite the closed PIC system but right now it seems there is something about ChromeOS that is preventing u from running generated code.

A simple test program that allocates some memory, set up permissions so we can execute from there, puts a few instructions in and jumps in, runs perfectly. However, in the full VM during the early stages of startup we generate a bunch of code for trampolines and when we make the first (I think( attempt to call one of those routines (ceCaptureCStackPointers IIRC) we get instead an illegal dereference to address 0.

I didn’t have a great deal of time to debug this since we had a lot going on, so everything is a bit tentative for now. Is anyone out there sufficiently familiar with chromeos to know of the details of setting memory area permissions and so forth?

Since chromeos doesn’t yet seem to support Pi hardware I can’t do much here unless I buy a chromebook - or of course, someone sends me one!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His seat back is not in the full upright and locked position.

johnmci

Re: ChromeOS/ARM/Cog problem

https://developer.chrome.com/native-client/faq

Data integrity: No loads or stores are permitted outside of the data sandbox. In particular this means that once loaded into memory, the binary is not writable. This is enforced by operating system protection mechanisms. While new instructions can be inserted at runtime to support things like JIT compilers, such instructions will be subject to runtime verification according to the following constraints before they are executed.

No unsafe instructions: The validator ensures that the Native Client application does not contain any unsafe instructions. Examples of unsafe instructions are syscall, int, and lds.
Control flow integrity: The validator ensures that all direct and indirect branches target a safe instruction.

The beauty of the Native Client sandbox is in reducing “safe” code to a few simple rules that can be verified by a small trusted validator: the compiler isn’t trusted. The same applies to Portable Native Client where even the .pexe to .nexe translator, a simplified compiler backend, isn’t trusted: it is validated before executing, and so is its output.

In addition to static analysis of untrusted code, the Native Client runtime also includes an outer sandbox that mediates system calls. For more details about both sandboxes, see Native Client: A Sandbox for Portable, Untrusted x86 Code (PDF).

On Mon, Nov 9, 2015 at 11:35 AM, tim Rowledge <[hidden email]> wrote:

At our CampSmalltalk over the weekend Ken Dickey & I were trying to make CogSpur run on his Acer ARM/Chromebook/ChromeOS machine. At first I thought we simply had the same problem that required me to rewrite the closed PIC system but right now it seems there is something about ChromeOS that is preventing u from running generated code.

A simple test program that allocates some memory, set up permissions so we can execute from there, puts a few instructions in and jumps in, runs perfectly. However, in the full VM during the early stages of startup we generate a bunch of code for trampolines and when we make the first (I think( attempt to call one of those routines (ceCaptureCStackPointers IIRC) we get instead an illegal dereference to address 0.

I didn’t have a great deal of time to debug this since we had a lot going on, so everything is a bit tentative for now. Is anyone out there sufficiently familiar with chromeos to know of the details of setting memory area permissions and so forth?

Since chromeos doesn’t yet seem to support Pi hardware I can’t do much here unless I buy a chromebook - or of course, someone sends me one!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His seat back is not in the full upright and locked position.

===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================

timrowledge

Re: ChromeOS/ARM/Cog problem

> On 09-11-2015, at 11:49 AM, John McIntosh <[hidden email]> wrote:
>
> https://developer.chrome.com/native-client/faq

Interesting. I wonder what we have that makes it not like us. We actually don’t do anything terribly dramatic instruction-wise.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BDC: Break Down and Cry

johnmci

Re: ChromeOS/ARM/Cog problem

Ah, but I think the issue might be how does the validation process start? Surely just jumping to the page wouldn't do it? Or is there a sys call you have to make?

On Mon, Nov 9, 2015 at 12:47 PM, tim Rowledge <[hidden email]> wrote:

> On 09-11-2015, at 11:49 AM, John McIntosh <[hidden email]> wrote:
>
> https://developer.chrome.com/native-client/faq

Interesting. I wonder what we have that makes it not like us. We actually don’t do anything terribly dramatic instruction-wise.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BDC: Break Down and Cry

johnmci

Re: ChromeOS/ARM/Cog problem

maybe use mprotect and change to PROT_EXEC only versus PROT_WRITE+PROT_EXEC after you write the bits.

On Mon, Nov 9, 2015 at 12:49 PM, John McIntosh <[hidden email]> wrote:

Ah, but I think the issue might be how does the validation process start? Surely just jumping to the page wouldn't do it? Or is there a sys call you have to make?

On Mon, Nov 9, 2015 at 12:47 PM, tim Rowledge <[hidden email]> wrote:

> On 09-11-2015, at 11:49 AM, John McIntosh <[hidden email]> wrote:
>
> https://developer.chrome.com/native-client/faq

Interesting. I wonder what we have that makes it not like us. We actually don’t do anything terribly dramatic instruction-wise.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BDC: Break Down and Cry

--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================

KenDickey

Re: ChromeOS/ARM/Cog problem

On Mon, 9 Nov 2015 12:57:36 -0800
John McIntosh <[hidden email]> wrote:

> maybe use mprotect and change to PROT_EXEC only versus PROT_WRITE+PROT_EXEC
> after you write the bits.

V8 JavaScript JIT for Chromium Linux uses:

int prot = PROT_READ | PROT_WRITE | (is_executable ? PROT_EXEC : 0);

see discussion on:

http://stackoverflow.com/questions/570257/jit-compilation-and-dep

which shows Win, Mac, and Linux code for JIT memory allocation.

--
-KenD

-KenD