Date   

New CVE entries this week

Masami Ichikawa
 

Hi !

It's this week's CVE report.

This week reported 8 new CVEs and 0 updated CVEs.

* New CVEs

CVE-2022-3169: Request to NVME_IOCTL_RESET and NVME_IOCTL_SUBSYS_RESET
may cause a DOS

CVSS v3 score is 5.5 MEDIUM.

A denial of service flaw may occur if there is a consecutive request
of the NVME_IOCTL_RESET and the NVME_IOCTL_SUBSYS_RESET through the
device file of the driver, resulting in a PCIe link disconnect.

This bug was reported last October to the kernel bugzilla
(https://bugzilla.redhat.com/show_bug.cgi?id=2125341) but it hasn't
been fixed yet.

Fixed status
Not fixed yet.

CVE-2022-40307: efi: capsule-loader: Fix use-after-free in efi_capsule_write

CVSS v3 score is 4.7 MEDIUM.

There is a race condition that occurs between the efi_capsule_write() and
efi_capsule_flush(). This race condition bug causes use-after-free bug.

Fixed status
mainline: [9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95]

CVE-2022-3077: A buffer overflow vulnerability was found in the Linux
kernel Intel’s iSMT SMBus host controller driver

CVSS v3 score is not assigned.

A buffer overflow vulnerability was found in the Linux kernel Intel’s
iSMT SMBus host controller driver in the way it handled the
I2C_SMBUS_BLOCK_PROC_CALL case (via the ioctl I2C_SMBUS) with
malicious input data. This flaw could allow a local user to crash the
system.

This vulnerability was introduced by commit 5e9a97b ("i2c: ismt:
Adding support for I2C_SMBUS_BLOCK_PROC_CALL") in 5.11-rc1.
This commit is not backported to earlier versions so that 4.4, 4.9,
4.14, 4.19, and 5.10 are not vulnerabile.

Fixed status
mainline: [690b2549b19563ec5ad53e5c82f6a944d910086e]
stable/5.15: [24c6fc6e7453f64cf6cbb4218c62aafdecc16ee1]

CVE-2022-36280: An out-of-bounds(OOB) memory access vulnerability was
found in vmwgfx driver

CVSS v3 score is not assigned(NIST).
CVSS v3 score is 6.3 MEDIUM(CNA).

An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx
driver in drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the
Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This
flaw allows a local attacker with a user account on the system to gain
privilege, causing a denial of service(DoS).

Above description said the vulnerability is in
drivers/gpu/vmxgfx/vmxgfx_kms.c but this file doesn't exist in the
mainline. It may be drivers/gpu/drm/vmwgfx/vmwgfx_kms.c instead.

Fixed status
Not fixed yet.

CVE-2022-38096: A NULL pointer dereference vulnerability was found in
vmwgfx driver

CVSS v3 score is 5.5 MEDIUM(NIST).
CVSS v3 score is 6.3 MEDIUM(CNA).

Above description said the vulnerability is in
drivers/gpu/vmxgfx/vmxgfx_kms.c but this file doesn't exist in the
mainline. It may be drivers/gpu/drm/vmwgfx/vmwgfx_kms.c instead.

Fixed status
Not fixed yet.

CVE-2022-38457: A use-after-free vulnerability was found int vmwgfx
drivers driver

CVSS v3 score is 5.5 MEDIUM(NIST).
CVSS v3 score is 6.3 MEDIUM(CNA).

A NULL pointer dereference vulnerability was found in vmwgfx driver in
drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel
with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a
local attacker with a user account on the system to gain privilege,
causing a denial of service(DoS).

Above description said the vulnerability is in
drivers/gpu/vmxgfx/vmxgfx_execbuf.c but this file doesn't exist in the
mainline. It may be drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c instead.

Fixed status
Not fixed yet.

CVE-2022-40133: A use-after-free vulnerability was found in vmwgfx driver

CVSS v3 score 5.5 MEDIUM(NIST).
CVSS v3 score is 6.3 MEDIUM(CNA).

A use-after-free(UAF) vulnerability was found in function
'vmw_execbuf_tie_context' in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in
Linux kernel's vmwgfx driver with device file '/dev/dri/renderD128 (or
Dxxx)'. This flaw allows a local attacker with a user account on the
system to gain privilege, causing a denial of service(DoS).

Above description said the vulnerability is in
drivers/gpu/vmxgfx/vmxgfx_execbuf.c but this file doesn't exist in the
mainline. It may be drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c instead.

Fixed status
Not fixed yet.

CVE-2022-3202: Null Pointer Deference in jfs_evict_inode leads to
Denial of Service

CVSS v3 score is not assigned

A NULL pointer dereference flaw in diFree in fs/jfs/inode.c in
Journaled File System (JFS)in the Linux kernel. This could allow a
local attacker to crash the system or leak kernel internal
information.

All stable kernels and cip kernels are fixed this issue.

Fixed status
mainline: [a53046291020ec41e09181396c1e829287b48d47]
stable/4.14: [33bd243566a9b1ca94261dcc2e16c7b9e3a71c15]
stable/4.19: [2ef74e3e0089b6615ee124e1183746974c6bb561]
stable/4.9: [d2e45f0bc25da09efcac658d6e405115fcfa83c2]
stable/5.10: [b9c5ac0a15f24d63b20f899072fa6dd8c93af136]
stable/5.15: [d925b7e78b62805fcc5440d1521181c82b6f03cb]
stable/5.4: [e19c3149a80e4fc8df298d6546640e01601f3758]

* Updated CVEs

No update CVEs.

Fixed status

Currently tracking CVEs

CVE-2021-31615: Unencrypted Bluetooth Low Energy baseband links in
Bluetooth Core Specifications 4.0 through 5.2

There is no fix information.

CVE-2020-26556: kernel: malleable commitment Bluetooth Mesh Provisioning

No fix information.

CVE-2020-26557: kernel: predictable Authvalue in Bluetooth Mesh
Provisioning Leads to MITM

No fix information.

CVE-2020-26559: kernel: Authvalue leak in Bluetooth Mesh Provisioning

No fix information.

CVE-2020-26560: kernel: impersonation attack in Bluetooth Mesh Provisioning

No fix information.

Regards,
--
Masami Ichikawa
Cybertrust Japan Co., Ltd.

Email :masami.ichikawa@...
:masami.ichikawa@...


[isar-cip-core][PATCH] Update to kas 3.1

Srinuvasan A
 

From: Srinuvasan A <srinuvasan_a@...>

Update to kas 3.1.

Signed-off-by: Srinuvasan A <srinuvasan_a@...>
---
.gitlab-ci.yml | 2 +-
README.md | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 81301e5..ce40b5d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,4 +1,4 @@
-image: ghcr.io/siemens/kas/kas-isar:3.0.2
+image: ghcr.io/siemens/kas/kas-isar:3.1

variables:
GIT_STRATEGY: clone
diff --git a/README.md b/README.md
index ff973c5..e30ff3a 100644
--- a/README.md
+++ b/README.md
@@ -12,7 +12,7 @@ from scratch.

Install `kas-container` from the [kas project](https://github.com/siemens/kas):

- wget https://raw.githubusercontent.com/siemens/kas/3.0.2/kas-container
+ wget https://raw.githubusercontent.com/siemens/kas/3.1/kas-container
chmod a+x kas-container

Furthermore, install docker and make sure you have required permissions to
--
2.25.1


CIP kernel lunch on Thursday at OSSEU

Jan Kiszka
 

Hi all,

if you are around at OSSEU/ELC-E here in Dublin:

The kernel workground, means those of us who are attending in-person,
will meet tomorrow at the CIP booth for having lunch together at 1pm.
Feel free to join us!

Jan


[isar-cip-core][PATCH v2] linux-cip: Update to 4.19.255-cip79, 5.10.140-cip16[-rt6]

Jan Kiszka
 

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

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

Changes in v2:
- fix typo in a download sha

...5.10.131-cip13-rt5.bb => linux-cip-rt_5.10.140-cip16-rt6.bb} | 2 +-
...{linux-cip_4.19.255-cip79.bb => linux-cip_4.19.257-cip81.bb} | 2 +-
...{linux-cip_5.10.136-cip14.bb => linux-cip_5.10.140-cip16.bb} | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
rename recipes-kernel/linux/{linux-cip-rt_5.10.131-cip13-rt5.bb => linux-cip-rt_5.10.140-cip16-rt6.bb} (72%)
rename recipes-kernel/linux/{linux-cip_4.19.255-cip79.bb => linux-cip_4.19.257-cip81.bb} (72%)
rename recipes-kernel/linux/{linux-cip_5.10.136-cip14.bb => linux-cip_5.10.140-cip16.bb} (72%)

diff --git a/recipes-kernel/linux/linux-cip-rt_5.10.131-cip13-rt5.bb b/recipes-kernel/linux/linux-cip-rt_5.10.140-cip16-rt6.bb
similarity index 72%
rename from recipes-kernel/linux/linux-cip-rt_5.10.131-cip13-rt5.bb
rename to recipes-kernel/linux/linux-cip-rt_5.10.140-cip16-rt6.bb
index 8c82e7e..fc895db 100644
--- a/recipes-kernel/linux/linux-cip-rt_5.10.131-cip13-rt5.bb
+++ b/recipes-kernel/linux/linux-cip-rt_5.10.140-cip16-rt6.bb
@@ -13,4 +13,4 @@ require linux-cip-rt-common.inc

KERNEL_DEFCONFIG_VERSION ?= "5.10.y-cip"

-SRC_URI[sha256sum] = "fc5ba1290c6ebeab65ad3783d3a0c65e2bb866c58905f2e627da04dff25166b3"
+SRC_URI[sha256sum] = "a59d2994a826c0a1a62e8631f482c6caa98faf87355d7b47868ce7ce17c2e9ce"
diff --git a/recipes-kernel/linux/linux-cip_4.19.255-cip79.bb b/recipes-kernel/linux/linux-cip_4.19.257-cip81.bb
similarity index 72%
rename from recipes-kernel/linux/linux-cip_4.19.255-cip79.bb
rename to recipes-kernel/linux/linux-cip_4.19.257-cip81.bb
index 7d1e634..1067672 100644
--- a/recipes-kernel/linux/linux-cip_4.19.255-cip79.bb
+++ b/recipes-kernel/linux/linux-cip_4.19.257-cip81.bb
@@ -13,4 +13,4 @@ require linux-cip-common.inc

KERNEL_DEFCONFIG_VERSION ?= "4.19.y-cip"

-SRC_URI[sha256sum] = "5e96607abd43e0e9e5935068f684b47fbb3101f913a85812ccbb326b27ff369c"
+SRC_URI[sha256sum] = "9337fca3b8f981bd26884a3fd1035296ce5db8b458c776b73114e3e476423737"
diff --git a/recipes-kernel/linux/linux-cip_5.10.136-cip14.bb b/recipes-kernel/linux/linux-cip_5.10.140-cip16.bb
similarity index 72%
rename from recipes-kernel/linux/linux-cip_5.10.136-cip14.bb
rename to recipes-kernel/linux/linux-cip_5.10.140-cip16.bb
index 3114365..9ed9ea6 100644
--- a/recipes-kernel/linux/linux-cip_5.10.136-cip14.bb
+++ b/recipes-kernel/linux/linux-cip_5.10.140-cip16.bb
@@ -13,4 +13,4 @@ require linux-cip-common.inc

KERNEL_DEFCONFIG_VERSION ?= "5.10.y-cip"

-SRC_URI[sha256sum] = "27dc2d0b877582b1d8e83c071029b26752d8a9cab2033ec7fef0c68b6bb9b4fa"
+SRC_URI[sha256sum] = "0bc556457854220e82e6e4f738ddccf92875817f28a0d0643d005fa9038935d0"
--
2.35.3


Re: [isar-cip-core] iwg20m: remove fixed PREFERRED_VERSION for linux_cip

Jan Kiszka
 

On 12.09.22 14:16, Hung Tran wrote:
From: Hung Tran <hung.tran.jy@...>

iwg20m had PREFERRED_VERSION for linux_cip as 4.4.%
Due to this setting, Gitlab CI always build linux_cip
version 4.4 for any iwg20m build targets.

This setting is old, and not necessary anymore.
Remove it to allow building suitable linux_cip versions for
each build target (4.19 for buster and 5.10 for bullseye)

Signed-off-by: Hung Tran <hung.tran.jy@...>
---
conf/machine/iwg20m.conf | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/conf/machine/iwg20m.conf b/conf/machine/iwg20m.conf
index d997a02..f5d5dda 100644
--- a/conf/machine/iwg20m.conf
+++ b/conf/machine/iwg20m.conf
@@ -14,13 +14,9 @@ IMAGE_FSTYPES ?= "wic"
MACHINE_SERIAL = "ttySC0"
BAUDRATE_TTY = "115200"

-# kernel version
-PREFERRED_VERSION_linux-cip ?= "4.4.%"
-PREFERRED_VERSION_linux-cip-rt ?= "4.4.%"
+# Setting for kernel and boot
USE_CIP_KERNEL_CONFIG = "1"
-KERNEL_DEFCONFIG = "cip-kernel-config/4.4.y-cip/arm/renesas_shmobile_defconfig"
-
-# Boot partition files
+KERNEL_DEFCONFIG = "cip-kernel-config/${KERNEL_DEFCONFIG_VERSION}/arm/renesas_shmobile_defconfig"
DTB_FILES = "r8a7743-iwg20d-q7-dbcm-ca.dtb"
KERNEL_IMAGE="zImage"
IMAGE_BOOT_FILES = "${KERNEL_IMAGE} ${DTB_FILES}"
Thanks, applied.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux


[isar-cip-core][PATCH] linux-cip: Update to 4.19.255-cip79, 5.10.140-cip16[-rt6]

Jan Kiszka
 

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

Signed-off-by: Jan Kiszka <jan.kiszka@...>
---
...5.10.131-cip13-rt5.bb => linux-cip-rt_5.10.140-cip16-rt6.bb} | 2 +-
...{linux-cip_4.19.255-cip79.bb => linux-cip_4.19.257-cip81.bb} | 2 +-
...{linux-cip_5.10.136-cip14.bb => linux-cip_5.10.140-cip16.bb} | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
rename recipes-kernel/linux/{linux-cip-rt_5.10.131-cip13-rt5.bb => linux-cip-rt_5.10.140-cip16-rt6.bb} (72%)
rename recipes-kernel/linux/{linux-cip_4.19.255-cip79.bb => linux-cip_4.19.257-cip81.bb} (72%)
rename recipes-kernel/linux/{linux-cip_5.10.136-cip14.bb => linux-cip_5.10.140-cip16.bb} (72%)

diff --git a/recipes-kernel/linux/linux-cip-rt_5.10.131-cip13-rt5.bb b/recipes-kernel/linux/linux-cip-rt_5.10.140-cip16-rt6.bb
similarity index 72%
rename from recipes-kernel/linux/linux-cip-rt_5.10.131-cip13-rt5.bb
rename to recipes-kernel/linux/linux-cip-rt_5.10.140-cip16-rt6.bb
index 8c82e7e..fc895db 100644
--- a/recipes-kernel/linux/linux-cip-rt_5.10.131-cip13-rt5.bb
+++ b/recipes-kernel/linux/linux-cip-rt_5.10.140-cip16-rt6.bb
@@ -13,4 +13,4 @@ require linux-cip-rt-common.inc

KERNEL_DEFCONFIG_VERSION ?= "5.10.y-cip"

-SRC_URI[sha256sum] = "fc5ba1290c6ebeab65ad3783d3a0c65e2bb866c58905f2e627da04dff25166b3"
+SRC_URI[sha256sum] = "a59d2994a826c0a1a62e8631f482c6caa98faf87355d7b47868ce7ce17c2e9ce"
diff --git a/recipes-kernel/linux/linux-cip_4.19.255-cip79.bb b/recipes-kernel/linux/linux-cip_4.19.257-cip81.bb
similarity index 72%
rename from recipes-kernel/linux/linux-cip_4.19.255-cip79.bb
rename to recipes-kernel/linux/linux-cip_4.19.257-cip81.bb
index 7d1e634..1067672 100644
--- a/recipes-kernel/linux/linux-cip_4.19.255-cip79.bb
+++ b/recipes-kernel/linux/linux-cip_4.19.257-cip81.bb
@@ -13,4 +13,4 @@ require linux-cip-common.inc

KERNEL_DEFCONFIG_VERSION ?= "4.19.y-cip"

-SRC_URI[sha256sum] = "5e96607abd43e0e9e5935068f684b47fbb3101f913a85812ccbb326b27ff369c"
+SRC_URI[sha256sum] = "9337fca3b8f981bd26884a3fd1035296ce5db8b458c776b73114e3e476423737"
diff --git a/recipes-kernel/linux/linux-cip_5.10.136-cip14.bb b/recipes-kernel/linux/linux-cip_5.10.140-cip16.bb
similarity index 72%
rename from recipes-kernel/linux/linux-cip_5.10.136-cip14.bb
rename to recipes-kernel/linux/linux-cip_5.10.140-cip16.bb
index 3114365..f8bdc8f 100644
--- a/recipes-kernel/linux/linux-cip_5.10.136-cip14.bb
+++ b/recipes-kernel/linux/linux-cip_5.10.140-cip16.bb
@@ -13,4 +13,4 @@ require linux-cip-common.inc

KERNEL_DEFCONFIG_VERSION ?= "5.10.y-cip"

-SRC_URI[sha256sum] = "27dc2d0b877582b1d8e83c071029b26752d8a9cab2033ec7fef0c68b6bb9b4fa"
+SRC_URI[sha256sum] = "bc556457854220e82e6e4f738ddccf92875817f28a0d0643d005fa9038935d0"
--
2.35.3


[isar-cip-core] iwg20m: remove fixed PREFERRED_VERSION for linux_cip

Hung Tran
 

From: Hung Tran <hung.tran.jy@...>

iwg20m had PREFERRED_VERSION for linux_cip as 4.4.%
Due to this setting, Gitlab CI always build linux_cip
version 4.4 for any iwg20m build targets.

This setting is old, and not necessary anymore.
Remove it to allow building suitable linux_cip versions for
each build target (4.19 for buster and 5.10 for bullseye)

Signed-off-by: Hung Tran <hung.tran.jy@...>
---
conf/machine/iwg20m.conf | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/conf/machine/iwg20m.conf b/conf/machine/iwg20m.conf
index d997a02..f5d5dda 100644
--- a/conf/machine/iwg20m.conf
+++ b/conf/machine/iwg20m.conf
@@ -14,13 +14,9 @@ IMAGE_FSTYPES ?= "wic"
MACHINE_SERIAL = "ttySC0"
BAUDRATE_TTY = "115200"

-# kernel version
-PREFERRED_VERSION_linux-cip ?= "4.4.%"
-PREFERRED_VERSION_linux-cip-rt ?= "4.4.%"
+# Setting for kernel and boot
USE_CIP_KERNEL_CONFIG = "1"
-KERNEL_DEFCONFIG = "cip-kernel-config/4.4.y-cip/arm/renesas_shmobile_defconfig"
-
-# Boot partition files
+KERNEL_DEFCONFIG = "cip-kernel-config/${KERNEL_DEFCONFIG_VERSION}/arm/renesas_shmobile_defconfig"
DTB_FILES = "r8a7743-iwg20d-q7-dbcm-ca.dtb"
KERNEL_IMAGE="zImage"
IMAGE_BOOT_FILES = "${KERNEL_IMAGE} ${DTB_FILES}"
--
2.25.1


Re: [isar-cip-core] README.swupdate.md: Add steps to verify SWUpdate on BBB

Kazuhiro Hayashi
 

Hello Shiva-san,


Hello Jan,

Thank you for the suggestion. I think the approach you mentioned is more developer friendly compared to mine.
however, I would like keep both, let user select the preferable option. Is it ok?
I think the document should be shorter & simpler and focus on SWUpdate testing.
If the network settings step is just for "scp", it's better to replace it by another simple way.

Best regards,
Kazu


Thanks & Regards
Shivanand K

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Jan Kiszka
Sent: Friday, September 9, 2022 11:11 PM
To: kunijadar shivanand(TSIP TMIEC ODG Porting) <Shivanand.Kunijadar@...>;
cip-dev@...
Cc: dinesh kumar(TSIP TMIEC ODG Porting) <dinesh.kumar@...>; hayashi kazuhiro(林 和宏 □SW
C◯ACT) <kazuhiro3.hayashi@...>
Subject: Re: [cip-dev] [isar-cip-core] README.swupdate.md: Add steps to verify SWUpdate on BBB

On 09.09.22 15:25, Shivanand.Kunijadar@... wrote:
From: Shivanand Kunijadar <Shivanand.Kunijadar@...>

Most of the steps are similar for both qemu-amd64 and BBB targets.
Add reference link wherever required instead of repeating steps.

Signed-off-by: Shivanand Kunijadar
<Shivanand.Kunijadar@...>
---
doc/README.swupdate.md | 52
++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)

diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md index
1b242a2..72690d6 100644
--- a/doc/README.swupdate.md
+++ b/doc/README.swupdate.md
@@ -32,6 +32,8 @@ Copy
`cip-core-image-cip-core-bullseye-qemu-amd64.swu` file from `tmp` folder in host$ scp -P 22222
/tmp/cip-core-image-cip-core-bullseye-qemu-amd64.swu root@localhost:
```

+## SWUpdate verification
+
Check which partition is booted, e.g. with lsblk:
```
root@demo:~# lsblk
@@ -215,3 +217,53 @@ user variables:


```
+
+# Building and testing the CIP Core image for BBB
+
+Follow the steps mentioned in the section [Building and testing the CIP Core
image](README.swupdate.md#building-and-testing-the-cip-core-image) for creating images and .swu files.
+- Replace qemu-amd64.yml kas file with BBB board specific file i.e
+bbb.yml
+- .swu file will be generated in the following folder
+build/tmp/deploy/images/bbb/
+
+Flash the BeagleBone Black image into SDcard ``` host$ dd
+if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-bullseye-bbb.wic \
+ of=/dev/<medium-device> bs=1M status=progress ```
+
+Prepare the hardware connections
+
+- Connect a serial port cable between host PC and BBB
+- Connect an Ethernet cable between host PC and BBB
+
+Insert SD card to BBB, hold S2 button while applying power suppy to BBB.
typo: supply

+Once the system is up, execute below command to configure static IP
+address to BBB
+
+```
+root@demo:~# cat <<EOF >> /etc/network/interfaces auto eth0 iface
+eth0 inet static
+ address 192.168.2.2
+ netmask 255.255.255.0
+ network 192.168.2.0
+ broadcast 192.168.2.255
+EOF
+root@demo:~# /etc/init.d/networking restart ```
+
+In host PC, configure below settings for Ethernet IPv4.
+
+- IP address: 192.168.2.1
+- Subnet mask: 255.255.255.0
+
+Execute below command to confirm 192.168.2.1 is accessible from BBB.
+```
+root@demo:~# ping 192.168.2.1
+```
+
+Copy .swu file from `tmp` folder to BBB from host PC using below command.
+
+```
+host$ scp tmp/cip-core-image-cip-core-bullseye-bbb.swu
+root@....2:/root/ ```
+
+For verifying swupdate on BBB use the same steps as mentioned in above [SWUpdate
Verification](README.swupdate.md#swupdate-verification).

How I tested (in the absence of a test network at that time):
- mount the flashed SD-card on the host
- cp the DIFFERENT swu into <mnt>/root/
- boot the target and run swupdate -i /root/<image>.swu

I think that is simpler if there is no common network with dhcp in reach.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux


Re: [isar-cip-core] README.swupdate.md: Add steps to verify SWUpdate on BBB

Kunijadar Shivanand
 

Hello Jan,

Thank you for the suggestion. I think the approach you mentioned is more developer friendly compared to mine.
however, I would like keep both, let user select the preferable option. Is it ok?

Thanks & Regards
Shivanand K

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Jan Kiszka
Sent: Friday, September 9, 2022 11:11 PM
To: kunijadar shivanand(TSIP TMIEC ODG Porting) <Shivanand.Kunijadar@...>; cip-dev@...
Cc: dinesh kumar(TSIP TMIEC ODG Porting) <dinesh.kumar@...>; hayashi kazuhiro(林 和宏 □SWC◯ACT) <kazuhiro3.hayashi@...>
Subject: Re: [cip-dev] [isar-cip-core] README.swupdate.md: Add steps to verify SWUpdate on BBB

On 09.09.22 15:25, Shivanand.Kunijadar@... wrote:
From: Shivanand Kunijadar <Shivanand.Kunijadar@...>

Most of the steps are similar for both qemu-amd64 and BBB targets.
Add reference link wherever required instead of repeating steps.

Signed-off-by: Shivanand Kunijadar
<Shivanand.Kunijadar@...>
---
doc/README.swupdate.md | 52
++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)

diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md index
1b242a2..72690d6 100644
--- a/doc/README.swupdate.md
+++ b/doc/README.swupdate.md
@@ -32,6 +32,8 @@ Copy
`cip-core-image-cip-core-bullseye-qemu-amd64.swu` file from `tmp` folder in host$ scp -P 22222 /tmp/cip-core-image-cip-core-bullseye-qemu-amd64.swu root@localhost:
```

+## SWUpdate verification
+
Check which partition is booted, e.g. with lsblk:
```
root@demo:~# lsblk
@@ -215,3 +217,53 @@ user variables:


```
+
+# Building and testing the CIP Core image for BBB
+
+Follow the steps mentioned in the section [Building and testing the CIP Core image](README.swupdate.md#building-and-testing-the-cip-core-image) for creating images and .swu files.
+- Replace qemu-amd64.yml kas file with BBB board specific file i.e
+bbb.yml
+- .swu file will be generated in the following folder
+build/tmp/deploy/images/bbb/
+
+Flash the BeagleBone Black image into SDcard ``` host$ dd
+if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-bullseye-bbb.wic \
+ of=/dev/<medium-device> bs=1M status=progress ```
+
+Prepare the hardware connections
+
+- Connect a serial port cable between host PC and BBB
+- Connect an Ethernet cable between host PC and BBB
+
+Insert SD card to BBB, hold S2 button while applying power suppy to BBB.
typo: supply

+Once the system is up, execute below command to configure static IP
+address to BBB
+
+```
+root@demo:~# cat <<EOF >> /etc/network/interfaces auto eth0 iface
+eth0 inet static
+ address 192.168.2.2
+ netmask 255.255.255.0
+ network 192.168.2.0
+ broadcast 192.168.2.255
+EOF
+root@demo:~# /etc/init.d/networking restart ```
+
+In host PC, configure below settings for Ethernet IPv4.
+
+- IP address: 192.168.2.1
+- Subnet mask: 255.255.255.0
+
+Execute below command to confirm 192.168.2.1 is accessible from BBB.
+```
+root@demo:~# ping 192.168.2.1
+```
+
+Copy .swu file from `tmp` folder to BBB from host PC using below command.
+
+```
+host$ scp tmp/cip-core-image-cip-core-bullseye-bbb.swu
+root@....2:/root/ ```
+
+For verifying swupdate on BBB use the same steps as mentioned in above [SWUpdate Verification](README.swupdate.md#swupdate-verification).
How I tested (in the absence of a test network at that time):
- mount the flashed SD-card on the host
- cp the DIFFERENT swu into <mnt>/root/
- boot the target and run swupdate -i /root/<image>.swu

I think that is simpler if there is no common network with dhcp in reach.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux


Re: [ANNOUNCE] Release v4.19.257-cip81 and v5.10.140-cip16

Pavel Machek
 

Hi!


CIP kernel team has released Linux kernel v4.19.257-cip81 and v5.10.140-cip16 The linux-4.19.y-cip tree has been updated base version from v4.19.256 to v4.19.257, and the linux-5.10.y-cip tree has been updated base version from v5.10.138 to v5.10.140.
RZ/G2UL SoC and reference board support have been added to 5.10.y-cip tree with this update.
Thank you. I just pushed -rt tree based on 5.10.140.

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


[ANNOUNCE] 5.10.140-cip16-rt6

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-5.10.y-cip-rt
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-5.10.y-cip-rt-rebase

And their content should be identical.

Best regards,
Pavel

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


Re: [isar-cip-core] README.swupdate.md: Add steps to verify SWUpdate on BBB

Jan Kiszka
 

On 09.09.22 15:25, Shivanand.Kunijadar@... wrote:
From: Shivanand Kunijadar <Shivanand.Kunijadar@...>

Most of the steps are similar for both qemu-amd64 and BBB targets.
Add reference link wherever required instead of repeating steps.

Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@...>
---
doc/README.swupdate.md | 52 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)

diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md
index 1b242a2..72690d6 100644
--- a/doc/README.swupdate.md
+++ b/doc/README.swupdate.md
@@ -32,6 +32,8 @@ Copy `cip-core-image-cip-core-bullseye-qemu-amd64.swu` file from `tmp` folder in
host$ scp -P 22222 /tmp/cip-core-image-cip-core-bullseye-qemu-amd64.swu root@localhost:
```

+## SWUpdate verification
+
Check which partition is booted, e.g. with lsblk:
```
root@demo:~# lsblk
@@ -215,3 +217,53 @@ user variables:


```
+
+# Building and testing the CIP Core image for BBB
+
+Follow the steps mentioned in the section [Building and testing the CIP Core image](README.swupdate.md#building-and-testing-the-cip-core-image) for creating images and .swu files.
+- Replace qemu-amd64.yml kas file with BBB board specific file i.e bbb.yml
+- .swu file will be generated in the following folder build/tmp/deploy/images/bbb/
+
+Flash the BeagleBone Black image into SDcard
+```
+host$ dd if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-bullseye-bbb.wic \
+ of=/dev/<medium-device> bs=1M status=progress
+```
+
+Prepare the hardware connections
+
+- Connect a serial port cable between host PC and BBB
+- Connect an Ethernet cable between host PC and BBB
+
+Insert SD card to BBB, hold S2 button while applying power suppy to BBB.
typo: supply

+Once the system is up, execute below command to configure static IP address to BBB
+
+```
+root@demo:~# cat <<EOF >> /etc/network/interfaces
+auto eth0
+iface eth0 inet static
+ address 192.168.2.2
+ netmask 255.255.255.0
+ network 192.168.2.0
+ broadcast 192.168.2.255
+EOF
+root@demo:~# /etc/init.d/networking restart
+```
+
+In host PC, configure below settings for Ethernet IPv4.
+
+- IP address: 192.168.2.1
+- Subnet mask: 255.255.255.0
+
+Execute below command to confirm 192.168.2.1 is accessible from BBB.
+```
+root@demo:~# ping 192.168.2.1
+```
+
+Copy .swu file from `tmp` folder to BBB from host PC using below command.
+
+```
+host$ scp tmp/cip-core-image-cip-core-bullseye-bbb.swu root@....2:/root/
+```
+
+For verifying swupdate on BBB use the same steps as mentioned in above [SWUpdate Verification](README.swupdate.md#swupdate-verification).
How I tested (in the absence of a test network at that time):
- mount the flashed SD-card on the host
- cp the DIFFERENT swu into <mnt>/root/
- boot the target and run swupdate -i /root/<image>.swu

I think that is simpler if there is no common network with dhcp in reach.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux


Re: [isar-cip-core 1/2] README.control-system-backup.md: Add steps to explain control system backup

Jan Kiszka
 

On 09.09.22 10:07, Sai.Sathujoda@... wrote:
From: Sai <Sai.Sathujoda@...>

Control system backup is an IEC security requirement to backup critical
systems for disaster recovery and system migration program.

This document demonstrates how control system backup can be taken using
'duplicity', and also provide steps to check the integrity and restore
the backups.

Signed-off-by: Sai <Sai.Sathujoda@...>
---
doc/README.control-system-backup.md | 194 ++++++++++++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 doc/README.control-system-backup.md

diff --git a/doc/README.control-system-backup.md b/doc/README.control-system-backup.md
new file mode 100644
index 0000000..4f4f9e1
--- /dev/null
+++ b/doc/README.control-system-backup.md
@@ -0,0 +1,194 @@
+# Overview
+This document explains how to take system-level backup, verify integrity, and restore the backup file. It also mentions the demonstration which has to be carried out using **duplicity** to perform both local and remote backups.
+
+# Description
+There is always a chance for the data to get corrupted or lost due to some unknown reasons. In those situations, system level backup is helpful so that if any data is lost then it can be restored back.
+If there is a lot of space available in the system then **Local backup** can be considered. But in some cases space will not be enough if we opt for daily backup. In that situation, it is better to choose remote backup where all the data in the system will be stored on a remote server.
+
+**Duplicity** provides facilities like system-level backup, encryption of the data taken as a backup, verification of data integrity before restore and finally the restoration of the data from the backup.
+
+# Pre-Requisites
+1. CIP security image which includes **duplicity** package, to build the image follow the steps described in the [README.security-testing.md](./README.security-testing.md#build-cip-security-linux-image).
+2. Additional storage in case of local backup, (Add the below lines in **/kas/opt/security.yml** file to increase the rootfs size).
+ ```
+ local_conf_header:
+ security_image_size: |
+ ROOTFS_EXTRA = "8192"
+ ```
+3. Remote machine with Linux OS to store remote backups.
I think this should rather target our SWUpdate configuration variant
where the data is clearly separated from the read-only rootfs.

+
+# Local Backup & Restore
+For the first backup taken it will be a **full backup** but after that it will be incremental backups. If full backups are to be taken explicitly then add "full" in the command.
+
+The user can choose the data needed to be taken as backup. For example, in the below command /usr/bin directory is taken as backup in the /usr/local/backup location locally.
See above: bad example. It's /home and /var in a more realistic system.

+Note: PASSPHRASE should be more than 8 characters.
+```
+root@demo:~# export PASSPHRASE=12345678
+root@demo:~# duplicity /usr/bin file:///usr/local/backup
+Local and Remote metadata are synchronized, no sync needed.
+Last full backup date: none
+No signatures found, switching to full backup.
+--------------[ Backup Statistics ]--------------
+StartTime 1661752359.77 (Mon Aug 29 05:52:39 2022)
+EndTime 1661752362.69 (Mon Aug 29 05:52:42 2022)
+ElapsedTime 2.92 (2.92 seconds)
+SourceFiles 582
+SourceFileSize 49793026 (47.5 MB)
+NewFiles 582
+NewFileSize 49793026 (47.5 MB)
+DeletedFiles 0
+ChangedFiles 0
+ChangedFileSize 0 (0 bytes)
+ChangedDeltaSize 0 (0 bytes)
+DeltaEntries 582
+RawDeltaSize 49779683 (47.5 MB)
+TotalDestinationSizeChange 21135788 (20.2 MB)
+Errors 0
+```
+Note: Two different data sets cannot be taken as backup into the same location. So make sure when a data set different from the previous is taken as backup, choose a different storage location.
+
+### Verification of data integrity before restore
+We can verify whatever changes are made to our latest file system on comparing with a latest backup taken like below:
+```
+root@demo:/usr/bin# rm google-authenticator
+root@demo:~# duplicity verify --compare-data -v4 file:///usr/local/backup /usr/bin
+Last full backup date: Mon Aug 29 05:52:31 2022
+GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 05:56:13 2022, expected Mon Aug 29 03:54:07 2022
+Difference found: File google-authenticator is missing
+Verify complete: 582 files compared, 2 differences found.
+```
+
+#### Data Restore
+The files can be restored only after integrity verification as shown above so that the user will specifically know which files or directories have to be restored due to an unwanted change or deletion in the file system.
+
+```
+root@demo:~# duplicity --file-to-restore google-authenticator file:///usr/local/backup /usr/bin/google-authenticator
+```
+Situation : If a directory containing 1000 files has around 250 files deleted and around 100 files modified. In that case it is not user friendly for the user to individually restore such a huge list of modified files to restore. Duplicity will not allow overwrite of remaining files in the directory so in that case the only possible solution is to delete the entire directory and restore it from the backup.
+
+The --file-to-restore switch should be removed if the user wants to restore a complete directory like shown below.
+```
+root@demo:~# duplicity file:///usr/local/backup /usr/bin/
+```
+
+### Listing all the files in the backup
+To check all the contents of a backup do as shown below:
+```
+root@demo:~# duplicity list-current-files file:///usr/local/backup
+Local and Remote metadata are synchronized, no sync needed.
+Last full backup date: Mon Aug 29 05:52:31 2022
+Mon Aug 29 03:54:07 2022 .
+Mon Aug 29 03:52:37 2022 Mail
+Thu Sep 24 08:36:09 2020 [
+Thu Jan 20 20:10:35 2022 addpart
+Sun Jan 16 12:36:56 2022 aide
+Thu Jun 10 08:53:34 2021 apt
+Thu Jun 10 08:53:34 2021 apt-cache
+Thu Jun 10 08:53:34 2021 apt-cdrom
+Thu Jun 10 08:53:34 2021 apt-config
+...
+```
+
+# Remote Backup & Restore
+### Setting up the environment on remote server
+In the Local server, generate a pair of RSA keys that will be used for authentication during remote backup.
+```
+root@demo:~# ssh-keygen -t rsa -b 2048 -N "" -f /root/.ssh/id_rsa
+root@demo:~# ssh-copy-id -i ~/.ssh/id_rsa remoteuser@remoteserver-ip
+```
+
+Create a directory in remote server for keeping the backup files
+```
+root@demo:~# ssh remoteuser@remoteserver mkdir -p sftp_remote_bk_testing/first_backup
+```
+
+### Generation of GPG keys for encryption of data
+Create a file name gen-key-script and add the parameters like below:
+```
+root@demo:~# cat >foo <<EOF
+ Key-Type: DSA
+ Key-Length: 1024
+ Subkey-Type: ELG-E
+ Subkey-Length: 1024
+ Name-Real: username
+ Name-Email: usermailID
+ Expire-Date: 0
+ # passphrase should be more than 8 characters
+ Passphrase: 123456789
+EOF
+root@demo:~# gpg --batch --gen-key foo
+gpg: Generating a basic OpenPGP key
+gpg: key AE57464HFG4 marked as ultimately trusted
+gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/E4C84C97B37BB24947E4522DA4B60C25738850E9.rev'
+```
+Use the encrypted key generated as above command and the encrypt key is AE57464HFG4 in the remote backup.
+
Manual setup on the target is also a suboptimal example as no real
system will likely ever be operated like that. Better define a workflow
and the required recipes to manage and inject the keys during image build.

+### Remote Backup
+```
+root@demo:~# duplicity --encrypt-key "AE57464HFG4" /usr/bin sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+```
+Find the backed up files in the remote location using the below command
+```
+root@demo:~# ssh remoteuser@remoteserver ls /home/remoteuser/sftp_remote_bk_testing/first_backup
+- duplicity-full.20220829T070950Z.manifest.gpg
+- duplicity-full.20220829T070950Z.vol1.difftar.gpg
+- duplicity-full-signatures.20220829T070950Z.sigtar.gpg
+```
+
+### Verification of integrity after recent backup in remote server
+```
+root@demo:~# duplicity verify --encrypt-key "AE57464HFG4" --compare-data sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin
+Local and Remote metadata are synchronized, no sync needed.5CAE2A504" --compare-data sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin
+Last full backup date: Mon Aug 29 07:09:50 2022
+GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 07:14:15 2022, expected Mon Aug 29 06:00:22 2022
+Difference found: File google-authenticator is missing
+Verify complete: 582 files compared, 2 differences found.
+```
+
+#### Restoration of data from remote server
+```
+root@demo:~# duplicity --file-to-restore google-authenticator sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin/google-authenticator
+```
+
+# Automatic Backup scheduling using cron service
+To avoid operator overhead to regularly take system backup, it is necessary to automate the backup so that the data backup will be **up-to-date**.
+
+While automating this backup process, it is suggestible to use remote backup based on space issue.
+
+Below a simple script which shall be added in the crontab to run on a daily basis.
+
+```
+#!/bin/bash
+echo "This will execute the backup on the first minute, first hour , every day"
+export PASSPHRASE=12345678
+duplicity --encrypt-key "AE57464HFG4" /usr/bin sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+unset PASSPHRASE
+```
+
+In this demo script, the /usr/bin is being taken as a backup. The user can replace based on the requirement.
+The passphrase should also match the one assigned by the user during GPG keys creation.
+
+Save the file (daily_backup.sh) in a known path and start the cron service.
+```
+root@demo:~# systemctl start cron
+```
+Check the status of the service (expected to be in running state)
+```
+root@demo:~# systemctl status cron
+● cron.service - Regular background program processing daemon
+ Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
+ Active: active (running) since Mon 2022-08-29 12:11:25 UTC; 12min ago
+```
+Open the crontab
+```
+root@demo:~# crontab -e
+```
+Add the below line at the end of the crontab file if the user needs a backup on daily basis onto the remote server.
+```
+0 0 * * * /root/daily_backup.sh
+```
+After saving the crontab, the below message should be displayed.
+**crontab: installing new crontab**
+The user can verify this automation by checking the contents of the remote backup folder regularly.
The crontab setup comes closes to what I would have expected from this
readme. What we are still missing are recipes to set that up during
build and do configure the backup sources there as well. Then AT MOST
the restore should remain as manual step.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux


[isar-cip-core] README.swupdate.md: Add steps to verify SWUpdate on BBB

Kunijadar Shivanand
 

From: Shivanand Kunijadar <Shivanand.Kunijadar@...>

Most of the steps are similar for both qemu-amd64 and BBB targets.
Add reference link wherever required instead of repeating steps.

Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@...>
---
doc/README.swupdate.md | 52 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)

diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md
index 1b242a2..72690d6 100644
--- a/doc/README.swupdate.md
+++ b/doc/README.swupdate.md
@@ -32,6 +32,8 @@ Copy `cip-core-image-cip-core-bullseye-qemu-amd64.swu` file from `tmp` folder in
host$ scp -P 22222 /tmp/cip-core-image-cip-core-bullseye-qemu-amd64.swu root@localhost:
```

+## SWUpdate verification
+
Check which partition is booted, e.g. with lsblk:
```
root@demo:~# lsblk
@@ -215,3 +217,53 @@ user variables:


```
+
+# Building and testing the CIP Core image for BBB
+
+Follow the steps mentioned in the section [Building and testing the CIP Core image](README.swupdate.md#building-and-testing-the-cip-core-image) for creating images and .swu files.
+- Replace qemu-amd64.yml kas file with BBB board specific file i.e bbb.yml
+- .swu file will be generated in the following folder build/tmp/deploy/images/bbb/
+
+Flash the BeagleBone Black image into SDcard
+```
+host$ dd if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-bullseye-bbb.wic \
+ of=/dev/<medium-device> bs=1M status=progress
+```
+
+Prepare the hardware connections
+
+- Connect a serial port cable between host PC and BBB
+- Connect an Ethernet cable between host PC and BBB
+
+Insert SD card to BBB, hold S2 button while applying power suppy to BBB.
+Once the system is up, execute below command to configure static IP address to BBB
+
+```
+root@demo:~# cat <<EOF >> /etc/network/interfaces
+auto eth0
+iface eth0 inet static
+ address 192.168.2.2
+ netmask 255.255.255.0
+ network 192.168.2.0
+ broadcast 192.168.2.255
+EOF
+root@demo:~# /etc/init.d/networking restart
+```
+
+In host PC, configure below settings for Ethernet IPv4.
+
+- IP address: 192.168.2.1
+- Subnet mask: 255.255.255.0
+
+Execute below command to confirm 192.168.2.1 is accessible from BBB.
+```
+root@demo:~# ping 192.168.2.1
+```
+
+Copy .swu file from `tmp` folder to BBB from host PC using below command.
+
+```
+host$ scp tmp/cip-core-image-cip-core-bullseye-bbb.swu root@....2:/root/
+```
+
+For verifying swupdate on BBB use the same steps as mentioned in above [SWUpdate Verification](README.swupdate.md#swupdate-verification).
--
2.20.1


[ANNOUNCE] Release v4.19.257-cip81 and v5.10.140-cip16

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.257-cip81 and v5.10.140-cip16 The linux-4.19.y-cip tree has been updated base version from v4.19.256 to v4.19.257, and the linux-5.10.y-cip tree has been updated base version from v5.10.138 to v5.10.140.
RZ/G2UL SoC and reference board support have been added to 5.10.y-cip tree with this update.

You can get this release via the git tree at:

v4.19.257-cip81:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
16d8368674cebd6b5d9a4b7317c0837f0a24eb5b
Fixed CVEs:
None
added commits:
CIP: Bump version suffix to -cip81 after merge from stable
drm: rcar-du: Fix Alpha blending issue on Gen3

v5.10.140-cip16:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-5.10.y-cip
commit hash:
e972e58dc6d8823515d89143ffc10d6dd7c9e621
Fixed CVEs:
CVE-2022-39190: netfilter: nf_tables: disallow binding to already bound chain
CVE-2022-3028: af_key: Do not call xfrm_probe_algs in parallel
CVE-2022-2905: bpf: Don't use tnum_range on array range checking for poke descriptors
added commits:
CIP: Bump version suffix to -cip16 after merge from stable
drm: rcar-du: Fix Alpha blending issue on Gen3
arm64: dts: renesas: rzg2ul-smarc-som: Enable ADC on SMARC platform
arm64: dts: renesas: rzg2ul-smarc: Enable RSPI1 on carrier board
arm64: dts: renesas: r9a07g043: Add ADC node
arm64: dts: renesas: r9a07g043: Add SPI Multi I/O Bus controller node
arm64: dts: renesas: r9a07g043: Create thermal zone to support IPA
arm64: dts: renesas: r9a07g043: Add TSU node
arm64: dts: renesas: r9a07g043: Add OPP table
arm64: dts: renesas: r9a07g043: Add RSPI{0,1,2} nodes
arm64: dts: renesas: rzg2ul-smarc: Enable USB2.0 support
arm64: dts: renesas: rzg2ul-smarc: Enable Audio
arm64: dts: renesas: rzg2l-smarc: Move ssi0 and cpu sound_dai nodes from common dtsi
arm64: dts: renesas: rzg2ul-smarc-som: Enable watchdog
arm64: dts: renesas: rzg2ul-smarc-som: Enable OSTM
arm64: dts: renesas: rzg2ul-smarc: Enable CANFD
arm64: dts: renesas: rzg2ul-smarc: Enable i2c{0,1} and wm8978
arm64: dts: renesas: r9a07g043: Fillup the WDT{0,2} stub nodes
arm64: dts: renesas: r9a07g043: Fillup the OSTM{0,1,2} stub nodes
arm64: dts: renesas: r9a07g043: Fillup the CANFD stub node
arm64: dts: renesas: r9a07g043: Add USB2.0 support
arm64: dts: renesas: r9a07g043: Add SSI{1,2,3} nodes and fillup the SSI0 stub node
arm64: dts: renesas: r9a07g043: Add I2C2 node and fillup the I2C{0,1,3} stub nodes
clk: renesas: r9a07g043: Add clock and reset entries for ADC
clk: renesas: r9a07g043: Add TSU clock and reset entry
clk: renesas: r9a07g043: Add RSPI clock and reset entries
clk: renesas: r9a07g043: Add clock and reset entries for SPI Multi I/O Bus Controller
dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G2UL USBPHY Control bindings
dt-bindings: iio: adc: Document Renesas RZ/G2UL ADC
dt-bindings: iio: adc: Document Renesas RZ/V2L ADC
ASoC: dt-bindings: renesas,rz-ssi: Document RZ/G2UL SoC
dt-bindings: watchdog: renesas,wdt: Document RZ/G2UL SoC
dt-bindings: thermal: rzg2l-thermal: Document RZ/G2UL bindings
dt-bindings: memory: renesas,rpc-if: Document RZ/G2UL SoC
spi: dt-bindings: renesas,rspi: Document RZ/G2UL SoC
dt-bindings: phy: renesas,usb2-phy: Document RZ/G2UL phy bindings
dt-bindings: can: renesas,rcar-canfd: Document RZ/G2UL support
dt-bindings: usb: renesas,usbhs: Document RZ/G2UL bindings
dt-bindings: i2c: renesas,riic: Document RZ/G2UL SoC
dt-bindings: timer: renesas: ostm: Document Renesas RZ/G2UL OSTM
arm64: dts: renesas: rzg2ul-smarc-som: Enable Ethernet on SMARC platform
arm64: dts: renesas: rzg2ul-smarc-som: Enable eMMC on SMARC platform
arm64: dts: renesas: rzg2ul-smarc: Enable microSD on SMARC platform
arm64: defconfig: Enable ARCH_R9A07G043
arm64: dts: renesas: r9a07g043: Add GbEthernet nodes
arm64: dts: renesas: r9a07g043: Add SDHI nodes
arm64: dts: renesas: rzg2ul-smarc: Add scif0 and audio clk pins
arm64: dts: renesas: r9a07g043: Fillup the pinctrl stub node
arm64: dts: renesas: Add initial device tree for RZ/G2UL Type-1 SMARC EVK
arm64: dts: renesas: Add initial DTSI for RZ/G2UL SoC
pinctrl: renesas: rzg2l: Return -EINVAL for pins which have input disabled
pinctrl: renesas: rzg2l: Restore pin config order
pinctrl: renesas: rzg2l: Add RZ/G2UL support
clk: renesas: r9a07g043: Add WDT clock and reset entries
clk: renesas: r9a07g043: Add OSTM clock and reset entries
clk: renesas: r9a07g043: Add clock and reset entries for CANFD
clk: renesas: r9a07g043: Add USB clocks/resets
clk: renesas: r9a07g043: Add SSIF-2 clock and reset entries
clk: renesas: r9a07g043: Add I2C clocks/resets
clk: renesas: r9a07g043: Add SDHI clock and reset entries
clk: renesas: r9a07g043: Add GbEthernet clock/reset
clk: renesas: r9a07g043: Add ethernet clock sources
clk: renesas: r9a07g043: Add GPIO clock and reset entries
clk: renesas: Add support for RZ/G2UL SoC
soc: renesas: Identify RZ/G2UL SoC
dt-bindings: clock: Add R9A07G043 CPG Clock and Reset Definitions
dt-bindings: net: renesas,etheravb: Document RZ/G2UL SoC
dt-bindings: mmc: renesas,sdhi: Document RZ/G2UL SoC
dt-bindings: dma: rz-dmac: Document RZ/G2UL SoC
dt-bindings: serial: renesas,sci: Document RZ/G2UL SoC
dt-bindings: serial: renesas,scif: Document RZ/G2UL SoC
dt-bindings: pinctrl: renesas: Document RZ/G2UL pinctrl
dt-bindings: clock: renesas: Document RZ/G2UL SoC
dt-bindings: power: renesas,rzg2l-sysc: Document RZ/G2UL SoC
dt-bindings: arm: renesas: Document Renesas RZ/G2UL SMARC EVK
dt-bindings: arm: renesas: Document Renesas RZ/V2L SoC on SMARC EVK

Best regards,
Nobuhiro


[isar-cip-core 2/2] cip-core-image-security.bb: Add duplicity package to enable IEC requirement

sai.sathujoda@...
 

From: Sai <Sai.Sathujoda@...>

Duplicity package provides below features in order to implement IEC
requirement "Control System Backup"
1. Backup and restore
2. Encryption of backup
3. Checks integrity before restore

Python3-paramiko package is required to enable remote backups.

Signed-off-by: Sai <Sai.Sathujoda@...>
---
recipes-core/images/cip-core-image-security.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb
index 24b1f46..9e9e43a 100644
--- a/recipes-core/images/cip-core-image-security.bb
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -34,6 +34,7 @@ IMAGE_PREINSTALL += " \
sudo \
aide-common \
libpam-google-authenticator \
+ duplicity python3-paramiko \
"

OVERRIDES_append = ":${BASE_DISTRO_CODENAME}"
--
2.20.1


[isar-cip-core 1/2] README.control-system-backup.md: Add steps to explain control system backup

sai.sathujoda@...
 

From: Sai <Sai.Sathujoda@...>

Control system backup is an IEC security requirement to backup critical
systems for disaster recovery and system migration program.

This document demonstrates how control system backup can be taken using
'duplicity', and also provide steps to check the integrity and restore
the backups.

Signed-off-by: Sai <Sai.Sathujoda@...>
---
doc/README.control-system-backup.md | 194 ++++++++++++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 doc/README.control-system-backup.md

diff --git a/doc/README.control-system-backup.md b/doc/README.control-system-backup.md
new file mode 100644
index 0000000..4f4f9e1
--- /dev/null
+++ b/doc/README.control-system-backup.md
@@ -0,0 +1,194 @@
+# Overview
+This document explains how to take system-level backup, verify integrity, and restore the backup file. It also mentions the demonstration which has to be carried out using **duplicity** to perform both local and remote backups.
+
+# Description
+There is always a chance for the data to get corrupted or lost due to some unknown reasons. In those situations, system level backup is helpful so that if any data is lost then it can be restored back.
+If there is a lot of space available in the system then **Local backup** can be considered. But in some cases space will not be enough if we opt for daily backup. In that situation, it is better to choose remote backup where all the data in the system will be stored on a remote server.
+
+**Duplicity** provides facilities like system-level backup, encryption of the data taken as a backup, verification of data integrity before restore and finally the restoration of the data from the backup.
+
+# Pre-Requisites
+1. CIP security image which includes **duplicity** package, to build the image follow the steps described in the [README.security-testing.md](./README.security-testing.md#build-cip-security-linux-image).
+2. Additional storage in case of local backup, (Add the below lines in **/kas/opt/security.yml** file to increase the rootfs size).
+ ```
+ local_conf_header:
+ security_image_size: |
+ ROOTFS_EXTRA = "8192"
+ ```
+3. Remote machine with Linux OS to store remote backups.
+
+# Local Backup & Restore
+For the first backup taken it will be a **full backup** but after that it will be incremental backups. If full backups are to be taken explicitly then add "full" in the command.
+
+The user can choose the data needed to be taken as backup. For example, in the below command /usr/bin directory is taken as backup in the /usr/local/backup location locally.
+Note: PASSPHRASE should be more than 8 characters.
+```
+root@demo:~# export PASSPHRASE=12345678
+root@demo:~# duplicity /usr/bin file:///usr/local/backup
+Local and Remote metadata are synchronized, no sync needed.
+Last full backup date: none
+No signatures found, switching to full backup.
+--------------[ Backup Statistics ]--------------
+StartTime 1661752359.77 (Mon Aug 29 05:52:39 2022)
+EndTime 1661752362.69 (Mon Aug 29 05:52:42 2022)
+ElapsedTime 2.92 (2.92 seconds)
+SourceFiles 582
+SourceFileSize 49793026 (47.5 MB)
+NewFiles 582
+NewFileSize 49793026 (47.5 MB)
+DeletedFiles 0
+ChangedFiles 0
+ChangedFileSize 0 (0 bytes)
+ChangedDeltaSize 0 (0 bytes)
+DeltaEntries 582
+RawDeltaSize 49779683 (47.5 MB)
+TotalDestinationSizeChange 21135788 (20.2 MB)
+Errors 0
+```
+Note: Two different data sets cannot be taken as backup into the same location. So make sure when a data set different from the previous is taken as backup, choose a different storage location.
+
+### Verification of data integrity before restore
+We can verify whatever changes are made to our latest file system on comparing with a latest backup taken like below:
+```
+root@demo:/usr/bin# rm google-authenticator
+root@demo:~# duplicity verify --compare-data -v4 file:///usr/local/backup /usr/bin
+Last full backup date: Mon Aug 29 05:52:31 2022
+GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 05:56:13 2022, expected Mon Aug 29 03:54:07 2022
+Difference found: File google-authenticator is missing
+Verify complete: 582 files compared, 2 differences found.
+```
+
+#### Data Restore
+The files can be restored only after integrity verification as shown above so that the user will specifically know which files or directories have to be restored due to an unwanted change or deletion in the file system.
+
+```
+root@demo:~# duplicity --file-to-restore google-authenticator file:///usr/local/backup /usr/bin/google-authenticator
+```
+Situation : If a directory containing 1000 files has around 250 files deleted and around 100 files modified. In that case it is not user friendly for the user to individually restore such a huge list of modified files to restore. Duplicity will not allow overwrite of remaining files in the directory so in that case the only possible solution is to delete the entire directory and restore it from the backup.
+
+The --file-to-restore switch should be removed if the user wants to restore a complete directory like shown below.
+```
+root@demo:~# duplicity file:///usr/local/backup /usr/bin/
+```
+
+### Listing all the files in the backup
+To check all the contents of a backup do as shown below:
+```
+root@demo:~# duplicity list-current-files file:///usr/local/backup
+Local and Remote metadata are synchronized, no sync needed.
+Last full backup date: Mon Aug 29 05:52:31 2022
+Mon Aug 29 03:54:07 2022 .
+Mon Aug 29 03:52:37 2022 Mail
+Thu Sep 24 08:36:09 2020 [
+Thu Jan 20 20:10:35 2022 addpart
+Sun Jan 16 12:36:56 2022 aide
+Thu Jun 10 08:53:34 2021 apt
+Thu Jun 10 08:53:34 2021 apt-cache
+Thu Jun 10 08:53:34 2021 apt-cdrom
+Thu Jun 10 08:53:34 2021 apt-config
+...
+```
+
+# Remote Backup & Restore
+### Setting up the environment on remote server
+In the Local server, generate a pair of RSA keys that will be used for authentication during remote backup.
+```
+root@demo:~# ssh-keygen -t rsa -b 2048 -N "" -f /root/.ssh/id_rsa
+root@demo:~# ssh-copy-id -i ~/.ssh/id_rsa remoteuser@remoteserver-ip
+```
+
+Create a directory in remote server for keeping the backup files
+```
+root@demo:~# ssh remoteuser@remoteserver mkdir -p sftp_remote_bk_testing/first_backup
+```
+
+### Generation of GPG keys for encryption of data
+Create a file name gen-key-script and add the parameters like below:
+```
+root@demo:~# cat >foo <<EOF
+ Key-Type: DSA
+ Key-Length: 1024
+ Subkey-Type: ELG-E
+ Subkey-Length: 1024
+ Name-Real: username
+ Name-Email: usermailID
+ Expire-Date: 0
+ # passphrase should be more than 8 characters
+ Passphrase: 123456789
+EOF
+root@demo:~# gpg --batch --gen-key foo
+gpg: Generating a basic OpenPGP key
+gpg: key AE57464HFG4 marked as ultimately trusted
+gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/E4C84C97B37BB24947E4522DA4B60C25738850E9.rev'
+```
+Use the encrypted key generated as above command and the encrypt key is AE57464HFG4 in the remote backup.
+
+### Remote Backup
+```
+root@demo:~# duplicity --encrypt-key "AE57464HFG4" /usr/bin sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+```
+Find the backed up files in the remote location using the below command
+```
+root@demo:~# ssh remoteuser@remoteserver ls /home/remoteuser/sftp_remote_bk_testing/first_backup
+- duplicity-full.20220829T070950Z.manifest.gpg
+- duplicity-full.20220829T070950Z.vol1.difftar.gpg
+- duplicity-full-signatures.20220829T070950Z.sigtar.gpg
+```
+
+### Verification of integrity after recent backup in remote server
+```
+root@demo:~# duplicity verify --encrypt-key "AE57464HFG4" --compare-data sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin
+Local and Remote metadata are synchronized, no sync needed.5CAE2A504" --compare-data sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin
+Last full backup date: Mon Aug 29 07:09:50 2022
+GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 07:14:15 2022, expected Mon Aug 29 06:00:22 2022
+Difference found: File google-authenticator is missing
+Verify complete: 582 files compared, 2 differences found.
+```
+
+#### Restoration of data from remote server
+```
+root@demo:~# duplicity --file-to-restore google-authenticator sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin/google-authenticator
+```
+
+# Automatic Backup scheduling using cron service
+To avoid operator overhead to regularly take system backup, it is necessary to automate the backup so that the data backup will be **up-to-date**.
+
+While automating this backup process, it is suggestible to use remote backup based on space issue.
+
+Below a simple script which shall be added in the crontab to run on a daily basis.
+
+```
+#!/bin/bash
+echo "This will execute the backup on the first minute, first hour , every day"
+export PASSPHRASE=12345678
+duplicity --encrypt-key "AE57464HFG4" /usr/bin sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+unset PASSPHRASE
+```
+
+In this demo script, the /usr/bin is being taken as a backup. The user can replace based on the requirement.
+The passphrase should also match the one assigned by the user during GPG keys creation.
+
+Save the file (daily_backup.sh) in a known path and start the cron service.
+```
+root@demo:~# systemctl start cron
+```
+Check the status of the service (expected to be in running state)
+```
+root@demo:~# systemctl status cron
+● cron.service - Regular background program processing daemon
+ Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
+ Active: active (running) since Mon 2022-08-29 12:11:25 UTC; 12min ago
+```
+Open the crontab
+```
+root@demo:~# crontab -e
+```
+Add the below line at the end of the crontab file if the user needs a backup on daily basis onto the remote server.
+```
+0 0 * * * /root/daily_backup.sh
+```
+After saving the crontab, the below message should be displayed.
+**crontab: installing new crontab**
+The user can verify this automation by checking the contents of the remote backup folder regularly.
--
2.20.1


[isar-cip-core 0/2] Patches to meet IEC CR 7.3

sai.sathujoda@...
 

From: Sai <Sai.Sathujoda@...>

These patches contain the packages to add in the IEC security layer to
meet CR 7.3 and the manual to use the package to fulfill the requirement.

Sai (2):
README.control-system-backup.md: Add steps to explain control system
backup
cip-core-image-security.bb: Add duplicity package to enable IEC
requirement

doc/README.control-system-backup.md | 194 ++++++++++++++++++
.../images/cip-core-image-security.bb | 1 +
2 files changed, 195 insertions(+)
create mode 100644 doc/README.control-system-backup.md

--
2.20.1


Re: [isar-cip-core 2/2] README.control-system-backup.md : Add steps to explain control system backup

sai.sathujoda@...
 

Hi Jan,

Please ignore below patch series , it has merge conflicts. I will resolve and re-send the patch series again.
Sorry for the confusion.

Regards,
Sai Ashrith

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of sai.sathujoda@...
Sent: Friday, September 9, 2022 12:34 PM
To: cip-dev@...; jan.kiszka@...
Cc: ashrith sai(TSIP) <Sai.Sathujoda@...>; dinesh kumar(TSIP TMIEC ODG Porting) <dinesh.kumar@...>; hayashi kazuhiro(林 和宏 □SWC◯ACT) <kazuhiro3.hayashi@...>
Subject: [cip-dev] [isar-cip-core 2/2] README.control-system-backup.md : Add steps to explain control system backup

From: Sai <Sai.Sathujoda@...>

Control system backup is an IEC security requirement to backup critical systems for disaster recovery and system migration program.

Signed-off-by: Sai <Sai.Sathujoda@...>
---
doc/README.control-system-backup.md | 214 ++++++++++++++++++++++++++++
1 file changed, 214 insertions(+)
create mode 100644 doc/README.control-system-backup.md

diff --git a/doc/README.control-system-backup.md b/doc/README.control-system-backup.md
new file mode 100644
index 0000000..ea8b761
--- /dev/null
+++ b/doc/README.control-system-backup.md
@@ -0,0 +1,214 @@
+# Overview
+This document explains how to take system-level backup, verify integrity, and restore the backup file. It also mentions the demonstration which has to be carried out using **duplicity** to perform both local and remote backups.
+
+<<<<<<< HEAD
+There is always a chance for the data to get corrupted or lost due to some unknown reasons. In those situations, system level backup is helpful so that if any data is lost then it can be restored back.
+=======
+# Description
+There is always a chance for the data to get corrupted or lost due to some unknown reasons. In those situations, system level backup is helpful so that if any data is lost then it can restored back.
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+If there is a lot of space available in the system then **Local backup** can be considered. But in some cases space will not be enough if we opt for daily backup. In that situation, it is better to choose remote backup where all the data in the system will be stored on a remote server.
+
+**Duplicity** provides facilities like system-level backup, encryption of the data taken as a backup, verification of data integrity before restore and finally the restoration of the data from the backup.
+
+# Pre-Requisites
+<<<<<<< HEAD
+
+1. Build the CIP security image which includes **duplicity** package as described in the [README.security-testing.md](./README.security-testing.md).
+2. Add additional storage in case of local backup like below in **/kas/opt/security.yml** file.
+```
+local_conf_header:
+ security_image_size: |
+ ROOTFS_EXTRA = "8192"
+```
+=======
+1. CIP security image which includes **duplicity** package, to build the image follow the steps described in the [README.security-testing.md](./README.security-testing.md#build-cip-security-linux-image).
+2. Additional storage in case of local backups or increase the rootfs size by adding the below lines in **/kas/opt/security.yml** file.
+ ```
+ local_conf_header:
+ security_image_size: |
+ ROOTFS_EXTRA = "8192"
+ ```
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+3. Remote machine with Linux OS to store remote backups.
+
+# Local Backup & Restore
+For the first backup taken it will be a **full backup** but after that it will be incremental backups. If full backups are to be taken explicitly then add "full" in the command.
+
+The user can choose the data needed to be taken as backup. For example, in the below command /usr/bin directory is taken as backup in the /usr/local/backup location locally.
+Note: PASSPHRASE should be more than 8 characters.
+```
+root@demo:~# export PASSPHRASE=12345678 root@demo:~# duplicity /usr/bin
+file:///usr/local/backup Local and Remote metadata are synchronized, no
+sync needed.
+Last full backup date: none
+No signatures found, switching to full backup.
+--------------[ Backup Statistics ]-------------- StartTime
+1661752359.77 (Mon Aug 29 05:52:39 2022) EndTime 1661752362.69 (Mon Aug
+29 05:52:42 2022) ElapsedTime 2.92 (2.92 seconds) SourceFiles 582
+SourceFileSize 49793026 (47.5 MB) NewFiles 582 NewFileSize 49793026
+(47.5 MB) DeletedFiles 0 ChangedFiles 0 ChangedFileSize 0 (0 bytes)
+ChangedDeltaSize 0 (0 bytes) DeltaEntries 582 RawDeltaSize 49779683
+(47.5 MB) TotalDestinationSizeChange 21135788 (20.2 MB) Errors 0 ```
+Note: Two different data sets cannot be taken as backup into the same location. So make sure when a data set different from the previous is taken as backup, choose a different storage location.
+
+### Verification of data integrity before restore We can verify
+whatever changes are made to our latest file system on comparing with a latest backup taken like below:
+```
+root@demo:/usr/bin# rm google-authenticator root@demo:~# duplicity
+verify --compare-data -v4 file:///usr/local/backup /usr/bin Last full
+backup date: Mon Aug 29 05:52:31 2022 GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 05:56:13 2022, expected
+Mon Aug 29 03:54:07 2022 Difference found: File google-authenticator is
+missing Verify complete: 582 files compared, 2 differences found.
+```
+<<<<<<< HEAD
+#### Data Restore
+The files can be restored only after integrity verification as shown above so that the user will specifically know which files or directories have to be restored due to an unwanted change or deletion in the file system.
+=======
+
+### Data Restore
+The files can be restored only after integrity verification as shown above so that the user will specifically know which files or directories have to restored due to an unwanted change or deletion in the file system.
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+
+```
+root@demo:~# duplicity --file-to-restore google-authenticator
+file:///usr/local/backup /usr/bin/google-authenticator ``` Situation :
+If a directory containing 1000 files has around 250 files deleted and around 100 files unwantedly modified. In that case it is not user friendly for the user to individually restore such a huge list of modified files to restore. Duplicity will not allow overwrite of remaining files in the directory so in that case the only possible solution is to delete the entire directory and restore it from the backup.
+
+The --file-to-restore switch should be removed if the user wants to restore a complete directory like shown below.
+```
+root@demo:~# duplicity file:///usr/local/backup /usr/bin/ ```
+
+### Listing all the files in the backup To check all the contents of a
+backup do as shown below:
+```
+root@demo:~# duplicity list-current-files file:///usr/local/backup
+Local and Remote metadata are synchronized, no sync needed.
+Last full backup date: Mon Aug 29 05:52:31 2022 Mon Aug 29 03:54:07
+2022 .
+Mon Aug 29 03:52:37 2022 Mail
+Thu Sep 24 08:36:09 2020 [
+Thu Jan 20 20:10:35 2022 addpart
+Sun Jan 16 12:36:56 2022 aide
+Thu Jun 10 08:53:34 2021 apt
+Thu Jun 10 08:53:34 2021 apt-cache
+Thu Jun 10 08:53:34 2021 apt-cdrom
+Thu Jun 10 08:53:34 2021 apt-config
+...
+```
+
+# Remote Backup & Restore
+### Setting up the environment on remote server In the Local server,
+generate a pair of RSA keys that will be used for authentication during remote backup.
+```
+root@demo:~# ssh-keygen -t rsa -b 2048 -N "" -f /root/.ssh/id_rsa
+root@demo:~# ssh-copy-id -i ~/.ssh/id_rsa remoteuser@remoteserver-ip
+```
+
+Create a directory in remote server for keeping the backup files ```
+root@demo:~# ssh remoteuser@remoteserver mkdir -p
+sftp_remote_bk_testing/first_backup
+```
+
+### Generation of GPG keys for encryption of data Create a file name
+gen-key-script and add the parameters like below:
+```
+root@demo:~# cat >foo <<EOF
+ Key-Type: DSA
+ Key-Length: 1024
+ Subkey-Type: ELG-E
+ Subkey-Length: 1024
+ Name-Real: username
+ Name-Email: usermailID
+ Expire-Date: 0
+ # passphrase should be more than 8 characters
+ Passphrase: 123456789
+EOF
+root@demo:~# gpg --batch --gen-key foo
+gpg: Generating a basic OpenPGP key
+gpg: key AE57464HFG4 marked as ultimately trusted
+gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/E4C84C97B37BB24947E4522DA4B60C25738850E9.rev'
+```
+Use the encrypted key generated as above command and the encrypt key is AE57464HFG4 in the remote backup.
+
+### Remote Backup
+```
+root@demo:~# duplicity --encrypt-key "AE57464HFG4" /usr/bin
+sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+```
+Find the backed up files in the remote location using the below command
+``` root@demo:~# ssh remoteuser@remoteserver ls
+/home/remoteuser/sftp_remote_bk_testing/first_backup
+- duplicity-full.20220829T070950Z.manifest.gpg
+- duplicity-full.20220829T070950Z.vol1.difftar.gpg
+- duplicity-full-signatures.20220829T070950Z.sigtar.gpg
+```
+
+### Verification of integrity after recent backup in remote server ```
+root@demo:~# duplicity verify --encrypt-key "AE57464HFG4"
+--compare-data
+sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+/usr/bin Local and Remote metadata are synchronized, no sync needed.5CAE2A504" --compare-data sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin Last full backup date: Mon Aug 29 07:09:50 2022 GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 07:14:15 2022, expected
+Mon Aug 29 06:00:22 2022 Difference found: File google-authenticator is
+missing Verify complete: 582 files compared, 2 differences found.
+```
+
+#### Restoration of data from remote server ``` root@demo:~# duplicity
+--file-to-restore google-authenticator
+sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+/usr/bin/google-authenticator ```
+
+# Automatic Backup scheduling using cron service To avoid operator
+overhead to regularly take system backup, it is necessary to automate the backup so that the data backup will be **up-to-date**.
+
+While automating this backup process, it is suggestible to use remote backup based on space issue.
+
+Below a simple script which shall be added in the crontab to run on a daily basis.
+
+```
+#!/bin/bash
+echo "This will execute the backup on the first minute, first hour , every day"
+export PASSPHRASE=12345678
+duplicity --encrypt-key "AE57464HFG4" /usr/bin
+sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+unset PASSPHRASE
+```
+
+In this demo script, the /usr/bin is being taken as a backup. The user can replace based on the requirement.
+The passphrase should also match the one assigned by the user during GPG keys creation.
+
+Save the file (daily_backup.sh) in a known path and start the cron service.
+```
+root@demo:~# systemctl start cron
+```
+Check the status of the service (expected to be in running state) ```
+root@demo:~# systemctl status cron ● cron.service - Regular background
+program processing daemon
+ Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
+ Active: active (running) since Mon 2022-08-29 12:11:25 UTC; 12min
+ago ``` Open the crontab ``` root@demo:~# crontab -e ``` Add the below
+line at the end of the crontab file if the user needs a backup on daily basis onto the remote server.
+```
+0 0 * * * /root/daily_backup.sh
+```
+After saving the crontab, the below message should be displayed.
+**crontab: installing new crontab**
+The user can verify this automation by checking the contents of the remote backup folder regularly.
--
2.20.1


[isar-cip-core 2/2] README.control-system-backup.md : Add steps to explain control system backup

sai.sathujoda@...
 

From: Sai <Sai.Sathujoda@...>

Control system backup is an IEC security requirement to backup critical
systems for disaster recovery and system migration program.

Signed-off-by: Sai <Sai.Sathujoda@...>
---
doc/README.control-system-backup.md | 214 ++++++++++++++++++++++++++++
1 file changed, 214 insertions(+)
create mode 100644 doc/README.control-system-backup.md

diff --git a/doc/README.control-system-backup.md b/doc/README.control-system-backup.md
new file mode 100644
index 0000000..ea8b761
--- /dev/null
+++ b/doc/README.control-system-backup.md
@@ -0,0 +1,214 @@
+# Overview
+This document explains how to take system-level backup, verify integrity, and restore the backup file. It also mentions the demonstration which has to be carried out using **duplicity** to perform both local and remote backups.
+
+<<<<<<< HEAD
+There is always a chance for the data to get corrupted or lost due to some unknown reasons. In those situations, system level backup is helpful so that if any data is lost then it can be restored back.
+=======
+# Description
+There is always a chance for the data to get corrupted or lost due to some unknown reasons. In those situations, system level backup is helpful so that if any data is lost then it can restored back.
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+If there is a lot of space available in the system then **Local backup** can be considered. But in some cases space will not be enough if we opt for daily backup. In that situation, it is better to choose remote backup where all the data in the system will be stored on a remote server.
+
+**Duplicity** provides facilities like system-level backup, encryption of the data taken as a backup, verification of data integrity before restore and finally the restoration of the data from the backup.
+
+# Pre-Requisites
+<<<<<<< HEAD
+
+1. Build the CIP security image which includes **duplicity** package as described in the [README.security-testing.md](./README.security-testing.md).
+2. Add additional storage in case of local backup like below in **/kas/opt/security.yml** file.
+```
+local_conf_header:
+ security_image_size: |
+ ROOTFS_EXTRA = "8192"
+```
+=======
+1. CIP security image which includes **duplicity** package, to build the image follow the steps described in the [README.security-testing.md](./README.security-testing.md#build-cip-security-linux-image).
+2. Additional storage in case of local backups or increase the rootfs size by adding the below lines in **/kas/opt/security.yml** file.
+ ```
+ local_conf_header:
+ security_image_size: |
+ ROOTFS_EXTRA = "8192"
+ ```
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+3. Remote machine with Linux OS to store remote backups.
+
+# Local Backup & Restore
+For the first backup taken it will be a **full backup** but after that it will be incremental backups. If full backups are to be taken explicitly then add "full" in the command.
+
+The user can choose the data needed to be taken as backup. For example, in the below command /usr/bin directory is taken as backup in the /usr/local/backup location locally.
+Note: PASSPHRASE should be more than 8 characters.
+```
+root@demo:~# export PASSPHRASE=12345678
+root@demo:~# duplicity /usr/bin file:///usr/local/backup
+Local and Remote metadata are synchronized, no sync needed.
+Last full backup date: none
+No signatures found, switching to full backup.
+--------------[ Backup Statistics ]--------------
+StartTime 1661752359.77 (Mon Aug 29 05:52:39 2022)
+EndTime 1661752362.69 (Mon Aug 29 05:52:42 2022)
+ElapsedTime 2.92 (2.92 seconds)
+SourceFiles 582
+SourceFileSize 49793026 (47.5 MB)
+NewFiles 582
+NewFileSize 49793026 (47.5 MB)
+DeletedFiles 0
+ChangedFiles 0
+ChangedFileSize 0 (0 bytes)
+ChangedDeltaSize 0 (0 bytes)
+DeltaEntries 582
+RawDeltaSize 49779683 (47.5 MB)
+TotalDestinationSizeChange 21135788 (20.2 MB)
+Errors 0
+```
+Note: Two different data sets cannot be taken as backup into the same location. So make sure when a data set different from the previous is taken as backup, choose a different storage location.
+
+### Verification of data integrity before restore
+We can verify whatever changes are made to our latest file system on comparing with a latest backup taken like below:
+```
+root@demo:/usr/bin# rm google-authenticator
+root@demo:~# duplicity verify --compare-data -v4 file:///usr/local/backup /usr/bin
+Last full backup date: Mon Aug 29 05:52:31 2022
+GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 05:56:13 2022, expected Mon Aug 29 03:54:07 2022
+Difference found: File google-authenticator is missing
+Verify complete: 582 files compared, 2 differences found.
+```
+<<<<<<< HEAD
+#### Data Restore
+The files can be restored only after integrity verification as shown above so that the user will specifically know which files or directories have to be restored due to an unwanted change or deletion in the file system.
+=======
+
+### Data Restore
+The files can be restored only after integrity verification as shown above so that the user will specifically know which files or directories have to restored due to an unwanted change or deletion in the file system.
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+
+```
+root@demo:~# duplicity --file-to-restore google-authenticator file:///usr/local/backup /usr/bin/google-authenticator
+```
+Situation : If a directory containing 1000 files has around 250 files deleted and around 100 files unwantedly modified. In that case it is not user friendly for the user to individually restore such a huge list of modified files to restore. Duplicity will not allow overwrite of remaining files in the directory so in that case the only possible solution is to delete the entire directory and restore it from the backup.
+
+The --file-to-restore switch should be removed if the user wants to restore a complete directory like shown below.
+```
+root@demo:~# duplicity file:///usr/local/backup /usr/bin/
+```
+
+### Listing all the files in the backup
+To check all the contents of a backup do as shown below:
+```
+root@demo:~# duplicity list-current-files file:///usr/local/backup
+Local and Remote metadata are synchronized, no sync needed.
+Last full backup date: Mon Aug 29 05:52:31 2022
+Mon Aug 29 03:54:07 2022 .
+Mon Aug 29 03:52:37 2022 Mail
+Thu Sep 24 08:36:09 2020 [
+Thu Jan 20 20:10:35 2022 addpart
+Sun Jan 16 12:36:56 2022 aide
+Thu Jun 10 08:53:34 2021 apt
+Thu Jun 10 08:53:34 2021 apt-cache
+Thu Jun 10 08:53:34 2021 apt-cdrom
+Thu Jun 10 08:53:34 2021 apt-config
+...
+```
+
+# Remote Backup & Restore
+### Setting up the environment on remote server
+In the Local server, generate a pair of RSA keys that will be used for authentication during remote backup.
+```
+root@demo:~# ssh-keygen -t rsa -b 2048 -N "" -f /root/.ssh/id_rsa
+root@demo:~# ssh-copy-id -i ~/.ssh/id_rsa remoteuser@remoteserver-ip
+```
+
+Create a directory in remote server for keeping the backup files
+```
+root@demo:~# ssh remoteuser@remoteserver mkdir -p sftp_remote_bk_testing/first_backup
+```
+
+### Generation of GPG keys for encryption of data
+Create a file name gen-key-script and add the parameters like below:
+```
+root@demo:~# cat >foo <<EOF
+ Key-Type: DSA
+ Key-Length: 1024
+ Subkey-Type: ELG-E
+ Subkey-Length: 1024
+ Name-Real: username
+ Name-Email: usermailID
+ Expire-Date: 0
+ # passphrase should be more than 8 characters
+ Passphrase: 123456789
+EOF
+root@demo:~# gpg --batch --gen-key foo
+gpg: Generating a basic OpenPGP key
+gpg: key AE57464HFG4 marked as ultimately trusted
+gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/E4C84C97B37BB24947E4522DA4B60C25738850E9.rev'
+```
+Use the encrypted key generated as above command and the encrypt key is AE57464HFG4 in the remote backup.
+
+### Remote Backup
+```
+root@demo:~# duplicity --encrypt-key "AE57464HFG4" /usr/bin sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+```
+Find the backed up files in the remote location using the below command
+```
+root@demo:~# ssh remoteuser@remoteserver ls /home/remoteuser/sftp_remote_bk_testing/first_backup
+- duplicity-full.20220829T070950Z.manifest.gpg
+- duplicity-full.20220829T070950Z.vol1.difftar.gpg
+- duplicity-full-signatures.20220829T070950Z.sigtar.gpg
+```
+
+### Verification of integrity after recent backup in remote server
+```
+root@demo:~# duplicity verify --encrypt-key "AE57464HFG4" --compare-data sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin
+Local and Remote metadata are synchronized, no sync needed.5CAE2A504" --compare-data sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin
+Last full backup date: Mon Aug 29 07:09:50 2022
+GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 07:14:15 2022, expected Mon Aug 29 06:00:22 2022
+Difference found: File google-authenticator is missing
+Verify complete: 582 files compared, 2 differences found.
+```
+
+#### Restoration of data from remote server
+```
+root@demo:~# duplicity --file-to-restore google-authenticator sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin/google-authenticator
+```
+
+# Automatic Backup scheduling using cron service
+To avoid operator overhead to regularly take system backup, it is necessary to automate the backup so that the data backup will be **up-to-date**.
+
+While automating this backup process, it is suggestible to use remote backup based on space issue.
+
+Below a simple script which shall be added in the crontab to run on a daily basis.
+
+```
+#!/bin/bash
+echo "This will execute the backup on the first minute, first hour , every day"
+export PASSPHRASE=12345678
+duplicity --encrypt-key "AE57464HFG4" /usr/bin sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+unset PASSPHRASE
+```
+
+In this demo script, the /usr/bin is being taken as a backup. The user can replace based on the requirement.
+The passphrase should also match the one assigned by the user during GPG keys creation.
+
+Save the file (daily_backup.sh) in a known path and start the cron service.
+```
+root@demo:~# systemctl start cron
+```
+Check the status of the service (expected to be in running state)
+```
+root@demo:~# systemctl status cron
+● cron.service - Regular background program processing daemon
+ Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
+ Active: active (running) since Mon 2022-08-29 12:11:25 UTC; 12min ago
+```
+Open the crontab
+```
+root@demo:~# crontab -e
+```
+Add the below line at the end of the crontab file if the user needs a backup on daily basis onto the remote server.
+```
+0 0 * * * /root/daily_backup.sh
+```
+After saving the crontab, the below message should be displayed.
+**crontab: installing new crontab**
+The user can verify this automation by checking the contents of the remote backup folder regularly.
--
2.20.1

81 - 100 of 9573