Date   

Migration complete - Re: Mailman2 to Groups.io reminder

Neal Caidin
 

Dear CIP Community,

The migration is complete. 

You should receive an email shortly asking you to log in with your email address and set a password.

One important note, please do NOT unsubscribe from the "main" list. This would unsubscribe you from all of the CIP lists. "main" is an administrative list used by Groups.io as a parent list to manage the other lists. Please let me know if you have any questions or issues. 

Lists

On Mon, Apr 6, 2020 at 3:34 PM Neal Caidin <ncaidin@...> wrote:
Reminder.  Mailman2 to Groups.io conversion about to kick off (about an 1 1/2 hours from now).


Please see schedule below.

Best Regards,
Neal



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


On Thu, Apr 2, 2020 at 4:56 PM Neal Caidin <ncaidin@...> wrote:
[cross posted]

Reminder.  Mailman2 to Groups.io email is scheduled to start on 

Pacific - 2 pm , Monday, April 6
Eastern - 5 pm, Monday April 6
CET - 11 pm, Monday April 6
JST - 6 am, Tuesday, April 7

It is expected to take several hours, but could be as much as a full 24 hours. 

When the migration is completed, I will send out the links so that you can access email archives.

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: Python 3.x vs 2.7

Jan Kiszka
 

On 03.04.20 23:47, Pavel Machek wrote:
Hi!


FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.
See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht
I'm not sure what your exact requirements are, but have you considered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to do
incremental backups...
I suppose there is that concern about GPLv3 again (as with broadly used rsync) - which is generally overrated. There exists legal views that already GPLv2 requires to keep such licensed components replaceable on the target. What then effectively remains with v3 is its, well, wording complexity.

Jan

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


Re: Python 3.x vs 2.7

punit1.agrawal@...
 

Hi Kent,

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

Thank you for your feedback, Iwamatsu-san.

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
[...]

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye
archive 3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

In my opinion, it is difficult to support Python2 for a super long term. And I think
it is difficult to support each library using Python2.
Therefore, I think Option2 is good. And if necessary, we can use
backposts.debian.org.
Actually, option-2 is dominant in the security team as well.
From a brief look at the pros / cons between the two choices (below), I
am also biased towards backporting a python3 based version of duplicity.

Suggested next steps further down -

* Python2

Pros
----
* No backport (to Buster) needed (least effort, right now)

Cons
----
* Has reached EOL in upstream. Not sure about ELTS support. It maybe
that if we go with Python2, we (CIP) is on our own.


* Python3

Pros
----
* Python3 is available in Debian Buster
* Likely to be supported for longer time - upstream and in Debian

Cons
----
* Needs backporting duplicity (and dependencies) to Buster via
backports to align with upstream first approach of CIP.
- From a quick check of dependencies in bullseye a backport of
librsync2 might also be needed.


Next steps
----------
* Investigate the effort to backport duplicity (and dependencies) to
buster-backports.
* If no major surprises are found during the investigation, work with
Debian upstream to upload the new version.

Hope that makes sense.

Thanks,
Punit


However, packages with large dependencies can be difficult to backports. For
example Kbuckup is difficult, I think.
Agree. We are not going to select the package which is GPL-3 or has a lot of dependent package, so the duplicity is only one candidate for us substantially.

Best regards,
Nobuhiro

From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento
Yoshida
Sent: Thursday, April 2, 2020 6:59 PM
To: cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: [cip-dev] Python 3.x vs 2.7

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the
python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the
functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is
not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive 3.
Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

FYI, unfortunately we couldn't find the alternative package for system backup. The
duplicity is the best package for us from the license and num of dependencies
point of view.
See the following.

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

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


Re: Python 3.x vs 2.7

Pavel Machek
 

Hi!


FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.
See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht
I'm not sure what your exact requirements are, but have you considered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to do
incremental backups...

Best regards,
Pavel

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


Re: Python 3.x vs 2.7

Kento Yoshida
 

Thank you for your feedback, Iwamatsu-san.

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: Friday, April 3, 2020 8:19 AM
To: Kento Yoshida <kento.yoshida.wz@renesas.com>; cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: RE: Python 3.x vs 2.7

Hi,

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye
archive 3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

In my opinion, it is difficult to support Python2 for a super long term. And I think
it is difficult to support each library using Python2.
Therefore, I think Option2 is good. And if necessary, we can use
backposts.debian.org.
Actually, option-2 is dominant in the security team as well.

However, packages with large dependencies can be difficult to backports. For
example Kbuckup is difficult, I think.
Agree. We are not going to select the package which is GPL-3 or has a lot of dependent package, so the duplicity is only one candidate for us substantially.

Best regards,
Nobuhiro

From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento
Yoshida
Sent: Thursday, April 2, 2020 6:59 PM
To: cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: [cip-dev] Python 3.x vs 2.7

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the
python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the
functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is
not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive 3.
Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

FYI, unfortunately we couldn't find the alternative package for system backup. The
duplicity is the best package for us from the license and num of dependencies
point of view.
See the following.

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

Best regards,
Kent


Re: Python 3.x vs 2.7

Nobuhiro Iwamatsu
 

Hi,

As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive
3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.
In my opinion, it is difficult to support Python2 for a super long term. And I think it is difficult to support each library using Python2.
Therefore, I think Option2 is good. And if necessary, we can use backposts.debian.org.
However, packages with large dependencies can be difficult to backports. For example Kbuckup is difficult, I think.

Best regards,
Nobuhiro

From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento Yoshida
Sent: Thursday, April 2, 2020 6:59 PM
To: cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: [cip-dev] Python 3.x vs 2.7

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive
3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.

FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.
See the following.

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV
Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

Best regards,
Kent


Mailman2 to Groups.io reminder

Neal Caidin
 

[cross posted]

Reminder.  Mailman2 to Groups.io email is scheduled to start on 

Pacific - 2 pm , Monday, April 6
Eastern - 5 pm, Monday April 6
CET - 11 pm, Monday April 6
JST - 6 am, Tuesday, April 7

It is expected to take several hours, but could be as much as a full 24 hours. 

When the migration is completed, I will send out the links so that you can access email archives.

Best regards,
Neal


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


Python 3.x vs 2.7

Kento Yoshida
 

Hi CIP core group,

 

The security package proposal is suspended now, but I'd like to discuss about the python version which is suitable to maintain.

 

We selected "duplicity" for the requirement of system backup according to the functionality, license, the number of dependencies and so on.

However, the duplicity in the Debian buster [1] dependent on python 2.7, which is not maintained anymore [2].

 

[1] https://packages.debian.org/source/buster/duplicity

[2] https://pythonclock.org/

 

As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:

 

1. Maintain python 2.7 as well

2. Backport the upper duplicity which migrated python 3.x in bullseye archive

3. Others

 

What do you think is best?

I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.

 

FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.

See the following.

 

<Rsync>

Encryption: No

Schedule backup: No

Incremental backup: Yes

License: GPL v3

Dependencies count (aprox): 24

Reference: https://rsync.samba.org/features.html

 

<duplicity>

Encryption: Yes

Schedule backup: No

Incremental backup: Yes

License: GPL v2

Dependencies count (aprox): 80

Reference: http://duplicity.nongnu.org/features.ht

 

<Backuppc>

Encryption: No

Schedule backup: Yes

Incremental backup: Yes

License: GPL-2+, X11

Dependencies count (aprox): 132

Reference: http://backuppc.sourceforge.net/info.html

 

<Amanda>

Encryption: Yes

Schedule backup: Yes

Incremental backup: Yes

License: GPL-2+

Dependencies count (aprox): 289

Reference: https://www.zmanda.com/amanda-community-edition.html

 

<Kbackup>

Encryption: Yes

Schedule backup: Yes

Incremental backup: Yes

License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV

Dependencies count (aprox): 414

Reference: https://kde.org/applications/utilities/org.kde.kbackup

 

Best regards,

Kent


Re: CIP IRC weekly meeting today

masashi.kudo@...
 

Hi, Iwamatsu-san,

Noted. Then, see you next week!

Best regards,
--
M. Kudo

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: Thursday, April 2, 2020 5:19 PM
To: 工藤 雅司(CTJ OSS事業推進室) <masashi.kudo@cybertrust.co.jp>; cip-dev@lists.cip-project.org
Subject: RE: CIP IRC weekly meeting today

Hi,

Sorry, I can not join IRC meeting today.

-----Original Message-----
From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf
Of masashi.kudo@cybertrust.co.jp
Sent: Thursday, April 2, 2020 9:30 AM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss
technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00
starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020
&month=4&day=2&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&
p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

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

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/03/cip.2020-03-26-09.
00.log.html

Agenda:

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

2.
Strengthen sustainable process to backport patches from Mainline/LTS -
Kernel Team 2-1. Workflow for identifying important fixes,
backporting, and reviewing them 2-2. Prepare the tools to be used for
this workflow 2-3. Get practice in backporting patches 3. Upload a
guideline for reference hardware platform addition - masashi910

* Kernel maintenance updates
No update. But I reviewed and checked other LTS kernel.

* Kernel testing
* CIP Core
* Software update
* CIP Security
* AOB

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


Re: CIP IRC weekly meeting today

Nobuhiro Iwamatsu
 

Hi,

Sorry, I can not join IRC meeting today.

-----Original Message-----
From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf
Of masashi.kudo@cybertrust.co.jp
Sent: Thursday, April 2, 2020 9:30 AM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss
technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00
starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020
&month=4&day=2&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&
p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

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

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/03/cip.2020-03-26-09.
00.log.html

Agenda:

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

2.
Strengthen sustainable process to backport patches from Mainline/LTS -
Kernel Team 2-1. Workflow for identifying important fixes, backporting,
and reviewing them 2-2. Prepare the tools to be used for this workflow
2-3. Get practice in backporting patches 3. Upload a guideline for
reference hardware platform addition - masashi910

* Kernel maintenance updates
No update. But I reviewed and checked other LTS kernel.

* Kernel testing
* CIP Core
* Software update
* CIP Security
* AOB

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


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

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

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

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

Agenda:

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

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* CIP Security
* AOB

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

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


Test case for the security pacakges tied to requirements of IEC 62443-4-2

Kento Yoshida
 

Hi,

 

As the last IRC meeting, I'll share a draft of test cases for security packages.

Noted that this draft is still under review and improvement.

In addition, it finally will be revised during validation with the certification body. Then, we don't intend to complete it at this moment.

But if you have any question or feedback, please let me know.

 

BR, Kent


Enquiry of BV

WORLDS VALVE <tjwdsv@...>
 

Hi Sir/Madam,

Glad to hear that you are on the market for valves, we specialize in this field for 13 years with the strength of BUTTERFLY VALVES with good quality and pretty competitive price.

Also we have our own professional designers to meet any of your requirements.

If you are interested in,Please let me know.

 

Best Regards!

 

 

Huang Dekai

____________________________

Tianjin Worlds Valve co., ltd.

www.wdsvalve.com

www.worldsvalve.com

Tel:0086-13682070288
Add:No.25,Fuhui Road,Jinnan District,Tianjin, China


[ANNOUNCE] Release v4.19.113-cip23

Nobuhiro Iwamatsu
 

Hi all,

CIP kernel team has released Linux kernel v4.19.113-cip23.

The linux-4.19.y-cip tree has been updated base version from v4.19.109 to v4.19.113.
You can get this release via the git tree at:

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

Best regards,
Nobuhiro


Re: [PATCH 4.4] vhost: Check docket sk_family instead of call getname

punit1.agrawal@...
 

Hi Pavel,

A couple of comments below -

Pavel Machek <pavel@ucw.cz> writes:

From: Eugenio Pérez <eperezma@redhat.com>

Doing so, we save one call to get data we already have in the struct.

Also, since there is no guarantee that getname use sockaddr_ll
parameter beyond its size, we add a little bit of security here.
It should do not do beyond MAX_ADDR_LEN, but syzbot found that
ax25_getname writes more (72 bytes, the size of full_sockaddr_ax25,
versus 20 + 32 bytes of sockaddr_ll + MAX_ADDR_LEN in syzbot repro).

Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server")
Reported-by: syzbot+f2a62d07a5198c819c7b@syzkaller.appspotmail.com
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Upstream: 42d84c8490f9f0931786f1623191fcab397c3d64
Please follow the style guidelines documented in
Documentation/process/stable-kernel-rules.rst. In this instance, please
mention the upstream commit id following -

The upstream commit ID must be specified with a separate line above the
commit
text, like this:

commit <sha1> upstream.

For an example, take a look at Commit ad598a48fe61 ("vhost: Check docket
sk_family instead of call getname"). It's a backport of the same
upstream patch to 4.19 stable kernel.

Signed-off-by: Pavel Machek <pavel@denx.de>
---
drivers/vhost/net.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)

---

Since it is a security problem, I backported the patch to 4.4. I
compile tested it on cip test farm, but it was only built for single
target, probably due to too big config.

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 1459dc9fd701..5efac33c29dc 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -815,11 +815,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)

static struct socket *get_raw_socket(int fd)
{
- struct {
- struct sockaddr_ll sa;
- char buf[MAX_ADDR_LEN];
- } uaddr;
- int uaddr_len = sizeof uaddr, r;
+ int r;
struct socket *sock = sockfd_lookup(fd, &r);

if (!sock)
@@ -831,12 +827,7 @@ static struct socket *get_raw_socket(int fd)
goto err;
}

- r = sock->ops->getname(sock, (struct sockaddr *)&uaddr.sa,
- &uaddr_len, 0);
- if (r)
- goto err;
-
- if (uaddr.sa.sll_family != AF_PACKET) {
+ if (sock->sk->sk_family != AF_PACKET) {
r = -EPFNOSUPPORT;
goto err;
}
--
2.20.1
This patch fails to apply with the following error -

% git am vhost.mbox
Applying: vhost: Check docket sk_family instead of call getname
error: corrupt patch at line 16
Patch failed at 0001 vhost: Check docket sk_family instead of call
getname
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

There is some encoding issue in your mail client. The same workflow
works for other kernel patches.

Thanks,
Punit


Re: 4.4-rt: Need testing on arm32

Pavel Machek
 

Hi!

I tried to prepare next 4.4-rt release. I have code ready, but while
running tests I realized that only two targets are used to run them.

We 4.19-rt has known bugs breaking boot on de0-nano (and probably
other) boards, and according to code inspection, same bug is present
in 4.4-rt. Fix is not complex, but I'm not comfortable applying it
without _any_ testing.

If I'm right, 4.4-rt should be broken on socfpga boards (arm32) in
non-realtime configuration; it should panic on boot in cca 50% of
cases. Patch below should fix it.
And I pushed code _without_ the patch to kernel.org,

To gitolite.kernel.org:pub/scm/linux/kernel/git/cip/linux-cip.git
924af895a033..fbc533f445d2 linux-4.4.y-cip-rt -> linux-4.4.y-cip-rt

Best regards,
Pavel

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


4.4-rt: Need testing on arm32

Pavel Machek
 

Hi!

I tried to prepare next 4.4-rt release. I have code ready, but while
running tests I realized that only two targets are used to run them.

We 4.19-rt has known bugs breaking boot on de0-nano (and probably
other) boards, and according to code inspection, same bug is present
in 4.4-rt. Fix is not complex, but I'm not comfortable applying it
without _any_ testing.

If I'm right, 4.4-rt should be broken on socfpga boards (arm32) in
non-realtime configuration; it should panic on boot in cca 50% of
cases. Patch below should fix it.

Best regards,
Pavel

commit 20124aef8572b764ffd90d836253153102c763c5
Author: Pavel Machek <pavel@ucw.cz>
Date: Sat Mar 21 22:58:43 2020 +0100

With -rt tree but prempt-rt not enabled, de0-nano was getting failures
during boot, such as this:

https://lava.ciplatform.org/scheduler/job/13037

[ 6.813352] Freeing unused kernel memory: 1024K
[ 6.817927] Unable to handle kernel paging request at virtual address e7fddef0
[ 6.825121] pgd = (ptrval)
[ 6.827816] [e7fddef0] *pgd=27e1141e(bad)
[ 6.831818] Internal error: Oops: 8000000d [#1] SMP ARM
[ 6.837019] Modules linked in:
[ 6.840067] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.106-cip21-gc82fe0af5 #1
[ 6.847601] Hardware name: Altera SOCFPGA
[ 6.851596] PC is at 0xe7fddef0
[ 6.854733] LR is at irq_work_run_list+0x84/0xc0

Bisect revealed fc9f4631a290 is the problematic commit, and some code
auditing revealed that it is working with wrong list. Fix it.

Signed-off-by: Pavel Machek <pavel@denx.de>
Fixes: fc9f4631a290 ("irqwork: push most work into softirq context")

diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 2899ba0d23d1..19896e6f1b2a 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -78,7 +78,8 @@ bool irq_work_queue_on(struct irq_work *work, int cpu)
if (!irq_work_claim(work))
return false;

- if (IS_ENABLED(CONFIG_PREEMPT_RT_FULL) && !(work->flags & IRQ_WORK_HARD_IRQ))
+ if ((IS_ENABLED(CONFIG_PREEMPT_RT_FULL) && !(work->flags & IRQ_WORK_HARD_IRQ))
+ || (work->flags & IRQ_WORK_LAZY))
list = &per_cpu(lazy_list, cpu);
else
list = &per_cpu(raised_list, cpu);

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


[PATCH 4.4] vhost: Check docket sk_family instead of call getname

Pavel Machek
 

From: Eugenio Pérez <eperezma@redhat.com>

Doing so, we save one call to get data we already have in the struct.

Also, since there is no guarantee that getname use sockaddr_ll
parameter beyond its size, we add a little bit of security here.
It should do not do beyond MAX_ADDR_LEN, but syzbot found that
ax25_getname writes more (72 bytes, the size of full_sockaddr_ax25,
versus 20 + 32 bytes of sockaddr_ll + MAX_ADDR_LEN in syzbot repro).

Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server")
Reported-by: syzbot+f2a62d07a5198c819c7b@syzkaller.appspotmail.com
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Upstream: 42d84c8490f9f0931786f1623191fcab397c3d64
Signed-off-by: Pavel Machek <pavel@denx.de>
---
drivers/vhost/net.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)

---

Since it is a security problem, I backported the patch to 4.4. I
compile tested it on cip test farm, but it was only built for single
target, probably due to too big config.

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 1459dc9fd701..5efac33c29dc 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -815,11 +815,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)

static struct socket *get_raw_socket(int fd)
{
- struct {
- struct sockaddr_ll sa;
- char buf[MAX_ADDR_LEN];
- } uaddr;
- int uaddr_len = sizeof uaddr, r;
+ int r;
struct socket *sock = sockfd_lookup(fd, &r);

if (!sock)
@@ -831,12 +827,7 @@ static struct socket *get_raw_socket(int fd)
goto err;
}

- r = sock->ops->getname(sock, (struct sockaddr *)&uaddr.sa,
- &uaddr_len, 0);
- if (r)
- goto err;
-
- if (uaddr.sa.sll_family != AF_PACKET) {
+ if (sock->sk->sk_family != AF_PACKET) {
r = -EPFNOSUPPORT;
goto err;
}
--
2.20.1


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


CIP IRC weekly meeting today

masashi.kudo@...
 

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=26&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-19-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
* CIP Security
* AOB
1. Summer Time
US summer time started on March 8. CEST starts on March 29. This IRC meeting stays to start 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.


Update - Re: April 6 cutover from Mailman2 to Group.io

Neal Caidin
 

Dear CIP community,

I have learned more information about the cutover plans. The migration is planned to start at 2 pm Pacific time on April 6, which is :
5 pm Eastern / 11 pm CET / and Tuesday, April 7 , 6 am JST 

The migration will probably take just a few hours, but the migration team would like to reserve 24 hours in case they run into any issues with transferring the archives into the new system.

I'll send more information about the migration as I learn more and as we get closer to the conversion date.

Thanks for your patience and understanding.

Best regards,
Neal

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


On Thu, Mar 12, 2020 at 3:50 PM Neal Caidin <ncaidin@...> wrote:
[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)

2521 - 2540 of 7074