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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no 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 78FE4C4346E for ; Fri, 25 Sep 2020 00:16:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3002723977 for ; Fri, 25 Sep 2020 00:16:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="F0LNJat7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726756AbgIYAQT (ORCPT ); Thu, 24 Sep 2020 20:16:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726676AbgIYAQT (ORCPT ); Thu, 24 Sep 2020 20:16:19 -0400 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9973EC0613D3 for ; Thu, 24 Sep 2020 17:16:18 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id j2so685199eds.9 for ; Thu, 24 Sep 2020 17:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7xIf+Wd02QlRb8dihS/DiLbBEmJ1zW6xAEVbZ5dS26E=; b=F0LNJat78CdDpEaqZQuJ1tqYitJYzbyqPAVCgU18z7GFkfA1gi8abPuI4hVEqqNjrO 7qCIQUkxAI8zgQLp6PDo1dx9GDy0tpvikrn94cKA25Mw9Wd+CoYHKC1yZ9q7T16cQQTP H/U9JPG7AON51/TYdL6xeqM6iEgi+a5lpR/BMpU/gSs626kra6z2IKHMZURbKhbDWw58 6hjmQKMFCy0B2LOAm2Bil0vYBlPkNu7nqxMWYn/VdN+36tDP8DNnEU9pi+Ogx8r10v1s Lg4LyJNKT6TRNahT1JulTgdRE1uBn1YZNSvD0yr2jskQl+ue+H+AxIuqrs1ABIGv450a 0QMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7xIf+Wd02QlRb8dihS/DiLbBEmJ1zW6xAEVbZ5dS26E=; b=lfwfYdSJ8LkVixFy95sIsSePVahSLwj5DkT7qts85kJ97VwdyvUZFDOJn2j0IidQ04 IVMH8LRM39wUULnRaxjlv1Gigk6Y1gzc0Ac787RaiqDKIU+YL6Uj0riYqid+HNXTJDvw prd9iwf9/2UDBr7PggUBrTs+r3/OiXeD5dayZMohIENgu7FTk0tb/pdhglEbigg8FmeW mB1UeNA9AAM3zdyvbK2WzsYkct9s2PdMIGDKfSbYI+Jw0p3VbmOxp0WSwjl6NOF9aNft OqwzACCudM+s4TQxzbHyGy8nUJ1Ynj28oPU+EtFLAe0RZri35bjM8BpfyvinHAjJB4Ep gcow== X-Gm-Message-State: AOAM533wFHhk8OFLyg9gl5BDtrYYZYBYb6XrF3h90buY7hp0PvgjLs2D sjEj9hxGmou1Kr2GafVHH70eeu0R8LtsRGdpqUFiuA== X-Google-Smtp-Source: ABdhPJxKKrQDdHZi95Ynf871qKWysLRg5gjvkYXRdU159HiWVv61BCzjOFRKE4h3CAptn9KbJU134l/l0xSFubL6Qkw= X-Received: by 2002:a05:6402:176c:: with SMTP id da12mr1354480edb.386.1600992977013; Thu, 24 Sep 2020 17:16:17 -0700 (PDT) MIME-Version: 1.0 References: <202009241658.A062D6AE@keescook> In-Reply-To: <202009241658.A062D6AE@keescook> From: Jann Horn Date: Fri, 25 Sep 2020 02:15:50 +0200 Message-ID: Subject: Re: [PATCH v2 seccomp 2/6] asm/syscall.h: Add syscall_arches[] array To: Kees Cook Cc: YiFei Zhu , YiFei Zhu , Linux Containers , bpf , kernel list , Aleksa Sarai , Andrea Arcangeli , Andy Lutomirski , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jack Chen , Josep Torrellas , Tianyin Xu , Tobin Feldman-Fitzthum , Tycho Andersen , Valentin Rothberg , Will Drewry Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 25, 2020 at 2:01 AM Kees Cook wrote: > 2) seccomp needs to handle "multiplexed" tables like x86_x32 (distros > haven't removed CONFIG_X86_X32 widely yet, so it is a reality that > it must be dealt with), which means seccomp's idea of the arch > "number" can't be the same as the AUDIT_ARCH. Sure, distros ship it; but basically nobody uses it, it doesn't have to be fast. As long as we don't *break* it, everything's fine. And if we ignore the existence of X32 in the fastpath, that'll just mean that syscalls with the X32 marker bit always hit the seccomp slowpath (because it'll look like the syscall number is out-of-bounds ) - no problem.