Date   

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

Daniel Sangorrin <daniel.sangorrin@...>
 

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


[cip-kernel-sec] support csv format

Daniel Sangorrin <daniel.sangorrin@...>
 

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


Fw: [cip-dev] improve show-description results

Daniel Sangorrin <daniel.sangorrin@...>
 

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


[cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs

Daniel Sangorrin <daniel.sangorrin@...>
 

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


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

Daniel Sangorrin <daniel.sangorrin@...>
 

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


[cip-kernel-sec 2/3] report_affected: Delete extra blank lines between CVEs

Daniel Sangorrin <daniel.sangorrin@...>
 

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


improve show-description results

Daniel Sangorrin <daniel.sangorrin@...>
 

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


Re: CVE-2020-0427 / pinctrl: devicetree: Avoid taking direct reference to device name string

Nobuhiro Iwamatsu
 

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


CVE-2020-0427 / pinctrl: devicetree: Avoid taking direct reference to device name string

Pavel Machek
 

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


Re: CIP IRC weekly meeting today

Akihiro Suzuki
 

Hi Kudo-san,

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

Thanks,
Suzuki

-----Original Message-----
From: cip-dev@... <cip-dev@...> On
Behalf Of masashi.kudo@...
Sent: Thursday, September 24, 2020 9:59 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=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.


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


Re: [cip-core:deby 2/3] security-configuration: apply security polcies using package bbappend

Venkata Pyla
 

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.


Re: Is CVE-2020-25284 backporting needed for 4.4-rt x86?

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

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


Re: Is CVE-2020-25284 backporting needed for 4.4-rt x86?

Jan Kiszka
 

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


Is CVE-2020-25284 backporting needed for 4.4-rt x86?

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

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


Re: [isar-cip-core][PATCH] classes/image_uuid: Generate new uuid if a new package is added

Jan Kiszka
 

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


[isar-cip-core][PATCH] classes/image_uuid: Generate new uuid if a new package is added

Quirin Gylstorff
 

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


Re: [cip-core:deby 2/3] security-configuration: apply security polcies using package bbappend

Venkata Pyla
 

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.

-----Original Message-----
From: daniel.sangorrin@... <daniel.sangorrin@...>
Sent: 17 September 2020 08:32
To: Venkata Seshagiri Pyla <Venkata.Pyla@...>
Cc: Venkata Seshagiri Pyla <Venkata.Pyla@...>; cip-dev@...
Subject: RE: [cip-core:deby 2/3] security-configuration: apply security polcies using package bbappend

Hi Venkata-san

Please check my inline comments and send me a merge request when you solve them.

-----Original Message-----
From: venkata.pyla@... <venkata.pyla@...>
Sent: Tuesday, September 15, 2020 11:24 PM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT)
<daniel.sangorrin@...>
Cc: pyla venkata(TSIP) <Venkata.Pyla@...>;
cip-dev@...
Subject: [cip-core:deby 2/3] security-configuration: apply security
polcies using package bbappend

From: venkata pyla <venkata.pyla@...>

add package bbappaned files in the security layer that will apply
bbappend

the security configurations like
e.g: Set password strength in pam configurations
Set audit failure actions in audit package configurations
etc.
Signed-off-by: venkata pyla <venkata.pyla@...>
---
.../audit/audit_debian.bbappend | 20 ++++++++++
.../base-files/base-files_debian.bbappend | 3 ++
.../openssh/openssh_debian.bbappend | 19 +++++++++
.../recipes-debian/pam/libpam_debian.bbappend | 39
+++++++++++++++++++
4 files changed, 81 insertions(+)
create mode 100644
meta-cip-security/recipes-debian/audit/audit_debian.bbappend
create mode 100644
meta-cip-security/recipes-debian/base-files/base-files_debian.bbappend
create mode 100644
meta-cip-security/recipes-debian/openssh/openssh_debian.bbappend
create mode 100644
meta-cip-security/recipes-debian/pam/libpam_debian.bbappend
Ideally, you would separate the patches for each file unless they have something in common.

diff --git
a/meta-cip-security/recipes-debian/audit/audit_debian.bbappend
b/meta-cip-security/recipes- debian/audit/audit_debian.bbappend
new file mode 100644
index 0000000..c148f27
--- /dev/null
+++ b/meta-cip-security/recipes-debian/audit/audit_debian.bbappend
@@ -0,0 +1,20 @@
+#
+# CIP Security, tiny profile
+#
+# Copyright (c) Toshiba Corporation, 2020 # #
+SPDX-License-Identifier: MIT #
+
+DESCRIPTION = "CIP Security customizations"
Append "for audit" to the description.

+
+pkg_postinst_audit_append() {
+ # CR2.9: Audit storage capacity
+ # CR2.9 RE-1: Warn when audit record storage capacity threshold reached
+ AUDIT_CONF_FILE="$D${sysconfdir}/audit/auditd.conf"
+ sed -i 's/space_left_action = .*/space_left_action = SYSLOG/' $AUDIT_CONF_FILE
+ sed -i 's/admin_space_left_action = .*/admin_space_left_action =
+SYSLOG/' $AUDIT_CONF_FILE
Don't you need to specify the values for space_left and admin_space_left?
Perhaps these variables should be configurable and have a default value.
Example:
AUDIT_SPACE_LEFT ?= "100"

Then you can change the value in local.conf (or using kas's local_conf_headers)

+
+ # CR2.10: Response to audit processing failures
+ sed -i 's/disk_error_action = .*/disk_error_action = SYSLOG/'
+$AUDIT_CONF_FILE }
Please check if you need other options as well here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-configuring_the_audit_service

diff --git
a/meta-cip-security/recipes-debian/base-files/base-files_debian.bbappe
nd b/meta-cip-security/recipes-debian/base-
files/base-files_debian.bbappend
new file mode 100644
index 0000000..895dc9f
--- /dev/null
+++ b/meta-cip-security/recipes-debian/base-files/base-files_debian.bb
+++ append
@@ -0,0 +1,3 @@
+do_install_append() {
+ echo "${MACHINE}" > ${D}${sysconfdir}/hostname }
Is this related to the security layer?
If not, please separate it into a different patch and explain why it is necessary.

diff --git
a/meta-cip-security/recipes-debian/openssh/openssh_debian.bbappend
b/meta-cip-security/recipes- debian/openssh/openssh_debian.bbappend
new file mode 100644
index 0000000..ddd2bfc
--- /dev/null
+++ b/meta-cip-security/recipes-debian/openssh/openssh_debian.bbappend
@@ -0,0 +1,19 @@
+#
+# CIP Security, tiny profile
+#
+# Copyright (c) Toshiba Corporation, 2020 # #
+SPDX-License-Identifier: MIT #
+
+DESCRIPTION = "CIP Security customizations"
Same as before, append "for openssh". The description for different things should be different.

+
+pkg_postinst_${PN}_append() {
+ # CR2.6: Remote session termination
+ # Terminate remote session after inactive time period
+ SSHD_CONFIG="$D${sysconfdir}/ssh/sshd_config"
+ alive_interval=$(sed -n '/ClientAliveInterval/p' "${SSHD_CONFIG}")
+ alive_countmax=$(sed -n '/ClientAliveCountMax/p' "${SSHD_CONFIG}")
+ sed -i "/${alive_interval}/c ClientAliveInterval 120" "${SSHD_CONFIG}"
+ sed -i "/${alive_countmax}/c ClientAliveCountMax 0" "${SSHD_CONFIG}"
Perhaps make the value for ClientAliveInterval configurable and use 120 as default.

+}
diff --git
a/meta-cip-security/recipes-debian/pam/libpam_debian.bbappend
b/meta-cip-security/recipes- debian/pam/libpam_debian.bbappend new
file mode 100644 index 0000000..c9c1605
--- /dev/null
+++ b/meta-cip-security/recipes-debian/pam/libpam_debian.bbappend
@@ -0,0 +1,39 @@
+#
+# CIP Security, tiny profile
+#
+# Copyright (c) Toshiba Corporation, 2020 # #
+SPDX-License-Identifier: MIT #
+
+DESCRIPTION = "CIP Security customizations"
Same thing: "for libpam"

+
+pkg_postinst_pam-plugin-cracklib_append() {
+ # CR1.7: Strength of password-based authentication
+ # Pam configuration to enforce password strength
+ PAM_PWD_FILE="$D${sysconfdir}/pam.d/common-password"
+ CRACKLIB_CONFIG="password requisite pam_cracklib.so retry=3 minlen=8 maxrepeat=3 ucredit=-1 lcredit=-1 dcredit=-1
ocredit=-1 difok=3 gecoscheck=1 reject_username enforce_for_root"
+ if grep -c "pam_cracklib.so" "${PAM_PWD_FILE}";then
+ sed -i '/pam_cracklib.so/ s/^#*/#/' "${PAM_PWD_FILE}"
+ fi
+ sed -i "0,/^password.*/s/^password.*/${CRACKLIB_CONFIG}\n&/" "${PAM_PWD_FILE}"
+}
Perhaps set minlen configurable.

+
+pkg_postinst_pam-plugin-tally2_append() {
+ # CR1.11: Unsuccessful login attempts
+ # Lock user account after unsuccessful login attempts
+ PAM_AUTH_FILE="$D${sysconfdir}/pam.d/common-auth"
+ pam_tally="auth required pam_tally2.so deny=3 even_deny_root unlock_time=60 root_unlock_time=60"
+ if grep -c "pam_tally2.so" "${PAM_AUTH_FILE}";then
+ sed -i '/pam_tally2/ s/^#*/#/' "${PAM_AUTH_FILE}"
+ fi
+ sed -i "0,/^auth.*/s/^auth.*/${pam_tally}\n&/" "${PAM_AUTH_FILE}"
+}
+
+
+pkg_postinst_libpam_append() {
+ # CR2.7: Concurrent session control
+ # Limit the concurrent login sessions
+ LIMITS_CONFIG="$D${sysconfdir}/security/limits.conf"
+ echo "* hard maxlogins 2" >> ${LIMITS_CONFIG} }
Thanks,
Daniel
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


Re: CIP IRC weekly meeting today

Akihiro Suzuki
 

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

-----Original Message-----
From: cip-dev@... <cip-dev@...> On
Behalf Of masashi.kudo@...
Sent: Thursday, September 17, 2020 10:21 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=9&day=17&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-10-09.00.log.
html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc

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

Since there will be another meeting at 9:30GMT, the meeting will take less than
30 min today.
If some topics may take long, they will be taken offline or in the next meeting.

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


Re: [cip-core:deby 3/3] aide-static: enable aide to build statically

Daniel Sangorrin <daniel.sangorrin@...>
 

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

-----Original Message-----
From: venkata.pyla@... <venkata.pyla@...>
Sent: Tuesday, September 15, 2020 11:24 PM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT) <daniel.sangorrin@...>
Cc: pyla venkata(TSIP) <Venkata.Pyla@...>; cip-dev@...
Subject: [cip-core:deby 3/3] aide-static: enable aide to build statically

From: venkata pyla <venkata.pyla@...>

To build aide statically, its dependencies also compile staticalliy, so all aide dependent library packages enabled static compiling in an
include file and added to the layer configuration.

Signed-off-by: venkata pyla <venkata.pyla@...>
---
meta-cip-security/conf/include/aide-static-libs.inc | 10 ++++++++++
meta-cip-security/conf/layer.conf | 2 ++
2 files changed, 12 insertions(+)
create mode 100644 meta-cip-security/conf/include/aide-static-libs.inc

diff --git a/meta-cip-security/conf/include/aide-static-libs.inc b/meta-cip-security/conf/include/aide-static-libs.inc
new file mode 100644
index 0000000..1dc4374
--- /dev/null
+++ b/meta-cip-security/conf/include/aide-static-libs.inc
@@ -0,0 +1,10 @@
+DISABLE_STATIC ?= " --disable-static"
+
+# aide dependencies to build statically DISABLE_STATIC_pn-aide = " "
+DISABLE_STATIC_pn-libgpg-error = " "
+DISABLE_STATIC_pn-libmhash = " "
+DISABLE_STATIC_pn-attr = " "
+DISABLE_STATIC_pn-acl = " "
+DISABLE_STATIC_pn-libpcre = " "
+EXTRA_OECONF_append_pn-aide = " --without-audit"
diff --git a/meta-cip-security/conf/layer.conf b/meta-cip-security/conf/layer.conf
index b015436..158d75c 100644
--- a/meta-cip-security/conf/layer.conf
+++ b/meta-cip-security/conf/layer.conf
@@ -16,3 +16,5 @@ LAYERVERSION_cip-security = "1"
LAYERDEPENDS_cip-security = "debian"

LAYERSERIES_COMPAT_cip-security = "warrior"
+
+require conf/include/aide-static-libs.inc
--
2.27.0.windows.1

The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may
contain privileged information.
If you are not the intended recipient, please notify the sender and delete the message along with any
attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any
annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be
the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is
accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use.

3801 - 3820 of 9278