All of lore.kernel.org
 help / color / mirror / Atom feed
* [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel
@ 2026-09-21  5:29 Jan Kiszka
  2026-10-20  4:27 ` Jan Kiszka
  2026-11-11 20:44 ` Pavel Machek
  0 siblings, 2 replies; 5+ messages in thread
From: Jan Kiszka @ 2026-09-21  5:29 UTC (permalink / raw)
  To: Ulrich Hecht, Pavel Machek, Nobuhiro Iwamatsu, cip-dev

From: Jan Kiszka <jan.kiszka@siemens.com>

This describes at which time which ares of the CIP kernel are handled by
the CIP security team and how to report vulnerabilities to it. It
furthermore state the this projects falls under the LF stewardship
framework.

As the original kernel documentation already contains a reporting guide,
leave a note there which one applies to CIP kernels.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

Changes in v2:
 - leave a note in security-bugs.rst (will need adjustment for older 
   kernels)

 Documentation/process/security-bugs.rst |  6 ++++
 SECURITY.md                             | 37 +++++++++++++++++++++++++
 2 files changed, 43 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 56c560a00b37a..7b38c83d932d6 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -3,6 +3,12 @@
 Security bugs
 =============
 
+.. note::
+
+   If you identified a vulnerability that only affects a CIP kernel, please
+   instead follow the reporting process described in SECURITY.md that can be
+   found in the top-level directory.
+
 Linux kernel developers take security very seriously.  As such, we'd
 like to know when a security bug is found so that it can be fixed and
 disclosed as quickly as possible.  Please report security bugs to the
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000000000..f39a0178338ee
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,37 @@
+# Security Policy
+
+This project is supported under the Linux Foundation CRA stewardship framework,
+as described at https://www.linuxfoundation.org/security. Security
+vulnerabilities should be reported through the mechanisms described below,
+which we will coordinate with our CRA steward. For actively exploited
+vulnerabilities and severe incidents that may require CRA escalation, please
+use the project’s emergency security reporting mechanisms as appropriate.
+
+## Security Context
+
+Open source software can be used in various contexts that may go far beyond
+what it was originally designed and also secured for. Therefore, we describe
+here what the CIP kernel maintenance is particularly covering and what is out
+of scope.
+
+Unlike the upstream kernel, the CIP kernel is maintained with the focus on
+architectures and configurations defined by the CIP project members, see
+https://gitlab.com/cip-project/cip-kernel/cip-kernel-config. Vulnerabilities
+found in code paths not covered this way are considered out of scope.
+Furthermore, vulnerabilities that are affecting the upstream Linux kernel as
+well are in the responsibility of the kernel security team, see
+https://www.kernel.org/doc/html/latest/process/security-bugs.html. In scope for
+the CIP kernel are issues caused by patches not found in the corresponding
+stable kernel (linux-6.12.y-cip vs. linux-6.12.y) or that are related to
+missing backports after the corresponding stable kernel went end-of-life.
+
+## Reporting a Vulnerability
+
+Please DO NOT report any potential security vulnerability via a public channel
+(mailing list, gitlab issue etc.). Instead, contact the CIP security team via
+security@cip-project.org via email. Please provide a detailed description of
+the issue, the steps to reproduce it, the affected versions and, if already
+available, a proposal for a fix. You should receive a response within 5 working
+days. If the issue is confirmed as a vulnerability by us, we will request a
+CVE, publish the fix and give credits for your report if desired. This project
+follows a 90 day disclosure timeline.
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel
  2026-09-21  5:29 [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel Jan Kiszka
@ 2026-10-20  4:27 ` Jan Kiszka
  2026-10-22  5:57   ` nobuhiro.iwamatsu.x90
  2026-11-11 20:44 ` Pavel Machek
  1 sibling, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2026-10-20  4:27 UTC (permalink / raw)
  To: Ulrich Hecht, Pavel Machek, Nobuhiro Iwamatsu, cip-dev

On 21.09.26 07:29, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This describes at which time which ares of the CIP kernel are handled by
> the CIP security team and how to report vulnerabilities to it. It
> furthermore state the this projects falls under the LF stewardship
> framework.
> 
> As the original kernel documentation already contains a reporting guide,
> leave a note there which one applies to CIP kernels.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> Changes in v2:
>  - leave a note in security-bugs.rst (will need adjustment for older 
>    kernels)
> 
>  Documentation/process/security-bugs.rst |  6 ++++
>  SECURITY.md                             | 37 +++++++++++++++++++++++++
>  2 files changed, 43 insertions(+)
>  create mode 100644 SECURITY.md
> 
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 56c560a00b37a..7b38c83d932d6 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -3,6 +3,12 @@
>  Security bugs
>  =============
>  
> +.. note::
> +
> +   If you identified a vulnerability that only affects a CIP kernel, please
> +   instead follow the reporting process described in SECURITY.md that can be
> +   found in the top-level directory.
> +
>  Linux kernel developers take security very seriously.  As such, we'd
>  like to know when a security bug is found so that it can be fixed and
>  disclosed as quickly as possible.  Please report security bugs to the
> diff --git a/SECURITY.md b/SECURITY.md
> new file mode 100644
> index 0000000000000..f39a0178338ee
> --- /dev/null
> +++ b/SECURITY.md
> @@ -0,0 +1,37 @@
> +# Security Policy
> +
> +This project is supported under the Linux Foundation CRA stewardship framework,
> +as described at https://www.linuxfoundation.org/security. Security
> +vulnerabilities should be reported through the mechanisms described below,
> +which we will coordinate with our CRA steward. For actively exploited
> +vulnerabilities and severe incidents that may require CRA escalation, please
> +use the project’s emergency security reporting mechanisms as appropriate.
> +
> +## Security Context
> +
> +Open source software can be used in various contexts that may go far beyond
> +what it was originally designed and also secured for. Therefore, we describe
> +here what the CIP kernel maintenance is particularly covering and what is out
> +of scope.
> +
> +Unlike the upstream kernel, the CIP kernel is maintained with the focus on
> +architectures and configurations defined by the CIP project members, see
> +https://gitlab.com/cip-project/cip-kernel/cip-kernel-config. Vulnerabilities
> +found in code paths not covered this way are considered out of scope.
> +Furthermore, vulnerabilities that are affecting the upstream Linux kernel as
> +well are in the responsibility of the kernel security team, see
> +https://www.kernel.org/doc/html/latest/process/security-bugs.html. In scope for
> +the CIP kernel are issues caused by patches not found in the corresponding
> +stable kernel (linux-6.12.y-cip vs. linux-6.12.y) or that are related to
> +missing backports after the corresponding stable kernel went end-of-life.
> +
> +## Reporting a Vulnerability
> +
> +Please DO NOT report any potential security vulnerability via a public channel
> +(mailing list, gitlab issue etc.). Instead, contact the CIP security team via
> +security@cip-project.org via email. Please provide a detailed description of
> +the issue, the steps to reproduce it, the affected versions and, if already
> +available, a proposal for a fix. You should receive a response within 5 working
> +days. If the issue is confirmed as a vulnerability by us, we will request a
> +CVE, publish the fix and give credits for your report if desired. This project
> +follows a 90 day disclosure timeline.

Gentle reminder that this one is awaiting more feedback. See also [1]
for discussions on v1 of this patch. Some issues pointed out there are
also awaiting adjustment proposals.

Thanks,
Jan

[1]
https://lore.kernel.org/cip-dev/2af79ddb-ba67-4afb-9722-85a36b15602f@siemens.com/

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel
  2026-10-20  4:27 ` Jan Kiszka
@ 2026-10-22  5:57   ` nobuhiro.iwamatsu.x90
  0 siblings, 0 replies; 5+ messages in thread
From: nobuhiro.iwamatsu.x90 @ 2026-10-22  5:57 UTC (permalink / raw)
  To: jan.kiszka, uli, pavel, cip-dev

Hi Jan,

> -----Original Message-----
> From: Jan Kiszka <jan.kiszka@siemens.com>
> Sent: Tuesday, October 20, 2026 1:28 PM
> To: Ulrich Hecht <uli@fpond.eu>; Pavel Machek <pavel@nabladev.com>;
> iwamatsu nobuhiro(岩松 信洋 □DITC○CPT)
> <nobuhiro.iwamatsu.x90@mail.toshiba>; cip-dev
> <cip-dev@lists.cip-project.org>
> Subject: Re: [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel
> 
> On 21.09.26 07:29, Jan Kiszka wrote:
> > From: Jan Kiszka <jan.kiszka@siemens.com>
> >
> > This describes at which time which ares of the CIP kernel are handled
> > by the CIP security team and how to report vulnerabilities to it. It
> > furthermore state the this projects falls under the LF stewardship
> > framework.
> >
> > As the original kernel documentation already contains a reporting
> > guide, leave a note there which one applies to CIP kernels.
> >
> > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > ---
> >
> > Changes in v2:
> >  - leave a note in security-bugs.rst (will need adjustment for older
> >    kernels)
> >
> >  Documentation/process/security-bugs.rst |  6 ++++
> >  SECURITY.md                             | 37
> +++++++++++++++++++++++++
> >  2 files changed, 43 insertions(+)
> >  create mode 100644 SECURITY.md
> >

I have reviewed the content. There were no points to notes.

Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>

Best regards,
  Nobuhiro


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel
  2026-09-21  5:29 [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel Jan Kiszka
  2026-10-20  4:27 ` Jan Kiszka
@ 2026-11-11 20:44 ` Pavel Machek
  2026-11-12  6:50   ` Jan Kiszka
  1 sibling, 1 reply; 5+ messages in thread
From: Pavel Machek @ 2026-11-11 20:44 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Ulrich Hecht, Pavel Machek, Nobuhiro Iwamatsu, cip-dev

[-- Attachment #1: Type: text/plain, Size: 4498 bytes --]

Hi!

> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This describes at which time which ares of the CIP kernel are handled by
> the CIP security team and how to report vulnerabilities to it. It
> furthermore state the this projects falls under the LF stewardship
> framework.
> 
> As the original kernel documentation already contains a reporting guide,
> leave a note there which one applies to CIP kernels.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---

Okay, so poor reporter starts here...

[A--starting palce]
> @@ -3,6 +3,12 @@
>  Security bugs
>  =============
>  
> +.. note::
> +
> +   If you identified a vulnerability that only affects a CIP kernel, please
> +   instead follow the reporting process described in SECURITY.md that can be
> +   found in the top-level directory.
> +

Goes here:

> diff --git a/SECURITY.md b/SECURITY.md
> new file mode 100644
> index 0000000000000..f39a0178338ee
> --- /dev/null
> +++ b/SECURITY.md
> @@ -0,0 +1,37 @@
> +# Security Policy
> +
> +This project is supported under the Linux Foundation CRA stewardship framework,
> +as described at https://www.linuxfoundation.org/security. Security

I would not mind " " before ".", so that link can be clicked (here and elsewhere).

> +vulnerabilities should be reported through the mechanisms described below,
> +which we will coordinate with our CRA steward. For actively exploited
> +vulnerabilities and severe incidents that may require CRA escalation, please
> +use the project’s emergency security reporting mechanisms as
> appropriate.

...and follows link

Sending an email to security@DOMAIN where DOMAIN is the domain of the
project/foundation. For example, Linux kernel security vulnerabilities
should be reported to security@kernel.org as described in the [[Linux
kernel security bugs page]]. In some cases, different email
address(es) other than “security” will be recommended.

Link makered [[]] will send him straight back to [A--starting palce].

Well, problem does not arise if someone goes through whole SECURITY.md first.

> +## Security Context
> +
> +Open source software can be used in various contexts that may go far beyond
> +what it was originally designed and also secured for. Therefore, we describe
> +here what the CIP kernel maintenance is particularly covering and what is out
> +of scope.
> +
> +Unlike the upstream kernel, the CIP kernel is maintained with the focus on
> +architectures and configurations defined by the CIP project members, see
> +https://gitlab.com/cip-project/cip-kernel/cip-kernel-config. Vulnerabilities
> +found in code paths not covered this way are considered out of scope.
> +Furthermore, vulnerabilities that are affecting the upstream Linux kernel as
> +well are in the responsibility of the kernel security team, see
> +https://www.kernel.org/doc/html/latest/process/security-bugs.html. In scope for
> +the CIP kernel are issues caused by patches not found in the corresponding
> +stable kernel (linux-6.12.y-cip vs. linux-6.12.y) or that are related to
> +missing backports after the corresponding stable kernel went end-of-life.
> +
> +## Reporting a Vulnerability
> +
> +Please DO NOT report any potential security vulnerability via a public channel
> +(mailing list, gitlab issue etc.). Instead, contact the CIP security team via
> +security@cip-project.org via email. Please provide a detailed description of
> +the issue, the steps to reproduce it, the affected versions and, if already
> +available, a proposal for a fix. You should receive a response within 5 working
> +days. If the issue is confirmed as a vulnerability by us, we will request a
> +CVE, publish the fix and give credits for your report if desired. This project
> +follows a 90 day disclosure timeline.

AFAICT what we are saying here is that:

bugs in -cip backports in 5.10/6.1/6.12 -> security@cip-project.org
other bugs in -cip for 5.10/6.1/6.12 -> security@kernel.org
all the bugs in 4.4/4.19 -> security@cip-project.org

That means that SPARC bug in 4.4-cip, for example, goes to us.

Good news is, that we have CRA contact at linux foundation that can
help, if we need help. Ok.

I still believe we should publish GPG key for
security@cip-project.org. I know sharing private keys is usually
no-no, but that still seems better than potentially no encryption at
all.

I guess I'm ok with the patch.

Best regards,
								Pavel


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel
  2026-11-11 20:44 ` Pavel Machek
@ 2026-11-12  6:50   ` Jan Kiszka
  0 siblings, 0 replies; 5+ messages in thread
From: Jan Kiszka @ 2026-11-12  6:50 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Ulrich Hecht, Nobuhiro Iwamatsu, cip-dev

On 11.11.26 21:44, Pavel Machek wrote:
> Hi!
> 
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This describes at which time which ares of the CIP kernel are handled by
>> the CIP security team and how to report vulnerabilities to it. It
>> furthermore state the this projects falls under the LF stewardship
>> framework.
>>
>> As the original kernel documentation already contains a reporting guide,
>> leave a note there which one applies to CIP kernels.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
> 
> Okay, so poor reporter starts here...
> 
> [A--starting palce]
>> @@ -3,6 +3,12 @@
>>  Security bugs
>>  =============
>>  
>> +.. note::
>> +
>> +   If you identified a vulnerability that only affects a CIP kernel, please
>> +   instead follow the reporting process described in SECURITY.md that can be
>> +   found in the top-level directory.
>> +
> 
> Goes here:
> 
>> diff --git a/SECURITY.md b/SECURITY.md
>> new file mode 100644
>> index 0000000000000..f39a0178338ee
>> --- /dev/null
>> +++ b/SECURITY.md
>> @@ -0,0 +1,37 @@
>> +# Security Policy
>> +
>> +This project is supported under the Linux Foundation CRA stewardship framework,
>> +as described at https://www.linuxfoundation.org/security. Security
> 
> I would not mind " " before ".", so that link can be clicked (here and elsewhere).
> 

Which programs have problems with that? All the public renderings I
found were fine, so is TB.

>> +vulnerabilities should be reported through the mechanisms described below,
>> +which we will coordinate with our CRA steward. For actively exploited
>> +vulnerabilities and severe incidents that may require CRA escalation, please
>> +use the project’s emergency security reporting mechanisms as
>> appropriate.
> 
> ...and follows link
> 
> Sending an email to security@DOMAIN where DOMAIN is the domain of the
> project/foundation. For example, Linux kernel security vulnerabilities
> should be reported to security@kernel.org as described in the [[Linux
> kernel security bugs page]]. In some cases, different email
> address(es) other than “security” will be recommended.
> 
> Link makered [[]] will send him straight back to [A--starting palce].
> 
> Well, problem does not arise if someone goes through whole SECURITY.md first.

We can reword the last sentence: s/as appropriate/as described below/".

> 
>> +## Security Context
>> +
>> +Open source software can be used in various contexts that may go far beyond
>> +what it was originally designed and also secured for. Therefore, we describe
>> +here what the CIP kernel maintenance is particularly covering and what is out
>> +of scope.
>> +
>> +Unlike the upstream kernel, the CIP kernel is maintained with the focus on
>> +architectures and configurations defined by the CIP project members, see
>> +https://gitlab.com/cip-project/cip-kernel/cip-kernel-config. Vulnerabilities
>> +found in code paths not covered this way are considered out of scope.
>> +Furthermore, vulnerabilities that are affecting the upstream Linux kernel as
>> +well are in the responsibility of the kernel security team, see
>> +https://www.kernel.org/doc/html/latest/process/security-bugs.html. In scope for
>> +the CIP kernel are issues caused by patches not found in the corresponding
>> +stable kernel (linux-6.12.y-cip vs. linux-6.12.y) or that are related to
>> +missing backports after the corresponding stable kernel went end-of-life.
>> +
>> +## Reporting a Vulnerability
>> +
>> +Please DO NOT report any potential security vulnerability via a public channel
>> +(mailing list, gitlab issue etc.). Instead, contact the CIP security team via
>> +security@cip-project.org via email. Please provide a detailed description of
>> +the issue, the steps to reproduce it, the affected versions and, if already
>> +available, a proposal for a fix. You should receive a response within 5 working
>> +days. If the issue is confirmed as a vulnerability by us, we will request a
>> +CVE, publish the fix and give credits for your report if desired. This project
>> +follows a 90 day disclosure timeline.
> 
> AFAICT what we are saying here is that:
> 
> bugs in -cip backports in 5.10/6.1/6.12 -> security@cip-project.org
> other bugs in -cip for 5.10/6.1/6.12 -> security@kernel.org
> all the bugs in 4.4/4.19 -> security@cip-project.org
> 
> That means that SPARC bug in 4.4-cip, for example, goes to us.

That is is excluded by following "Security Context" -> cip-kernel-config
-> no coverage for SPARC.

> 
> Good news is, that we have CRA contact at linux foundation that can
> help, if we need help. Ok.
> 
> I still believe we should publish GPG key for
> security@cip-project.org. I know sharing private keys is usually
> no-no, but that still seems better than potentially no encryption at
> all.

Even the kernel uses no GPG.

> 
> I guess I'm ok with the patch.
> 
> Best regards,
> 								Pavel
> 

Thanks for reviewing.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-11-12  6:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-21  5:29 [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel Jan Kiszka
2026-10-20  4:27 ` Jan Kiszka
2026-10-22  5:57   ` nobuhiro.iwamatsu.x90
2026-11-11 20:44 ` Pavel Machek
2026-11-12  6:50   ` Jan Kiszka

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.