Hi Stephen,
I'm happy to hear that.
In the future, please take care to reply to the list too, such that others can
learn as well. :-)
Cheers,
Philipp
Am 12.06.25 um 8:34 AM schrieb yy18513676366:
Hi Philipp,
Thank you for your reply — it was truly helpful to me.
I believe I have identified the root cause of the issue. I had assigned full
permissions to all capabilities using :svr(), which included the L4_CAP_FPAGE_D
right. This permission caused kernel objects to be forcibly deleted. After I
adjusted the capability permissions to m("rwncs"), the problem was resolved.
I do not yet have a deep enough understanding of capabilities, their permission
flags, and the mapping process via l4_task_map.
Regarding the restart procedure — it is actually quite straightforward.
According to the documentation, the L4Re::Parent::signal interface can be used
to terminate a running program. So I terminate uvmm first, and then restart it
using the ned script, just like at the beginning. In this way, the guest OS is
relaunched.
Through this process, I’ve come to appreciate the stability of L4Re. It is
reassuring to see that the crash of a single application does not affect other
programs.
Once again, thank you for your support and assistance.
Best regards,
Stephen.yang
At 2025-06-11 17:21:32, "Philipp Eppelt" wrote:
Hi Stephen,
I don't quite follow your description, can you please show your ned script to
help my understanding?
Wrt 1.: To actively delete a kernel object, you need a capability possessing
delete rights and call `l4_task_unmap()` featuring the delete flag or
`l4_task_delete_obj()`.
Otherwise, the kernel object gets deleted, when the reference count drops to
zero, meaning there are no more capabilities holding a reference to this kernel
object.
An application can release its reference, but still possess the capability. Or a
capability can be mapped to another application without increasing the reference
count.
To answer 2 and 3 I first need to understand your reboot workflow.
Cheers,
Philipp
Am 10.06.25 um 10:27 AM schrieb yy18513676366:
Hello,
I am currently conducting research using the L4Re system, and I am working on
implementing a mechanism to reboot a Guest OS managed by UVMM.
In my setup, I run two Linux instances under UVMM. My goal is to reboot one of
them without affecting the other.
To achieve this, I terminate the target instance by sending a signal using |
L4Re::Parent::signal|, and then I restart it using a Ned script to launch a new
instance of the same program.
When restarting, I reuse the capability that was created during the first launch
of the UVMM instance.
However, during execution, the restarted program encounters an *"invalid
capability invoke"* error.
Upon investigation, I suspect this happens because |l4_task_unmap| was called
during the restart process, which likely removed kernel objects associated with
the original capability. As a result, the reused |cap_index| no longer refers to
a valid object.
Based on this, I would appreciate your insights on the following questions:
1.
Under what conditions are kernel objects deleted in L4Re?
2.
In this rebooting workflow, how can we ensure that capabilities remain valid
or that their associated kernel objects are not prematurely unmapped or
deleted?
3.
If UVMM crashes during operation, how can we design a mechanism to ensure
system-wide stability and security?
Thank you in advance for your valuable feedback!
Best regards,
stephen.yang
___
l4-hackers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
[email protected] - Tel. 0351-41 883 221
http://www.kernkonzept.com
Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129.
Geschäftsführer: Dr.-Ing. Michael Hohmuth
--
[email protected] - Tel. 0351-41 883 221
http://www.kernkonzept.com
Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129.
Geschäftsführer: Dr.-Ing. Michael Hohmuth
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
l4-hackers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
