Date   

[PATCH 4.4.y-cip 1/9] drm: Add an encoder and connector type enum for DPI.

Biju Das <biju.das.jz@...>
 

From: Eric Anholt <eric@anholt.net>

commit 0b27c02a7f1c697694f2ad6d6517e7dbf9ecfa39 upstream.

Right now exynos is exposing DPI as a TMDS encoder and VGA connector,
which seems rather misleading. This isn't just an internal detail,
since xrandr actually exposes "VGA" as the output name. Define some
new enums so that vc4's DPI can have a more informative name.

I considered other names for the connector as well. For VC4, the
Adafruit DPI kippah takes the 28 GPIO pins and routes them to a
standard-ish 40-pin FPC connector, but "40-pin FPC" doesn't uniquely
identify an ordering of pins (apparently some other orderings exist),
doesn't explain things as well for the user (who, if anything, knows
their product is a DPI kippah/panel combo), and actually doesn't have
to exist (one could connect the 28 GPIOs directly to something else).
Simply "DPI" seems like a good compromise name to distinguish from the
HDMI, DSI, and TV connectors .

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/drm_crtc.c | 2 ++
include/uapi/drm/drm_mode.h | 2 ++
2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5e4bb4837bae..34538444fd19 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -168,6 +168,7 @@ static struct drm_conn_prop_enum_list drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
+ { DRM_MODE_CONNECTOR_DPI, "DPI" },
};

static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
@@ -179,6 +180,7 @@ static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
{ DRM_MODE_ENCODER_DSI, "DSI" },
{ DRM_MODE_ENCODER_DPMST, "DP MST" },
+ { DRM_MODE_ENCODER_DPI, "DPI" },
};

static const struct drm_prop_enum_list drm_subpixel_enum_list[] = {
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 6c11ca401de8..325e9eb3d812 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -202,6 +202,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_VIRTUAL 5
#define DRM_MODE_ENCODER_DSI 6
#define DRM_MODE_ENCODER_DPMST 7
+#define DRM_MODE_ENCODER_DPI 8

struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -241,6 +242,7 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_eDP 14
#define DRM_MODE_CONNECTOR_VIRTUAL 15
#define DRM_MODE_CONNECTOR_DSI 16
+#define DRM_MODE_CONNECTOR_DPI 17

struct drm_mode_get_connector {

--
2.17.1


[PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E board

Biju Das <biju.das.jz@...>
 

Add LCD Panel support for iWave RZ/G1E board based on r8a7745 SoC.

Backporting the panel patch as it is, requires drm bridge Api changes,
which is not present at 4.4 kernel. So used the 4.4 rm framework to attach
the simple panel driver with rgb connector driver. The rgb connector is
based on the workdone for the lvds connector. The display panel binding
patch is backported to 4.4 kernel,since the mainline uses yaml file and
it conflict with corresponding .txt in 4.4 kernel.

Other patches in this series are cherry picked from mainline.


Biju Das (2):
dt-bindings: display: Add bindings for EDT panel
drm: rcar-du: Support panels connected directly to the DPAD outputs

Eric Anholt (1):
drm: Add an encoder and connector type enum for DPI.

Fabrizio Castro (1):
ARM: shmobile: defconfig: Enable support for panels from EDT

Geert Uytterhoeven (1):
ARM: shmobile: defconfig: Enable frame buffer console for
armadillo800eva

Laurent Pinchart (1):
drm: rcar-du: Use the DRM panel API

Marian-Cristian Rotariu (2):
drm/panel: simple: Add EDT panel support
ARM: dts: iwg22d-sodimm: Enable LCD panel

Rob Herring (1):
of: add node name compare helper functions

.../display/panel/edt,etm043080dh6gp.txt | 9 ++
.../dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 6 +
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 59 ++++++++++
arch/arm/configs/shmobile_defconfig | 3 +
drivers/gpu/drm/drm_crtc.c | 2 +
drivers/gpu/drm/panel/panel-simple.c | 33 ++++++
drivers/gpu/drm/rcar-du/Kconfig | 1 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 36 ++++++
drivers/gpu/drm/rcar-du/rcar_du_rgbcon.c | 105 ++++++++++++++++++
drivers/gpu/drm/rcar-du/rcar_du_rgbcon.h | 22 ++++
drivers/of/base.c | 22 ++++
include/linux/of.h | 13 +++
include/uapi/drm/drm_mode.h | 2 +
14 files changed, 314 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm043080dh6gp.txt
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_rgbcon.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_rgbcon.h

--
2.17.1


[PATCH 4.4.y-cip 8/9] ARM: shmobile: defconfig: Enable support for panels from EDT

Biju Das <biju.das.jz@...>
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit a630a6121bef3e9598482a49eda6b1fa715385d6 upstream.

The iwg20d comes with an LCD panel from Emerging Display
Technologies Corporation (EDT), therefore enable what's
required to support it.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/1573660292-10629-12-git-send-email-fabrizio.castro@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
[Removed DRM_LVDS_CODEC configuration]
---
arch/arm/configs/shmobile_defconfig | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index f21de1bec37c..151fad5c0b8d 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -98,6 +98,7 @@ CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_GPIO=y
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_EDT_FT5X06=y
CONFIG_TOUCHSCREEN_ST1232=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_ADXL34X=y
@@ -155,6 +156,7 @@ CONFIG_DRM_I2C_ADV7511=y
CONFIG_DRM_RCAR_DU=y
CONFIG_DRM_RCAR_HDMI=y
CONFIG_DRM_RCAR_LVDS=y
+CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_FB_SH_MOBILE_LCDC=y
CONFIG_FB_SH_MOBILE_MERAM=y
# CONFIG_LCD_CLASS_DEVICE is not set
--
2.17.1


Re: [isar-cip-core 1/3] cip-security: Add packages for IEC-62443-4-2 evaluation

Jan Kiszka
 

On 27.07.20 13:41, venkata.pyla@toshiba-tsip.com wrote:
From: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation
Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Signed-off-by: Venkata Pyla <venkata.pyla@toshiba-tsip.com>
---
.../images/cip-core-image-security.bb | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb
diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb
new file mode 100644
index 0000000..a17c522
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,36 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"
Still no CI for this. You can send that separately on top, the series looks fine otherwise.

Jan

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


CIP embedded platform Internet connection?

Mohammed Billoo <mab@...>
 

Hi,

This question stems from the thread titled "The security of NTP". If we do go with NTS, it looks like we're going to need an Internet connection to the embedded platform. Is that acceptable? The work that I've seen so far related to CIP SWUpdate has assumed that the Hawkbit server is on the local network. It isn't obvious if that has been an intentional decision (due to security requirements) or just to ease development.

--
Mohammed A Billoo
Founder
MAB Labs, LLC
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: The security of NTP

Mohammed Billoo <mab@...>
 

Cool. I'll check out NTS and I'll just respond in this group with silly questions as I stumble along (I'm new to CIP and am not a security expert at all).

On Mon, Jul 27, 2020 at 9:40 AM Daniel Sangorrin <daniel.sangorrin@...> wrote:
Hi Mohammed

> -----Original Message-----
> From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
> Sent: Monday, July 27, 2020 9:55 PM
> To: cip-dev@...
> Subject: Re: [cip-dev] The security of NTP
>
> Daniel,
>
> Thanks for pointing that out. Since CIP is reliant on available packages on particular versions of Debian, would the process/workflow then
> be to wait for tlsdate to be available in Buster and then pull it into CIP and continue working on this issue? Or, should I just go ahead and try
> to get tlsdate incorporated into Buster by following the contribution guidelines in Debian?

That would be something that needs to be decided by the whole CIP project, but I read that tlsdate depends on a timestamp that has been removed on TLS 1.3.
https://www.feistyduck.com/bulletproof-tls-newsletter/issue_54_network_time_security_nts_could_finally_bring_support_for_authenticated_network_time

Personally, I think that CIP should focus on NTS (already included in chrony for example)
https://www.iana.org/assignments/nts/nts.xhtml

Thanks,
Daniel

> On Mon, Jul 27, 2020 at 8:41 AM Daniel Sangorrin <daniel.sangorrin@... <mailto:daniel.sangorrin@...> > wrote:
>
>
>
>       > -----Original Message-----
>       > From: cip-dev@... <mailto:cip-dev@...>  <cip-dev@... <mailto:cip-
> dev@...> > On Behalf Of Mohammed Billoo
>       > Sent: Monday, July 27, 2020 8:32 PM
>       > Daniel, Pavel:
>       >
>       > Thanks for the feedback. Is tlsdate a better alternative (https://github.com/ioerror/tlsdate/)? The only caveat if using tlsdate (or
> any sort of
>       > time mechanism that relies on a "well-known" server) is that an Internet connection is necessary. It isn't obvious to me whether
> this is
>       > acceptable or not. Can someone chime in?
>
>       It seems that that project is dead, but there is a fork for ChromiumOS remaining that seems to be well maintained (for
> ChromiumOS)
>       https://github.com/ioerror/tlsdate/issues/199
>       https://chromium.googlesource.com/chromiumos/third_party/tlsdate
>
>       There are some packages in Debian
>       https://packages.debian.org/search?keywords=tlsdate
>       but not for Buster.
>
>       Thanks,
>       Daniel
>
>
>
>       >
>       > Thanks
>       > --
>       > Mohammed Billoo
>       > MAB Labs, LLC
>       > www.mab-labs.com <http://www.mab-labs.com>
>
>
>
>
>
> --
>
> Mohammed A Billoo
> Founder
> MAB Labs, LLC
> www.mab-labs.com <http://www.mab-labs.com>
> 201-338-2022
>
>
> --
> Mohammed Billoo
> MAB Labs, LLC
> www.mab-labs.com



--
Mohammed A Billoo
Founder
MAB Labs, LLC
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: The security of NTP

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Mohammed

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Mohammed Billoo
Sent: Monday, July 27, 2020 9:55 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] The security of NTP

Daniel,

Thanks for pointing that out. Since CIP is reliant on available packages on particular versions of Debian, would the process/workflow then
be to wait for tlsdate to be available in Buster and then pull it into CIP and continue working on this issue? Or, should I just go ahead and try
to get tlsdate incorporated into Buster by following the contribution guidelines in Debian?
That would be something that needs to be decided by the whole CIP project, but I read that tlsdate depends on a timestamp that has been removed on TLS 1.3.
https://www.feistyduck.com/bulletproof-tls-newsletter/issue_54_network_time_security_nts_could_finally_bring_support_for_authenticated_network_time

Personally, I think that CIP should focus on NTS (already included in chrony for example)
https://www.iana.org/assignments/nts/nts.xhtml

Thanks,
Daniel

On Mon, Jul 27, 2020 at 8:41 AM Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp <mailto:daniel.sangorrin@toshiba.co.jp> > wrote:



> -----Original Message-----
> From: cip-dev@lists.cip-project.org <mailto:cip-dev@lists.cip-project.org> <cip-dev@lists.cip-project.org <mailto:cip-
dev@lists.cip-project.org> > On Behalf Of Mohammed Billoo
> Sent: Monday, July 27, 2020 8:32 PM
> Daniel, Pavel:
>
> Thanks for the feedback. Is tlsdate a better alternative (https://github.com/ioerror/tlsdate/)? The only caveat if using tlsdate (or
any sort of
> time mechanism that relies on a "well-known" server) is that an Internet connection is necessary. It isn't obvious to me whether
this is
> acceptable or not. Can someone chime in?

It seems that that project is dead, but there is a fork for ChromiumOS remaining that seems to be well maintained (for
ChromiumOS)
https://github.com/ioerror/tlsdate/issues/199
https://chromium.googlesource.com/chromiumos/third_party/tlsdate

There are some packages in Debian
https://packages.debian.org/search?keywords=tlsdate
but not for Buster.

Thanks,
Daniel



>
> Thanks
> --
> Mohammed Billoo
> MAB Labs, LLC
> www.mab-labs.com <http://www.mab-labs.com>





--

Mohammed A Billoo
Founder
MAB Labs, LLC
www.mab-labs.com <http://www.mab-labs.com>
201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: The security of NTP

Mohammed Billoo <mab@...>
 

Daniel,

Thanks for pointing that out. Since CIP is reliant on available packages on particular versions of Debian, would the process/workflow then be to wait for tlsdate to be available in Buster and then pull it into CIP and continue working on this issue? Or, should I just go ahead and try to get tlsdate incorporated into Buster by following the contribution guidelines in Debian?

Thanks


On Mon, Jul 27, 2020 at 8:41 AM Daniel Sangorrin <daniel.sangorrin@...> wrote:

> -----Original Message-----
> From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
> Sent: Monday, July 27, 2020 8:32 PM
> Daniel, Pavel:
>
> Thanks for the feedback. Is tlsdate a better alternative (https://github.com/ioerror/tlsdate/)? The only caveat if using tlsdate (or any sort of
> time mechanism that relies on a "well-known" server) is that an Internet connection is necessary. It isn't obvious to me whether this is
> acceptable or not. Can someone chime in?

It seems that that project is dead, but there is a fork for ChromiumOS remaining that seems to be well maintained (for ChromiumOS)
https://github.com/ioerror/tlsdate/issues/199
https://chromium.googlesource.com/chromiumos/third_party/tlsdate

There are some packages in Debian
https://packages.debian.org/search?keywords=tlsdate
but not for Buster.

Thanks,
Daniel



>
> Thanks
> --
> Mohammed Billoo
> MAB Labs, LLC
> www.mab-labs.com



--
Mohammed A Billoo
Founder
MAB Labs, LLC
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: The security of NTP

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Mohammed Billoo
Sent: Monday, July 27, 2020 8:32 PM
Daniel, Pavel:

Thanks for the feedback. Is tlsdate a better alternative (https://github.com/ioerror/tlsdate/)? The only caveat if using tlsdate (or any sort of
time mechanism that relies on a "well-known" server) is that an Internet connection is necessary. It isn't obvious to me whether this is
acceptable or not. Can someone chime in?
It seems that that project is dead, but there is a fork for ChromiumOS remaining that seems to be well maintained (for ChromiumOS)
https://github.com/ioerror/tlsdate/issues/199
https://chromium.googlesource.com/chromiumos/third_party/tlsdate

There are some packages in Debian
https://packages.debian.org/search?keywords=tlsdate
but not for Buster.

Thanks,
Daniel




Thanks
--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Test - please ignore #email

Neal Caidin <neal.caidin@...>
 

Test - please ignore.

Thanks,
Neal Caidin
Linux Foundation

(sent from a personal account)


[isar-cip-core 3/3] README: Add steps to build cip-security image

Venkata Pyla
 

From: Venkata Pyla <venkata.pyla@toshiba-tsip.com>

Signed-off-by: Venkata Pyla <venkata.pyla@toshiba-tsip.com>
---
README.md | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/README.md b/README.md
index 59a014b..26fbbef 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,16 @@ card, run
dd if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-buster-bbb.wic.img \
of=/dev/<medium-device> bs=1M status=progress

+## Building Security target images
+Building images for QEMU x86-64bit machine
+
+ ./kas-docker --isar build --target cip-core-image-security kas.yml:board-qemu-amd64.yml
+
+Run the generated securiy images on QEMU (x86-64bit)
+
+ TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64
+
+
## Community Resources

TBD
--
2.20.1

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

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


[isar-cip-core 2/3] start-qemu.sh: Use 'TARGET_IMAGE' to pick respective image file

Venkata Pyla
 

From: Venkata Pyla <venkata.pyla@toshiba-tsip.com>

Use 'TARGET_IMAGE' to pick respective image file when starting qemu
by default 'TARGET_IMAGE' uses "cip-core-image".

to pick different target image set the 'TARGET_IMAGE' variable as below
e.g: $TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64

Signed-off-by: Venkata Pyla <venkata.pyla@toshiba-tsip.com>
---
start-qemu.sh | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/start-qemu.sh b/start-qemu.sh
index 49f0266..5c17d74 100755
--- a/start-qemu.sh
+++ b/start-qemu.sh
@@ -75,7 +75,11 @@ if [ -z "${DISTRO_RELEASE}" ]; then
DISTRO_RELEASE="buster"
fi

-IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/cip-core-image-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}"
+if [ -z "${TARGET_IMAGE}" ]; then
+ TARGET_IMAGE="cip-core-image"
+fi
+
+IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/${TARGET_IMAGE}-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}"
IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img)

if [ -z "${DISPLAY}" ]; then
--
2.20.1

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

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


[isar-cip-core 1/3] cip-security: Add packages for IEC-62443-4-2 evaluation

Venkata Pyla
 

From: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>

Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation

Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Signed-off-by: Venkata Pyla <venkata.pyla@toshiba-tsip.com>
---
.../images/cip-core-image-security.bb | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb

diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb
new file mode 100644
index 0000000..a17c522
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,36 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"
--
2.20.1

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

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


[isar-cip-core 0/3] Security Branch patches

Venkata Pyla
 

From: Venkata Pyla <venkata.pyla@toshiba-tsip.com>

Patch series for Security changes for IEC-62443-4-2 evaluation

Kazuhiro Hayashi (1):
cip-security: Add packages for IEC-62443-4-2 evaluation

Venkata Pyla (2):
start-qemu.sh: Use 'TARGET_IMAGE' to pick respective image file
README: Add steps to build cip-security image

README.md | 10 ++++++
.../images/cip-core-image-security.bb | 36 +++++++++++++++++++
start-qemu.sh | 6 +++-
3 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 recipes-core/images/cip-core-image-security.bb

--
2.20.1

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

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


Re: The security of NTP

Mohammed Billoo <mab@...>
 

Daniel, Pavel:

Thanks for the feedback. Is tlsdate a better alternative (https://github.com/ioerror/tlsdate/)? The only caveat if using tlsdate (or any sort of time mechanism that relies on a "well-known" server) is that an Internet connection is necessary. It isn't obvious to me whether this is acceptable or not. Can someone chime in?

Thanks
--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


FW: Final call to participate in the LTS survey

Chris Paterson
 

FYI

Kind regards, Chris

From: Holger Levsen <holger@layer-acht.org>
Sent: 26 July 2020 13:37

Hi,

after 6 years of existence, we wanted to run a survey to learn more about
how Debian LTS is used and perceived. You are among the most importants
LTS users since you are those that build Debian in the first place and help
maintaining our stable releases on which LTS is build.

Please take a few minutes to participate in the survey:
https://surveys.debian.net/index.php?r=survey/index&sid=856794&lang=e
n

Also, please hurry up, the survey will close at the end of July 27th on Samoa,
which is in roughly 48h from now.


--
cheers,
      Holger

-------------------------------------------------------------------------------
                holger@(debian|reproducible-builds|layer-acht).org
        PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


[cip core] license compliance for CIP core image releases

Daniel Sangorrin <daniel.sangorrin@...>
 

Hello,

During the last CIP Core meeting we discussed about license compliance for CIP core image releases.
In particular, we talked about how to make sure that users can get exactly the same source code version used to build the Debian binary packages included on each image.

We concluded that we should not rely on Debian repositories, but rather create our own apt mirror with snapshots for each release.

However, today I asked myself: when people upload a Docker image to Dockerhub, what do they do to comply with the licenses of all of the packages inside.

I thought that Microsoft would be one of the most cautious and checked their Docker images.

https://hub.docker.com/_/microsoft-dotnet-core (click "Discover licensing for Linux image contents")

If you read their document, it looks like the rely on the Debian source code packages to be always available either in the Debian repo or the Snapshots repository.

[Note] additionally they rely on the license and copyright information provided by Debian to be correct (they do not verify it manually)

I would like to know your opinions about this. Do you think it is worth the effort to build, pay and maintain a repository mirror with snapshots? or can we rely on Debian snapshot repositories (for users to retrieve source code, not for building the image)?

Thanks,
Daniel


Re: [PATCH 1/3] cip-security: Add packages for IEC-62443-4-2 Evaluation.

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Jan,

From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Thursday, July 23, 2020 10:53 PM
Don't worry. The submission looked fairly good otherwise, not like first-time!

BTW, I'm still ambivalent whether to do UI (MRs) or cip-dev based patch reviews for isar-cip-core. As contributions increase, you
contributors need to express your preference. I'm used to both by now, I have troubles with both by now. However, we just need to
consolidate over one system because we can't couple them reasonably.
Patches give you greater visibility (all cip-dev members), but I can see some benefits in using MRs as well:
* merge when the pipeline succeeds
* map issues with the patches that close them
* discussions are kept close to the code
* no need for guru e-mail clients that don't mesh with your TABs Lol.
* they are more user friendly (push the merge request button instead of having to configure git send-email which can be problematic in corporate environments)

I am open to use any of them.

Thanks,
Daniel


The security of NTP

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Pavel,
*I renamed the subject and added cip-security to Cc

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Pavel Machek
Sent: Friday, July 24, 2020 5:58 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Resource describing the Deby workflow?

Hi!

I'm almost done getting SSL working between the BBB and hawkbit. The
last piece of the puzzle is to get NTP working on the BBB (since I
need valid time to ensure that the server certificate is valid).
Unfortunately, I'm
Notice that in this case SSL is not adding as much security as you think it does.

SSL attempts to protect against active attackers, and those can manipulate NTP easily.
In the past, I read a bit about this topic because NTP seemed to be weak against man-in-the-middle attacks and that could cause problems when updating software:
- the device may not be able to judge correctly whether a certificate is expired or not
- the device may reject updates because it thinks they are older than the current update (when using timestamps)

Both cases would cause the device not being updated (a freeze attack).

[Note] civil infrastructure devices may also use GPS Satellites for time synchronization, or contract private leased lines and set up their own NTP server there. Not perfect but probably there are easier ways to compromise your device.

After some reading, I found out that NTP includes authentication support nowadays (symmetric keys, autokey..) but apparently nobody uses them.
https://tools.ietf.org/html/rfc5906
https://chrony.tuxfamily.org/comparison.html (check NTP authentication)

It seems there is a new standard called Network Time Security (NTS) now.
https://www.rfc-editor.org/rfc/rfc8633.html
https://weberblog.net/network-time-security-strengths-weaknesses/
https://www.infoq.com/news/2019/11/cloudflare-open-source-nts/

Also, during my investigation on software update technology I also found out that TUF (the update framework) and its child UPTANE had a separate Time server to limit the freeze attacks.

There was a nice presentation by Justin Cappos in Japan last year:
https://events19.linuxfoundation.org/wp-content/uploads/2018/07/Uptane-2019-Summer-AGL-event.pdf

Thanks,
Daniel




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


[ANNOUNCE] Release v4.19.134-cip31

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.134-cip31.
The linux-4.19.y-cip tree has been updated base version from v4.19.132
to v4.19.134,
In addition, the rcar-du and display features have been backported for
the RZ/G2.

You can get this release via the git tree at:

v4.19.134-cip31:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
ed5f9765186cc342cfc250e6b101cea95a921666
added commits:
CIP: Bump version suffix to -cip31 after merge from stable
arm64: dts: renesas: Add EK874 board with idk-2121wr display support
dt-bindings: display: Add idk-2121wr binding
arm64: dts: renesas: rzg2: Add reset control properties for display
arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1
drm: rcar-du: lvds: Allow for even and odd pixels swap
drm: rcar-du: lvds: Get dual link configuration from DT
drm: of: Add drm_of_lvds_get_dual_link_pixel_order
drm: rcar-du: lvds: Improve identification of panels
drm: rcar-du: lvds: Get mode from state
drm: Add atomic variants for bridge enable/disable
drm: Add drm_atomic_get_(old|new)_connector_for_encoder() helpers
drm: rcar_lvds: Fix dual link mode operations
drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode
drm: rcar-du: lvds: Add support for dual-link mode
dt-bindings: display: renesas: lvds: Add renesas,companion property
drm: bridge: Add dual_link field to the drm_bridge_timings structure
drm: rcar-du: lvds: Remove LVDS double-enable checks
arm64: defconfig: Enable additional support for Renesas platforms
ASoC: rsnd: fixup SSI clock during suspend/resume modes

Best regards,
Nobuhiro

2481 - 2500 of 7513