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: Tue, 21 Apr 2020 07:49:23 -0600 From: David Ahern <dsahern@...il.com> To: Toke Høiland-Jørgensen <toke@...hat.com>, David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org Cc: davem@...emloft.net, kuba@...nel.org, prashantbhole.linux@...il.com, jasowang@...hat.com, brouer@...hat.com, toshiaki.makita1@...il.com, daniel@...earbox.net, john.fastabend@...il.com, ast@...nel.org, kafai@...com, songliubraving@...com, yhs@...com, andriin@...com, David Ahern <dahern@...italocean.com> Subject: Re: [PATCH bpf-next 04/16] net: Add BPF_XDP_EGRESS as a bpf_attach_type On 4/21/20 7:25 AM, Toke Høiland-Jørgensen wrote: > David Ahern <dsahern@...il.com> writes: > >> On 4/21/20 4:14 AM, Toke Høiland-Jørgensen wrote: >>> As I pointed out on the RFC patch, I'm concerned whether this will work >>> right with freplace programs attaching to XDP programs. It may just be >>> that I'm missing something, but in that case please explain why it >>> works? :) >> >> expected_attach_type is not unique to XDP. freplace is not unique to >> XDP. IF there is a problem, it is not unique to XDP, and any >> enhancements needed to freplace functionality will not be unique to XDP. > > Still needs to be fixed, though :) one problem at a time. I have a long list of items that are directly relevant to what I want to do. > > Also, at least looking through all the is_valid_access functions in > filter.c, they all seem to "fail safe". I.e., specific > expected_attach_type values can permit the program access to additional > ranges. In which case an freplace program that doesn't have the right > attach type will just be rejected if it tries to access such a field. > Whereas here you're *disallowing* something based on a particular > expected_attach_type, so you can end up with an egress program that > should have been rejected by the verifier but isn't because it's missing > the attach_type. There are 6 existing valid access checks on expected_attach_type doing the exact same thing - validating access based on attach type.
Powered by blists - more mailing lists