[PATCH v3] Documentation: Document the Linux Kernel CVE process

[Greg Kroah-Hartman]

The Linux kernel project now has the ability to assign CVEs to fixed
issues, so document the process and how individual developers can get a
CVE if one is not automatically assigned for their fixes.

Reviewed-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Lee Jones 
---
v3: fix up wording in security-bugs.rst based on the changes to the cve
assignment process from v1, thanks to a private reviewer for
pointing that out.
v2: Grammer fixes based on review from Randy
Updated paragraph about how CVE identifiers will be assigned
(automatically when added to stable trees, or ask us for one
directly before that happens if so desired)

 Documentation/process/cve.rst   | 120 
 Documentation/process/index.rst |   1 +
 Documentation/process/security-bugs.rst |   5 +-
 3 files changed, 123 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/process/cve.rst

diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
new file mode 100644
index ..6465e6a79c18
--- /dev/null
+++ b/Documentation/process/cve.rst
@@ -0,0 +1,120 @@
+CVEs
+
+
+Common Vulnerabilities and Exposure (CVE®) numbers were developed as an
+unambiguous way to identify, define, and catalog publicly disclosed
+security vulnerabilities.  Over time, their usefulness has declined with
+regards to the kernel project, and CVE numbers were very often assigned
+in inappropriate ways and for inappropriate reasons.  Because of this,
+the kernel development community has tended to avoid them.  However, the
+combination of continuing pressure to assign CVEs and other forms of
+security identifiers, and ongoing abuses by community members outside of
+the kernel community has made it clear that the kernel community should
+have control over those assignments.
+
+The Linux kernel developer team does have the ability to assign CVEs for
+potential Linux kernel security issues.  This assignment is independent
+of the :doc:`normal Linux kernel security bug reporting
+process<../process/security_bugs>`.
+
+A list of all assigned CVEs for the Linux kernel can be found in the
+archives of the linux-cve mailing list, as seen on
+https://lore.kernel.org/linux-cve-announce/.  To get notice of the
+assigned CVEs, please subscribe to that mailing list.
+
+Process
+---
+
+As part of the normal stable release process, kernel changes that are
+potentially security issues are identified by the developers responsible
+for CVE number assignments and have CVE numbers automatically assigned
+to them.  These assignments are published on the linux-cve-announce
+mailing list as announcements on a frequent basis.
+
+Note, due to the layer at which the Linux kernel is in a system, almost
+any bug might be exploitable to compromise the security of the kernel,
+but the possibility of exploitation is often not evident when the bug is
+fixed.  Because of this, the CVE assignment team is overly cautious and
+assign CVE numbers to any bugfix that they identify.  This
+explains the seemingly large number of CVEs that are issued by the Linux
+kernel team.
+
+If the CVE assignment team misses a specific fix that any user feels
+should have a CVE assigned to it, please email them at 
+and the team there will work with you on it.  Note that no potential
+security issues should be sent to this alias, it is ONLY for assignment
+of CVEs for fixes that are already in released kernel trees.  If you
+feel you have found an unfixed security issue, please follow the
+:doc:`normal Linux kernel security bug reporting
+process<../process/security_bugs>`.
+
+No CVEs will be automatically assigned for unfixed security issues in
+the Linux kernel; assignment will only automatically happen after a fix
+is available and applied to a stable kernel tree, and it will be tracked
+that way by the git commit id of the original fix.  If anyone wishes to
+have a CVE assigned before an issue is resolved with a commit, please
+contact the kernel CVE assignment team at  to get an
+identifier assigned from their batch of reserved identifiers.
+
+No CVEs will be assigned for any issue found in a version of the kernel
+that is not currently being actively supported by the Stable/LTS kernel
+team.  A list of the currently supported kernel branches can be found at
+https://kernel.org/category/releases.html
+
+Disputes of assigned CVEs
+-
+
+The authority to dispute or modify an assigned CVE for a specific kernel
+change lies solely with the maintainers of the relevant subsystem
+affected.  This principle ensures a high degree of accuracy and
+accountability in vulnerability reporting.  Only those individuals with
+deep expertise and intimate knowledge of the subsystem can effectively
+assess the validity and scope of a reported vulnerability and determine
+its appropriate CVE designation.  Any attempt to modify or dispute a CVE
+outside of this designated author

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Lukas Bulwahn]

On Wed, Feb 14, 2024 at 9:01 AM Greg Kroah-Hartman
 wrote:
>
> The Linux kernel project now has the ability to assign CVEs to fixed
> issues, so document the process and how individual developers can get a
> CVE if one is not automatically assigned for their fixes.
>
> Reviewed-by: Kees Cook 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Sasha Levin 
> Signed-off-by: Lee Jones 
> ---
> v3: fix up wording in security-bugs.rst based on the changes to the cve
> assignment process from v1, thanks to a private reviewer for
> pointing that out.
> v2: Grammer fixes based on review from Randy
> Updated paragraph about how CVE identifiers will be assigned
> (automatically when added to stable trees, or ask us for one
> directly before that happens if so desired)
>

Hi Greg, Sasha, Lee,

Generally, I think this is a great step forward on the whole "security
vulnerability mess" and this will certainly help me and others in the
embedded space to argue to update to recent stable kernel versions.
This can then finally put the practice of shipping multiple-year-old
kernel versions to an end. Often this was just done with the argument
that there is not a recent CVE and fix assigned to some recent stable
kernel version---and integrators think updates to recent kernel stable
versions are not needed and not recommended.

I am looking forward to seeing what and how many stable commits are
going to get CVEs assigned. If Greg's policy from the Kernel Recipes
2019 presentation comes into play, every git kernel hash (GKH)---at
least in the stable tree---could get a CVE identifier (just to be on
the safe side). But I assume you are going to use some expert
knowledge, heuristics or some machine-learning AI to make some commits
in the stable tree carrying a CVE identifier and some others not.

Reviewed-by: Lukas Bulwahn 

Below, there is just some nitpicking on some wording:

>  Documentation/process/cve.rst   | 120 
>  Documentation/process/index.rst |   1 +
>  Documentation/process/security-bugs.rst |   5 +-
>  3 files changed, 123 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/process/cve.rst
>
> diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
> new file mode 100644
> index ..6465e6a79c18
> --- /dev/null
> +++ b/Documentation/process/cve.rst
> @@ -0,0 +1,120 @@
> +CVEs
> +
> +
> +Common Vulnerabilities and Exposure (CVE®) numbers were developed as an
> +unambiguous way to identify, define, and catalog publicly disclosed
> +security vulnerabilities.  Over time, their usefulness has declined with
> +regards to the kernel project, and CVE numbers were very often assigned
> +in inappropriate ways and for inappropriate reasons.  Because of this,
> +the kernel development community has tended to avoid them.  However, the
> +combination of continuing pressure to assign CVEs and other forms of
> +security identifiers, and ongoing abuses by community members outside of
> +the kernel community has made it clear that the kernel community should
> +have control over those assignments.
> +

Though, I get what is meant with "the community members outside of the
kernel community", it still feels strange when reading.

Here are some alternatives I could come up with:

"reporters outside the kernel community"
"reporters beyond the actively contributing/engaged kernel community members"
"individuals not engaged with the kernel community"

> +The Linux kernel developer team does have the ability to assign CVEs for
> +potential Linux kernel security issues.  This assignment is independent
> +of the :doc:`normal Linux kernel security bug reporting
> +process<../process/security_bugs>`.
> +
> +A list of all assigned CVEs for the Linux kernel can be found in the
> +archives of the linux-cve mailing list, as seen on
> +https://lore.kernel.org/linux-cve-announce/.  To get notice of the
> +assigned CVEs, please subscribe to that mailing list.
> +
> +Process
> +---
> +
> +As part of the normal stable release process, kernel changes that are
> +potentially security issues are identified by the developers responsible
> +for CVE number assignments and have CVE numbers automatically assigned
> +to them.  These assignments are published on the linux-cve-announce
> +mailing list as announcements on a frequent basis.
> +
> +Note, due to the layer at which the Linux kernel is in a system, almost
> +any bug might be exploitable to compromise the security of the kernel,

Just a nit: but I would say: a kernel bug is compromising the
"security of the system"; the kernel bug just happens to allow anyone
to run any code on their hardware... in some systems that is a
security issue, but in my previous MSDOS system that was the default
behaviour ;)

> +but the possibility of exploitation is often not evident when the bug is
> +fixed.  Because of this, the CVE assignment team is overly cautious and
> +assign CVE numbers to any bugfix that th

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Vegard Nossum]

On 14/02/2024 09:00, Greg Kroah-Hartman wrote:

diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
new file mode 100644
index ..6465e6a79c18
--- /dev/null
+++ b/Documentation/process/cve.rst
@@ -0,0 +1,120 @@
+CVEs
+


Document titles should have  above them as well, and then you would
need to shift all the other headings in this document (i.e. all the ---
should become ===).

Info here: 
https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation



+The Linux kernel developer team does have the ability to assign CVEs for
+potential Linux kernel security issues.  This assignment is independent
+of the :doc:`normal Linux kernel security bug reporting
+process<../process/security_bugs>`.


These documents are both under process/ so it should be enough to say:

:doc:`[...] `

In fact, when building the docs with your patch applied, I see:

Documentation/process/cve.rst:15: WARNING: unknown document: 
../process/security_bugs
Documentation/process/cve.rst:42: WARNING: unknown document: 
../process/security_bugs


Note the hyphen vs. underscore (it should have a hyphen like my line above).


+Process
+---
+
+As part of the normal stable release process, kernel changes that are
+potentially security issues are identified by the developers responsible
+for CVE number assignments and have CVE numbers automatically assigned
+to them.  These assignments are published on the linux-cve-announce
+mailing list as announcements on a frequent basis.
+
+Note, due to the layer at which the Linux kernel is in a system, almost
+any bug might be exploitable to compromise the security of the kernel,
+but the possibility of exploitation is often not evident when the bug is
+fixed.  Because of this, the CVE assignment team is overly cautious and


What is the composition of the CVE assignment team, or is that secret?
Should this be a MAINTAINERS entry? (s...@k.org is one.)


+If the CVE assignment team misses a specific fix that any user feels
+should have a CVE assigned to it, please email them at 
+and the team there will work with you on it.  Note that no potential
+security issues should be sent to this alias, it is ONLY for assignment
+of CVEs for fixes that are already in released kernel trees.  If you
+feel you have found an unfixed security issue, please follow the
+:doc:`normal Linux kernel security bug reporting
+process<../process/security_bugs>`.


Same


+Disputes of assigned CVEs
+-
+
+The authority to dispute or modify an assigned CVE for a specific kernel
+change lies solely with the maintainers of the relevant subsystem
+affected.  This principle ensures a high degree of accuracy and
+accountability in vulnerability reporting.  Only those individuals with
+deep expertise and intimate knowledge of the subsystem can effectively
+assess the validity and scope of a reported vulnerability and determine
+its appropriate CVE designation.  Any attempt to modify or dispute a CVE
+outside of this designated authority could lead to confusion, inaccurate
+reporting, and ultimately, compromised systems.


Just to clarify, I think "dispute" here is used in the
Mitre/CVE-technical meaning of the word, correct? I assume people will
still have the right to say "hey, this doesn't look like a real issue
[because of X/Y/Z]" on a mailing list.


--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -99,9 +99,8 @@ CVE assignment
  The security team does not assign CVEs, nor do we require them for
  reports or fixes, as this can needlessly complicate the process and may
  delay the bug handling.  If a reporter wishes to have a CVE identifier
-assigned, they should find one by themselves, for example by contacting
-MITRE directly.  However under no circumstances will a patch inclusion
-be delayed to wait for a CVE identifier to arrive.
+assigned for a confirmed issue, they can contact the :doc:`kernel CVE
+assignment team<../process/cve>` to obtain one.


Same here, this could be just .


Vegard

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Krzysztof Kozlowski]

On 14/02/2024 09:00, Greg Kroah-Hartman wrote:
> The Linux kernel project now has the ability to assign CVEs to fixed
> issues, so document the process and how individual developers can get a
> CVE if one is not automatically assigned for their fixes.
> 
> Reviewed-by: Kees Cook 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Sasha Levin 
> Signed-off-by: Lee Jones 
> ---
> v3: fix up wording in security-bugs.rst based on the changes to the cve
> assignment process from v1, thanks to a private reviewer for
> pointing that out.
> v2: Grammer fixes based on review from Randy
> Updated paragraph about how CVE identifiers will be assigned
> (automatically when added to stable trees, or ask us for one
> directly before that happens if so desired)
> 
>  Documentation/process/cve.rst   | 120 
>  Documentation/process/index.rst |   1 +
>  Documentation/process/security-bugs.rst |   5 +-

Great direction! Finally all these bugs we are fixing every release
(thus in stable trees) will get proper attention via assigned CVEs.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Konstantin Ryabitsev]

On Wed, Feb 14, 2024 at 09:00:30AM +0100, Greg Kroah-Hartman wrote:
> +A list of all assigned CVEs for the Linux kernel can be found in the
> +archives of the linux-cve mailing list, as seen on
> +https://lore.kernel.org/linux-cve-announce/.  To get notice of the
> +assigned CVEs, please subscribe to that mailing list.

Since the archives page doesn't carry any instructions on how to subscribe,
I think you should link to https://subspace.kernel.org/subscribing.html here,
e.g.:

... please `subscribe `_ to that
mailing list.

> +No CVEs will be assigned for any issue found in a version of the kernel
> +that is not currently being actively supported by the Stable/LTS kernel
> +team.  A list of the currently supported kernel branches can be found at
> +https://kernel.org/category/releases.html

Can just be https://kernel.org/releases.html

Reviewed-by: Konstantin Ryabitsev 

-K

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Jiri Kosina]

On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:

> +No CVEs will be automatically assigned for unfixed security issues in
> +the Linux kernel; assignment will only automatically happen after a fix
> +is available and applied to a stable kernel tree, and it will be tracked
> +that way by the git commit id of the original fix. 

I think this needs way more clarification .. how exactly is this going to 
work?

Do I read this correctly that *everything* that lands in -stable will 
automatically get CVE assigned? If so, that's just plain crazy. Just took 
a random peek on the topmost -stable changelog ...

ASoC: codecs: wsa883x: fix PA volume control
ASoC: codecs: lpass-wsa-macro: fix compander volume hack
ASoC: codecs: wcd938x: fix headphones volume controls
ASoC: qcom: sc8280xp: limit speaker volumes
drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'

Only the last one can *potentially* be considered a CVE candidate, but 
someone would actually have to take a *deep* look. Most likely it'll be a 
functional issue, but not a security issue by any measures.

So I hope it's not the case, and someone will actually be doing some 
triage. If that's the case -- is this process described anywhere?

Also, how are the CVSS-like scores going to be assigned? There are no 
details whatsoever about that in the document.

In any case, by making this change we are going to make security theathre 
industry super-happy (they will have a lot of expensive nothing going on), 
and all the distros not basing on -stable very unhappy (we're already 
drowning because everybody and his grandma wants to become famous by 
publishing a CVE for something completely irrelevant). If this is the 
intention, it should be spelled out loud and clear.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Mark Brown]

On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:

> > +No CVEs will be automatically assigned for unfixed security issues in
> > +the Linux kernel; assignment will only automatically happen after a fix
> > +is available and applied to a stable kernel tree, and it will be tracked
> > +that way by the git commit id of the original fix. 

> I think this needs way more clarification .. how exactly is this going to 
> work?

> Do I read this correctly that *everything* that lands in -stable will 
> automatically get CVE assigned? If so, that's just plain crazy. Just took 
> a random peek on the topmost -stable changelog ...

>   ASoC: codecs: wsa883x: fix PA volume control
>   ASoC: codecs: lpass-wsa-macro: fix compander volume hack
>   ASoC: codecs: wcd938x: fix headphones volume controls
>   ASoC: qcom: sc8280xp: limit speaker volumes
>   drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'

> Only the last one can *potentially* be considered a CVE candidate, but 
> someone would actually have to take a *deep* look. Most likely it'll be a 
> functional issue, but not a security issue by any measures.

Not addressing your point in general but the speaker volume limiting is
security relevant, that change prevents physical damage to the system.
There's an argument for many headphone volume related fixes too since
excessively large volumes can cause substantial distress and potential
injury to users (I can't remember if that fix would be relevant to that
issue).


signature.asc
Description: PGP signature

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Greg Kroah-Hartman]

On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:
> 
> > +No CVEs will be automatically assigned for unfixed security issues in
> > +the Linux kernel; assignment will only automatically happen after a fix
> > +is available and applied to a stable kernel tree, and it will be tracked
> > +that way by the git commit id of the original fix. 
> 
> I think this needs way more clarification .. how exactly is this going to 
> work?
> 
> Do I read this correctly that *everything* that lands in -stable will 
> automatically get CVE assigned? If so, that's just plain crazy. Just took 
> a random peek on the topmost -stable changelog ...
> 
>   ASoC: codecs: wsa883x: fix PA volume control
>   ASoC: codecs: lpass-wsa-macro: fix compander volume hack
>   ASoC: codecs: wcd938x: fix headphones volume controls
>   ASoC: qcom: sc8280xp: limit speaker volumes
>   drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'
> 
> Only the last one can *potentially* be considered a CVE candidate, but 
> someone would actually have to take a *deep* look. Most likely it'll be a 
> functional issue, but not a security issue by any measures.
> 
> So I hope it's not the case, and someone will actually be doing some 
> triage. If that's the case -- is this process described anywhere?

It's described as "we know it when we see it" :)

Seriously, this is something that Sasha has already been doing
successfully for 3+ years now with the GSD project, so look at the
commits that have been assigned there for an example of what will be
picked.  Also we will probably go back in time for a few years and use
that data to populate the CVE database for older releases as long as
they are still in currently supported releases as this is something that
the CVE group has asked us to do already.

As for your list above, I doubt any of those would be a CVE, give us
some credit here.  Let's see how it goes and if people complain we are
picking things that we shouldn't be picking, OR if we aren't picking
enough, they will then be asked to join the team doing the work :)

The people that make up the current team, Lee, Sasha, and I, have a LONG
history of fixing and triaging and managing security bugs for the
kernel, in the community and in corporate environments.  We know how to
do this as we have been doing it for decades already.  If you or anyone
else wishes to help us out with this classification, we can gladly use
the help.

> Also, how are the CVSS-like scores going to be assigned? There are no 
> details whatsoever about that in the document.

We will not be doing any CVSS scoring as that is outside the scope of a
CVE entry and not required at all, and the CVE board agrees with this
decision.  As you well know, doing something like this for the kernel
where we have no idea what your use case is, is almost impossible on the
best days.

There are external groups that suck in the CVE entries and attempt to
assign CVSS-like scores to issues.  It will be "interesting" to see how
they classify things, but if the history of how well they have done this
in the past is any indication, their tools need a lot of work and
hopefully people stop relying on them and do the evaluation of their own
use cases instead.

> In any case, by making this change we are going to make security theathre 
> industry super-happy (they will have a lot of expensive nothing going on), 
> and all the distros not basing on -stable very unhappy (we're already 
> drowning because everybody and his grandma wants to become famous by 
> publishing a CVE for something completely irrelevant). If this is the 
> intention, it should be spelled out loud and clear.

As we are not allowed to credit anyone in the publication of a CVE, I
doubt the "I want a CVE!" group will get any louder than they currently
are.  And if it generates these people to actually submit bug fixes with
their reports, all the better for us!

I can't speak to the "security theatre industry" but right now, we have
a real problem of external groups assigning random CVEs to the kernel
with absolutely no input from us and no accountability, which is causing
a lot of us real problems.  This will take away the ability for those
groups to continue to abuse our project just because of their broken
engineering rules, and properly integrate them into our development
process if they so desire to join in.

thanks,

greg k-h

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Greg Kroah-Hartman]

On Wed, Feb 14, 2024 at 01:55:43PM +, Mark Brown wrote:
> On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote:
> > On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:
> 
> > > +No CVEs will be automatically assigned for unfixed security issues in
> > > +the Linux kernel; assignment will only automatically happen after a fix
> > > +is available and applied to a stable kernel tree, and it will be tracked
> > > +that way by the git commit id of the original fix. 
> 
> > I think this needs way more clarification .. how exactly is this going to 
> > work?
> 
> > Do I read this correctly that *everything* that lands in -stable will 
> > automatically get CVE assigned? If so, that's just plain crazy. Just took 
> > a random peek on the topmost -stable changelog ...
> 
> > ASoC: codecs: wsa883x: fix PA volume control
> > ASoC: codecs: lpass-wsa-macro: fix compander volume hack
> > ASoC: codecs: wcd938x: fix headphones volume controls
> > ASoC: qcom: sc8280xp: limit speaker volumes
> > drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'
> 
> > Only the last one can *potentially* be considered a CVE candidate, but 
> > someone would actually have to take a *deep* look. Most likely it'll be a 
> > functional issue, but not a security issue by any measures.
> 
> Not addressing your point in general but the speaker volume limiting is
> security relevant, that change prevents physical damage to the system.
> There's an argument for many headphone volume related fixes too since
> excessively large volumes can cause substantial distress and potential
> injury to users (I can't remember if that fix would be relevant to that
> issue).

And this points to the fact that we now have a way, if a
maintainer/developer says "hey, that commit could be a potential issue,
I want to call that out to others!" they now have a path to do so.  Just
email c...@kernel.org "can you assign a cve to git id  because of
YYY" and we will do so.

thanks!

greg k-h

[RFC][PATCH 0/8] ima: Integrate with digest_cache LSM

[Roberto Sassu]

From: Roberto Sassu 

One of the IMA shortcomings over the years has been the availability of
reference digest values for appraisal. Recently, the situation improved
and some Linux distributions are including file signatures.

The digest_cache LSM takes a different approach. Instead of requiring
Linux distributions to include file signatures in their packages, it parses
the digests from signed RPM package headers and exposes an API for
integrity providers to query a digest.

That enables Linux distributions to immediately gain the ability to do
integrity checks with the existing packages, lowering the burden for
software vendors.

In addition, integrating IMA with the digest_cache LSMs has even more
benefits.

First, it allows generating a new-style masurement list including the RPM
package headers and the unknown files, which improves system performance
due to the lower usage of the TPM. The cost is the less accuracy of the
information reported, which might not suitable for everyone.

Second, performance improve for appraisal too. It has been found that
verifying the signatures of only the RPM package headers and doing a digest
lookup is much less computationally expensive than verifying individual
file signatures.

For reference, a preliminary performance evaluation has been published
here:

https://lore.kernel.org/linux-integrity/20240209140917.846878-14-roberto.sa...@huaweicloud.com/


Third, it makes a PCR predictable and suitable for TPM key sealing
policies.

Finally, it allows IMA to maintain a predictable PCR and to perform
appraisal from the very beginning of the boot, in the initial ram disk
(of course, it won't recognize automatically generated files, that don't
exist in the RPM packages).


This patch set has some prerequisites:
- KEYS: Introduce user asymmetric keys and signatures (PGP keys and sigs)
- security: Move IMA and EVM to the LSM infrastructure
- security: digest_cache LSM (+digest_cache_changed(), introduced later)


Integration of IMA with the digest_cache LSM is straightforward.

Patch 1 lets IMA know when the digest_cache LSM is reading a digest list,
to populate a digest cache.

Patch 2 allows nested IMA verification of digest lists read by the
digest_cache LSM.

Patch 3 allows the usage of digest caches with the IMA policy.

Patch 4 introduces new boot-time policies, to use digest caches from the
very beginning (it allows measurement/appraisal from the initial ram disk).

Patch 5 attaches the verification result of the digest list to the digest
cache being populated with that digest list.

Patch 6-7 enable the usage of digest caches respectively for measurement
and appraisal, at the condition that it is authorized with the IMA policy
and that the digest list itself was measured and appraised too.

Patch 8 detects digest cache changes and consequently resets the IMA
cached verification result.

Roberto Sassu (8):
  ima: Introduce hook DIGEST_LIST_CHECK
  ima: Nest iint mutex for DIGEST_LIST_CHECK hook
  ima: Add digest_cache policy keyword
  ima: Add digest_cache_measure and digest_cache_appraise boot-time
policies
  ima: Record IMA verification result of digest lists in digest cache
  ima: Use digest cache for measurement
  ima: Use digest cache for appraisal
  ima: Detect if digest cache changed since last measurement/appraisal

 Documentation/ABI/testing/ima_policy  |   6 +-
 .../admin-guide/kernel-parameters.txt |  15 ++-
 security/integrity/ima/Kconfig|  10 ++
 security/integrity/ima/ima.h  |  24 +++-
 security/integrity/ima/ima_api.c  |  21 +++-
 security/integrity/ima/ima_appraise.c |  33 +++--
 security/integrity/ima/ima_iint.c |  14 ++-
 security/integrity/ima/ima_main.c |  81 ++--
 security/integrity/ima/ima_policy.c   | 118 +-
 9 files changed, 285 insertions(+), 37 deletions(-)

-- 
2.34.1

[RFC][PATCH 1/8] ima: Introduce hook DIGEST_LIST_CHECK

[Roberto Sassu]

From: Roberto Sassu 

Introduce a new hook to check the integrity of digest lists.

The new hook is invoked during a kernel read with file type
READING_DIGEST LIST, which is done by the digest_cache LSM when it is
populating a digest cache with a digest list.

Signed-off-by: Roberto Sassu 
---
 Documentation/ABI/testing/ima_policy | 1 +
 security/integrity/ima/ima.h | 1 +
 security/integrity/ima/ima_main.c| 3 ++-
 security/integrity/ima/ima_policy.c  | 3 +++
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/ima_policy 
b/Documentation/ABI/testing/ima_policy
index c2385183826c..22237fec5532 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -36,6 +36,7 @@ Description:
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
[KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
[SETXATTR_CHECK][MMAP_CHECK_REQPROT]
+   [DIGEST_LIST_CHECK]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
   [[^]MAY_EXEC]
fsmagic:= hex value
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 11d7c0332207..cea4517e73ab 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -310,6 +310,7 @@ static inline unsigned int ima_hash_key(u8 *digest)
hook(KEY_CHECK, key)\
hook(CRITICAL_DATA, critical_data)  \
hook(SETXATTR_CHECK, setxattr_check)\
+   hook(DIGEST_LIST_CHECK, digest_list_check)  \
hook(MAX_CHECK, none)
 
 #define __ima_hook_enumify(ENUM, str)  ENUM,
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index c84e8c55333d..780627b0cde7 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -785,7 +785,8 @@ const int read_idmap[READING_MAX_ID] = {
[READING_MODULE] = MODULE_CHECK,
[READING_KEXEC_IMAGE] = KEXEC_KERNEL_CHECK,
[READING_KEXEC_INITRAMFS] = KEXEC_INITRAMFS_CHECK,
-   [READING_POLICY] = POLICY_CHECK
+   [READING_POLICY] = POLICY_CHECK,
+   [READING_DIGEST_LIST] = DIGEST_LIST_CHECK,
 };
 
 /**
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index c0556907c2e6..7cfd1860791f 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1287,6 +1287,7 @@ static bool ima_validate_rule(struct ima_rule_entry 
*entry)
case MODULE_CHECK:
case KEXEC_KERNEL_CHECK:
case KEXEC_INITRAMFS_CHECK:
+   case DIGEST_LIST_CHECK:
if (entry->flags & ~(IMA_FUNC | IMA_MASK | IMA_FSMAGIC |
 IMA_UID | IMA_FOWNER | IMA_FSUUID |
 IMA_INMASK | IMA_EUID | IMA_PCR |
@@ -1530,6 +1531,8 @@ static int ima_parse_rule(char *rule, struct 
ima_rule_entry *entry)
entry->func = CRITICAL_DATA;
else if (strcmp(args[0].from, "SETXATTR_CHECK") == 0)
entry->func = SETXATTR_CHECK;
+   else if (strcmp(args[0].from, "DIGEST_LIST_CHECK") == 0)
+   entry->func = DIGEST_LIST_CHECK;
else
result = -EINVAL;
if (!result)
-- 
2.34.1

[RFC][PATCH 2/8] ima: Nest iint mutex for DIGEST_LIST_CHECK hook

[Roberto Sassu]

From: Roberto Sassu 

Invoking digest_cache_get() inside the iint->mutex critical region can
cause deadlocks due to the fact that IMA can be recursively invoked for
reading the digest list. The deadlock would occur if the digest_cache LSM
attempts to read the same inode that is already locked by IMA.

However, since the digest_cache LSM makes sure that the above situation
never happens, as it checks the inodes, it is safe to call
digest_cache_get() inside the critical region and nest the iint->mutex
when the DIGEST_LIST_CHECK hook is executed.

Add a lockdep subclass to the iint->mutex, that is 0 if the IMA hook
executed is not DIGEST_LIST_CHECK, and 1 when it is. Since lockdep allows
nesting with higher classes and subclasses, that effectively eliminates the
warning about the unsafe lock.

Pass the new lockdep subclass (nested variable) from ima_inode_get() to
ima_iint_init_always() and ima_iint_lockdep_annotate().

Signed-off-by: Roberto Sassu 
---
 security/integrity/ima/ima.h  |  2 +-
 security/integrity/ima/ima_iint.c | 11 ++-
 security/integrity/ima/ima_main.c |  6 +++---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index cea4517e73ab..c9140a57b591 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -216,7 +216,7 @@ static inline void ima_inode_set_iint(const struct inode 
*inode,
 }
 
 struct ima_iint_cache *ima_iint_find(struct inode *inode);
-struct ima_iint_cache *ima_inode_get(struct inode *inode);
+struct ima_iint_cache *ima_inode_get(struct inode *inode, bool nested);
 void ima_inode_free(struct inode *inode);
 void __init ima_iintcache_init(void);
 
diff --git a/security/integrity/ima/ima_iint.c 
b/security/integrity/ima/ima_iint.c
index e7c9c216c1c6..b4f476fae437 100644
--- a/security/integrity/ima/ima_iint.c
+++ b/security/integrity/ima/ima_iint.c
@@ -41,7 +41,7 @@ struct ima_iint_cache *ima_iint_find(struct inode *inode)
  * See ovl_lockdep_annotate_inode_mutex_key() for more details.
  */
 static inline void ima_iint_lockdep_annotate(struct ima_iint_cache *iint,
-struct inode *inode)
+struct inode *inode, bool nested)
 {
 #ifdef CONFIG_LOCKDEP
static struct lock_class_key ima_iint_mutex_key[IMA_MAX_NESTING];
@@ -56,7 +56,7 @@ static inline void ima_iint_lockdep_annotate(struct 
ima_iint_cache *iint,
 }
 
 static void ima_iint_init_always(struct ima_iint_cache *iint,
-struct inode *inode)
+struct inode *inode, bool nested)
 {
iint->ima_hash = NULL;
iint->version = 0;
@@ -69,7 +69,7 @@ static void ima_iint_init_always(struct ima_iint_cache *iint,
iint->ima_creds_status = INTEGRITY_UNKNOWN;
iint->measured_pcrs = 0;
mutex_init(&iint->mutex);
-   ima_iint_lockdep_annotate(iint, inode);
+   ima_iint_lockdep_annotate(iint, inode, nested);
 }
 
 static void ima_iint_free(struct ima_iint_cache *iint)
@@ -82,13 +82,14 @@ static void ima_iint_free(struct ima_iint_cache *iint)
 /**
  * ima_inode_get - Find or allocate an iint associated with an inode
  * @inode: Pointer to the inode
+ * @nested: Whether or not the iint->mutex lock can be nested
  *
  * Find an iint associated with an inode, and allocate a new one if not found.
  * Caller must lock i_mutex.
  *
  * Return: An iint on success, NULL on error.
  */
-struct ima_iint_cache *ima_inode_get(struct inode *inode)
+struct ima_iint_cache *ima_inode_get(struct inode *inode, bool nested)
 {
struct ima_iint_cache *iint;
 
@@ -100,7 +101,7 @@ struct ima_iint_cache *ima_inode_get(struct inode *inode)
if (!iint)
return NULL;
 
-   ima_iint_init_always(iint, inode);
+   ima_iint_init_always(iint, inode, nested);
 
inode->i_flags |= S_IMA;
ima_inode_set_iint(inode, iint);
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index 780627b0cde7..18285fc8ac07 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -248,7 +248,7 @@ static int process_measurement(struct file *file, const 
struct cred *cred,
inode_lock(inode);
 
if (action) {
-   iint = ima_inode_get(inode);
+   iint = ima_inode_get(inode, func == DIGEST_LIST_CHECK);
if (!iint)
rc = -ENOMEM;
}
@@ -699,7 +699,7 @@ static void ima_post_create_tmpfile(struct mnt_idmap *idmap,
return;
 
/* Nothing to do if we can't allocate memory */
-   iint = ima_inode_get(inode);
+   iint = ima_inode_get(inode, false);
if (!iint)
return;
 
@@ -731,7 +731,7 @@ static void ima_post_path_mknod(struct mnt_idmap *idmap, 
struct dentry *dentry)
return;
 
/* Nothing to do if we can't allocate memory */
-   ii

[RFC][PATCH 3/8] ima: Add digest_cache policy keyword

[Roberto Sassu]

From: Roberto Sassu 

Add the 'digest_cache=' policy keyword, to enable the usage of digest
caches for specific IMA actions and purposes.

At the moment, it accepts only 'content' as value, as digest caches can be
only used only for measurement and appraisal of file content. In the
future, it might be possible to use them for file metadata too.

The 'digest_cache=' keyword can be specified for the subset of IMA hooks
listed in ima_digest_cache_func_allowed().

POLICY_CHECK has been excluded for measurement, because policy changes must
be visible in the IMA measurement list. For appraisal, instead, it might be
useful to load custom policies in the initial ram disk (no security.ima
xattr).

Add the digest_cache_mask member to the ima_rule_entry structure, and set
the flag IMA_DIGEST_CACHE_MEASURE_CONTENT if 'digest_cache=content' was
specified for a measure rule, IMA_DIGEST_CACHE_APPRAISE_CONTENT for an
appraise rule.

Propagate the mask down to ima_match_policy() and ima_get_action(), so that
process_measurement() can make the final decision on whether or not digest
caches should be used to measure/appraise the file being evaluated.

Since using digest caches changes the meaning of the IMA measurement list,
which will include only digest lists and unknown files, enforce specifying
'pcr=' with a non-standard value, when 'digest_cache=content' is specified
in a measure rule.

This removes the ambiguity on the meaning of the IMA measurement list.

Signed-off-by: Roberto Sassu 
---
 Documentation/ABI/testing/ima_policy  |  5 +-
 security/integrity/ima/ima.h  | 10 +++-
 security/integrity/ima/ima_api.c  |  6 ++-
 security/integrity/ima/ima_appraise.c |  2 +-
 security/integrity/ima/ima_main.c |  8 +--
 security/integrity/ima/ima_policy.c   | 70 ++-
 6 files changed, 89 insertions(+), 12 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy 
b/Documentation/ABI/testing/ima_policy
index 22237fec5532..be045fb60530 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -29,7 +29,7 @@ Description:
 [obj_user=] [obj_role=] [obj_type=]]
option: [digest_type=] [template=] [permit_directio]
[appraise_type=] [appraise_flag=]
-   [appraise_algos=] [keyrings=]
+   [appraise_algos=] [keyrings=] [digest_cache=]
  base:
func:= 
[BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
@@ -77,6 +77,9 @@ Description:
For example, "sha256,sha512" to only accept to appraise
files where the security.ima xattr was hashed with one
of these two algorithms.
+   digest_cache:= [content]
+   "content" means that the digest cache is used only
+   for file content measurement and/or appraisal.
 
  default policy:
# PROC_SUPER_MAGIC
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index c9140a57b591..deee56d99d6f 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -43,6 +43,10 @@ enum tpm_pcrs { TPM_PCR0 = 0, TPM_PCR8 = 8, TPM_PCR10 = 10 };
 
 #define NR_BANKS(chip) ((chip != NULL) ? chip->nr_allocated_banks : 0)
 
+/* Digest cache usage flags. */
+#define IMA_DIGEST_CACHE_MEASURE_CONTENT   0x0001
+#define IMA_DIGEST_CACHE_APPRAISE_CONTENT  0x0002
+
 /* current content of the policy */
 extern int ima_policy_flag;
 
@@ -367,7 +371,8 @@ int ima_get_action(struct mnt_idmap *idmap, struct inode 
*inode,
   const struct cred *cred, u32 secid, int mask,
   enum ima_hooks func, int *pcr,
   struct ima_template_desc **template_desc,
-  const char *func_data, unsigned int *allowed_algos);
+  const char *func_data, unsigned int *allowed_algos,
+  u64 *digest_cache_mask);
 int ima_must_measure(struct inode *inode, int mask, enum ima_hooks func);
 int ima_collect_measurement(struct ima_iint_cache *iint, struct file *file,
void *buf, loff_t size, enum hash_algo algo,
@@ -398,7 +403,8 @@ int ima_match_policy(struct mnt_idmap *idmap, struct inode 
*inode,
 const struct cred *cred, u32 secid, enum ima_hooks func,
 int mask, int flags, int *pcr,
 struct ima_template_desc **template_desc,
-const char *func_data, unsigned int *allowed_algos);
+const char *func_data, unsigned int *allowed_algos,
+u64 *digest_cache_mask);
 void ima_init_policy(void);
 void ima_update_policy(void);
 void ima_update_policy_flags(void);
diff --git a/security/integri

[RFC][PATCH 4/8] ima: Add digest_cache_measure and digest_cache_appraise boot-time policies

[Roberto Sassu]

From: Roberto Sassu 

Specify the 'digest_cache_measure' boot-time policy with 'ima_policy=' in
the kernel command line to add the following rule at the beginning of the
IMA policy, before other rules:

measure func=DIGEST_LIST_CHECK pcr=12

which will measure digest lists into PCR 12 (or the value in
CONFIG_IMA_DIGEST_CACHE_MEASURE_PCR_IDX).

'digest_cache_measure' also adds 'digest_cache=content pcr=12' to the other
measure rules, if they have a compatible IMA hook. The PCR value still
comes from CONFIG_IMA_DIGEST_CACHE_MEASURE_PCR_IDX.

Specify 'digest_cache_appraise' to add the following rule at the beginning,
before other rules:

appraise func=DIGEST_LIST_CHECK appraise_type=imasig|modsig

which will appraise digest lists with IMA signatures or module-style
appended signatures.

'digest_cache_appraise' also adds 'digest_cache=content' to the other
appraise rules, if they have a compatible IMA hook.

Signed-off-by: Roberto Sassu 
---
 .../admin-guide/kernel-parameters.txt | 15 ++-
 security/integrity/ima/Kconfig| 10 +
 security/integrity/ima/ima_policy.c   | 45 +++
 3 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 31b3a25680d0..a79967fcba7d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2011,7 +2011,8 @@
ima_policy= [IMA]
The builtin policies to load during IMA setup.
Format: "tcb | appraise_tcb | secure_boot |
-fail_securely | critical_data"
+fail_securely | critical_data |
+digest_cache_measure | digest_cache_appraise"
 
The "tcb" policy measures all programs exec'd, files
mmap'd for exec, and all files opened with the read
@@ -2033,6 +2034,18 @@
The "critical_data" policy measures kernel integrity
critical data.
 
+   The "digest_cache_measure" policy measures digest lists
+   into PCR 12 (can be changed with kernel config), enables
+   the digest cache to be used for the other selected
+   measure rules (if compatible), and measures the files
+   with digest not found in the digest list into PCR 12
+   (changeable).
+
+   The "digest_cache_appraise" policy appraises digest
+   lists with IMA signatures or module-style appended
+   signatures, and enables the digest cache to be used for
+   the other selected appraise rules (if compatible).
+
ima_tcb [IMA] Deprecated.  Use ima_policy= instead.
Load a policy which meets the needs of the Trusted
Computing Base.  This means IMA will measure all
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 475c32615006..6a481019fb6e 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -321,4 +321,14 @@ config IMA_DISABLE_HTABLE
help
   This option disables htable to allow measurement of duplicate 
records.
 
+config IMA_DIGEST_CACHE_MEASURE_PCR_IDX
+   int
+   range 8 14
+   default 12
+   help
+ This option determines the TPM PCR register index that IMA uses to
+ maintain the integrity aggregate of the measurement list, when the
+ digest_cache LSM is used (different measurement style).  If unsure,
+ use the default 12.
+
 endif
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 4ac83df8d255..04127f962ef4 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -254,6 +254,21 @@ static struct ima_rule_entry critical_data_rules[] 
__ro_after_init = {
{.action = MEASURE, .func = CRITICAL_DATA, .flags = IMA_FUNC},
 };
 
+static struct ima_rule_entry measure_digest_cache_rule __ro_after_init = {
+#ifdef CONFIG_SECURITY_DIGEST_CACHE
+   .action = MEASURE, .func = DIGEST_LIST_CHECK,
+   .pcr = CONFIG_IMA_DIGEST_CACHE_MEASURE_PCR_IDX,
+   .flags = IMA_FUNC | IMA_PCR
+#endif
+};
+
+static struct ima_rule_entry appraise_digest_cache_rule __ro_after_init = {
+#ifdef CONFIG_SECURITY_DIGEST_CACHE
+   .action = APPRAISE, .func = DIGEST_LIST_CHECK,
+   .flags = IMA_FUNC | IMA_DIGSIG_REQUIRED | IMA_MODSIG_ALLOWED,
+#endif
+};
+
 /* An array of architecture specific rules */
 static struct ima_rule_entry *arch_policy_entry __ro_after_init;
 
@@ -278,6 +293,8 @@ static bool ima_use_appraise_tcb __initdata;
 static bool ima_use_secure_boot __initdata;
 static bool ima_use_critical_data __initdata;
 stat

[RFC][PATCH 5/8] ima: Record IMA verification result of digest lists in digest cache

[Roberto Sassu]

From: Roberto Sassu 

The digest_cache LSM allows integrity providers to record how the digest
list being used to populate the digest cache was verified.

Integrity providers can register a kernel_post_read_file LSM hook
implementation, and call digest_cache_verif_set() providing the result of
the digest list verification, together with the digest list file
descriptor.

IMA calls digest_cache_verif_set() during the DIGEST_LIST_CHECK hook
(kernel read with file type READING_DIGEST_LIST), and attaches to the
digest cache a u64 variable with the IMA_DIGEST_CACHE_MEASURE_CONTENT and
IMA_DIGEST_CACHE_APPRAISE_CONTENT flags set, if the digest list was
respectively measured and appraised.

The same flags are set in another u64 variable, if 'digest_cache=content'
appears respectively in a measure or appraise rule.

The final decision on whether the digest cache can be used for measurement
and appraisal depends on the AND of these two variables, so it must have
been authorized with the IMA policy and the same action must have been done
on the digest list.

This prevents remote verifiers from receiving an incomplete IMA measurement
list, where measurements are skipped, but there isn't the digest list the
calculated file digest was search into. It also prevents successful
appraisal without appraising the digest list itself.

Signed-off-by: Roberto Sassu 
---
 security/integrity/ima/ima.h  |  1 +
 security/integrity/ima/ima_main.c | 19 ++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index deee56d99d6f..2dbcaf0a9402 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "../integrity.h"
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index e3ca80098c4c..3fc48214850a 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -214,7 +214,7 @@ static int process_measurement(struct file *file, const 
struct cred *cred,
char *pathbuf = NULL;
char filename[NAME_MAX];
const char *pathname = NULL;
-   int rc = 0, action, must_appraise = 0;
+   int rc = 0, digest_cache_rc, action, must_appraise = 0;
int pcr = CONFIG_IMA_MEASURE_PCR_IDX;
struct evm_ima_xattr_data *xattr_value = NULL;
struct modsig *modsig = NULL;
@@ -222,6 +222,7 @@ static int process_measurement(struct file *file, const 
struct cred *cred,
bool violation_check;
enum hash_algo hash_algo;
unsigned int allowed_algos = 0;
+   u64 verif_mask = 0;
 
if (!ima_policy_flag || !S_ISREG(inode->i_mode))
return 0;
@@ -399,6 +400,22 @@ static int process_measurement(struct file *file, const 
struct cred *cred,
if ((mask & MAY_WRITE) && test_bit(IMA_DIGSIG, &iint->atomic_flags) &&
 !(iint->flags & IMA_NEW_FILE))
rc = -EACCES;
+   if (!rc && func == DIGEST_LIST_CHECK) {
+   if (iint->flags & IMA_MEASURED)
+   verif_mask |= IMA_DIGEST_CACHE_MEASURE_CONTENT;
+   if (iint->flags & IMA_APPRAISED_SUBMASK)
+   verif_mask |= IMA_DIGEST_CACHE_APPRAISE_CONTENT;
+
+   /* Remember actions done on digest list for later use. */
+   digest_cache_rc = digest_cache_verif_set(file, "ima",
+&verif_mask,
+sizeof(verif_mask));
+   /* Ignore if fd doesn't have digest cache set (prefetching). */
+   if (digest_cache_rc && digest_cache_rc != -ENOENT)
+   pr_debug("Cannot set verification mask for %s, ret: %d, 
ignoring\n",
+file_dentry(file)->d_name.name,
+digest_cache_rc);
+   }
mutex_unlock(&iint->mutex);
kfree(xattr_value);
ima_free_modsig(modsig);
-- 
2.34.1

[RFC][PATCH 6/8] ima: Use digest cache for measurement

[Roberto Sassu]

From: Roberto Sassu 

Introduce a new measurement style using digest caches, which can be
performed exclusively on non-standard PCRs, to avoid ambiguity.

While a measurement on the standard PCR means that a file was accessed and
had the measured content, a measurement with the digest cache means only
that the calculated file digest was not found in any of the measured digest
lists (any digest list used for the search must be measured, otherwise IMA
wouldn't use it).

The new measurement style does not tell: whether or not the file was
actually accessed (since its measurement is skipped even if it was); in
which sequence files were accessed. So, one has to guess that the system
might have possibly accessed any of the files whose digest is in the
measured digest lists, in any order.

However, it has the following benefits: the IMA measurement list can be
much shorter, system performance can be much better due to less PCR extend
operations (see the performance evaluation in the digest_cache LSM
documentation); the PCR can be predictable as long as the set of measured
digest lists does not change (which obviously happens during software
updates).

The PCR can be predictable because the digest_cache LSM has a prefetching
mechanism that reads digest lists in a deterministic order, until it
finds the digest list containing the digest calculated by IMA from an
accessed file. If IMA measures digest lists, the PCR is extended in a
deterministic order too.

Predictable PCR means that a TPM key can be made dependent on specific PCR
values (or a OR of them, depending on the key policy). Accessing a file
with an unknown digest immediately makes that TPM key unusable, requiring a
reboot to use it again.

This mechanism can be used for the so called implicit remote attestation,
where the ability of a system to respond to challenges based on the private
part of the TPM key means that the system has the expected PCR values
(which would mean that the integrity of the system is ok). This is opposed
to the explicit remote attestation, where a system has to send all its
measurements, to prove to a remote party about its integrity.

If the IMA policy allows the usage of the digest cache for the current file
access (except for DIGEST_LIST_CHECK hook, not supported), call
digest_cache_get() in process_measurement() to get a digest cache for that
file, and call digest_cache_lookup() to search the calculated file digest.

Doing the lookup is necessary to retrieve the digest cache containing the
digest, since digest_cache_get() might only return a directory digest
cache, useful only to iterate over the digest caches of the directory
entries.

If digest_cache_lookup() returns a positive value (digest cache reference
in the digest_cache_found_t form), call digest_cache_from_found_t() to get
an usable digest cache pointer, and digest_cache_verif_get() to get
the verification result of the corresponding digest list, and AND it with
the policy mask.

Then, pass the AND result to ima_store_measurement() and, if the result has
the IMA_DIGEST_CACHE_MEASURE_CONTENT flag set, behave as if the file was
successfully added to the IMA measurement list (i.e. set the IMA_MEASURED
flag and the PCR flag from the value specified in the matching policy
rule), but actually don't do it.

Finally, release the digest cache reference acquired with
digest_cache_get(), by calling digest_cache_put().

Signed-off-by: Roberto Sassu 
---
 security/integrity/ima/ima.h  |  3 ++-
 security/integrity/ima/ima_api.c  | 15 ++-
 security/integrity/ima/ima_main.c | 32 ---
 3 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 2dbcaf0a9402..cf04f5a22234 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -382,7 +382,8 @@ void ima_store_measurement(struct ima_iint_cache *iint, 
struct file *file,
   const unsigned char *filename,
   struct evm_ima_xattr_data *xattr_value,
   int xattr_len, const struct modsig *modsig, int pcr,
-  struct ima_template_desc *template_desc);
+  struct ima_template_desc *template_desc,
+  u64 digest_cache_mask);
 int process_buffer_measurement(struct mnt_idmap *idmap,
   struct inode *inode, const void *buf, int size,
   const char *eventname, enum ima_hooks func,
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index 87e286ace43c..b216f86c983d 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -345,7 +345,8 @@ void ima_store_measurement(struct ima_iint_cache *iint, 
struct file *file,
   const unsigned char *filename,
   struct evm_ima_xattr_data *xattr_value,
   i

[RFC][PATCH 7/8] ima: Use digest cache for appraisal

[Roberto Sassu]

From: Roberto Sassu 

Similarly to measurement, enable the new appraisal style too using digest
caches.

Instead of verifying individual file signatures, verify the signature of
lists of digests and search calculated file digests in those lists.

The benefits are that signed lists of digests already exist (e.g. RPM
package headers), although their format needs to be supported by the
digest_cache LSM, and appraisal with digest lists is computationally much
less expensive than with individual file signatures (see the performance
evaluation of the digest_cache LSM).

As for measurement, pass the AND of the policy mask and the digest list
verification mask to ima_appraise_measurement().

If EVM is disabled or the file does not have any protected xattr
(evm_verifyxattr() returns INTEGRITY_UNKNOWN or INTEGRITY_NOXATTRS), the
other appraisal methods (xattr and modsig) are not available, and the AND
of the masks has the IMA_DIGEST_CACHE_APPRAISE_CONTENT flag set, mark the
file as successfully appraised (i.e. set the integrity status to
INTEGRITY_PASS and return zero).

Signed-off-by: Roberto Sassu 
---
 security/integrity/ima/ima.h  |  6 --
 security/integrity/ima/ima_appraise.c | 31 +--
 security/integrity/ima/ima_main.c |  3 ++-
 3 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index cf04f5a22234..36faf2bc81b0 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -433,7 +433,8 @@ int ima_check_blacklist(struct ima_iint_cache *iint,
 int ima_appraise_measurement(enum ima_hooks func, struct ima_iint_cache *iint,
 struct file *file, const unsigned char *filename,
 struct evm_ima_xattr_data *xattr_value,
-int xattr_len, const struct modsig *modsig);
+int xattr_len, const struct modsig *modsig,
+u64 digest_cache_mask);
 int ima_must_appraise(struct mnt_idmap *idmap, struct inode *inode,
  int mask, enum ima_hooks func);
 void ima_update_xattr(struct ima_iint_cache *iint, struct file *file);
@@ -458,7 +459,8 @@ static inline int ima_appraise_measurement(enum ima_hooks 
func,
   const unsigned char *filename,
   struct evm_ima_xattr_data 
*xattr_value,
   int xattr_len,
-  const struct modsig *modsig)
+  const struct modsig *modsig,
+  u8 digest_cache_mask)
 {
return INTEGRITY_UNKNOWN;
 }
diff --git a/security/integrity/ima/ima_appraise.c 
b/security/integrity/ima/ima_appraise.c
index 27ccc9a2c09f..dcea88d502a9 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -478,7 +478,8 @@ int ima_check_blacklist(struct ima_iint_cache *iint,
 int ima_appraise_measurement(enum ima_hooks func, struct ima_iint_cache *iint,
 struct file *file, const unsigned char *filename,
 struct evm_ima_xattr_data *xattr_value,
-int xattr_len, const struct modsig *modsig)
+int xattr_len, const struct modsig *modsig,
+u64 digest_cache_mask)
 {
static const char op[] = "appraise_data";
const char *cause = "unknown";
@@ -488,12 +489,19 @@ int ima_appraise_measurement(enum ima_hooks func, struct 
ima_iint_cache *iint,
int rc = xattr_len;
bool try_modsig = iint->flags & IMA_MODSIG_ALLOWED && modsig;
 
-   /* If not appraising a modsig, we need an xattr. */
-   if (!(inode->i_opflags & IOP_XATTR) && !try_modsig)
+   /*
+* If not appraising a modsig/there is no digest cache match, we need
+* an xattr.
+*/
+   if (!(inode->i_opflags & IOP_XATTR) && !try_modsig &&
+   !digest_cache_mask)
return INTEGRITY_UNKNOWN;
 
-   /* If reading the xattr failed and there's no modsig, error out. */
-   if (rc <= 0 && !try_modsig) {
+   /*
+* If reading the xattr failed and there's no modsig/digest cache match,
+* error out.
+*/
+   if (rc <= 0 && !try_modsig && !digest_cache_mask) {
if (rc && rc != -ENODATA)
goto out;
 
@@ -524,8 +532,11 @@ int ima_appraise_measurement(enum ima_hooks func, struct 
ima_iint_cache *iint,
case INTEGRITY_UNKNOWN:
break;
case INTEGRITY_NOXATTRS:/* No EVM protected xattrs. */
-   /* It's fine not to have xattrs when using a modsig. */
-   if (try_modsig)
+   /*
+* It's fine not to have xattrs when using a modsig or the
+* digest cache.
+

[RFC][PATCH 8/8] ima: Detect if digest cache changed since last measurement/appraisal

[Roberto Sassu]

From: Roberto Sassu 

IMA invalidates the cached verification result on file content/metadata
update, so that the file is evaluated again at next access.

While until now checking modifications on the file was sufficient to
determine if the cached verification result is still valid, that no longer
applies if that verification result was obtained with digest caches.

In that case, it is also necessary to check modifications on the digest
lists and on the security.digest_list xattr of the files for which digest
caches are used.

The digest_cache LSM offers the digest_cache_changed() function, which
tells if a file would use a different digest cache than the one passed as
argument. digest_cache_get() might return a different digest cache if the
digest list was modified/deleted/renamed or the security.digest_list xattr
was modified.

Hold a digest cache reference in the IMA integrity metadata, when using it
for measurement/appraisal. At every file access, check if that reference is
still actual by passing it to digest_cache_changed(). If not, reset the
integrity status and do the verification again.

Finally, move the digest_cache_put() call from process_measurement() to
ima_iint_free(), unless the digest cache changed. In that case, still
release the reference in process_measurement().

Signed-off-by: Roberto Sassu 
---
 security/integrity/ima/ima.h  |  1 +
 security/integrity/ima/ima_iint.c |  3 +++
 security/integrity/ima/ima_main.c | 22 ++
 3 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 36faf2bc81b0..c25bde918cd5 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -192,6 +192,7 @@ struct ima_iint_cache {
enum integrity_status ima_read_status:4;
enum integrity_status ima_creds_status:4;
struct ima_digest_data *ima_hash;
+   struct digest_cache *digest_cache;
 };
 
 extern struct lsm_blob_sizes ima_blob_sizes;
diff --git a/security/integrity/ima/ima_iint.c 
b/security/integrity/ima/ima_iint.c
index b4f476fae437..fd369809809f 100644
--- a/security/integrity/ima/ima_iint.c
+++ b/security/integrity/ima/ima_iint.c
@@ -68,6 +68,7 @@ static void ima_iint_init_always(struct ima_iint_cache *iint,
iint->ima_read_status = INTEGRITY_UNKNOWN;
iint->ima_creds_status = INTEGRITY_UNKNOWN;
iint->measured_pcrs = 0;
+   iint->digest_cache = NULL;
mutex_init(&iint->mutex);
ima_iint_lockdep_annotate(iint, inode, nested);
 }
@@ -75,6 +76,8 @@ static void ima_iint_init_always(struct ima_iint_cache *iint,
 static void ima_iint_free(struct ima_iint_cache *iint)
 {
kfree(iint->ima_hash);
+   if (iint->digest_cache)
+   digest_cache_put(iint->digest_cache);
mutex_destroy(&iint->mutex);
kmem_cache_free(ima_iint_cache, iint);
 }
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index a66522a22cbc..e1b2f5737753 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -301,6 +301,15 @@ static int process_measurement(struct file *file, const 
struct cred *cred,
}
}
 
+   /* Check if digest cache changed since last measurement/appraisal. */
+   if (iint->digest_cache &&
+   digest_cache_changed(inode, iint->digest_cache)) {
+   iint->flags &= ~IMA_DONE_MASK;
+   iint->measured_pcrs = 0;
+   digest_cache_put(iint->digest_cache);
+   iint->digest_cache = NULL;
+   }
+
/* Determine if already appraised/measured based on bitmask
 * (IMA_MEASURE, IMA_MEASURED, IMA__APPRAISE, IMA__APPRAISED,
 *  IMA_AUDIT, IMA_AUDITED)
@@ -371,8 +380,15 @@ static int process_measurement(struct file *file, const 
struct cred *cred,
 * Since we allow IMA policy rules without func=, we have to enforce
 * this restriction here.
 */
-   if (rc == 0 && policy_mask && func != DIGEST_LIST_CHECK)
-   digest_cache = digest_cache_get(file_dentry(file));
+   if (rc == 0 && policy_mask && func != DIGEST_LIST_CHECK) {
+   if (!iint->digest_cache) {
+   /* Released by ima_iint_free(). */
+   digest_cache = digest_cache_get(file_dentry(file));
+   iint->digest_cache = digest_cache;
+   } else {
+   digest_cache = iint->digest_cache;
+   }
+   }
 
if (digest_cache) {
found = digest_cache_lookup(file_dentry(file), digest_cache,
@@ -386,8 +402,6 @@ static int process_measurement(struct file *file, const 
struct cred *cred,
if (verif_mask_ptr)
allow_mask = policy_mask & *verif_mask_ptr;
}
-
-   digest_cache_put(digest_cache);
}
 
if (action & IMA_MEASURE)
-- 
2.34.1

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Jiri Kosina]

On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:

> The people that make up the current team, Lee, Sasha, and I, have a LONG
> history of fixing and triaging and managing security bugs for the
> kernel, in the community and in corporate environments.  We know how to
> do this as we have been doing it for decades already.  

Thanks for clarifying. Maybe the wording could use some more verbosity 
then; one of my potential readings of it was "everything that gets picked 
for -stable will get a CVE assigned".

> If you or anyone else wishes to help us out with this classification, we 
> can gladly use the help.

Thanks, but no, thanks, I want to stay away from the CVE tragedy as far as 
possible :)

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Jiri Kosina]

On Wed, 14 Feb 2024, Mark Brown wrote:

> Not addressing your point in general but the speaker volume limiting is
> security relevant, that change prevents physical damage to the system.
> There's an argument for many headphone volume related fixes too since
> excessively large volumes can cause substantial distress and potential
> injury to users (I can't remember if that fix would be relevant to that
> issue).

Thanks, I guess you are actually supporting my point, and that is -- there 
is no consensus whatsoever of what assigning a CVE actually means, at all.

To me -- physical damage to the system, fair enough, that might really 
easily be security relevant.

Something being too loud, causing distress ... that's really a grey zone 
(to put it mildly) for me. How about e.g. a bug in GPU driver, leading to 
a flickering screen? Many people are very sensitive to that (both 
physically and mentally) for various reasons.

Bug worth fixing? Absolutely, as soon as possible. Security-relevant? Not 
in my book.

To me, kernel is in no way special, in this respect, actually. With each 
and every coding error in software of your choice, given anough fantasy, 
you'll come up with a scenario where this will cause some real issues to 
some living human.

That's not what CVE is about at all, at least in my understaing.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Greg Kroah-Hartman]

On Wed, Feb 14, 2024 at 03:38:52PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:
> 
> > The people that make up the current team, Lee, Sasha, and I, have a LONG
> > history of fixing and triaging and managing security bugs for the
> > kernel, in the community and in corporate environments.  We know how to
> > do this as we have been doing it for decades already.  
> 
> Thanks for clarifying. Maybe the wording could use some more verbosity 
> then; one of my potential readings of it was "everything that gets picked 
> for -stable will get a CVE assigned".

CVE has a very specific definition already, as per cve.org:

 CVE Record is the descriptive data about a vulnerability
 associated with a CVE ID, provided by a CVE Numbering Authority
 (CNA). This data is provided in multiple human and
 machine-readable formats.

And they define "vulnerability" as:

An instance of one or more weaknesses in a Product that can be
exploited, causing a negative impact to confidentiality,
integrity, or availability; a set of conditions or behaviors
that allows the violation of an explicit or implicit security
policy.

and as a CNA we must follow that definition.  No need to restate the CVE
rules in our own document, I am sure that if we don't follow them, lots
of people will be quick to point it out and we will revoke those ids
that we mess up on.

thanks,

greg k-h

Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Mark Brown]

On Wed, Feb 14, 2024 at 03:46:12PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Mark Brown wrote:

> > There's an argument for many headphone volume related fixes too since
> > excessively large volumes can cause substantial distress and potential
> > injury to users (I can't remember if that fix would be relevant to that
> > issue).

> Something being too loud, causing distress ... that's really a grey zone 
> (to put it mildly) for me. How about e.g. a bug in GPU driver, leading to 
> a flickering screen? Many people are very sensitive to that (both 
> physically and mentally) for various reasons.

> Bug worth fixing? Absolutely, as soon as possible. Security-relevant? Not 
> in my book.

To be clear, most headphone drivers can easily generate output levels
which will cause temporary or permanent hearing loss after very brief
exposure.  The distress is the urgent and instinctive need to remove the
headphones as fast as possible that tends to result, much as it would
for any other ongoing source of injury.


signature.asc
Description: PGP signature

Re: [PATCH] Documentation: Document the Linux Kernel CVE process

[Randy Dunlap]

On 2/13/24 23:15, Greg Kroah-Hartman wrote:
> On Tue, Feb 13, 2024 at 11:56:42AM -0800, Randy Dunlap wrote:
>>> +As part of the normal stable release process, kernel changes that are
>>> +potentially security issues are identified by the developers responsible
>>> +for CVE number assignments and have CVE numbers automatically assigned
>>> +to them.  These assignments are published on the linux-cve mailing list
>>
>> linux-cve-announce 
>> mailing list
> 
> Ah, good catch, you can see the "old" name for the list here, this is
> due to this document being an older version, a symptom of "write it on
> my workstation, sync to laptop, travel with laptop for 3+ weeks and make
> changes based on meetings with CVE and others and then forget to sync
> from laptop when arriving home".
> 
> Ugh :(
> 
> Thanks so much for the grammer fixes, they are much appreciated.  I'll
> apply them and send out the latest version in a bit.
> 
>>> +No CVEs will be assigned for unfixed security issues in the Linux
>>> +kernel, assignment will only happen after a fix is available as it can
>>
>>kernel;
>>
>>> +be properly tracked that way by the git commit id of the original fix.
> 
> One of my goals in life is to never use a ';' in a sentence, and after
> writing 2 books without them, I thought I achieve that pretty well as I
> never seem to remember when they are to be used or not.  But I'll trust
> you on this and use it here.

For some reason kernel documentation has a plethora of run-on sentences. :(

Guess we need doclint.

-- 
#Randy

Re: [PATCH v3 00/35] Memory allocation profiling

[Andrew Morton]

On Tue, 13 Feb 2024 14:59:11 -0800 Suren Baghdasaryan  wrote:

> > > If you think you can easily achieve what Michal requested without all 
> > > that,
> > > good.
> >
> > He requested something?
> 
> Yes, a cleaner instrumentation. Unfortunately the cleanest one is not
> possible until the compiler feature is developed and deployed. And it
> still would require changes to the headers, so don't think it's worth
> delaying the feature for years.

Can we please be told much more about this compiler feature? 
Description of what it is, what it does, how it will affect this kernel
feature, etc.

Who is developing it and when can we expect it to become available?

Will we be able to migrate to it without back-compatibility concerns? 
(I think "you need quite recent gcc for memory profiling" is
reasonable).



Because: if the maintainability issues which Michel describes will be
significantly addressed with the gcc support then we're kinda reviewing
the wrong patchset.  Yes, it may be a maintenance burden initially, but
at some (yet to be revealed) time in the future, this will be addressed
with the gcc support?

Re: [PATCH] Documentation: Document the Linux Kernel CVE process

[Kees Cook]

On Wed, Feb 14, 2024 at 08:45:19AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 14, 2024 at 07:43:32AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Feb 13, 2024 at 02:35:24PM -0800, Kees Cook wrote:
> > > On Tue, Feb 13, 2024 at 07:48:12PM +0100, Greg Kroah-Hartman wrote:
> > > > +No CVEs will be assigned for unfixed security issues in the Linux
> > > > +kernel, assignment will only happen after a fix is available as it can
> > > > +be properly tracked that way by the git commit id of the original fix.
> > > 
> > > This seems at odds with the literal definition of what CVEs are:
> > > _vulnerability_ enumeration. This is used especially during the
> > > coordination of fixes; how is this meant to interact with embargoed
> > > vulnerability fixing?
> > 
> > Yes, this is totally wrong, it was the original first draft of the
> > document, that I did on my workstation, and then went on the road for 3+
> > weeks and I never sycned up when I got home with the updated version
> > that is on my laptop.  The updated version addresses this, as it was
> > rightly pointed out by the CVE group that this is not how a CNA is
> > supposed to only work.
> > 
> > Yet another reason why keeping changes private is a major pain, not only
> > for security ones!  :(
> > 
> > Let me send out the proper one after my morning coffee has kicked in and
> > I resolve the differences, and make the grammer fixes that Randy pointed
> > out...
> 
> To make it more obvious here, as others have pointed this out to me as
> well, here's the updated paragraph that will be in my v2 patch, with
> proper ';' usage:
> 
>   No CVEs will be automatically assigned for unfixed security issues in
>   the Linux kernel; assignment will only automatically happen after a fix
>   is available and applied to a stable kernel tree, and it will be tracked
>   that way by the git commit id of the original fix.  If anyone wishes to
>   have a CVE assigned before an issue is resolved with a commit, please
>   contact the kernel CVE assignment team at  to get an
>   identifier assigned from their batch of reserved identifiers.
> 
> Does that help explain the process better?

Yeah, that's great. It get qualified with the "automatic" bit, which
makes this clear now. Thanks!

-Kees

-- 
Kees Cook

[PATCH] Documentation: update mailing list addresses

[Konstantin Ryabitsev]

ER
 M: Dragos Tatulea 
-L: virtualizat...@lists.linux-foundation.org
+L: virtualizat...@lists.linux.dev
 S: Supported
 F: drivers/vdpa/mlx5/
 
@@ -21519,7 +21519,7 @@ F:  tools/testing/selftests/drivers/net/team/
 TECHNICAL ADVISORY BOARD PROCESS DOCS
 M: "Theodore Ts'o" 
 M: Greg Kroah-Hartman 
-L: tech-board-disc...@lists.linux-foundation.org
+L: tech-board-disc...@lists.linux.dev
 S: Maintained
 F: Documentation/process/contribution-maturity-model.rst
 F: Documentation/process/researcher-guidelines.rst
@@ -23078,7 +23078,7 @@ F:  drivers/vfio/pci/mlx5/
 VFIO VIRTIO PCI DRIVER
 M: Yishai Hadas 
 L: k...@vger.kernel.org
-L: virtualizat...@lists.linux-foundation.org
+L: virtualizat...@lists.linux.dev
 S: Maintained
 F: drivers/vfio/pci/virtio
 

---
base-commit: 7e90b5c295ec1e47c8ad865429f046970c549a66
change-id: 20240214-lf-org-list-migration-0f81f19a1333

Best regards,
-- 
Konstantin Ryabitsev 

Re: [PATCH] Documentation: embargoed-hardware-issues.rst: Fix Trilok's email

[Jonathan Corbet]

Trilok Soni  writes:

> On 2/2/2024 9:06 AM, Carlos Bilbao wrote:
>> On 2/2/24 10:48, Greg KH wrote:
>>> On Fri, Feb 02, 2024 at 09:41:19AM -0700, Jeffrey Hugo wrote:
 The servers for the @codeaurora domain have long been retired and any
 messages addressed to @codeaurora will bounce.

 Trilok has an entry in .mailmap, but the raw documentation files still
 list an old @codeaurora address.  Update the address in the
 documentation files for anyone reading them.

 Signed-off-by: Jeffrey Hugo 
 ---
   Documentation/process/embargoed-hardware-issues.rst | 2 +-
   .../translations/sp_SP/process/embargoed-hardware-issues.rst    | 2 +-
   .../translations/zh_CN/process/embargoed-hardware-issues.rst    | 2 +-
   .../translations/zh_TW/process/embargoed-hardware-issues.rst    | 2 +-
   4 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> I think we need an ack from Trilok for this :)
>> 
>> Assuming ack from Trilok, regarding the Spanish documentation,
>> 
>> Reviewed-by: Carlos Bilbao 
>
> Looks good to me. Thank you.
>
> Reviewed-by: Trilok Soni  

Applied, thanks.

jon

Re: [PATCH] Documentation: update mailing list addresses

[Kees Cook]

On Wed, Feb 14, 2024 at 03:09:53PM -0500, Konstantin Ryabitsev wrote:
> The mailman2 server running on lists.linuxfoundation.org will be shut
> down in very imminent future. Update all instances of obsolete list
> addresses throughout the tree with their new destinations.
> 
> Signed-off-by: Konstantin Ryabitsev 

Thanks for this! I had just updated the TAB's internal docs for the list
changes too.

Reviewed-by: Kees Cook 

-- 
Kees Cook

[PATCH 1/1] Documentation: hyperv: Add overview of PCI pass-thru device support

[mhkelley58]

From: Michael Kelley 

Add documentation topic for PCI pass-thru devices in Linux guests
on Hyper-V and for the associated PCI controller driver (pci-hyperv.c).

Signed-off-by: Michael Kelley 
---
 Documentation/virt/hyperv/index.rst |   1 +
 Documentation/virt/hyperv/vpci.rst  | 316 
 2 files changed, 317 insertions(+)
 create mode 100644 Documentation/virt/hyperv/vpci.rst

diff --git a/Documentation/virt/hyperv/index.rst 
b/Documentation/virt/hyperv/index.rst
index 4a7a1b738bbe..de447e11b4a5 100644
--- a/Documentation/virt/hyperv/index.rst
+++ b/Documentation/virt/hyperv/index.rst
@@ -10,3 +10,4 @@ Hyper-V Enlightenments
overview
vmbus
clocks
+   vpci
diff --git a/Documentation/virt/hyperv/vpci.rst 
b/Documentation/virt/hyperv/vpci.rst
new file mode 100644
index ..dbca50f31923
--- /dev/null
+++ b/Documentation/virt/hyperv/vpci.rst
@@ -0,0 +1,316 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+PCI pass-thru devices
+=
+In a Hyper-V guest VM, PCI pass-thru devices (also called
+virtual PCI devices, or vPCI devices) are physical PCI devices
+that are mapped directly into the VM's physical address space.
+Guest device drivers can interact directly with the hardware
+without intermediation by the host hypervisor.  This approach
+provides higher bandwidth access to the device with lower
+latency, compared with devices that are virtualized by the
+hypervisor.  The device should appear to the guest just as it
+would when running on bare metal, so no changes are required
+to the Linux device drivers for the device.
+
+Hyper-V terminology for vPCI devices is "Discrete Device
+Assignment" (DDA).  Public documentation for Hyper-V DDA is
+available here: `DDA`_
+
+.. _DDA: 
https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-for-deploying-devices-using-discrete-device-assignment
+
+DDA is typically used for storage controllers, such as NVMe,
+and for GPUs.  A similar mechanism for NICs is called SR-IOV
+and produces the same benefits by allowing a guest device
+driver to interact directly with the hardware.  See Hyper-V
+public documentation here: `SR-IOV`_
+
+.. _SR-IOV: 
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-single-root-i-o-virtualization--sr-iov-
+
+This discussion of vPCI devices includes DDA and SR-IOV
+devices.
+
+Device Presentation
+---
+Hyper-V provides full PCI functionality for a vPCI device when
+it is operating, so the Linux device driver for the device can
+be used unchanged, provided it uses the correct Linux kernel
+APIs for accessing PCI config space and for other integration
+with Linux.  But the initial detection of the PCI device and
+its integration with the Linux PCI subsystem must use Hyper-V
+specific mechanisms.  Consequently, vPCI devices on Hyper-V
+have a dual identity.  They are initially presented to Linux
+guests as VMBus devices via the standard VMBus "offer"
+mechanism, so they have a VMBus identity and appear under
+/sys/bus/vmbus/devices.  The VMBus vPCI driver in Linux at
+drivers/pci/controller/pci-hyperv.c handles a newly introduced
+vPCI device by fabricating a PCI bus topology and creating all
+the normal PCI device data structures in Linux that would
+exist if the PCI device were discovered via ACPI on a bare-
+metal system.  Once those data structures are set up, the
+device also has a normal PCI identity in Linux, and the normal
+Linux device driver for the vPCI device can function as if it
+were running in Linux on bare-metal.  Because vPCI devices are
+presented dynamically through the VMBus offer mechanism, they
+do not appear in the Linux guest's ACPI tables.  vPCI devices
+may be added to a VM or removed from a VM at any time during
+the life of the VM, and not just during initial boot.
+
+With this approach, the vPCI device is a VMBus device and a
+PCI device at the same time.  In response to the VMBus offer
+message, the hv_pci_probe() function runs and establishes a
+VMBus connection to the vPCI VSP on the Hyper-V host.  That
+connection has a single VMBus channel.  The channel is used to
+exchange messages with the vPCI VSP for the purpose of setting
+up and configuring the vPCI device in Linux.  Once the device
+is fully configured in Linux as a PCI device, the VMBus
+channel is used only if Linux changes the vCPU to be
+interrupted in the guest, or if the vPCI device is removed by
+the VM while the VM is running.  The ongoing operation of the
+device happens directly between the Linux device driver for
+the device and the hardware, with VMBus and the VMBus channel
+playing no role.
+
+PCI Device Setup
+
+PCI device setup follows a sequence that Hyper-V originally
+created for Windows guests, and that can be ill-suited for
+Linux guests due to differences in the overall structure of
+the Linux PCI subsystem compared with Windows.  Nonetheless,
+with a bit of hackery in the Hyper-V virtual PCI d