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 93C3EC4346E for ; Fri, 25 Sep 2020 00:16:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 477E823977 for ; Fri, 25 Sep 2020 00:16:31 +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 S1726703AbgIYAQT (ORCPT ); Thu, 24 Sep 2020 20:16:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726448AbgIYAQS (ORCPT ); Thu, 24 Sep 2020 20:16:18 -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 94DADC0613CE for ; Thu, 24 Sep 2020 17:16:18 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id e22so700611edq.6 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=ehBYc4Wvh1taIbj/A2H4FFh7GM1snHC6b+NS3TX5MzWHZIDqCunWodZOPZQ0McuJhG duUfDr1NU8D93kTF+mERqd6LCj9iN0KqtlH+3EF12bSZMk3Z2kiMbwx1LTTPEqjkyh/M 7JAqZW2EU3QkyPDaOWC3bwJkLdtmlGGGOufrpDKnRNX8Xpq9WNaiSVVzWZmt102QFw/b +JrtSuqA8vFNdOTTiPXDUsX/C4fOSW/1tlujIeUq5kRGbhIEpaiG7WVXZ35YViFxYGWH tey8TLAUa/gOI1rb0hKrVFv+mkClYtAS76P7Q0j2TisA71HH/U3Uh/uuVfHdf5fwr+PK u4Lg== X-Gm-Message-State: AOAM531MD2XpizJFA02VTaje9O9QLfNZ21EBvlTqJGs2oA1LItU70198 Ps1BgzJV/J+lc/4Aw2V+4tUDw+MAujVwEBjRt2idcA== 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: bpf@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.