Date   

[isar-cip-core RFC 0/4] A/B Rootfs update with software update

Quirin Gylstorff
 

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

This patchset adds efibootguard, swupdate to allow A/B updates in
cip-core. The update mechanism is currently only implemented for x86_64.


Quirin Gylstorff (4):
recipes-bsp: Add efibootguard
patches: add libubootenv
recipes-core: add swupdate
wic: Add wks files for A/B Partition update

classes/kconfig-snippets.bbclass | 90 ++++
classes/swupdate-config.bbclass | 76 +++
classes/swupdate-img.bbclass | 75 +++
.../0001-u-boot-add-libubootenv.patch | 169 +++++++
kas/cip.yml | 4 +
kas/opt/ebg-swu.yml | 26 +
.../efibootguard/efibootguard_0.6-git+isar.bb | 46 ++
recipes-bsp/efibootguard/files/debian/compat | 1 +
.../efibootguard/files/debian/control.tmpl | 20 +
.../files/debian/efibootguard-dev.install | 3 +
.../files/debian/efibootguard.install | 2 +
recipes-bsp/efibootguard/files/debian/rules | 21 +
.../swupdate/files/debian/changelog.tmpl | 6 +
recipes-core/swupdate/files/debian/compat | 1 +
.../swupdate/files/debian/control.tmpl | 15 +
recipes-core/swupdate/files/debian/copyright | 36 ++
recipes-core/swupdate/files/debian/rules.tmpl | 30 ++
.../swupdate/files/debian/swupdate.examples | 2 +
.../swupdate/files/debian/swupdate.install | 2 +
.../swupdate/files/debian/swupdate.manpages | 5 +
.../swupdate/files/debian/swupdate.tmpfile | 2 +
recipes-core/swupdate/files/debian/watch | 12 +
recipes-core/swupdate/files/postinst | 2 +
recipes-core/swupdate/files/swupdate.cfg | 6 +
.../swupdate/files/swupdate.service.example | 11 +
.../swupdate/files/swupdate.socket.example | 11 +
.../swupdate/files/swupdate.socket.tmpl | 13 +
.../swupdate/files/swupdate_defconfig | 83 ++++
.../swupdate_defconfig_efibootguard.snippet | 3 +
.../files/swupdate_defconfig_lua.snippet | 2 +
.../swupdate_defconfig_luahandler.snippet | 4 +
.../files/swupdate_defconfig_mtd.snippet | 1 +
.../files/swupdate_defconfig_u-boot.snippet | 3 +
.../files/swupdate_defconfig_ubi.snippet | 6 +
.../swupdate/files/swupdate_handlers.lua | 449 ++++++++++++++++++
recipes-core/swupdate/swupdate.bb | 54 +++
.../wic/plugins/source/efibootguard-boot.py | 162 +++++++
.../wic/plugins/source/efibootguard-efi.py | 102 ++++
wic/ebg-sysparts.inc | 8 +
wic/qemu-amd64-efibootguard.wks | 5 +
wic/simatic-ipc227e-efibootguard.wks | 5 +
wic/swupdate-partition.inc | 4 +
42 files changed, 1578 insertions(+)
create mode 100644 classes/kconfig-snippets.bbclass
create mode 100644 classes/swupdate-config.bbclass
create mode 100644 classes/swupdate-img.bbclass
create mode 100644 isar-patches/0001-u-boot-add-libubootenv.patch
create mode 100644 kas/opt/ebg-swu.yml
create mode 100644 recipes-bsp/efibootguard/efibootguard_0.6-git+isar.bb
create mode 100644 recipes-bsp/efibootguard/files/debian/compat
create mode 100644 recipes-bsp/efibootguard/files/debian/control.tmpl
create mode 100644 recipes-bsp/efibootguard/files/debian/efibootguard-dev.install
create mode 100644 recipes-bsp/efibootguard/files/debian/efibootguard.install
create mode 100755 recipes-bsp/efibootguard/files/debian/rules
create mode 100644 recipes-core/swupdate/files/debian/changelog.tmpl
create mode 100644 recipes-core/swupdate/files/debian/compat
create mode 100644 recipes-core/swupdate/files/debian/control.tmpl
create mode 100644 recipes-core/swupdate/files/debian/copyright
create mode 100755 recipes-core/swupdate/files/debian/rules.tmpl
create mode 100644 recipes-core/swupdate/files/debian/swupdate.examples
create mode 100644 recipes-core/swupdate/files/debian/swupdate.install
create mode 100644 recipes-core/swupdate/files/debian/swupdate.manpages
create mode 100644 recipes-core/swupdate/files/debian/swupdate.tmpfile
create mode 100644 recipes-core/swupdate/files/debian/watch
create mode 100644 recipes-core/swupdate/files/postinst
create mode 100644 recipes-core/swupdate/files/swupdate.cfg
create mode 100644 recipes-core/swupdate/files/swupdate.service.example
create mode 100644 recipes-core/swupdate/files/swupdate.socket.example
create mode 100644 recipes-core/swupdate/files/swupdate.socket.tmpl
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_efibootguard.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_lua.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_luahandler.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_mtd.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_u-boot.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_ubi.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_handlers.lua
create mode 100644 recipes-core/swupdate/swupdate.bb
create mode 100644 scripts/lib/wic/plugins/source/efibootguard-boot.py
create mode 100644 scripts/lib/wic/plugins/source/efibootguard-efi.py
create mode 100644 wic/ebg-sysparts.inc
create mode 100644 wic/qemu-amd64-efibootguard.wks
create mode 100644 wic/simatic-ipc227e-efibootguard.wks
create mode 100644 wic/swupdate-partition.inc

--
2.20.1


[isar-cip-core PATCH 1/2] update ISAR

Quirin Gylstorff
 

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

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
conf/machine/hihope-rzg2m.conf | 4 +-
conf/machine/iwg20m.conf | 4 +-
...d-path-to-image-for-arm-kernels-4.12.patch | 37 -------------------
kas.yml | 7 +---
4 files changed, 5 insertions(+), 47 deletions(-)
delete mode 100644 isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch

diff --git a/conf/machine/hihope-rzg2m.conf b/conf/machine/hihope-rzg2m.conf
index 8278205..a2ae03d 100644
--- a/conf/machine/hihope-rzg2m.conf
+++ b/conf/machine/hihope-rzg2m.conf
@@ -15,5 +15,5 @@ IMAGE_TYPE ?= "wic-img"

KERNEL_DEFCONFIG = "cip-kernel-config/4.19.y-cip/arm64/renesas_defconfig"
USE_CIP_KERNEL_CONFIG = "1"
-DTB_FILE = "r8a774a1-hihope-rzg2m-ex.dtb"
-IMAGE_BOOT_FILES = "${KERNEL_IMAGE} ${DTB_FILE}"
+DTB_FILES = "r8a774a1-hihope-rzg2m-ex.dtb"
+IMAGE_BOOT_FILES = "${KERNEL_IMAGE} ${DTB_FILES}"
diff --git a/conf/machine/iwg20m.conf b/conf/machine/iwg20m.conf
index 37f98fa..91bfd94 100644
--- a/conf/machine/iwg20m.conf
+++ b/conf/machine/iwg20m.conf
@@ -21,6 +21,6 @@ USE_CIP_KERNEL_CONFIG = "1"
KERNEL_DEFCONFIG = "cip-kernel-config/4.4.y-cip/arm/renesas_shmobile_defconfig"

# Boot partition files
-DTB_FILE = "r8a7743-iwg20d-q7-dbcm-ca.dtb"
+DTB_FILES = "r8a7743-iwg20d-q7-dbcm-ca.dtb"
KERNEL_IMAGE="zImage"
-IMAGE_BOOT_FILES = "${KERNEL_IMAGE} ${DTB_FILE}"
+IMAGE_BOOT_FILES = "${KERNEL_IMAGE} ${DTB_FILES}"
diff --git a/isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch b/isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch
deleted file mode 100644
index 3e4e13e..0000000
--- a/isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-From 4961476f3affabd2bfb8f12ccc86c0abc6a66200 Mon Sep 17 00:00:00 2001
-From: Quirin Gylstorff <quirin.gylstorff@...>
-Date: Wed, 8 Jan 2020 14:43:01 +0100
-Subject: [PATCH] linux-custom: add path to image for arm* kernels < 4.12
-To: isar-users@...
-
-ARM/ARM64 Kernel with a version < 4.12 do not contain the path to
-the kernel image in image_name. This was added with commits:
-152e6744ebfc8fa6cc9fff4ba36271f5f1ba2821 for arm and
-06995804b5762f016c7a80503406da853a8f3785 for arm64.
-
-Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
----
- meta/recipes-kernel/linux/files/debian/isar/install.tmpl | 7 ++++++-
- 1 file changed, 6 insertions(+), 1 deletion(-)
-
-diff --git a/meta/recipes-kernel/linux/files/debian/isar/install.tmpl b/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
-index 67b7ce3..ac347aa 100644
---- a/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
-+++ b/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
-@@ -56,7 +56,12 @@ EOF
-
- install_image() {
- install -m 755 -d ${deb_img_dir}/$(dirname ${kimage_path})
-- cp ${O}/${kimage} ${deb_img_dir}/${kimage_path}
-+ # ARM/ARM64 kernels < 4.12 do not include the path to the kernel
-+ if [ -e ${O}/${kimage} ]; then
-+ cp ${O}/${kimage} ${deb_img_dir}/${kimage_path}
-+ else
-+ cp ${O}/arch/$ARCH/boot/${kimage} ${deb_img_dir}/${kimage_path}
-+ fi
-
- # Make sure arm64 kernels are decompressed
- if [ "${ARCH}" = "arm64" ]; then
---
-2.20.1
-
diff --git a/kas.yml b/kas.yml
index a157dc9..019b31e 100644
--- a/kas.yml
+++ b/kas.yml
@@ -19,14 +19,9 @@ repos:

isar:
url: https://github.com/ilbers/isar.git
- refspec: 619d6d88ac8c745282fd16773d50a466567615b6
+ refspec: 351af175bc54a201c6f44307d4e998bd6c0afdb8
layers:
meta:
- patches:
- build-arm-with-4.4:
- path: isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch
- repo: cip-core
-

bblayers_conf_header:
standard: |
--
2.20.1


[isar-cip-core PATCH 0/2] Cleanup

Quirin Gylstorff
 

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

Move kas related files into folder kas for a cleaner repository root.
Update isar to remove patches folder for now

Quirin Gylstorff (2):
update ISAR
kas: Restructure kas files.

.gitlab-ci.yml | 8 ++--
README.md | 4 +-
conf/machine/hihope-rzg2m.conf | 4 +-
conf/machine/iwg20m.conf | 4 +-
...d-path-to-image-for-arm-kernels-4.12.patch | 37 -------------------
board-bbb.yml => kas/board/bbb.yml | 0
board-iwg20m.yml => kas/board/iwg20m.yml | 0
.../board/qemu-amd64.yml | 0
board-rzg2m.yml => kas/board/rzg2m.yml | 0
.../board/simatic-ipc227e.yml | 0
kas.yml => kas/cip.yml | 7 +---
opt-4.4.yml => kas/opt/4.4.yml | 0
opt-rt.yml => kas/opt/rt.yml | 0
opt-stretch.yml => kas/opt/stretch.yml | 0
opt-targz-img.yml => kas/opt/targz-img.yml | 0
15 files changed, 11 insertions(+), 53 deletions(-)
delete mode 100644 isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch
rename board-bbb.yml => kas/board/bbb.yml (100%)
rename board-iwg20m.yml => kas/board/iwg20m.yml (100%)
rename board-qemu-amd64.yml => kas/board/qemu-amd64.yml (100%)
rename board-rzg2m.yml => kas/board/rzg2m.yml (100%)
rename board-simatic-ipc227e.yml => kas/board/simatic-ipc227e.yml (100%)
rename kas.yml => kas/cip.yml (74%)
rename opt-4.4.yml => kas/opt/4.4.yml (100%)
rename opt-rt.yml => kas/opt/rt.yml (100%)
rename opt-stretch.yml => kas/opt/stretch.yml (100%)
rename opt-targz-img.yml => kas/opt/targz-img.yml (100%)

--
2.20.1


[isar-cip-core PATCH 2/2] kas: Restructure kas files.

Quirin Gylstorff
 

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

Create folder structure
kas -> general configuration
kas/board -> all supported boards
kas/opt -> all kas option files

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++--
board-bbb.yml => kas/board/bbb.yml | 0
board-iwg20m.yml => kas/board/iwg20m.yml | 0
board-qemu-amd64.yml => kas/board/qemu-amd64.yml | 0
board-rzg2m.yml => kas/board/rzg2m.yml | 0
.../board/simatic-ipc227e.yml | 0
kas.yml => kas/cip.yml | 0
opt-4.4.yml => kas/opt/4.4.yml | 0
opt-rt.yml => kas/opt/rt.yml | 0
opt-stretch.yml => kas/opt/stretch.yml | 0
opt-targz-img.yml => kas/opt/targz-img.yml | 0
12 files changed, 6 insertions(+), 6 deletions(-)
rename board-bbb.yml => kas/board/bbb.yml (100%)
rename board-iwg20m.yml => kas/board/iwg20m.yml (100%)
rename board-qemu-amd64.yml => kas/board/qemu-amd64.yml (100%)
rename board-rzg2m.yml => kas/board/rzg2m.yml (100%)
rename board-simatic-ipc227e.yml => kas/board/simatic-ipc227e.yml (100%)
rename kas.yml => kas/cip.yml (100%)
rename opt-4.4.yml => kas/opt/4.4.yml (100%)
rename opt-rt.yml => kas/opt/rt.yml (100%)
rename opt-stretch.yml => kas/opt/stretch.yml (100%)
rename opt-targz-img.yml => kas/opt/targz-img.yml (100%)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..564398d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas/cip.yml:kas/board/simatic-ipc227e.yml:kas/opt/rt.yml:kas/opt/targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e

- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas/cip.yml:kas/board/bbb.yml:kas/opt/rt.yml:kas/opt/targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas/cip.yml:kas/board/iwg20m.yml:kas/opt/rt.yml:kas/opt/targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas/cip.yml:kas/board/rzg2m.yml:kas/opt/rt.yml:kas/opt/targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..ebbdee4 100644
--- a/README.md
+++ b/README.md
@@ -21,11 +21,11 @@ start containers.
To build, e.g., the QEMU AMD64 target inside Docker, invoke kas-docker like
this:

- ./kas-docker --isar build kas.yml:board-qemu-amd64.yml
+ ./kas-docker --isar build kas/cip.yml:kas/board/qemu-amd64.yml

This image can be run using `start-qemu.sh x86`.

-The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
+The BeagleBone Black target is selected by `... kas/cip.yml:kas/board/bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.

diff --git a/board-bbb.yml b/kas/board/bbb.yml
similarity index 100%
rename from board-bbb.yml
rename to kas/board/bbb.yml
diff --git a/board-iwg20m.yml b/kas/board/iwg20m.yml
similarity index 100%
rename from board-iwg20m.yml
rename to kas/board/iwg20m.yml
diff --git a/board-qemu-amd64.yml b/kas/board/qemu-amd64.yml
similarity index 100%
rename from board-qemu-amd64.yml
rename to kas/board/qemu-amd64.yml
diff --git a/board-rzg2m.yml b/kas/board/rzg2m.yml
similarity index 100%
rename from board-rzg2m.yml
rename to kas/board/rzg2m.yml
diff --git a/board-simatic-ipc227e.yml b/kas/board/simatic-ipc227e.yml
similarity index 100%
rename from board-simatic-ipc227e.yml
rename to kas/board/simatic-ipc227e.yml
diff --git a/kas.yml b/kas/cip.yml
similarity index 100%
rename from kas.yml
rename to kas/cip.yml
diff --git a/opt-4.4.yml b/kas/opt/4.4.yml
similarity index 100%
rename from opt-4.4.yml
rename to kas/opt/4.4.yml
diff --git a/opt-rt.yml b/kas/opt/rt.yml
similarity index 100%
rename from opt-rt.yml
rename to kas/opt/rt.yml
diff --git a/opt-stretch.yml b/kas/opt/stretch.yml
similarity index 100%
rename from opt-stretch.yml
rename to kas/opt/stretch.yml
diff --git a/opt-targz-img.yml b/kas/opt/targz-img.yml
similarity index 100%
rename from opt-targz-img.yml
rename to kas/opt/targz-img.yml
--
2.20.1


Re: CIP IRC weekly meeting today

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

Hi, Pavel-san,

Not sure if I'll be able to make it today.
From last meeting, I have been reviewing patches for 4.19.129 and 4.19.130.
Thanks for your update.

Best regards,
--
M. Kudo


Re: CIP IRC weekly meeting today

Pavel Machek
 

Hi!

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=6&day=25&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
Not sure if I'll be able to make it today.

From last meeting, I have been reviewing patches for 4.19.129 and
4.19.130.

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


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=6&day=25&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/06/cip.2020-06-18-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Ask board owners to review reference platform configs to optimize backporting - masashi910
4. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - iwamatsu
5. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* 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: Share your suggestions for supporting session lock requirement in CIP

Dinesh Kumar
 

Hi Jan,

"lock" is documented as offical option for IdleAction:
https://www.freedesktop.org/software/systemd/man/logind.conf.html#IdleAction=
Yes that's right. So here the contradiction it is documented as working but in reality it is not working.
So we have already raised an issue at bugs.debian.org/cgi-bin/bugreport.cgi?bug=963135. So far there is no update.

We can discuss it further during today's CIP Core meeting if there is some free time.

Thanks & Regards,
Dinesh Kumar


-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 22 June 2020 12:22
To: Dinesh Kumar <Dinesh.Kumar@...>
Cc: cip-security@...; cip-dev@...
Subject: Re: [cip-dev] Share your suggestions for supporting session lock requirement in CIP

On 21.06.20 10:23, Dinesh Kumar wrote:
Hi Jan,

I have added my comments, please let me know your views.

Thanks & Regards,
Dinesh Kumar

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 16 June 2020 12:39
To: Dinesh Kumar <Dinesh.Kumar@...>
Cc: cip-security@...; cip-dev@...
Subject: Re: [cip-dev] Share your suggestions for supporting session
lock requirement in CIP

On 16.06.20 09:00, Dinesh Kumar wrote:
Hi Jan,

Thanks for your review comments.
Kindly refer my response and let me know your opinion.

Thanks & Regards,
Dinesh Kumar


-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 15 June 2020 12:52
To: cip-dev@...; Dinesh Kumar
<Dinesh.Kumar@...>
Cc: cip-security@...
Subject: Re: [cip-dev] Share your suggestions for supporting session
lock requirement in CIP

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?
Dinesh>>Yes, we can do that by using TMOUT. However, we were just trying if we can achieve session lock with some existing packages or minimal changes in CIP. But that does not seem to happen.
Our idea of sharing this detail here was if anyone can suggest achieving session lock with some Debian packages without any modifications in the packages.
TMOUT is our backup option.

CR2.6 Req-2 Remote session termination: Component should support
terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?
Dinesh>>Since idle_action=lock is disabled in current systemd code. We enabled with changes described in this email. Though it works but we are not sure about side effects.
But that mode is documented in systemd manuals - without any note that it's in fact off? Something does not match here yet. At least, it would be a documentation bug, but maybe also a chance to enhance the code and sell it upstream.
Dinesh>>It's not documented in systemd manuals as well, not even any note whether it has been intentionally kept off.
"lock" is documented as offical option for IdleAction:
https://www.freedesktop.org/software/systemd/man/logind.conf.html#IdleAction=

Jan



2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?
Dinesh>>It's sufficient but disabled.

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?
Dinesh>>We quickly checked physlock, it's better alternate to vlock. But first we have to decide systemd changes, since vlock or physlock only work if systemd code changes are enabled.
OK. Still confused, though, because there is no mentioning of that somewhere. Unless I miss that. Is there any Debian bug? Or even an systemd issue?
Dinesh>>We searched Debian systemd bugs in Debian but there is no related bug found. So we have a raised a bug in Debian as attached.


4. Enable dbus in systemd
What do you mean by that?
Dinesh>>Sorry for confusing you. I meant dbus is an optional dependency of systemd package which is required to be enabled in CIP if we want to achieve session lock with systemd.
OK, so this is about adding dbus to our package set - not unrealistic.


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int
manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void
*us

(m->idle_action_not_before_usec <= 0 || n >=
m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action,
+ false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature to systemd so that it may become configurable (avoid the patch)? Or is it even a generic feature that everyone wants?
Dinesh>>This code simply enables idle_action=lock. I am not sure why they have kept it disabled. Should we post this change in upstream and ask them whether it can be made configurable?
Yes, this needs to be be clarified. Otherwise, we cannot decide how to move on.
Dinesh>>Sure, we have created a bug, hopefully we will have clear direction when someone replies.


It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it to the component that can implement it best. Once accepted, we can still look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing tools do not fulfill the requirements. And which tools or methods you examined already.
Dinesh>>Thanks for your inputs.
We have raised our query in systemd ML to know why lock action is disabled but no one has responded so far.
If there is an integration issue with systemd + vlock/physlock under Debian, it may also be an option to open an ticket there so that Debian maintainers call push it or provide further input.
Dinesh>>Agree, we have to wait for the response from Debian then decide next.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
Competence Center Embedded Linux 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.
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
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: Share your suggestions for supporting session lock requirement in CIP

Jan Kiszka
 

On 21.06.20 10:23, Dinesh Kumar wrote:
Hi Jan,

I have added my comments, please let me know your views.

Thanks & Regards,
Dinesh Kumar

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 16 June 2020 12:39
To: Dinesh Kumar <Dinesh.Kumar@...>
Cc: cip-security@...; cip-dev@...
Subject: Re: [cip-dev] Share your suggestions for supporting session lock requirement in CIP

On 16.06.20 09:00, Dinesh Kumar wrote:
Hi Jan,

Thanks for your review comments.
Kindly refer my response and let me know your opinion.

Thanks & Regards,
Dinesh Kumar


-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 15 June 2020 12:52
To: cip-dev@...; Dinesh Kumar
<Dinesh.Kumar@...>
Cc: cip-security@...
Subject: Re: [cip-dev] Share your suggestions for supporting session
lock requirement in CIP

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?
Dinesh>>Yes, we can do that by using TMOUT. However, we were just trying if we can achieve session lock with some existing packages or minimal changes in CIP. But that does not seem to happen.
Our idea of sharing this detail here was if anyone can suggest achieving session lock with some Debian packages without any modifications in the packages.
TMOUT is our backup option.

CR2.6 Req-2 Remote session termination: Component should support
terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?
Dinesh>>Since idle_action=lock is disabled in current systemd code. We enabled with changes described in this email. Though it works but we are not sure about side effects.
But that mode is documented in systemd manuals - without any note that it's in fact off? Something does not match here yet. At least, it would be a documentation bug, but maybe also a chance to enhance the code and sell it upstream.
Dinesh>>It's not documented in systemd manuals as well, not even any note whether it has been intentionally kept off.
"lock" is documented as offical option for IdleAction:
https://www.freedesktop.org/software/systemd/man/logind.conf.html#IdleAction=

Jan



2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?
Dinesh>>It's sufficient but disabled.

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?
Dinesh>>We quickly checked physlock, it's better alternate to vlock. But first we have to decide systemd changes, since vlock or physlock only work if systemd code changes are enabled.
OK. Still confused, though, because there is no mentioning of that somewhere. Unless I miss that. Is there any Debian bug? Or even an systemd issue?
Dinesh>>We searched Debian systemd bugs in Debian but there is no related bug found. So we have a raised a bug in Debian as attached.


4. Enable dbus in systemd
What do you mean by that?
Dinesh>>Sorry for confusing you. I meant dbus is an optional dependency of systemd package which is required to be enabled in CIP if we want to achieve session lock with systemd.
OK, so this is about adding dbus to our package set - not unrealistic.


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int
manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us

(m->idle_action_not_before_usec <= 0 || n >=
m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action,
+ false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature to systemd so that it may become configurable (avoid the patch)? Or is it even a generic feature that everyone wants?
Dinesh>>This code simply enables idle_action=lock. I am not sure why they have kept it disabled. Should we post this change in upstream and ask them whether it can be made configurable?
Yes, this needs to be be clarified. Otherwise, we cannot decide how to move on.
Dinesh>>Sure, we have created a bug, hopefully we will have clear direction when someone replies.


It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it to the component that can implement it best. Once accepted, we can still look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing tools do not fulfill the requirements. And which tools or methods you examined already.
Dinesh>>Thanks for your inputs.
We have raised our query in systemd ML to know why lock action is disabled but no one has responded so far.
If there is an integration issue with systemd + vlock/physlock under Debian, it may also be an option to open an ticket there so that Debian maintainers call push it or provide further input.
Dinesh>>Agree, we have to wait for the response from Debian then decide next.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
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.
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: Share your suggestions for supporting session lock requirement in CIP

Dinesh Kumar
 

Hi Jan,

I have added my comments, please let me know your views.

Thanks & Regards,
Dinesh Kumar

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 16 June 2020 12:39
To: Dinesh Kumar <Dinesh.Kumar@...>
Cc: cip-security@...; cip-dev@...
Subject: Re: [cip-dev] Share your suggestions for supporting session lock requirement in CIP

On 16.06.20 09:00, Dinesh Kumar wrote:
Hi Jan,

Thanks for your review comments.
Kindly refer my response and let me know your opinion.

Thanks & Regards,
Dinesh Kumar


-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 15 June 2020 12:52
To: cip-dev@...; Dinesh Kumar
<Dinesh.Kumar@...>
Cc: cip-security@...
Subject: Re: [cip-dev] Share your suggestions for supporting session
lock requirement in CIP

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?
Dinesh>>Yes, we can do that by using TMOUT. However, we were just trying if we can achieve session lock with some existing packages or minimal changes in CIP. But that does not seem to happen.
Our idea of sharing this detail here was if anyone can suggest achieving session lock with some Debian packages without any modifications in the packages.
TMOUT is our backup option.

CR2.6 Req-2 Remote session termination: Component should support
terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?
Dinesh>>Since idle_action=lock is disabled in current systemd code. We enabled with changes described in this email. Though it works but we are not sure about side effects.
But that mode is documented in systemd manuals - without any note that it's in fact off? Something does not match here yet. At least, it would be a documentation bug, but maybe also a chance to enhance the code and sell it upstream.
Dinesh>>It's not documented in systemd manuals as well, not even any note whether it has been intentionally kept off.


2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?
Dinesh>>It's sufficient but disabled.

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?
Dinesh>>We quickly checked physlock, it's better alternate to vlock. But first we have to decide systemd changes, since vlock or physlock only work if systemd code changes are enabled.
OK. Still confused, though, because there is no mentioning of that somewhere. Unless I miss that. Is there any Debian bug? Or even an systemd issue?
Dinesh>>We searched Debian systemd bugs in Debian but there is no related bug found. So we have a raised a bug in Debian as attached.


4. Enable dbus in systemd
What do you mean by that?
Dinesh>>Sorry for confusing you. I meant dbus is an optional dependency of systemd package which is required to be enabled in CIP if we want to achieve session lock with systemd.
OK, so this is about adding dbus to our package set - not unrealistic.


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int
manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us

(m->idle_action_not_before_usec <= 0 || n >=
m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action,
+ false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature to systemd so that it may become configurable (avoid the patch)? Or is it even a generic feature that everyone wants?
Dinesh>>This code simply enables idle_action=lock. I am not sure why they have kept it disabled. Should we post this change in upstream and ask them whether it can be made configurable?
Yes, this needs to be be clarified. Otherwise, we cannot decide how to move on.
Dinesh>>Sure, we have created a bug, hopefully we will have clear direction when someone replies.


It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it to the component that can implement it best. Once accepted, we can still look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing tools do not fulfill the requirements. And which tools or methods you examined already.
Dinesh>>Thanks for your inputs.
We have raised our query in systemd ML to know why lock action is disabled but no one has responded so far.
If there is an integration issue with systemd + vlock/physlock under Debian, it may also be an option to open an ticket there so that Debian maintainers call push it or provide further input.
Dinesh>>Agree, we have to wait for the response from Debian then decide next.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
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: staging drivers in use by defconfigs (moxa_eds and others)

SZ Lin <sz.lin@...>
 

Hi Pavel,

From: cip-dev@... <cip-dev@...> On Behalf

Hi!

I noticed that android drivers in staging are enabled by moxa_eds:

CONFIG_ION=y
CONFIG_ION_SYSTEM_HEAP=y
CONFIG_ION_CARVEOUT_HEAP=y
CONFIG_ION_CHUNK_HEAP=y
CONFIG_ION_CMA_HEAP=y

I normally don't review staging changes, and they are deemed by community
not to be ready for serious usage.

Is someone using them in production? If not, could we disable them in
defconfigs?
Thanks for the heads up, I will confirm this issue internally and keep you posted.

SZ


./4.4.y-cip/arm/toshiba_tegra_defconfig:CONFIG_STAGING=y
./4.4.y-cip/arm/siemens_imx6_defconfig:CONFIG_STAGING=y
./4.4.y-cip/x86/plathome_obsvx1.config:CONFIG_STAGING=y
./4.4.y-cip/x86/siemens_iot2000.config:CONFIG_STAGING=y
./4.19.y-cip/arm/renesas_shmobile_defconfig:CONFIG_STAGING=y
./4.19.y-cip/arm/siemens_imx6.config:CONFIG_STAGING=y
./4.19.y-cip/arm64/moxa_eds_defconfig:CONFIG_STAGING=y
./4.19.y-cip/x86/siemens_ipc227e_defconfig:CONFIG_STAGING=y
./4.19.y-cip/x86/plathome_obsvx2.config:CONFIG_STAGING=y
./4.19.y-cip-rt/arm/renesas_shmobile-rt_defconfig:CONFIG_STAGING=y
./4.19.y-cip-rt/x86/siemens_i386-rt.config:CONFIG_STAGING=y

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


staging drivers in use by defconfigs (moxa_eds and others)

Pavel Machek
 

Hi!

I noticed that android drivers in staging are enabled by moxa_eds:

CONFIG_ION=y
CONFIG_ION_SYSTEM_HEAP=y
CONFIG_ION_CARVEOUT_HEAP=y
CONFIG_ION_CHUNK_HEAP=y
CONFIG_ION_CMA_HEAP=y

I normally don't review staging changes, and they are deemed by
community not to be ready for serious usage.

Is someone using them in production? If not, could we disable them in defconfigs?

./4.4.y-cip/arm/toshiba_tegra_defconfig:CONFIG_STAGING=y
./4.4.y-cip/arm/siemens_imx6_defconfig:CONFIG_STAGING=y
./4.4.y-cip/x86/plathome_obsvx1.config:CONFIG_STAGING=y
./4.4.y-cip/x86/siemens_iot2000.config:CONFIG_STAGING=y
./4.19.y-cip/arm/renesas_shmobile_defconfig:CONFIG_STAGING=y
./4.19.y-cip/arm/siemens_imx6.config:CONFIG_STAGING=y
./4.19.y-cip/arm64/moxa_eds_defconfig:CONFIG_STAGING=y
./4.19.y-cip/x86/siemens_ipc227e_defconfig:CONFIG_STAGING=y
./4.19.y-cip/x86/plathome_obsvx2.config:CONFIG_STAGING=y
./4.19.y-cip-rt/arm/renesas_shmobile-rt_defconfig:CONFIG_STAGING=y
./4.19.y-cip-rt/x86/siemens_i386-rt.config:CONFIG_STAGING=y

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

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

Hi, Iwamatsu-san,

Thanks for your updates. But, how about the following?

5. Issues to be fixed for swupdate "copyright correction and salsa
CI testing" - iwamatsu
Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Nobuhiro Iwamatsu
Sent: Thursday, June 18, 2020 4:19 PM
To: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

Hi,

I can not attend IRC meeting today, sorry.

-----Original Message-----
From: cip-dev@...
[mailto:cip-dev@...] On Behalf Of
masashi.kudo@...
Sent: Thursday, June 18, 2020 9:20 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&m
onth=6&day=18&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/06/cip.2020-06-11-09.00
.log.html

Agenda:

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

2. Post LTP results to KernelCI - patersonc
3. Ask board owners to review reference platform configs to optimize backporting - masashi910
4. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) -
iwamatsu
No update.
No update / work can be seen even in Upstream etc.

5. Issues to be fixed for swupdate "copyright correction and salsa
CI testing" - iwamatsu

Note: The followings are 2020 Kernel Team Roadmap stuff. If there are
any progresses I will report at the "Kernel maintenance updates" in future.
+. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
+. Upload a guideline for reference hardware platform addition -
masashi910

* Kernel maintenance updates
I reviewed LTS-rc. I send a comment.

* Kernel testing
* Software update
* CIP Security
* AOB

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

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


Re: CIP IRC weekly meeting today

Nobuhiro Iwamatsu
 

Hi,

I can not attend IRC meeting today, sorry.

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of
masashi.kudo@...
Sent: Thursday, June 18, 2020 9:20 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=6&day=18&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/06/cip.2020-06-11-09.00.log.html

Agenda:

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

2. Post LTP results to KernelCI - patersonc
3. Ask board owners to review reference platform configs to optimize backporting - masashi910
4. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - iwamatsu
No update.
No update / work can be seen even in Upstream etc.

5. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

Note: The followings are 2020 Kernel Team Roadmap stuff. If there are any progresses I will report at the "Kernel
maintenance updates" in future.
+. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
+. Upload a guideline for reference hardware platform addition - masashi910

* Kernel maintenance updates
I reviewed LTS-rc. I send a comment.

* Kernel testing
* Software update
* CIP Security
* AOB

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

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


CIP IRC weekly meeting today

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

Hi, all,

Please let me resend, because the original mail does not seem to be delivered.

Best regards,
--
M. Kudo

-----Original Message-----
From: 工藤 雅司(CTJ OSS事業推進室)
Sent: Thursday, June 18, 2020 9:20 AM
To: cip-dev@...
Subject: 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=6&day=18&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/06/cip.2020-06-11-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Ask board owners to review reference platform configs to optimize backporting - masashi910
4. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - iwamatsu
5. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

Note: The followings are 2020 Kernel Team Roadmap stuff. If there are any progresses I will report at the "Kernel maintenance updates" in future.
+. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
+. Upload a guideline for reference hardware platform addition - 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=6&day=18&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/06/cip.2020-06-11-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Ask board owners to review reference platform configs to optimize backporting - masashi910
4. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - iwamatsu
5. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

Note: The followings are 2020 Kernel Team Roadmap stuff. If there are any progresses I will report at the "Kernel maintenance updates" in future.
+. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
+. Upload a guideline for reference hardware platform addition - 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.


FW: KernelCI plans for 2020-Q3

Chris Paterson
 

FYI

Kind regards, Chris

From: kernelci@groups.io <kernelci@groups.io> On Behalf Of Guillaume
Tucker via groups.io
Sent: 16 June 2020 07:41

As you probably all know, the Linux Plumbers Conference (LPC) is
going to be KernelCI's next milestone, at the end of August.
While it's not entirely clear yet which online format it will
adopt and whether we'll be able to discuss all the things as we
would normally do face-to-face, it is still a key moment for
KernelCI and the kernel community.

A lot of progress has been made in KernelCI over the past months.
Like with any project, some things still need to be completed and
others haven't even started yet. In order to focus our efforts
and be in a strong position by LPC, we have outlined our plans in
this shared document:


https://docs.google.com/document/d/1KCIv6L3XrsNFIu4GzFMTV7Qx6Jlm2tr
c-bvRIbDEVV8/edit#


And like with any community project, nobody really has any
control over the actual course of events. But it helps to have
some guidelines and agree on what the priorities should be.
That's what the plan document is here for.


There is also a new GitHub project board for 2020-Q3, for the
tasks that fit in this format:

https://github.com/orgs/kernelci/projects/2


There's some exciting work ahead of us, and several opportunities
to grow the project with new contributors. I'm sure we'll have
to overcome some challenges but there's every reason to be
optimistic. We've come a long way already!


This is of course all open for comments and questions, please
feel free to reply on this thread or on the shared document.


Thanks,
Guillaume


Re: Share your suggestions for supporting session lock requirement in CIP

Jan Kiszka
 

On 16.06.20 09:00, Dinesh Kumar wrote:
Hi Jan,

Thanks for your review comments.
Kindly refer my response and let me know your opinion.

Thanks & Regards,
Dinesh Kumar


-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 15 June 2020 12:52
To: cip-dev@...; Dinesh Kumar <Dinesh.Kumar@...>
Cc: cip-security@...
Subject: Re: [cip-dev] Share your suggestions for supporting session lock requirement in CIP

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?
Dinesh>>Yes, we can do that by using TMOUT. However, we were just trying if we can achieve session lock with some existing packages or minimal changes in CIP. But that does not seem to happen.
Our idea of sharing this detail here was if anyone can suggest achieving session lock with some Debian packages without any modifications in the packages.
TMOUT is our backup option.

CR2.6 Req-2 Remote session termination: Component should support
terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?
Dinesh>>Since idle_action=lock is disabled in current systemd code. We enabled with changes described in this email. Though it works but we are not sure about side effects.
But that mode is documented in systemd manuals - without any note that
it's in fact off? Something does not match here yet. At least, it would
be a documentation bug, but maybe also a chance to enhance the code and
sell it upstream.


2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?
Dinesh>>It's sufficient but disabled.

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?
Dinesh>>We quickly checked physlock, it's better alternate to vlock. But first we have to decide systemd changes, since vlock or physlock only work if systemd code changes are enabled.
OK. Still confused, though, because there is no mentioning of that
somewhere. Unless I miss that. Is there any Debian bug? Or even an
systemd issue?


4. Enable dbus in systemd
What do you mean by that?
Dinesh>>Sorry for confusing you. I meant dbus is an optional dependency of systemd package which is required to be enabled in CIP if we want to achieve session lock with systemd.
OK, so this is about adding dbus to our package set - not unrealistic.


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int
manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us

(m->idle_action_not_before_usec <= 0 || n >=
m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action,
+ false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature to systemd so that it may become configurable (avoid the patch)? Or is it even a generic feature that everyone wants?
Dinesh>>This code simply enables idle_action=lock. I am not sure why they have kept it disabled. Should we post this change in upstream and ask them whether it can be made configurable?
Yes, this needs to be be clarified. Otherwise, we cannot decide how to
move on.


It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it to the component that can implement it best. Once accepted, we can still look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing tools do not fulfill the requirements. And which tools or methods you examined already.
Dinesh>>Thanks for your inputs.
We have raised our query in systemd ML to know why lock action is disabled but no one has responded so far.
If there is an integration issue with systemd + vlock/physlock under
Debian, it may also be an option to open an ticket there so that Debian
maintainers call push it or provide further input.

Jan

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


Re: Share your suggestions for supporting session lock requirement in CIP

Dinesh Kumar
 

Hi Jan,

Thanks for your review comments.
Kindly refer my response and let me know your opinion.

Thanks & Regards,
Dinesh Kumar

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 15 June 2020 12:52
To: cip-dev@...; Dinesh Kumar <Dinesh.Kumar@...>
Cc: cip-security@...
Subject: Re: [cip-dev] Share your suggestions for supporting session lock requirement in CIP

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?
Dinesh>>Yes, we can do that by using TMOUT. However, we were just trying if we can achieve session lock with some existing packages or minimal changes in CIP. But that does not seem to happen.
Our idea of sharing this detail here was if anyone can suggest achieving session lock with some Debian packages without any modifications in the packages.
TMOUT is our backup option.

CR2.6 Req-2 Remote session termination: Component should support
terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?
Dinesh>>Since idle_action=lock is disabled in current systemd code. We enabled with changes described in this email. Though it works but we are not sure about side effects.

2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?
Dinesh>>It's sufficient but disabled.

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?
Dinesh>>We quickly checked physlock, it's better alternate to vlock. But first we have to decide systemd changes, since vlock or physlock only work if systemd code changes are enabled.


4. Enable dbus in systemd
What do you mean by that?
Dinesh>>Sorry for confusing you. I meant dbus is an optional dependency of systemd package which is required to be enabled in CIP if we want to achieve session lock with systemd.


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int
manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us

(m->idle_action_not_before_usec <= 0 || n >=
m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action,
+ false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature to systemd so that it may become configurable (avoid the patch)? Or is it even a generic feature that everyone wants?
Dinesh>>This code simply enables idle_action=lock. I am not sure why they have kept it disabled. Should we post this change in upstream and ask them whether it can be made configurable?

It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it to the component that can implement it best. Once accepted, we can still look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing tools do not fulfill the requirements. And which tools or methods you examined already.
Dinesh>>Thanks for your inputs.
We have raised our query in systemd ML to know why lock action is disabled but no one has responded so far.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
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: Share your suggestions for supporting session lock requirement in CIP

Jan Kiszka
 

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?

CR2.6 Req-2 Remote session termination: Component should support terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?

2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?


4. Enable dbus in systemd
What do you mean by that?


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us

(m->idle_action_not_before_usec <= 0 || n >= m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action, false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature
to systemd so that it may become configurable (avoid the patch)? Or is
it even a generic feature that everyone wants?

It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it
to the component that can implement it best. Once accepted, we can still
look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing
tools do not fulfill the requirements. And which tools or methods you
examined already.

Jan

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

3781 - 3800 of 8596