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" philipp.eppelt@kernkonzept.com 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:
Under what conditions are kernel objects deleted in L4Re?
In this rebooting workflow, how can we ensure that capabilities remain valid or that their associated kernel objects are not prematurely unmapped or deleted?
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 -- l4-hackers@os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave@os.inf.tu-dresden.de
-- philipp.eppelt@kernkonzept.com - Tel. 0351-41 883 221 http://www.kernkonzept.com
Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth
l4-hackers@os.inf.tu-dresden.de
-
Philipp Eppelt