WAMR application can access the whole File System at Zephyr

[banana-sun]

OS: Zephyr v3.7.1
WAMR brance: https://github.com/bytecodealliance/wasm-micro-runtime/tree/dev/zephyr_file_socket
Hardware: NUCLEO-H563ZI
Zephyr File System: lfs/test.txt
WAMR FS interaction folder: --dir=/lfs

There is a test.txt file at /lfs. Then in the WAMR application, if need to access test.txt file, it should be /test.txt instead of /lfs/test.txt. This is my understanding. I'm not sure if it's correct.

Runtime implement:

    const char * wasi_dir = "/lfs";

    /* load WASM module */
    wasm_module = wasm_runtime_load(wasm_file_buf, entry.size, error_buf, sizeof(error_buf));

    wasm_runtime_set_wasi_args_ex(wasm_module, &wasi_dir, 1, NULL, 0, NULL, 0, NULL, 0, 0, 1, 2);

    /* instantiate the module */
    wasm_module_inst =
              wasm_runtime_instantiate(wasm_module, CONFIG_APP_STACK_SIZE, CONFIG_APP_HEAP_SIZE, error_buf, sizeof(error_buf));
    wasm_application_execute_main(module_inst, app_argc, app_argv);

Application code:

#include <stdio.h>
#include <stdlib.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <dirent.h>

static int file_test(void)
{
    int     fd;
    uint8_t buf[32] = { 0 };

    fd = open("/lfs/test.txt", O_CREAT | O_RDWR);
    if (fd < 0)
    {
        printf("Error opening file [%d]\n", fd);
        printf("%s\r\n", strerror(errno));
        return fd;
    }
    printf("File opened successfully\n");

    uint32_t len = read(fd, buf, sizeof(buf));
    if (len < 0)
    {
        printf("Error reading file [%d]\n", len);
        return len;
    }
    printf("Read: %s\n", buf);

    close(fd);
    return 0;
}

It will output:

Hello world!
File opened successfully
Read: hello

But if I modify it to: fd = open("/test.txt", O_CREAT | O_RDWR);, it will output Error opening file [-1].

[banana-sun]

I tried again using the latest version of this PR(#4377), but still had this problem.

[lucasAbadFr]

Hello !

I think it is because relative path are not supported.
If I remember correctly Zephyr don't even support relative path, at least from what I can see from this example.

Have you tried a Native Zephyr approach ?

[banana-sun]

Hello !

I think it is because relative path are not supported. If I remember correctly Zephyr don't even support relative path, at least from what I can see from this example.

Have you tried a Native Zephyr approach ?

Hi,

I have tried the file system of Zephyr and indeed it does not support relative paths. However, for WAMR applications, the root file system is /, which corresponds to /lfs under Zephyr.

In this case, I think the WAMR application accesses test.txt, and what is displayed under Zephyr is /lfs/test.txt.

[lucasAbadFr]

Hi

I have tried the file system of Zephyr and indeed it does not support relative paths.

Indeed, Zephyr doesn't support relative paths, and all examples I've seen use absolute paths. That said, when mounting file systems, it might still resolve a mount point internally when opening a file — but it's not doing general path resolution.

However, for WAMR applications, the root file system is /, which corresponds to /lfs under Zephyr.
In this case, I think the WAMR application accesses test.txt, and what is displayed under Zephyr is /lfs/test.txt.

1. I'm not entirely sure I understand this part. First, what do you mean exactly by "WAMR application"?

   I assume you're referring to a WASM module compiled with wasi-sdk and linked against (wasi) libc. In that case, libc does perform some level of path resolution. However, since Zephyr itself doesn't support relative paths, we had to manually rebuild absolute paths in the WAMR Zephyr port using this function:

   wasm-micro-runtime/core/shared/platform/zephyr/zephyr_file.c

   Lines 95 to 113 in 442ea20

   	bool
   	build_absolute_path(char *abs_path, size_t abs_path_len, const char *path)
   	{
   	if (!path) {
   	abs_path[0] = '\0';
   	return false;
   	}
   	size_t len1 = strlen(prestat_dir);
   	size_t len2 = strlen(path);
   	if (len1 + 1 + len2 + 1 > abs_path_len) {
   	abs_path[0] = '\0'; // Empty string on error
   	return false; // Truncation would occur
   	}
   	snprintf(abs_path, abs_path_len, "%s/%s", prestat_dir, path);
   	return true;
   	}

   You could try calling:

   fd = open("./test.txt", O_CREAT | O_RDWR);

   ...but I'm not even sure this will work.

   Alternatively, you can add a log inside the os_openat function to see the final resolved path. That might help pinpoint the issue, it could be something as simple as it trying to open /lfs//test.txt instead of /lfs/test.txt.

   In the meantime I will re-install the wasm toolchain and double-check what behavior I get.

2. Are you expecting the WAMR runtime to internally map the preopened directory (e.g., /lfs) to the root path /?

   While that could be implemented, I believe it would be a bad idea, for several reasons:

   • Zephyr doesn't support relative paths natively, so introducing a fake resolution mechanism in WAMR would be inconsistent with platform behavior.
   • WASM modules are already relatively heavy for embedded systems; adding a full path resolution layer would increase runtime complexity and size.
   • Zephyr allows multiple mounted file systems. Without real path resolution support, it's unclear which FS a relative path should refer to.
   • The WASM runtime (WAMR) supports multiple preopened directories, at least on platforms like Linux. Even though that's not yet supported in the Zephyr port, directly mapping a single preopen to / won't scale when more than one directory is passed.

To conclude, I think the current implementation respects the Zephyr platform constraints and keeps the runtime lightweight and predictable. If platform differences ever require alternate behaviors, wrapping the logic in a #define or configuration flag might be a cleaner solution than introducing automatic path resolution.