Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp103949pxk; Thu, 24 Sep 2020 00:15:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzaOcXiv37Dve6H55Hz28Sl6vQDfe8RJ1gWcSk36aUpqwMO7zVN3DPJi57G+Z6zQ9kbYpG/ X-Received: by 2002:a17:906:f0cb:: with SMTP id dk11mr3349442ejb.457.1600931715695; Thu, 24 Sep 2020 00:15:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600931715; cv=none; d=google.com; s=arc-20160816; b=usTWVyWxKqamSQJndFgtRDLCFOw1q3bAqVyxKjpak3e/fqKQn17JMjYqt9WNwk7PPn NXmx1G3w1xxx8nVOAbYpFr7Llc0UobIHjg/Cj5Sc2o6z9Tvl6X/k83MZmzqDrrA+I1YD QXLCaUZwQxNd9ZldLoB8metAM2vvxmq+xfIKmOn2SRD6Pxh3bNa3EHZMWkVN1Jv8c+7Z XRbYiRFxaF+dEY8wPhkd1cTJPxGqq8urcd3Hez8tbRbJ65XM298vKc08mm/+QzR+6APk mKXuQVAjy6jHM8CzVENNWW/Bs90A8+b/lyZoLbxPlHiwQfus8a06HBmdj5xBE4etfGs9 EkAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=JPyfajfaHq+r5oQ4+KHWAZ8VwhlnanG+Cg9XmXwcpuM=; b=r90ydrn7fMLUw7cbbtZVXOvkVUi6WlStugQS0gQtMd/OBkD6yzfS8vrJlwXCuvNGFI bTaMTjRhymaLlID5YLLleNQfcFF900MOjuTe6DKgF7QhVSCMdArNNhuad/PZdJOq8IBX rISkx6YDS8KTnx+cWh+hEC1MWcJ3t5tfqHwgDIYEffLc+U8Uhd3nV5n+oMnwVq+r8Pvg zB8hyuNNOTYa2SLL1vJpksdnXkVJW3NiqQdK0U7rSvY2z+E6wOZZ/qGt0fublNH1+w9y klxTd+GwZv/EALp45kGoBWYW/xGVOvYCReNpTlF0AGeGGXJ1O5bLzW5ltrviV063+Ry4 EQgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=U7RM1C8n; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dr18si1210178ejc.702.2020.09.24.00.14.36; Thu, 24 Sep 2020 00:15:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=U7RM1C8n; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727217AbgIXHMX (ORCPT + 99 others); Thu, 24 Sep 2020 03:12:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727092AbgIXHMV (ORCPT ); Thu, 24 Sep 2020 03:12:21 -0400 Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A151FC0613CE for ; Thu, 24 Sep 2020 00:12:21 -0700 (PDT) Received: by mail-pf1-x441.google.com with SMTP id f18so1317908pfa.10 for ; Thu, 24 Sep 2020 00:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JPyfajfaHq+r5oQ4+KHWAZ8VwhlnanG+Cg9XmXwcpuM=; b=U7RM1C8nWHiMvrUrOKOxP2OLNnkhNzx+5Xb+ZMQxUQlQ/k1EejiqZf9v+kTIPp+x+y CfUd2Msra+Iq6+48aOR+1uozXy3KUCJ65MrxIuN9LacgwDvrl040rvwOdje3uhosgFR8 PHfcR07iK0OejM+M/srngdXt8hwsnJWfraF04= 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; bh=JPyfajfaHq+r5oQ4+KHWAZ8VwhlnanG+Cg9XmXwcpuM=; b=npn05f97XzNIhdeKYuXQep3QvWWpabwDp86idvcLLWo9X/ImLhAMiqbmFTnTslvEc+ sQz4IpG1Vx2OrIT7Sx2IDThoXQXo9Wpg5dyMG1K/yAhShYH8ntRmk52x9yc2+3ZNINmj bqbnHgpSMpOMoXBmk1QseLlPbJOM/5yet4qaTZycHiR+v+djCqE6Eyu3YXBONikp3T9o b7B5KpsQwn+tJRfq7KR0iskLm0unyWZe1yeRLmuFOuzvFklY6xQx32RMRlqtv+0NMk5+ ldpcEZf3a/9l25oMvKlPIZZL15Kn2jlNGBBULbqrl8QYvIlt9yULCFHwPjCwSBFTcOdD smIQ== X-Gm-Message-State: AOAM533f7ysgW6dehO7eCRATGw4eKp3+DcZurO3zbInKpqbOlFAtC2o/ hJDo/qDQM/i6K7wl76eKW70nKg== X-Received: by 2002:a63:c20b:: with SMTP id b11mr2902014pgd.421.1600931541212; Thu, 24 Sep 2020 00:12:21 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id n9sm1783640pgi.2.2020.09.24.00.12.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2020 00:12:20 -0700 (PDT) Date: Thu, 24 Sep 2020 00:12:19 -0700 From: Kees Cook To: Jann Horn Cc: YiFei Zhu , Christian Brauner , Tycho Andersen , Andy Lutomirski , Will Drewry , Andrea Arcangeli , Giuseppe Scrivano , Tobin Feldman-Fitzthum , Dimitrios Skarlatos , Valentin Rothberg , Hubertus Franke , Jack Chen , Josep Torrellas , Tianyin Xu , bpf , Linux Containers , Linux API , kernel list Subject: Re: [PATCH 2/6] x86: Enable seccomp architecture tracking Message-ID: <202009240011.A56710DC@keescook> References: <20200923232923.3142503-1-keescook@chromium.org> <20200923232923.3142503-3-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 24, 2020 at 02:45:45AM +0200, Jann Horn wrote: > On Thu, Sep 24, 2020 at 1:29 AM Kees Cook wrote: > > Provide seccomp internals with the details to calculate which syscall > > table the running kernel is expecting to deal with. This allows for > > efficient architecture pinning and paves the way for constant-action > > bitmaps. > [...] > > diff --git a/arch/x86/include/asm/seccomp.h b/arch/x86/include/asm/seccomp.h > [...] > > +#ifdef CONFIG_X86_64 > [...] > > +#else /* !CONFIG_X86_64 */ > > +# define SECCOMP_ARCH AUDIT_ARCH_I386 > > +#endif > > If we are on a 32-bit kernel, performing architecture number checks in > the kernel is completely pointless, because we know that there is only > a single architecture identifier under which syscalls can happen. > > While this patch is useful for enabling the bitmap logic in the > following patches, I think it adds unnecessary overhead in the context > of the previous patch. That's what the RFC was trying to do (avoid the logic if there is only a single arch known to the kernel). I will rework this a bit harder. :) -- Kees Cook