bus1 / bus1 Goto Github PK
View Code? Open in Web Editor NEWBus1 Out-of-Tree Kernel Module
Home Page: http://www.bus1.org
License: Other
bus1's Introduction
bus1 - Bus1 Kernel Module
DETAILS:
https://github.com/bus1/bus1
BUG REPORTS:
https://github.com/bus1/bus1/issues
GIT:
[email protected]:bus1/bus1.git
https://github.com/bus1/bus1.git
GITWEB:
https://github.com/bus1/bus1
LICENSE:
LGPLv2.1+ (LICENSE.LGPL2.1)
See COPYING for details.
bus1's People
Contributors
Stargazers
Watchers
Forkers
eworm-de teg opendz slowfranklin kragniz maurojr peter-harliman crorvick daann2016 tpruzina iplayinsun azenla dhilip89 edef1c selenologist msekletar dvdhrm justinbrewer portalgun-io lordrasmus wheelcomplex w-simon dyllanzhou kkdwivedi nicememory victoryangbus1's Issues
make tt fails a test
Hi! I had the following output while running bus1 tests.
Could be a bug ?
PS: I know this is currently a work in progress! Feel free ignore/remove this issue!
[e@localhost bus1]$ uname -a
Linux localhost.localdomain 4.4.0-0.rc8.git2.1.fc24.x86_64 #1 SMP Thu Jan 7 16:22:48 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[e@localhost bus1]$ sudo make tt
[sudo] password for e:
make -C /lib/modules/4.4.0-0.rc8.git2.1.fc24.x86_64/build M=/home/e/src/org.bus1/bus1 EXTRA_CFLAGS="-I/home/e/src/org.bus1/bus1/include -DBUS1_SUPER_MAGIC=0x64627573" \
HOST_EXTRACFLAGS="-I/home/e/src/org.bus1/bus1/usr/include" BUS1_EXT=1 \
CONFIG_BUS1=m CONFIG_SAMPLES=y CONFIG_SAMPLE_BUS1=y
make[1]: Entering directory '/usr/src/kernels/4.4.0-0.rc8.git2.1.fc24.x86_64'
LD /home/e/src/org.bus1/bus1/ipc/bus1/built-in.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/active.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/domain.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/filesystem.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/main.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/peer.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/pool.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/queue.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/transaction.o
CC [M] /home/e/src/org.bus1/bus1/ipc/bus1/util.o
LD [M] /home/e/src/org.bus1/bus1/ipc/bus1/bus1.o
LD /home/e/src/org.bus1/bus1/samples/bus1/built-in.o
LD /home/e/src/org.bus1/bus1/built-in.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/e/src/org.bus1/bus1/ipc/bus1/bus1.mod.o
LD [M] /home/e/src/org.bus1/bus1/ipc/bus1/bus1.ko
make[1]: Leaving directory '/usr/src/kernels/4.4.0-0.rc8.git2.1.fc24.x86_64'
CFLAGS="-g -O0" make -C tools/testing/selftests/bus1/
make[1]: Entering directory '/home/e/src/org.bus1/bus1/tools/testing/selftests/bus1'
gcc -g -O0 -I../../../../usr/include/ -c b1-client.c -o b1-client.o
gcc -g -O0 -I../../../../usr/include/ -c b1-test.c -o b1-test.o
gcc -g -O0 -I../../../../usr/include/ -c test-filesystem.c -o test-filesystem.o
gcc -g -O0 -I../../../../usr/include/ -c test-mount.c -o test-mount.o
gcc -g -O0 -I../../../../usr/include/ -c test-peer.c -o test-peer.o
gcc -g -O0 -I../../../../usr/include/ b1-client.o b1-test.o test-filesystem.o test-mount.o test-peer.o -o b1-test
make[1]: Leaving directory '/home/e/src/org.bus1/bus1/tools/testing/selftests/bus1'
sudo sh -c 'dmesg -c > /dev/null'
sudo umount /sys/fs/bus1
umount: /sys/fs/bus1: mountpoint not found
Makefile:125: recipe for target 'tt-prepare' failed
make: [tt-prepare] Error 32 (ignored)
sudo sh -c 'rmmod bus1'
rmmod: ERROR: Module bus1 is not currently loaded
Makefile:125: recipe for target 'tt-prepare' failed
make: [tt-prepare] Error 1 (ignored)
sudo sh -c 'insmod ipc/bus1/bus1.ko'
sudo mount -t bus1fs bus1fs /sys/fs/bus1
tools/testing/selftests/bus1/b1-test --module bus1 ; (R=$? ; dmesg ; exit $R)
Run all tests:
Testing: `filesystem' ...................................... OK
Testing: `mount' ........................................... SKIP
Testing: `peer' ............................................
noop send takes 999 ns
unicast send without payload takes 8508 ns
unicast send/recv without payload takes 13717 ns
multicast 2 messages without payload in 6582 ns per destination
multicast 8 messages without payload in 7902 ns per destination
multicast 32 messages without payload in 11398 ns per destination
multicast 128 messages without payload in 2456 ns per destination
unicast send with payload takes 4086 ns
unicast send/recv with payload takes 6650 ns
multicast 2 messages with payload in 4039 ns per destination
multicast 8 messages with payload in 3184 ns per destination
multicast 32 messages with payload in 3106 ns per destinatio OK
[ 153.914805] bus1: module verification failed: signature and/or required key missing - tainting kernel
[ 153.917130] bus1: initialized
[ 165.477523] BUG: MAX_LOCK_DEPTH too low!
[ 165.477528] turning off the locking correctness validator.
[ 165.477530] Please attach the output of /proc/lock_stat to the bug report
[ 165.477531] depth: 48 max: 48!
[ 165.477533] 48 locks held by b1-test/2707:
[ 165.477534] #0: (&peer->rwlock){++++++}, at: [<ffffffffa0395de5>] bus1_peer_ioctl+0xb5/0x1980 [bus1]
[ 165.477554] #1: (bus1.active#2){++++.+}, at: [<ffffffffa0395e04>] bus1_peer_ioctl+0xd4/0x1980 [bus1]
[ 165.477560] #2: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477566] #3: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477571] #4: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477577] #5: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477582] #6: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477587] #7: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477592] #8: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477598] #9: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477603] #10: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477608] #11: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477613] #12: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477619] #13: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477624] #14: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477629] #15: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477634] #16: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477639] #17: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477644] #18: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477650] #19: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477655] #20: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477660] #21: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477665] #22: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477670] #23: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477675] #24: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477680] #25: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477685] #26: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477691] #27: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477696] #28: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477701] #29: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477706] #30: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477711] #31: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477716] #32: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477721] #33: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477726] #34: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477732] #35: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477749] #36: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477755] #37: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477760] #38: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477765] #39: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477770] #40: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477775] #41: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477780] #42: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477785] #43: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477791] #44: (bus1.active#2){++++.+}, at: [<ffffffffa0395b99>] bus1_peer_acquire_by_id+0x219/0x2f0 [bus1]
[ 165.477796] #45: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff811e70e6>] generic_file_write_iter+0x36/0x1f0
[ 165.477808] #46: (hrtimer_bases.lock){-.-...}, at: [<ffffffff81136620>] hrtimer_interrupt+0x70/0x1d0
[ 165.477817] #47: (tk_core){----..}, at: [<ffffffff8113663d>] hrtimer_interrupt+0x8d/0x1d0
[ 165.477824] INFO: lockdep is turned off.
[ 165.477828] CPU: 0 PID: 2707 Comm: b1-test Tainted: G W OE 4.4.0-0.rc8.git2.1.fc24.x86_64 #1
[ 165.477829] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[ 165.477831] 0000000000000000 00000000242db1f8 ffff8800afc03d80 ffffffff81427eb9
[ 165.477835] ffff88007d6616d8 ffff8800afc03e70 ffffffff81109f32 0000000000000045
[ 165.477837] 0000000000000001 ffff8800afc03e90 0000000000000046 0000000000000000
[ 165.477840] Call Trace:
[ 165.477843] <IRQ> [<ffffffff81427eb9>] dump_stack+0x4b/0x72
[ 165.477852] [<ffffffff81109f32>] __lock_acquire+0xe52/0x1b70
[ 165.477854] [<ffffffff81108ba9>] ? mark_held_locks+0x79/0xa0
[ 165.477859] [<ffffffff8187ee3c>] ? _raw_spin_unlock_irq+0x2c/0x40
[ 165.477861] [<ffffffff8110b5de>] lock_acquire+0xce/0x1c0
[ 165.477863] [<ffffffff8113663d>] ? hrtimer_interrupt+0x8d/0x1d0
[ 165.477867] [<ffffffff8113e65f>] ktime_get_update_offsets_now+0x5f/0x180
[ 165.477869] [<ffffffff8113663d>] ? hrtimer_interrupt+0x8d/0x1d0
[ 165.477871] [<ffffffff8113663d>] hrtimer_interrupt+0x8d/0x1d0
[ 165.477874] [<ffffffff81058f48>] local_apic_timer_interrupt+0x38/0x60
[ 165.477877] [<ffffffff8188268d>] smp_apic_timer_interrupt+0x3d/0x50
[ 165.477879] [<ffffffff818806e1>] apic_timer_interrupt+0x91/0xa0
[ 165.477880] <EOI> [<ffffffff8110b5f6>] ? lock_acquire+0xe6/0x1c0
[ 165.477884] [<ffffffff811e70e6>] ? generic_file_write_iter+0x36/0x1f0
[ 165.477887] [<ffffffff8187baa6>] mutex_lock_nested+0x86/0x400
[ 165.477889] [<ffffffff811e70e6>] ? generic_file_write_iter+0x36/0x1f0
[ 165.477890] [<ffffffff811e70e6>] ? generic_file_write_iter+0x36/0x1f0
[ 165.477893] [<ffffffff811e70e6>] generic_file_write_iter+0x36/0x1f0
[ 165.477896] [<ffffffff81275ff9>] vfs_iter_write+0x79/0xc0
[ 165.477900] [<ffffffffa0397fe3>] bus1_pool_write_iovec+0x73/0xe0 [bus1]
[ 165.477902] [<ffffffffa0398a67>] bus1_transaction_instantiate+0x97/0x130 [bus1]
[ 165.477905] [<ffffffffa0398e7f>] bus1_transaction_instantiate_for_id+0x3f/0x90 [bus1]
[ 165.477908] [<ffffffffa03962f7>] bus1_peer_ioctl+0x5c7/0x1980 [bus1]
[ 165.477910] [<ffffffffa0394b4e>] ? bus1_fs_bus_fop_ioctl_native+0x2e/0x40 [bus1]
[ 165.477912] [<ffffffff81108cf9>] ? trace_hardirqs_on_caller+0x129/0x1b0
[ 165.477915] [<ffffffffa0394b4e>] bus1_fs_bus_fop_ioctl_native+0x2e/0x40 [bus1]
[ 165.477919] [<ffffffff8128b511>] do_vfs_ioctl+0x2f1/0x550
[ 165.477923] [<ffffffff81127b4d>] ? debug_lockdep_rcu_enabled+0x1d/0x20
[ 165.477925] [<ffffffff8128b7e9>] SyS_ioctl+0x79/0x90
[ 165.477927] [<ffffffff8187f872>] entry_SYSCALL_64_fastpath+0x12/0x76
rmmod: ERROR: Module bus1 is in use
I cannot unload bus1 module.
It complains about still being used.
This happens after running bus1 own tests
(but with error)
I don't know how to identify who is using it !!!
Please fell free to discard this issue if there is work in progress ...
[root@dock bus1]# rmmod bus1
rmmod: ERROR: Module bus1 is in use
[root@dock bus1]# lsmod | grep bus1
bus1 53248 2
[root@dock bus1]# modinfo bus1
filename: /lib/modules/4.8.0-0.rc3.git0.1.fc26.x86_64/kernel/ipc/bus1/bus1.ko
description: Bus based interprocess communication
license: GPL
depends:
vermagic: 4.8.0-0.rc3.git0.1.fc26.x86_64 SMP mod_unload
parm: user_slices_max:Max number of slices for each user. (ushort)
parm: user_handles_max:Max number of handles for each user. (ushort)
parm: user_bytes_max:Max number of bytes for each user. (uint)
parm: user_fds_max:Max number of fds for each user. (ushort)
Dedicated flag instead of BUS1_HANDLE_INVALID
Why not use the first bit of a handle as a flag for an invalid handle? Checking for 0 make more sense instead of checking for ((__u64)-1), which btw set the managed and remote flag.
test-io: test.h:102: test_open: Assertion `*mapp != ((void *) -1)' failed
test-io fails when run on a Raspberry. Below is the full output of make tt:
make[1]: Entering directory '/home/scanf/src/github.com/scanf/bus1/tools/testing/selftests/bus1'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/scanf/src/github.com/scanf/bus1/tools/testing/selftests/bus1'
make[1]: Entering directory '/home/scanf/src/tmp/linux-rpi-4.9.y'
LD /home/scanf/src/github.com/scanf/bus1/built-in.o
LD /home/scanf/src/github.com/scanf/bus1/ipc/bus1/built-in.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/handle.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/main.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/message.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/peer.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/tx.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/user.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/util.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/util/active.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/util/flist.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/util/pool.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/util/queue.o
CC [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/tests.o
LD [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/bus1.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/scanf/src/github.com/scanf/bus1/ipc/bus1/bus1.mod.o
LD [M] /home/scanf/src/github.com/scanf/bus1/ipc/bus1/bus1.ko
make[1]: Leaving directory '/home/scanf/src/tmp/linux-rpi-4.9.y'
sudo sh -c 'dmesg -c > /dev/null'
sudo sh -c 'rmmod bus1'
sudo sh -c 'insmod ipc/bus1/bus1.ko'
make[1]: Entering directory '/home/scanf/src/github.com/scanf/bus1/tools/testing/selftests/bus1'
selftests: test-api [PASS]
UDS took 6598 ns without payload
UDS took 10542 ns
test-io: test.h:102: test_open: Assertion `*mapp != ((void *) -1)' failed.
Aborted
selftests: test-io [FAIL]
make[1]: Leaving directory '/home/scanf/src/github.com/scanf/bus1/tools/testing/selftests/bus1'
[ 1654.992491] bus1: unloaded
[ 1655.154023] bus1: run selftests..
[ 1655.156364] bus1: loaded
I am not sure what is going wrong, but it looks like we can't allocate enough
memory. Applying the patch below fixes the issue and the tests pass.
diff --git a/tools/testing/selftests/bus1/test.h b/tools/testing/selftests/bus1/test.h
index fee815e1844d..c8591de6ebe0 100644
--- a/tools/testing/selftests/bus1/test.h
+++ b/tools/testing/selftests/bus1/test.h
@@ -92,7 +92,7 @@ static inline int test_parse_argv(int argc, char **argv)
static inline int test_open(const uint8_t **mapp, size_t *n_mapp)
{
- const size_t size = 16UL * 1024UL * 1024UL;
+ const size_t size = 16UL * 1024UL;
int fd;
fd = open(test_path, O_RDWR | O_CLOEXEC | O_NONBLOCK | O_NOCTTY);
a peer context shared by two processes
Process B received the file descriptor from process A sent by UDS, and mmaped to it, thus process B has access to all nodes of the peer context that process A has created.
But seems that ioctl_recv drops all messages whether a message is destined to it or not, so it is not VERY possible for process B to send a message to process A that sharing the same peer context, suppose process B is receiving messages either.
From bus1 documentation there is a BUS1_RECV_FLAG_PEEK could ignore a message not destined to the node and it seems gone from the source.
I've write demo for testing above, It would be great if I made mistakes and I wish the processes could actually share the same peer context, or which is not actually necessary.
Thank you :)
Priority inheritance (Binder-like)
Binder is able to emulate a thread migration to transfer the client's priority to the receiving thread. Underneath, the kernel set the receiving thread's nice level (cf. binder_set_nice() in drivers/android/binder.c). This priority inheritance is useful to have services at the same nice level as their clients. A safe IPC needs to provide a way to "charge" clients and protect services from being exhausted by their clients. More explanations can be found here: https://lwn.net/Articles/697191/ (Like binder, only better?).
This priority inheritance does not seem to fit well with bus1 because Binder works with a thread-pool whereas bus1 works with a unique thread, polling a peer FD. bus1 needs this unique thread to properly enable message-ordering guarantees.
A simple and secure way to have a similar feature with bus1 would be to add a flag in both the sender and the receiver side. The "flags" field for the BUS1_CMD_SEND command could accept a BUS1_SEND_FLAG_GIVE_PRIORITY flag to enable a client to willingly give its priority (i.e. nice level) with its message. The "flags" field for the BUS1_CMD_RECV command could accept a BUS1_RECV_FLAG_APPLY_PRIORITY to effectively get the client's priority, if wanted by the receiving thread. The BUS1_RECV_FLAG_APPLY_PRIORITY protects the callee thread from unexpected behavior if it was not intended to change its priority. However, if the callee set BUS1_RECV_FLAG_APPLY_PRIORITY but the caller didn't set BUS1_SEND_FLAG_GIVE_PRIORITY, the BUS1_CMD_RECV should failed to prevent unattended behavior as well.
A solution to properly manage this priority transfer may look like this:
- thread A (client) send a message with BUS1_SEND_FLAG_GIVE_PRIORITY
- thread B (service) is notified with epoll(2)
- thread B create a dedicated thread C and wait on a new pipe(2)
- thread C read the message with the BUS1_RECV_FLAG_APPLY_PRIORITY flag to update its priority
- thread C write on the other part of the pipe to unlock thread B, which can go back to the epoll() call (step 2)
- thread C handle the request with the same nice level as thread A, then exit
One issue with this scenario is that the step 5 may delay thread B because thread C does not have the same priority anymore. It would be nice to handle the lock/unlock mechanism in an atomic way with the BUS1_CMD_RECV command. This could be done with additional flags/commands like BUS1_CMD_PEER_SUSPEND_NOTIFICATION and BUS1_RECV_FLAG_RESUME_NOTIFICATION.
A priority inheritance feature may be a future extension of bus1. This would keep the next patch series a bit smaller, with less code to review. However, I think this kind of feature should be reviewed as soon as possible to find possible pitfalls which could be an issue for the evolution of the bus1 UAPI.
What do you think about this design? Did you plan something similar?
I noticed that BUS1_RECV_FLAG_PEEK was recently removed (commit 53daeb3). I think this command may be useful for a receiving thread to protect itself from a file descriptor exhaustion attack. Another way would be to be able to tie a "contract" to an handle to act like a firewall/filter. This could be done with a dedicated eBPF program similar to BPF_PROG_TYPE_SOCKET_FILTER, though.
[Question] Why handles are transitive?
Hey @dvdhrm
The website explains that access rights can be passed transitively
However, access rights can be transmitted as auxiliary data with any message, effectively granting them to the receiver of the message. This even works transitively, that is, any peer that was granted access to an object can pass on those rights, even if they do not own the object.
Handles are local to each peer, but can be transmitted as auxiliary data with any message, effectively allocating a new handle to the same node in the destination peer. This works transitively, and each peer that holds a handle can pass it on further, or deliberately drop it.
Can you elaborate why such design decision was made? What use-cases does this allow?
What about security implications? Here is an abstract example:
For example Peer Context 1(PC1) does not want to grant access to Peer1(P1), but it grants it to P2.
P2 shares the handle with P1, defeating security policy of PC1.
replace c with rust
Before we build a new complex system software in a memory insecure language like C, which we know for sure will lead to hundreds of security issues even with the best guidelines in place, why not use a modern alternative like rust to avoid this kind of issue, leading to 95% less bugs and security issues with no effort.
State/Status of project now that we have dbus-broker?
Just wondering where you guys stand with pursing this project now that dbus-broker seems to solve a lot of problems the community has had with dbus. Maybe trojan horse this guy in at some later date?
Diagrams on the website
It would be good if the website included some diagrams to make it easier to understand.
FTBFS with c-sundry 0~29
With c-sundry 8deaceba08f06348c3825b2c99b4393e9e589bb9, bus1 no longer builds:
[ 34s] In file included from src/message.c:14:0:
[ 34s] src/message.h:15:9: error: unknown type name 'CRef'
[ 34s] CRef ref;
[ 34s] ^~~~
file descriptor exhaustion attack
From #58:
I noticed that BUS1_RECV_FLAG_PEEK was recently removed (commit 53daeb3). I think this command may be useful for a receiving thread to protect itself from a file descriptor exhaustion attack. Another way would be to be able to tie a "contract" to an handle to act like a firewall/filter. This could be done with a dedicated eBPF program similar to BPF_PROG_TYPE_SOCKET_FILTER, though.
Now, regarding your second question (if this turns into a longer discussion, I'd prefer doing it as a separate issue): Care to elaborate how PEEK is useful against FD exhaustion attacks? In a single-threaded dispatcher, you can simply close the FDs once received. If you don't want FDs, don't use BUS1_RECV_FLAG_INSTALL_FDS.
Looking at a message to decide whether you want those FDs is a hack, IMO. If the existing API does not serve your security concerns, I'd appreciate if you can elaborate on the exact attack vectors, so we can comment on the issue, rather than on the solution.
Here is a use case: you only want to receive a specific number of FDs, which you may have requested. You could then PEEK the received message and look the number of FDs in it, but without the BUS1_RECV_FLAG_INSTALL_FDS flag. Then, if it seems OK, you could dequeue the message with BUS1_RECV_FLAG_INSTALL_FDS and get the FDs.
It may be an issue to receive a large amount of FDs with a unique message. Is there a way to be protected against this kind of threat?
Thanks,
Mickaël
Project no longer builds?
Hi,
I wanted to experiment with bus1 and tried to install the bus1-dkms-git package from ArchLinux's AUR repos. The package installed successfully, but building the module against kernel 5.9.1 fails. Here's the build log:
DKMS make.log for bus1-r977.20ee2f7 for kernel 5.9.1-arch1-1 (x86_64)
sáb 24 out 2020 07:13:24 -03
make[1]: Entrando no diretório '/usr/lib/modules/5.9.1-arch1-1/build'
AR /var/lib/dkms/bus1/r977.20ee2f7/build/built-in.a
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/handle.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/main.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/message.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/peer.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/tx.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/user.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/active.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/flist.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/pool.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/queue.o
CC [M] /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/tests.o
/var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/tests.c: In function ‘bus1_test_pool’:
/var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/tests.c:168:9: error: implicit declaration of function ‘get_ds’; did you mean ‘get_fs’? [-Werror=implicit-function-declaration]
168 | set_fs(get_ds());
| ^~~~~~
| get_fs
/var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/tests.c:168:9: error: incompatible type for argument 1 of ‘set_fs’
168 | set_fs(get_ds());
| ^~~~~~~~
| |
| int
In file included from ./include/linux/uaccess.h:9,
from /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/tests.c:15:
./arch/x86/include/asm/uaccess.h:29:40: note: expected ‘mm_segment_t’ but argument is of type ‘int’
29 | static inline void set_fs(mm_segment_t fs)
| ~~~~~~~~~~~~~^~
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:283: /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/tests.o] Erro 1
make[3]: ** Esperando que outros processos terminem.
/var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/pool.c: In function ‘bus1_pool_write_kvec’:
/var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/pool.c:503:9: error: implicit declaration of function ‘get_ds’; did you mean ‘get_fs’? [-Werror=implicit-function-declaration]
503 | set_fs(get_ds());
| ^~~~~~
| get_fs
/var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/pool.c:503:9: error: incompatible type for argument 1 of ‘set_fs’
503 | set_fs(get_ds());
| ^~~~~~~~
| |
| int
In file included from ./include/linux/uaccess.h:9,
from ./include/linux/sched/task.h:11,
from ./include/linux/sched/signal.h:9,
from ./include/linux/rcuwait.h:6,
from ./include/linux/percpu-rwsem.h:7,
from ./include/linux/fs.h:33,
from ./include/uapi/linux/aio_abi.h:31,
from ./include/linux/aio.h:5,
from /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/pool.c:11:
./arch/x86/include/asm/uaccess.h:29:40: note: expected ‘mm_segment_t’ but argument is of type ‘int’
29 | static inline void set_fs(mm_segment_t fs)
| ~~~~~~~~~~~~~^~
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:283: /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1/util/pool.o] Erro 1
make[2]: *** [scripts/Makefile.build:500: /var/lib/dkms/bus1/r977.20ee2f7/build/ipc/bus1] Erro 2
make[1]: *** [Makefile:1784: /var/lib/dkms/bus1/r977.20ee2f7/build] Erro 2
make[1]: Saindo do diretório '/usr/lib/modules/5.9.1-arch1-1/build'
make: *** [Makefile:53: module] Erro 2
Examples of API usage
Hi,
I am doing some research around this nice new feature for a Company. It all seems very nice, but I am missing some simple "get started" examples of the API. I did use the unit-tests as examples, but that is not optimal, and lacks documentation/minor explanations.
I had to read much of the code-base to get started. Some small examples would be great and will also faster increase the user base.
bus1 tests - "INFO: suspicious RCU usage"
Hi!
bus1 outputs an OK to all tests!
But at the same time there is a kernel warning message:
[ 130.167965] "INFO: suspicious RCU usage."
[ 130.170209] 1 lock held by bus1-test/1475:
[ 130.170401] #0: (bus1.active){++++.+}, at: [] bus1_fop_ioctl+0x57/0x1d0 [bus1]
Complete test log messages are on anexed file.
PS: I found a similiar complain on LKML, but with a different stack trace, on the subject: "[writeback] 8bc4ad9498: INFO: suspicious RCU usage. ]".
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.