1. cip-dev@lists.cip-project.org
  2. Messages
   Date   
[RFC PATCH 4.19.y-cip 02/50] PCI: dwc: Add ->get_features() callback function to dw_pcie_ep_ops

Lad Prabhakar
 

From: Kishon Vijay Abraham I <kishon@ti.com>

commit fee35cb76a54c87985410ea6aa12002e5d38b367 upstream.

Each platform using Designware PCIe core can support different set of
endpoint features. Add a new callback function ->get_features() in
dw_pcie_ep_ops so that each platform using Designware PCIe core can
advertise its supported features to the endpoint function driver.

Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/pci/controller/dwc/pcie-designware-ep.c | 12 ++++++++++++
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 13 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index a3d07d9c598b..d1bb4b852b6c 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -355,6 +355,17 @@ static int dw_pcie_ep_start(struct pci_epc *epc)
return pci->ops->start_link(pci);
}

+static const struct pci_epc_features*
+dw_pcie_ep_get_features(struct pci_epc *epc, u8 func_no)
+{
+ struct dw_pcie_ep *ep = epc_get_drvdata(epc);
+
+ if (!ep->ops->get_features)
+ return NULL;
+
+ return ep->ops->get_features(ep);
+}
+
static const struct pci_epc_ops epc_ops = {
.write_header = dw_pcie_ep_write_header,
.set_bar = dw_pcie_ep_set_bar,
@@ -368,6 +379,7 @@ static const struct pci_epc_ops epc_ops = {
.raise_irq = dw_pcie_ep_raise_irq,
.start = dw_pcie_ep_start,
.stop = dw_pcie_ep_stop,
+ .get_features = dw_pcie_ep_get_features,
};

int dw_pcie_ep_raise_legacy_irq(struct dw_pcie_ep *ep, u8 func_no)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 14dcf6646699..90f978f2d1b0 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -181,6 +181,7 @@ struct dw_pcie_ep_ops {
void (*ep_init)(struct dw_pcie_ep *ep);
int (*raise_irq)(struct dw_pcie_ep *ep, u8 func_no,
enum pci_epc_irq_type type, u16 interrupt_num);
+ const struct pci_epc_features* (*get_features)(struct dw_pcie_ep *ep);
};

struct dw_pcie_ep {
--
2.17.1
[RFC PATCH 4.19.y-cip 01/50] PCI: endpoint: Add new pci_epc_ops to get EPC features

Lad Prabhakar
 

From: Kishon Vijay Abraham I <kishon@ti.com>

commit 41cb8d189c9d4964df52a6f497cab7b301ae831b upstream.

Add a new pci_epc_ops ->get_features() to get the features
supported by the EPC. Since EPC can provide different features to
different functions, the ->get_features() ops takes _func_no_ as
an argument.

Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/pci/endpoint/pci-epc-core.c | 30 +++++++++++++++++++++++++++++
include/linux/pci-epc.h | 22 +++++++++++++++++++++
2 files changed, 52 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index 094dcc3203b8..5a099479d9ab 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -83,6 +83,36 @@ struct pci_epc *pci_epc_get(const char *epc_name)
}
EXPORT_SYMBOL_GPL(pci_epc_get);

+/**
+ * pci_epc_get_features() - get the features supported by EPC
+ * @epc: the features supported by *this* EPC device will be returned
+ * @func_no: the features supported by the EPC device specific to the
+ * endpoint function with func_no will be returned
+ *
+ * Invoke to get the features provided by the EPC which may be
+ * specific to an endpoint function. Returns pci_epc_features on success
+ * and NULL for any failures.
+ */
+const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
+ u8 func_no)
+{
+ const struct pci_epc_features *epc_features;
+ unsigned long flags;
+
+ if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
+ return NULL;
+
+ if (!epc->ops->get_features)
+ return NULL;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ epc_features = epc->ops->get_features(epc, func_no);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return epc_features;
+}
+EXPORT_SYMBOL_GPL(pci_epc_get_features);
+
/**
* pci_epc_stop() - stop the PCI link
* @epc: the link of the EPC device that has to be stopped
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 931fda3e5e0d..fcd5e5047546 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -59,6 +59,8 @@ struct pci_epc_ops {
enum pci_epc_irq_type type, u16 interrupt_num);
int (*start)(struct pci_epc *epc);
void (*stop)(struct pci_epc *epc);
+ const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
+ u8 func_no);
struct module *owner;
};

@@ -103,6 +105,24 @@ struct pci_epc {
unsigned int features;
};

+/**
+ * struct pci_epc_features - features supported by a EPC device per function
+ * @linkup_notifier: indicate if the EPC device can notify EPF driver on link up
+ * @msi_capable: indicate if the endpoint function has MSI capability
+ * @msix_capable: indicate if the endpoint function has MSI-X capability
+ * @reserved_bar: bitmap to indicate reserved BAR unavailable to function driver
+ * @bar_fixed_64bit: bitmap to indicate fixed 64bit BARs
+ * @bar_fixed_size: Array specifying the size supported by each BAR
+ */
+struct pci_epc_features {
+ unsigned int linkup_notifier : 1;
+ unsigned int msi_capable : 1;
+ unsigned int msix_capable : 1;
+ u8 reserved_bar;
+ u8 bar_fixed_64bit;
+ u64 bar_fixed_size[BAR_5 + 1];
+};
+
#define EPC_FEATURE_NO_LINKUP_NOTIFIER BIT(0)
#define EPC_FEATURE_BAR_MASK (BIT(1) | BIT(2) | BIT(3))
#define EPC_FEATURE_MSIX_AVAILABLE BIT(4)
@@ -161,6 +181,8 @@ int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
enum pci_epc_irq_type type, u16 interrupt_num);
int pci_epc_start(struct pci_epc *epc);
void pci_epc_stop(struct pci_epc *epc);
+const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
+ u8 func_no);
struct pci_epc *pci_epc_get(const char *epc_name);
void pci_epc_put(struct pci_epc *epc);

--
2.17.1
[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(岩松 信洋 □ＳＷＣ◯ＡＣＴ)
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(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <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(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <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

?
signature.asc

2861 - 2880 of 8382