From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0041C433F5 for ; Wed, 9 Feb 2022 22:38:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236113AbiBIWiW (ORCPT ); Wed, 9 Feb 2022 17:38:22 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:55566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236258AbiBIWiQ (ORCPT ); Wed, 9 Feb 2022 17:38:16 -0500 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82709C1DF65E for ; Wed, 9 Feb 2022 14:38:18 -0800 (PST) Received: by mail-yb1-xb49.google.com with SMTP id f32-20020a25b0a0000000b0061dad37dcd6so7804783ybj.16 for ; Wed, 09 Feb 2022 14:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=Ib123V5iLfjbHcZ4PIw5eMxrsJC+gSwDpXVK3o+dB3g=; b=S9ncoterRMsBZv0Ny234MoaDJTDDS3NyLulE0TB3sbEpy2yvZjoBt0dxyXquO9VPLZ u/oB2oTPAfMp1D03l1U074OIkZBCxo0QhZNGVGzhciQm0x/FrItEwZhUSdP5JdCMF2ZT dwot++JnORcrakDGnFA5rRcqlmKBYeOddD/j6kO0yAiN45ECI+IOTzGfiSMqqx7Oyd9B +moP3fK0OO6vurQZX2i7ppdv/JPwYxgA4KTfKmtM+0p4toeF4ti8rbxSS7FbbwRr7HCY rYYfVsydz3ByHNwvLCdVfQ2A7YkK1z90fz/u/rDk/7K8jG0EPVMIFps13Oese/C+4yJU dKlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=Ib123V5iLfjbHcZ4PIw5eMxrsJC+gSwDpXVK3o+dB3g=; b=GqPZshNWrK9C02qEJ0T2pYUErfms8kptMV/d7S4I961cxkfI4X8ZCamvG2f7EgJ+BV KBjog/SBNG+ORo9iQbSPRELwKzcDrv77WXvC6wVAbcAb9Ffs4Gu4ZHC9I9fX9ixcHKDI 4/X/iSBCPAp91mQYf8+V4pnjCe9w22TGrX5q6ZXKGWQuViyUHLEWOqQ+aj9FplQd4Tps whpe5emFKWda1vnKagkoGgiNqZ1+BKKy9r9hXUKugA6T3wEre+chmNi55LUhjR0hFSWX 4XgnV/txXbPjoSPm0KHXLW8cWwDjhgdpxJalTkDpNgkgm4yG0MLqfA8xM32cO36pJcKM wnxg== X-Gm-Message-State: AOAM533cnBjFpdqrGzZgDastFyUJ/nlpZjKgolJMtUD5yZndLevarRME A8AG97wXPGYkH75+VW9ER1zOl84= X-Google-Smtp-Source: ABdhPJx15MYjWWMuxTVtlE7hisOqrWbFhN/8ONrpccG5UN1JHLZpdqbiClritO5ewf/2VC8rH8XIfW4= X-Received: from sdf2.svl.corp.google.com ([2620:15c:2c4:201:4d3:1afe:7eeb:c0e6]) (user=sdf job=sendgmr) by 2002:a25:fe07:: with SMTP id k7mr4328312ybe.589.1644446297749; Wed, 09 Feb 2022 14:38:17 -0800 (PST) Date: Wed, 9 Feb 2022 14:38:15 -0800 In-Reply-To: Message-Id: Mime-Version: 1.0 References: <20220209210207.dyhi6queg223tsuy@kafai-mbp.dhcp.thefacebook.com> Subject: Re: Override default socket policy per cgroup From: sdf@google.com To: Alexei Starovoitov Cc: Martin KaFai Lau , Alexei Starovoitov , Daniel Borkmann , Network Development , bpf Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 02/09, Alexei Starovoitov wrote: > On Wed, Feb 9, 2022 at 1:51 PM wrote: > > > > On 02/09, Martin KaFai Lau wrote: > > > On Wed, Feb 09, 2022 at 09:03:45AM -0800, sdf@google.com wrote: > > > > Let's say I want to set some default sk_priority for all sockets in > a > > > > specific cgroup. I can do it right now using cgroup/sock_create, > but it > > > > applies only to AF_INET{,6} sockets. I'd like to do the same for raw > > > > (AF_PACKET) sockets and cgroup/sock_create doesn't trigger for > them :-( > > > Other than AF_PACKET and INET[6], do you have use cases for other > > > families? > > > > No, I only need AF_PACKET for now. But I feel like we should create > > a more extensible hook point this time (if we go this route). > > > > > > (1) My naive approach would be to add another > cgroup/sock_post_create > > > > which runs late from __sock_create and triggers on everything. > > > > > > > > (2) Another approach might be to move BPF_CGROUP_RUN_PROG_INET_SOCK > and > > > > make it work with AF_PACKET. This might be not 100% backwards > compatible > > > > but I'd assume that most users should look at the socket family > before > > > > doing anything. (in this case it feels like we can extend > > > > sock_bind/release for af_packets as well, just for accounting > purposes, > > > > without any way to override the target ifindex). > > > If adding a hook at __sock_create, I think having a new > > > CGROUP_POST_SOCK_CREATE > > > may be better instead of messing with the current inet assumption > > > in CGROUP_'INET'_SOCK_CREATE. Running all CGROUP_*_SOCK_CREATE at > > > __sock_create could be a nice cleanup such that a few lines can be > > > removed from inet[6]_create but an extra family check will be needed. > > > > SG. Hopefully I can at least reuse exiting progtype and just introduce > > new hook point in __sock_create. > Can you take a look at what it would take to add cgroup scope > to bpf_lsm ? > __sock_create() already has > security_socket_create and security_socket_post_create > in the right places. > bpf_lsm cannot write directly into PTR_TO_BTF_ID like the 1st 'sock' > pointer. > We can whitelist the write for certain cases. > Maybe prototype it with bpf_lsm and use > bpf_current_task_under_cgroup() helper to limit the scope > before implementing cgroup-scoped bpf_lsm? > There were cases in the past where bpf_lsm hook was in the ideal > spot, but lack of cgroup scoping was a show stopper. > This use case is another example and motivation to extend > what bpf can do with lsm hooks. That's better than > adding a new bpf_cgroup hook in the same location. Cool, if you think we can whitelist some writes in lsm/fentry that might be a perfect solution (especially if it gets per-cgroup scope). I'll try to look in that, thanks!