|
[PATCH 4.4.y-cip 3/9] dt-bindings: display: Add bindings for EDT panel
Biju Das <biju.das.jz@...>
Document the Emerging Display Technology Corp. (EDT) ETM043080DH6-GP
display, which is a 480x272 4.3" TFT display with capacitive touchscreen. This patch is based on the upstream commit c752affbadb05b619 ("dt-bindings: display: Add bindings for EDT panel"). Signed-off-by: Biju Das <biju.das.jz@...> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...> --- .../bindings/display/panel/edt,etm043080dh6gp.txt | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm043080dh6gp.txt diff --git a/Documentation/devicetree/bindings/display/panel/edt,etm043080dh6gp.txt b/Documentation/devicetree/bindings/display/panel/edt,etm043080dh6gp.txt new file mode 100644 index 000000000000..c837e0bfb1a9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/edt,etm043080dh6gp.txt @@ -0,0 +1,9 @@ +Emerging Display Technology Corp. ETM043080DH6-GP 4.3" WQVGA TFT LCD panel + +Required properties: +- compatible: should be "edt,etm043080dh6gp" + +ETM043080DH6-GP is 480x272 TFT Display with capacitive touchscreen. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.17.1
|
|
|
|
[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@...>
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@...> Reviewed-by: Daniel Vetter <daniel.vetter@...> Signed-off-by: Biju Das <biju.das.jz@...> --- 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@...>
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@...> Acked-by: Laurent Pinchart <laurent.pinchart@...> Link: https://lore.kernel.org/r/1573660292-10629-12-git-send-email-fabrizio.castro@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@...> Signed-off-by: Biju Das <biju.das.jz@...> [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@... wrote:
From: Kazuhiro Hayashi <kazuhiro3.hayashi@...>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@... <mailto:daniel.sangorrin@...> > 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@...>
Signed-off-by: Venkata Pyla <venkata.pyla@...> --- 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@...>
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@...> --- 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@...>
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@...> Signed-off-by: Venkata Pyla <venkata.pyla@...> --- .../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@...> +# +# 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@...>
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@...>
|
|
|
|
[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@... <cip-dev@...> 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
|
|
|