Date   

Re: Please check health for renesas board on LAVA

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Chris Paterson [mailto:Chris.Paterson2@renesas.com]
Sent: Wednesday, March 18, 2020 6:14 PM
To: iwamatsu nobuhiro(岩松 信洋 ○SWC□OST)
<nobuhiro1.iwamatsu@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org
Subject: RE: Please check health for renesas board on LAVA

Hello Iwamatsu-san,

From: nobuhiro1.iwamatsu@toshiba.co.jp
<nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 18 March 2020 05:42

Hi Chris,

Some Renesas boards look like down[0].
Therefore, testing with gitlab has not been completed.
Yes, sorry. There is an issue with one of the USB hubs.
However we're all working from home at the moment so it's not easy for
me to get physical access.
I see.


As a temporary measure yesterday I removed the problematic boards from
our CI pipelines, so hopefully going forward we should be okay.
The offline boards were additional non CIP reference platforms, so our
CI will still be testing what needs to be tested.
Okay, thanks for your work!

This adds to my point that we need to spread reference platforms over
more then one location 😊
Yes, We (Toshiba) will work on joining this support as well.

Best regards,
Nobuhiro


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

US-West US-East UK DE TW JP
02:00 05:00 09:00 10:00 17:00 18:00

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

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/03/cip.2020-03-12-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - Iwamatsu-san
2. Assign the owner of "CIP kernel config" - masashi910
3. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
3-1. Workflow for identifying important fixes, backporting, and reviewing them
3-2. Prepare the tools to be used for this workflow
3-3. Get practice in backporting patches
4. Upload a guideline for reference hardware platform addition - masashi910

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB
1. Summer Time
US summer time started on March 8. CEST starts on March 29.
This IRC meeting starts at UTC (GMT) 09:00.

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: Please check health for renesas board on LAVA

Chris Paterson
 

From: Pavel Machek <pavel@denx.de>
Sent: 18 March 2020 20:43

Hi!

This adds to my point that we need to spread reference platforms over more
then one location 😊
...yeah, and at least one site should be on the moon - in case of another
wide-spread lockdown. ;)
I'd suggest a moon rather than the moon. Europa could work, just to be
sure :-).
I'm not sure if we'll cope with the latency though...


                                                                      Pavel


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


Re: Please check health for renesas board on LAVA

Pavel Machek
 

Hi!

This adds to my point that we need to spread reference platforms over more then one location 😊
...yeah, and at least one site should be on the moon - in case of another
wide-spread lockdown. ;)
I'd suggest a moon rather than the moon. Europa could work, just to be
sure :-).

Pavel


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


Re: Please check health for renesas board on LAVA

Jan Kiszka
 

On 18.03.20 10:13, Chris Paterson wrote:
Hello Iwamatsu-san,

From: nobuhiro1.iwamatsu@toshiba.co.jp
<nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 18 March 2020 05:42

Hi Chris,

Some Renesas boards look like down[0].
Therefore, testing with gitlab has not been completed.
Yes, sorry. There is an issue with one of the USB hubs.
However we're all working from home at the moment so it's not easy for me to get physical access.
As a temporary measure yesterday I removed the problematic boards from our CI pipelines, so hopefully going forward we should be okay.
The offline boards were additional non CIP reference platforms, so our CI will still be testing what needs to be tested.
This adds to my point that we need to spread reference platforms over more then one location 😊
...yeah, and at least one site should be on the moon - in case of another wide-spread lockdown. ;)

Jan

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


Re: Please check health for renesas board on LAVA

Chris Paterson
 

Hello Iwamatsu-san,

From: nobuhiro1.iwamatsu@toshiba.co.jp
<nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 18 March 2020 05:42

Hi Chris,

Some Renesas boards look like down[0].
Therefore, testing with gitlab has not been completed.
Yes, sorry. There is an issue with one of the USB hubs.
However we're all working from home at the moment so it's not easy for me to get physical access.

As a temporary measure yesterday I removed the problematic boards from our CI pipelines, so hopefully going forward we should be okay.
The offline boards were additional non CIP reference platforms, so our CI will still be testing what needs to be tested.

This adds to my point that we need to spread reference platforms over more then one location 😊

Kind regards, Chris


Could you check it?

Best regards,
Nobuhiro

[0]: https://lava.ciplatform.org/scheduler/alldevices


Please check health for renesas board on LAVA

Nobuhiro Iwamatsu
 

Hi Chris,

Some Renesas boards look like down[0].
Therefore, testing with gitlab has not been completed.

Could you check it?

Best regards,
Nobuhiro

[0]: https://lava.ciplatform.org/scheduler/alldevices


COMUNICADO Departamento Policia Civil

Aviso Importante <delegaciavirtual@...>
 

Departamento da Delegacia Eletrônica

   Caro Usuário, 

      Atendendo a uma reclamante foi gerado uma queixa de crime em seu CPF/E-mail, estamos entrando em contato
para a apresentação da mesma. Para maiores esclarecimentos do Boletim de Ocorrência de N° F44694752 877614104WA 17/03/2020,
na qual a sua pessoa terá que efetuar o comparecimento. Na data informada no 
Boletim de Ocorrência.
Na data e local especificado. Com os documentos de identificação.  

Confira no Boletim.

Registro de Ocorréncia: Intimação_MP-17/03/2020.msi

 


Re: Linux-cip: Kselftest plans

Vijai Kumar K
 

On Tue, Mar 17, 2020 at 4:19 AM <nobuhiro1.iwamatsu@toshiba.co.jp> wrote:

Hi all,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
Sent: Tuesday, March 17, 2020 12:27 AM
To: vijai kumar <vijaikumar.kanagarajan@gmail.com>;
cip-dev@lists.cip-project.org; Chris Paterson
<Chris.Paterson2@renesas.com>; iwamatsu nobuhiro(岩松 信洋 ○SWC□
OST) <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek
<pavel@denx.de>
Subject: Re: [cip-dev] Linux-cip: Kselftest plans

On 06.03.20 09:21, vijai kumar wrote:
Hi All,

Is kselftest maintained in the cip-kernel tree? I do see some
branch[1] maintained by Nobuhiro-san for kselftest, but it's out of
5.6 linux tree.

The reason being to gather collective thoughts about the plan for
kselftest based tests for cip kernel. Are there any existing or future
plans for using kselftest for testing cip kernels? If so are we going
to use the latest tree from upstream or plan to fix/backport test
cases to current cip kernel versions?
I am now implementing LAVA's kselftest. This kselftest uses kseflftest included in the latest kernel.
There are no plans to backport tests to 4.4 or 4.19. I believe that ksefltest included in the CIP kernel
is inadequate in function and difficult to use as it is.
I suggest using a new kernel test that incorporates the latest tests.
Thank you Nobuhiro-San. Our original idea was to use the kselftest
from 4.19/4.4 cip tree. We faced some issues with
out-of-tree compilation while debianizing it. Also we faced some
compilation issues.

If that is the case, that we are going to use kselftest from the
latest kernel, how can we track the kselftest binaries for a
particular
cip kernel release? I am not sure if all the test cases would pass for
4.19/4/4. Do you have any plans to maintain a branch and release
kselftest binaries and/or testcases that have been tested with a
particular cip kernel release?

Thanks,
Vijai Kumar K

Best regards,
Nobuhiro


Re: Linux-cip: Kselftest plans

Nobuhiro Iwamatsu
 

Hi all,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
Sent: Tuesday, March 17, 2020 12:27 AM
To: vijai kumar <vijaikumar.kanagarajan@gmail.com>;
cip-dev@lists.cip-project.org; Chris Paterson
<Chris.Paterson2@renesas.com>; iwamatsu nobuhiro(岩松 信洋 ○SWC□
OST) <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek
<pavel@denx.de>
Subject: Re: [cip-dev] Linux-cip: Kselftest plans

On 06.03.20 09:21, vijai kumar wrote:
Hi All,

Is kselftest maintained in the cip-kernel tree? I do see some
branch[1] maintained by Nobuhiro-san for kselftest, but it's out of
5.6 linux tree.

The reason being to gather collective thoughts about the plan for
kselftest based tests for cip kernel. Are there any existing or future
plans for using kselftest for testing cip kernels? If so are we going
to use the latest tree from upstream or plan to fix/backport test
cases to current cip kernel versions?
I am now implementing LAVA's kselftest. This kselftest uses kseflftest included in the latest kernel.
There are no plans to backport tests to 4.4 or 4.19. I believe that ksefltest included in the CIP kernel
is inadequate in function and difficult to use as it is.
I suggest using a new kernel test that incorporates the latest tests.

Best regards,
Nobuhiro


You Have (2) Pending E-mail

Email Support <noreply-admin@...>
 

Some Incoming E-mail were Undelivered to Inbox
Proceed Here to Fix Errors


 


Re: I need de0-nano testing for -rt release was Re: 4.19.106-cip21-rt8 problems on de0-nano

Bhola, Bikram <Bikram_Bhola@...>
 

Hi Pavel,

All these random failures are happening because of the slowness in network.
Because of the COVID-19 situation and in preparation of all employees to work from home office, Our IT team was doing some experiments/setup by reserving some network bandwidth. That caused the slowness in network and the timeout.

The board is connected through network cable. If Root filesystems (etc) are not changing too often, it totally make sense to do rsync to pull additional changes if any. We will give it a try on that.

I saw all of the jobs started working fine today again for both 127E and 227E board. But we may see these random failures as IT told to have these network thing will settle in another day or two.

Sorry for the trouble and thank you for being patient.

Regards,
Bikram

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: 16 March 2020 17:29
To: Pavel Machek <pavel@denx.de>
Cc: Bhola, Bikram <Bikram_Bhola@mentor.com>; Jan Kiszka <jan.kiszka@siemens.com>; Quirin Gylstorff <quirin.gylstorff@siemens.com>; cip-dev@lists.cip-project.org
Subject: Re: I need de0-nano testing for -rt release was Re: [cip-dev] 4.19.106-cip21-rt8 problems on de0-nano

Hi!

Both de0-nano and IPC227E targets are up and running. I have monitored for test jobs on it and those completed successfully.

Thank You!!
There's still something broken with the testing. renesas_shmobile
initially failed (okay after restart), rest failed:

https://gitlab.com/cip-project/cip-kernel/linux-cip/pipelines/12635589
0
https://lava.ciplatform.org/scheduler/job/12718

Going through the logs:

progress 90% (81MB)
progress 95% (86MB)
progress 100% (90MB)
90MB downloaded in 383.03s (0.24MB/s)
end: 1.3.1 http-download (duration 00:06:23) [common]
case: http-download
case_id: 403737
definition: lava
duration: 383.03
extra: ...
level: 1.3.1
namespace: common
result: pass
tftp-deploy timed out after 1283 seconds
end: 1.3 download-retry (duration 00:06:24) [common

You are not trying to do tftp over WAN, are you?

Seeing the download speeds... would it make sense to do downloads with rsync? Root filesystems (etc) are not changing too often, so that should provide some speedups.

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


Re: Linux-cip: Kselftest plans

Jan Kiszka
 

On 06.03.20 09:21, vijai kumar wrote:
Hi All,
Is kselftest maintained in the cip-kernel tree? I do see some
branch[1] maintained by Nobuhiro-san for kselftest, but it's out of
5.6 linux tree.
The reason being to gather collective thoughts about the plan for
kselftest based tests for cip kernel. Are there any existing or future
plans for using kselftest for testing cip kernels? If so are we going
to use the latest tree from upstream or plan to fix/backport test
cases to current cip kernel versions?
[1] https://gitlab.com/cip-project/cip-kernel/linux-cip/-/tree/ci/iwamatsu/linux-cip-kselftest
Thanks,
Vijai Kumar K
CC'ing our kernel maintainers and Chris in case someone has input on this.

Vijai, maybe you can say a few words about your integration experience and options to move forward.

Jan

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


Re: I need de0-nano testing for -rt release was Re: 4.19.106-cip21-rt8 problems on de0-nano

Pavel Machek
 

Hi!

Both de0-nano and IPC227E targets are up and running. I have monitored for test jobs on it and those completed successfully.

Thank You!!
There's still something broken with the testing. renesas_shmobile
initially failed (okay after restart), rest failed:

https://gitlab.com/cip-project/cip-kernel/linux-cip/pipelines/126355890
https://lava.ciplatform.org/scheduler/job/12718

Going through the logs:

progress 90% (81MB)
progress 95% (86MB)
progress 100% (90MB)
90MB downloaded in 383.03s (0.24MB/s)
end: 1.3.1 http-download (duration 00:06:23) [common]
case: http-download
case_id: 403737
definition: lava
duration: 383.03
extra: ...
level: 1.3.1
namespace: common
result: pass
tftp-deploy timed out after 1283 seconds
end: 1.3 download-retry (duration 00:06:24) [common

You are not trying to do tftp over WAN, are you?

Seeing the download speeds... would it make sense to do downloads with
rsync? Root filesystems (etc) are not changing too often, so that
should provide some speedups.

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


Re: Backporting "net: ipv6_stub: use ip6_dst_lookup_flow instead of ip6_dst_lookup"

punit1.agrawal@...
 

Hi Pavel,

Not sure if the email was intended for any specific recipient so my
comments below may not make sense...

Pavel Machek <pavel@ucw.cz> writes:

Hi!

Here's backport of `subj` to 4.19. ip6_dst_lookup_flow() prototype
changed between 4.19 and mainline, files were moved around, and I
could not find some instances to update. Fun!
It would be helpful for readers / reviewers if this was sent following
the same format / guidelines as expected by the stable tree
(Documentation/process/stable-kernel-rules.rst). Especially including
the commit hash so it's easier to lookup the context.

Thanks,
Punit

I did minimal compile testing, I'll need to run it behind gitlab ci;
but... if you are using IPv6 and can test this, it would be nice.

Best regards,
Pavel



diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 46b855a42884..e3c948617c73 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -415,9 +415,9 @@ static int addr6_resolve(struct sockaddr_in6 *src_in,
fl6.saddr = src_in->sin6_addr;
fl6.flowi6_oif = addr->bound_dev_if;
- ret = ipv6_stub->ipv6_dst_lookup(addr->net, NULL, &dst, &fl6);
- if (ret < 0)
- return ret;
+ dst = ipv6_stub->ipv6_dst_lookup_flow(addr->net, NULL, &fl6, NULL);
+ if (IS_ERR(dst))
+ return PTR_ERR(dst);
rt = (struct rt6_info *)dst;
if (ipv6_addr_any(&src_in->sin6_addr)) {
diff --git a/drivers/infiniband/sw/rxe/rxe_net.c b/drivers/infiniband/sw/rxe/rxe_net.c
index 8094cbaa54a9..95cf4fd69c55 100644
--- a/drivers/infiniband/sw/rxe/rxe_net.c
+++ b/drivers/infiniband/sw/rxe/rxe_net.c
@@ -154,10 +154,12 @@ static struct dst_entry *rxe_find_route6(struct net_device *ndev,
memcpy(&fl6.daddr, daddr, sizeof(*daddr));
fl6.flowi6_proto = IPPROTO_UDP;
- if (unlikely(ipv6_stub->ipv6_dst_lookup(sock_net(recv_sockets.sk6->sk),
- recv_sockets.sk6->sk, &ndst, &fl6))) {
+ ndst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(recv_sockets.sk6->sk),
+ recv_sockets.sk6->sk, &fl6,
+ NULL);
+ if (unlikely(IS_ERR(ndst))) {
pr_err_ratelimited("no route to %pI6\n", daddr);
- goto put;
+ return NULL;
}
if (unlikely(ndst->error)) {
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 493cd382b8aa..f22f187a91cd 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -796,7 +796,9 @@ static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
if (dst)
return dst;
}
- if (ipv6_stub->ipv6_dst_lookup(geneve->net, gs6->sock->sk, &dst, fl6)) {
+ dst = ipv6_stub->ipv6_dst_lookup_flow(geneve->net, gs6->sock->sk, fl6,
+ NULL);
+ if (IS_ERR(dst)) {
netdev_dbg(dev, "no route to %pI6\n", &fl6->daddr);
return ERR_PTR(-ENETUNREACH);
}
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 27bd586b94b0..0b6e899bd02e 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1952,7 +1952,6 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
bool use_cache = ip_tunnel_dst_cache_usable(skb, info);
struct dst_entry *ndst;
struct flowi6 fl6;
- int err;
if (!sock6)
return ERR_PTR(-EIO);
@@ -1975,10 +1974,9 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
fl6.fl6_dport = dport;
fl6.fl6_sport = sport;
- err = ipv6_stub->ipv6_dst_lookup(vxlan->net,
- sock6->sock->sk,
- &ndst, &fl6);
- if (unlikely(err < 0)) {
+ ndst = ipv6_stub->ipv6_dst_lookup_flow(vxlan->net, sock6->sock->sk,
+ &fl6, NULL);
+ if (unlikely(IS_ERR(ndst))) {
netdev_dbg(dev, "no route to %pI6\n", daddr);
return ERR_PTR(-ENETUNREACH);
}
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 6def0351bcc3..ceb36cce91ee 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -235,9 +235,10 @@ struct ipv6_stub {
const struct in6_addr *addr);
int (*ipv6_sock_mc_drop)(struct sock *sk, int ifindex,
const struct in6_addr *addr);
- int (*ipv6_dst_lookup)(struct net *net, struct sock *sk,
- struct dst_entry **dst, struct flowi6 *fl6);
-
+ struct dst_entry *(*ipv6_dst_lookup_flow)(struct net *net,
+ const struct sock *sk,
+ struct flowi6 *fl6,
+ const struct in6_addr *final_dst);
struct fib6_table *(*fib6_get_table)(struct net *net, u32 id);
struct fib6_info *(*fib6_lookup)(struct net *net, int oif,
struct flowi6 *fl6, int flags);
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index ff33f498c137..035cd7dc3836 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -961,6 +961,13 @@ int ip6_dst_lookup(struct net *net, struct sock *sk, struct dst_entry **dst,
struct flowi6 *fl6);
struct dst_entry *ip6_dst_lookup_flow(const struct sock *sk, struct flowi6 *fl6,
const struct in6_addr *final_dst);
+
+static inline struct dst_entry *ip6_dst_lookup_flow_net(struct net *ign, const struct sock *sk, struct flowi6 *fl6,
+ const struct in6_addr *final_dst)
+{
+ return ip6_dst_lookup_flow(sk, fl6, final_dst);
+}
+
struct dst_entry *ip6_sk_dst_lookup_flow(struct sock *sk, struct flowi6 *fl6,
const struct in6_addr *final_dst,
bool connected);
diff --git a/net/ipv6/addrconf_core.c b/net/ipv6/addrconf_core.c
index 5cd0029d930e..fe7f59193bb1 100644
--- a/net/ipv6/addrconf_core.c
+++ b/net/ipv6/addrconf_core.c
@@ -127,11 +127,12 @@ int inet6addr_validator_notifier_call_chain(unsigned long val, void *v)
}
EXPORT_SYMBOL(inet6addr_validator_notifier_call_chain);
-static int eafnosupport_ipv6_dst_lookup(struct net *net, struct sock *u1,
- struct dst_entry **u2,
- struct flowi6 *u3)
+static struct dst_entry *eafnosupport_ipv6_dst_lookup_flow(struct net *net,
+ const struct sock *sk,
+ struct flowi6 *fl6,
+ const struct in6_addr *final_dst)
{
- return -EAFNOSUPPORT;
+ return ERR_PTR(-EAFNOSUPPORT);
}
static struct fib6_table *eafnosupport_fib6_get_table(struct net *net, u32 id)
@@ -169,7 +170,7 @@ eafnosupport_ip6_mtu_from_fib6(struct fib6_info *f6i, struct in6_addr *daddr,
}
const struct ipv6_stub *ipv6_stub __read_mostly = &(struct ipv6_stub) {
- .ipv6_dst_lookup = eafnosupport_ipv6_dst_lookup,
+ .ipv6_dst_lookup_flow = eafnosupport_ipv6_dst_lookup_flow,
.fib6_get_table = eafnosupport_fib6_get_table,
.fib6_table_lookup = eafnosupport_fib6_table_lookup,
.fib6_lookup = eafnosupport_fib6_lookup,
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 9a4261e50272..e44534f22e00 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -889,7 +889,7 @@ static struct pernet_operations inet6_net_ops = {
static const struct ipv6_stub ipv6_stub_impl = {
.ipv6_sock_mc_join = ipv6_sock_mc_join,
.ipv6_sock_mc_drop = ipv6_sock_mc_drop,
- .ipv6_dst_lookup = ip6_dst_lookup,
+ .ipv6_dst_lookup_flow = ip6_dst_lookup_flow_net,
.fib6_get_table = fib6_get_table,
.fib6_table_lookup = fib6_table_lookup,
.fib6_lookup = fib6_lookup,
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 8fbe6cdbe255..e42ef8f835fa 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -618,16 +618,15 @@ static struct net_device *inet6_fib_lookup_dev(struct net *net,
struct net_device *dev;
struct dst_entry *dst;
struct flowi6 fl6;
- int err;
if (!ipv6_stub)
return ERR_PTR(-EAFNOSUPPORT);
memset(&fl6, 0, sizeof(fl6));
memcpy(&fl6.daddr, addr, sizeof(struct in6_addr));
- err = ipv6_stub->ipv6_dst_lookup(net, NULL, &dst, &fl6);
- if (err)
- return ERR_PTR(err);
+ dst = ipv6_stub->ipv6_dst_lookup_flow(net, NULL, &fl6, NULL);
+ if (IS_ERR(dst))
+ return ERR_CAST(dst);
dev = dst->dev;
dev_hold(dev);
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index 9783101bc4a9..1ab684a4f565 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -190,6 +190,14 @@ static int tipc_udp_xmit(struct net *net, struct sk_buff *skb,
.saddr = src->ipv6,
.flowi6_proto = IPPROTO_UDP
};
+ ndst = ipv6_stub->ipv6_dst_lookup_flow(net,
+ ub->ubsock->sk,
+ &fl6, NULL);
+ if (IS_ERR(ndst)) {
+ err = PTR_ERR(ndst);
+ goto tx_error;
+ }
+
err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk, &ndst,
&fl6);
if (err)


Re: I need de0-nano testing for -rt release was Re: 4.19.106-cip21-rt8 problems on de0-nano

Pavel Machek
 

Hi!

Both de0-nano and IPC227E targets are up and running. I have monitored for test jobs on it and those completed successfully.

Thank You!!
There's still something broken with the testing. renesas_shmobile
initially failed (okay after restart), rest failed:

https://gitlab.com/cip-project/cip-kernel/linux-cip/pipelines/126355890

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


Backporting "net: ipv6_stub: use ip6_dst_lookup_flow instead of ip6_dst_lookup"

Pavel Machek
 

Hi!

Here's backport of `subj` to 4.19. ip6_dst_lookup_flow() prototype
changed between 4.19 and mainline, files were moved around, and I
could not find some instances to update. Fun!

I did minimal compile testing, I'll need to run it behind gitlab ci;
but... if you are using IPv6 and can test this, it would be nice.

Best regards,
Pavel



diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 46b855a42884..e3c948617c73 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -415,9 +415,9 @@ static int addr6_resolve(struct sockaddr_in6 *src_in,
fl6.saddr = src_in->sin6_addr;
fl6.flowi6_oif = addr->bound_dev_if;

- ret = ipv6_stub->ipv6_dst_lookup(addr->net, NULL, &dst, &fl6);
- if (ret < 0)
- return ret;
+ dst = ipv6_stub->ipv6_dst_lookup_flow(addr->net, NULL, &fl6, NULL);
+ if (IS_ERR(dst))
+ return PTR_ERR(dst);

rt = (struct rt6_info *)dst;
if (ipv6_addr_any(&src_in->sin6_addr)) {
diff --git a/drivers/infiniband/sw/rxe/rxe_net.c b/drivers/infiniband/sw/rxe/rxe_net.c
index 8094cbaa54a9..95cf4fd69c55 100644
--- a/drivers/infiniband/sw/rxe/rxe_net.c
+++ b/drivers/infiniband/sw/rxe/rxe_net.c
@@ -154,10 +154,12 @@ static struct dst_entry *rxe_find_route6(struct net_device *ndev,
memcpy(&fl6.daddr, daddr, sizeof(*daddr));
fl6.flowi6_proto = IPPROTO_UDP;

- if (unlikely(ipv6_stub->ipv6_dst_lookup(sock_net(recv_sockets.sk6->sk),
- recv_sockets.sk6->sk, &ndst, &fl6))) {
+ ndst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(recv_sockets.sk6->sk),
+ recv_sockets.sk6->sk, &fl6,
+ NULL);
+ if (unlikely(IS_ERR(ndst))) {
pr_err_ratelimited("no route to %pI6\n", daddr);
- goto put;
+ return NULL;
}

if (unlikely(ndst->error)) {
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 493cd382b8aa..f22f187a91cd 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -796,7 +796,9 @@ static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
if (dst)
return dst;
}
- if (ipv6_stub->ipv6_dst_lookup(geneve->net, gs6->sock->sk, &dst, fl6)) {
+ dst = ipv6_stub->ipv6_dst_lookup_flow(geneve->net, gs6->sock->sk, fl6,
+ NULL);
+ if (IS_ERR(dst)) {
netdev_dbg(dev, "no route to %pI6\n", &fl6->daddr);
return ERR_PTR(-ENETUNREACH);
}
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 27bd586b94b0..0b6e899bd02e 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1952,7 +1952,6 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
bool use_cache = ip_tunnel_dst_cache_usable(skb, info);
struct dst_entry *ndst;
struct flowi6 fl6;
- int err;

if (!sock6)
return ERR_PTR(-EIO);
@@ -1975,10 +1974,9 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
fl6.fl6_dport = dport;
fl6.fl6_sport = sport;

- err = ipv6_stub->ipv6_dst_lookup(vxlan->net,
- sock6->sock->sk,
- &ndst, &fl6);
- if (unlikely(err < 0)) {
+ ndst = ipv6_stub->ipv6_dst_lookup_flow(vxlan->net, sock6->sock->sk,
+ &fl6, NULL);
+ if (unlikely(IS_ERR(ndst))) {
netdev_dbg(dev, "no route to %pI6\n", daddr);
return ERR_PTR(-ENETUNREACH);
}
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 6def0351bcc3..ceb36cce91ee 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -235,9 +235,10 @@ struct ipv6_stub {
const struct in6_addr *addr);
int (*ipv6_sock_mc_drop)(struct sock *sk, int ifindex,
const struct in6_addr *addr);
- int (*ipv6_dst_lookup)(struct net *net, struct sock *sk,
- struct dst_entry **dst, struct flowi6 *fl6);
-
+ struct dst_entry *(*ipv6_dst_lookup_flow)(struct net *net,
+ const struct sock *sk,
+ struct flowi6 *fl6,
+ const struct in6_addr *final_dst);
struct fib6_table *(*fib6_get_table)(struct net *net, u32 id);
struct fib6_info *(*fib6_lookup)(struct net *net, int oif,
struct flowi6 *fl6, int flags);
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index ff33f498c137..035cd7dc3836 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -961,6 +961,13 @@ int ip6_dst_lookup(struct net *net, struct sock *sk, struct dst_entry **dst,
struct flowi6 *fl6);
struct dst_entry *ip6_dst_lookup_flow(const struct sock *sk, struct flowi6 *fl6,
const struct in6_addr *final_dst);
+
+static inline struct dst_entry *ip6_dst_lookup_flow_net(struct net *ign, const struct sock *sk, struct flowi6 *fl6,
+ const struct in6_addr *final_dst)
+{
+ return ip6_dst_lookup_flow(sk, fl6, final_dst);
+}
+
struct dst_entry *ip6_sk_dst_lookup_flow(struct sock *sk, struct flowi6 *fl6,
const struct in6_addr *final_dst,
bool connected);
diff --git a/net/ipv6/addrconf_core.c b/net/ipv6/addrconf_core.c
index 5cd0029d930e..fe7f59193bb1 100644
--- a/net/ipv6/addrconf_core.c
+++ b/net/ipv6/addrconf_core.c
@@ -127,11 +127,12 @@ int inet6addr_validator_notifier_call_chain(unsigned long val, void *v)
}
EXPORT_SYMBOL(inet6addr_validator_notifier_call_chain);

-static int eafnosupport_ipv6_dst_lookup(struct net *net, struct sock *u1,
- struct dst_entry **u2,
- struct flowi6 *u3)
+static struct dst_entry *eafnosupport_ipv6_dst_lookup_flow(struct net *net,
+ const struct sock *sk,
+ struct flowi6 *fl6,
+ const struct in6_addr *final_dst)
{
- return -EAFNOSUPPORT;
+ return ERR_PTR(-EAFNOSUPPORT);
}

static struct fib6_table *eafnosupport_fib6_get_table(struct net *net, u32 id)
@@ -169,7 +170,7 @@ eafnosupport_ip6_mtu_from_fib6(struct fib6_info *f6i, struct in6_addr *daddr,
}

const struct ipv6_stub *ipv6_stub __read_mostly = &(struct ipv6_stub) {
- .ipv6_dst_lookup = eafnosupport_ipv6_dst_lookup,
+ .ipv6_dst_lookup_flow = eafnosupport_ipv6_dst_lookup_flow,
.fib6_get_table = eafnosupport_fib6_get_table,
.fib6_table_lookup = eafnosupport_fib6_table_lookup,
.fib6_lookup = eafnosupport_fib6_lookup,
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 9a4261e50272..e44534f22e00 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -889,7 +889,7 @@ static struct pernet_operations inet6_net_ops = {
static const struct ipv6_stub ipv6_stub_impl = {
.ipv6_sock_mc_join = ipv6_sock_mc_join,
.ipv6_sock_mc_drop = ipv6_sock_mc_drop,
- .ipv6_dst_lookup = ip6_dst_lookup,
+ .ipv6_dst_lookup_flow = ip6_dst_lookup_flow_net,
.fib6_get_table = fib6_get_table,
.fib6_table_lookup = fib6_table_lookup,
.fib6_lookup = fib6_lookup,
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 8fbe6cdbe255..e42ef8f835fa 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -618,16 +618,15 @@ static struct net_device *inet6_fib_lookup_dev(struct net *net,
struct net_device *dev;
struct dst_entry *dst;
struct flowi6 fl6;
- int err;

if (!ipv6_stub)
return ERR_PTR(-EAFNOSUPPORT);

memset(&fl6, 0, sizeof(fl6));
memcpy(&fl6.daddr, addr, sizeof(struct in6_addr));
- err = ipv6_stub->ipv6_dst_lookup(net, NULL, &dst, &fl6);
- if (err)
- return ERR_PTR(err);
+ dst = ipv6_stub->ipv6_dst_lookup_flow(net, NULL, &fl6, NULL);
+ if (IS_ERR(dst))
+ return ERR_CAST(dst);

dev = dst->dev;
dev_hold(dev);
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index 9783101bc4a9..1ab684a4f565 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -190,6 +190,14 @@ static int tipc_udp_xmit(struct net *net, struct sk_buff *skb,
.saddr = src->ipv6,
.flowi6_proto = IPPROTO_UDP
};
+ ndst = ipv6_stub->ipv6_dst_lookup_flow(net,
+ ub->ubsock->sk,
+ &fl6, NULL);
+ if (IS_ERR(ndst)) {
+ err = PTR_ERR(ndst);
+ goto tx_error;
+ }
+
err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk, &ndst,
&fl6);
if (err)

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


April 6 cutover from Mailman2 to Group.io

Neal Caidin
 

[x-posted]
Dear CIP community,

These Mailman2 email lists will be converted starting on Monday, April 6 and may take up to 24 hours to complete. 

There is no action required on your part. 

Any emails that are sent during the downtime will be queued up and come through when the system is up and running.

Please let me know if you have any questions.

Best regards,
Neal

Neal Caidin
Program Manager, Program Management & Operations
The Linux Foundation
+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)


Re: Package Proposal #1 (Security packages), rev03

punit1.agrawal@...
 

Hi Yoshida-san,

Thanks for the clarifications. Where applicable please include them in
the requirements text and / or comments for the relevant packages for
the next update.

One additional comment below -

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

[...]

* uuid-runtime

It’s not clear how the package is related to the requirement -

"Account Identifier shall be unique on a component or system wide
level. Protection of relevant information in rest and transit shall
be supported."

Can you add more details to the requirement to clarify this?
As is, identifier shall be unique, so we need universally unique identifier generator.
Sorry but I don't know what you don't know. This is very simple
requirement.
I understand the requirement for having ’unique account identifier’
(usernames) but using uuidgen to achieve this seems quite impractical.

For reference, I checked the output of uuidgen included in the package -

$ uuidgen
b865c278-4230-4d5a-b7de-0ee528910095

It generates a 37 character long string of what seems like random hex
values. Are you recommending that we have these kind of strings for
usernames?

Thanks,
Punit


-----Original Message-----
From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Sent: Monday, March 9, 2020 7:31 PM
To: Kento Yoshida <kento.yoshida.wz@renesas.com>
Cc: cip-dev@lists.cip-project.org; cip-security@lists.cip-project.org
Subject: Re: [cip-dev] Package Proposal #1 (Security packages), rev03

Hi,

As mentioned earlier, I had some questions / queries regarding the requirements
for the proposed packages. Sending them here for discussion.

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

Requirements_for_proposal_SecurityWG_rev03.xlsx: the same file which
I've already sent before to explain the requirement in the standard
* sudo-ldap

Is there a specific requirement to include sudo-ldap in favour of plain sudo? IIUC,
sudo is a minimal dependency version while ldap requires additional packages to
be available.


* openssh

Based on the listed requierments, it is not clear why ftp and ssh clients are needed.
Can you please clarify the requirements' text to motivate inclusion of the client
binaries as well.


* pam-pkcs11
From my understanding, the package enables login using public / private keys.
But the requirements talk about enforcing the strength of passwords -

"A minimum strength of used passwords needs to be enforced."

Possibly a mixup of package and requirements?


* tpm2*

I think libtss2-esys0 is mistakenly included as explicit requirement. It seems to be a
dependency of tpm2-abrmd and will get pulled in automatically as per my
understanding.


* uuid-runtime

It’s not clear how the package is related to the requirement -

"Account Identifier shall be unique on a component or system wide
level. Protection of relevant information in rest and transit shall
be supported."

Can you add more details to the requirement to clarify this?
---


Thanks,
Punit


Re: Sample image including security packages

Kazuhiro Hayashi
 

Hello Venkata,


Hello Kazu-san,

Thank you for confirming.
Below is the merge request for the same.
https://gitlab.com/zuka0828/isar-cip-core/-/merge_requests/1
Merged. Thank you for quick response.

Best regards,
Kazu


Thanks
Venkata.

-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp [mailto:kazuhiro3.hayashi@toshiba.co.jp]
Sent: 12 March 2020 12:42
To: Venkata Seshagiri Pyla <Venkata.Pyla@toshiba-tsip.com>; Dinesh Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>
Cc: cip-security@lists.cip-project.org; cip-dev@lists.cip-project.org
Subject: RE: Sample image including security packages

Hello Venkata,

Thank you for checking the result.
I confirmed that this variable should not be overwritten in the image recipe.
Could you send MR including this update to https://gitlab.com/zuka0828/isar-cip-core ?

Best regards,
Kazu

-----Original Message-----
From: Venkata Seshagiri Pyla [mailto:Venkata.Pyla@toshiba-tsip.com]
Sent: Thursday, March 12, 2020 12:56 PM
To: hayashi kazuhiro(林 和宏 ○SWC□OST) <kazuhiro3.hayashi@toshiba.co.jp>;
dinesh kumar(TSIP DS Company) <dinesh.kumar@toshiba-tsip.com>
Cc: cip-security@lists.cip-project.org; cip-dev@lists.cip-project.org
Subject: RE: Sample image including security packages

Hello Kazu-san,

I observed 'init' system is not included in the image when append
operator is not used and so booting the image is not successful.

Here is the output of `bitbake -e cip-core-image-security | grep
'IMAGE_PREINSTALL'` when append is not used
----------------------------------------------------------------------
---------------------------
# $IMAGE_PREINSTALL [2 operations]
IMAGE_PREINSTALL=" openssl libssl1.1 fail2ban openssh-server openssh-sftp-server openssh-client
syslog-ng-core syslog-ng-mod-journal aide aide-common libnftables0 nftables libpam-pkcs11
chrony tpm2-tools tpm2-abrmd libtss2-esys0 libtss2-udev libpam-cracklib acl
libauparse0 audispd-plugins auditd uuid-runtime vim "
# "${IMAGE_PREINSTALL} ${IMAGE_INSTALL}"
# " ${IMAGE_PREINSTALL} ${IMAGE_INSTALL}"
----------------------------------------------------------------------
---------------------------

Output when append is used
----------------------------------------------------------------------
---------------------------
# $IMAGE_PREINSTALL [2 operations]
IMAGE_PREINSTALL=" init openssl libssl1.1 fail2ban openssh-server openssh-sftp-server
openssh-client syslog-ng-core syslog-ng-mod-journal aide aide-common libnftables0 nftables
libpam-pkcs11 chrony tpm2-tools tpm2-abrmd libtss2-esys0 libtss2-udev libpam-cracklib
acl libauparse0 audispd-plugins auditd uuid-runtime vim "
# "${IMAGE_PREINSTALL} ${IMAGE_INSTALL}"
# " ${IMAGE_PREINSTALL} ${IMAGE_INSTALL}"
----------------------------------------------------------------------
---------------------------


Thanks,
Venkata.
-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp
[mailto:kazuhiro3.hayashi@toshiba.co.jp]
Sent: 12 March 2020 05:16
To: Venkata Seshagiri Pyla <Venkata.Pyla@toshiba-tsip.com>; Dinesh
Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>
Cc: cip-security@lists.cip-project.org; cip-dev@lists.cip-project.org
Subject: RE: Sample image including security packages

Hello Venkata,

Thank you for the information.

Regarding the usage of `IMAGE_PREINSTALL`, I'm not sure if we always need `+` in the image recipe.
Example:
https://github.com/ilbers/isar/blob/master/doc/user_manual.md#create-a
-custom-image-recipe Could you dump the value of `IMAGE_PREINSTALL`
with/without `+` by `bitbake -e` command?

Best regards,
Kazu

-----Original Message-----
From: Venkata Seshagiri Pyla [mailto:Venkata.Pyla@toshiba-tsip.com]
Sent: Thursday, March 5, 2020 6:06 PM
To: hayashi kazuhiro(林 和宏 ○SWC□OST)
<kazuhiro3.hayashi@toshiba.co.jp>;
dinesh kumar(TSIP DS Company) <dinesh.kumar@toshiba-tsip.com>
Cc: cip-security@lists.cip-project.org;
cip-dev@lists.cip-project.org
Subject: RE: Sample image including security packages

Hi Kazu-san and Dinesh,

I have created the image with all proposed security packages included.
applied the below change, and booted the image in QEMU correctly.
-----------------
diff --git a/recipes-core/images/cip-core-image-security.bb
b/recipes-core/images/cip-core-image-security.bb
index 70571f8..b883414 100644
--- a/recipes-core/images/cip-core-image-security.bb
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -18,7 +18,7 @@ IMAGE_INSTALL += "customizations"

# Debian packages that provide security features # TODO: Add sudo
or sudo-ldap which conflict each other -IMAGE_PREINSTALL = " \
+IMAGE_PREINSTALL += " \
openssl libssl1.1 \
fail2ban \
openssh-server openssh-sftp-server openssh-client \
--
-----------------

Thanks
venkata
-----Original Message-----
From: Venkata Seshagiri Pyla
Sent: 02 March 2020 19:38
To: Dinesh Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>;
kazuhiro3.hayashi@toshiba.co.jp
Cc: cip-security@lists.cip-project.org;
cip-dev@lists.cip-project.org
Subject: RE: Sample image including security packages

Hi Kazu-san and Dinesh,

We found most of the packages are not included in the isar image,
could you please confirm whether all the proposed packages
are included in the given source?
If it is included, could you please let us know how to install them in the image?
I think we have to create the image for the target "cip-core-image-security" instead of "cip-core-image".

All the security packages are configured to install are present in this file "cip-core-image-security.bb".

I will generate the image for target "cip-core-image-security" and recheck all the security functionality.

Thanks,
Venkata.

-----Original Message-----
From: Cip-security
[mailto:cip-security-bounces@lists.cip-project.org]
On Behalf Of Dinesh Kumar
Sent: 02 March 2020 15:29
To: kazuhiro3.hayashi@toshiba.co.jp
Cc: cip-security@lists.cip-project.org;
cip-dev@lists.cip-project.org
Subject: Re: [Cip-security] Sample image including security packages

Dear Kazu-san,

Thanks for sharing the isar-cip-core repository details with us.

We followed below steps to first confirm whether all the proposed
binaries are included when we create CIP isar based image.
1. Create CIP isar based image from
"https://gitlab.com/zuka0828/isar-cip-core/-/tree/master" for
QEMU_x86-64 platform 2. Booted the image in QEMU virtual machine 3.
For each security package we compared the binaries
listed on Debian page e.g. for acl package at
(https://packages.debian.org/buster/amd64/acl/filelist)
According to the Debian page there are three binaries which
should be present in the image "/bin/chacl", "/bin/getfacl", "/bin/setfacl".
Then we check in the CIP running image at /bin whether all three packages are included or not.
4. Based on this kind of investigation we have prepare the attached
list of missing binary packages in current CIP isar image.

We found most of the packages are not included in the isar image,
could you please confirm whether all the proposed packages are included in the given source?
If it is included, could you please let us know how to install them in the image?

Once all the security packages are included in the CIP isar image,
we will proceed to next step of verifying applicable IEC 62443-4-2 security requirements.

Thanks & Regards,
Dinesh Kumar


-----Original Message-----
From: Cip-security <cip-security-bounces@lists.cip-project.org> On
Behalf Of kazuhiro3.hayashi@toshiba.co.jp
Sent: 21 February 2020 10:58
To: cip-security@lists.cip-project.org
Cc: cip-dev@lists.cip-project.org
Subject: [Cip-security] Sample image including security packages

Hello CIP Security WG,

I've created a sample setting to customize CIP Core generic profile.
https://gitlab.com/zuka0828/isar-cip-core/-/tree/master
(Now in my personal account)

Introduction:
https://gitlab.com/zuka0828/isar-cip-core/-/blob/master/SECURITY.md

Please ask in cip-dev if you need more development information :)

Note: `sudo` and `sudo-ldap` conflict each other, but both were proposed.
We need to select one from them.
I temporally removed the both from `IMAGE_PREINSTALL`.

Best regards,
Kazu

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

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded
Software India Pvt.
Ltd, for any loss or damage arising in any way from its use.
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the recipient and
may contain privileged information.
If you are not the intended recipient, please notify the sender and
delete the message along with any attachments/annexure/appendices.
You should not disclose, copy or otherwise use the information
contained in the message or any annexure. Any views expressed in
this e-mail are those of the individual sender except where the
sender specifically states them to be the views of Toshiba Software India Pvt. Ltd.
(TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and
no responsibility is accepted by Toshiba Embedded Software India
Pvt. Ltd, for any loss or damage arising in any way from its use.
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the recipient and
may contain privileged information.
If you are not the intended recipient, please notify the sender and
delete the message along with any attachments/annexure/appendices. You
should not disclose, copy or otherwise use the information contained
in the message or any annexure. Any views expressed in this e-mail are
those of the individual sender except where the sender specifically
states them to be the views of Toshiba Software India Pvt. Ltd.
(TSIP),Bangalore.

Although this transmission and any attachments are believed to be free
of any virus or other defect that might affect any computer system
into which it is received and opened, it is the responsibility of the
recipient to ensure that it is virus free and no responsibility is
accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

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

2561 - 2580 of 7074