search for: ebpf

On 09/18/2017 10:47 PM, Jiong Wang wrote: > Hi, > > Currently, LLVM eBPF backend always generate code in 64-bit mode, this may > cause troubles when JITing to 32-bit targets. > > For example, it is quite common for XDP eBPF program to access some packet > fields through base + offset that the default eBPF will generate BPF_ALU64 for > the address forma...

On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote: > On 18/09/2017 22:29, Daniel Borkmann wrote: > > On 09/18/2017 10:47 PM, Jiong Wang wrote: > > > Hi, > > > > > >    Currently, LLVM eBPF backend always generate code in 64-bit mode, > > > this may > > > cause troubles when JITing to 32-bit targets. > > > > > >    For example, it is quite common for XDP eBPF program to access > > > some packet > > > fields through base + offset t...

...12:20:40AM +0100, Jiong Wang via iovisor-dev wrote: >> >>> On 18/09/2017 22:29, Daniel Borkmann wrote: >> >>>> On 09/18/2017 10:47 PM, Jiong Wang wrote: >> >>>>> Hi, >> >>>>> >> >>>>> Currently, LLVM eBPF backend always generate code in 64-bit mode, >> >>>>> this may >> >>>>> cause troubles when JITing to 32-bit targets. >> >>>>> >> >>>>> For example, it is quite common for XDP eBPF program to access >> &gt...

...h will obviously result in r1 == 0xffffffff00000000. LLVM should > not assume r1.hi is cleared, but I'm not sure this is a strong enough > argument. llvm will assume that r1.hi is cleared. 32-bit subregisters were defined on the day one. See Documentation/networking/filter.txt "All eBPF registers are 64-bit with 32-bit lower subregisters that zero-extend into 64-bit if they are being written to." If some JIT is not clearing upper bits, it's a bug or it's being too smart :) We can add analysis pass to the verifier to help JITs in such case.

...utils-devel at lists.fedorahosted.org/message/OEOF26ZHEJLHPOMRMOGDXTMYXUHPWVGA/ > > I haven't sent one yet for binutils. > >>> + EM_BPF = 0xeb9f, // Linux kernel bpf virtual machine Great, can that be assumed the final magic e_machine number for the ELF header that eBPF loaders can check for as well then (I do like 0xeb9f ;))? >> was this id reserved this with whoever managing the numbers ? >> The only reason bpf backend used em_none is that we were couldn't >> figure out who's responsible for keeping these records. > > No, it'...

On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: >>>> You could probably >>>> even handle the Tx queue selection via a simple eBPF program and map >>>> since the input for whatever is used to select Tx should be pretty >>>> simple, destination MAC, source NUMA node, etc, and the data-set >>>> shouldn't be too large. >>> That sounds interesting. A separate device might make this...

On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: >>>> You could probably >>>> even handle the Tx queue selection via a simple eBPF program and map >>>> since the input for whatever is used to select Tx should be pretty >>>> simple, destination MAC, source NUMA node, etc, and the data-set >>>> shouldn't be too large. >>> That sounds interesting. A separate device might make this...

...[ 0.048241] LSM: initializing lsm=lockdown,capability,landlock,yama,integrity,apparmor,tomoyo,bpf [ 0.048250] landlock: Up and running. [ 0.048250] Yama: becoming mindful. [ 0.048293] AppArmor: AppArmor initialized [ 0.048295] TOMOYO Linux initialized [ 0.048300] LSM support for eBPF active But from the source it seems that eBPF creates all hooks and returns the default value of 0 for inode_init_security: include/linux/lsm_hook_defs.h:LSM_HOOK(int, 0, inode_init_security, struct inode *inode, kernel/bpf/bpf_lsm.c:#define LSM_HOOK(RET, DEFAULT, NAME, ...) \ kernel/bpf/bpf_ls...

...PM -0800, Samudrala, Sridhar wrote: >> On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: >> > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: >> > > > > You could probably >> > > > > even handle the Tx queue selection via a simple eBPF program and map >> > > > > since the input for whatever is used to select Tx should be pretty >> > > > > simple, destination MAC, source NUMA node, etc, and the data-set >> > > > > shouldn't be too large. >> > > > That sounds...

...efactoring that was done by a bunch of people over the last 5 month didn't cause any problems for them or for the backend - it was accidentally included in the last night builds and reverted today. There were no buildbot issues (afaik) - recent press: http://brendangregg.com/blog/2015-05-15/ebpf-one-small-step.html bpf backend has been in-tree since January and has quite a few users, so I think it's time to graduate it from experimental. Thanks!

On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote: > > > + finfo = netdev_priv(failover_dev); > > > + > > > + primary_dev = rtnl_dereference(finfo->primary_dev); > > > + standby_dev = rtnl_dereference(finfo->standby_dev); > > > + > > > + if (slave_dev != primary_dev && slave_dev != standby_dev) > > > +

...ATCH_BPF=m > > > > # CONFIG_BPFILTER is not set > > > > CONFIG_NET_CLS_BPF=m > > > > CONFIG_NET_ACT_BPF=m > > > > CONFIG_BPF_JIT=y > > > > CONFIG_BPF_STREAM_PARSER=y > > > > CONFIG_LWTUNNEL_BPF=y > > > > CONFIG_HAVE_EBPF_JIT=y > > > > CONFIG_BPF_EVENTS=y > > > > # CONFIG_BPF_KPROBE_OVERRIDE is not set > > > > # CONFIG_TEST_BPF is not set > > > > > > Hi > > > > > > I've installed clean archlinux to try this out and it works as expected, &g...

...a >> bridge can receive a packet in on one interface and transmit it on >> another. We don't really need that. This is more of a VEPA type setup >> and doesn't need to be anything all that complex. You could probably >> even handle the Tx queue selection via a simple eBPF program and map >> since the input for whatever is used to select Tx should be pretty >> simple, destination MAC, source NUMA node, etc, and the data-set >> shouldn't be too large. > That sounds interesting. A separate device might make this kind of setup > a bit easier....

...a >> bridge can receive a packet in on one interface and transmit it on >> another. We don't really need that. This is more of a VEPA type setup >> and doesn't need to be anything all that complex. You could probably >> even handle the Tx queue selection via a simple eBPF program and map >> since the input for whatever is used to select Tx should be pretty >> simple, destination MAC, source NUMA node, etc, and the data-set >> shouldn't be too large. > That sounds interesting. A separate device might make this kind of setup > a bit easier....

...e, but makes code ugly. Because of the above two problems, I decided to try clang builtin again. I think that should be the last try. If still not work, then I'd like to stop working on it until I have any better idea (BCC rewriter should be a considerable solution). Let patch series 'Make eBPF programs output data to perf' be merged into upstream without the 'typeid' change. Before the decoding problem solved, we have to let user decode the BPF output themself manually or use perf script or babeltrace script. Thank you. ----------------- EXAMPLE -----------------...

...I or PCIe topology mapping for the devices that can be translated into something we can communicate over the communication channel. After that we also have the added complexity of how do we figure out which Tx path we want to choose. This is one of the reasons why I was thinking of something like a eBPF blob that is handed up from the host side and into the guest to select the Tx queue. That way when we add some new approach such as a NUMA/cpu based netdev selection then we just provide an eBPF blob that does that. Most of this is just theoretical at this point though since I haven't had a cha...

...I or PCIe topology mapping for the devices that can be translated into something we can communicate over the communication channel. After that we also have the added complexity of how do we figure out which Tx path we want to choose. This is one of the reasons why I was thinking of something like a eBPF blob that is handed up from the host side and into the guest to select the Tx queue. That way when we add some new approach such as a NUMA/cpu based netdev selection then we just provide an eBPF blob that does that. Most of this is just theoretical at this point though since I haven't had a cha...

On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: > > > You could probably > > > even handle the Tx queue selection via a simple eBPF program and map > > > since the input for whatever is used to select Tx should be pretty > > > simple, destination MAC, source NUMA node, etc, and the data-set > > > shouldn't be too large. > > That sounds interesting. A separate device might make this kind of s...

...et here anyway. As such generic XDP is the preferred way to handle this since it will work regardless of what lower devices are present. The only advantage of having XDP down at the virtio or VF level would be that it performs better, but at the cost of complexity since we would need to rebind the eBPF program any time a device is hotplugged out and then back in. For now the current approach is in keeping with how bonding and other similar drivers are currently handling this. Thanks. - Alex

...run into this article [1] that explains that even if you > > have all permissions and no SELinux you can still be blocked by > > something called kernel_lockdown and it should appear in dmesg. > > > > Pavel > > > > [1] <https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-lifting-the-kernel-lockdown/> > > Unfortunately, nothing related to kernel lockdowns. My kernel sysrq also > doesn't seem to recognize x, and neither dmesg nor system journal > indicate the system is even booted with lockdowns. I don't run > Secure Boo...