Jarkko Sakkinen
jarkko
https://github.com/rust-vmm/vm-memory/issues/371
https://github.com/enarx/enarx/pull/2617
This is not super important for me but I talked about this with vm-memory year ago and then I did not have any code to demonstrate the issue so it bothered me :-)
https://github.com/enarx/enarx/pull/2617
This is not super important for me but I talked about this with vm-memory year ago and then I did not have any code to demonstrate the issue so it bothered me :-)
0
0
1
@suihkulokki @stsquad And defining memory layout etc. it's all unsafe. You can probably make it syntactically nicer and feel less unsafe but in the end of the day you're still out of the sandbox you're defining. Syntax does add to complexity in this sense, and it is the price of using Rust.
0
0
0
@suihkulokki @stsquad It's exactly like that. It's near proximity enough that if you've looked a lot of C and Assembly during course of your life it is easy to have in the ballpark idea of how C will transform.
1
0
1
Jarkko Sakkinen
jarkko
The first time I got copilot feedback: https://github.com/himmelblau-idm/himmelblau/pull/1079
4/7 require additional feedback i.e., this pretty much explains why *what* is really the time consuming part, at least when aiming to production quality. In other words, you have unlimited ways to implement a functionality but no computation can cherry pick exactly right form from the unlimited options.
4/7 require additional feedback i.e., this pretty much explains why *what* is really the time consuming part, at least when aiming to production quality. In other words, you have unlimited ways to implement a functionality but no computation can cherry pick exactly right form from the unlimited options.
0
0
1
@stsquad Area where I still don't think Rust has an edge: early initialization code of kernel. In that it is super important to roughly have an idea of the generated assembly code while you develop and debug it. You are defining the basic constraints of e.g. mm at that point of time, so I just don't pragmatically get Rust at that point.
I don't believe one-tool-conquers-it-all world. Everything should be evaluated by the context.
I don't believe one-tool-conquers-it-all world. Everything should be evaluated by the context.
1
0
1
Jarkko Sakkinen
jarkko
@troglobit This is basically collecting the fruits of what I created during the Fall :-)
0
0
1
Jarkko Sakkinen
jarkko
@vbabka At least when it comes to protocol itself I want to base it on https://crates.io/crates/tpm2-protocol but I have to look if some of the code lke crypto primitives would be reusable. I'll take a look at it :-)
tpm2-protocol crate that I did defines a syntax macros to define the full TCG protocol in a bidirectonial way so that it can parse and emit to both directions. And I believe it is the most advanced peace of code for this particular niche :-) That's why it was so easy to ramp beginnings of a QEMU patch.
tpm2-protocol crate that I did defines a syntax macros to define the full TCG protocol in a bidirectonial way so that it can parse and emit to both directions. And I believe it is the most advanced peace of code for this particular niche :-) That's why it was so easy to ramp beginnings of a QEMU patch.
1
0
1
Jarkko Sakkinen
jarkko
I started rebasing and tuning dhowell's old container patches.
Right now I've bumped into use of "init_cred", which was made static in the recent past.
I guess I can address this by:
1. Removing static initialization of the field from struct container.
2. Adding a snippet of code to kernel initialization that assigns the same field dynamically using kernel_cred().
Is this the path I should take?
#linux #kernel
Right now I've bumped into use of "init_cred", which was made static in the recent past.
I guess I can address this by:
1. Removing static initialization of the field from struct container.
2. Adding a snippet of code to kernel initialization that assigns the same field dynamically using kernel_cred().
Is this the path I should take?
#linux #kernel
1
0
0
Jarkko Sakkinen
jarkko
0
1
1
@jani @dennyhenke @miiko and a small supporting tool i did for opening html emails: https://crates.io/crates/mailweb
0
0
1
Jarkko Sakkinen
jarkko
Edited 3 months ago
Created beginnings of TPM 2.0 emulator integrated directly to QEMU based on Infineon SLB9672. It requires compilation with optionally enabled Rust shenanigans.
Right now it processes only self-test, reading of capabilities and stuff like that but is bound and wired to qemu. I.e. can do "-tpmdev vtpm,id=tpm0".
Not out anytime soon but will be out in foreseeable future :-)
#qemu #tpm #emulator
Right now it processes only self-test, reading of capabilities and stuff like that but is bound and wired to qemu. I.e. can do "-tpmdev vtpm,id=tpm0".
Not out anytime soon but will be out in foreseeable future :-)
#qemu #tpm #emulator
3
4
10
@dennyhenke @jani @miiko Inbox privacy is irrelevant tbh :-) If you want privacy in that context, sign/encrypt your email.
Inbox encryption does not seal SMTP.
Inbox encryption does not seal SMTP.
0
0
0
Jarkko Sakkinen
jarkko
Edited 3 months ago
Speaking of swcam R&D benefits.
I talked about drones at LKML but you don't have to go that far in order to find useful places to improve QA using a software-define camera.
E.g., one could use it to improve tests of libcamera, pipewire and gstreamer ;-)
EDIT: and it could be utilized with WSL2 to provide video source for the VM environment.
I talked about drones at LKML but you don't have to go that far in order to find useful places to improve QA using a software-define camera.
E.g., one could use it to improve tests of libcamera, pipewire and gstreamer ;-)
EDIT: and it could be utilized with WSL2 to provide video source for the VM environment.
0
0
2
@jani I appreciate this but as said I don't *expect* this :-) However, hopefully this happens rather sooner than later!
This episode of life left me sort of speechless in the sense that whenever there is a NACK for a patch that I've made, I pretty much always am informed in enough detail by the maintainers that I'm 100% on the board ditching my own patch.
Now I can dig up these conclusions from the thread(s):
1. Undefined "proprietary driver risk".
2. Pick the versions of libcamera, gstreamer and pipewire plus few hundred megabytes of their dependencies and you're set. Not going to test this theory, one week is enough ;-)
3. We just don't want to do it despite all these objective facts and undeniable security impact, which never can be fully closed by doing random user space libraries.
I'm not really dissapointed, as I cannot be when I do the "right thing" - acceptance is secondary. Now I played my hand correctly and this is the unfortunate outcome :-)
This episode of life left me sort of speechless in the sense that whenever there is a NACK for a patch that I've made, I pretty much always am informed in enough detail by the maintainers that I'm 100% on the board ditching my own patch.
Now I can dig up these conclusions from the thread(s):
1. Undefined "proprietary driver risk".
2. Pick the versions of libcamera, gstreamer and pipewire plus few hundred megabytes of their dependencies and you're set. Not going to test this theory, one week is enough ;-)
3. We just don't want to do it despite all these objective facts and undeniable security impact, which never can be fully closed by doing random user space libraries.
I'm not really dissapointed, as I cannot be when I do the "right thing" - acceptance is secondary. Now I played my hand correctly and this is the unfortunate outcome :-)
0
0
1