From: Andi Kleen <ak@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Dan Williams <dan.j.williams@intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v1] driver: base: Add driver filter support
Date: Wed, 4 Aug 2021 12:50:24 -0700 [thread overview]
Message-ID: <f2b1d564-8174-f8e9-9fee-12e938c6d846@linux.intel.com> (raw)
In-Reply-To: <YQrqhYEL64CSLRTy@kroah.com>
> So you are trying to work around the "problem" that distro kernels
> provides drivers for everything by adding additional kernel complexity?
>
> What prevents you from using a sane, stripped down, kernel image for
> these vms which would keep things sane and simpler and easier to audit
> and most importantly, prove, that the image is not doing something you
> don't expect it to do?
>
> Why not just make distros that want to support this type of platform,
> also provide these tiny kernel images? Why are you pushing this work on
> the kernel community instead?
Greg, I'm surprised by your comment. Traditionally we've been tried to
support all platforms in unified binary kernels and gone to considerable
complications to do so. That has been standard Linux practice for at
least the 90ies. In some cases we went to considerable pain to support
that, for example for the 5 level page tables or for paravirt ops.
Imagine there were 10 new features or platforms and they would all ask
distributions to produce custom kernels for them, they would need to
maintain 10 different kernel packages forever for all these different
cases. It's totally reasonable that they don't want to do that.
Also even if they were willing to do custom configs it's not clear how
this could be maintained and distributed. We would either have a
standard TDX config and get everyone to agree on it (very difficult). Or
some enforcement mechanism at the Kconfig level that forces most drivers
to be disabled when TDX is on, which would be also a considerable new
mechanism and complication. In addition there are drivers which are not
covered by Kconfig today (like quite a few of the basic platform
drivers), but which we still want to filter. So to implement a full
build time mechanism would likely need more changes than this relatively
straight forward run time mechanism based on the driver model.
And of course there other use cases for a run time filter mechanism. For
example let's say you want filtering for Thunderbolt security. In this
case it has to be done at runtime because it's not practical to have a
kernel that is only built for Thunderbolt drivers, but doesn't support
anything else that is on the SOC. The only sane way to handle such a
case is to make a runtime distinction.
> And what's wrong with the current method of removing drivers from
> devices that you do not want them to be bound to? We offer that support
> for all busses now that want to do it, what driver types are you needing
> to "control" here that does not take advantage of the existing
> infrastructure that we currently have for this type of thing?
I'm not sure what mechanism you're referring to here, but in general
don't want the drivers to initialize at all because they might get
exploited in any code that they execute.The intention is to disable all
drivers except for a small allow list, because it's not practical to
harden all 25M lines of Linux code.
-Andi
next prev parent reply other threads:[~2021-08-04 19:50 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-04 17:43 [PATCH v1] driver: base: Add driver filter support Kuppuswamy Sathyanarayanan
2021-08-04 18:08 ` Matthew Wilcox
2021-08-04 18:29 ` Kuppuswamy, Sathyanarayanan
2021-08-04 18:33 ` Matthew Wilcox
2021-08-04 19:27 ` Andi Kleen
2021-08-04 18:45 ` Dan Williams
2021-08-04 19:29 ` Greg Kroah-Hartman
2021-08-04 19:50 ` Andi Kleen [this message]
2021-08-04 20:09 ` Kuppuswamy, Sathyanarayanan
2021-08-05 7:50 ` Greg Kroah-Hartman
2021-08-05 7:49 ` Greg Kroah-Hartman
2021-08-05 7:55 ` Greg Kroah-Hartman
2021-08-05 7:58 ` Greg Kroah-Hartman
2021-08-05 13:52 ` Andi Kleen
2021-08-05 17:51 ` Greg Kroah-Hartman
2021-08-05 17:58 ` Andi Kleen
2021-08-05 18:09 ` Greg Kroah-Hartman
2021-08-05 18:44 ` Andi Kleen
2021-08-05 19:01 ` Dan Williams
2021-08-05 19:08 ` Kuppuswamy, Sathyanarayanan
2021-08-05 19:28 ` Greg Kroah-Hartman
2021-08-05 21:10 ` Andi Kleen
2021-08-06 1:00 ` Dan Williams
2021-08-06 5:17 ` Greg Kroah-Hartman
2021-08-06 14:36 ` Dan Williams
2021-08-06 5:07 ` Greg Kroah-Hartman
2021-08-05 18:53 ` Kuppuswamy, Sathyanarayanan
2021-08-05 19:12 ` Greg Kroah-Hartman
2021-08-05 19:18 ` Dan Williams
2021-08-05 19:28 ` Greg Kroah-Hartman
2021-08-05 19:52 ` Dan Williams
2021-08-06 11:15 ` Jonathan Cameron
2021-08-05 16:37 ` Dan Williams
2021-08-05 17:25 ` Kuppuswamy, Sathyanarayanan
2021-08-05 17:48 ` Greg Kroah-Hartman
2021-08-05 17:52 ` Andi Kleen
2021-08-05 18:11 ` Greg Kroah-Hartman
2021-08-05 17:49 ` Greg Kroah-Hartman
2021-08-04 20:11 ` Dan Williams
2021-08-04 20:29 ` Kuppuswamy, Sathyanarayanan
2021-08-04 21:07 ` Matthew Wilcox
2021-08-04 21:28 ` Dan Williams
2021-08-05 4:45 ` Andi Kleen
2021-08-05 7:59 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2b1d564-8174-f8e9-9fee-12e938c6d846@linux.intel.com \
--to=ak@linux.intel.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=knsathya@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.