1. cip-dev@lists.cip-project.org
  2. Messages
   Date   
Backporting of security patches for Intel i40e drivers required?

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

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
Re: CIP IRC weekly meeting today

Chen-Yu Tsai (Moxa) <wens@...>
 

On Thu, Oct 8, 2020 at 8:57 AM masashi.kudo@...
<masashi.kudo@...> wrote:

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
I might not make it. Here's this week's update:

Five new CVEs:
- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for
mainline and 4.19+
- This is enabled in Siemens x86 configs for both 4.4 and 4.19
and we should probably backport them.
- CVE-2020-25643 [hdlc_ppp] - Fixed in all current stable kernels
- CVE-2020-26541 [UEFI secure boot] - Fix posted but hasn't landed

I also reviewed some patches from Daniel for cip-kernel-sec on the mailing list.

ChenYu



* 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.
Re: [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs

Chen-Yu Tsai (Moxa) <wens@...>
 

On Fri, Sep 25, 2020 at 12:01 PM Daniel Sangorrin
<daniel.sangorrin@...> wrote:

From: nguyen van hieu <hieu2.nguyenvan@...>

I noticed that some issues have the description field empty
when using the --show-description option.

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@...>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
Looks like all the new descriptions were copied from MITRE.

Reviewed-by: Chen-Yu Tsai (Moxa) <wens@...>
Re: [cip-kernel-sec 2/3] report_affected: Delete extra blank lines between CVEs

Chen-Yu Tsai (Moxa) <wens@...>
 

On Thu, Oct 8, 2020 at 3:59 PM Chen-Yu Tsai <wens@...> wrote:

On Fri, Sep 25, 2020 at 12:00 PM Daniel Sangorrin
<daniel.sangorrin@...> wrote:

From: nguyen van hieu <hieu2.nguyenvan@...>

When using the --show-description option CVEs had blank
lines between them. Remove them to make it more compact.

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@...>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
Reviewed-by: Chen-Yu Tsai (Moxa) <wens@...>

Though these occurrences seem to be very rare.
Jumped the gun. This patch is no longer needed if you use join()
to combine the lines.
Re: [cip-kernel-sec 2/3] report_affected: Delete extra blank lines between CVEs

Chen-Yu Tsai (Moxa) <wens@...>
 

On Fri, Sep 25, 2020 at 12:00 PM Daniel Sangorrin
<daniel.sangorrin@...> wrote:

From: nguyen van hieu <hieu2.nguyenvan@...>

When using the --show-description option CVEs had blank
lines between them. Remove them to make it more compact.

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@...>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
Reviewed-by: Chen-Yu Tsai (Moxa) <wens@...>

Though these occurrences seem to be very rare.

---
scripts/report_affected.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/report_affected.py b/scripts/report_affected.py
index a181d97..9894602 100755
--- a/scripts/report_affected.py
+++ b/scripts/report_affected.py
@@ -141,7 +141,7 @@ def main(git_repo, remotes, only_fixed_upstream,
wrap_description = ''
for line in textwrap.wrap(description, 80, break_long_words=False):
wrap_description += line + '\n '
- print(cve_id, '=>',wrap_description)
+ print(cve_id, '=>',wrap_description.strip())
else:
print('%s:' % branch['full_name'], *sorted_cve_ids)

--
2.25.1
Re: [cip-kernel-sec 1/3] report_affected: word-wrap for the 'description'

Chen-Yu Tsai (Moxa) <wens@...>
 

On Fri, Sep 25, 2020 at 12:00 PM Daniel Sangorrin
<daniel.sangorrin@...> wrote:

From: Nguyen Van Hieu <hieu2.nguyenvan@...>

Currently some descriptions are quite long, and it is hard to read.
Add line-breaks so every line is at most 80 characters long.

Signed-off-by: Nguyen Van Hieu <hieu2.nguyenvan@...>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
---
scripts/report_affected.py | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/report_affected.py b/scripts/report_affected.py
index a97b700..a181d97 100755
--- a/scripts/report_affected.py
+++ b/scripts/report_affected.py
@@ -19,6 +19,7 @@ import kernel_sec.branch
import kernel_sec.issue
import kernel_sec.version

+import textwrap

def main(git_repo, remotes, only_fixed_upstream,
include_ignored, show_description, *branch_names):
@@ -136,8 +137,11 @@ def main(git_repo, remotes, only_fixed_upstream,
if show_description:
print('%s:' % branch['full_name'])
for cve_id in sorted_cve_ids:
- print(cve_id, '=>',
- kernel_sec.issue.load(cve_id).get('description', 'None'))
+ description=kernel_sec.issue.load(cve_id).get('description', 'None')
+ wrap_description = ''
+ for line in textwrap.wrap(description, 80, break_long_words=False):
+ wrap_description += line + '\n '
I believe it would be better to include the "CVE => " string in the full text
passed to textwrap. That would make all lines properly wrapped at the given
width.

Also, textwrap can handle indentation for subsequent lines, so you don't have
to handle that yourself. And it might be easier to read if they matched up
with the beginning of the description in the first line.

Last, you could use join() to combine the lines.

So I would rewrite the part as:

text = cve_id + ' => ' +
kernel_sec.issue.load(cve_id).get('description', 'None')
print('\n'.join(textwrap.wrap(text, 80, subsequent_indent=' ' *
(len(cve_id) + 4), break_long_words=False)))


ChenYu
Moxa


+ print(cve_id, '=>',wrap_description)
else:
print('%s:' % branch['full_name'], *sorted_cve_ids)

--
2.25.1
Re: CIP IRC weekly meeting today

Nobuhiro Iwamatsu
 

Hi Kudo-san,

Sorry, I can not participate IRC meeting today.

-----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
No update.

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
I reviewed 4.4.y-rc.

* 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,
Nobuhiro
Re: [ANNOUNCE] v4.19.148-cip35-rt15

Nobuhiro Iwamatsu
 

Hi,

-----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.
Sorry, this may be wrong.
If 151 isn't released this weekend, I'll cherry pick this commit, and release new CIP kernel.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-4.19.y&id=1fa5848fae409511eda2c6ee4f8ad9e42a0cb3c1

And I think we can use it to release the cip-rt tree.
Best regards,
Nobuhiro
Re: [ANNOUNCE] v4.19.148-cip35-rt15

Nobuhiro Iwamatsu
 

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.


Best regards,
Pavel
Best regards,
Nobuhiro
Re: CIP IRC weekly meeting today

Kento Yoshida
 

Hi Kudo-san and all,

I'll be absent today.

And, I'll report here as an alternative to attendance.
Both minor updates were once reported, but since they are protracted, I will summarize again here.

Major updates:
There is no major update this week.

Minor updates:
1. Gap assessment for the development process (IEC 62443-4-1):
The report from the certification body, whether development process for OSS meets to the IEC 62443-4-1 standard, is delayed.
But, perhaps we can get it the end of this week.
And then, we'll plan to share the documents on the development process that reflects the feedback from the report.
2. Gap assessment for security features of security packages we suggested (IEC 62443-4-2):
We started review security features of security packages we suggested to add as CIP core packages.
The completion date is scheduled by the end of December.
After this, we'll continue to proceed our suggestion, now it's pended.

Regards,
Kent

-----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.
CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

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.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.
Re: [ANNOUNCE] v4.19.148-cip35-rt15

Pavel Machek
 

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
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

?
signature.asc

Re: [cip-kernel-sec] reports: add script to convert reports to csv format

Daniel Sangorrin <daniel.sangorrin@...>
 

Hello Ben,

Thanks a lot for your review and sorry for taking your time.
We will have an internal review and take your comments into account to prepare a new proposal.

Kind regards,
Daniel

-----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
Re: [ANNOUNCE] v4.19.148-cip35-rt15

Nobuhiro Iwamatsu
 

Hi,

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

Best regards,
Nobuhiro

-----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
Re: [cip-kernel-sec] reports: add script to convert reports to csv format

Ben Hutchings <ben.hutchings@...>
 

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
Re: [ANNOUNCE] v4.19.148-cip35-rt15

Nobuhiro Iwamatsu
 

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
Re: [ANNOUNCE] v4.19.148-cip35-rt15

Pavel Machek
 

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

?
signature.asc

Re: [ANNOUNCE] v4.19.148-cip35-rt15

Chris Paterson
 

Hello Pavel,

From: Pavel Machek <pavel@...>
Sent: 04 October 2020 10:07

*** gpg4o | The signature of this email could not be verified because the
following public key is missing. Click here to search and import the key
30E7F06A95DBFAF2 ***

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?

Thanks, Chris


Best regards,
                                                                 Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [isar-cip-core] image: export dpkg status file for debsecan

Jan Kiszka <jan.kiszka@...>
 

On 30.09.20 04:08, Daniel Sangorrin wrote:
Although the currently exported manifest probably has
enough information, the tool debsecan and our wrapper
cip-core-sec depend on the dpkg status format.

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
---
recipes-core/images/cip-core-image-security.bb | 8 ++++++++
recipes-core/images/cip-core-image.bb | 8 ++++++++
2 files changed, 16 insertions(+)

diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb
index 61ddc39..928774c 100644
--- a/recipes-core/images/cip-core-image-security.bb
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -34,3 +34,11 @@ IMAGE_PREINSTALL += " \
uuid-runtime \
sudo \
"
+
+# for cip-core-sec/debsecan
+ROOTFS_POSTPROCESS_COMMAND += "export_dpkg_status"
+export_dpkg_status() {
+ sudo -E chroot --userspec=$(id -u):$(id -g) '${ROOTFSDIR}' \
+ cat /var/lib/dpkg/status > \
+ ${ROOTFS_MANIFEST_DEPLOY_DIR}/"${PF}".dpkg_status
This is just a copy-out, I don't see the chroot need here.

+}
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 2cecde3..0139819 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -19,3 +19,11 @@ IMAGE_INSTALL += "customizations"
# for swupdate
SWU_DESCRIPTION ??= "swupdate"
include ${SWU_DESCRIPTION}.inc
+
+# for cip-core-sec/debsecan
+ROOTFS_POSTPROCESS_COMMAND += "export_dpkg_status"
+export_dpkg_status() {
+ sudo -E chroot --userspec=$(id -u):$(id -g) '${ROOTFSDIR}' \
+ cat /var/lib/dpkg/status > \
+ ${ROOTFS_MANIFEST_DEPLOY_DIR}/"${PF}".dpkg_status
+}
Please avoid code duplication. We have means like "require some.inc" in
bitbake.

I'm also wondering if this should go to isar upstream directly. debsecan
is a generic Debian tool, nothing CIP-specific per se.

Jan
[ANNOUNCE] v4.19.148-cip35-rt15

Pavel Machek
 

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.

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.

Best regards,
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

?
signature.asc

3201 - 3220 of 8714