[Vm-dev] ChromeOS/ARM/Cog problem

John McIntosh johnmci at smalltalkconsulting.com
Mon Nov 9 19:49:37 UTC 2015


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 <tim at rowledge.org> 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; tim at rowledge.org; 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
===========================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151109/f56a4676/attachment.htm


More information about the Vm-dev mailing list