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=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 5CB0DC4363A for ; Tue, 27 Oct 2020 19:11:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DB84B21556 for ; Tue, 27 Oct 2020 19:10:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TDpYEM9j" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1829426AbgJ0TJK (ORCPT ); Tue, 27 Oct 2020 15:09:10 -0400 Received: from mail-pj1-f68.google.com ([209.85.216.68]:51824 "EHLO mail-pj1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762525AbgJ0TJJ (ORCPT ); Tue, 27 Oct 2020 15:09:09 -0400 Received: by mail-pj1-f68.google.com with SMTP id a17so1276966pju.1; Tue, 27 Oct 2020 12:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vhFHGlRt/TibQfkAL2EZLq+3HRZ+VxPAD9HYXcgWC/k=; b=TDpYEM9j0VTG9y1sK6+P54LMevQ/wxvF5jiUXCKKLZ1FxRRYMYefcVyVQfAc+Om1PS ZEe1VRZkmhk0ir6O43G95oBAO2XD+Bq4fVBpHzkVRZw+UriLY30a/R4X0pDFtk1z5MUB yLaicL/Mrjl46F0+UFymiiwaSisHRYKw813Q0Kd47cc1WgZhvOJbmIZ6w6cxJxiecpuq hwk7hhJezQPq9VDBZdwaoEdHe5L3Ab5JZ4CMwJDp3CVt6wOQRLayWvn4DBgp1j2xyiIA Nfr8NKXzTh5ilnJ2tvCD46vw2NdTRtKMK/iutofss4RYEab+Vx7Vu0QT/YxkCzMOQAZw APGA== 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=vhFHGlRt/TibQfkAL2EZLq+3HRZ+VxPAD9HYXcgWC/k=; b=S50P8F9V+chxT2NTgSsOOjn0hbJKehYtwcu38QQlOTafvwPZoOGGRidaMudPB6O4cw qe9JVcYA7OJ0oOXyU7vlzOGgWDPCG5PDXzIzWD9wDmVl/v13f1nHl/CJthGJUrB7B949 CVFp00/xswSfWPB5lktOp3uvm/Mcus/YmdQ7uUDs15u8RyaGg8AlaKGrjgKkTgXCFj3f J3VmhTbE9l8cz3WLkoA/SupBAIewbZeco9P9M8AE7oe1Yv+bepDxdU4I4bqyaCRgzVac mw1Z6GdGYgdk2jwLXaLXayPrY1IBvecwwMjmWn4s+jYKTKaDwVx4OWCtppadRznKAw2E DGug== X-Gm-Message-State: AOAM531XDIOQlohjO+o5YT2qzSv1m+pf+bOLFEYYZDWaQFYXtsTBdbIO e/e8T2koRSw9Bj5PTOUM+WRgU/SfN4z47Pz4Wiw= X-Google-Smtp-Source: ABdhPJxT3MVZFdXRiktZytixxJYH/g52Rzd4ej1B/B/6AaacDeKHj7pSvVmudEo7lSKi4TSWV3mmIU7KhXAqNfkE9GM= X-Received: by 2002:a17:902:6803:b029:d2:42a6:312 with SMTP id h3-20020a1709026803b02900d242a60312mr3734880plk.24.1603825748736; Tue, 27 Oct 2020 12:09:08 -0700 (PDT) MIME-Version: 1.0 References: <9ede6ef35c847e58d61e476c6a39540520066613.1600951211.git.yifeifz2@illinois.edu> In-Reply-To: From: YiFei Zhu Date: Tue, 27 Oct 2020 14:08:56 -0500 Message-ID: Subject: Re: [PATCH v2 seccomp 1/6] seccomp: Move config option SECCOMP to arch/Kconfig To: Geert Uytterhoeven Cc: Linux Containers , YiFei Zhu , bpf , Linux Kernel Mailing List , Aleksa Sarai , Andrea Arcangeli , Andy Lutomirski , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jack Chen , Jann Horn , Josep Torrellas , Kees Cook , 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 Tue, Oct 27, 2020 at 4:52 AM Geert Uytterhoeven wrote: > Please tell me why SECCOMP is special, and deserves to default to be > enabled. Is it really that critical, given only 13.5 (half of sparc > ;-) out of 24 > architectures implement support for it? Good point. My thought process is that quite a few system software are reliant on seccomp for enforcing policies -- systemd, docker, and other sandboxing tools like browsers and firejail, so when I moved this to the non-perarch section, it at least has to be default for x86. Granted, I'm not super familiar with other architectures, so you are probably right that those that did not have it on by default should be kept off by default; many of them could be for embedded devices. What's the best way to do this? Set it as default N in Kconfig and add CONFIG_SECCOMP=y in each arch's defconfig? YiFei Zhu