~phoebos

https://bvnf.space

~phoebos/uxndebug

Last active 5 months ago
View more

Recent activity

Re: Synthesizable Uxn CPU 4 months ago

From phoebos to ~rabbits/uxn

On Thu, Jun 30, 2022 at 15:42:59 -0700, Hundred Rabbits wrote:
> Could you explain the k mode in your own words in that way that could
> be useful to other implementers, so I could put it on the docs? Is
> there a way we could make the uxn.c more explicit?

I'm not Martin, but my own thoughts: (pretty much a translation of uxn.c):

Normally, operations get values to work on by POPping sequentially, but the
k mode causes POP to do nothing to the stack, or it POPs from a copy of the stack.
So any operation which needs to read some value, even if it will leave it there,
would usually

    a = POP(); PUSH(a);
    ...other operations using a

Re: File device and the debugger [was Re: Seeking the File device] 5 months ago

From phoebos to ~rabbits/uxn

On Wed, Jun 22, 2022 at 17:21:38 -0700, Hundred Rabbits wrote:
> just wanted to say thanks for the sandboxing patch, works amazingly
> well. I've been testing it for the past two days and I haven't found a
> way to exit it.

That's great to hear! I spent almost a full day on it so it's nice that
it's appreciated. Unfortunately it might require some rewriting if/when
the File devices are changed.

phoebos

Re: File device and the debugger [was Re: Seeking the File device] 5 months ago

From phoebos to ~rabbits/uxn

On Wed, Jun 22, 2022 at 01:01:18 +0100, Andrew Alderwick wrote:
> I wonder what the appetite is to restrict it further so that if it's run in
> the home directory, it changes directory to e.g. ~/.config/uxn after reading
> the ROM. My threat model here is that running Uxn from inside ~/uxn is
> safer, but when it's run directly in ${HOME} then it can read/delete my
> ~/.ssh/ private keys.

On second thought, this would be quite confusing behaviour to any program
using the File device. Perhaps a better method would be to include in
the emulator code a list of paths which are forbidden to be accessed,
such as $HOME/.ssh . This list could be hard-coded or read from a file.
We'd have implemented something like unveil(2) (but the opposite!).

phoebos

Re: File device and the debugger [was Re: Seeking the File device] 5 months ago

From phoebos to ~rabbits/uxn

On Wed, Jun 22, 2022 at 01:01:18 +0100, Andrew Alderwick wrote:
> I see the patch restricts File access to the current directory and
> below — well done!

:)

> I wonder what the appetite is to restrict it further so that if it's run in
> the home directory, it changes directory to e.g. ~/.config/uxn after reading
> the ROM. My threat model here is that running Uxn from inside ~/uxn is
> safer, but when it's run directly in ${HOME} then it can read/delete my
> ~/.ssh/ private keys.
> 
> This is technically doable with little extra work, but I was interested in
> people's thoughts about the potential for confusion/annoyance and whether

Re: File device and the debugger [was Re: Seeking the File device] 5 months ago

From phoebos to ~rabbits/uxn

On Mon, Jun 20, 2022 at 23:40:57 -0400, Erik Osheim wrote:
> On Mon, Jun 20, 2022 at 07:39:32PM -0700, Hundred Rabbits wrote:
> > Excuse my naivety, but I was thinking, couldn't we just catch paths
> > that contain either `..` or `~/`, is there another ways to exit the
> > working folder than those two?
> 
> On systems that have them you'd be able to use symbolic links to
> escape the working folder without having to mention `..` or `~`.

Yes, I could use a symbolic link or an absolute address. '~' is expanded
by the shell and wouldn't work anyway.

I didn't want to just block paths containing '..', because it's a
perfectly valid thing to use if you've gone into one directory and want

Re: File device and the debugger [was Re: Seeking the File device] 5 months ago

From phoebos to ~rabbits/uxn

On Sun, Jun 19, 2022 at 18:39:47 -0700, Hundred Rabbits wrote:
> > This is easy to implement with unveil(2)!
> 
> Do you think you could make a PR to uxn11? I'd love to take this for a spin.

unveil(2) is OpenBSD-specific, but I've put together a check using realpath(3),
which is POSIX. The patch is attached.

realpath(3) finds the _canonical_ version of a pathname, so,
/foo/../bar// becomes /bar, and symlinks are also resolved. However, it
only works for existing paths, so I had to make a wrapper function which
tries realpath, and if I get ENOENT then remove the last component and
try again. The result is that I find the longest part which exists of the
requested pathname, and this can be compared to the current working

Re: File device and the debugger [was Re: Seeking the File device] 5 months ago

From phoebos to ~rabbits/uxn

On Sun, Jun 19, 2022 at 16:28:35 -0700, Hundred Rabbits wrote:
> Ah, one other thing it might be worth thinking about sandboxing
> by-default while we're here. I would love it if the file device was
> always sand-boxed, I think people are afraid of the damages this could
> do and I tend to agree, I've been running a lot of other people's roms
> recently and it's just a matter of time.

I was thinking about this recently and I agree with what cancel
implemented in uxn32: the VM can only access the filesystem at and below
the current working directory. This is easy to implement with unveil(2)!
When implementing manually, both relative addresses (../../etc/foo) and
absolute (/etc/foo) should be parsed to check if they are inside the
sandbox. It might be useful for an emulator to print a warning if an
attempt is made to access files outside the sandbox, so that some bugs

Re: Error Code 4: Halting on non-empty stack 5 months ago

From phoebos to ~rabbits/uxn

On Sun, Jun 12, 2022 at 09:57:53 -0700, Devine Lu Linvega wrote:
> While Varvara handles the erroring, the core itself is what
> communicates that error. The halting is out of the scope of the specs
> freeze, but the error codes aren't.

Are you suggesting to standardise the error codes which should be
printed by an emulator? Or might these by reported in some way, maybe by
the System vector?

As for the actual values, they're fine, but I don't see a huge point in
standardising them if they are only to be printed with an accompanying
message.

phoebos

[PATCH uxn] (uxnasm) only ignore [ or ] if it is a whole token 5 months ago

From phoebos to ~rabbits/public-inbox

Currently, tokens beginning with a [ or ] character are completely
ignored, which forbids a macro from beginning with these characters.
Specifically, a macro can be declared eg. as `%[x { ... }` but cannot be
dereferenced as `[x`.
This patch only ignores these tokens if they have a length of 1;
otherwise the switch falls through to the default case.
---

I noticed this bug from a note in this post: https://cybre.space/@wim_v12e/108425428588139783

 src/uxnasm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/uxnasm.c b/src/uxnasm.c
[message trimmed]

[PATCH uxn11] Exit emulator on HALT. 5 months ago

From phoebos to ~rabbits/public-inbox

Check if .System/halt is non-zero like uxnemu does.

I tried to use the return value of uxn_eval, which would seem to return
0 on halt:

uxn_eval(Uxn *u, Uint16 pc) {
	if (!pc || u->dev[0x0f]) return 0;
	...
	return 1;
}

but in some programs (eg. polycat), pc can be zero at unexpected times.
I'm not really sure what pc does.