|
[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>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 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 -- --
Mohammed Billoo MAB Labs, LLC www.mab-labs.com
|
|
|
|
Re: The security of NTP
Daniel Sangorrin <daniel.sangorrin@...>
Hi Mohammed
toggle quoted messageShow quoted text
-----Original Message-----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:
|
|
|
|
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:
-- --
Mohammed Billoo MAB Labs, LLC www.mab-labs.com
|
|
|
|
Re: The security of NTP
Daniel Sangorrin <daniel.sangorrin@...>
toggle quoted messageShow quoted text
-----Original Message-----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
|
|
|
|
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
toggle quoted messageShow quoted text
Kind regards, Chris
From: Holger Levsen <holger@layer-acht.org>
|
|
|
|
[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 KiszkaPatches 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,
toggle quoted messageShow quoted text
*I renamed the subject and added cip-security to Cc
-----Original Message-----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
|
|
|
|
[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
|
|
|
|
[ANNOUNCE] v4.4.231-cip47-rt30
Pavel Machek
Hi!
v4.4.231-cip47-rt30 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.4.y-cip-rt https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-cip-rt-rebase And their content should be identical. There is known issue in upsream -rt: sigwaittest with hackbench as workload is able to trigger a crash on x86_64, the same as reported for the v4.4.220-rt196 release. As it turns out it was not triggered by BPF. https://paste.opensuse.org/view/raw/58939248 Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
|
|
|