[9fans] porting p9p to Google's NaCl

[9fans] porting p9p to Google's NaCl

[Skip Tavakkolian]

anyone working on this?

Re: [9fans] porting p9p to Google's NaCl

[Roman V Shaposhnik]

On Fri, 2009-06-12 at 13:04 -0700, Skip Tavakkolian wrote:
> anyone working on this?

What's so great about NaCl? Isn't it just a fancy way to start
QEmu/VirtualBox/VMWare?

Thanks,
Roman.

Re: [9fans] porting p9p to Google's NaCl

[Skip Tavakkolian]

>> anyone working on this?
>
> What's so great about NaCl? Isn't it just a fancy way to start
> QEmu/VirtualBox/VMWare?

it has the advantages of JVM in the browser, but at native speed and
using any language with a compiler that can produce code for the inner
sandbox (restricted instructions and a minimal posix environment).

Re: [9fans] porting p9p to Google's NaCl

[André Günther]

I just want to point out that in NaCl you can't possibly ever support  
proper error handling because NaCl will just let your process die on a  
fault.

Other than that i'd like to know what kind of use cases you would find  
this interesting for. I can't come up with any, but that's maybe due  
to my lack of imagination.

best regards,
André

Re: [9fans] porting p9p to Google's NaCl

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

Having looked into this a bit, it appears to be more like 9vx than QEMU
 (uses segmenting capabilities), that is, unless I've forgotten how 9vx is
set up.
I believe some X11 stuff also uses segment registers, as well as TLS on
Linux.

I
"get it". Especially that they're shooting for Native Arm.  It' be
cool on mobiles for sure.

On Fri, Jun 12, 2009 at 6:04 PM, Roman V Shaposhnik <rvs@sun.com> wrote:

> On Fri, 2009-06-12 at 13:04 -0700, Skip Tavakkolian wrote:
> > anyone working on this?
>
> What's so great about NaCl? Isn't it just a fancy way to start
> QEmu/VirtualBox/VMWare?
>
> Thanks,
> Roman.
>
>
>

[-- Attachment #2: Type: text/html, Size: 984 bytes --]

Re: [9fans] porting p9p to Google's NaCl

[André Günther]

> Having looked into this a bit, it appears to be more like 9vx than  
> QEMU  (uses segmenting capabilities), that is, unless I've forgotten  
> how 9vx is set up.
>
> I believe some X11 stuff also uses segment registers, as well as TLS  
> on Linux.
>


TLS and the kind of segmentation 9vx and NaCl are using are two pairs  
of shoes.

For every memory related operation in 32bit x86 there's a specific  
register responsible for being part of the address translation. (eg.  
%ds for various mov instructions and %ss for stack operations...)
However there are two "free" segment registers, namely: %fs and %gs.
So how can we possible use them? The x86 has the ability to prefix  
operations in a way that it uses another segment register instead of  
the usual one for translation.
This is how TLS is done. Either %gs or %fs are setup so that a  
prefixed instruction will use the TLS address range.

However the way segmentation is used in 9vx and NaCl is a whole other  
story. (What I am now saying me be specific to 9vx and differ on NaCl,  
but the general principle should be the same)
Here the segment registers like %cs, %ds, %es and %ss are directly  
altered (and given another segment description) so most of the memory  
instructions can just be used without further host->guest code  
translation (as long as the guest code doesn't use special  
segmentation stuff himself).

The basic idea is: when segment translation is done anyway, let's  
exploit it and get guest code memory translation/access restriction  
for free)

Hope that clears it a bit and i wasn't too much of a noise for the list,
best regards,
André

Re: [9fans] porting p9p to Google's NaCl

[erik quanstrom]

> This is how TLS is done. Either %gs or %fs are setup so that a
> prefixed instruction will use the TLS address range.

all the world's a vax.  er, wrong century.  all the world's
an x86.

> The basic idea is: when segment translation is done anyway, let's
> exploit it and get guest code memory translation/access restriction
> for free)

i think you misspelled "for the cost of portability".

- erik