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 X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_PASS,USER_AGENT_NEOMUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4AC13C04AB3 for ; Thu, 9 May 2019 23:52:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 14EF12183E for ; Thu, 9 May 2019 23:52:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="P6oowXoX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726784AbfEIXwA (ORCPT ); Thu, 9 May 2019 19:52:00 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:37298 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726704AbfEIXwA (ORCPT ); Thu, 9 May 2019 19:52:00 -0400 Received: by mail-pf1-f193.google.com with SMTP id g3so2150976pfi.4; Thu, 09 May 2019 16:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=dnhhdYAshS1GKWhwftArZcRPf6fExExegf04hvxznZI=; b=P6oowXoXsuchZhKZUKH9CGl1p8vBELELW4vdVRDg2Gz31WVfOruo08HebqHTRNv3ep l3ZD0U4kzShIWNOHNGlvD37bA9yiGGqIlRGS/eLW3d/csy9qbbkuhWG0P9u56n547i82 c6o4c+d90jxPffCaCU1fD7NlecBnO5tRHdOzJRwu7mEbqtykioUvt/51GWwQJn4oPYyu SRFlswVurR2ovp7BhOQ+J1o8JXKN/mk42H6QypzL0ayBxPVGEiMTO9wTcubuXGYsQXW6 Gd6f8QMSbFUfT/EIATb2T5lrzWClEYU7Z2PgpP5PYy3rcIqz31EUwlOLEZw+2CXie41L 0+cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dnhhdYAshS1GKWhwftArZcRPf6fExExegf04hvxznZI=; b=Lq4X6YULwbR6dh+iIJLVdFs3Gf46JrNORSErVSAjMeCS1dJdmpMrmTg3f/qUUFZ30r InfjBi2ATN2FaSz+Ltkm5uoEhpN+vezD3kTqIZUkiRTxU05OA/VjzPatR+uxsNLKyIyc QjBoze2yM4OeCfOf9pr6tobjcmoCzvfuJYw+3bEtrlPGHw8H3v6noIiyhJXy66dBDwPc 8AT1/F6MZg5WuUxYVDxkKg5mHs8R50fbQuCt9Fhz7TW80h75Mia4XqDokVVXak+n2jlG ILQK9vITDdDzJ/3uWs6GzbV78x7I2l1C1gBLMuw5YGVUyuWHMryib2f5zqEj66HWAf8d OBAw== X-Gm-Message-State: APjAAAVyrOD6+qzIWS4QR0Ipl4BtzZGDqNupZy2mJmPwtohslbohwBWq 6ZJ9AoswBEZDSIPslDpyB6w= X-Google-Smtp-Source: APXvYqyn2FEc18kwEwcsK2EyYIxzDsjcVX+updFaKLTYuG4pKJys2qCBprosQhRtFw7czkzclu1Rxw== X-Received: by 2002:a63:c64a:: with SMTP id x10mr9404456pgg.195.1557445918490; Thu, 09 May 2019 16:51:58 -0700 (PDT) Received: from ast-mbp ([2620:10d:c090:200::bc44]) by smtp.gmail.com with ESMTPSA id y3sm4838608pfe.9.2019.05.09.16.51.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 May 2019 16:51:57 -0700 (PDT) Date: Thu, 9 May 2019 16:51:56 -0700 From: Alexei Starovoitov To: Eric Dumazet Cc: Daniel Borkmann , Alexei Starovoitov , netdev , bpf , Kees Cook , Andy Lutomirski , Jann Horn , Will Drewry Subject: Re: Question about seccomp / bpf Message-ID: <20190509235154.6h2vbzb2ovwubqtr@ast-mbp> References: <20190508230941.6rqccgijqzkxmz4t@ast-mbp> <20190509044720.fxlcldi74atev5id@ast-mbp> <20190509233023.jrezshp2aglvoieo@ast-mbp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180223 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, May 09, 2019 at 04:50:12PM -0700, Eric Dumazet wrote: > On Thu, May 9, 2019 at 4:30 PM Alexei Starovoitov > wrote: > > > > On Thu, May 09, 2019 at 01:49:25PM +0200, Daniel Borkmann wrote: > > > On 05/09/2019 12:58 PM, Eric Dumazet wrote: > > > > On Thu, May 9, 2019 at 3:52 AM Eric Dumazet wrote: > > > >> On Wed, May 8, 2019 at 9:47 PM Alexei Starovoitov > > > >> wrote: > > > >>> On Wed, May 08, 2019 at 04:17:29PM -0700, Eric Dumazet wrote: > > > >>>> On Wed, May 8, 2019 at 4:09 PM Alexei Starovoitov > > > >>>> wrote: > > > >>>>> On Wed, May 08, 2019 at 02:21:52PM -0700, Eric Dumazet wrote: > > > >>>>>> Hi Alexei and Daniel > > > >>>>>> > > > >>>>>> I have a question about seccomp. > > > >>>>>> > > > >>>>>> It seems that after this patch, seccomp no longer needs a helper > > > >>>>>> (seccomp_bpf_load()) > > > >>>>>> > > > >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd4cf0ed331a275e9bf5a49e6d0fd55dffc551b8 > > > >>>>>> > > > >>>>>> Are we detecting that a particular JIT code needs to call at least one > > > >>>>>> function from the kernel at all ? > > > >>>>> > > > >>>>> Currently we don't track such things and trying very hard to avoid > > > >>>>> any special cases for classic vs extended. > > > >>>>> > > > >>>>>> If the filter contains self-contained code (no call, just inline > > > >>>>>> code), then we could use any room in whole vmalloc space, > > > >>>>>> not only from the modules (which is something like 2GB total on x86_64) > > > >>>>> > > > >>>>> I believe there was an effort to make bpf progs and other executable things > > > >>>>> to be everywhere too, but I lost the track of it. > > > >>>>> It's not that hard to tweak x64 jit to emit 64-bit calls to helpers > > > >>>>> when delta between call insn and a helper is more than 32-bit that fits > > > >>>>> into call insn. iirc there was even such patch floating around. > > > >>>>> > > > >>>>> but what motivated you question? do you see 2GB space being full?! > > > >>>> > > > >>>> A customer seems to hit the limit, with about 75,000 threads, > > > >>>> each one having a seccomp filter with 6 pages (plus one guard page > > > >>>> given by vmalloc) > > > >>> > > > >>> Since cbpf doesn't have "fd as a program" concept I suspect > > > >>> the same program was loaded 75k times. What a waste of kernel memory. > > > >>> And, no, we're not going to extend or fix cbpf for this. > > > >>> cbpf is frozen. seccomp needs to start using ebpf. > > > >>> It can have one program to secure all threads. > > > >>> If necessary single program can be customized via bpf maps > > > >>> for each thread. > > > >> > > > >> Yes, docker seems to have a very generic implementation and should > > > >> probably be fixed > > > >> ( https://github.com/moby/moby/blob/v17.03.2-ce/profiles/seccomp/seccomp.go ) > > > > > > > > Even if the seccomp program was optimized to a few bytes, it would > > > > still consume at least 2 pages in module vmalloc space, > > > > so the limit in number of concurrent programs would be around 262,144 > > > > > > > > We might ask seccomp guys to detect that the same program is used, by > > > > maintaining a hash of already loaded ones. > > > > ( I see struct seccomp_filter has a @usage refcount_t ) > > > > > > +1, that would indeed be worth to pursue as a short term solution. > > > > I'm not sure how that can work. seccomp's prctl accepts a list of insns. > > There is no handle. > > kernel can keep a hashtable of all progs ever loaded and do a search > > in it before loading another one, but that's an ugly hack. > > I guess that if such a hack is doable and can save 2GB of memory, then > it is an acceptable one. sounds that user space can and should be fixed first.