-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of
Jan Kiszka
Sent: Friday, October 9, 2020 4:24 PM
To: nobuhiro1.iwamatsu@...; cip-dev@...
Subject: Re: [cip-dev] Backporting of security patches for Intel i40e drivers
required?

Hi all,

given the exposure of such a device but also the fact that I can't tell for sure
if/where it's used (not only by us), I would recommend backporting.

Jan

On 09.10.20 02:23, nobuhiro1.iwamatsu@... wrote:

Hi,

I have some comment for this issue.

https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200810/021
006.html

https://lore.kernel.org/stable/20200807205517.1740307-1-jesse.brandebu
rg@.../

There are multiple patches fixed for 4.19, which can be separated by feature.

- i40e: add num_vectors checker in iwarp handler

This issue has been produced by e3219ce6a7754 ("i40e: Add support for

client interface for IWARP driver").

e3219ce6a7754 is not included in 4.4.y and can be ignored.

- i40e: Wrong truncation from u16 to u8
This can be apply in 4.4.y.

- i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

This issue has been produced by e284fc280473b ("i40e: Add and delete

cloud filter").

It is not included in 4.4.y. However, this patch has several different fixes, so

some patches need to be applied.

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -181,7 +181,7 @@ static inline bool i40e_vc_isvalid_vsi_id(struct
i40e_vf *vf, u16 vsi_id)
* check for the valid queue id
**/
static inline bool i40e_vc_isvalid_queue_id(struct i40e_vf *vf, u16 vsi_id,
- u8 qid)
+ u16 qid)
{
struct i40e_pf *pf = vf->pf;
struct i40e_vsi *vsi = i40e_find_vsi_from_id(pf, vsi_id);


- i40e: Memory leak in i40e_config_iwarp_qvlist
This issue has been produced by e3219ce6a7754 ("i40e: Add support for

client interface for IWARP driver").

e3219ce6a7754 is not included in 4.4.y and can be ignored.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@...
[mailto:cip-dev@...] On Behalf Of
masashi.kudo@...
Sent: Thursday, October 8, 2020 6:43 PM
To: cip-dev@...
Cc: jan.kiszka@...
Subject: [cip-dev] Backporting of security patches for Intel i40e drivers

required?

Hi, Jan-san, All,

At the IRC meeting today, we identified the following new CVEs are not in

LTS4.4 yet.

- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for
mainline and 4.19+

These are for i40e driver for Intel.

The kernel team would like to know whether their backporting is needed or

not.

For details of those CVE checking results, please see the following.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requ
ests/75/diffs

Regarding the discussion of the IRC meeting, please see the following.
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.0
0.log.html

Best regards,
--
M. Kudo

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Hi,

I have some comment for this issue.
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200810/021006.html
https://lore.kernel.org/stable/20200807205517.1740307-1-jesse.brandeburg@intel.com/

There are multiple patches fixed for 4.19, which can be separated by feature.

- i40e: add num_vectors checker in iwarp handler

This issue has been produced by e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

- i40e: Wrong truncation from u16 to u8
This can be apply in 4.4.y.

- i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

This issue has been produced by e284fc280473b ("i40e: Add and delete cloud filter").
It is not included in 4.4.y. However, this patch has several different fixes, so some patches need to be applied.

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -181,7 +181,7 @@ static inline bool i40e_vc_isvalid_vsi_id(struct
i40e_vf *vf, u16 vsi_id)
* check for the valid queue id
**/
static inline bool i40e_vc_isvalid_queue_id(struct i40e_vf *vf, u16 vsi_id,
- u8 qid)
+ u16 qid)
{
struct i40e_pf *pf = vf->pf;
struct i40e_vsi *vsi = i40e_find_vsi_from_id(pf, vsi_id);


- i40e: Memory leak in i40e_config_iwarp_qvlist
This issue has been produced by e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of
masashi.kudo@...
Sent: Thursday, October 8, 2020 6:43 PM
To: cip-dev@...
Cc: jan.kiszka@...
Subject: [cip-dev] Backporting of security patches for Intel i40e drivers required?

Hi, Jan-san, All,

At the IRC meeting today, we identified the following new CVEs are not in LTS4.4 yet.

- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for mainline and 4.19+

These are for i40e driver for Intel.

The kernel team would like to know whether their backporting is needed or not.

For details of those CVE checking results, please see the following.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requests/75/diffs

Regarding the discussion of the IRC meeting, please see the following.
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.00.log.html

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of
masashi.kudo@...
Sent: Thursday, October 8, 2020 6:43 PM
To: cip-dev@...
Cc: jan.kiszka@...
Subject: [cip-dev] Backporting of security patches for Intel i40e drivers required?

Hi, Jan-san, All,

At the IRC meeting today, we identified the following new CVEs are not in LTS4.4 yet.

- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for mainline and 4.19+

These are for i40e driver for Intel.

The kernel team would like to know whether their backporting is needed or not.

For details of those CVE checking results, please see the following.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requests/75/diffs

Regarding the discussion of the IRC meeting, please see the following.
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.00.log.html

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of
masashi.kudo@...
Sent: Thursday, October 8, 2020 9:57 AM
To: cip-dev@...
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according
to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=8&hour=9&min=0&sec=0&p1=224&p2=
179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-01-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu

2. Check whether CVE-2020-25284 needs to be backported to 4.4-rt
-> Delete rbd ( Ceph block device ) from 4.4-rt x86 config - iwamatsu
-> Done, so will be closed today.

* Kernel maintenance updates

* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics
can stay. Otherwise, the topic will be taken offline or in the next meeting.

-----Original Message-----
From: iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ)
Sent: Thursday, October 8, 2020 2:32 PM
To: Pavel Machek <pavel@...>
Cc: cip-dev@...; jan.kiszka@...; SZ.Lin@...; ben.hutchings@...;
Chris.Paterson2@...
Subject: RE: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi Pavel,

-----Original Message-----
From: Pavel Machek [mailto:pavel@...]
Sent: Thursday, October 8, 2020 5:11 AM
To: iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <nobuhiro1.iwamatsu@...>
Cc: cip-dev@...; pavel@...; jan.kiszka@...; SZ.Lin@...;
ben.hutchings@...; Chris.Paterson2@...
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi!

FYI:
https://patchwork.ozlabs.org/project/netdev/patch/20200922072931.2148-1-geert+renesas@glider.be/

Yes, and the revert is now queued to 4.19-stable, too.

So.. what do we want to do here?

We can merge 4.19.151 to -cip when it is released, and I can then
release new -cip-rt that works on renesas boards...

Yes, I think so.
Perhaps 4.19.151 will be released this weekend. And this week is the release week of the CIP kernel.

And I think we can use it to release the cip-rt tree.

-----Original Message-----
From: Pavel Machek [mailto:pavel@...]
Sent: Thursday, October 8, 2020 5:11 AM
To: iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <nobuhiro1.iwamatsu@...>
Cc: cip-dev@...; pavel@...; jan.kiszka@...; SZ.Lin@...;
ben.hutchings@...; Chris.Paterson2@...
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi!

FYI:
https://patchwork.ozlabs.org/project/netdev/patch/20200922072931.2148-1-geert+renesas@glider.be/

Yes, and the revert is now queued to 4.19-stable, too.

So.. what do we want to do here?

We can merge 4.19.151 to -cip when it is released, and I can then
release new -cip-rt that works on renesas boards...

Best regards,
Pavel

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of
masashi.kudo@... via lists.cip-project.org
Sent: Thursday, October 8, 2020 9:57 AM
To: cip-dev@...
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical
topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting
from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&mont
h=10&day=8&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=24
1&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-01-09.00.log.htm
l

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Check whether CVE-2020-25284 needs to be backported to 4.4-rt
-> Delete rbd ( Ceph block device ) from 4.4-rt x86 config - iwamatsu
-> Done, so will be closed today.

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes
sense and those involved in the topics can stay. Otherwise, the topic will be taken
offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.

-----Original Message-----
From: Ben Hutchings <ben.hutchings@...>
Sent: Wednesday, October 7, 2020 6:28 AM
To: sangorrin daniel(サンゴリン ダニエル □ＳＷＣ◯ＡＣＴ) <daniel.sangorrin@...>; sz.lin@...; wens@...
Cc: cip-dev@...
Subject: Re: [cip-kernel-sec] reports: add script to convert reports to csv format

On Fri, 2020-09-25 at 14:07 +0900, Daniel Sangorrin wrote:

The text version is probably enough for developers but customers
usually prefer to have a CSV that you can open with a spreadsheet
program and contains additional information. CVEs are sorted in rows
according to their criticality.

[...]

I think this script is trying to do too many different things:

1. Importing data from NVD
2. Importing data from Debian security tracker 3. Parsing an existing report (!) 4. Generating a new report

1. If there's useful information from NVD that belongs in reports, and the license allows us to redistribute it, we should add an import
script that adds that to the issue files (and extend the schema if necessary). We can then use that in any of the reporting scripts.

2. I'm not sure why the script is using Debian's general security tracker. Debian's kernel-sec normally has better information for kernel
issues, and the import_debian.py script already imports that.

3. The output of report_affected.py is intended to be human-readable, and just happens to be relatively easy to parse. If you want to
use its output as input, that should either be done by adding a structured format (e.g. JSON) for the intermediate file, or by sharing
code between the two reporting scripts so there's no need to use an intermediate file.

Other comments:

- The new script needs to be documented in README.md.

- Any files created in the process of importing data should go under the import/ subdirectory.

- Error handling needs improvement, e.g.:

+def download_file(src, file, bar=""):
+ """Re-download file when an error occurred due to network connection problem.
+ """
+ for i in range(3):
+ try:
+ wget.download(src, file, bar)
+ break
+ except:
+ pass

This doesn't check whether there was a network error; it retries in case of *any* error. The except block should specify which
exception types we want to handle.

+ if not os.path.exists(file):
+ print("ERROR: Can't download %s" % src)

Error messages should go to stderr.

+ exit(1)

This should call sys.exit.

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Nobuhiro Iwamatsu
Sent: Tuesday, October 6, 2020 3:49 PM
To: cip-dev@...; pavel@...
Cc: jan.kiszka@...; SZ.Lin@...; ben.hutchings@...; Chris.Paterson2@...
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi,

This issue seems to occur randomly.

# cip+rt kernel
NG: https://lava.ciplatform.org/scheduler/job/57129
https://lava.ciplatform.org/scheduler/job/57842
OK: https://lava.ciplatform.org/scheduler/job/57851
https://lava.ciplatform.org/scheduler/job/57841

# 4.19.148+cip kernel
NG: https://lava.ciplatform.org/scheduler/job/58836
OK: https://lava.ciplatform.org/scheduler/job/58837


We may need to confirm these relationships with CIP kernel patches.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Pavel Machek
Sent: Monday, October 5, 2020 6:39 AM
To: Chris Paterson <Chris.Paterson2@...>
Cc: Pavel Machek <pavel@...>; jan.kiszka@...; cip-dev@...; SZ.Lin@...;
ben.hutchings@...
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi!

New realtime trees should be available at kernel.org.

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-
cip.git/log/?h=linux-4.19.y-cip-rt
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-
cip.git/log/?h=linux-4.19.y-cip-rt-rebase

And their content should be identical.

Thank you for the release.

This patch merges 4.19.148-stable into -cip-rt (because that's what
recent -rt is based on, and older -rt tree is too old). Unfortunately,
that brings regression with ethernet on Renesas Arm64 targets, which
will prevent boot, and fail tests etc.

Kernel that should work ok on Renesas Arm64 machines can be obtained
by reverting fb3a780e7a76cf8efb055f8322ec039923cee41f "ravb: Fixed to
be able to unload modules" on top of -cip-rt release.

So we're releasing a Kernel that we know doesn't boot on one of CIP's reference platforms?
Or did you already revert the above patch as part of your release?

Yes, I did that, as the changelog explains. Sorry.

I had to select from few bad options: 4.19.147-rt release is not
available and previous release is too old. So -cip-rt is based on
4.19.148-rt, and it brings in the bad commit.

I thought about reverting it for release, but all I'd get would be
rejects, as it really needs to be solved in -cip, not -cip-rt.

Proper solution is likely updating 4.19-cip to 4.19.148, first. Then
figuring out what is the clean way to solve the problem, and then
creating new -rt release. But that will likely take more than few
days, and it will end up with different release number.

I can create new -cip-rt release when that is done.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Pavel Machek
Sent: Monday, October 5, 2020 6:39 AM
To: Chris Paterson <Chris.Paterson2@...>
Cc: Pavel Machek <pavel@...>; jan.kiszka@...; cip-dev@...; SZ.Lin@...;
ben.hutchings@...
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi!

New realtime trees should be available at kernel.org.

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-
cip.git/log/?h=linux-4.19.y-cip-rt
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-
cip.git/log/?h=linux-4.19.y-cip-rt-rebase

And their content should be identical.

Thank you for the release.

This patch merges 4.19.148-stable into -cip-rt (because that's what
recent -rt is based on, and older -rt tree is too old). Unfortunately,
that brings regression with ethernet on Renesas Arm64 targets, which
will prevent boot, and fail tests etc.

Kernel that should work ok on Renesas Arm64 machines can be obtained
by reverting fb3a780e7a76cf8efb055f8322ec039923cee41f "ravb: Fixed to
be able to unload modules" on top of -cip-rt release.

So we're releasing a Kernel that we know doesn't boot on one of CIP's reference platforms?
Or did you already revert the above patch as part of your release?

Yes, I did that, as the changelog explains. Sorry.

I had to select from few bad options: 4.19.147-rt release is not
available and previous release is too old. So -cip-rt is based on
4.19.148-rt, and it brings in the bad commit.

I thought about reverting it for release, but all I'd get would be
rejects, as it really needs to be solved in -cip, not -cip-rt.

Proper solution is likely updating 4.19-cip to 4.19.148, first. Then
figuring out what is the clean way to solve the problem, and then
creating new -rt release. But that will likely take more than few
days, and it will end up with different release number.

I can create new -cip-rt release when that is done.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany