Date   

[isar-cip-core] qemu-amd64: use cip-kernel-config file

Daniel Sangorrin
 

We should use configs from the cip-kernel-config
repository, which are shared between CIP Core
reference implementations and CIP testing.

I updated the cip-kernel-config commit id because QEMU's
config file was inexistent.

I have built and boot-tested the QEMU target but not
the other ones. Hopefully our CI will detect any
regressions.

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
conf/machine/qemu-amd64.conf | 2 +
.../linux/files/qemu-amd64_defconfig | 353 ------------------
recipes-kernel/linux/linux-cip-common.inc | 2 +-
3 files changed, 3 insertions(+), 354 deletions(-)
delete mode 100644 recipes-kernel/linux/files/qemu-amd64_defconfig

diff --git a/conf/machine/qemu-amd64.conf b/conf/machine/qemu-amd64.conf
index 7cbd55b..c90d957 100644
--- a/conf/machine/qemu-amd64.conf
+++ b/conf/machine/qemu-amd64.conf
@@ -9,3 +9,5 @@
DISTRO_ARCH = "amd64"

IMAGE_TYPE ?= "ext4-img"
+USE_CIP_KERNEL_CONFIG = "1"
+KERNEL_DEFCONFIG = "cip-kernel-config/4.19.y-cip/x86/cip_qemu_defconfig"
diff --git a/recipes-kernel/linux/files/qemu-amd64_defconfig b/recipes-kernel/linux/files/qemu-amd64_defconfig
deleted file mode 100644
index 7487152..0000000
--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ /dev/null
@@ -1,353 +0,0 @@
-# CONFIG_LOCALVERSION_AUTO is not set
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_FHANDLE=y
-CONFIG_NO_HZ_IDLE=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_BSD_PROCESS_ACCT=y
-CONFIG_BSD_PROCESS_ACCT_V3=y
-CONFIG_TASKSTATS=y
-CONFIG_TASK_DELAY_ACCT=y
-CONFIG_TASK_XACCT=y
-CONFIG_TASK_IO_ACCOUNTING=y
-CONFIG_IKCONFIG=m
-CONFIG_NUMA_BALANCING=y
-# CONFIG_NUMA_BALANCING_DEFAULT_ENABLED is not set
-CONFIG_CGROUP_FREEZER=y
-CONFIG_CGROUP_PIDS=y
-CONFIG_CGROUP_DEVICE=y
-CONFIG_CPUSETS=y
-CONFIG_CGROUP_CPUACCT=y
-CONFIG_MEMCG=y
-CONFIG_MEMCG_SWAP=y
-# CONFIG_MEMCG_SWAP_ENABLED is not set
-CONFIG_CGROUP_PERF=y
-CONFIG_CFS_BANDWIDTH=y
-CONFIG_BLK_CGROUP=y
-CONFIG_CHECKPOINT_RESTORE=y
-CONFIG_NAMESPACES=y
-CONFIG_USER_NS=y
-CONFIG_SCHED_AUTOGROUP=y
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_EXPERT=y
-CONFIG_KALLSYMS_ALL=y
-CONFIG_BPF_SYSCALL=y
-CONFIG_USERFAULTFD=y
-# CONFIG_COMPAT_BRK is not set
-CONFIG_SLAB=y
-CONFIG_PROFILING=y
-CONFIG_KPROBES=y
-CONFIG_JUMP_LABEL=y
-CONFIG_CC_STACKPROTECTOR_STRONG=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODVERSIONS=y
-CONFIG_BLK_DEV_BSGLIB=y
-CONFIG_BLK_DEV_INTEGRITY=y
-CONFIG_BLK_DEV_THROTTLING=y
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_CFQ_GROUP_IOSCHED=y
-CONFIG_SMP=y
-CONFIG_X86_X2APIC=y
-# CONFIG_X86_EXTENDED_PLATFORM is not set
-CONFIG_X86_INTEL_LPSS=y
-CONFIG_X86_AMD_PLATFORM_DEVICE=y
-CONFIG_IOSF_MBI=y
-CONFIG_HYPERVISOR_GUEST=y
-CONFIG_PARAVIRT=y
-CONFIG_PARAVIRT_SPINLOCKS=y
-CONFIG_GART_IOMMU=y
-CONFIG_CALGARY_IOMMU=y
-CONFIG_NR_CPUS=512
-CONFIG_SCHED_SMT=y
-CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
-CONFIG_MICROCODE_AMD=y
-CONFIG_NUMA=y
-CONFIG_NUMA_EMU=y
-CONFIG_MEMORY_HOTPLUG=y
-CONFIG_MEMORY_HOTREMOVE=y
-CONFIG_KSM=y
-CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
-CONFIG_MEMORY_FAILURE=y
-CONFIG_TRANSPARENT_HUGEPAGE=y
-CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
-CONFIG_FRONTSWAP=y
-CONFIG_MEM_SOFT_DIRTY=y
-CONFIG_ZSWAP=y
-CONFIG_ZBUD=y
-CONFIG_X86_INTEL_MPX=y
-CONFIG_EFI=y
-CONFIG_EFI_STUB=y
-CONFIG_EFI_MIXED=y
-CONFIG_KEXEC=y
-CONFIG_KEXEC_FILE=y
-CONFIG_KEXEC_VERIFY_SIG=y
-CONFIG_CRASH_DUMP=y
-CONFIG_RANDOMIZE_BASE=y
-CONFIG_LIVEPATCH=y
-CONFIG_HIBERNATION=y
-CONFIG_PM_DEBUG=y
-CONFIG_PM_ADVANCED_DEBUG=y
-# CONFIG_ACPI_AC is not set
-# CONFIG_ACPI_BATTERY is not set
-CONFIG_ACPI_BUTTON=m
-# CONFIG_ACPI_FAN is not set
-CONFIG_ACPI_DOCK=y
-# CONFIG_ACPI_THERMAL is not set
-CONFIG_ACPI_PCI_SLOT=y
-CONFIG_ACPI_HOTPLUG_MEMORY=y
-CONFIG_ACPI_BGRT=y
-CONFIG_ACPI_APEI=y
-CONFIG_ACPI_APEI_GHES=y
-CONFIG_ACPI_APEI_PCIEAER=y
-CONFIG_ACPI_APEI_MEMORY_FAILURE=y
-CONFIG_ACPI_EXTLOG=y
-CONFIG_SFI=y
-CONFIG_CPU_FREQ=y
-CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
-CONFIG_X86_INTEL_PSTATE=y
-CONFIG_INTEL_IDLE=y
-CONFIG_PCI_MMCONFIG=y
-CONFIG_PCIEPORTBUS=y
-CONFIG_HOTPLUG_PCI_PCIE=y
-CONFIG_PCI_REALLOC_ENABLE_AUTO=y
-CONFIG_PCI_IOV=y
-CONFIG_HOTPLUG_PCI=y
-CONFIG_HOTPLUG_PCI_ACPI=y
-CONFIG_HOTPLUG_PCI_CPCI=y
-CONFIG_IA32_EMULATION=y
-CONFIG_IA32_AOUT=y
-CONFIG_X86_X32=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_XFRM_SUB_POLICY=y
-CONFIG_XFRM_MIGRATE=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_IP_ADVANCED_ROUTER=y
-CONFIG_IP_FIB_TRIE_STATS=y
-CONFIG_IP_MULTIPLE_TABLES=y
-CONFIG_IP_ROUTE_MULTIPATH=y
-CONFIG_IP_ROUTE_VERBOSE=y
-CONFIG_IP_MROUTE=y
-CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
-CONFIG_IP_PIMSM_V1=y
-CONFIG_IP_PIMSM_V2=y
-CONFIG_SYN_COOKIES=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_DIAG is not set
-CONFIG_TCP_CONG_ADVANCED=y
-# CONFIG_TCP_CONG_BIC is not set
-# CONFIG_TCP_CONG_WESTWOOD is not set
-# CONFIG_TCP_CONG_HTCP is not set
-CONFIG_TCP_MD5SIG=y
-CONFIG_IPV6_ROUTER_PREF=y
-CONFIG_IPV6_ROUTE_INFO=y
-CONFIG_IPV6_OPTIMISTIC_DAD=y
-CONFIG_IPV6_MIP6=y
-# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET6_XFRM_MODE_BEET is not set
-# CONFIG_IPV6_SIT is not set
-CONFIG_IPV6_MULTIPLE_TABLES=y
-CONFIG_IPV6_SUBTREES=y
-CONFIG_IPV6_MROUTE=y
-CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
-CONFIG_IPV6_PIMSM_V2=y
-CONFIG_NETFILTER=y
-CONFIG_IP_NF_IPTABLES=m
-CONFIG_NET_SCHED=y
-CONFIG_NET_EMATCH=y
-CONFIG_NET_CLS_ACT=y
-CONFIG_DCB=y
-CONFIG_MPLS=y
-CONFIG_NET_MPLS_GSO=y
-CONFIG_NET_L3_MASTER_DEV=y
-CONFIG_CGROUP_NET_PRIO=y
-CONFIG_CGROUP_NET_CLASSID=y
-CONFIG_BPF_JIT=y
-CONFIG_LWTUNNEL=y
-# CONFIG_UEVENT_HELPER is not set
-CONFIG_DEVTMPFS=y
-# CONFIG_FIRMWARE_IN_KERNEL is not set
-CONFIG_CONNECTOR=y
-# CONFIG_PNP_DEBUG_MESSAGES is not set
-CONFIG_VIRTIO_BLK=y
-# CONFIG_SCSI_PROC_FS is not set
-CONFIG_BLK_DEV_SD=m
-CONFIG_CHR_DEV_SG=m
-CONFIG_SCSI_CONSTANTS=y
-CONFIG_SCSI_LOGGING=y
-CONFIG_SCSI_SCAN_ASYNC=y
-CONFIG_MEGARAID_NEWGEN=y
-CONFIG_SCSI_DH=y
-CONFIG_ATA=y
-# CONFIG_SATA_PMP is not set
-CONFIG_SATA_AHCI=y
-# CONFIG_ATA_SFF is not set
-CONFIG_MD=y
-CONFIG_NETDEVICES=y
-CONFIG_NET_FC=y
-CONFIG_VIRTIO_NET=y
-# CONFIG_NET_VENDOR_ARC is not set
-CONFIG_NET_TULIP=y
-# CONFIG_NET_VENDOR_SEEQ is not set
-CONFIG_INPUT_EVDEV=m
-CONFIG_MOUSE_PS2=m
-CONFIG_MOUSE_PS2_ELANTECH=y
-CONFIG_MOUSE_PS2_SENTELIC=y
-CONFIG_MOUSE_PS2_VMMOUSE=y
-CONFIG_INPUT_JOYSTICK=y
-CONFIG_INPUT_TABLET=y
-CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_PCSPKR=m
-# CONFIG_SERIO_SERPORT is not set
-CONFIG_SERIO_RAW=m
-CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
-# CONFIG_LEGACY_PTYS is not set
-CONFIG_SERIAL_NONSTANDARD=y
-# CONFIG_DEVKMEM is not set
-CONFIG_SERIAL_8250=y
-# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=32
-CONFIG_SERIAL_8250_EXTENDED=y
-CONFIG_SERIAL_8250_MANY_PORTS=y
-CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_8250_RSA=y
-# CONFIG_HW_RANDOM is not set
-CONFIG_HPET=y
-CONFIG_I2C=y
-CONFIG_I2C_I801=m
-CONFIG_SPI=y
-CONFIG_PINCTRL_BAYTRAIL=y
-CONFIG_PINCTRL_CHERRYVIEW=y
-CONFIG_PINCTRL_BROXTON=y
-CONFIG_PINCTRL_SUNRISEPOINT=y
-CONFIG_GPIO_SYSFS=y
-CONFIG_GPIO_INTEL_MID=y
-CONFIG_POWER_SUPPLY=y
-CONFIG_THERMAL_WRITABLE_TRIPS=y
-CONFIG_THERMAL_GOV_FAIR_SHARE=y
-CONFIG_THERMAL_GOV_BANG_BANG=y
-CONFIG_THERMAL_GOV_USER_SPACE=y
-# CONFIG_X86_PKG_TEMP_THERMAL is not set
-CONFIG_WATCHDOG=y
-CONFIG_ITCO_WDT=m
-CONFIG_ITCO_VENDOR_SUPPORT=y
-CONFIG_LPC_ICH=m
-CONFIG_AGP=y
-CONFIG_AGP_AMD64=y
-CONFIG_AGP_INTEL=y
-CONFIG_AGP_SIS=y
-CONFIG_AGP_VIA=y
-CONFIG_VGA_SWITCHEROO=y
-CONFIG_FB=y
-CONFIG_FIRMWARE_EDID=y
-CONFIG_FB_MODE_HELPERS=y
-CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_VESA=y
-CONFIG_FB_EFI=y
-CONFIG_BACKLIGHT_LCD_SUPPORT=y
-# CONFIG_LCD_CLASS_DEVICE is not set
-CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
-CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
-# CONFIG_HID is not set
-CONFIG_NEW_LEDS=y
-CONFIG_LEDS_CLASS=y
-CONFIG_LEDS_TRIGGERS=y
-CONFIG_LEDS_TRIGGER_CPU=y
-CONFIG_ACCESSIBILITY=y
-CONFIG_A11Y_BRAILLE_CONSOLE=y
-CONFIG_EDAC=y
-# CONFIG_EDAC_DECODE_MCE is not set
-CONFIG_RTC_CLASS=y
-CONFIG_DMADEVICES=y
-CONFIG_VIRT_DRIVERS=y
-CONFIG_VIRTIO_PCI=y
-CONFIG_AMD_IOMMU=y
-CONFIG_AMD_IOMMU_V2=y
-CONFIG_INTEL_IOMMU=y
-CONFIG_INTEL_IOMMU_SVM=y
-# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
-CONFIG_IRQ_REMAP=y
-CONFIG_PM_DEVFREQ=y
-CONFIG_MEMORY=y
-CONFIG_GENERIC_PHY=y
-CONFIG_POWERCAP=y
-CONFIG_DMI_SYSFS=y
-CONFIG_ISCSI_IBFT_FIND=y
-CONFIG_EXT4_FS=m
-CONFIG_EXT4_FS_POSIX_ACL=y
-CONFIG_EXT4_FS_SECURITY=y
-CONFIG_FS_DAX=y
-CONFIG_FANOTIFY=y
-CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
-CONFIG_QUOTA=y
-CONFIG_QUOTA_NETLINK_INTERFACE=y
-CONFIG_AUTOFS4_FS=m
-CONFIG_PROC_KCORE=y
-CONFIG_TMPFS=y
-CONFIG_TMPFS_POSIX_ACL=y
-CONFIG_HUGETLBFS=y
-# CONFIG_EFIVAR_FS is not set
-CONFIG_NLS_DEFAULT="utf8"
-CONFIG_PRINTK_TIME=y
-CONFIG_BOOT_PRINTK_DELAY=y
-CONFIG_DYNAMIC_DEBUG=y
-CONFIG_STRIP_ASM_SYMS=y
-# CONFIG_UNUSED_SYMBOLS is not set
-# CONFIG_FRAME_POINTER is not set
-CONFIG_MAGIC_SYSRQ=y
-CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6
-CONFIG_PAGE_POISONING=y
-CONFIG_DEBUG_MEMORY_INIT=y
-CONFIG_LOCKUP_DETECTOR=y
-CONFIG_SCHEDSTATS=y
-CONFIG_SCHED_STACK_END_CHECK=y
-CONFIG_FTRACE_SYSCALLS=y
-CONFIG_TRACER_SNAPSHOT=y
-CONFIG_STACK_TRACER=y
-CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
-CONFIG_MMIOTRACE=y
-CONFIG_MEMTEST=y
-CONFIG_STRICT_DEVMEM=y
-# CONFIG_X86_VERBOSE_BOOTUP is not set
-CONFIG_EARLY_PRINTK_EFI=y
-# CONFIG_DEBUG_RODATA_TEST is not set
-CONFIG_DEBUG_SET_MODULE_RONX=y
-CONFIG_OPTIMIZE_INLINING=y
-CONFIG_KEYS=y
-CONFIG_SECURITY_DMESG_RESTRICT=y
-CONFIG_SECURITY=y
-CONFIG_SECURITY_NETWORK_XFRM=y
-CONFIG_SECURITY_SELINUX=y
-CONFIG_SECURITY_TOMOYO=y
-CONFIG_SECURITY_APPARMOR=y
-CONFIG_SECURITY_YAMA=y
-CONFIG_IMA=y
-CONFIG_IMA_DEFAULT_HASH_SHA256=y
-CONFIG_IMA_APPRAISE=y
-CONFIG_DEFAULT_SECURITY_DAC=y
-# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
-# CONFIG_CRYPTO_ECHAINIV is not set
-CONFIG_CRYPTO_CRC32C=y
-CONFIG_CRYPTO_CRC32C_INTEL=y
-CONFIG_CRYPTO_SHA256=y
-CONFIG_CRYPTO_DEV_CCP=y
-# CONFIG_CRYPTO_DEV_CCP_DD is not set
-# CONFIG_VIRTUALIZATION is not set
-# CONFIG_XZ_DEC_POWERPC is not set
-# CONFIG_XZ_DEC_IA64 is not set
-# CONFIG_XZ_DEC_ARM is not set
-# CONFIG_XZ_DEC_ARMTHUMB is not set
-# CONFIG_XZ_DEC_SPARC is not set
diff --git a/recipes-kernel/linux/linux-cip-common.inc b/recipes-kernel/linux/linux-cip-common.inc
index 8bd0f99..d45a3b0 100644
--- a/recipes-kernel/linux/linux-cip-common.inc
+++ b/recipes-kernel/linux/linux-cip-common.inc
@@ -26,4 +26,4 @@ SRC_URI += " \
SRC_URI_append = " ${@conditional("USE_CIP_KERNEL_CONFIG", "1", \
"git://gitlab.com/cip-project/cip-kernel/cip-kernel-config.git;protocol=https;destsuffix=cip-kernel-config;name=cip-kernel-config", \
"file://${KERNEL_DEFCONFIG}",d)}"
-SRCREV_cip-kernel-config ?= "f88ee1e75253104f975263cf4d0bddd557388197"
+SRCREV_cip-kernel-config ?= "db2085219b5f28ed7c3e0fbdf93b7867947958a8"
--
2.25.1


Re: CIP embedded platform Internet connection?

Akihiro Suzuki
 

Hi Mohammed,

 

> I realized that the configuration of the embedded platform and Hawkbit server may be specific for the SWUpdate demo. Suzuki-san, is that correct?

Yes. It is specific for the SWUpdate demo.

 

> is it OK if these parameters are in files or would you want them in a less permanent form (e.g. environment variables)?

If possible, I prefer the latter.

Current cip-sw-updates-demo repository has many inconvenient points.

If you have time, could you fix them?

 

Thanks,

Suzuki

 

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Thursday, July 30, 2020 9:32 AM
To: cip-dev@...
Subject: Re: [cip-dev] CIP embedded platform Internet connection?

 

Daniel,

 

Thanks for getting back. I realized that the configuration of the embedded platform and Hawkbit server may be specific for the SWUpdate demo. Suzuki-san, is that correct? If so, is it OK if these parameters are in files or would you want them in a less permanent form (e.g. environment variables)? The advantage of the latter would be that if I need to change the network configuration for my own set up (since my localhost external IP is different from what's in the BBB customization), I don't have to manage two different network configurations. I can set the appropriate environment variable (for example) and the build, if set up correctly, would pick up the environment variables and configure the BBB image correctly. Is there any strong conviction for either way?

 

Thanks 

Mohammed A Billoo
Founder
MAB Labs, LLC
www.mab-labs.com
201-338-2022

 

On Wed, Jul 29, 2020, 7:52 PM Daniel Sangorrin <daniel.sangorrin@...> wrote:

Hi Mohammed,

> -----Original Message-----
> From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
> 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.

There is nothing in CIP SWUpdate that assumes the Hawkbit server is on a local network.
Perhaps the README is using a local serve for demonstration purposes?

Thanks,
Daniel


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


Re: [PATCH 3/3] README: Add steps to build cip-security image

Jan Kiszka
 

On 30.07.20 02:07, daniel.sangorrin@toshiba.co.jp wrote:
Hi Venkata-san
Maybe Jan didn't see your e-mail because he wasn't in the CC.

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Venkata Pyla
Sent: Friday, July 24, 2020 3:58 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [PATCH 3/3] README: Add steps to build cip-security image

Hi Jan,

On Thu, Jul 23, 2020 at 04:10 PM, Jan Kiszka wrote:


On 21.07.20 10:16, Venkata Pyla wrote:
From: venkata <venkata.pyla@toshiba-tsip.com>

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

diff --git a/README.md b/README.md
index bbad1a0..b2c4166 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
This patch is fine, but I'm missing 4/4: Add this image to CI (same
comment as I had on the MR on gitlab).
Adding cip security image to CI,
i need some suggestions to use the current format present in .gitlab-ci.yml

Currently i have the below problem for using script deploy-cip-core.sh:
1. image name formation in the script should have another variable
.../$IMG_PREFIX-cip-core-$RELEASE-$TARGET
where $IMG_PREFIX is default to "cip-core-image" if not specified
for security image it will be passed as 4th argument "cip-core-image-security"
2. currently scrit is expecting the image format in *.wic.img so,
for qemu i think we should have wks file to generate image with format .wic.img

or for this security image do we need to deploy it seperatley?
please guide me
Sometimes it is better to send a patch instead of trying to explain it with words.
I've replied on the deployment question already.

If there is a need for the security artifacts already, we need to enhance the deployment for that particular use case - but I doubt there is at this point, otherwise the series had carried CI in the first place.

Jan

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


Re: [isar-cip-core PATCH v3 1/6] kernel: add fat for qemu-amd64

Jan Kiszka
 

On 30.07.20 03:56, daniel.sangorrin@toshiba.co.jp wrote:
-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Thursday, July 30, 2020 1:47 AM
To: cip-dev@lists.cip-project.org; Quirin Gylstorff <quirin.gylstorff@siemens.com>
Subject: Re: [cip-dev] [isar-cip-core PATCH v3 1/6] kernel: add fat for qemu-amd64

On 24.07.20 17:01, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

Add a fat configuration to access FAT Partitions on the qemu-amd64
target.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
recipes-kernel/linux/files/qemu-amd64_defconfig | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/recipes-kernel/linux/files/qemu-amd64_defconfig
b/recipes-kernel/linux/files/qemu-amd64_defconfig
index 7487152..5449317 100644
--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,9 @@ CONFIG_CRYPTO_DEV_CCP=y
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
Taking that for now, but we should quickly move that defconfig into cip-kernel-config. I'm not sure if there is anything for qemu already.
Could you check an propose our defconfig for it?
I confirmed that cip-kernel-config's qemu config boots correctly with isar-cip-core's start_qemu.sh.
Shall i prepare a patch that removes the local one and picks up the one from cip-kernel-config.
That would be good.

If needed, Quirin, please patch cip-kernel-config directly for these extra switches.

Jan

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


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=7&day=30&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://lore.kernel.org/cip-dev/OSAPR01MB23857705B82D0D163B5E5211B7770@OSAPR01MB2385.jpnprd01.prod.outlook.com/T/#m873e67bf005078f86fe9f659682614def4a448a6

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Email Kernel team/cip-dev about patchwork usage - patersonc
Old AI "Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu" was taken care by SZ-san and was closed last week.

* 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: [isar-cip-core PATCH v3 1/6] kernel: add fat for qemu-amd64

Daniel Sangorrin
 

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Thursday, July 30, 2020 1:47 AM
To: cip-dev@lists.cip-project.org; Quirin Gylstorff <quirin.gylstorff@siemens.com>
Subject: Re: [cip-dev] [isar-cip-core PATCH v3 1/6] kernel: add fat for qemu-amd64

On 24.07.20 17:01, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

Add a fat configuration to access FAT Partitions on the qemu-amd64
target.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
recipes-kernel/linux/files/qemu-amd64_defconfig | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/recipes-kernel/linux/files/qemu-amd64_defconfig
b/recipes-kernel/linux/files/qemu-amd64_defconfig
index 7487152..5449317 100644
--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,9 @@ CONFIG_CRYPTO_DEV_CCP=y
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
Taking that for now, but we should quickly move that defconfig into cip-kernel-config. I'm not sure if there is anything for qemu already.
Could you check an propose our defconfig for it?
I confirmed that cip-kernel-config's qemu config boots correctly with isar-cip-core's start_qemu.sh.
Shall i prepare a patch that removes the local one and picks up the one from cip-kernel-config.

Thanks,
Daniel


Re: [PATCH 4.4.y-cip] ARM: dts: iwg22d-sodimm: Enable touchscreen

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Biju Das [mailto:biju.das.jz@bp.renesas.com]
Sent: Wednesday, July 29, 2020 7:56 PM
To: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>
Cc: Chris Paterson <chris.paterson2@renesas.com>; Biju Das <biju.das.jz@bp.renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: [PATCH 4.4.y-cip] ARM: dts: iwg22d-sodimm: Enable touchscreen

From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>

commit 99ae78f1fc3a73c88fe726c676ae963ce722bf20 upstream.

In one of the iWave-G22D development board variants, called Generic SODIMM
Development Platform, we have an LCD with touchscreen. The resistive touch
controller, STMPE811 is on the development board and is connected through
the i2c5 of the RZ-G1E.

Additionally, this controller should generate an interrupt to the CPU and
it is connected through GPIO4,4 to the GIC.

Touch was tested with one of our iW-RainboW-G22D-SODIMM RZ/G1E development
platforms.

More details on the iWave website:
https://www.iwavesystems.com/rz-g1e-sodimm-development-kit.html

Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Link: https://lore.kernel.org/r/1583336650-25848-1-git-send-email-marian-cristian.rotariu.rb@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
There seems to be no issue with this patch, but we also need to update defcofnig.
If there is no other objection, I will apply this.

Best regards,
Nobuhiro


---
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 33 +++++++++++++++++++++
1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index 1e331d1e414b..5cd989556b60 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -149,6 +149,39 @@
status = "okay";
clock-frequency = <400000>;

+ stmpe811@44 {
+ compatible = "st,stmpe811";
+ reg = <0x44>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+
+ stmpe_touchscreen {
+ compatible = "st,stmpe-ts";
+ /* 8 sample average control */
+ st,ave-ctrl = <3>;
+ /* 7 length fractional part in z */
+ st,fraction-z = <7>;
+ /*
+ * 50 mA typical 80 mA max touchscreen drivers
+ * current limit value
+ */
+ st,i-drive = <1>;
+ /* 1 ms panel driver settling time */
+ st,settling = <3>;
+ /* 5 ms touch detect interrupt delay */
+ st,touch-det-delay = <5>;
+ };
+ };
+
sgtl5000: codec@a {
compatible = "fsl,sgtl5000";
#sound-dai-cells = <0>;
--
2.17.1


Re: CIP embedded platform Internet connection?

Mohammed Billoo <mab@...>
 

Daniel,

Thanks for getting back. I realized that the configuration of the embedded platform and Hawkbit server may be specific for the SWUpdate demo. Suzuki-san, is that correct? If so, is it OK if these parameters are in files or would you want them in a less permanent form (e.g. environment variables)? The advantage of the latter would be that if I need to change the network configuration for my own set up (since my localhost external IP is different from what's in the BBB customization), I don't have to manage two different network configurations. I can set the appropriate environment variable (for example) and the build, if set up correctly, would pick up the environment variables and configure the BBB image correctly. Is there any strong conviction for either way?

Thanks 

Mohammed A Billoo
Founder
MAB Labs, LLC
www.mab-labs.com
201-338-2022

On Wed, Jul 29, 2020, 7:52 PM Daniel Sangorrin <daniel.sangorrin@...> wrote:
Hi Mohammed,

> -----Original Message-----
> From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
> 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.

There is nothing in CIP SWUpdate that assumes the Hawkbit server is on a local network.
Perhaps the README is using a local serve for demonstration purposes?

Thanks,
Daniel


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


Re: [PATCH 3/3] README: Add steps to build cip-security image

Daniel Sangorrin
 

Hi Venkata-san

Maybe Jan didn't see your e-mail because he wasn't in the CC.

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Venkata Pyla
Sent: Friday, July 24, 2020 3:58 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [PATCH 3/3] README: Add steps to build cip-security image

Hi Jan,

On Thu, Jul 23, 2020 at 04:10 PM, Jan Kiszka wrote:


On 21.07.20 10:16, Venkata Pyla wrote:
From: venkata <venkata.pyla@toshiba-tsip.com>

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

diff --git a/README.md b/README.md
index bbad1a0..b2c4166 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
This patch is fine, but I'm missing 4/4: Add this image to CI (same
comment as I had on the MR on gitlab).
Adding cip security image to CI,
i need some suggestions to use the current format present in .gitlab-ci.yml

Currently i have the below problem for using script deploy-cip-core.sh:
1. image name formation in the script should have another variable
.../$IMG_PREFIX-cip-core-$RELEASE-$TARGET
where $IMG_PREFIX is default to "cip-core-image" if not specified
for security image it will be passed as 4th argument "cip-core-image-security"
2. currently scrit is expecting the image format in *.wic.img so,
for qemu i think we should have wks file to generate image with format .wic.img

or for this security image do we need to deploy it seperatley?
please guide me
Sometimes it is better to send a patch instead of trying to explain it with words.

Thanks,
Daniel


Re: CIP embedded platform Internet connection?

Daniel Sangorrin
 

Hi Mohammed,

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Mohammed Billoo
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.
There is nothing in CIP SWUpdate that assumes the Hawkbit server is on a local network.
Perhaps the README is using a local serve for demonstration purposes?

Thanks,
Daniel


Re: [isar-cip-core PATCH v2 0/5] A/B Rootfs update with software update

Jan Kiszka
 

On 29.06.20 11:56, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
This patchset adds efibootguard, swupdate to allow A/B updates in
cip-core. The update mechanism is currently only implemented for x86_64.
Changes V2:
- update efibootguard to v0.7
- add swdescription and kas option to build qemu-amd64 test image
- swupdate set to upstream mirror and no longer use gitsm
Quirin Gylstorff (5):
recipes-bsp: Add efibootguard
patches: add libubootenv
recipes-core: add swupdate
wic: Add wks files for A/B Partition update
swupdate: create swu file from wic image
classes/extract-partition.bbclass | 26 +
classes/kconfig-snippets.bbclass | 90 ++++
classes/swupdate-config.bbclass | 76 +++
classes/swupdate-img.bbclass | 75 +++
classes/wic-swu-img.bbclass | 20 +
.../0001-u-boot-add-libubootenv.patch | 169 +++++++
kas-cip.yml | 4 +
kas/opt/ebg-swu.yml | 26 +
kas/opt/qemu-swupdate.yml | 19 +
.../efibootguard/efibootguard_0.7-git+isar.bb | 46 ++
recipes-bsp/efibootguard/files/debian/compat | 1 +
.../efibootguard/files/debian/control.tmpl | 20 +
.../files/debian/efibootguard-dev.install | 3 +
.../files/debian/efibootguard.install | 2 +
recipes-bsp/efibootguard/files/debian/rules | 21 +
recipes-core/images/cip-core-image.bb | 10 +
recipes-core/images/files/sw-description.tmpl | 29 ++
.../swupdate/files/debian/changelog.tmpl | 6 +
recipes-core/swupdate/files/debian/compat | 1 +
.../swupdate/files/debian/control.tmpl | 15 +
recipes-core/swupdate/files/debian/copyright | 36 ++
recipes-core/swupdate/files/debian/rules.tmpl | 30 ++
.../swupdate/files/debian/swupdate.examples | 2 +
.../swupdate/files/debian/swupdate.install | 2 +
.../swupdate/files/debian/swupdate.manpages | 5 +
.../swupdate/files/debian/swupdate.tmpfile | 2 +
recipes-core/swupdate/files/debian/watch | 12 +
recipes-core/swupdate/files/postinst | 2 +
recipes-core/swupdate/files/swupdate.cfg | 6 +
.../swupdate/files/swupdate.service.example | 11 +
.../swupdate/files/swupdate.socket.example | 11 +
.../swupdate/files/swupdate.socket.tmpl | 13 +
.../swupdate/files/swupdate_defconfig | 83 ++++
.../swupdate_defconfig_efibootguard.snippet | 3 +
.../files/swupdate_defconfig_lua.snippet | 2 +
.../swupdate_defconfig_luahandler.snippet | 4 +
.../files/swupdate_defconfig_mtd.snippet | 1 +
.../files/swupdate_defconfig_u-boot.snippet | 3 +
.../files/swupdate_defconfig_ubi.snippet | 6 +
.../swupdate/files/swupdate_handlers.lua | 453 ++++++++++++++++++
recipes-core/swupdate/swupdate.bb | 54 +++
.../wic/plugins/source/efibootguard-boot.py | 162 +++++++
.../wic/plugins/source/efibootguard-efi.py | 102 ++++
wic/ebg-sysparts.inc | 8 +
wic/qemu-amd64-efibootguard.wks | 5 +
wic/simatic-ipc227e-efibootguard.wks | 5 +
wic/swupdate-partition.inc | 4 +
47 files changed, 1686 insertions(+)
create mode 100644 classes/extract-partition.bbclass
create mode 100644 classes/kconfig-snippets.bbclass
create mode 100644 classes/swupdate-config.bbclass
create mode 100644 classes/swupdate-img.bbclass
create mode 100644 classes/wic-swu-img.bbclass
create mode 100644 isar-patches/0001-u-boot-add-libubootenv.patch
create mode 100644 kas/opt/ebg-swu.yml
create mode 100644 kas/opt/qemu-swupdate.yml
create mode 100644 recipes-bsp/efibootguard/efibootguard_0.7-git+isar.bb
create mode 100644 recipes-bsp/efibootguard/files/debian/compat
create mode 100644 recipes-bsp/efibootguard/files/debian/control.tmpl
create mode 100644 recipes-bsp/efibootguard/files/debian/efibootguard-dev.install
create mode 100644 recipes-bsp/efibootguard/files/debian/efibootguard.install
create mode 100755 recipes-bsp/efibootguard/files/debian/rules
create mode 100644 recipes-core/images/files/sw-description.tmpl
create mode 100644 recipes-core/swupdate/files/debian/changelog.tmpl
create mode 100644 recipes-core/swupdate/files/debian/compat
create mode 100644 recipes-core/swupdate/files/debian/control.tmpl
create mode 100644 recipes-core/swupdate/files/debian/copyright
create mode 100755 recipes-core/swupdate/files/debian/rules.tmpl
create mode 100644 recipes-core/swupdate/files/debian/swupdate.examples
create mode 100644 recipes-core/swupdate/files/debian/swupdate.install
create mode 100644 recipes-core/swupdate/files/debian/swupdate.manpages
create mode 100644 recipes-core/swupdate/files/debian/swupdate.tmpfile
create mode 100644 recipes-core/swupdate/files/debian/watch
create mode 100644 recipes-core/swupdate/files/postinst
create mode 100644 recipes-core/swupdate/files/swupdate.cfg
create mode 100644 recipes-core/swupdate/files/swupdate.service.example
create mode 100644 recipes-core/swupdate/files/swupdate.socket.example
create mode 100644 recipes-core/swupdate/files/swupdate.socket.tmpl
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_efibootguard.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_lua.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_luahandler.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_mtd.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_u-boot.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_ubi.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_handlers.lua
create mode 100644 recipes-core/swupdate/swupdate.bb
create mode 100644 scripts/lib/wic/plugins/source/efibootguard-boot.py
create mode 100644 scripts/lib/wic/plugins/source/efibootguard-efi.py
create mode 100644 wic/ebg-sysparts.inc
create mode 100644 wic/qemu-amd64-efibootguard.wks
create mode 100644 wic/simatic-ipc227e-efibootguard.wks
create mode 100644 wic/swupdate-partition.inc
Thanks, applied to next. The secure boot series is on hold due to conflict. When you update it, please also make sure that at least one target covering as much as possible of your code is built via CI.

Jan

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


Re: [isar-cip-core PATCH v3 4/6] secure-boot: Add secure boot with unified kernel image

Jan Kiszka
 

On 24.07.20 17:01, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
A unified kernel image contains the os-release, kernel,
kernel commandline, initramfs and efi-stub in one binary.
This binary can be boot by systemd-boot and efibootguard.
It also allows to sign kernel and initramfs as one packages.
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
...

diff --git a/start-qemu.sh b/start-qemu.sh
index 49f0266..74d1b54 100755
--- a/start-qemu.sh
+++ b/start-qemu.sh
@@ -15,6 +15,8 @@ usage()
echo "Usage: $0 ARCHITECTURE [QEMU_OPTIONS]"
echo -e "\nSet QEMU_PATH environment variable to use a locally " \
"built QEMU version"
+ echo -e "\nSet SECURE_BOOT environment variable to boot a secure boot environment " \
+ "This environment also needs the variables OVMF_VARS and OVMF_CODE set"
exit 1
}
@@ -22,17 +24,25 @@ if [ -n "${QEMU_PATH}" ]; then
QEMU_PATH="${QEMU_PATH}/"
fi
+if [ -z "${DISTRO_RELEASE}" ]; then
+ DISTRO_RELEASE="buster"
+fi
+if [ -z "${TARGET_IMAGE}" ];then
+ TARGET_IMAGE="cip-core-image"
+fi
+
case "$1" in
x86|x86_64|amd64)
DISTRO_ARCH=amd64
QEMU=qemu-system-x86_64
QEMU_EXTRA_ARGS=" \
- -cpu host -smp 4 \
- -enable-kvm -machine q35 \
+ -cpu qemu64 \
+ -smp 4 \
+ -machine q35,accel=kvm:tcg \
-device ide-hd,drive=disk \
-device virtio-net-pci,netdev=net"
KERNEL_CMDLINE=" \
- root=/dev/sda vga=0x305 console=ttyS0"
+ root=/dev/sda vga=0x305"
;;
arm64|aarch64)
DISTRO_ARCH=arm64
@@ -71,21 +81,41 @@ case "$1" in
;;
esac
-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}"
-IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img)
+IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/${TARGET_IMAGE}-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}"
if [ -z "${DISPLAY}" ]; then
QEMU_EXTRA_ARGS="${QEMU_EXTRA_ARGS} -nographic"
+ case "$1" in
+ x86|x86_64|amd64)
+ KERNEL_CMDLINE="${KERNEL_CMDLINE} console=ttyS0"
+ esac
+fi
+
+
+
+if [ -n "SECURE_BOOT" ]; then
+ ovmf_code=${OVMF_CODE:-/usr/share/OVMF/OVMF_CODE.secboot.fd}
+ ovmf_vars=${OVMF_VARS:-./OVMF_VARS.fd}
+ QEMU_EXTRA_ARGS=" \
+ ${QEMU_EXTRA_ARGS} \
+ -global ICH9-LPC.disable_s3=1 \
+ -global isa-fdc.driveA= \
+ "
Looks like someone fell asleep on the tab key - please indent more reasonably.

+ BOOT_FILES="-drive if=pflash,format=raw,unit=0,readonly=on,file=${ovmf_code} \
+ -drive if=pflash,format=raw,file=${ovmf_vars} \
+ -drive file=${IMAGE_PREFIX}.wic.img,discard=unmap,if=none,id=disk,format=raw"
+else
+ IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img)
+
+ KERNEL_FILE=$(ls ${IMAGE_PREFIX}-vmlinuz* | tail -1)
+ INITRD_FILE=$(ls ${IMAGE_PREFIX}-initrd.img* | tail -1)
+
+ BOOT_FILES=-kernel ${KERNEL_FILE} -append "${KERNEL_CMDLINE}" \
+ -initrd ${INITRD_FILE}
fi
shift 1
${QEMU_PATH}${QEMU} \
- -drive file=${IMAGE_FILE},discard=unmap,if=none,id=disk,format=raw \
-m 1G -serial mon:stdio -netdev user,id=net \
- -kernel ${IMAGE_PREFIX}-vmlinuz -append "${KERNEL_CMDLINE}" \
- -initrd ${IMAGE_PREFIX}-initrd.img ${QEMU_EXTRA_ARGS} "$@"
+ ${BOOT_FILES} ${QEMU_EXTRA_ARGS} "$@"
This file is in conflict with changes in next. Please rebase.

Jan

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


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

Jan Kiszka
 

On 27.07.20 13:41, Venkata Pyla wrote:
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
Applied to next - now awaiting the patch for .gitlab-ci.yml ;)

Thanks,
Jan

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


Re: [isar-cip-core PATCH v3 1/6] kernel: add fat for qemu-amd64

Jan Kiszka
 

On 24.07.20 17:01, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
Add a fat configuration to access FAT Partitions on the qemu-amd64
target.
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
recipes-kernel/linux/files/qemu-amd64_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/recipes-kernel/linux/files/qemu-amd64_defconfig b/recipes-kernel/linux/files/qemu-amd64_defconfig
index 7487152..5449317 100644
--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,9 @@ CONFIG_CRYPTO_DEV_CCP=y
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
Taking that for now, but we should quickly move that defconfig into cip-kernel-config. I'm not sure if there is anything for qemu already. Could you check an propose our defconfig for it?

Jan

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


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

Jan Kiszka
 

On 29.07.20 14:39, Venkata Pyla wrote:
On Mon, Jul 27, 2020 at 08:04 PM, Jan Kiszka wrote:


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.
To add security image in gitlab-ci.yml i need some suggestions...
in deploy-cip-core script that is used in gitlab-ci is expecting *.wic image for copying the files,
but because there is no wks file yet for QEMU it is not generating the image.
i think we should add wks file for the qemu target, can you guide me how to do that?
Such a wks file only makes sense when we switch QEMU to image-based booting, like Quirin does in [1].

For adding CI coverage to the security image, it would already be enough to just build it, skipping the deployment. Of course, if you'd like to feed the build result into automated testing, that needs deployment again, but possibly also more. So, let's postpone it until that is on the agenda of the day, I would say.

Jan

[1] https://lists.cip-project.org/g/cip-dev/message/4997

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


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

Venkata Pyla
 

On Mon, Jul 27, 2020 at 08:04 PM, Jan Kiszka wrote:


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.
To add security image in gitlab-ci.yml i need some suggestions...
in deploy-cip-core script that is used in gitlab-ci is expecting *.wic image for copying the files,
but because there is no wks file yet for QEMU it is not generating the image.

i think we should add wks file for the qemu target, can you guide me how to do that?

Jan

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


[PATCH 4.4.y-cip] ARM: dts: iwg22d-sodimm: Enable touchscreen

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

From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>

commit 99ae78f1fc3a73c88fe726c676ae963ce722bf20 upstream.

In one of the iWave-G22D development board variants, called Generic SODIMM
Development Platform, we have an LCD with touchscreen. The resistive touch
controller, STMPE811 is on the development board and is connected through
the i2c5 of the RZ-G1E.

Additionally, this controller should generate an interrupt to the CPU and
it is connected through GPIO4,4 to the GIC.

Touch was tested with one of our iW-RainboW-G22D-SODIMM RZ/G1E development
platforms.

More details on the iWave website:
https://www.iwavesystems.com/rz-g1e-sodimm-development-kit.html

Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Link: https://lore.kernel.org/r/1583336650-25848-1-git-send-email-marian-cristian.rotariu.rb@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 33 +++++++++++++++++++++
1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index 1e331d1e414b..5cd989556b60 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -149,6 +149,39 @@
status = "okay";
clock-frequency = <400000>;

+ stmpe811@44 {
+ compatible = "st,stmpe811";
+ reg = <0x44>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+
+ stmpe_touchscreen {
+ compatible = "st,stmpe-ts";
+ /* 8 sample average control */
+ st,ave-ctrl = <3>;
+ /* 7 length fractional part in z */
+ st,fraction-z = <7>;
+ /*
+ * 50 mA typical 80 mA max touchscreen drivers
+ * current limit value
+ */
+ st,i-drive = <1>;
+ /* 1 ms panel driver settling time */
+ st,settling = <3>;
+ /* 5 ms touch detect interrupt delay */
+ st,touch-det-delay = <5>;
+ };
+ };
+
sgtl5000: codec@a {
compatible = "fsl,sgtl5000";
#sound-dai-cells = <0>;
--
2.17.1


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

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

Hi All,

Thanks for the feedback.

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

Hi all,

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Wednesday, July 29, 2020 5:40 AM
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC
◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Chris Paterson
<chris.paterson2@renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E
board

Hi!

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.
I don't see anything wrong with this, so I'll test/apply it if noone objects.
I didn't see any isseue this patche series.
The CI test is fine, so I commit.

I guess we could like patches for cip-kernel-config repository to
actually enable this in our testing...
+1.
Sure I will send a new merge request for cip-kernel-config.

Cheers,
Biju


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


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

Nobuhiro Iwamatsu
 

Hi all,

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Wednesday, July 29, 2020 5:40 AM
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Chris Paterson <chris.paterson2@renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E board

Hi!

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.
I don't see anything wrong with this, so I'll test/apply it if noone objects.
I didn't see any isseue this patche series.
The CI test is fine, so I commit.

I guess we could like patches for cip-kernel-config repository to actually enable this in
our testing...
+1.


Best regards,
Pavel
Best regards,
Nobuhiro


Re: [isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 11:07 PM
[...]

Nobuhiro, is something missing from your perspective in Daniels approach? If not, I'd like to have one patch that takes us to that level.

By now, I think an opt-testtools.yml is better (an "option", not a
"layer") than a separate image. That allows to test the security image eventually as well.
Personally, I think the same.
Perhaps Iwamatsu-san got a bit confused by the comments on the merge request.

Thanks,
Daniel

2001 - 2020 of 7061