Date   

5.10.16 testing failing

Pavel Machek
 

Hi!

Latest -stable-rc tests are failing, both for 4.19 and for 5.10.16. I
resubmitted tests and some succeeded on second try, but most did not.

It does not seem to be real failures, it seems more like network problems.

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/254936494
https://lava.ciplatform.org/scheduler/job/162225
extra keys not allowed @
data['actions[2]']['test']['definition']['definitions'][0]['repository']['metadata']['version']
progress 65% (59MB)
http-download timed out after 895 seconds
end: 1.3.1 http-download (duration 00:14:55) [common]
tftp-deploy timed out after 1715 seconds
end: 1.3 download-retry (duration 00:13:35) [common]

https://lava.ciplatform.org/scheduler/job/162215
(does not load logs at all?)

etc...

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


Re: Cip-kernel-sec Updates for Week of 2021-02-11

Pavel Machek
 

Hi!

Six new issues this week:
- CVE-2020-12362, CVE-2020-12363, CVE-2020-12364:
CVEs from Intel Advisory affecting Intel Graphics Driver. Details
unknown
It seems there's more for the intel graphics, but it is not mentioned
in our repository. OTOH trailer there that these are rather old
issues, fixed in 5.5...

Best regards,
Pavel

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00438.html

CVEID: CVE-2020-0544

Description: Insufficient control flow management in the kernel mode
driver for some Intel(R) Graphics Drivers before version 15.36.39.5145
may allow an authenticated user to potentially enable escalation of
privilege via local access.

CVSS Base Score: 8.8 High

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H



CVEID: CVE-2020-0521

Description: Insufficient control flow management in some Intel(R)
Graphics Drivers before version 15.45.32.5145 may allow an
authenticated user to potentially enable escalation of privilege via
local access.

CVSS Base Score: 7.7 High

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L

...

Affected Products:
Intel® Graphics Drivers for 3rd, 4th, 5th, 6th, 7th, 8th, 9th and 10th
Generation Intel® Processors for Windows* 7, 8.1 and 10 before
versions 15.33.51.5146, 15.36.39.5145, 15.40.46.5144, 15.45.32.5164,
26.20.100.8141, 27.20.100.8587 and Intel® Graphics Drivers for Linux
before Linux kernel version 5.5.

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


Re: Cip-kernel-sec Updates for Week of 2021-02-11

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

On Thu, Feb 11, 2021 at 4:50 PM Chen-Yu Tsai <wens@csie.org> wrote:

Hi everyone,

Six new issues this week:
- CVE-2020-12362, CVE-2020-12363, CVE-2020-12364:
CVEs from Intel Advisory affecting Intel Graphics Driver. Details unknown

- CVE-2021-20194 [bpf heap overflow] - fixed for relevant kernels
- CVE-2021-20226 [io_uring UAF] - likely a duplicate of
CVE-2020-29534, already fixed
- CVE-2021-26708 [AF_VSOCK: local priv. escalation] - fixed for relevant kernels

Additionally, CVE-2021-3347 is fixed for 4.4 and 4.9.
I still need to match patches for 4.4 against 4.9, but it looks like
the fixes are there.
Based on fixes for 4.9 reported by Debian, CVE-2021-3347 is now fixed for 4.4 by
6510e4a2d04f33e4bfd221760faab23e55d8772b..46358277b2da868763517f79aa0ac25ce78c4f68
inclusive.

Lee Jones just posted a few follow-up fixes for futexes for 4.9 [1]. I
wonder if they
would also be posted for 4.4.


Regards
ChenYu

[1] https://lore.kernel.org/stable/20210211092700.11772-1-lee.jones@linaro.org/


Re: CIP IRC weekly meeting today

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

Hi, Pavel-san,

Today, there were just Chen-Yu-san and me. Very quiet. :)
Thanks for your report.
See you next week!

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
Pavel Machek
Sent: Thursday, February 11, 2021 6:21 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] CIP IRC weekly meeting today

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=2021&m
onth=2&day=11&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p
5=241&p6=
248

USWest USEast UK DE TW JP
01:00 04:00 9:00 10:00 17:00 18:00
I missed the meeting, I'm sorry. I'll go through the meeting logs.

My activity for last week were reviews on 5.10.14 and 5.10.15 and corresponding
older kernels.

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


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=2021&month=2&day=11&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
01:00 04:00 9:00 10:00 17:00 18:00
I missed the meeting, I'm sorry. I'll go through the meeting logs.

My activity for last week were reviews on 5.10.14 and 5.10.15 and
corresponding older kernels.

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


Cip-kernel-sec Updates for Week of 2021-02-11

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

Hi everyone,

Six new issues this week:
- CVE-2020-12362, CVE-2020-12363, CVE-2020-12364:
CVEs from Intel Advisory affecting Intel Graphics Driver. Details unknown

- CVE-2021-20194 [bpf heap overflow] - fixed for relevant kernels
- CVE-2021-20226 [io_uring UAF] - likely a duplicate of
CVE-2020-29534, already fixed
- CVE-2021-26708 [AF_VSOCK: local priv. escalation] - fixed for relevant kernels

Additionally, CVE-2021-3347 is fixed for 4.4 and 4.9.
I still need to match patches for 4.4 against 4.9, but it looks like
the fixes are there.


Regards
ChenYu


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=2021&month=2&day=11&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
01:00 04:00 9:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2021/02/cip.2021-02-04-09.00.log.html

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Do some experiment to lower burdens on CI - patersonc
3. Check hitachi_omap defconfigs wrt CVE-2020-27820 [drm/nouveau UAF] - Hitachi-team
4. Track the CVE-2021-3347 patch status - Kernel Team

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

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

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


Re: Cip-kernel-sec Updates for Week of 2021-02-04

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

Hi, Chen-Yu san,

Thanks for reporting this!

Best regards,
--
M. Kudo

-----Original Message-----
From: Chen-Yu Tsai <wens@csie.org>
Sent: Friday, February 5, 2021 11:33 AM
To: cip-dev@lists.cip-project.org
Cc: Pavel Machek <pavel@denx.de>; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@toshiba.co.jp>; 工藤 雅司(CTJ OSS事業推進室)
<masashi.kudo@cybertrust.co.jp>
Subject: Re: Cip-kernel-sec Updates for Week of 2021-02-04

On Thu, Feb 4, 2021 at 1:26 PM Chen-Yu Tsai <wens@csie.org> wrote:

Hi everyone,

Two new issue this week:
- CVE-2021-3347 [UAF in futex]: fixed for 4.14 and later [1]
- CVE-2021-3348 [nbd: UAF when adding connections while operations are
running]: fixed in all kernels

For CVE-2021-3347, based on [1], more patches are needed for 4.4 and 4.9.
The second batch:

12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9..34b1a1ce1458f50ef27c54e28eb
9
b1947012907a
inclusive

has not been included yet. Lee Jones seems to be handling it [2].
FTR, a second backport series for 4.4 was also posted:

https://lore.kernel.org/stable/20210204172903.2860981-1-lee.jones@linaro.org
/


ChenYu

For CVE-2020-27825 from two weeks ago, the fix has been backported to
all stable kernels.

For CVE-2020-16120, Ubuntu mentions a regression due to the backported fix
[3].
We probably don't care either way since this requires unprivileged
user namespace is enabled.


Regards
ChenYu

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.gi
t/tree/pending/futex_issues.txt [2]
https://lore.kernel.org/stable/20210203134539.2583943-1-lee.jones@lina
ro.org/ [2]
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1900141


Re: Cip-kernel-sec Updates for Week of 2021-02-04

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

On Thu, Feb 4, 2021 at 1:26 PM Chen-Yu Tsai <wens@csie.org> wrote:

Hi everyone,

Two new issue this week:
- CVE-2021-3347 [UAF in futex]: fixed for 4.14 and later [1]
- CVE-2021-3348 [nbd: UAF when adding connections while operations are
running]: fixed in all kernels

For CVE-2021-3347, based on [1], more patches are needed for 4.4 and 4.9.
The second batch:

12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9..34b1a1ce1458f50ef27c54e28eb9b1947012907a
inclusive

has not been included yet. Lee Jones seems to be handling it [2].
FTR, a second backport series for 4.4 was also posted:

https://lore.kernel.org/stable/20210204172903.2860981-1-lee.jones@linaro.org/


ChenYu

For CVE-2020-27825 from two weeks ago, the fix has been backported to
all stable kernels.

For CVE-2020-16120, Ubuntu mentions a regression due to the backported fix [3].
We probably don't care either way since this requires unprivileged
user namespace
is enabled.


Regards
ChenYu

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/pending/futex_issues.txt
[2] https://lore.kernel.org/stable/20210203134539.2583943-1-lee.jones@linaro.org/
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1900141


Re: CIP IRC weekly meeting today

Nobuhiro Iwamatsu
 

Hi,

I can not participate IRC meeting today for personal reason.

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

2. Do some experiment to lower burdens on CI - patersonc
3. Check hitachi_omap defconfigs wrt CVE-2020-27820 [drm/nouveau UAF] - Hitachi-team

* Kernel maintenance updates
I reviewed 4.4.255.

* Kernel testing
* CIP Security
* AOB

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of
masashi.kudo@cybertrust.co.jp
Sent: Thursday, February 4, 2021 9:04 AM
To: cip-dev@lists.cip-project.org
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=2021&month=2&day=4&hour=9&min=0&sec=0&p1=224&p2=1
79&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
01:00 04:00 9:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2021/01/cip.2021-01-28-09.00.log.html

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Do some experiment to lower burdens on CI - patersonc
3. Check hitachi_omap defconfigs wrt CVE-2020-27820 [drm/nouveau UAF] - Hitachi-team

* Kernel maintenance updates
* Kernel testing
* 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-kernel-sec Updates for Week of 2021-02-04

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

Hi everyone,

Two new issue this week:
- CVE-2021-3347 [UAF in futex]: fixed for 4.14 and later [1]
- CVE-2021-3348 [nbd: UAF when adding connections while operations are
running]: fixed in all kernels

For CVE-2021-3347, based on [1], more patches are needed for 4.4 and 4.9.
The second batch:

12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9..34b1a1ce1458f50ef27c54e28eb9b1947012907a
inclusive

has not been included yet. Lee Jones seems to be handling it [2].

For CVE-2020-27825 from two weeks ago, the fix has been backported to
all stable kernels.

For CVE-2020-16120, Ubuntu mentions a regression due to the backported fix [3].
We probably don't care either way since this requires unprivileged
user namespace
is enabled.


Regards
ChenYu

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/pending/futex_issues.txt
[2] https://lore.kernel.org/stable/20210203134539.2583943-1-lee.jones@linaro.org/
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1900141


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=2021&month=2&day=4&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
01:00 04:00 9:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2021/01/cip.2021-01-28-09.00.log.html

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Do some experiment to lower burdens on CI - patersonc
3. Check hitachi_omap defconfigs wrt CVE-2020-27820 [drm/nouveau UAF] - Hitachi-team

* Kernel maintenance updates
* Kernel testing
* 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: [isar-cip-core][PATCH 2/2] secure-boot: Move image-uuid to own file

Quirin Gylstorff
 

On 2/1/21 5:47 PM, Jan Kiszka wrote:
On 01.02.21 17:24, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

/etc/os-release is controlled by the Debian Package base-files
and will be silently overwritten if the package updates the file.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
classes/image_uuid.bbclass | 4 +---
.../initramfs-config/files/initramfs.image_uuid.hook | 6 +++---
.../initramfs-config/files/secure-boot-debian-local-patch | 4 ++--
3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/classes/image_uuid.bbclass b/classes/image_uuid.bbclass
index 2813ed9..a0ab202 100644
--- a/classes/image_uuid.bbclass
+++ b/classes/image_uuid.bbclass
@@ -22,9 +22,7 @@ IMAGE_UUID ?= "${@generate_image_uuid(d)}"
do_generate_image_uuid[vardeps] += "IMAGE_UUID"
do_generate_image_uuid[depends] = "buildchroot-target:do_build"
do_generate_image_uuid() {
- sudo sed -i '/^IMAGE_UUID=.*/d' '${IMAGE_ROOTFS}/etc/os-release'
- echo "IMAGE_UUID=\"${IMAGE_UUID}\"" | \
- sudo tee -a '${IMAGE_ROOTFS}/etc/os-release'
+ sudo sh -c 'echo "IMAGE_UUID=\"${IMAGE_UUID}\"" > "${IMAGE_ROOTFS}/etc/secureboot-image-uuid"'
image_do_mounts
# update initramfs to add uuid
diff --git a/recipes-support/initramfs-config/files/initramfs.image_uuid.hook b/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
index 910ce84..bf39abb 100644
--- a/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
+++ b/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
@@ -22,12 +22,12 @@ esac
. /usr/share/initramfs-tools/scripts/functions
. /usr/share/initramfs-tools/hook-functions
-if [ ! -e /etc/os-release ]; then
- echo "Warning: couldn't find /etc/os-release!"
+if [ ! -e /etc/secureboot-image-uuid ]; then
+
echo "Warning: couldn't find /etc/secureboot-image-uuid!"
exit 0
fi
-IMAGE_UUID=$(sed -n 's/^IMAGE_UUID="\(.*\)"/\1/p' /etc/os-release)
+IMAGE_UUID=$(sed -n 's/^IMAGE_UUID="\(.*\)"/\1/p' /etc/secureboot-image-uuid)
echo "${IMAGE_UUID}" > "${DESTDIR}/conf/image_uuid"
exit 0
\ No newline at end of file
diff --git a/recipes-support/initramfs-config/files/secure-boot-debian-local-patch b/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
index cd2d271..82d325a 100644
--- a/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
+++ b/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
@@ -58,8 +58,8 @@
+ # Mount root
+ # shellcheck disable=SC2086
+ if mount ${roflag} ${FSTYPE:+-t "${FSTYPE}"} ${ROOTFLAGS} "${ROOT}" "${rootmnt?}"; then
-+ if [ -e "${rootmnt?}"/etc/os-release ]; then
-+ image_uuid=$(sed -n 's/^IMAGE_UUID=//p' "${rootmnt?}"/etc/os-release | tr -d '"' )
++ if [ -e "${rootmnt?}"/etc/secureboot-image-uuid ]; then
++ image_uuid=$(sed -n 's/^IMAGE_UUID=//p' "${rootmnt?}"/etc/secureboot-image-uuid | tr -d '"' )
+ if [ "${INITRAMFS_IMAGE_UUID}" = "${image_uuid}" ]; then
+ return 0
+ fi
This one would work, though, if we fixed
https://groups.google.com/d/msgid/isar-users/67e1fac9-5af5-29aa-de57-9a0de0cdd165%40siemens.com
in Isar, right? Should we rather wait for that?
At the moment I would say yes, wait for it.


Quirin

Applied patch 1 for now.
Jan


Re: [isar-cip-core][PATCH 2/2] secure-boot: Move image-uuid to own file

Jan Kiszka
 

On 01.02.21 17:24, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

/etc/os-release is controlled by the Debian Package base-files
and will be silently overwritten if the package updates the file.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
classes/image_uuid.bbclass | 4 +---
.../initramfs-config/files/initramfs.image_uuid.hook | 6 +++---
.../initramfs-config/files/secure-boot-debian-local-patch | 4 ++--
3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/classes/image_uuid.bbclass b/classes/image_uuid.bbclass
index 2813ed9..a0ab202 100644
--- a/classes/image_uuid.bbclass
+++ b/classes/image_uuid.bbclass
@@ -22,9 +22,7 @@ IMAGE_UUID ?= "${@generate_image_uuid(d)}"
do_generate_image_uuid[vardeps] += "IMAGE_UUID"
do_generate_image_uuid[depends] = "buildchroot-target:do_build"
do_generate_image_uuid() {
- sudo sed -i '/^IMAGE_UUID=.*/d' '${IMAGE_ROOTFS}/etc/os-release'
- echo "IMAGE_UUID=\"${IMAGE_UUID}\"" | \
- sudo tee -a '${IMAGE_ROOTFS}/etc/os-release'
+ sudo sh -c 'echo "IMAGE_UUID=\"${IMAGE_UUID}\"" > "${IMAGE_ROOTFS}/etc/secureboot-image-uuid"'
image_do_mounts

# update initramfs to add uuid
diff --git a/recipes-support/initramfs-config/files/initramfs.image_uuid.hook b/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
index 910ce84..bf39abb 100644
--- a/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
+++ b/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
@@ -22,12 +22,12 @@ esac
. /usr/share/initramfs-tools/scripts/functions
. /usr/share/initramfs-tools/hook-functions

-if [ ! -e /etc/os-release ]; then
- echo "Warning: couldn't find /etc/os-release!"
+if [ ! -e /etc/secureboot-image-uuid ]; then
+ echo "Warning: couldn't find /etc/secureboot-image-uuid!"
exit 0
fi

-IMAGE_UUID=$(sed -n 's/^IMAGE_UUID="\(.*\)"/\1/p' /etc/os-release)
+IMAGE_UUID=$(sed -n 's/^IMAGE_UUID="\(.*\)"/\1/p' /etc/secureboot-image-uuid)
echo "${IMAGE_UUID}" > "${DESTDIR}/conf/image_uuid"

exit 0
\ No newline at end of file
diff --git a/recipes-support/initramfs-config/files/secure-boot-debian-local-patch b/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
index cd2d271..82d325a 100644
--- a/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
+++ b/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
@@ -58,8 +58,8 @@
+ # Mount root
+ # shellcheck disable=SC2086
+ if mount ${roflag} ${FSTYPE:+-t "${FSTYPE}"} ${ROOTFLAGS} "${ROOT}" "${rootmnt?}"; then
-+ if [ -e "${rootmnt?}"/etc/os-release ]; then
-+ image_uuid=$(sed -n 's/^IMAGE_UUID=//p' "${rootmnt?}"/etc/os-release | tr -d '"' )
++ if [ -e "${rootmnt?}"/etc/secureboot-image-uuid ]; then
++ image_uuid=$(sed -n 's/^IMAGE_UUID=//p' "${rootmnt?}"/etc/secureboot-image-uuid | tr -d '"' )
+ if [ "${INITRAMFS_IMAGE_UUID}" = "${image_uuid}" ]; then
+ return 0
+ fi
This one would work, though, if we fixed
https://groups.google.com/d/msgid/isar-users/67e1fac9-5af5-29aa-de57-9a0de0cdd165%40siemens.com
in Isar, right? Should we rather wait for that?

Applied patch 1 for now.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


[isar-cip-core][PATCH 1/2] swupdate: Secure-boot fix paths

Quirin Gylstorff
 

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

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
recipes-core/images/secureboot.inc | 2 ++
recipes-core/images/swupdate.inc | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-core/images/secureboot.inc b/recipes-core/images/secureboot.inc
index 3e284e0..f048497 100644
--- a/recipes-core/images/secureboot.inc
+++ b/recipes-core/images/secureboot.inc
@@ -9,6 +9,8 @@
# SPDX-License-Identifier: MIT
#

+FILESEXTRAPATHS_prepend := "${THISDIR}/files/secure-boot:"
+
EXTRACT_PARTITIONS = "img4"
ROOTFS_PARTITION_NAME="img4.gz"

diff --git a/recipes-core/images/swupdate.inc b/recipes-core/images/swupdate.inc
index a88ed14..6708a7e 100644
--- a/recipes-core/images/swupdate.inc
+++ b/recipes-core/images/swupdate.inc
@@ -9,8 +9,6 @@
# SPDX-License-Identifier: MIT
#

-FILESEXTRAPATHS_prepend := "${THISDIR}/files/secure-boot:"
-
EXTRACT_PARTITIONS = "img4"
ROOTFS_PARTITION_NAME="img4.gz"

--
2.20.1


[isar-cip-core][PATCH 2/2] secure-boot: Move image-uuid to own file

Quirin Gylstorff
 

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

/etc/os-release is controlled by the Debian Package base-files
and will be silently overwritten if the package updates the file.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
classes/image_uuid.bbclass | 4 +---
.../initramfs-config/files/initramfs.image_uuid.hook | 6 +++---
.../initramfs-config/files/secure-boot-debian-local-patch | 4 ++--
3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/classes/image_uuid.bbclass b/classes/image_uuid.bbclass
index 2813ed9..a0ab202 100644
--- a/classes/image_uuid.bbclass
+++ b/classes/image_uuid.bbclass
@@ -22,9 +22,7 @@ IMAGE_UUID ?= "${@generate_image_uuid(d)}"
do_generate_image_uuid[vardeps] += "IMAGE_UUID"
do_generate_image_uuid[depends] = "buildchroot-target:do_build"
do_generate_image_uuid() {
- sudo sed -i '/^IMAGE_UUID=.*/d' '${IMAGE_ROOTFS}/etc/os-release'
- echo "IMAGE_UUID=\"${IMAGE_UUID}\"" | \
- sudo tee -a '${IMAGE_ROOTFS}/etc/os-release'
+ sudo sh -c 'echo "IMAGE_UUID=\"${IMAGE_UUID}\"" > "${IMAGE_ROOTFS}/etc/secureboot-image-uuid"'
image_do_mounts

# update initramfs to add uuid
diff --git a/recipes-support/initramfs-config/files/initramfs.image_uuid.hook b/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
index 910ce84..bf39abb 100644
--- a/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
+++ b/recipes-support/initramfs-config/files/initramfs.image_uuid.hook
@@ -22,12 +22,12 @@ esac
. /usr/share/initramfs-tools/scripts/functions
. /usr/share/initramfs-tools/hook-functions

-if [ ! -e /etc/os-release ]; then
- echo "Warning: couldn't find /etc/os-release!"
+if [ ! -e /etc/secureboot-image-uuid ]; then
+ echo "Warning: couldn't find /etc/secureboot-image-uuid!"
exit 0
fi

-IMAGE_UUID=$(sed -n 's/^IMAGE_UUID="\(.*\)"/\1/p' /etc/os-release)
+IMAGE_UUID=$(sed -n 's/^IMAGE_UUID="\(.*\)"/\1/p' /etc/secureboot-image-uuid)
echo "${IMAGE_UUID}" > "${DESTDIR}/conf/image_uuid"

exit 0
\ No newline at end of file
diff --git a/recipes-support/initramfs-config/files/secure-boot-debian-local-patch b/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
index cd2d271..82d325a 100644
--- a/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
+++ b/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
@@ -58,8 +58,8 @@
+ # Mount root
+ # shellcheck disable=SC2086
+ if mount ${roflag} ${FSTYPE:+-t "${FSTYPE}"} ${ROOTFLAGS} "${ROOT}" "${rootmnt?}"; then
-+ if [ -e "${rootmnt?}"/etc/os-release ]; then
-+ image_uuid=$(sed -n 's/^IMAGE_UUID=//p' "${rootmnt?}"/etc/os-release | tr -d '"' )
++ if [ -e "${rootmnt?}"/etc/secureboot-image-uuid ]; then
++ image_uuid=$(sed -n 's/^IMAGE_UUID=//p' "${rootmnt?}"/etc/secureboot-image-uuid | tr -d '"' )
+ if [ "${INITRAMFS_IMAGE_UUID}" = "${image_uuid}" ]; then
+ return 0
+ fi
--
2.20.1


[isar-cip-core][PATCH 0/2] Secureboot fixes

Quirin Gylstorff
 

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

Use correct swu-description.tmpl and use own file for image-uuid
to avoid overwrite by Debian package `base-files`.

Quirin Gylstorff (2):
swupdate: Secure-boot fix paths
secure-boot: Move image-uuid to own file

classes/image_uuid.bbclass | 4 +---
recipes-core/images/secureboot.inc | 2 ++
recipes-core/images/swupdate.inc | 2 --
.../initramfs-config/files/initramfs.image_uuid.hook | 6 +++---
.../initramfs-config/files/secure-boot-debian-local-patch | 4 ++--
5 files changed, 8 insertions(+), 10 deletions(-)

--
2.20.1


Re: [isar-cip-core][PATCH] Use u-boot-config instead of tools

Jan Kiszka
 

On 01.02.21 13:33, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

Swupdate requires libubootenv0.1 and u-boot-config to access the u-boot
environment. u-boot-config adds the configuration files.

Add the flag `USE_U_BOOT_CONFIG` to deactivate the addition of
'u-boot-${MACHINE}-config.' If the image uses an upstream u-boot binary
(e.g. [1]) remove the package by setting `USE_U_BOOT_CONFIG` to `false`.

[1]: https://packages.debian.org/buster/u-boot-omap

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
classes/swupdate-config.bbclass | 8 +++++---
recipes-core/swupdate/swupdate.bb | 2 --
2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/classes/swupdate-config.bbclass b/classes/swupdate-config.bbclass
index dd0317f..9909113 100644
--- a/classes/swupdate-config.bbclass
+++ b/classes/swupdate-config.bbclass
@@ -45,10 +45,13 @@ KFEATURE_ubi[KCONFIG_SNIPPETS] = "file://swupdate_defconfig_ubi.snippet"

KFEATURE_DEPS[ubi] = "mtd"

+USE_U_BOOT_CONFIG ?= "true"
KFEATURE_u-boot = ""
KFEATURE_u-boot[BUILD_DEB_DEPENDS] = "libubootenv-dev"
-KFEATURE_u-boot[DEBIAN_DEPENDS] = "libubootenv-tool, u-boot-tools"
-KFEATURE_u-boot[DEPENDS] = "${U_BOOT}"
+KFEATURE_u-boot[DEBIAN_DEPENDS] = "${@ 'libubootenv0.1, u-boot-${MACHINE}-config' \
+ if d.getVar("USE_U_BOOT_CONFIG", True) == "true" \
+ else 'libubootenv0.1'}"
+KFEATURE_u-boot[DEPENDS] = "${U_BOOT} libubootenv"
KFEATURE_u-boot[KCONFIG_SNIPPETS] = "file://swupdate_defconfig_u-boot.snippet"

SWUPDATE_LUASCRIPT ?= "swupdate_handlers.lua"
@@ -73,4 +76,3 @@ python do_check_bootloader () {
bb.warn("swupdate: BOOTLOADER set to incompatible value: " + bootloader)
}
addtask check_bootloader before do_fetch
-
diff --git a/recipes-core/swupdate/swupdate.bb b/recipes-core/swupdate/swupdate.bb
index b4d64fe..526c72f 100644
--- a/recipes-core/swupdate/swupdate.bb
+++ b/recipes-core/swupdate/swupdate.bb
@@ -24,8 +24,6 @@ SRC_URI += "file://debian \
file://${DEFCONFIG} \
file://${PN}.cfg"

-DEPENDS += "libubootenv"
-
DEBIAN_DEPENDS = "${shlibs:Depends}, ${misc:Depends}"

inherit dpkg


Applied, thanks.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


[isar-cip-core][PATCH] Use u-boot-config instead of tools

Quirin Gylstorff
 

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

Swupdate requires libubootenv0.1 and u-boot-config to access the u-boot
environment. u-boot-config adds the configuration files.

Add the flag `USE_U_BOOT_CONFIG` to deactivate the addition of
'u-boot-${MACHINE}-config.' If the image uses an upstream u-boot binary
(e.g. [1]) remove the package by setting `USE_U_BOOT_CONFIG` to `false`.

[1]: https://packages.debian.org/buster/u-boot-omap

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
classes/swupdate-config.bbclass | 8 +++++---
recipes-core/swupdate/swupdate.bb | 2 --
2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/classes/swupdate-config.bbclass b/classes/swupdate-config.bbclass
index dd0317f..9909113 100644
--- a/classes/swupdate-config.bbclass
+++ b/classes/swupdate-config.bbclass
@@ -45,10 +45,13 @@ KFEATURE_ubi[KCONFIG_SNIPPETS] = "file://swupdate_defconfig_ubi.snippet"

KFEATURE_DEPS[ubi] = "mtd"

+USE_U_BOOT_CONFIG ?= "true"
KFEATURE_u-boot = ""
KFEATURE_u-boot[BUILD_DEB_DEPENDS] = "libubootenv-dev"
-KFEATURE_u-boot[DEBIAN_DEPENDS] = "libubootenv-tool, u-boot-tools"
-KFEATURE_u-boot[DEPENDS] = "${U_BOOT}"
+KFEATURE_u-boot[DEBIAN_DEPENDS] = "${@ 'libubootenv0.1, u-boot-${MACHINE}-config' \
+ if d.getVar("USE_U_BOOT_CONFIG", True) == "true" \
+ else 'libubootenv0.1'}"
+KFEATURE_u-boot[DEPENDS] = "${U_BOOT} libubootenv"
KFEATURE_u-boot[KCONFIG_SNIPPETS] = "file://swupdate_defconfig_u-boot.snippet"

SWUPDATE_LUASCRIPT ?= "swupdate_handlers.lua"
@@ -73,4 +76,3 @@ python do_check_bootloader () {
bb.warn("swupdate: BOOTLOADER set to incompatible value: " + bootloader)
}
addtask check_bootloader before do_fetch
-
diff --git a/recipes-core/swupdate/swupdate.bb b/recipes-core/swupdate/swupdate.bb
index b4d64fe..526c72f 100644
--- a/recipes-core/swupdate/swupdate.bb
+++ b/recipes-core/swupdate/swupdate.bb
@@ -24,8 +24,6 @@ SRC_URI += "file://debian \
file://${DEFCONFIG} \
file://${PN}.cfg"

-DEPENDS += "libubootenv"
-
DEBIAN_DEPENDS = "${shlibs:Depends}, ${misc:Depends}"

inherit dpkg
--
2.20.1


Re: [isar-cip-core][PATCH] linux: Fix warning if USE_CIP_KERNEL_CONFIG is not defined

Quirin Gylstorff
 

On 1/29/21 3:18 PM, Jan Kiszka wrote:
On 29.01.21 13:22, Gylstorff Quirin wrote:


On 1/28/21 3:13 PM, Jan Kiszka wrote:
On 25.01.21 19:23, Gylstorff Quirin wrote:


On 1/25/21 6:28 PM, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
USE_CIP_KERNEL_CONFIG may not be defined in all layers using the
isar-cip-core layer, so we end up with the following warnings:

WARNING:
/work/cip-core/recipes-kernel/linux/linux-cip_4.19.140-cip33.bb:
Unable to get checksum for linux-cip SRC_URI entry
${MACHINE}_defconfig: file could not be found
WARNING:
/work/cip-core/recipes-kernel/linux/linux-cip-rt_4.4.231-cip47-rt30.bb:
Unable
to get checksum for linux-cip-rt SRC_URI entry ${MACHINE}_defconfig:
file could not be found
WARNING:
/work/cip-core/recipes-kernel/linux/linux-cip_4.4.230-cip47.bb: Unable
to get checksum for linux-cip SRC_URI entry ${MACHINE}_defconfig: file
could not be found
WARNING:
/work/cip-core/recipes-kernel/linux/linux-cip-rt_4.19.135-cip31-rt13.bb:

Unable to get checksum for linux-cip-rt SRC_URI entry
${MACHINE}_defconfig: file could not be found

${MACHINE}_defconfig needs to be added to SRC_URI only if
USE_CIP_KERNEL_CONFIG is set to "1".

There is one in-tree machine definition (the bbb) that does not set
USE_CIP_KERNEL_CONFIG to "1" but still needs the defconfig added.
A machine specific SRC_URI was set to take care of that.

Closes #7.

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---

Some additional notes:
    - That's my first contribution, so review carefully ;-)
    - Both branches (master, next) are affected
    - The gitlab MR: [1]
    - The gitlab issue: [2]

    [1]
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/10


    [2]
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/7



   recipes-kernel/linux/linux-cip-common.inc | 15 ++++++---------
   1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/recipes-kernel/linux/linux-cip-common.inc
b/recipes-kernel/linux/linux-cip-common.inc
index 6db1d1d..9aca9af 100644
--- a/recipes-kernel/linux/linux-cip-common.inc
+++ b/recipes-kernel/linux/linux-cip-common.inc
@@ -11,21 +11,18 @@

   KERNEL_DEFCONFIG ?= "${MACHINE}_defconfig"

-def conditional(variable, checkvalue, truevalue, falsevalue, d):
-    if d.getVar(variable) == checkvalue:
-        return truevalue
-    else:
-        return falsevalue
-
   require recipes-kernel/linux/linux-custom.inc

   SRC_URI += " \
      https://gitlab.com/cip-project/cip-kernel/linux-cip/-/archive/v$
\
       "

-SRC_URI_append = " ${@conditional("USE_CIP_KERNEL_CONFIG", "1", \
-
"git://gitlab.com/cip-project/cip-kernel/cip-kernel-config.git;protocol=https;destsuffix=cip-kernel-config;name=cip-kernel-config",

\
-    "file://${KERNEL_DEFCONFIG}",d)}"
The easier way would have been to delete file://${KERNEL_DEFCONFIG}
instead of create the logic anew. The conditional function should allow
an empty string.
I'm not yet sure which string should be empty and would break with the
new version. Can you elaborate?

Jan

I will skip the url.
You could have written

SRC_URI_append =  "${@conditional("USE_CIP_KERNEL_CONFIG",
"1","git://...","",d)"

instead of

SRC_URI_append = "${@ "git://..." if d.getVar('USE_CIP_KERNEL_CONFIG')
== '1' else ''}"

The result is the same. The second method saves some code in form of a
function.
Means you are fine with Florian's patch? If there are no downsides, I
would prefer that pattern as well.
Jan
I'm fine with Florian's patch.

Quirin


Quirin

+SRC_URI_append = "${@
"git://gitlab.com/cip-project/cip-kernel/cip-kernel-config.git;protocol=https;destsuffix=cip-kernel-config;name=cip-kernel-config"

\
+    if d.getVar('USE_CIP_KERNEL_CONFIG') == '1' else '' \
+    }"
+
+SRC_URI_append_bbb = "file://${KERNEL_DEFCONFIG}"
+
   SRCREV_cip-kernel-config ?=
"7f2930b9667372f94f2edb42ca9cf6fc6c0aed50"

   S = "${WORKDIR}/linux-cip-v${PV}"
--
2.29.2
Quirin

1341 - 1360 of 7512