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.
)
Example usage:
$ ./scripts/report_affected.py stable/4.19 > security-report.txt
$ ./scripts/report_to_csv.py \
--security-report security-report.txt \
--issues-dir issues

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@...>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
---
scripts/report_to_csv.py | 262 +++++++++++++++++++++++++++++++++++++++
1 file changed, 262 insertions(+)
create mode 100755 scripts/report_to_csv.py

diff --git a/scripts/report_to_csv.py b/scripts/report_to_csv.py
new file mode 100755
index 0000000..a3a984f
--- /dev/null
+++ b/scripts/report_to_csv.py
@@ -0,0 +1,262 @@
+#!/usr/bin/python3
+
+"""
+This script will parse the text output from report_affected.py
+(without options) and generate a CSV file that contains
+additional information extracted from the NVD database (json format)
+
+Example usage:
+ $ ./scripts/report_affected.py stable/4.19 > security-report.txt
+ $ ./scripts/report_to_csv.py \
+ --security-report security-report.txt \
+ --issues-dir issues
+"""
+
+import re
+import wget
+import os
+import sys
+import gzip
+import json
+import csv
+import filecmp
+
+DATABASE_DIR = os.getcwd() + "/nvd-data/"
+
+def parse_cmd():
+ """Parse command options.
+ """
+ import argparse
+
+ CURRENT_DIR = os.getcwd()
+ parser = argparse.ArgumentParser()
+ parser.add_argument('--security-report', dest='security_report', metavar='FILE',
+ default=CURRENT_DIR + '/security-report.txt',
+ help='Output from report_affected.py (without options)')
+ parser.add_argument('--issues-dir', dest='issues_dir', metavar='DIRECTORY',
+ default=CURRENT_DIR + '/issues',
+ help='directory containing the issues in YAML format')
+
+ args = parser.parse_args()
+ return args
+
+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
+
+ if not os.path.exists(file):
+ print("ERROR: Can't download %s" % src)
+ exit(1)
+
+def get_cves_database(years):
+ """Get NVD data (json format) from NVD Data Feeds
+ """
+ DATABASE_URL = "https://nvd.nist.gov/feeds/json/cve/1.1"
+
+ for year in years:
+ if not os.path.exists(DATABASE_DIR + year):
+ os.makedirs(DATABASE_DIR + year)
+
+ json_data = '/nvdcve-1.1-' + year + '.json.gz'
+ meta_data = '/nvdcve-1.1-' + year + '.meta'
+ # Download meta and database files if they don't exist
+ if not os.path.exists(DATABASE_DIR + year + meta_data):
+ download_file(DATABASE_URL + meta_data, DATABASE_DIR + year + meta_data)
+ else:
+ download_file(DATABASE_URL + meta_data, DATABASE_DIR + year + meta_data + '.new')
+ if filecmp.cmp(DATABASE_DIR + year + meta_data, DATABASE_DIR + year + meta_data + '.new'):
+ os.remove(DATABASE_DIR + year + meta_data + '.new')
+
+ # Update meta and database files if they have any modified
+ else:
+ os.rename(DATABASE_DIR + year + meta_data + '.new', DATABASE_DIR + year + meta_data)
+ if os.path.exists(DATABASE_DIR + year + json_data):
+ os.remove(DATABASE_DIR + year + json_data)
+
+ if not os.path.exists(DATABASE_DIR + year + json_data):
+ download_file(DATABASE_URL + json_data, DATABASE_DIR + year + json_data)
+
+def get_severity(cve_id, cve_items):
+ """Parse NVD database to get the `severity` of each CVE
+ """
+ severity = ''
+ for cve_item in cve_items['CVE_Items']:
+ if cve_id == cve_item['cve']['CVE_data_meta']['ID']:
+ if 'baseMetricV3' in cve_item['impact']:
+ severity = cve_item['impact']['baseMetricV3']['cvssV3']['baseSeverity']
+ elif 'baseMetricV2' in cve_item['impact']:
+ severity = cve_item['impact']['baseMetricV2']['severity']
+ break
+ if not severity:
+ severity = "N/A"
+ return severity
+
+def get_description(cve_id, cve_items):
+ """Parse NVD database to get the `description` of each CVE
+ """
+ DEBIAN_TRACKER = "https://security-tracker.debian.org/tracker/"
+ description = ''
+ for cve_item in cve_items['CVE_Items']:
+ if cve_id == cve_item['cve']['CVE_data_meta']['ID']:
+ description = cve_item['cve']['description']['description_data'][0]['value']
+ break
+
+ # Get CVE's description from debian tracker if that CVE is RESERVED in NVD
+ if not description:
+ if os.path.exists(cve_id):
+ os.remove(cve_id)
+
+ download_file(DEBIAN_TRACKER + cve_id, cve_id)
+ try:
+ file = open(cve_id,'r')
+ except:
+ print("ERROR: Can't open CVE tracker file: %s" % cve_id)
+ exit(1)
+ content = file.read()
+ try:
+ description = re.search('Description.*?<td>(.*?)</td>',content).group(1)
+ except:
+ description = "N/A"
+ file.close()
+ os.remove(cve_id)
+ return description
+
+def parse_kernel_log(security_report):
+ """Parsing the security report text file to get list CVEs of each branch|tag
+ """
+ if not os.path.exists(security_report):
+ print("ERROR: the security report text file doesn't exist")
+ exit(1)
+ if os.stat(security_report).st_size == 0:
+ print("LOG: the security report text file is empty")
+ exit(1)
+
+ CVE_IDS = {}
+ with open(security_report, 'r') as file:
+ for line in file.read().splitlines():
+ if not line:
+ continue
+ try:
+ branch = line.split(':')[-2].replace("/", "_")
+ cve_list = line.split(':')[-1]
+
+ cves_by_year = {}
+ for cve in cve_list.split():
+ year = cve.split('-')[1]
+ if year not in cves_by_year.keys():
+ cves_by_year[year] = []
+ cves_by_year[year].append(cve)
+
+ if not branch or not cves_by_year:
+ print("LOG: Don't have any CVEs in branch|tag: '%s'" % branch)
+ break
+ if branch in CVE_IDS.keys():
+ print("LOG: The branch|tag '%s' is duplicated in the security report text file" % branch)
+
+ CVE_IDS[branch] = cves_by_year
+ except:
+ print("ERROR: The format of the security report text file is incorrect")
+ exit(1)
+ return CVE_IDS
+
+def get_cve_info(issues_dir, cves_by_year):
+ """Get the list of CVE-ids from the output of report_affected.py,
+ and parse the information from the CVE*.yml issues.
+ """
+ import yaml
+ import subprocess
+
+ CVES = []
+ for year in cves_by_year.keys():
+ json_data = '/nvdcve-1.1-' + year + '.json.gz'
+ # Parse json data file to get the severity/description of CVE
+ try:
+ file = gzip.open(DATABASE_DIR + year + json_data, 'r').read()
+ except:
+ print("ERROR: Can't open json data file: %s" % json_data)
+ exit(1)
+ cve_items = json.loads(file)
+
+ for cve_id in cves_by_year[year]:
+ if not os.path.exists(issues_dir + "/" + cve_id + '.yml'):
+ print("ERROR: Issues directory or %s.yml doesn't exist" % cve_id)
+ exit(1)
+
+ with open(issues_dir + "/" + cve_id + '.yml', encoding='utf-8') as f:
+ description = ''
+ references = ''
+ comments = ''
+ introduced_by = ''
+ fixed_by = ''
+
+ cve_info = yaml.load(f, Loader=yaml.Loader)
+ if "description" in cve_info:
+ description = cve_info["description"]
+ # get the description in NVD database or Debian tracker if it doesn't exist in .yml file
+ if not description or description.isspace():
+ description = get_description(cve_id, cve_items)
+
+ severity = get_severity(cve_id, cve_items)
+
+ if "references" in cve_info:
+ for str in cve_info["references"]:
+ references += str + "\n"
+ else:
+ references = "N/A"
+
+ if "comments" in cve_info:
+ for key in cve_info["comments"]:
+ comments += key + ": " + cve_info["comments"][key] + "\n"
+ else:
+ comments = "N/A"
+
+ if "introduced-by" in cve_info:
+ for key in cve_info["introduced-by"]:
+ introduced_by += key + ": " + " ".join(cve_info["introduced-by"][key]).replace(',', '+') + "\n"
+ else:
+ introduced_by = "N/A"
+ if "fixed-by" in cve_info:
+ for key in cve_info["fixed-by"]:
+ fixed_by += key + ": " + ", ".join(cve_info["fixed-by"][key]) + "\n"
+ else:
+ fixed_by = "N/A"
+
+ CVES.append({'CVE-id': cve_id, 'Description': description,
+ 'Severity': severity, 'References': references,
+ 'Comments': comments, 'Introduced-by': introduced_by,
+ 'Fixed-by': fixed_by})
+ return CVES
+
+def generate_csv_report(CVES, file_name):
+ with open(file_name, mode='w') as csv_file:
+ # writing the header fields
+ headers = CVES[0].keys()
+ csvwriter = csv.DictWriter(csv_file, fieldnames=headers)
+ csvwriter.writeheader()
+
+ weight_severity = {"CRITICAL": 0, "HIGH" : 1, "MEDIUM" : 2, "LOW" : 3, "N/A": 4, "": 5}
+ sorted_CVES = sorted(CVES, key=lambda x: weight_severity[x['Severity'].upper()])
+ # Writing the contents
+ for data in sorted_CVES:
+ csvwriter.writerow(data)
+
+if __name__ == "__main__":
+ args = parse_cmd()
+
+ CVE_IDS = parse_kernel_log(args.security_report)
+
+ # Getting CVEs database from NVD
+ YEARS = {}
+ for branch in CVE_IDS.keys():
+ YEARS |= CVE_IDS[branch].keys()
+ get_cves_database(YEARS)
+
+ for branch, cves_by_year in CVE_IDS.items():
+ CVES = get_cve_info(args.issues_dir, cves_by_year)
+ generate_csv_report(CVES, "security-report-%s.csv" % branch)
--
2.25.1

This patch adds a script that converts the raw text reports
that you get from report_affected.py into CSV files with
additional information obtained from the NVD database.

[1/1] reports: add script to convert reports to csv format

Thanks,
Daniel

Sorry Ben, it seems that I misspelled your e-mail address.
I sent 3 patches for cip-kernel-sec to cip-dev.

Kind regards,
Daniel

________________________________________
From: cip-dev@... <cip-dev@...> on behalf of Daniel Sangorrin <daniel.sangorrin@...>
Sent: Friday, September 25, 2020 12:59 PM
To: sz.lin@...; ben.hutchings@...; wens@...
Cc: cip-dev@...
Subject: [cip-dev] improve show-description results

I had this in the backlog for a long time. These
patches, improve the way CVEs' descriptions are displayed
when calling scripts/report_affected.py with the option
--show-description` enabled.

[1/3] report_affected: word-wrap for the 'description'
[2/3] report_affected: Delete extra blank lines
[3/3] issues: fill in the description field of

Thanks,
Daniel

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@...>
---
issues/CVE-2016-6213.yml | 5 ++++-
issues/CVE-2017-1000364.yml | 5 ++++-
issues/CVE-2017-1000365.yml | 6 +++++-
issues/CVE-2017-1000379.yml | 5 ++++-
issues/CVE-2017-16538.yml | 5 ++++-
issues/CVE-2019-15214.yml | 6 +++++-
issues/CVE-2019-20794.yml | 6 +++++-
issues/CVE-2020-11725.yml | 8 +++++++-
8 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/issues/CVE-2016-6213.yml b/issues/CVE-2016-6213.yml
index 31762df..58bf472 100644
--- a/issues/CVE-2016-6213.yml
+++ b/issues/CVE-2016-6213.yml
@@ -1,4 +1,7 @@
-description: ''
+description: |-
+ fs/namespace.c in the Linux kernel before 4.9 does not restrict how many mounts may exist in a mount namespace,
+ which allows local users to cause a denial of service (memory consumption and deadlock) via MS_BIND mount system calls,
+ as demonstrated by a loop that triggers exponential growth in the number of mounts.
references:
- http://www.openwall.com/lists/oss-security/2016/07/13/6
- https://lkml.org/lkml/2016/8/28/269
diff --git a/issues/CVE-2017-1000364.yml b/issues/CVE-2017-1000364.yml
index 8841754..c566c5b 100644
--- a/issues/CVE-2017-1000364.yml
+++ b/issues/CVE-2017-1000364.yml
@@ -1,4 +1,7 @@
-description: ''
+description: |-
+ An issue was discovered in the size of the stack guard page on Linux, specifically a 4k stack guard
+ page is not sufficiently large and can be "jumped" over (the stack guard page is bypassed),
+ this affects Linux Kernel versions 4.11.5 and earlier (the stackguard page was introduced in 2010).
references:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000364
- http://www.ubuntu.com/usn/usn-3324-1
diff --git a/issues/CVE-2017-1000365.yml b/issues/CVE-2017-1000365.yml
index 6cbae0b..f87ca53 100644
--- a/issues/CVE-2017-1000365.yml
+++ b/issues/CVE-2017-1000365.yml
@@ -1,4 +1,8 @@
-description: ''
+description: |-
+ The Linux Kernel imposes a size restriction on the arguments and environmental strings passed through
+ RLIMIT_STACK/RLIM_INFINITY (1/4 of the size), but does not take the argument and environment pointers
+ into account, which allows attackers to bypass this limitation. This affects Linux Kernel versions 4.11.5 and earlier.
+ It appears that this feature was introduced in the Linux Kernel version 2.6.23.
references:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000365
- https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
diff --git a/issues/CVE-2017-1000379.yml b/issues/CVE-2017-1000379.yml
index 93258d8..2ae11b1 100644
--- a/issues/CVE-2017-1000379.yml
+++ b/issues/CVE-2017-1000379.yml
@@ -1,4 +1,7 @@
-description: ''
+description: |-
+ The Linux Kernel running on AMD64 systems will sometimes map the contents of PIE executable,
+ the heap or ld.so to where the stack is mapped allowing attackers to more easily manipulate the stack.
+ Linux Kernel version 4.11.5 is affected.
references:
- https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000379
diff --git a/issues/CVE-2017-16538.yml b/issues/CVE-2017-16538.yml
index 793db3f..c466041 100644
--- a/issues/CVE-2017-16538.yml
+++ b/issues/CVE-2017-16538.yml
@@ -1,4 +1,7 @@
-description: ''
+description: |-
+ drivers/media/usb/dvb-usb-v2/lmedm04.c in the Linux kernel through 4.13.11 allows local users to cause a denial of service
+ (general protection fault and system crash) or possibly have unspecified other impact via a crafted USB device,
+ related to a missing warm-start check and incorrect attach timing (dm04_lme2510_frontend_attach versus dm04_lme2510_tuner).
references:
- https://patchwork.linuxtv.org/patch/44566/
- https://patchwork.linuxtv.org/patch/44567/
diff --git a/issues/CVE-2019-15214.yml b/issues/CVE-2019-15214.yml
index c92091b..cb6006d 100644
--- a/issues/CVE-2019-15214.yml
+++ b/issues/CVE-2019-15214.yml
@@ -1,4 +1,8 @@
-description: ''
+description: |-
+ An issue was discovered in the Linux kernel before 5.0.10.
+ There is a use-after-free in the sound subsystem because
+ card disconnection causes certain data structures to be deleted too early.
+ This is related to sound/core/init.c and sound/core/info.c.
references:
- https://syzkaller.appspot.com/bug?id=75903e0021cef79bc434d068b5169b599b2a46a9
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15214
diff --git a/issues/CVE-2019-20794.yml b/issues/CVE-2019-20794.yml
index 43e3ccf..8f30e12 100644
--- a/issues/CVE-2019-20794.yml
+++ b/issues/CVE-2019-20794.yml
@@ -1,4 +1,8 @@
-description: ''
+description: |-
+ An issue was discovered in the Linux kernel 4.18 through 5.6.11 when unprivileged user namespaces are allowed.
+ A user can create their own PID namespace, and mount a FUSE filesystem. Upon interaction with this FUSE filesystem,
+ if the userspace component is terminated via a kill of the PID namespace's pid 1, it will result in a hung task,
+ and resources being permanently locked up until system reboot. This can result in resource exhaustion.
references:
- https://github.com/sargun/fuse-example
- https://sourceforge.net/p/fuse/mailman/message/36598753/
diff --git a/issues/CVE-2020-11725.yml b/issues/CVE-2020-11725.yml
index ca2b80d..3cae05d 100644
--- a/issues/CVE-2020-11725.yml
+++ b/issues/CVE-2020-11725.yml
@@ -1,4 +1,10 @@
-description: ''
+description: |-
+ ** DISPUTED ** snd_ctl_elem_add in sound/core/control.c in the Linux kernel through 5.6.3 has a count=info->owner line,
+ which later affects a private_size*count multiplication for unspecified "interesting side effects."
+ NOTE: kernel engineers dispute this finding, because it could be relevant only if new callers were added
+ that were unfamiliar with the misuse of the info->owner field to represent data unrelated to the "owner" concept.
+ The existing callers, SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE,
+ have been designed to misuse the info->owner field in a safe way.
references:
- https://twitter.com/yabbadabbadrew/status/1248632267028582400
- https://lore.kernel.org/alsa-devel/s5h4ktmlfpx.wl-tiwai@suse.de/
--
2.25.1

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 '
+ print(cve_id, '=>',wrap_description)
else:
print('%s:' % branch['full_name'], *sorted_cve_ids)

--
2.25.1

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@...>
---
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

I had this in the backlog for a long time. These
patches, improve the way CVEs' descriptions are displayed
when calling scripts/report_affected.py with the option
--show-description` enabled.

[1/3] report_affected: word-wrap for the 'description'
[2/3] report_affected: Delete extra blank lines
[3/3] issues: fill in the description field of

Thanks,
Daniel

Hi Pavel,

2020年9月24日(木) 19:17 Pavel Machek <pavel@...>:

Hi!

Backport to 4.4 was very easy (there was single dev_err that prevented
patch for applying), and backported patch tests okay:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/193933346

Thanks for your work.
It looks like there is no issue.

Best regards,
Pavel

Best regards,
Nobuhiro

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

--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6

Hi!

Backport to 4.4 was very easy (there was single dev_err that prevented
patch for applying), and backported patch tests okay:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/193933346

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

Hi Kudo-san,

Sorry, I will be absent IRC meeting today.
SW Updates WG don't have any updates this week.

Thanks,
Suzuki

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=9&day=24&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/09/cip.2020-09-17-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 - masashi910

* 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.

On Fri, Sep 18, 2020 at 10:23 AM, Venkata Pyla wrote:
Hi Daniel-san,

I have created the merge request for all the security layer changes including your suggestions.
Kindly review and letme know if you have any more suggestions.

Thanks
venkata.

Hi, Jan-san,

Thanks for your quick response!

Is that the only config in our repo carrying rbd/ceph? The we should likely drop
that, to be clear also in the future.

When we discussed at the IRC, the config carrying rbd/ceph is only 4.4-rt x86.

So, I understood that the backporting is not required.

Best regards,
--
M. Kudo

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: Saturday, September 19, 2020 2:36 AM
To: 工藤　雅司（CTJ　OSS事業推進室） <masashi.kudo@...>;
cip-dev@...
Subject: Re: Is CVE-2020-25284 backporting needed for 4.4-rt x86?

On 18.09.20 15:58, masashi.kudo@... wrote:

Hi, Jan-san, Siemens team,

There was some query to Siemens about the need of CVE-2020-25284

backporting.

- CVE-2020-25284 is in rbd ( Ceph block device ).
- it is only fixed for v4.19 and later stable kernels
- Siemens has this built as a module in their 4.4-rt x86 config, but
not their 4.19 one

So the question from the Kernel Team is whether Siemens needs its backporting

to 4.4-rt or not.

Not to my best knowledge. This is very likely an accidental choice.

Is that the only config in our repo carrying rbd/ceph? The we should likely drop
that, to be clear also in the future.

Jan

Please take a look about the discussion at the IRC meeting yesterday.

https://irclogs.baserock.org/meetings/cip/2020/09/cip.2020-09-17-09.00
.log.html

Best regards,
--
M. Kudo

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence
Center Embedded Linux

On 18.09.20 15:58, masashi.kudo@... wrote:

Hi, Jan-san, Siemens team,
There was some query to Siemens about the need of CVE-2020-25284 backporting.
- CVE-2020-25284 is in rbd ( Ceph block device ).
- it is only fixed for v4.19 and later stable kernels
- Siemens has this built as a module in their 4.4-rt x86 config, but not their 4.19 one
So the question from the Kernel Team is whether Siemens needs its backporting to 4.4-rt or not.

Not to my best knowledge. This is very likely an accidental choice.

Is that the only config in our repo carrying rbd/ceph? The we should likely drop that, to be clear also in the future.

Jan

Please take a look about the discussion at the IRC meeting yesterday.
https://irclogs.baserock.org/meetings/cip/2020/09/cip.2020-09-17-09.00.log.html
Best regards,
--
M. Kudo

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Hi, Jan-san, Siemens team,

There was some query to Siemens about the need of CVE-2020-25284 backporting.

- CVE-2020-25284 is in rbd ( Ceph block device ).
- it is only fixed for v4.19 and later stable kernels
- Siemens has this built as a module in their 4.4-rt x86 config, but not their 4.19 one

So the question from the Kernel Team is whether Siemens needs its backporting to 4.4-rt or not.

Please take a look about the discussion at the IRC meeting yesterday.

https://irclogs.baserock.org/meetings/cip/2020/09/cip.2020-09-17-09.00.log.html

Best regards,
--
M. Kudo

On 18.09.20 10:04, Q. Gylstorff wrote:

From: Quirin Gylstorff <quirin.gylstorff@...>
BB_BASEHASH only includes the task itself and its metadata.
Dependencies are not taken into account when this hash is
generated which means updating a package will not generate a new
UUID.
BB_TASKHASH takes the changes into account.
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
classes/image_uuid.bbclass | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/classes/image_uuid.bbclass b/classes/image_uuid.bbclass
index d5337b8..873abc5 100644
--- a/classes/image_uuid.bbclass
+++ b/classes/image_uuid.bbclass
@@ -9,23 +9,23 @@
# SPDX-License-Identifier: MIT
#
-def generate_image_uuid(d):
- import uuid
+IMAGE_UUID ?= "random"

Why not using an undefined or empty IMAGE_UUID as "generate me one" indication?

- base_hash = d.getVar("BB_BASEHASH_task-do_rootfs_install", True)
- if base_hash is None:
- return None
- return str(uuid.UUID(base_hash[:32], version=4))
-
-IMAGE_UUID ?= "${@generate_image_uuid(d)}"
+IMAGE_UUID_NAMESPACE = "6090f47e-b068-475c-b125-7be7c24cdd4e"

Is that namespace random, or does that have specific meaning?

do_generate_image_uuid[vardeps] += "IMAGE_UUID"
do_generate_image_uuid[depends] = "buildchroot-target:do_build"
+IMAGER_INSTALL += "uuid-runtime"

Please separate variable for job definitions be a blank line. Also the job specifications above should be visually separated from the code below that way. IOW:

IMAGER_INSTALL += "uuid-runtime"

do_generate_image_uuid[vardeps] += "IMAGE_UUID"
do_generate_image_uuid[depends] = "buildchroot-target:do_build"

do_generate_image_uuid() {

do_generate_image_uuid() {
+ image_do_mounts
+ if [ "${IMAGE_UUID}" != "random" ]; then
+ IMAGE_UUID_FINAL="${IMAGE_UUID}"
+ else
+ IMAGE_UUID_FINAL="$(sudo -E chroot ${BUILDCHROOT_DIR} uuidgen -s -n "${IMAGE_UUID_NAMESPACE}" -N "${BB_TASKHASH}")"

Why do we need to switch to uuidgen from the buildchroot, rather than using python's uuid?

And what ensures that uuidgen is available there?

+ fi
sudo sed -i '/^IMAGE_UUID=.*/d' '${IMAGE_ROOTFS}/etc/os-release'
- echo "IMAGE_UUID=\"${IMAGE_UUID}\"" | \
+ echo "IMAGE_UUID=\"${IMAGE_UUID_FINAL}\"" | \
sudo tee -a '${IMAGE_ROOTFS}/etc/os-release'
- image_do_mounts
# update initramfs to add uuid
sudo chroot '${IMAGE_ROOTFS}' update-initramfs -u

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

From: Quirin Gylstorff <quirin.gylstorff@...>

BB_BASEHASH only includes the task itself and its metadata.
Dependencies are not taken into account when this hash is
generated which means updating a package will not generate a new
UUID.

BB_TASKHASH takes the changes into account.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
classes/image_uuid.bbclass | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/classes/image_uuid.bbclass b/classes/image_uuid.bbclass
index d5337b8..873abc5 100644
--- a/classes/image_uuid.bbclass
+++ b/classes/image_uuid.bbclass
@@ -9,23 +9,23 @@
# SPDX-License-Identifier: MIT
#

-def generate_image_uuid(d):
- import uuid
+IMAGE_UUID ?= "random"

- base_hash = d.getVar("BB_BASEHASH_task-do_rootfs_install", True)
- if base_hash is None:
- return None
- return str(uuid.UUID(base_hash[:32], version=4))
-
-IMAGE_UUID ?= "${@generate_image_uuid(d)}"
+IMAGE_UUID_NAMESPACE = "6090f47e-b068-475c-b125-7be7c24cdd4e"

do_generate_image_uuid[vardeps] += "IMAGE_UUID"
do_generate_image_uuid[depends] = "buildchroot-target:do_build"
+IMAGER_INSTALL += "uuid-runtime"
do_generate_image_uuid() {
+ image_do_mounts
+ if [ "${IMAGE_UUID}" != "random" ]; then
+ IMAGE_UUID_FINAL="${IMAGE_UUID}"
+ else
+ IMAGE_UUID_FINAL="$(sudo -E chroot ${BUILDCHROOT_DIR} uuidgen -s -n "${IMAGE_UUID_NAMESPACE}" -N "${BB_TASKHASH}")"
+ fi
sudo sed -i '/^IMAGE_UUID=.*/d' '${IMAGE_ROOTFS}/etc/os-release'
- echo "IMAGE_UUID=\"${IMAGE_UUID}\"" | \
+ echo "IMAGE_UUID=\"${IMAGE_UUID_FINAL}\"" | \
sudo tee -a '${IMAGE_ROOTFS}/etc/os-release'
- image_do_mounts

# update initramfs to add uuid
sudo chroot '${IMAGE_ROOTFS}' update-initramfs -u
--
2.20.1

HI Daniel-san,

Thank you for your feedback.

sorry for spell checks issues in the commits, I will correct it and send another merge request.
Also I will apply other security configuration suggestions.

Thanks
Venkata.

Hi Kudo-san,

Sorry, I will be absent today's IRC meeting because I've got a plan already today.
SW Updates WG don't have any updates this week.

Thanks,
Suzuki

Thanks, it looks good.
Perhaps you can write in the commit id what is the effect in size compared to not using static compilation.
Please send me a merge request