[CM] S7 integrated in TIC-80, and bug reports

David St-Hilaire sthilaire.david at gmail.com
Fri Feb 3 10:42:58 PST 2023

I think it would be a good idea in another context. I think that forbidding
IO completely is better aligned with the intentional use of the TIC-80
which is meant to be a fantasy console. The scheme code runs directly on
the fictionnal hardware (a bit like your assembly would run from a NES
cartridge). There shouldn't be any persistent file systems / storage
accessible to users using that premise.

On Fri, Feb 3, 2023 at 1:23 PM Massimiliano Gubinelli <m.gubinelli at gmail.com>

> What about implementing a fake filesystem instead of allowing s7 to access
> the real one? In this way it will be effectively sandboxed. This is the
> approach used by emscripten to have ports work in webasm.
> Max
> On 3 Feb 2023, at 13:43, David St-Hilaire <sthilaire.david at gmail.com>
> wrote:
> I think it's mostly writing to files that is dangerous but disabling
> reading would be important too, if not only for forbidding "breaking" the
> fantasy console barriers. I looked at doing some changes but I was really
> not sure how to do it properly. If you would be generous enough to do
> the needed changes, it would be really amazing!
> Thank you so much for your help!
> On Fri, Feb 3, 2023 at 8:32 AM <bil at ccrma.stanford.edu> wrote:
>> Do you need to disallow reading a file?  If it's just
>> creating or altering a file that needs to be blocked,
>> you could redirect fopen and fwrite (in s7.c) to
>> functions that raise an error.  I don't think s7 uses
>> creat, open (except with O_RDONLY), or write.  Also
>> build it with WITH_C_LOADER=0 (to disallow dynamic
>> loading of C object code), and maybe WITH_SYSTEM_EXTRAS=0.
>> Hmmm... as I type this, this seems interesting --
>> maybe I'll tackle it later today.  It might be
>> equally easy to disallow reading a file -- fread etc.
>> Oh, and for fopen, check the mode doesn't have "w" or "x"
>> or whatever else might change a file.  I'm probably
>> forgetting something obvious.
>> (There's also the sandbox procedure in stuff.scm, but
>> it's been years since I looked at it).
> --
> David
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20230203/eaf9d051/attachment-0001.html>

More information about the Cmdist mailing list