Date   

[RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Lad Prabhakar
 

Hi All,

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.

* Required EP framework changes and fixes are ported as well.
* All the patches have been cheery picked from upstream kernel.
* Patches [43, 44, 45, 46, 48]/50 are picked from linux-next.
* I was skeptic with patch 36/50 "Rename pcie-rcar.c to pcie-rcar-host.c"
this is required as patch 38/50 adds a new file named pcie-rcar.c. Open
for suggestions if this can be handled differently.
* In patch 37/48 I have dropped the changes for host driver as the patch
doesn't apply cleanly and manually applying it was resulting in a big diff.
* As the changes touches three other controller drivers I have build tested them
as done similarly while upstreaming R-Car Gen3 PCIe EP driver.
* Since the changes are huge I am sending the patches as RFC.

Cheers,
Prabhakar

Alan Mikhak (5):
PCI: endpoint: Set endpoint controller pointer to NULL
PCI: endpoint: Allocate enough space for fixed size BAR
PCI: endpoint: Skip odd BAR when skipping 64bit BAR
PCI: endpoint: Clear BAR before freeing its space
PCI: endpoint: Cast the page number to phys_addr_t

Hewenliang (1):
tools: PCI: Fix fd leakage

Jean-Jacques Hiblot (1):
tools: PCI: Exit with error code when test fails

Kangjie Lu (1):
PCI: endpoint: Fix a potential NULL pointer dereference

Kishon Vijay Abraham I (23):
PCI: endpoint: Add new pci_epc_ops to get EPC features
PCI: dwc: Add ->get_features() callback function to dw_pcie_ep_ops
PCI: designware-plat: Populate ->get_features() dw_pcie_ep_ops
PCI: pci-dra7xx: Populate ->get_features() dw_pcie_ep_ops
PCI: rockchip: Populate ->get_features() dw_pcie_ep_ops
PCI: cadence: Populate ->get_features() cdns_pcie_epc_ops
PCI: endpoint: Add helper to get first unreserved BAR
PCI: endpoint: Fix pci_epf_alloc_space() to set correct MEM TYPE flags
PCI: pci-epf-test: Remove setting epf_bar flags in function driver
PCI: pci-epf-test: Do not allocate next BARs memory if current BAR is
64Bit
PCI: pci-epf-test: Use pci_epc_get_features() to get EPC features
PCI: cadence: Remove pci_epf_linkup() from Cadence EP driver
PCI: rockchip: Remove pci_epf_linkup() from Rockchip EP driver
PCI: designware-plat: Remove setting epc->features in Designware plat
EP driver
PCI: endpoint: Remove features member in struct pci_epc
PCI: endpoint: Add support to specify alignment for buffers allocated
to BARs
PCI: endpoint: Use notification chain mechanism to notify EPC events
to EPF
PCI: endpoint: Replace spinlock with mutex
PCI: endpoint: Protect concurrent access to pci_epf_ops with mutex
PCI: endpoint: Assign function number for each PF in EPC core
PCI: endpoint: Fix ->set_msix() to take BIR and offset as arguments
PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table
address
PCI: endpoint: functions/pci-epf-test: Print throughput information

Kunihiko Hayashi (1):
PCI: endpoint: Fix clearing start entry in configfs

Lad Prabhakar (15):
PCI: endpoint: Pass page size as argument to pci_epc_mem_init()
PCI: endpoint: Add support to handle multiple base for mapping
outbound memory
PCI: rcar: Rename pcie-rcar.c to pcie-rcar-host.c
arm64: defconfig: Enable CONFIG_PCIE_RCAR_HOST
PCI: rcar: Move shareable code to a common file
PCI: rcar: Fix calculating mask for PCIEPAMR register
dt-bindings: PCI: rcar: Add bindings for R-Car PCIe endpoint
controller
PCI: rcar: Add endpoint mode support
arm64: defconfig: Enable R-Car PCIe endpoint driver
dt-bindings: pci: rcar-pci-ep: Document r8a774a1 and r8a774b1
arm64: dts: renesas: r8a774c0: Add PCIe EP node
arm64: dts: renesas: r8a774a1: Add PCIe EP nodes
arm64: dts: renesas: r8a774b1: Add PCIe EP nodes
misc: pci_endpoint_test: Add Device ID for RZ/G2E PCIe controller
misc: pci_endpoint_test: Add Device ID for RZ/G2M and RZ/G2N PCIe
controllers

Vidya Sagar (3):
PCI: endpoint: Add core init notifying feature
PCI: endpoint: Add notification for core init completion
PCI: pci-epf-test: Add support to defer core initialization

.../devicetree/bindings/pci/rcar-pci-ep.yaml | 80 ++
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 38 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 38 +
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 19 +
arch/arm64/configs/defconfig | 7 +-
drivers/misc/pci_endpoint_test.c | 7 +
drivers/pci/controller/Kconfig | 18 +
drivers/pci/controller/Makefile | 3 +-
drivers/pci/controller/dwc/pci-dra7xx.c | 13 +
.../pci/controller/dwc/pcie-designware-ep.c | 39 +-
.../pci/controller/dwc/pcie-designware-plat.c | 17 +-
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/pcie-cadence-ep.c | 27 +-
drivers/pci/controller/pcie-rcar-ep.c | 563 ++++++++
drivers/pci/controller/pcie-rcar-host.c | 1264 +++++++++++++++++
drivers/pci/controller/pcie-rcar.c | 1224 +---------------
drivers/pci/controller/pcie-rcar.h | 140 ++
drivers/pci/controller/pcie-rockchip-ep.c | 18 +-
drivers/pci/endpoint/functions/pci-epf-test.c | 295 +++-
drivers/pci/endpoint/pci-ep-cfs.c | 28 +-
drivers/pci/endpoint/pci-epc-core.c | 187 ++-
drivers/pci/endpoint/pci-epc-mem.c | 204 ++-
drivers/pci/endpoint/pci-epf-core.c | 49 +-
include/linux/pci-epc.h | 95 +-
include/linux/pci-epf.h | 32 +-
tools/pci/pcitest.c | 5 +-
26 files changed, 2919 insertions(+), 1492 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml
create mode 100644 drivers/pci/controller/pcie-rcar-ep.c
create mode 100644 drivers/pci/controller/pcie-rcar-host.c
create mode 100644 drivers/pci/controller/pcie-rcar.h

--
2.17.1


LAVA infrastructure: Planned maintenance

Chris Paterson
 

Hello all,

Just a heads up that the CIP LAVA infrastructure will be offline for a couple of hours (maybe less, maybe more) on Wednesday 14th from about 0700 UTC.

We're going to be upgrading to the latest version of lava-docker on the master and workers.

If the downtime at that time is going to cause any headaches please let me know, preferably before Wednesday...

Kind regards, Chris


Re: Backporting of security patches for Intel i40e drivers required?

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

Hi, Jan-san,

Thanks for your response.

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
Jan Kiszka
Sent: Friday, October 9, 2020 4:24 PM
To: nobuhiro1.iwamatsu@toshiba.co.jp; cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Backporting of security patches for Intel i40e drivers
required?

Hi all,

given the exposure of such a device but also the fact that I can't tell for sure
if/where it's used (not only by us), I would recommend backporting.

Jan

On 09.10.20 02:23, nobuhiro1.iwamatsu@toshiba.co.jp wrote:
Hi,

I have some comment for this issue.
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200810/021
006.html

https://lore.kernel.org/stable/20200807205517.1740307-1-jesse.brandebu
rg@intel.com/

There are multiple patches fixed for 4.19, which can be separated by feature.

- i40e: add num_vectors checker in iwarp handler

This issue has been produced by e3219ce6a7754 ("i40e: Add support for
client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

- i40e: Wrong truncation from u16 to u8
This can be apply in 4.4.y.

- i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

This issue has been produced by e284fc280473b ("i40e: Add and delete
cloud filter").
It is not included in 4.4.y. However, this patch has several different fixes, so
some patches need to be applied.

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -181,7 +181,7 @@ static inline bool i40e_vc_isvalid_vsi_id(struct
i40e_vf *vf, u16 vsi_id)
* check for the valid queue id
**/
static inline bool i40e_vc_isvalid_queue_id(struct i40e_vf *vf, u16 vsi_id,
- u8 qid)
+ u16 qid)
{
struct i40e_pf *pf = vf->pf;
struct i40e_vsi *vsi = i40e_find_vsi_from_id(pf, vsi_id);


- i40e: Memory leak in i40e_config_iwarp_qvlist
This issue has been produced by e3219ce6a7754 ("i40e: Add support for
client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@lists.cip-project.org
[mailto:cip-dev@lists.cip-project.org] On Behalf Of
masashi.kudo@cybertrust.co.jp
Sent: Thursday, October 8, 2020 6:43 PM
To: cip-dev@lists.cip-project.org
Cc: jan.kiszka@siemens.com
Subject: [cip-dev] Backporting of security patches for Intel i40e drivers
required?

Hi, Jan-san, All,

At the IRC meeting today, we identified the following new CVEs are not in
LTS4.4 yet.

- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for
mainline and 4.19+

These are for i40e driver for Intel.

The kernel team would like to know whether their backporting is needed or
not.

For details of those CVE checking results, please see the following.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requ
ests/75/diffs

Regarding the discussion of the IRC meeting, please see the following.
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.0
0.log.html

Best regards,
--
M. Kudo
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


Release v4.19.150-cip36 and v4.4.238-cip50

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.150-cip36 and v4.4.238-cip50.
The linux-4.19.y-cip tree has been updated base version to v4.19.150, and the
linux-4.4.y-cip tree has been updated base version to v4.4.238 with audio support
for iwg21d-q7 board.
And this release includes a patch for ravb (77972b55fb9d: Revert "ravb: Fixed to
be able to unload modules" ). This fixed the ethernet issue of Renesas
SoCs temporarily.

You can get this release via the git tree at:

v4.19.150-cip36:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
946cd6c834661fa97c8dc914c95fc8a90a111676
added commits:
CIP: Bump version suffix to -cip36 after merge from stable with ravb fix
Revert "ravb: Fixed to be able to unload modules"

v4.4.238-cip50:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
e21f6a3128beb731449030d76249db60d380b8dd
added commits:
CIP: Bump version suffix to -cip50 after merge from stable with ravb fix
Revert "ravb: Fixed to be able to unload modules"
ARM: dts: r8a7742-iwg21d-q7: Sound DMA support via DVC on DTS
ARM: dts: r8a7742-iwg21d-q7: Enable SGTL5000 audio codec
ARM: dts: r8a7742: Add audio support
dt-bindings: ASoC: renesas,rsnd: Add r8a7742 support

Best regards,
Nobuhiro


Re: Backporting of security patches for Intel i40e drivers required?

Jan Kiszka
 

Hi all,

given the exposure of such a device but also the fact that I can't tell
for sure if/where it's used (not only by us), I would recommend backporting.

Jan

On 09.10.20 02:23, nobuhiro1.iwamatsu@toshiba.co.jp wrote:
Hi,

I have some comment for this issue.
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200810/021006.html
https://lore.kernel.org/stable/20200807205517.1740307-1-jesse.brandeburg@intel.com/

There are multiple patches fixed for 4.19, which can be separated by feature.

- i40e: add num_vectors checker in iwarp handler

This issue has been produced by e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

- i40e: Wrong truncation from u16 to u8
This can be apply in 4.4.y.

- i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

This issue has been produced by e284fc280473b ("i40e: Add and delete cloud filter").
It is not included in 4.4.y. However, this patch has several different fixes, so some patches need to be applied.

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -181,7 +181,7 @@ static inline bool i40e_vc_isvalid_vsi_id(struct
i40e_vf *vf, u16 vsi_id)
* check for the valid queue id
**/
static inline bool i40e_vc_isvalid_queue_id(struct i40e_vf *vf, u16 vsi_id,
- u8 qid)
+ u16 qid)
{
struct i40e_pf *pf = vf->pf;
struct i40e_vsi *vsi = i40e_find_vsi_from_id(pf, vsi_id);


- i40e: Memory leak in i40e_config_iwarp_qvlist
This issue has been produced by e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of
masashi.kudo@cybertrust.co.jp
Sent: Thursday, October 8, 2020 6:43 PM
To: cip-dev@lists.cip-project.org
Cc: jan.kiszka@siemens.com
Subject: [cip-dev] Backporting of security patches for Intel i40e drivers required?

Hi, Jan-san, All,

At the IRC meeting today, we identified the following new CVEs are not in LTS4.4 yet.

- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for mainline and 4.19+

These are for i40e driver for Intel.

The kernel team would like to know whether their backporting is needed or not.

For details of those CVE checking results, please see the following.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requests/75/diffs

Regarding the discussion of the IRC meeting, please see the following.
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.00.log.html

Best regards,
--
M. Kudo
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


Re: Backporting of security patches for Intel i40e drivers required?

Nobuhiro Iwamatsu
 

Hi,

I have some comment for this issue.
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200810/021006.html
https://lore.kernel.org/stable/20200807205517.1740307-1-jesse.brandeburg@intel.com/

There are multiple patches fixed for 4.19, which can be separated by feature.

- i40e: add num_vectors checker in iwarp handler

This issue has been produced by e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

- i40e: Wrong truncation from u16 to u8
This can be apply in 4.4.y.

- i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

This issue has been produced by e284fc280473b ("i40e: Add and delete cloud filter").
It is not included in 4.4.y. However, this patch has several different fixes, so some patches need to be applied.

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -181,7 +181,7 @@ static inline bool i40e_vc_isvalid_vsi_id(struct
i40e_vf *vf, u16 vsi_id)
* check for the valid queue id
**/
static inline bool i40e_vc_isvalid_queue_id(struct i40e_vf *vf, u16 vsi_id,
- u8 qid)
+ u16 qid)
{
struct i40e_pf *pf = vf->pf;
struct i40e_vsi *vsi = i40e_find_vsi_from_id(pf, vsi_id);


- i40e: Memory leak in i40e_config_iwarp_qvlist
This issue has been produced by e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of
masashi.kudo@cybertrust.co.jp
Sent: Thursday, October 8, 2020 6:43 PM
To: cip-dev@lists.cip-project.org
Cc: jan.kiszka@siemens.com
Subject: [cip-dev] Backporting of security patches for Intel i40e drivers required?

Hi, Jan-san, All,

At the IRC meeting today, we identified the following new CVEs are not in LTS4.4 yet.

- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for mainline and 4.19+

These are for i40e driver for Intel.

The kernel team would like to know whether their backporting is needed or not.

For details of those CVE checking results, please see the following.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requests/75/diffs

Regarding the discussion of the IRC meeting, please see the following.
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.00.log.html

Best regards,
--
M. Kudo


Backporting of security patches for Intel i40e drivers required?

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

Hi, Jan-san, All,

At the IRC meeting today, we identified the following new CVEs are not in LTS4.4 yet.

- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for mainline and 4.19+

These are for i40e driver for Intel.

The kernel team would like to know whether their backporting is needed or not.

For details of those CVE checking results, please see the following.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requests/75/diffs

Regarding the discussion of the IRC meeting, please see the following.
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.00.log.html

Best regards,
--
M. Kudo


Re: CIP IRC weekly meeting today

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

On Thu, Oct 8, 2020 at 8:57 AM masashi.kudo@cybertrust.co.jp
<masashi.kudo@cybertrust.co.jp> wrote:

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=10&day=8&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/10/cip.2020-10-01-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Check whether CVE-2020-25284 needs to be backported to 4.4-rt
-> Delete rbd ( Ceph block device ) from 4.4-rt x86 config - iwamatsu
-> Done, so will be closed today.

* Kernel maintenance updates
I might not make it. Here's this week's update:

Five new CVEs:
- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for
mainline and 4.19+
- This is enabled in Siemens x86 configs for both 4.4 and 4.19
and we should probably backport them.
- CVE-2020-25643 [hdlc_ppp] - Fixed in all current stable kernels
- CVE-2020-26541 [UEFI secure boot] - Fix posted but hasn't landed

I also reviewed some patches from Daniel for cip-kernel-sec on the mailing list.

ChenYu



* Kernel testing
* Software update
* CIP Security
* AOB

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

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




Re: [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs

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

On Fri, Sep 25, 2020 at 12:01 PM Daniel Sangorrin
<daniel.sangorrin@toshiba.co.jp> wrote:

From: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>

I noticed that some issues have the description field empty
when using the --show-description option.

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Looks like all the new descriptions were copied from MITRE.

Reviewed-by: Chen-Yu Tsai (Moxa) <wens@csie.org>


Re: [cip-kernel-sec 2/3] report_affected: Delete extra blank lines between CVEs

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

On Thu, Oct 8, 2020 at 3:59 PM Chen-Yu Tsai <wens@csie.org> wrote:

On Fri, Sep 25, 2020 at 12:00 PM Daniel Sangorrin
<daniel.sangorrin@toshiba.co.jp> wrote:

From: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>

When using the --show-description option CVEs had blank
lines between them. Remove them to make it more compact.

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Reviewed-by: Chen-Yu Tsai (Moxa) <wens@csie.org>

Though these occurrences seem to be very rare.
Jumped the gun. This patch is no longer needed if you use join()
to combine the lines.


Re: [cip-kernel-sec 2/3] report_affected: Delete extra blank lines between CVEs

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

On Fri, Sep 25, 2020 at 12:00 PM Daniel Sangorrin
<daniel.sangorrin@toshiba.co.jp> wrote:

From: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>

When using the --show-description option CVEs had blank
lines between them. Remove them to make it more compact.

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Reviewed-by: Chen-Yu Tsai (Moxa) <wens@csie.org>

Though these occurrences seem to be very rare.

---
scripts/report_affected.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/report_affected.py b/scripts/report_affected.py
index a181d97..9894602 100755
--- a/scripts/report_affected.py
+++ b/scripts/report_affected.py
@@ -141,7 +141,7 @@ def main(git_repo, remotes, only_fixed_upstream,
wrap_description = ''
for line in textwrap.wrap(description, 80, break_long_words=False):
wrap_description += line + '\n '
- print(cve_id, '=>',wrap_description)
+ print(cve_id, '=>',wrap_description.strip())
else:
print('%s:' % branch['full_name'], *sorted_cve_ids)

--
2.25.1




Re: [cip-kernel-sec 1/3] report_affected: word-wrap for the 'description'

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

On Fri, Sep 25, 2020 at 12:00 PM Daniel Sangorrin
<daniel.sangorrin@toshiba.co.jp> wrote:

From: Nguyen Van Hieu <hieu2.nguyenvan@toshiba.co.jp>

Currently some descriptions are quite long, and it is hard to read.
Add line-breaks so every line is at most 80 characters long.

Signed-off-by: Nguyen Van Hieu <hieu2.nguyenvan@toshiba.co.jp>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
scripts/report_affected.py | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/report_affected.py b/scripts/report_affected.py
index a97b700..a181d97 100755
--- a/scripts/report_affected.py
+++ b/scripts/report_affected.py
@@ -19,6 +19,7 @@ import kernel_sec.branch
import kernel_sec.issue
import kernel_sec.version

+import textwrap

def main(git_repo, remotes, only_fixed_upstream,
include_ignored, show_description, *branch_names):
@@ -136,8 +137,11 @@ def main(git_repo, remotes, only_fixed_upstream,
if show_description:
print('%s:' % branch['full_name'])
for cve_id in sorted_cve_ids:
- print(cve_id, '=>',
- kernel_sec.issue.load(cve_id).get('description', 'None'))
+ description=kernel_sec.issue.load(cve_id).get('description', 'None')
+ wrap_description = ''
+ for line in textwrap.wrap(description, 80, break_long_words=False):
+ wrap_description += line + '\n '
I believe it would be better to include the "CVE => " string in the full text
passed to textwrap. That would make all lines properly wrapped at the given
width.

Also, textwrap can handle indentation for subsequent lines, so you don't have
to handle that yourself. And it might be easier to read if they matched up
with the beginning of the description in the first line.

Last, you could use join() to combine the lines.

So I would rewrite the part as:

text = cve_id + ' => ' +
kernel_sec.issue.load(cve_id).get('description', 'None')
print('\n'.join(textwrap.wrap(text, 80, subsequent_indent=' ' *
(len(cve_id) + 4), break_long_words=False)))


ChenYu
Moxa


+ print(cve_id, '=>',wrap_description)
else:
print('%s:' % branch['full_name'], *sorted_cve_ids)

--
2.25.1




Re: CIP IRC weekly meeting today

Nobuhiro Iwamatsu
 

Hi Kudo-san,

Sorry, I can not participate IRC meeting today.

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of
masashi.kudo@cybertrust.co.jp
Sent: Thursday, October 8, 2020 9:57 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=10&day=8&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/10/cip.2020-10-01-09.00.log.html

Agenda:

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

2. Check whether CVE-2020-25284 needs to be backported to 4.4-rt
-> Delete rbd ( Ceph block device ) from 4.4-rt x86 config - iwamatsu
-> Done, so will be closed today.

* Kernel maintenance updates
I reviewed 4.4.y-rc.

* Kernel testing
* Software update
* CIP Security
* AOB

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


Re: [ANNOUNCE] v4.19.148-cip35-rt15

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Sent: Thursday, October 8, 2020 2:32 PM
To: Pavel Machek <pavel@denx.de>
Cc: cip-dev@lists.cip-project.org; jan.kiszka@siemens.com; SZ.Lin@moxa.com; ben.hutchings@codethink.co.uk;
Chris.Paterson2@renesas.com
Subject: RE: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi Pavel,

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Thursday, October 8, 2020 5:11 AM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; pavel@denx.de; jan.kiszka@siemens.com; SZ.Lin@moxa.com;
ben.hutchings@codethink.co.uk; Chris.Paterson2@renesas.com
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi!

FYI:
https://patchwork.ozlabs.org/project/netdev/patch/20200922072931.2148-1-geert+renesas@glider.be/
Yes, and the revert is now queued to 4.19-stable, too.

So.. what do we want to do here?

We can merge 4.19.151 to -cip when it is released, and I can then
release new -cip-rt that works on renesas boards...
Yes, I think so.
Perhaps 4.19.151 will be released this weekend. And this week is the release week of the CIP kernel.
Sorry, this may be wrong.
If 151 isn't released this weekend, I'll cherry pick this commit, and release new CIP kernel.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-4.19.y&id=1fa5848fae409511eda2c6ee4f8ad9e42a0cb3c1

And I think we can use it to release the cip-rt tree.
Best regards,
Nobuhiro


Re: [ANNOUNCE] v4.19.148-cip35-rt15

Nobuhiro Iwamatsu
 

Hi Pavel,

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Thursday, October 8, 2020 5:11 AM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; pavel@denx.de; jan.kiszka@siemens.com; SZ.Lin@moxa.com;
ben.hutchings@codethink.co.uk; Chris.Paterson2@renesas.com
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi!

FYI:
https://patchwork.ozlabs.org/project/netdev/patch/20200922072931.2148-1-geert+renesas@glider.be/
Yes, and the revert is now queued to 4.19-stable, too.

So.. what do we want to do here?

We can merge 4.19.151 to -cip when it is released, and I can then
release new -cip-rt that works on renesas boards...
Yes, I think so.
Perhaps 4.19.151 will be released this weekend. And this week is the release week of the CIP kernel.
And I think we can use it to release the cip-rt tree.


Best regards,
Pavel
Best regards,
Nobuhiro


Re: CIP IRC weekly meeting today

Kento Yoshida
 

Hi Kudo-san and all,

I'll be absent today.

And, I'll report here as an alternative to attendance.
Both minor updates were once reported, but since they are protracted, I will summarize again here.

Major updates:
There is no major update this week.

Minor updates:
1. Gap assessment for the development process (IEC 62443-4-1):
The report from the certification body, whether development process for OSS meets to the IEC 62443-4-1 standard, is delayed.
But, perhaps we can get it the end of this week.
And then, we'll plan to share the documents on the development process that reflects the feedback from the report.
2. Gap assessment for security features of security packages we suggested (IEC 62443-4-2):
We started review security features of security packages we suggested to add as CIP core packages.
The completion date is scheduled by the end of December.
After this, we'll continue to proceed our suggestion, now it's pended.

Regards,
Kent

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
masashi.kudo@cybertrust.co.jp via lists.cip-project.org
Sent: Thursday, October 8, 2020 9:57 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&mont
h=10&day=8&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=24
1&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/10/cip.2020-10-01-09.00.log.htm
l

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Check whether CVE-2020-25284 needs to be backported to 4.4-rt
-> Delete rbd ( Ceph block device ) from 4.4-rt x86 config - iwamatsu
-> Done, so will be closed today.

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

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

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


CIP IRC weekly meeting today

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

Hi all,

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

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=8&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/10/cip.2020-10-01-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Check whether CVE-2020-25284 needs to be backported to 4.4-rt
-> Delete rbd ( Ceph block device ) from 4.4-rt x86 config - iwamatsu
-> Done, so will be closed today.

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

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

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


Re: [ANNOUNCE] v4.19.148-cip35-rt15

Pavel Machek
 

Hi!

FYI:
https://patchwork.ozlabs.org/project/netdev/patch/20200922072931.2148-1-geert+renesas@glider.be/
Yes, and the revert is now queued to 4.19-stable, too.

So.. what do we want to do here?

We can merge 4.19.151 to -cip when it is released, and I can then
release new -cip-rt that works on renesas boards...

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


Re: [cip-kernel-sec] reports: add script to convert reports to csv format

Daniel Sangorrin
 

Hello Ben,

Thanks a lot for your review and sorry for taking your time.
We will have an internal review and take your comments into account to prepare a new proposal.

Kind regards,
Daniel

-----Original Message-----
From: Ben Hutchings <ben.hutchings@codethink.co.uk>
Sent: Wednesday, October 7, 2020 6:28 AM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT) <daniel.sangorrin@toshiba.co.jp>; sz.lin@moxa.com; wens@csie.org
Cc: cip-dev@lists.cip-project.org
Subject: Re: [cip-kernel-sec] reports: add script to convert reports to csv format

On Fri, 2020-09-25 at 14:07 +0900, Daniel Sangorrin wrote:
The text version is probably enough for developers but customers
usually prefer to have a CSV that you can open with a spreadsheet
program and contains additional information. CVEs are sorted in rows
according to their criticality.
[...]

I think this script is trying to do too many different things:

1. Importing data from NVD
2. Importing data from Debian security tracker 3. Parsing an existing report (!) 4. Generating a new report

1. If there's useful information from NVD that belongs in reports, and the license allows us to redistribute it, we should add an import
script that adds that to the issue files (and extend the schema if necessary). We can then use that in any of the reporting scripts.

2. I'm not sure why the script is using Debian's general security tracker. Debian's kernel-sec normally has better information for kernel
issues, and the import_debian.py script already imports that.

3. The output of report_affected.py is intended to be human-readable, and just happens to be relatively easy to parse. If you want to
use its output as input, that should either be done by adding a structured format (e.g. JSON) for the intermediate file, or by sharing
code between the two reporting scripts so there's no need to use an intermediate file.

Other comments:

- The new script needs to be documented in README.md.

- Any files created in the process of importing data should go under the import/ subdirectory.

- Error handling needs improvement, e.g.:

+def download_file(src, file, bar=""):
+ """Re-download file when an error occurred due to network connection problem.
+ """
+ for i in range(3):
+ try:
+ wget.download(src, file, bar)
+ break
+ except:
+ pass
This doesn't check whether there was a network error; it retries in case of *any* error. The except block should specify which
exception types we want to handle.

+ if not os.path.exists(file):
+ print("ERROR: Can't download %s" % src)
Error messages should go to stderr.

+ exit(1)
This should call sys.exit.

Ben.

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


Re: [ANNOUNCE] v4.19.148-cip35-rt15

Nobuhiro Iwamatsu
 

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of Nobuhiro Iwamatsu
Sent: Tuesday, October 6, 2020 3:49 PM
To: cip-dev@lists.cip-project.org; pavel@denx.de
Cc: jan.kiszka@siemens.com; SZ.Lin@moxa.com; ben.hutchings@codethink.co.uk; Chris.Paterson2@renesas.com
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi,

This issue seems to occur randomly.

# cip+rt kernel
NG: https://lava.ciplatform.org/scheduler/job/57129
https://lava.ciplatform.org/scheduler/job/57842
OK: https://lava.ciplatform.org/scheduler/job/57851
https://lava.ciplatform.org/scheduler/job/57841

# 4.19.148+cip kernel
NG: https://lava.ciplatform.org/scheduler/job/58836
OK: https://lava.ciplatform.org/scheduler/job/58837


We may need to confirm these relationships with CIP kernel patches.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of Pavel Machek
Sent: Monday, October 5, 2020 6:39 AM
To: Chris Paterson <Chris.Paterson2@renesas.com>
Cc: Pavel Machek <pavel@denx.de>; jan.kiszka@siemens.com; cip-dev@lists.cip-project.org; SZ.Lin@moxa.com;
ben.hutchings@codethink.co.uk
Subject: Re: [cip-dev] [ANNOUNCE] v4.19.148-cip35-rt15

Hi!

New realtime trees should be available at kernel.org.

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-
cip.git/log/?h=linux-4.19.y-cip-rt
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-
cip.git/log/?h=linux-4.19.y-cip-rt-rebase

And their content should be identical.
Thank you for the release.


This patch merges 4.19.148-stable into -cip-rt (because that's what
recent -rt is based on, and older -rt tree is too old). Unfortunately,
that brings regression with ethernet on Renesas Arm64 targets, which
will prevent boot, and fail tests etc.

Kernel that should work ok on Renesas Arm64 machines can be obtained
by reverting fb3a780e7a76cf8efb055f8322ec039923cee41f "ravb: Fixed to
be able to unload modules" on top of -cip-rt release.
So we're releasing a Kernel that we know doesn't boot on one of CIP's reference platforms?
Or did you already revert the above patch as part of your release?
Yes, I did that, as the changelog explains. Sorry.

I had to select from few bad options: 4.19.147-rt release is not
available and previous release is too old. So -cip-rt is based on
4.19.148-rt, and it brings in the bad commit.

I thought about reverting it for release, but all I'd get would be
rejects, as it really needs to be solved in -cip, not -cip-rt.

Proper solution is likely updating 4.19-cip to 4.19.148, first. Then
figuring out what is the clean way to solve the problem, and then
creating new -rt release. But that will likely take more than few
days, and it will end up with different release number.

I can create new -cip-rt release when that is done.

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

1501 - 1520 of 7020