lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 25 Jan 2017 05:12:56 +0200 From: "Michael S. Tsirkin" <mst@...hat.com> To: Jason Wang <jasowang@...hat.com> Cc: John Fastabend <john.fastabend@...il.com>, john.r.fastabend@...el.com, netdev@...r.kernel.org, alexei.starovoitov@...il.com, daniel@...earbox.net Subject: Re: XDP offload to hypervisor On Wed, Jan 25, 2017 at 10:41:24AM +0800, Jason Wang wrote: > > > On 2017年01月24日 05:40, Michael S. Tsirkin wrote: > > I've been thinking about passing XDP programs from guest to the > > hypervisor. Basically, after getting an incoming packet, we could run > > an XDP program in host kernel. > > > > If the result is XDP_DROP or XDP_TX we don't need to wake up the guest at all! > > Interesting, but there're some questions: > > - This may work well for XDP_DROP and XDP_TX, and manage to work for > XDP_PASS. But what if XDP were extend for other capabilities in the future? > E.g forward to other interface or userspace? This is exactly what I am saying. Any future extensions will need feature negotiation. > - For XDP_DROP, it can be done through socket filter. > - Need to translate XDP_TX as something like XDP_RX at least for tun. Or it > may bring some confusion if tun support XDP or XDP were supported in tx > patch in the future. > > > > > When using tun for networking - especially with adjust_head - this > > unfortunately probably means we need to do a data copy unless there is > > enough headroom. How much is enough though? > > Not a tun specific issue I believe? It is tun specific because tun gets skbs from linux net core while XDP expects pre-skb pages. > > > > Another issue is around host/guest ABI. Guest BPF could add new features > > at any point. What if hypervisor can not support it all? I guess we > > could try loading program into hypervisor and run it within guest on > > failure to load, but this ignores question of cross-version > > compatibility - someone might start guest on a new host > > then try to move to an old one. So we will need an option > > "behave like an older host" such that guest can start and then > > move to an older host later. > > I'm suspect whether or not this can be done easily. > > > This will likely mean > > implementing this validation of programs in qemu userspace unless linux > > can supply something like this. Is this (disabling some features) > > something that might be of interest to larger bpf community? > > > > With a device such as macvtap there exist configurations where a single > > guest is in control of the device (aka passthrough mode) in that case > > there's a potential to run xdp on host before host skb is built, unless > > host already has an xdp program attached. If it does we could run the > > program within guest, but what if a guest program got attached first? > > Maybe we should pass a flag in the packet "xdp passed on this packet in > > host". Then, guest can skip running it. Unless we do a full reset > > there's always a potential for packets to slip through, e.g. on xdp > > program changes. Maybe a flush command is needed, or force queue or > > device reset to make sure nothing is going on. Does this make sense? > > > > Thanks! > >
Powered by blists - more mailing lists