Skip to content
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

can lkl based app run on vm #535

Open
qsmen opened this issue Dec 13, 2023 · 4 comments
Open

can lkl based app run on vm #535

qsmen opened this issue Dec 13, 2023 · 4 comments

Comments

@qsmen
Copy link

qsmen commented Dec 13, 2023

Hi,
unikernel (App based on libos) can run on a VM without os. Can the app based on lkl run on vm without os too? if not, I choose to compile the app in its targeted enviroment. i.e, if it runs in linux , i compile it in linux.
I want to use lkl to compile a single address space app.
Thank you.
qsmen

@fish4terrisa-MSDSM
Copy link

Hi, unikernel (App based on libos) can run on a VM without os. Can the app based on lkl run on vm without os too? if not, I choose to compile the app in its targeted enviroment. i.e, if it runs in linux , i compile it in linux. I want to use lkl to compile a single address space app. Thank you. qsmen

It runs on linux and some other platforms(mainly linux)

@qsmen
Copy link
Author

qsmen commented Dec 14, 2023

Hi, unikernel (App based on libos) can run on a VM without os. Can the app based on lkl run on vm without os too? if not, I choose to compile the app in its targeted enviroment. i.e, if it runs in linux , i compile it in linux. I want to use lkl to compile a single address space app. Thank you. qsmen

It runs on linux and some other platforms(mainly linux)

I see. Thank you.
It is said that "LKL can run in any environment, as long as the environment provides a few basic primitives" in the paper lkl. My questions are:
1).what are the few primitives? just the io syscalls supported by VMM?
2). If so, a VMM already implemented the few primitives, can the lkl-based app run in a VM?
3).and is the linked lkl-based app similar to the concept of unikernel? That is, the app is selfcontained except io syscall.

@fish4terrisa-MSDSM
Copy link

fish4terrisa-MSDSM commented Dec 14, 2023

Hi, unikernel (App based on libos) can run on a VM without os. Can the app based on lkl run on vm without os too? if not, I choose to compile the app in its targeted enviroment. i.e, if it runs in linux , i compile it in linux. I want to use lkl to compile a single address space app. Thank you. qsmen

It runs on linux and some other platforms(mainly linux)

I see. Thank you. It is said that "LKL can run in any environment, as long as the environment provides a few basic primitives" in the paper lkl. My questions are: 1).what are the few primitives? just the io syscalls supported by VMM? 2). If so, a VMM already implemented the few primitives, can the lkl-based app run in a VM? 3).and is the linked lkl-based app similar to the concept of unikernel? That is, the app is selfcontained except io syscall.

I don't know much about 1) and 2). However, lkl is like a unikernel, but nearly all its syscall is selfcontained(However, host syscall can be called indirectly.

@thehajime
Copy link
Member

1).what are the few primitives? just the io syscalls supported by VMM?
2). If so, a VMM already implemented the few primitives, can the lkl-based app run in a VM?
3).and is the linked lkl-based app similar to the concept of unikernel? That is, the app is selfcontained except io syscall.

there is my previous attempt to integrate LKL as a unikernel. ukontainer is a collection of repositories with running application linked with LKL over container runtime. It uses rump hypercall, which interfaces various underlying environment including VMMs (e.g., QEMU, xen), though the ukontainer hasn't implemented so far.

So technically the answer should be, Yes, but not ready yet as far as I'm aware of.

See more detail in my past documents and repositories.

https://github.com/ukontainer/runu
https://dl.acm.org/doi/10.1145/3453933.3454011

thehajime pushed a commit to thehajime/linux that referenced this issue Oct 23, 2024
The altmode device release refers to its parent device, but without keeping
a reference to it.

When registering the altmode, get a reference to the parent and put it in
the release function.

Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues
like this:

[   43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)
[   43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)
[   43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)
[   43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)
[   46.612867] ==================================================================
[   46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129
[   46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48
[   46.614538]
[   46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 lkl#535
[   46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[   46.616042] Workqueue: events kobject_delayed_cleanup
[   46.616446] Call Trace:
[   46.616648]  <TASK>
[   46.616820]  dump_stack_lvl+0x5b/0x7c
[   46.617112]  ? typec_altmode_release+0x38/0x129
[   46.617470]  print_report+0x14c/0x49e
[   46.617769]  ? rcu_read_unlock_sched+0x56/0x69
[   46.618117]  ? __virt_addr_valid+0x19a/0x1ab
[   46.618456]  ? kmem_cache_debug_flags+0xc/0x1d
[   46.618807]  ? typec_altmode_release+0x38/0x129
[   46.619161]  kasan_report+0x8d/0xb4
[   46.619447]  ? typec_altmode_release+0x38/0x129
[   46.619809]  ? process_scheduled_works+0x3cb/0x85f
[   46.620185]  typec_altmode_release+0x38/0x129
[   46.620537]  ? process_scheduled_works+0x3cb/0x85f
[   46.620907]  device_release+0xaf/0xf2
[   46.621206]  kobject_delayed_cleanup+0x13b/0x17a
[   46.621584]  process_scheduled_works+0x4f6/0x85f
[   46.621955]  ? __pfx_process_scheduled_works+0x10/0x10
[   46.622353]  ? hlock_class+0x31/0x9a
[   46.622647]  ? lock_acquired+0x361/0x3c3
[   46.622956]  ? move_linked_works+0x46/0x7d
[   46.623277]  worker_thread+0x1ce/0x291
[   46.623582]  ? __kthread_parkme+0xc8/0xdf
[   46.623900]  ? __pfx_worker_thread+0x10/0x10
[   46.624236]  kthread+0x17e/0x190
[   46.624501]  ? kthread+0xfb/0x190
[   46.624756]  ? __pfx_kthread+0x10/0x10
[   46.625015]  ret_from_fork+0x20/0x40
[   46.625268]  ? __pfx_kthread+0x10/0x10
[   46.625532]  ret_from_fork_asm+0x1a/0x30
[   46.625805]  </TASK>
[   46.625953]
[   46.626056] Allocated by task 678:
[   46.626287]  kasan_save_stack+0x24/0x44
[   46.626555]  kasan_save_track+0x14/0x2d
[   46.626811]  __kasan_kmalloc+0x3f/0x4d
[   46.627049]  __kmalloc_noprof+0x1bf/0x1f0
[   46.627362]  typec_register_port+0x23/0x491
[   46.627698]  cros_typec_probe+0x634/0xbb6
[   46.628026]  platform_probe+0x47/0x8c
[   46.628311]  really_probe+0x20a/0x47d
[   46.628605]  device_driver_attach+0x39/0x72
[   46.628940]  bind_store+0x87/0xd7
[   46.629213]  kernfs_fop_write_iter+0x1aa/0x218
[   46.629574]  vfs_write+0x1d6/0x29b
[   46.629856]  ksys_write+0xcd/0x13b
[   46.630128]  do_syscall_64+0xd4/0x139
[   46.630420]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   46.630820]
[   46.630946] Freed by task 48:
[   46.631182]  kasan_save_stack+0x24/0x44
[   46.631493]  kasan_save_track+0x14/0x2d
[   46.631799]  kasan_save_free_info+0x3f/0x4d
[   46.632144]  __kasan_slab_free+0x37/0x45
[   46.632474]  kfree+0x1d4/0x252
[   46.632725]  device_release+0xaf/0xf2
[   46.633017]  kobject_delayed_cleanup+0x13b/0x17a
[   46.633388]  process_scheduled_works+0x4f6/0x85f
[   46.633764]  worker_thread+0x1ce/0x291
[   46.634065]  kthread+0x17e/0x190
[   46.634324]  ret_from_fork+0x20/0x40
[   46.634621]  ret_from_fork_asm+0x1a/0x30

Fixes: 8a37d87 ("usb: typec: Bus type for alternate modes")
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Reviewed-by: Heikki Krogerus <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants