nacl and present

[Dan Kortschak]

With the impending introduction of NaCl support for 1.3, I'd like to ask
about how that will interact with play code in present presentations.

Motivation: I would like to use present for lectures that I give (I
already do this) and I would further like students to be able to try out
alterations of parameterisation of code that I am showing - for example
in a lecture on biological sequence alignment I play code that does
pairwise alignment and allows alteration of the scoring matrices for
alignment. However, I don't really want students unfettered access to my
machine - here NaCl comes in to sandbox play code. What I wondering is
how to deal with the fact that present runs alien (non-Go) code which
will be run outside the NaCl environment.

Is this something that it might be reasonable to expect present to deal
with? I'm happy to just break alien code execution in a fork if this is
outside the intended use of present/NaCl.

thanks
Dan

[Andrew Gerrand]

It may be possible to achieve this by simply setting GOOS=nacl GOARCH=amd64p32 before running present. Of course you'd need a cross-compiled nacl tool chain installed first, with all the appropriate dependencies.

Andrew

[Dan Kortschak]

Absolutely, that was my intention. What I'm concerned about is if I have
a .play which is not running Go code or is running Go code where the
entire file is present in the play window. Here a sufficiently clever
student may replace the code with either code in the non-Go language or
replace the complete file with non-Go code and execute that via the call
at go.tools/playground/socket/socket.go#L184.

I suppose a reasonably simple work around is to never provide a file
that has the first line alterable (and don't include non-Go code). Then
it can be trusted that the NaCl runtime is what is being used (rather
than say - python or bash). Simpler that a gaol for the whole thing and
it's environment.

Dan

[Andrew Gerrand]

What about a flag to disable non-Go code execution?

[Dan Kortschak]

On Mon, 2014-03-17 at 11:02 +1100, Andrew Gerrand wrote:
> What about a flag to disable non-Go code execution?
>

That occurred to me. Yes, probably a good idea.

thanks
Dan

[Andrew Gerrand]

Or better, we could have a -nacl flag that sets the correct GOOS/GOARCH and disabled non-Go execution. That way just one flag is sufficient to secure the present tool.  

[Dan Kortschak]

Very nice.

[Dan Kortschak]

On Mon, 2014-03-17 at 10:37 +1100, Andrew Gerrand wrote:

> It may be possible to achieve this by simply setting GOOS=nacl
> GOARCH=amd64p32 before running present. Of course you'd need a
> cross-compiled nacl tool chain installed first, with all the
> appropriate dependencies.

I've just tried this (using Dave's misc/nacl scripts) and I get a
segfault when the code is run in the playground - either using the
changes I mailed or by doing what you have above in the command line.
The same code segfaults with go build as is used in the playground
(*proccess).start func, but weirdly works with go run using the same
invocation (code from 10 things).

$ GOOS=nacl GOARCH=amd64p32 go build -tags OMIT -o compile compile0.go
$ ./compile
Segmentation fault (core dumped)
$ GOOS=nacl GOARCH=amd64p32 go build compile0.go
$ ./compile
Segmentation fault (core dumped)
$ GOOS=nacl GOARCH=amd64p32 go run compile0.go
Java beat C++
Python beat Perl
Go beat C

[Dan Kortschak]

On Tue, 2014-03-18 at 13:21 +1030, Dan Kortschak wrote:
> $ GOOS=nacl GOARCH=amd64p32 go build compile0.go
> $ ./compile
> Segmentation fault (core dumped)

Correction:

$ GOOS=nacl GOARCH=amd64p32 go build compile.go

[Dave Cheney]

That is correct, nacl binaries are not self contained, they need to be
hosted by the nacl runtime.

GOOS=nacl GOARCH=amd64p32 go run compile.go

[Dan Kortschak]

On Tue, 2014-03-18 at 14:16 +1100, Dave Cheney wrote:
> That is correct, nacl binaries are not self contained, they need to be
> hosted by the nacl runtime.
>
> GOOS=nacl GOARCH=amd64p32 go run compile.go
>

OK. Thanks. That means the playground needs additional support for that
case then.

[Dave Cheney]

Please have a look at

https://codereview.appspot.com/75080043

[Dan Kortschak]

On Tue, 2014-03-18 at 14:24 +1100, Dave Cheney wrote:
> Please have a look at
>
> https://codereview.appspot.com/75080043
>

Thanks Dave, yes I was working from that but missed the crucial part.

If I alter the socket.go code to do this (as an experiment):

// run x
cmd = p.cmd("", "go_nacl_amd64p32_exec", bin)
if opt != nil && opt.Race {
cmd.Env = append(cmd.Env, "GOMAXPROCS=2")
}
if err := cmd.Start(); err != nil {
// If we failed to exec, that might be because they built
// a non-main package instead of an executable.
// Check and report that.
if name, err := packageName(body); err == nil && name != "main" {
return errors.New(`executable programs must use "package main"`)
}
return err
}
p.run = cmd

it works (as expected if I actually read your README properly).

Now this means that I'm not so sure about the approach to signalling the
playground to use NaCl by the socket.Environ func. I can still do that
and have the socket code check for GOOS=nacl and check which GOARCH to
use, but it seems like a bool might be better after all. Andrew?

cheers
Dan