Date   

Re: RT Testing

Kazuhiro Hayashi
 

Hello Chris,

Thank you for your updates!

Hello Pavel, Hayashi-san, Jan, Daniel,
[...]

Currently there is an issue with the way that the cyclic test case results are shown (i.e. they aren't) in LAVA due to
a change [0] made to Linaro's cyclictest.sh.
That means that the test parsing now depends on Python, which isn't included in the cip-core RFS [1] that is currently
being used.

Do either of the CIP Core profiles include Python support?
At the moment, we've just started creating the supported package list, so I cannot clearly say Yes.
However, at least, the both profiles can create an image including python only for testing
because the python packages are already provided in upstream projects (isar, meta-debian).

Whether CIP Core provides Python packages or not depends on
what kind of packages will be proposed (requested) by CIP WGs in future.
Currently, several packages which depend on Python packages would be
included in the next proposal from security WG (under review now).

BTW, it would be better to confirm which Python version (2.7 or 3) that cyclictest.sh depends on.
Do you know anything about this?

Kazu


Linaro test-definitions [2] have the following tests marked within the preempt-rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml

Which of the above would be valuable to run on CIP RT Kernels?

A while back Daniel Wagner also did some work on a Jitterdebugger test [3], but it hasn't been merged yet and I'm not
sure what the current status is. Any updates Daniel?

Is anyone able to provide RT config/defconfigs for the x86 and arm boards in the Mentor lab? Or BBB, QEMU etc.? (assuming
that the hardware is suitable).


[0]
https://github.com/Linaro/test-definitions/commit/4b5c46f275632932b3045f2ee16ad9cae5bb482d#diff-c724b852b75aefda2cc3
505c4517828dR50
[1] https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-core/iwg20m/core-image-minimal-iwg20m.tar.gz
[2] https://github.com/Linaro/test-definitions/blob/master/automated/linux
[3] https://github.com/igaw/test-definitions/blob/preempt-rt/automated/linux/jitterdebugger/jitterdebugger.yaml

Kind regards, Chris


CIP IRC weekly meeting today

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

US-West US-East UK DE TW JP
01:00 04:00 09:00 10:00 17:00 18:00

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

Last week's meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/01/cip.2020-01-09-09.00.log.html

Agenda:

* Action item
1. Combine rootfilesystem with kselftest binary - Iwamatsu-san
2. Document a process on how to add tests to the CIP test setup - patersonc
3. Arrangement of F2F Kernel Meeting in Nuremberg - masashi910
4. Add config for qemux86-64 and BBB to both 4.4 and 4.19 - Iwamatsu-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* 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.


RT Testing

Chris Paterson
 

Hello Pavel, Hayashi-san, Jan, Daniel,

Addressing this email to all of you as both RT and CIP Core are involved.

I started to look into RT testing in more detail today.

I've created an RT configuration for the RZ/G1 boards:
https://gitlab.com/patersonc/cip-kernel-config/blob/chris/add_renesas_rt_configs/4.4.y-cip-rt/arm/renesas_shmobile-rt_defconfig
I'll do something similar for the RZ/G2 boards soon.

Built it with linux-4.4.y-cip-rt and run cyclic test:
https://lava.ciplatform.org/scheduler/job/9828
Times look okay to an rt-untrained eye:
T: 0 ( 1169) P:98 I:1000 C: 59993 Min: 13 Act: 16 Avg: 16 Max: 33

Compared to a run with linux-4.4.y-cip:
https://lava.ciplatform.org/scheduler/job/9829
T: 0 ( 938) P:98 I:1000 C: 6000 Min: 1618 Act: 9604 Avg: 9603 Max: 14550

Pavel, does the above look okay/useful to you? Or is cyclictest not worth running unless there is some load on the system?

Currently there is an issue with the way that the cyclic test case results are shown (i.e. they aren't) in LAVA due to a change [0] made to Linaro's cyclictest.sh.
That means that the test parsing now depends on Python, which isn't included in the cip-core RFS [1] that is currently being used.

Do either of the CIP Core profiles include Python support?

Linaro test-definitions [2] have the following tests marked within the preempt-rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml

Which of the above would be valuable to run on CIP RT Kernels?

A while back Daniel Wagner also did some work on a Jitterdebugger test [3], but it hasn't been merged yet and I'm not sure what the current status is. Any updates Daniel?

Is anyone able to provide RT config/defconfigs for the x86 and arm boards in the Mentor lab? Or BBB, QEMU etc.? (assuming that the hardware is suitable).


[0] https://github.com/Linaro/test-definitions/commit/4b5c46f275632932b3045f2ee16ad9cae5bb482d#diff-c724b852b75aefda2cc3505c4517828dR50
[1] https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-core/iwg20m/core-image-minimal-iwg20m.tar.gz
[2] https://github.com/Linaro/test-definitions/blob/master/automated/linux
[3] https://github.com/igaw/test-definitions/blob/preempt-rt/automated/linux/jitterdebugger/jitterdebugger.yaml

Kind regards, Chris


Re: [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package Proposal #1 (Security packages))

Kento Yoshida
 

Please try if you need :)
It's convenience for us. Thank you.

The security working group will have a bi-weekly meeting tomorrow, and we'll decide the packages that are proposed as the proposal of this time.
I'll create the proposal using the following option after that meeting.

Kent

-----Original Message-----
From: kazuhiro3.hayashi@... <kazuhiro3.hayashi@...>
Sent: Tuesday, January 14, 2020 1:26 PM
To: Kento Yoshida <kento.yoshida.wz@...>; jan.kiszka@...;
cip-dev@...; dinesh.kumar@...
Subject: RE: [cip-dev] [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package
Proposal #1 (Security packages))

Hello Kent, Dinesh,

Here is a minor update of generate-proposal.py:
"-a" option is newly supported to append packages to the existing proposal file.
$ ./generate-proposal.py -a existing-proposal.yml

It may be useful when users want to restart creating proposal from an existing
incomplete file, or append several packages to an existing proposal file which
another person created, etc.

PDP revision is updated to 3.1, but all functions are compatible with 3.0.
If a same source package is appended by -a option, the old proposal information in
the existing-proposal will be overwritten.

Please try if you need :)

Best regards,
Kazu


Hi,

Could you try the updated script to create a new proposal including
the origin 21 security packages + their dependencies?
Sure. Now, the security working group is re-checking the proposed packages and
their dependency.
Actually, our original proposal consisted of a non-well-maintained package.
In addition, as Jan mentioned, there was also waste such as both python 2.7 and
3 are included.
We are preparing a proposal without these defect.

Best regards,
Kent
-----Original Message-----
From: kazuhiro3.hayashi@...
<kazuhiro3.hayashi@...>
Sent: Thursday, January 9, 2020 9:05 PM
To: jan.kiszka@...; Kento Yoshida
<kento.yoshida.wz@...>; cip-dev@...;
dinesh.kumar@...
Subject: RE: [cip-dev] [cip-core] Update PDP to 3.0 (was: RE:
[cip-core] Package Proposal #1 (Security packages))

Hello,

PDP and the helper scripts have been updated to 3.0.

* Add a rule to satisfy all run-time dependencies for the proposed
binary packages

https://gitlab.com/cip-project/cip-core/cip-pkglist/commit/6867b5b41b
cf618d4b
e3955f302df8dbb3114050#c284394f3826d472fb70f72e2ef4ef9fe9606660_8
0
_78
* Add a script (check_deps.py) to check the dependencies
* (Minor update): Caching CVE and apt data to reduce the
initialization time of generate-proposal.py

Kent, Dinesh,

Could you try the updated script to create a new proposal including
the origin 21 security packages + their dependencies?

Please let me know if you find some issues.

Best regards,
Kazu


Hello CIP core members,

If you have any objections about the following approach, please let
me know *by the next IRC meeting (on Jan 9th)*.

We are already updating cip-pkglist based on the following approach
and will create the new "proposal.yml" for the security packages ASAP.

Best regards,
Kazu


Hello Jan, Kent, and all CIP core members,

Anyway, I will create and share a sample of proposal.yml with
the flat package set, please review that and confirm if it
matches your opinion of
the "CIP maintained packages".

I would like to confirm that the following solution can satisfy our
requirements.

Examples:
* proposal*.yml: The package proposal file that a proposer is
creating using
"generate-proposal.py"
* pkglist_buster.yml: Existing "supported" package list, that was
created/updated before (See the attached files. All information
except "bin_pkgs" are dropped to simplify.)

Solution:
0. Use the same YML format as Kent's proposal (Don't change the
current YML format) 1. Add a new script "check-deps.py" to check
if binary
packages in "depends:" are included in
either "proposal.yml" or "pkglist_buster.yml"
2. "generate-proposal.py" runs "check-deps.py" at the end and
proposer needs
to
add more packages to "proposal.yml" if unmet dependencies are
reported
by "check-deps.py"
3. The proposer can request the package proposal only if
"check-deps.py" reports nothing

In the attached examples, the initial proposal "proposal1.yml"
has an unmet
dependency (= lsb-base).
"check-deps.py" reports this then the proposer add "lsb-base"
source package and binary package to the second proposal
"proposal2.yml", which satisfies all run-time dependencies so can be
proposed to cip-dev.

What do you think?
If OK, we will update the scripts in
https://gitlab.com/cip-project/cip-core/cip-pkglist
based on the above solution.

Best regards,
Kazu


Hello Jan and CIP core members,

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@... wrote:
suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't
we agree on
listing them flat?
This, e.g., pulls python, currently even v2 - anything
but a trivial package. Or did I miss that we have this
in
our list already?

@kazuhiro3.hayashi@... and @Dinesh Kumar, Do
you need a script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of
top-lists are still in preparation and are under
investigation
in the security working group.
The automatic outputs of the script have been used as it
is for the
dependencies package displayed in this proposal.

We can only decide about package sets which have their
runtime dependencies already fulfilled with the existing
package set (where is that now, BTW?) or include these
dependencies in
the set.

I'm assuming the "existing package set" is the list of
packages that are
already accepted by CIP.
If so, there is no such list because this is the first proposal.
Then let's define that base (minimal debootstrap) first
before adding further packages.
OK, let's start from defining this base.



Also, it's difficult for me to agree with the opinion that
"all runtime dependencies must be fullfilled with the
existing package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view
(debconf, debian-archive-keyring, etc.)
Anything that a Debian package requires needs to be present -
otherwise the package becomes broken. I can't imagine we want
to propose that to our users. Weaker dependencies are obviously
optional.

Yes, anything required by Debian package needs to be "present",
but it is not always necessary to "maintain" their source (e.g.
Request them to Debian Extended LTS).

I think that there are two kinds in our "support" levels:
(1) Just make the package available (present) in CIP at least
10 years
(2) (1) + Keep watching the latest bugs and security issues and
fixing them aggressively I was understanding that the CIP
package list we are discussing is for clarifying the packages like (2).
However, if no one in CIP care about the difference between (1)
and (2), we should simply define the package list including all
binary package
dependencies, like Jan mentioned.


If we should run into a package that seems to require more
than it should, let's improve it by proposing a break-up
upstream. Or by repackaging it in meta-debian /
isar-cip-core. But that should come first before proposing it here.
It would be better if the both profiles can have such improved
packages, but actually changing upstream (Debian) takes much
time and effort and repackaging by ourselves may bring big
impacts to package compatibilities, especially in the generic profile.


2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal
pulls around 90 packages finally)
Anything in that range still seems reasonable from a
maintenance perspective - provided there are no "challenging"
packages included. But we should still check if that number
is seriously needed,
though.

OK, let's discuss about this number in the future proposal.

Anyway, I will create and share a sample of proposal.yml with
the flat package set, please review that and confirm if it
matches your opinion of
the "CIP maintained packages".

Kazu


Jan


I only checked
suricata because of the outstanding python dependency, but
there might be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages,
PDP steps, and
the format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements
of all
members become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@...> On
Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...;
cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1
(Security packages)

On 09.12.19 14:54, kazuhiro3.hayashi@... wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of
the attached
package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob
/ma ster/doc/pd p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy
their required
features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please
show the reasons
as well.

Due Date: December 23rd
(We can extend this due date if more time required for
reviews, please let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification
for CR 2.11,
2.11(1)
security_criteria: network::server,
network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't
we agree on listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that
we have this in our
list already?

Jan

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

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package Proposal #1 (Security packages))

Kazuhiro Hayashi
 

Hello Kent, Dinesh,

Here is a minor update of generate-proposal.py:
"-a" option is newly supported to append packages to the existing proposal file.
$ ./generate-proposal.py -a existing-proposal.yml

It may be useful when users want to restart creating proposal from an existing incomplete file,
or append several packages to an existing proposal file which another person created, etc.

PDP revision is updated to 3.1, but all functions are compatible with 3.0.
If a same source package is appended by -a option, the old proposal information
in the existing-proposal will be overwritten.

Please try if you need :)

Best regards,
Kazu


Hi,

Could you try the updated script to create a new proposal including the origin 21
security packages + their dependencies?
Sure. Now, the security working group is re-checking the proposed packages and their dependency.
Actually, our original proposal consisted of a non-well-maintained package.
In addition, as Jan mentioned, there was also waste such as both python 2.7 and 3 are included.
We are preparing a proposal without these defect.

Best regards,
Kent
-----Original Message-----
From: kazuhiro3.hayashi@... <kazuhiro3.hayashi@...>
Sent: Thursday, January 9, 2020 9:05 PM
To: jan.kiszka@...; Kento Yoshida <kento.yoshida.wz@...>;
cip-dev@...; dinesh.kumar@...
Subject: RE: [cip-dev] [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package
Proposal #1 (Security packages))

Hello,

PDP and the helper scripts have been updated to 3.0.

* Add a rule to satisfy all run-time dependencies for the proposed binary packages

https://gitlab.com/cip-project/cip-core/cip-pkglist/commit/6867b5b41bcf618d4b
e3955f302df8dbb3114050#c284394f3826d472fb70f72e2ef4ef9fe9606660_80
_78
* Add a script (check_deps.py) to check the dependencies
* (Minor update): Caching CVE and apt data to reduce the initialization time of
generate-proposal.py

Kent, Dinesh,

Could you try the updated script to create a new proposal including the origin 21
security packages + their dependencies?

Please let me know if you find some issues.

Best regards,
Kazu


Hello CIP core members,

If you have any objections about the following approach, please let me
know *by the next IRC meeting (on Jan 9th)*.

We are already updating cip-pkglist based on the following approach
and will create the new "proposal.yml" for the security packages ASAP.

Best regards,
Kazu


Hello Jan, Kent, and all CIP core members,

Anyway, I will create and share a sample of proposal.yml with the
flat package set, please review that and confirm if it matches your opinion of
the "CIP maintained packages".

I would like to confirm that the following solution can satisfy our requirements.

Examples:
* proposal*.yml: The package proposal file that a proposer is creating using
"generate-proposal.py"
* pkglist_buster.yml: Existing "supported" package list, that was
created/updated before (See the attached files. All information
except "bin_pkgs" are dropped to simplify.)

Solution:
0. Use the same YML format as Kent's proposal (Don't change the
current YML format) 1. Add a new script "check-deps.py" to check if binary
packages in "depends:" are included in
either "proposal.yml" or "pkglist_buster.yml"
2. "generate-proposal.py" runs "check-deps.py" at the end and proposer needs
to
add more packages to "proposal.yml" if unmet dependencies are reported
by "check-deps.py"
3. The proposer can request the package proposal only if
"check-deps.py" reports nothing

In the attached examples, the initial proposal "proposal1.yml" has an unmet
dependency (= lsb-base).
"check-deps.py" reports this then the proposer add "lsb-base" source
package and binary package to the second proposal "proposal2.yml",
which satisfies all run-time dependencies so can be proposed to cip-dev.

What do you think?
If OK, we will update the scripts in
https://gitlab.com/cip-project/cip-core/cip-pkglist
based on the above solution.

Best regards,
Kazu


Hello Jan and CIP core members,

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@... wrote:
suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on
listing them flat?
This, e.g., pulls python, currently even v2 - anything but
a trivial package. Or did I miss that we have this
in
our list already?

@kazuhiro3.hayashi@... and @Dinesh Kumar, Do you
need a script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of
top-lists are still in preparation and are under
investigation
in the security working group.
The automatic outputs of the script have been used as it is for the
dependencies package displayed in this proposal.

We can only decide about package sets which have their
runtime dependencies already fulfilled with the existing
package set (where is that now, BTW?) or include these dependencies in
the set.

I'm assuming the "existing package set" is the list of packages that are
already accepted by CIP.
If so, there is no such list because this is the first proposal.
Then let's define that base (minimal debootstrap) first before
adding further packages.
OK, let's start from defining this base.



Also, it's difficult for me to agree with the opinion that
"all runtime dependencies must be fullfilled with the existing
package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view (debconf,
debian-archive-keyring, etc.)
Anything that a Debian package requires needs to be present -
otherwise the package becomes broken. I can't imagine we want to
propose that to our users. Weaker dependencies are obviously optional.
Yes, anything required by Debian package needs to be "present",
but it is not always necessary to "maintain" their source (e.g.
Request them to Debian Extended LTS).

I think that there are two kinds in our "support" levels:
(1) Just make the package available (present) in CIP at least 10
years
(2) (1) + Keep watching the latest bugs and security issues and
fixing them aggressively I was understanding that the CIP package
list we are discussing is for clarifying the packages like (2).
However, if no one in CIP care about the difference between (1)
and (2), we should simply define the package list including all binary package
dependencies, like Jan mentioned.


If we should run into a package that seems to require more than
it should, let's improve it by proposing a break-up upstream. Or
by repackaging it in meta-debian / isar-cip-core. But that
should come first before proposing it here.
It would be better if the both profiles can have such improved
packages, but actually changing upstream (Debian) takes much time
and effort and repackaging by ourselves may bring big impacts to
package compatibilities, especially in the generic profile.


2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal
pulls around 90 packages finally)
Anything in that range still seems reasonable from a maintenance
perspective - provided there are no "challenging" packages
included. But we should still check if that number is seriously needed,
though.

OK, let's discuss about this number in the future proposal.

Anyway, I will create and share a sample of proposal.yml with the
flat package set, please review that and confirm if it matches your opinion of
the "CIP maintained packages".

Kazu


Jan


I only checked
suricata because of the outstanding python dependency, but
there might be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages, PDP steps, and
the format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all
members become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@...> On
Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...;
cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1
(Security packages)

On 09.12.19 14:54, kazuhiro3.hayashi@... wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached
package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/ma
ster/doc/pd p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required
features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons
as well.

Due Date: December 23rd
(We can extend this due date if more time required for
reviews, please let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification for CR 2.11,
2.11(1)
security_criteria: network::server, network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we
agree on listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that we have this in our
list already?

Jan

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

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [isar-cip-core PATCH] classes/wic-targz-img: add dependency between targz-img and wic-img

Jan Kiszka
 

On 09.01.20 15:30, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@...>
Add a dependency between targz_image and wic_image to avoid
an error during the generation of the targz image as wic modifies
the rootfs.
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
classes/wic-targz-img.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/classes/wic-targz-img.bbclass b/classes/wic-targz-img.bbclass
index 4e9f89d..1327840 100644
--- a/classes/wic-targz-img.bbclass
+++ b/classes/wic-targz-img.bbclass
@@ -11,3 +11,5 @@
inherit wic-img
inherit targz-img
+
+addtask do_targz_image after do_wic_image
Applied to next, thanks.

Jan

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


Re: [isar-cip-core PATCH v2 0/5] Use cip-kernel-config for images

Jan Kiszka
 

On 09.01.20 09:52, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@...>
Use the kernel_defconfigs
from https://gitlab.com/cip-project/cip-kernel/cip-kernel-config
to build the images for rzg2m, iwg20m and simatic-ipc227e.
The final patch is necessary until isar upstream will apply it.
Version 2:
- Add the missing protocol to download the repository cip-kernel-config
Quirin Gylstorff (5):
recipes-kernel/linux: allow the usage of the cip-kernel-config
Use renesas-config for hihope-rzg2m
Use renesas_shmobile_defconfig for iwg20m
Use siemens_ipc227e_defconfig for simatic-ipc227e
kas: patch isar for iwg20m with kernel 4.4
conf/machine/hihope-rzg2m.conf | 3 +-
conf/machine/iwg20m.conf | 2 +
conf/machine/simatic-ipc227e.conf | 2 +
...d-path-to-image-for-arm-kernels-4.12.patch | 37 +++++++++++++++++++
kas.yml | 9 ++++-
recipes-kernel/linux/linux-cip-common.inc | 18 +++++++--
6 files changed, 65 insertions(+), 6 deletions(-)
create mode 100644 isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch
Applied to next, just minimally massaged the style of patch 1.

Thanks,
Jan

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


[isar-cip-core PATCH] ci: Adjust deploy-cip-core.sh to new kernel build

Jan Kiszka
 

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

The path structure has changed, multiple times by now in fact.

Signed-off-by: Jan Kiszka <jan.kiszka@...>
---
scripts/deploy-cip-core.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/deploy-cip-core.sh b/scripts/deploy-cip-core.sh
index e5c09ef..b8a1cd3 100755
--- a/scripts/deploy-cip-core.sh
+++ b/scripts/deploy-cip-core.sh
@@ -39,5 +39,5 @@ aws s3 cp --no-progress $KERNEL_IMAGE s3://download.cip-project.org/cip-core/$TA
aws s3 cp --no-progress $BASE_PATH-initrd.img s3://download.cip-project.org/cip-core/$TARGET/

if [ -n "$DTB" ]; then
- aws s3 cp --no-progress build/tmp/work/cip-core-*/linux-cip-*/repack/linux-image/usr/lib/linux-image-*/$DTB s3://download.cip-project.org/cip-core/$TARGET/
+ aws s3 cp --no-progress build/tmp/work/cip-core-*/linux-cip/*/linux-cip-*/debian/linux-image-cip/usr/lib/linux-image-*/$DTB s3://download.cip-project.org/cip-core/$TARGET/
fi
--
2.16.4


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


Re: isar-cip-core testing

Chris Paterson
 

Hello Quirin,

From: Gylstorff Quirin <quirin.gylstorff@...>
Sent: 10 January 2020 17:10

Hi,

I started to implement testing of isar-cip-core with linux-cip-ci.
You can find the prototype at [0].
Thank you for sharing this.

Once you're happy with it, please sent a merge request to linux-cip-ci and I'll help review it in detail.
I've added you as a developer to the project, so you can add a branch directly to linux-cip-ci, which means the CI will be able to run.

Currently I can submit test to the my local LAVA Lab and the first
boot test has run successfully (iwg20m).
Huzzah!

Kind regards, Chris



[0]
https://gitlab.com/Quirin.Gy/linux-cip-ci/tree/feature/add-isar-cip-testing

Kind regards
Quirin


Re: Difference between v4.19.88-cip16-rebase..v4.19.88-cip16 was Re: Getting older -cip-rebase versions

Chris Paterson
 

From: cip-dev <cip-dev-bounces@...> On Behalf Of Ben
Hutchings
Sent: 10 January 2020 18:30

On Wed, 2020-01-08 at 04:02 +0000, nobuhiro1.iwamatsu@...
wrote:
[...]
Any idea what is going on there? Which version is ok and which should
be adjusted?
I already fixed these issue on local repository.
Since first issue is on -rebase branch, I don't think it will have a big impact.
Second issue is on cip branch, I will need to do force push and re-tag.

Also, to avoid the same problem, I will add a step to check the differences
when rebase and merge.

Anyone who has pulled the wrong tags already won't see updated tags.
So at this point I would suggest using new names for the fixed tags
(e.g. -rebase-2).

Maybe it is worthwhile to test in CI for the -rc repository that the
rebased branches match the corresponding non-rebased branches? (It is
probably not reasonable to require that this is true at other times.)
Sounds like a plan. I'll add it to my backlog, unless anyone else is keen.

Kind regards, Chris


Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Difference between v4.19.88-cip16-rebase..v4.19.88-cip16 was Re: Getting older -cip-rebase versions

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2020-01-08 at 04:02 +0000, nobuhiro1.iwamatsu@... wrote:
[...]
Any idea what is going on there? Which version is ok and which should
be adjusted?
I already fixed these issue on local repository.
Since first issue is on -rebase branch, I don't think it will have a big impact.
Second issue is on cip branch, I will need to do force push and re-tag.

Also, to avoid the same problem, I will add a step to check the differences when rebase and merge.
Anyone who has pulled the wrong tags already won't see updated tags.
So at this point I would suggest using new names for the fixed tags
(e.g. -rebase-2).

Maybe it is worthwhile to test in CI for the -rc repository that the
rebased branches match the corresponding non-rebased branches? (It is
probably not reasonable to require that this is true at other times.)

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


isar-cip-core testing

Quirin Gylstorff
 

Hi,

I started to implement testing of isar-cip-core with linux-cip-ci.
You can find the prototype at [0].
Currently I can submit test to the my local LAVA Lab and the first
boot test has run successfully (iwg20m).


[0] https://gitlab.com/Quirin.Gy/linux-cip-ci/tree/feature/add-isar-cip-testing

Kind regards
Quirin


[ANNOUNCE] v4.19.90-cip16-rt6

Pavel Machek
 


[ANNOUNCE] Release v4.19.94-cip18 and v4.4.208-cip41

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.94-cip18 and v4.4.208-cip41.
The linux-4.19.y-cip tree has been updated base version from 4.19.91 to 4.19.94.
And the linux-4.4.y-cip tree has been updated base version from 4.4.206 to 4.4.208,
and added support R8A7744 to rcar-du driver.

You can get this release via the git tree at:

v4.19.94-cip18:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
b17c26ec7d8aef9ec4bc13e564fb4aea05e22486
added commits:
CIP: Bump version suffix to -cip18 after merge from stable

v4.4.208-cip41:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
ba8dc2a25994d1d17872b641d4e6ff50ea9d9217
added commits:
CIP: Bump version suffix to -cip41 after merge from stable
ARM: dts: r8a7744: Add DU support
drm: rcar-du: Add R8A7744 support
dt-bindings: display: renesas: du: Document the r8a7744 bindings

Best regards,
Nobuhiro


Re: [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package Proposal #1 (Security packages))

Kento Yoshida
 

Hi,

Could you try the updated script to create a new proposal including the origin 21
security packages + their dependencies?
Sure. Now, the security working group is re-checking the proposed packages and their dependency.
Actually, our original proposal consisted of a non-well-maintained package.
In addition, as Jan mentioned, there was also waste such as both python 2.7 and 3 are included.
We are preparing a proposal without these defect.

Best regards,
Kent
-----Original Message-----
From: kazuhiro3.hayashi@... <kazuhiro3.hayashi@...>
Sent: Thursday, January 9, 2020 9:05 PM
To: jan.kiszka@...; Kento Yoshida <kento.yoshida.wz@...>;
cip-dev@...; dinesh.kumar@...
Subject: RE: [cip-dev] [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package
Proposal #1 (Security packages))

Hello,

PDP and the helper scripts have been updated to 3.0.

* Add a rule to satisfy all run-time dependencies for the proposed binary packages

https://gitlab.com/cip-project/cip-core/cip-pkglist/commit/6867b5b41bcf618d4b
e3955f302df8dbb3114050#c284394f3826d472fb70f72e2ef4ef9fe9606660_80
_78
* Add a script (check_deps.py) to check the dependencies
* (Minor update): Caching CVE and apt data to reduce the initialization time of
generate-proposal.py

Kent, Dinesh,

Could you try the updated script to create a new proposal including the origin 21
security packages + their dependencies?

Please let me know if you find some issues.

Best regards,
Kazu


Hello CIP core members,

If you have any objections about the following approach, please let me
know *by the next IRC meeting (on Jan 9th)*.

We are already updating cip-pkglist based on the following approach
and will create the new "proposal.yml" for the security packages ASAP.

Best regards,
Kazu


Hello Jan, Kent, and all CIP core members,

Anyway, I will create and share a sample of proposal.yml with the
flat package set, please review that and confirm if it matches your opinion of
the "CIP maintained packages".

I would like to confirm that the following solution can satisfy our requirements.

Examples:
* proposal*.yml: The package proposal file that a proposer is creating using
"generate-proposal.py"
* pkglist_buster.yml: Existing "supported" package list, that was
created/updated before (See the attached files. All information
except "bin_pkgs" are dropped to simplify.)

Solution:
0. Use the same YML format as Kent's proposal (Don't change the
current YML format) 1. Add a new script "check-deps.py" to check if binary
packages in "depends:" are included in
either "proposal.yml" or "pkglist_buster.yml"
2. "generate-proposal.py" runs "check-deps.py" at the end and proposer needs
to
add more packages to "proposal.yml" if unmet dependencies are reported
by "check-deps.py"
3. The proposer can request the package proposal only if
"check-deps.py" reports nothing

In the attached examples, the initial proposal "proposal1.yml" has an unmet
dependency (= lsb-base).
"check-deps.py" reports this then the proposer add "lsb-base" source
package and binary package to the second proposal "proposal2.yml",
which satisfies all run-time dependencies so can be proposed to cip-dev.

What do you think?
If OK, we will update the scripts in
https://gitlab.com/cip-project/cip-core/cip-pkglist
based on the above solution.

Best regards,
Kazu


Hello Jan and CIP core members,

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@... wrote:
suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on
listing them flat?
This, e.g., pulls python, currently even v2 - anything but
a trivial package. Or did I miss that we have this
in
our list already?

@kazuhiro3.hayashi@... and @Dinesh Kumar, Do you
need a script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of
top-lists are still in preparation and are under
investigation
in the security working group.
The automatic outputs of the script have been used as it is for the
dependencies package displayed in this proposal.

We can only decide about package sets which have their
runtime dependencies already fulfilled with the existing
package set (where is that now, BTW?) or include these dependencies in
the set.

I'm assuming the "existing package set" is the list of packages that are
already accepted by CIP.
If so, there is no such list because this is the first proposal.
Then let's define that base (minimal debootstrap) first before
adding further packages.
OK, let's start from defining this base.



Also, it's difficult for me to agree with the opinion that
"all runtime dependencies must be fullfilled with the existing
package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view (debconf,
debian-archive-keyring, etc.)
Anything that a Debian package requires needs to be present -
otherwise the package becomes broken. I can't imagine we want to
propose that to our users. Weaker dependencies are obviously optional.
Yes, anything required by Debian package needs to be "present",
but it is not always necessary to "maintain" their source (e.g.
Request them to Debian Extended LTS).

I think that there are two kinds in our "support" levels:
(1) Just make the package available (present) in CIP at least 10
years
(2) (1) + Keep watching the latest bugs and security issues and
fixing them aggressively I was understanding that the CIP package
list we are discussing is for clarifying the packages like (2).
However, if no one in CIP care about the difference between (1)
and (2), we should simply define the package list including all binary package
dependencies, like Jan mentioned.


If we should run into a package that seems to require more than
it should, let's improve it by proposing a break-up upstream. Or
by repackaging it in meta-debian / isar-cip-core. But that
should come first before proposing it here.
It would be better if the both profiles can have such improved
packages, but actually changing upstream (Debian) takes much time
and effort and repackaging by ourselves may bring big impacts to
package compatibilities, especially in the generic profile.


2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal
pulls around 90 packages finally)
Anything in that range still seems reasonable from a maintenance
perspective - provided there are no "challenging" packages
included. But we should still check if that number is seriously needed,
though.

OK, let's discuss about this number in the future proposal.

Anyway, I will create and share a sample of proposal.yml with the
flat package set, please review that and confirm if it matches your opinion of
the "CIP maintained packages".

Kazu


Jan


I only checked
suricata because of the outstanding python dependency, but
there might be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages, PDP steps, and
the format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all
members become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@...> On
Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...;
cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1
(Security packages)

On 09.12.19 14:54, kazuhiro3.hayashi@... wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached
package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/ma
ster/doc/pd p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required
features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons
as well.

Due Date: December 23rd
(We can extend this due date if more time required for
reviews, please let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification for CR 2.11,
2.11(1)
security_criteria: network::server, network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we
agree on listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that we have this in our
list already?

Jan

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

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


[isar-cip-core PATCH] classes/wic-targz-img: add dependency between targz-img and wic-img

Quirin Gylstorff
 

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

Add a dependency between targz_image and wic_image to avoid
an error during the generation of the targz image as wic modifies
the rootfs.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
classes/wic-targz-img.bbclass | 2 ++
1 file changed, 2 insertions(+)

diff --git a/classes/wic-targz-img.bbclass b/classes/wic-targz-img.bbclass
index 4e9f89d..1327840 100644
--- a/classes/wic-targz-img.bbclass
+++ b/classes/wic-targz-img.bbclass
@@ -11,3 +11,5 @@

inherit wic-img
inherit targz-img
+
+addtask do_targz_image after do_wic_image
--
2.20.1


Re: [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package Proposal #1 (Security packages))

Kazuhiro Hayashi
 

Hello,

PDP and the helper scripts have been updated to 3.0.

* Add a rule to satisfy all run-time dependencies for the proposed binary packages
https://gitlab.com/cip-project/cip-core/cip-pkglist/commit/6867b5b41bcf618d4be3955f302df8dbb3114050#c284394f3826d472fb70f72e2ef4ef9fe9606660_80_78
* Add a script (check_deps.py) to check the dependencies
* (Minor update): Caching CVE and apt data to reduce the initialization time of generate-proposal.py

Kent, Dinesh,

Could you try the updated script to create a new proposal
including the origin 21 security packages + their dependencies?

Please let me know if you find some issues.

Best regards,
Kazu


Hello CIP core members,

If you have any objections about the following approach,
please let me know *by the next IRC meeting (on Jan 9th)*.

We are already updating cip-pkglist based on the following approach and
will create the new "proposal.yml" for the security packages ASAP.

Best regards,
Kazu


Hello Jan, Kent, and all CIP core members,

Anyway, I will create and share a sample of proposal.yml with the flat package set,
please review that and confirm if it matches your opinion of the "CIP maintained packages".
I would like to confirm that the following solution can satisfy our requirements.

Examples:
* proposal*.yml: The package proposal file that a proposer is creating using "generate-proposal.py"
* pkglist_buster.yml: Existing "supported" package list, that was created/updated before
(See the attached files. All information except "bin_pkgs" are dropped to simplify.)

Solution:
0. Use the same YML format as Kent's proposal (Don't change the current YML format)
1. Add a new script "check-deps.py" to check if binary packages in "depends:" are included in
either "proposal.yml" or "pkglist_buster.yml"
2. "generate-proposal.py" runs "check-deps.py" at the end and proposer needs to
add more packages to "proposal.yml" if unmet dependencies are reported by "check-deps.py"
3. The proposer can request the package proposal only if "check-deps.py" reports nothing

In the attached examples, the initial proposal "proposal1.yml" has an unmet dependency (= lsb-base).
"check-deps.py" reports this then the proposer add "lsb-base" source package and binary package
to the second proposal "proposal2.yml", which satisfies all run-time dependencies
so can be proposed to cip-dev.

What do you think?
If OK, we will update the scripts in https://gitlab.com/cip-project/cip-core/cip-pkglist
based on the above solution.

Best regards,
Kazu


Hello Jan and CIP core members,

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@... wrote:
suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this
in
our list already?

@kazuhiro3.hayashi@... and @Dinesh Kumar,
Do you need a script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under
investigation
in the security working group.
The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.
We can only decide about package sets which have their runtime
dependencies already fulfilled with the existing package set (where is
that now, BTW?) or include these dependencies in the set.
I'm assuming the "existing package set" is the list of packages that are already accepted by CIP.
If so, there is no such list because this is the first proposal.
Then let's define that base (minimal debootstrap) first before adding
further packages.
OK, let's start from defining this base.



Also, it's difficult for me to agree with the opinion that
"all runtime dependencies must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view (debconf, debian-archive-keyring, etc.)
Anything that a Debian package requires needs to be present - otherwise
the package becomes broken. I can't imagine we want to propose that to
our users. Weaker dependencies are obviously optional.
Yes, anything required by Debian package needs to be "present",
but it is not always necessary to "maintain" their source
(e.g. Request them to Debian Extended LTS).

I think that there are two kinds in our "support" levels:
(1) Just make the package available (present) in CIP at least 10 years
(2) (1) + Keep watching the latest bugs and security issues and fixing them aggressively
I was understanding that the CIP package list we are discussing is
for clarifying the packages like (2).
However, if no one in CIP care about the difference between (1) and (2),
we should simply define the package list including all binary package dependencies, like Jan mentioned.


If we should run into a package that seems to require more than it
should, let's improve it by proposing a break-up upstream. Or by
repackaging it in meta-debian / isar-cip-core. But that should come
first before proposing it here.
It would be better if the both profiles can have such improved packages,
but actually changing upstream (Debian) takes much time and effort and
repackaging by ourselves may bring big impacts to package compatibilities,
especially in the generic profile.


2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal pulls around 90 packages finally)
Anything in that range still seems reasonable from a maintenance
perspective - provided there are no "challenging" packages included. But
we should still check if that number is seriously needed, though.
OK, let's discuss about this number in the future proposal.

Anyway, I will create and share a sample of proposal.yml with the flat package set,
please review that and confirm if it matches your opinion of the "CIP maintained packages".

Kazu


Jan


I only checked
suricata because of the outstanding python dependency, but there might
be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages, PDP steps, and the format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@...> On Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...; cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

On 09.12.19 14:54, kazuhiro3.hayashi@... wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: December 23rd
(We can extend this due date if more time required for reviews, please
let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
security_criteria: network::server, network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that we have this in our list already?

Jan

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

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


[isar-cip-core PATCH v2 5/5] kas: patch isar for iwg20m with kernel 4.4

Quirin Gylstorff
 

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

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
...d-path-to-image-for-arm-kernels-4.12.patch | 37 +++++++++++++++++++
kas.yml | 5 +++
2 files changed, 42 insertions(+)
create mode 100644 isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch

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
new file mode 100644
index 0000000..3e4e13e
--- /dev/null
+++ b/isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch
@@ -0,0 +1,37 @@
+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 3eb6f03..a157dc9 100644
--- a/kas.yml
+++ b/kas.yml
@@ -22,6 +22,11 @@ repos:
refspec: 619d6d88ac8c745282fd16773d50a466567615b6
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 v2 4/5] Use siemens_ipc227e_defconfig for simatic-ipc227e

Quirin Gylstorff
 

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

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
conf/machine/simatic-ipc227e.conf | 2 ++
1 file changed, 2 insertions(+)

diff --git a/conf/machine/simatic-ipc227e.conf b/conf/machine/simatic-ipc227e.conf
index 473e6c5..3c9638f 100644
--- a/conf/machine/simatic-ipc227e.conf
+++ b/conf/machine/simatic-ipc227e.conf
@@ -10,3 +10,5 @@ DISTRO_ARCH = "amd64"

IMAGE_TYPE ?= "wic-img"
IMAGER_INSTALL += "${GRUB_BOOTLOADER_INSTALL}"
+USE_CIP_KERNEL_CONFIG = "1"
+KERNEL_DEFCONFIG = "cip-kernel-config/4.19.y-cip/x86/siemens_ipc227e_defconfig"
--
2.20.1


[isar-cip-core PATCH v2 3/5] Use renesas_shmobile_defconfig for iwg20m

Quirin Gylstorff
 

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

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
conf/machine/iwg20m.conf | 2 ++
1 file changed, 2 insertions(+)

diff --git a/conf/machine/iwg20m.conf b/conf/machine/iwg20m.conf
index 6c1a227..37f98fa 100644
--- a/conf/machine/iwg20m.conf
+++ b/conf/machine/iwg20m.conf
@@ -17,6 +17,8 @@ BAUDRATE_TTY = "115200"
# kernel version
PREFERRED_VERSION_linux-cip ?= "4.4.%"
PREFERRED_VERSION_linux-cip-rt ?= "4.4.%"
+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"
--
2.20.1

6001 - 6020 of 10158