<div dir="ltr"><a href="https://developer.chrome.com/native-client/faq">https://developer.chrome.com/native-client/faq</a><div><br></div><div>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.</div><div><br>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.<br>Control flow integrity: The validator ensures that all direct and indirect branches target a safe instruction.<br><br>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.<br><br>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).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 11:35 AM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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!<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
Useful random insult:- His seat back is not in the full upright and locked position.<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">===========================================================================<br>John M. McIntosh. Corporate Smalltalk Consulting Ltd <a href="https://www.linkedin.com/in/smalltalk" target="_blank">https://www.linkedin.com/in/smalltalk</a><br>===========================================================================<br></div></div></div></div>
</div>