Received: by 10.192.165.148 with SMTP id m20csp4993827imm; Tue, 8 May 2018 19:30:10 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrKQnpe0KFTa4FCXNAPKoqsrOF4J929LHFoTzd1Me96l4bExFvNO5YgPa5DKstCnyYKwSw2 X-Received: by 2002:a17:902:ba93:: with SMTP id k19-v6mr24862571pls.379.1525833010698; Tue, 08 May 2018 19:30:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525833010; cv=none; d=google.com; s=arc-20160816; b=r+xdO5R5St0gKgmEawH6sGXyvynxUG7TXXCtE+43WXlua1gfY+nvFF/eq6BaiF66uG ulZwfktL6ypPjdSpjMdq4mCNWscyUmwJtPAil2EiE4z4qghoq5J3cCFesWkU5AKLQPHN sUFSqlCod22oBrTh2BB5K9uKJ9L7/ko5+vEd06pRKeHCFWyu8ifp9KikvSINiVYL7iJF hvbxzvvEU0Iv6lfIZvpDF/ED2i4KFC524w62jFhYKcGUaYvHI2rBZhLdchRZt6v8AV+C hBUMw/wuQA7OH7Rdd3NJUrs06xe2TQfzWAAs3dC2FSV+MHMr6FhZ21DGjdpJFR59Gc7Z L8Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=gQqJfRb+BYJB9x/7qkeKR1CLKP7s2iq6mhx2Xa4oI3Q=; b=QUB3bWyXAVQvAT32nxLdULF8lsvYN/vYvNHMAK+FsytYFLYiKoSYsif7+TiTNWGUF3 hSP93hvq+7+/y3XKOezV9Q19TD3fA6C9i7Uq+l5QGZY4dyvqIylwHgfPSF++ChyqquzG yzd5w3BWD+PP8wRVjJ0XpZCY9J2S2hy848x865xRrfPqjzSZKfkLjrIRc654xhad7cTR 1t+YAmBVvt3RPLrwDeNYGg7ElDDk93889L5BnkS5krf988WIV21Qw/vhGvW939XfPLsd bOb/VfiuYmFb7LoVxRLfeKwYNOWHsgp1eOue19595TkfL5uRV9wuwDNwHSBkco7TmWou 0TAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FCrk2Ua1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 43-v6si11483079plb.511.2018.05.08.19.29.55; Tue, 08 May 2018 19:30:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FCrk2Ua1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933637AbeEIC3i (ORCPT + 99 others); Tue, 8 May 2018 22:29:38 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:41247 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932115AbeEIC3e (ORCPT ); Tue, 8 May 2018 22:29:34 -0400 Received: by mail-pf0-f194.google.com with SMTP id v63so24852076pfk.8; Tue, 08 May 2018 19:29:34 -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=gQqJfRb+BYJB9x/7qkeKR1CLKP7s2iq6mhx2Xa4oI3Q=; b=FCrk2Ua1S6lDHuE2erBqNgtqeevpTtfWVI7H3DcOjdRO7MPhV61zDiwFs8iERVOXG8 A6y3KEpfkwK/KGawe7itVbGZ0f/AaG6NkZRPoFc2q6o6aUHBfGryALA09MQ4LHWL/2ta BSV26fUWKkgPQDbSEht8LJ4P1O4gCjZ7MUhVEndk5Su5Wdo7EEd1WWlU9de7ms77Qi4S wxscqUN2puJeRvpbM1zUGMohYONhh+JFz3v/ub2F84uh7jhHellnmpXLQzI1xlE8ZO1+ ym5Qk/vdPH/u1nwPwmYTrdKaidSafemiI6rNTHMFN++qAAjBB6h8yiVjmNQyMRbBeQ9+ H18Q== 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=gQqJfRb+BYJB9x/7qkeKR1CLKP7s2iq6mhx2Xa4oI3Q=; b=BvpGpfdhHE5Gw3ZY8R1LOtUyMq/Qrk2y5ZI7r8+VGjrxzPPJ/8jti5Bf0H9rGsSFof MA70UqUDCAV8OGtDTXBpRq7dm/oZrBI3m0rpJdNRM3NQsppSPtso2d1IHo+5puSJ8ucI npr6cmetWDWadUFQGuuyfedQuHT9J5eiTr8fKgpBc8P+by6IT/qYvJz6ap+fkuI3OQFd iNDUUf18YFuXbq//MwWqb0tRgAyLv2NpVHsK2glLb/mN2uzmTgAkusp+0/oeCiknNRPy vSHyQB1tn/1cj+erA/rAZ2KhRsv0CKifP8GH3OpnjuRXpYzMITdfJzApSgSWEyPg0eX+ PP8g== X-Gm-Message-State: ALKqPwfA6yXhKhbwZwuHKhGF0G3oncxHL9xbqxgn9oFoQYGZjWify2lU OfK8reaAMrNozJA7y3QoFrI= X-Received: by 2002:a65:550d:: with SMTP id f13-v6mr3882517pgr.324.1525832973854; Tue, 08 May 2018 19:29:33 -0700 (PDT) Received: from ast-mbp ([2620:10d:c090:180::1:917f]) by smtp.gmail.com with ESMTPSA id m72sm32656365pfk.110.2018.05.08.19.29.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 May 2018 19:29:32 -0700 (PDT) Date: Tue, 8 May 2018 19:29:29 -0700 From: Alexei Starovoitov To: "Luis R. Rodriguez" Cc: Alexei Starovoitov , davem@davemloft.net, daniel@iogearbox.net, torvalds@linux-foundation.org, gregkh@linuxfoundation.org, luto@amacapital.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Juergen Gross , Eric Paris , Matthew Auld , Josh Triplett , "Kirill A. Shutemov" , Joonas Lahtinen , Chris Wilson , Stephen Smalley , "Eric W. Biederman" , Mimi Zohar , David Howells , Kees Cook , Andrew Morton , Dominik Brodowski , Hugh Dickins , Jann Horn , Jani Nikula , Rodrigo Vivi , David Airlie , "Rafael J. Wysocki" , Linux FS Devel , pjones@redhat.com, Michael Matz , mjg59@google.com, linux-security-module , linux-integrity@vger.kernel.org Subject: Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module Message-ID: <20180509022928.elyxj6mohm2jud56@ast-mbp> References: <20180503043604.1604587-1-ast@kernel.org> <20180503043604.1604587-3-ast@kernel.org> <20180507185124.GA18195@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180507185124.GA18195@wotan.suse.de> User-Agent: NeoMutt/20180223 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 07, 2018 at 06:51:24PM +0000, Luis R. Rodriguez wrote: > > Notice that _binary_net_bpfilter_bpfilter_umh_start - end > > is placed into .init.rodata section, so it's freed as soon as __init > > function of bpfilter.ko is finished. > > As part of __init the bpfilter.ko does first request/reply action > > via two unix pipe provided by fork_usermode_blob() helper to > > make sure that umh is healthy. If not it will kill it via pid. > > It does this very fast, right away. On a really slow system how are you sure > that this won't race and the execution of the check happens early on prior to > letting the actual setup trigger? After all, we're calling the userpsace > process in async mode. We could preempt it now. I don't see an issue. the kernel synchronously writes into a pipe. User space process reads. Exactly the same as coredump logic with pipes. > > +# a bit of elf magic to convert bpfilter_umh binary into a binary blob > > +# inside bpfilter_umh.o elf file referenced by > > +# _binary_net_bpfilter_bpfilter_umh_start symbol > > +# which bpfilter_kern.c passes further into umh blob loader at run-time > > +quiet_cmd_copy_umh = GEN $@ > > + cmd_copy_umh = echo ':' > $(obj)/.bpfilter_umh.o.cmd; \ > > + $(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT) \ > > + -B `$(OBJDUMP) -f $<|grep architecture|cut -d, -f1|cut -d' ' -f2` \ > > + --rename-section .data=.init.rodata $< $@ > > Cool, but so our expectation is that the compiler sets this symbol, how > are we sure it will always be set? Compiler doesn't set it. objcopy does. > > + > > + if (__bpfilter_process_sockopt(NULL, 0, 0, 0, 0) != 0) { > > See, here, what if the userspace process gets preemtped and we run this > check afterwards? Is that possible? User space is a normal task. It can sleep and can be single stepped with GDB.