nuxinl / cloudabi Goto Github PK
View Code? Open in Web Editor NEWDefinitions for the CloudABI data types and system calls
Home Page: https://nuxi.nl/cloudabi/
License: Other
Definitions for the CloudABI data types and system calls
Home Page: https://nuxi.nl/cloudabi/
License: Other
For the last few days, everyone has been talking about the new branch prediction/cache/timing attacks. I've been thinking, maybe this is a good opportunity for CloudABI?
max_timer_precision: 1ms
in the YAML file to limit the maximum resolution of cloudabi_sys_clock_time_get()
. Also something like randomize_clocks: true
to make cloudabi_sys_clock_time_get()
report fuzzy time.(I realize the project is unmaintained, but I'll mention this anyway.)
CloudABI claims that programs that use it have no effect on global resources, so that they can safely be run without a container, VM, or other enclosure mechanism. However, fork bombs are still possible. (Tl;dr: a process forks, and then each child process forks, and then ...)
Is there a way to get user-friendly messages (static str or other) from errno
numbers? I can't see anything except to refer to the table in cloudabi.txt:209.
For comparison, see from_raw_os_error
which uses sys::os::error_string
, which uses strerror_r
internally. It looks like CloudABI error codes don't match up with POSIX error codes so will you provide an equivalent?
What’s the difference between the websites? As a newbie it’s a tad confusing to have to navigate to both for info, and that’s not counting the GitHub source website.
I'm assuming that at some point a syscall might need to be added, and one might need preprocessor definitions to understand which version of CloudABI is available.
Can the ABI version be determined by a preprocessor definition?
Right now all I am finding is __CloudABI__
which is set to the value of 1
:
$ /usr/bin/x86_64-unknown-cloudabi-cc -dM -E - < /dev/null | grep -i abi
#define __CloudABI__ 1
...
I understand that project is not maintained now, but there are too many links which were used and now redirected to nowhere. In particular, it's hard to understand to new user now e.g. how to obtain runtime packages. Probably they could be built manually given instructions from where and how?
I like the idea of CloudABI, and WASM is not substitute for it, so it would be great if it still be usable at least in "frozen" state, so new user could appear, and sometimes hopefully new maintainers!
The right rights.fd_datasync includes "If rights.file_open
is set, includes the right to invoke file_open
with fdflags.dsync
." However, if one has the rights.fd_stat_put_flags
right, it would appear one could invoke sys_fd_stat_put_flags
with fdsflags.flags
to set the fdflags.dsync
flag, which would be a way to obtain a file descriptor with fdflags.dsync
without having rights.fd_datasync
.
Consequently, if one wishes to withhold the ability to open files with fdflags.dsync
set, clearing the rights.fd_datasync
right might seem sufficient, but isn't: one must also clear the rights.fd_stat_put_flags
right as well. It would seem more consistent to make sys_fd_stat_put_flags
require rights.fd_datasync
for setting fdflags.dsync
.
Similar considerations apply to rights.fd_sync
, fdflags.rsync
, and fdflags.dsync
.
https://nuxi.nl/cloudabi/freebsd/
'''
[user@freebsd ~]$ sudo pkg install cloudabi-utils
Password:
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating CloudABI repository catalogue...
CloudABI repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'cloudabi-utils' have been found in the repositories
'''
As an engineer, I want to see some basic benchmarks for key performance indicators, so that I have more information when deciding to use CloudABI versus competing tools for sandboxing.
For example, I am interested in seeing how many queries per second the same C/C++ Web server application can provide depending on whether it runs natively (libc) vs. cloudabi-run vs. cloudabi-run -e vs. Docker.
As long as we’re running arbitrary binaries with security in mind, we may as well implement our libc in Rust. This reduces the risk of buffer overflow escapes from our sandbox.
Fortunately, Rust is able to output C-compatible object files. So while cloudlibc could be reimplemented in Rust, there is no technical requirement that user applications be written in Rust; they can continue using a typical C FFI.
I think this should be done with cloudlibc proper, as well as the cloudabi runtime and any dependencies as well, such as the yaml arg parser.
@m-ou-se Thank you for publishing crates to integrate Rust with CloudABI! Could the source for the argdata and cloudabi crates be posted as well? Not sure if these are generated directly from the C or what.
By the way, would love to see the argdata crate build in Rust stable. Is there a way to get this to work without depending on the nightly try_from
feature?
The subscription.clock.identifier
field appears to be unused.
It appears to have become unused when the identifier
field was removed from event_t
.
Obviously, removing this field would be an ABI change, so I don't know if it's worth it, but it would be useful to document it if not.
clock_time_get
has a precision
parameter, which has this documentation:
The maximum lag (exclusive) that the returned
time value may have, compared to its actual
value.
The CloudABI implementations on FreeBSD, Linux, and the emulator don't seem to use this parameter.
One hypothetical use for it might be to allow implementations to return an error in case they can't provide the requested level of precision, however in cloudlibc, clock_time_get
's return value is usually ignored. And applications can use clock_res_get
to learn about the precision they're getting from clock_time_get
.
Is there an expected future use for the precision
parameter?
I think file descriptors tend to use signed 32-bit integers, whereas the Rust crate uses unsigned. How important is it to expand the potential open files that wide, versus the trade-off of losing some type compatibility between libc vs. CloudABI?
This subtle difference makes it a bit harder to write polyglot programs that can target libc and CloudABI, depending on the toolchain applied.
Could the CloudABI runtime support an option to enforce W^X
, in order to reduce the attack surface further? This would minimize the risk of escaping out of the CloudABI runtime into the host.
BOINC is a distributed computing platform currently prioritizing jobs for evaluating COVID-19 vaccines.
macOS, Windows, Linux desktop, Android, and Docker currently supported.
Line 284 in 106ec68
This line should likely be changed to use mem::zeroed() if I'm following correctly that these are C-like structs that are being initialized.
It is not currently defined to perform the reference and field access on the uninitialized memory too, whereas with zeroed this should be fine (at least as I understand it, though I cannot be 100% certain, as some of these details are still in flux).
Hello. Your CloudABI need to be complemented by something. We lack object-oriented shell for it.
What I mean under object-oriented shell? Now the shells work with 3 binary streams and allow only their redirection. It is not fine: what if I need to pass a resource from one process to another? What if I need to pass multiple resources, for example multiple streams? In the case of multiple streams fifo can help, but in case of resources of other types it won't.
The proposial is to use programms as functions with variable number of arguments.
1 Each programm binary has a metadata block in it describing its command line format.
2 The shell reads that metadata block and validates vommand line before executing
3 when executing the shell passes arguments to a programm
4 The arguments are not text strings, they are objects of standardized types. For first time I propose to have the following types : string, number, input stream, output stream, input-output stream, network, error and void.
5 A programm has one return type, it can return either its return type or error.
6 A programm can either return its type and stop or return its type and daemonize itself. In the case it daemonizes itself it can be used by another program through the returned object.
7 Arguments types can be implicitly converted, for example strings can be converted into file descriptors which are iostreams.
Most devices are ran at RTOS, and that's great to unify the RTOS family with linux/unix.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.