-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Islet rmm memory handling issues #368
Comments
Before reproducing the problem with the provisioning example, I checked if it still has problem with large size files in a simplied setup using virtio-9p in a linux realm. File sizes execution in a linux realm.
Most of the memory operations are involved during the realm launch and virtio usages. |
@bokdeuk-jeong ,
|
Unfortunately(?), islet and tf-rmm show the same results with the debian12.img.
and
|
While running the provisioning setup, we started encountering a truly random errors from various layers of the stack that could not be reproduced in tf-rmm. In detail, we encountered the following errors:
Since we couldn't reproduce them while running tf-rmm there might be some memory issue introduced by islet rmm. We first encountered this issue when we tried to test the application installation using a statically linked rust "hello world" application. It weights about 1MB, due to static linking and debug build. Every time we tried to install it while running islet, the installation process would fail with TLS decrypt error. We then switch to tf-rmm to check if the issue still persisted. To our surprise, it did not. In the next step, we created a lighter "hello world" application that weight only 1KB and managed to get it installed under Islet. This let us conclude that Islet introduces some memory instability that leads to arbitrary corruption when large amounts of data are processed.
Testcases
The big application
example_app
This application consists of a simple loop that prints "I'm alive" with a number and then increments it.
After compiling and packaging the OCI container with this application weights about 1.2MB.
Using:
create-application -n example_app -v latest -i image-registry.net:1337 -o 32 -d 32 -r 5156ae05-1da0-4e7b-a168-ec8d1869890e
Islet rmm
On islet this application failes everytime mostly with some TLS decryption error. Although, sometimes we observed an hash mismatch error suggesting that the TLS layer worked fine but the corruption happend during OCI container image validation.
tf-rmm
On tf-rmm this application works everytime.
The light application
light_app
This application acts similarly but was made to be as small as possible. For this reason, it is written in C and utilizes syscalls directly.
After compiling and packaging, the OCI container with this application weights about 13KB.
Using:
create-application -n light_app -v latest -i image-registry.net:1337 -o 32 -d 32 -r 5156ae05-1da0-4e7b-a168-ec8d1869890e
Islet rmm
Thanks to the lowered application size we were able to launch the
light_app
:Unfortunately, lowering the container size only made error less frequent. We are still noticing error similar to this:
tf-rmm
On tf-rmm everything works just like with the bigger application.
Reproduction
To reproduce this issue you can follow the application provisioning instruction.
Naturally, the realm image was compiled once to ensure that the build process doesn't interfere with the results. I only changed between islet and tf-rmm using the commandline:
./scripts/fvp-cca --normal-world=linux-net --realm=linux --rmm=tf-rmm --hes --rmm-log-level info
for tf-rmm,./scripts/fvp-cca --normal-world=linux-net --realm=linux --rmm=islet --hes --rmm-log-level info
for islet.The rest is exaclty as spcecified in the instruction. The building of test applications used in this issue is also explained in the instruction.
The text was updated successfully, but these errors were encountered: