Date   

[meta-selinux][PATCH 2/3] refpolicy: fix unknown classes and permissions

wenzong.fan@...
 

From: Wenzong Fan <wenzong.fan@windriver.com>

Backport upstream patches:
- 0001-refpolicy-Define-getrlimit-permission-for-class-proc.patch
- 0002-refpolicy-Define-smc_socket-security-class.patch

This fixes the runtime issues:

$ load_policy
SELinux: Permission getrlimit in class process not defined in policy.
SELinux: Class smc_socket not defined in policy.
SELinux: the above unknown classes and permissions will be allowed

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
---
...efine-getrlimit-permission-for-class-proc.patch | 33 ++++++++++
...efpolicy-Define-smc_socket-security-class.patch | 74 ++++++++++++++++++++++
.../refpolicy/refpolicy_2.20170204.inc | 6 ++
3 files changed, 113 insertions(+)
create mode 100644 recipes-security/refpolicy/refpolicy-2.20170204/0001-refpolicy-Define-getrlimit-permission-for-class-proc.patch
create mode 100644 recipes-security/refpolicy/refpolicy-2.20170204/0002-refpolicy-Define-smc_socket-security-class.patch

diff --git a/recipes-security/refpolicy/refpolicy-2.20170204/0001-refpolicy-Define-getrlimit-permission-for-class-proc.patch b/recipes-security/refpolicy/refpolicy-2.20170204/0001-refpolicy-Define-getrlimit-permission-for-class-proc.patch
new file mode 100644
index 0000000..727e48a
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-2.20170204/0001-refpolicy-Define-getrlimit-permission-for-class-proc.patch
@@ -0,0 +1,33 @@
+From c5cdfec50b4d6191173725b32b311399345962ac Mon Sep 17 00:00:00 2001
+From: Stephen Smalley <sds@tycho.nsa.gov>
+Date: Wed, 17 May 2017 11:33:46 -0400
+Subject: [PATCH 1/2] refpolicy: Define getrlimit permission for class process
+
+This permission was added to the kernel in commit 791ec491c372
+("prlimit,security,selinux: add a security hook for prlimit")
+circa Linux 4.12 in order to control the ability to get the resource
+limits of another process. It is only checked when acting on another
+process, so getrlimit permission is not required for use of getrlimit(2).
+
+Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
+
+Upstream-Status: Backport
+---
+ policy/flask/access_vectors | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
+index 69f69af..6204e68 100644
+--- a/policy/flask/access_vectors
++++ b/policy/flask/access_vectors
+@@ -383,6 +383,7 @@ class process
+ execheap
+ setkeycreate
+ setsockcreate
++ getrlimit
+ }
+
+
+--
+2.7.4
+
diff --git a/recipes-security/refpolicy/refpolicy-2.20170204/0002-refpolicy-Define-smc_socket-security-class.patch b/recipes-security/refpolicy/refpolicy-2.20170204/0002-refpolicy-Define-smc_socket-security-class.patch
new file mode 100644
index 0000000..e8ef659
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-2.20170204/0002-refpolicy-Define-smc_socket-security-class.patch
@@ -0,0 +1,74 @@
+From cfe0a94feb3e965663ea20961ac866ac8712b94a Mon Sep 17 00:00:00 2001
+From: Stephen Smalley <sds@tycho.nsa.gov>
+Date: Wed, 17 May 2017 11:31:48 -0400
+Subject: [PATCH 2/2] refpolicy: Define smc_socket security class
+
+Linux kernel commit da69a5306ab9 ("selinux: support distinctions among all
+network address families") triggers a build error if a new address family
+is added without defining a corresponding SELinux security class. As a
+result, the smc_socket class was added to the kernel to resolve a build
+failure as part of merge commit 3051bf36c25d that introduced AF_SMC circa
+Linux 4.11. Define this security class and its access vector, note that it
+is enabled as part of the extended_socket_class policy capability, and add
+it to the socket_class_set macro.
+
+Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
+
+Upstream-Status: Backport
+---
+ policy/flask/access_vectors | 3 +++
+ policy/flask/security_classes | 1 +
+ policy/policy_capabilities | 1 +
+ policy/support/obj_perm_sets.spt | 2 +-
+ 4 files changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
+index 6204e68..7652a31 100644
+--- a/policy/flask/access_vectors
++++ b/policy/flask/access_vectors
+@@ -1059,3 +1059,6 @@ inherits socket
+
+ class qipcrtr_socket
+ inherits socket
++
++class smc_socket
++inherits socket
+diff --git a/policy/flask/security_classes b/policy/flask/security_classes
+index 18f18fd..18c4f97 100644
+--- a/policy/flask/security_classes
++++ b/policy/flask/security_classes
+@@ -182,5 +182,6 @@ class nfc_socket
+ class vsock_socket
+ class kcm_socket
+ class qipcrtr_socket
++class smc_socket
+
+ # FLASK
+diff --git a/policy/policy_capabilities b/policy/policy_capabilities
+index 39e3930..e0ff6e3 100644
+--- a/policy/policy_capabilities
++++ b/policy/policy_capabilities
+@@ -77,6 +77,7 @@ policycap open_perms;
+ # vsock_socket
+ # kcm_socket
+ # qipcrtr_socket
++# smc_socket
+ #
+ # Available in kernel 4.11+.
+ # Requires libsepol 2.7+ to build policy with this enabled.
+diff --git a/policy/support/obj_perm_sets.spt b/policy/support/obj_perm_sets.spt
+index 590ea63..872ca1d 100644
+--- a/policy/support/obj_perm_sets.spt
++++ b/policy/support/obj_perm_sets.spt
+@@ -34,7 +34,7 @@ define(`devfile_class_set', `{ blk_file chr_file }')
+ #
+ # All socket classes.
+ #
+-define(`socket_class_set', `{ tcp_socket udp_socket rawip_socket netlink_socket packet_socket unix_stream_socket unix_dgram_socket appletalk_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket netlink_iscsi_socket netlink_fib_lookup_socket netlink_connector_socket netlink_netfilter_socket netlink_generic_socket netlink_scsitransport_socket netlink_rdma_socket netlink_crypto_socket sctp_socket icmp_socket ax25_socket ipx_socket netrom_socket atmpvc_socket x25_socket rose_socket decnet_socket atmsvc_socket rds_socket irda_socket pppox_socket llc_socket can_socket tipc_socket bluetooth_socket iucv_socket rxrpc_socket isdn_socket phonet_socket ieee802154_socket caif_socket alg_socket nfc_socket vsock_socket kcm_socket qipcrtr_socket}')
++define(`socket_class_set', `{ tcp_socket udp_socket rawip_socket netlink_socket packet_socket unix_stream_socket unix_dgram_socket appletalk_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket netlink_iscsi_socket netlink_fib_lookup_socket netlink_connector_socket netlink_netfilter_socket netlink_generic_socket netlink_scsitransport_socket netlink_rdma_socket netlink_crypto_socket sctp_socket icmp_socket ax25_socket ipx_socket netrom_socket atmpvc_socket x25_socket rose_socket decnet_socket atmsvc_socket rds_socket irda_socket pppox_socket llc_socket can_socket tipc_socket bluetooth_socket iucv_socket rxrpc_socket isdn_socket phonet_socket ieee802154_socket caif_socket alg_socket nfc_socket vsock_socket kcm_socket qipcrtr_socket smc_socket }')
+
+ #
+ # Datagram socket classes.
+--
+2.7.4
+
diff --git a/recipes-security/refpolicy/refpolicy_2.20170204.inc b/recipes-security/refpolicy/refpolicy_2.20170204.inc
index 8b72cbd..51c5050 100644
--- a/recipes-security/refpolicy/refpolicy_2.20170204.inc
+++ b/recipes-security/refpolicy/refpolicy_2.20170204.inc
@@ -55,4 +55,10 @@ SRC_URI += " \
file://ftp-add-ftpd_t-to-mlsfilewrite.patch \
"

+# Backport from upstream
+SRC_URI += " \
+ file://0001-refpolicy-Define-getrlimit-permission-for-class-proc.patch \
+ file://0002-refpolicy-Define-smc_socket-security-class.patch \
+ "
+
include refpolicy_common.inc
--
2.13.0


[meta-selinux][PATCH 1/3] refpolicy-targeted: rebase patches for 2.20170204

wenzong.fan@...
 

From: Wenzong Fan <wenzong.fan@windriver.com>

Rebase and apply the patches for 2.20170204:
- refpolicy-fix-optional-issue-on-sysadm-module.patch
- refpolicy-unconfined_u-default-user.patch

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
---
...olicy-fix-optional-issue-on-sysadm-module.patch | 33 +++--
.../refpolicy-unconfined_u-default-user.patch | 140 +++++++++------------
2 files changed, 77 insertions(+), 96 deletions(-)

diff --git a/recipes-security/refpolicy/refpolicy-targeted/refpolicy-fix-optional-issue-on-sysadm-module.patch b/recipes-security/refpolicy/refpolicy-targeted/refpolicy-fix-optional-issue-on-sysadm-module.patch
index b33e84b..04fc575 100644
--- a/recipes-security/refpolicy/refpolicy-targeted/refpolicy-fix-optional-issue-on-sysadm-module.patch
+++ b/recipes-security/refpolicy/refpolicy-targeted/refpolicy-fix-optional-issue-on-sysadm-module.patch
@@ -17,12 +17,12 @@ Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
policy/modules/system/locallogin.te | 4 +++-
2 files changed, 11 insertions(+), 7 deletions(-)

+diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
+index 6503fff..be291a9 100644
--- a/policy/modules/system/init.te
+++ b/policy/modules/system/init.te
-@@ -344,17 +344,19 @@ ifdef(`init_systemd',`
-
- optional_policy(`
- modutils_domtrans(init_t)
+@@ -302,12 +302,14 @@ ifdef(`init_systemd',`
+ modutils_domtrans_insmod(init_t)
')
',`
- tunable_policy(`init_upstart',`
@@ -30,27 +30,23 @@ Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
- ',`
- # Run the shell in the sysadm role for single-user mode.
- # causes problems with upstart
-- ifndef(`distro_debian',`
-- sysadm_shell_domtrans(init_t)
+- sysadm_shell_domtrans(init_t)
+ optional_policy(`
+ tunable_policy(`init_upstart',`
+ corecmd_shell_domtrans(init_t, initrc_t)
+ ',`
+ # Run the shell in the sysadm role for single-user mode.
+ # causes problems with upstart
-+ ifndef(`distro_debian',`
-+ sysadm_shell_domtrans(init_t)
-+ ')
- ')
++ sysadm_shell_domtrans(init_t)
++ ')
')
')

- ifdef(`distro_debian',`
+diff --git a/policy/modules/system/locallogin.te b/policy/modules/system/locallogin.te
+index 8386084..5242713 100644
--- a/policy/modules/system/locallogin.te
+++ b/policy/modules/system/locallogin.te
-@@ -260,11 +260,13 @@ seutil_read_default_contexts(sulogin_t)
- userdom_use_unpriv_users_fds(sulogin_t)
-
+@@ -246,7 +246,9 @@ userdom_use_unpriv_users_fds(sulogin_t)
userdom_search_user_home_dirs(sulogin_t)
userdom_use_user_ptys(sulogin_t)

@@ -59,7 +55,8 @@ Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
+ sysadm_shell_domtrans(sulogin_t)
+')

- # by default, sulogin does not use pam...
- # sulogin_pam might need to be defined otherwise
- ifdef(`sulogin_pam', `
- selinux_get_fs_mount(sulogin_t)
+ # suse and debian do not use pam with sulogin...
+ ifdef(`distro_suse', `define(`sulogin_no_pam')')
+--
+2.13.0
+
diff --git a/recipes-security/refpolicy/refpolicy-targeted/refpolicy-unconfined_u-default-user.patch b/recipes-security/refpolicy/refpolicy-targeted/refpolicy-unconfined_u-default-user.patch
index 29d3e2d..95c50ac 100644
--- a/recipes-security/refpolicy/refpolicy-targeted/refpolicy-unconfined_u-default-user.patch
+++ b/recipes-security/refpolicy/refpolicy-targeted/refpolicy-unconfined_u-default-user.patch
@@ -13,13 +13,15 @@ Signed-off-by: Xin Ouyang <Xin.Ouyang@windriver.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
---
- config/appconfig-mcs/seusers | 4 ++--
+ config/appconfig-mcs/seusers | 5 ++--
policy/modules/roles/sysadm.te | 1 +
- policy/modules/system/init.if | 47 ++++++++++++++++++++++++++++++-------
+ policy/modules/system/init.if | 46 ++++++++++++++++++++++++++++++-------
policy/modules/system/unconfined.te | 7 ++++++
policy/users | 16 +++++--------
5 files changed, 55 insertions(+), 20 deletions(-)

+diff --git a/config/appconfig-mcs/seusers b/config/appconfig-mcs/seusers
+index ce614b4..d707475 100644
--- a/config/appconfig-mcs/seusers
+++ b/config/appconfig-mcs/seusers
@@ -1,2 +1,3 @@
@@ -28,25 +30,58 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
+root:unconfined_u:s0-mcs_systemhigh
+__default__:unconfined_u:s0
+
+diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te
+index 46fbe81..6a6468f 100644
--- a/policy/modules/roles/sysadm.te
+++ b/policy/modules/roles/sysadm.te
-@@ -37,10 +37,11 @@ ubac_process_exempt(sysadm_t)
- ubac_file_exempt(sysadm_t)
- ubac_fd_exempt(sysadm_t)
-
- init_exec(sysadm_t)
- init_admin(sysadm_t)
+@@ -43,6 +43,7 @@ init_shutdown_system(sysadm_t)
+ init_start_generic_units(sysadm_t)
+ init_stop_generic_units(sysadm_t)
+ init_reload_generic_units(sysadm_t)
+init_script_role_transition(sysadm_r)

- selinux_read_policy(sysadm_t)
-
# Add/remove user home directories
userdom_manage_user_home_dirs(sysadm_t)
+diff --git a/policy/modules/system/init.if b/policy/modules/system/init.if
+index 0cb296f..6e26881 100644
--- a/policy/modules/system/init.if
+++ b/policy/modules/system/init.if
-@@ -1394,30 +1394,31 @@ interface(`init_script_file_entry_type',
- ## </summary>
- ## </param>
+@@ -44,6 +44,34 @@ interface(`init_script_file',`
+
+ ########################################
+ ## <summary>
++## Transition to system_r when execute an init script
++## </summary>
++## <desc>
++## <p>
++## Execute a init script in a specified role
++## </p>
++## <p>
++## No interprocess communication (signals, pipes,
++## etc.) is provided by this interface since
++## the domains are not owned by this module.
++## </p>
++## </desc>
++## <param name="source_role">
++## <summary>
++## Role to transition from.
++## </summary>
++## </param>
++#
++interface(`init_script_role_transition',`
++ gen_require(`
++ attribute init_script_file_type;
++ ')
++
++ role_transition $1 init_script_file_type system_r;
++')
++
++########################################
++## <summary>
+ ## Make the specified type usable for
+ ## systemd unit files.
+ ## </summary>
+@@ -1234,11 +1262,12 @@ interface(`init_script_file_entry_type',`
#
interface(`init_spec_domtrans_script',`
gen_require(`
@@ -61,10 +96,7 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>

ifdef(`distro_gentoo',`
gen_require(`
- type rc_exec_t;
- ')
-
- domtrans_pattern($1, rc_exec_t, initrc_t)
+@@ -1249,11 +1278,11 @@ interface(`init_spec_domtrans_script',`
')

ifdef(`enable_mcs',`
@@ -78,11 +110,7 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
')
')

- ########################################
- ## <summary>
-@@ -1429,22 +1430,23 @@ interface(`init_spec_domtrans_script',`
- ## </summary>
- ## </param>
+@@ -1269,18 +1298,19 @@ interface(`init_spec_domtrans_script',`
#
interface(`init_domtrans_script',`
gen_require(`
@@ -106,48 +134,11 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
')
')

- ########################################
- ## <summary>
-@@ -2972,5 +2974,34 @@ interface(`init_admin',`
- init_stop_all_units($1)
- init_stop_generic_units($1)
- init_stop_system($1)
- init_telinit($1)
- ')
-+
-+########################################
-+## <summary>
-+## Transition to system_r when execute an init script
-+## </summary>
-+## <desc>
-+## <p>
-+## Execute a init script in a specified role
-+## </p>
-+## <p>
-+## No interprocess communication (signals, pipes,
-+## etc.) is provided by this interface since
-+## the domains are not owned by this module.
-+## </p>
-+## </desc>
-+## <param name="source_role">
-+## <summary>
-+## Role to transition from.
-+## </summary>
-+## </param>
-+#
-+interface(`init_script_role_transition',`
-+ gen_require(`
-+ attribute init_script_file_type;
-+ ')
-+
-+ role_transition $1 init_script_file_type system_r;
-+')
-+
+diff --git a/policy/modules/system/unconfined.te b/policy/modules/system/unconfined.te
+index 189869d..5688bbb 100644
--- a/policy/modules/system/unconfined.te
+++ b/policy/modules/system/unconfined.te
-@@ -18,10 +18,15 @@ init_system_domain(unconfined_t, unconfi
-
- type unconfined_execmem_t;
+@@ -20,6 +20,11 @@ type unconfined_execmem_t;
type unconfined_execmem_exec_t;
init_system_domain(unconfined_execmem_t, unconfined_execmem_exec_t)
role unconfined_r types unconfined_execmem_t;
@@ -159,11 +150,7 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>

########################################
#
- # Local policy
- #
-@@ -48,10 +53,12 @@ unconfined_domain(unconfined_t)
- userdom_user_home_dir_filetrans_user_home_content(unconfined_t, { dir file lnk_file fifo_file sock_file })
-
+@@ -50,6 +55,8 @@ userdom_user_home_dir_filetrans_user_home_content(unconfined_t, { dir file lnk_f
ifdef(`direct_sysadm_daemon',`
optional_policy(`
init_run_daemon(unconfined_t, unconfined_r)
@@ -172,13 +159,11 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
')
',`
ifdef(`distro_gentoo',`
- seutil_run_runinit(unconfined_t, unconfined_r)
- seutil_init_script_run_runinit(unconfined_t, unconfined_r)
+diff --git a/policy/users b/policy/users
+index ca20375..ac1ca6c 100644
--- a/policy/users
+++ b/policy/users
-@@ -13,37 +13,33 @@
- # system_u is the user identity for system processes and objects.
- # There should be no corresponding Unix user identity for system,
+@@ -15,7 +15,7 @@
# and a user process should never be assigned the system user
# identity.
#
@@ -187,9 +172,7 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>

#
# user_u is a generic user identity for Linux users who have no
- # SELinux user identity defined. The modified daemons will use
- # this user identity in the security context if there is no matching
- # SELinux user identity for a Linux user. If you do not want to
+@@ -25,14 +25,14 @@ gen_user(system_u,, system_r, s0, s0 - mls_systemhigh, mcs_allcats)
# permit any access to such users, then remove this entry.
#
gen_user(user_u, user, user_r, s0, s0)
@@ -208,9 +191,7 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
')

#
- # The following users correspond to Unix identities.
- # These identities are typically assigned as the user attribute
- # when login starts the user shell. Users with access to the sysadm_r
+@@ -42,8 +42,4 @@ ifdef(`direct_sysadm_daemon',`
# role should use the staff_r role instead of the user_r role when
# not in the sysadm_r.
#
@@ -220,3 +201,6 @@ Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
- gen_user(root, sysadm, sysadm_r staff_r ifdef(`enable_mls',`secadm_r auditadm_r'), s0, s0 - mls_systemhigh, mcs_allcats)
-')
+gen_user(root, user, sysadm_r staff_r ifdef(`enable_mls',`secadm_r auditadm_r') unconfined_r system_r, s0, s0 - mls_systemhigh, mcs_allcats)
+--
+2.13.0
+
--
2.13.0


[meta-security][PATCH V2] keynote: update the SRC_URI

Dengke Du <dengke.du@...>
 

The old URL can't be available, give the new URL to keynote.
The project already moved to:

https://sourceforge.net/projects/keynote-2-3/

The different between old and new tarball was:

the old tarball contains doc directory, source codes were same.

Signed-off-by: Dengke Du <dengke.du@windriver.com>
---
recipes-security/keynote/keynote_2.3.bb | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/recipes-security/keynote/keynote_2.3.bb b/recipes-security/keynote/keynote_2.3.bb
index b1df880..e692485 100644
--- a/recipes-security/keynote/keynote_2.3.bb
+++ b/recipes-security/keynote/keynote_2.3.bb
@@ -9,16 +9,19 @@ SECTION = "security"
LICENSE = "ISC"
LIC_FILES_CHKSUM = "file://LICENSE;md5=3a265095c549c1808686a676f2699c98"

-SRC_URI = "http://www.cs.columbia.edu/~angelos/Code/${BPN}.tar.gz \
+MAIN_ID = "${@d.getVar('PV').split('.')[0]}"
+MINOR_ID = "${@d.getVar('PV').split('.')[1]}"
+SRC_URI = "${SOURCEFORGE_MIRROR}/project/${BPN}-${MAIN_ID}-${MINOR_ID}/${BPN}_${PV}.tar.gz \
file://configure-remove-hardcode-path.patch \
file://makefile-add-ldflags.patch \
file://run-ptest \
"
+S = "${WORKDIR}/${BPN}-${PV}+dfsg.orig"

inherit autotools-brokensep ptest

-SRC_URI[md5sum] = "ba58a0297c421dc6aa671e6b753ef695"
-SRC_URI[sha256sum] = "62f7a9d57ceb6bcdd47b604b637a7ac8ed337cef0ab02f1fa28b7e61c9b15821"
+SRC_URI[md5sum] = "a14553e6ad921b5c85026ce5bec3afe7"
+SRC_URI[sha256sum] = "38d2acfa1c3630a07adcb5c8fe92d2aef7f0e6d242b8998b2bbb1c6e4c408d46"

DEPENDS = "flex openssl"

--
2.8.1


populate sdk fails when multilib enabled

Ferry Toth <ftoth@...>
 

When I build for x86_64 I found I needed to enable multilib to be able to
build u-boot (actually lib32_u-boot). U-boot now builds.

However 'bitbake edison-image -c populate_sdk' now errors with
Build Configuration:
BB_VERSION = "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "edison"
DISTRO = "poky-edison"
DISTRO_VERSION = "2.2.2"
TUNE_FEATURES = "m64 core2"

The following packages have unmet dependencies:
lib32-packagegroup-core-standalone-sdk-target :
Depends: lib32-glibc but it is not installable
Depends: lib32-glibc-dbg but it is not installable
Depends: lib32-glibc-dev but it is not installable
Depends: lib32-glibc-gconv-cp1252 but it is not installable
Depends: lib32-glibc-gconv-ibm850 but it is not installable
Depends: lib32-glibc-gconv-iso8859-1 but it is not installable
Depends: lib32-glibc-gconv-iso8859-15 but it is not installable
Depends: lib32-glibc-localedata-i18n but it is not installable
Depends: lib32-glibc-thread-db but it is not installable
Depends: lib32-glibc-utils but it is not installable
Depends: lib32-libatomic but it is not installable
Depends: lib32-libatomic-dev but it is not installable
Depends: lib32-libgcc but it is not installable
Depends: lib32-libgcc-dev but it is not installable
Depends: lib32-libsegfault but it is not installable
Depends: lib32-libstdc++ but it is not installable
Depends: lib32-libstdc++-dev but it is not installable
E: Unable to correct problems, you have held broken packages.


Other than u-boot I am not building any lib32- packages. In my image recipy
I have:
EXTRA_IMAGEDEPENDS += "lib32-u-boot"

In my conf file I have:
#multilib
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " lib32-libgcc"

Both lib32-packagegroup-core-standalone-sdk-target and packagegroup-core-
standalone-sdk-target can be found under deploy/deb/all, the packages should
probably be under deploy/deb/core2-32. Some are there, some I don't
recognize, but I have not idea why there are not installable.

Does anybody know what's wrong here? Is there a bug in the lib32 package
group?

Is there a way I can prevent this package group from being installed in the
sdk?

Thanks in advance!

--
Ferry Toth


[meta-security][PATCH 4/4] openssl-tpm-engine: add package

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
...ate-tpm-key-support-well-known-key-option.patch | 99 ++++++++
.../files/0002-libtpm-support-env-TPM_SRK_PW.patch | 80 +++++++
.../files/0003-Fix-not-building-libtpm.la.patch | 25 ++
...-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch | 254 +++++++++++++++++++++
...-tpm-engine-change-variable-c-type-from-c.patch | 34 +++
.../openssl-tpm-engine/openssl-tpm-engine_0.4.2.bb | 78 +++++++
6 files changed, 570 insertions(+)
create mode 100644 meta-tpm/recipes-tpm/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
create mode 100644 meta-tpm/recipes-tpm/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
create mode 100644 meta-tpm/recipes-tpm/openssl-tpm-engine/files/0003-Fix-not-building-libtpm.la.patch
create mode 100644 meta-tpm/recipes-tpm/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
create mode 100644 meta-tpm/recipes-tpm/openssl-tpm-engine/files/0004-tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch
create mode 100644 meta-tpm/recipes-tpm/openssl-tpm-engine/openssl-tpm-engine_0.4.2.bb

diff --git a/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
new file mode 100644
index 0000000..67071b6
--- /dev/null
+++ b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
@@ -0,0 +1,99 @@
+commit 16dac0cb7b73b8a7088300e45b98ac20819b03ed
+Author: Junxian.Xiao <Junxian.Xiao@windriver.com>
+Date: Wed Jun 19 18:57:13 2013 +0800
+
+support well-known password in openssl-tpm-engine.
+
+Add "-z" option to select well known password in create_tpm_key tool.
+
+Signed-off-by: Junxian.Xiao <Junxian.Xiao@windriver.com>
+
+diff --git a/create_tpm_key.c b/create_tpm_key.c
+index fee917f..7b94d62 100644
+--- a/create_tpm_key.c
++++ b/create_tpm_key.c
+@@ -46,6 +46,8 @@
+ #include <trousers/tss.h>
+ #include <trousers/trousers.h>
+
++#define TPM_WELL_KNOWN_KEY_LEN 20 /*well know key length is 20 bytes zero*/
++
+ #define print_error(a,b) \
+ fprintf(stderr, "%s:%d %s result: 0x%x (%s)\n", __FILE__, __LINE__, \
+ a, b, Trspi_Error_String(b))
+@@ -70,6 +72,7 @@ usage(char *argv0)
+ "\t\t-e|--enc-scheme encryption scheme to use [PKCSV15] or OAEP\n"
+ "\t\t-q|--sig-scheme signature scheme to use [DER] or SHA1\n"
+ "\t\t-s|--key-size key size in bits [2048]\n"
++ "\t\t-z|--zerokey use well known 20 bytes zero as SRK password.\n"
+ "\t\t-a|--auth require a password for the key [NO]\n"
+ "\t\t-p|--popup use TSS GUI popup dialogs to get the password "
+ "for the\n\t\t\t\t key [NO] (implies --auth)\n"
+@@ -147,6 +150,7 @@ int main(int argc, char **argv)
+ int asn1_len;
+ char *filename, c, *openssl_key = NULL;
+ int option_index, auth = 0, popup = 0, wrap = 0;
++ int wellknownkey = 0;
+ UINT32 enc_scheme = TSS_ES_RSAESPKCSV15;
+ UINT32 sig_scheme = TSS_SS_RSASSAPKCS1V15_DER;
+ UINT32 key_size = 2048;
+@@ -154,12 +158,15 @@ int main(int argc, char **argv)
+
+ while (1) {
+ option_index = 0;
+- c = getopt_long(argc, argv, "pe:q:s:ahw:",
++ c = getopt_long(argc, argv, "pe:q:s:zahw:",
+ long_options, &option_index);
+ if (c == -1)
+ break;
+
+ switch (c) {
++ case 'z':
++ wellknownkey = 1;
++ break;
+ case 'a':
+ initFlags |= TSS_KEY_AUTHORIZATION;
+ auth = 1;
+@@ -293,6 +300,8 @@ int main(int argc, char **argv)
+
+ if (srk_authusage) {
+ char *authdata = calloc(1, 128);
++ TSS_FLAG secretMode = TSS_SECRET_MODE_PLAIN;
++ int authlen = 0;
+
+ if (!authdata) {
+ fprintf(stderr, "malloc failed.\n");
+@@ -309,17 +318,26 @@ int main(int argc, char **argv)
+ exit(result);
+ }
+
+- if (EVP_read_pw_string(authdata, 128, "SRK Password: ", 0)) {
+- Tspi_Context_CloseObject(hContext, hKey);
+- Tspi_Context_Close(hContext);
+- free(authdata);
+- exit(result);
++ if (wellknownkey) {
++ memset(authdata, 0, TPM_WELL_KNOWN_KEY_LEN);
++ secretMode = TSS_SECRET_MODE_SHA1;
++ authlen = TPM_WELL_KNOWN_KEY_LEN;
++ }
++ else {
++ if (EVP_read_pw_string(authdata, 128, "SRK Password: ", 0)) {
++ Tspi_Context_CloseObject(hContext, hKey);
++ Tspi_Context_Close(hContext);
++ free(authdata);
++ exit(result);
++ }
++ secretMode = TSS_SECRET_MODE_PLAIN;
++ authlen = strlen(authdata);
+ }
+
+ //Set Secret
+ if ((result = Tspi_Policy_SetSecret(srkUsagePolicy,
+- TSS_SECRET_MODE_PLAIN,
+- strlen(authdata),
++ secretMode,
++ authlen,
+ (BYTE *)authdata))) {
+ print_error("Tspi_Policy_SetSecret", result);
+ free(authdata);
diff --git a/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
new file mode 100644
index 0000000..f718f2e
--- /dev/null
+++ b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
@@ -0,0 +1,80 @@
+commit 16dac0cb7b73b8a7088300e45b98ac20819b03ed
+Author: Junxian.Xiao <Junxian.Xiao@windriver.com>
+Date: Wed Jun 19 18:57:13 2013 +0800
+
+support reading SRK password from env TPM_SRK_PW
+
+Add "env TPM_SRK_PW=xxxx" to set password for libtpm.so. Specially,
+use "env TPM_SRK_PW=#WELLKNOWN#" to set well known password.
+
+Signed-off-by: Junxian.Xiao <Junxian.Xiao@windriver.com>
+
+diff --git a/e_tpm.c b/e_tpm.c
+index f3e8bcf..7dcb75a 100644
+--- a/e_tpm.c
++++ b/e_tpm.c
+@@ -38,6 +38,8 @@
+
+ #include "e_tpm.h"
+
++#define TPM_WELL_KNOWN_KEY_LEN 20 /*well know key length is 20 bytes zero*/
++
+ //#define DLOPEN_TSPI
+
+ #ifndef OPENSSL_NO_HW
+@@ -248,6 +250,10 @@ int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+ TSS_RESULT result;
+ UINT32 authusage;
+ BYTE *auth;
++ char *srkPasswd = NULL;
++ TSS_FLAG secretMode = secret_mode;
++ int authlen = 0;
++
+
+ if (hSRK != NULL_HKEY) {
+ DBGFN("SRK is already loaded.");
+@@ -299,18 +305,36 @@ int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+ return 0;
+ }
+
+- if (!tpm_engine_get_auth(ui, (char *)auth, 128, "SRK authorization: ",
+- cb_data)) {
+- Tspi_Context_CloseObject(hContext, hSRK);
+- free(auth);
+- TSSerr(TPM_F_TPM_LOAD_SRK, TPM_R_REQUEST_FAILED);
+- return 0;
++ srkPasswd = getenv("TPM_SRK_PW");
++ if (NULL != srkPasswd) {
++ if (0 == strcmp(srkPasswd, "#WELLKNOWN#")) {
++ memset(auth, 0, TPM_WELL_KNOWN_KEY_LEN);
++ secretMode = TSS_SECRET_MODE_SHA1;
++ authlen = TPM_WELL_KNOWN_KEY_LEN;
++ } else {
++ int authbuflen = 128;
++ memset(auth, 0, authbuflen);
++ strncpy(auth, srkPasswd, authbuflen-1);
++ secretMode = TSS_SECRET_MODE_PLAIN;
++ authlen = strlen(auth);
++ }
++ }
++ else {
++ if (!tpm_engine_get_auth(ui, (char *)auth, 128,
++ "SRK authorization: ", cb_data)) {
++ Tspi_Context_CloseObject(hContext, hSRK);
++ free(auth);
++ TSSerr(TPM_F_TPM_LOAD_SRK, TPM_R_REQUEST_FAILED);
++ return 0;
++ }
++ secretMode = secret_mode;
++ authlen = strlen(auth);
+ }
+
+ /* secret_mode is a global that may be set by engine ctrl
+ * commands. By default, its set to TSS_SECRET_MODE_PLAIN */
+- if ((result = Tspi_Policy_SetSecret(hSRKPolicy, secret_mode,
+- strlen((char *)auth), auth))) {
++ if ((result = Tspi_Policy_SetSecret(hSRKPolicy, secretMode,
++ authlen, auth))) {
+ Tspi_Context_CloseObject(hContext, hSRK);
+ free(auth);
+ TSSerr(TPM_F_TPM_LOAD_SRK, TPM_R_REQUEST_FAILED);
diff --git a/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0003-Fix-not-building-libtpm.la.patch b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0003-Fix-not-building-libtpm.la.patch
new file mode 100644
index 0000000..d24a150
--- /dev/null
+++ b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0003-Fix-not-building-libtpm.la.patch
@@ -0,0 +1,25 @@
+From 7848445a1f4c750ef73bf96f5e89d402f87a1756 Mon Sep 17 00:00:00 2001
+From: Lans Zhang <jia.zhang@windriver.com>
+Date: Mon, 19 Jun 2017 14:54:28 +0800
+Subject: [PATCH] Fix not building libtpm.la
+
+Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
+---
+ Makefile.am | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 6695656..634a7e6 100644
+--- a/Makefile.am
++++ b/Makefile.am
+@@ -10,4 +10,6 @@ libtpm_la_LIBADD=-lcrypto -lc -ltspi
+ libtpm_la_SOURCES=e_tpm.c e_tpm.h e_tpm_err.c
+
+ create_tpm_key_SOURCES=create_tpm_key.c
+-create_tpm_key_LDADD=-ltspi
++create_tpm_key_LDFLAGS=-ltspi
++
++LDADD=libtpm.la
+--
+2.7.5
+
diff --git a/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
new file mode 100644
index 0000000..a88148f
--- /dev/null
+++ b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
@@ -0,0 +1,254 @@
+From eb28ad92a2722fd30f8114840cf2b1ade26b80ee Mon Sep 17 00:00:00 2001
+From: Limeng <Meng.Li@windriver.com>
+Date: Fri, 23 Jun 2017 11:39:04 +0800
+Subject: [PATCH] tpm:openssl-tpm-engine:parse an encrypted tpm SRK password
+ from env
+
+Before, we support reading SRK password from env TPM_SRK_PW,
+but it is a plain password and not secure.
+So, we improve it and support to get an encrypted (AES algorithm)
+SRK password from env, and then parse it. The default decrypting
+AES password and salt is set in bb file.
+When we initialize TPM, and set a SRK pw, and then we need to
+encrypt it with the same AES password and salt by AES algorithm.
+At last, we set a env as below:
+export TPM_SRK_ENC_PW=xxxxxxxx
+"xxxxxxxx" is the encrypted SRK password for libtpm.so.
+
+Signed-off-by: Meng Li <Meng.Li@windriver.com>
+---
+ e_tpm.c | 157 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
+ e_tpm.h | 4 ++
+ e_tpm_err.c | 4 ++
+ 3 files changed, 164 insertions(+), 1 deletion(-)
+
+diff --git a/e_tpm.c b/e_tpm.c
+index 7dcb75a..11bf74b 100644
+--- a/e_tpm.c
++++ b/e_tpm.c
+@@ -245,6 +245,118 @@ void ENGINE_load_tpm(void)
+ ERR_clear_error();
+ }
+
++static int tpm_decode_base64(unsigned char *indata,
++ int in_len,
++ unsigned char *outdata,
++ int *out_len)
++{
++ int total_len, len, ret;
++ EVP_ENCODE_CTX dctx;
++
++ EVP_DecodeInit(&dctx);
++
++ total_len = 0;
++ ret = EVP_DecodeUpdate(&dctx, outdata, &len, indata, in_len);
++ if (ret < 0) {
++ TSSerr(TPM_F_TPM_DECODE_BASE64, TPM_R_DECODE_BASE64_FAILED);
++ return 1;
++ }
++
++ total_len += len;
++ ret = EVP_DecodeFinal(&dctx, outdata, &len);
++ if (ret < 0) {
++ TSSerr(TPM_F_TPM_DECODE_BASE64, TPM_R_DECODE_BASE64_FAILED);
++ return 1;
++ }
++ total_len += len;
++
++ *out_len = total_len;
++
++ return 0;
++}
++
++static int tpm_decrypt_srk_pw(unsigned char *indata, int in_len,
++ unsigned char *outdata,
++ int *out_len)
++{
++ int dec_data_len, dec_data_lenfinal;
++ unsigned char dec_data[256];
++ unsigned char *aes_pw;
++ unsigned char aes_salt[PKCS5_SALT_LEN];
++ unsigned char key[EVP_MAX_KEY_LENGTH], iv[EVP_MAX_IV_LENGTH];
++ const EVP_CIPHER *cipher = NULL;
++ const EVP_MD *dgst = NULL;
++ EVP_CIPHER_CTX *ctx = NULL;
++
++ if (sizeof(SRK_DEC_SALT) - 1 > PKCS5_SALT_LEN) {
++ TSSerr(TPM_F_TPM_DECRYPT_SRK_PW, TPM_R_DECRYPT_SRK_PW_FAILED);
++ return 1;
++ }
++
++ aes_pw = malloc(sizeof(SRK_DEC_PW) - 1);
++ if (aes_pw == NULL) {
++ TSSerr(TPM_F_TPM_DECRYPT_SRK_PW, TPM_R_DECRYPT_SRK_PW_FAILED);
++ return 1;
++ }
++
++ memset(aes_salt, 0x00, sizeof(aes_salt));
++ memcpy(aes_pw, SRK_DEC_PW, sizeof(SRK_DEC_PW) - 1);
++ memcpy(aes_salt, SRK_DEC_SALT, sizeof(SRK_DEC_SALT) - 1);
++
++ cipher = EVP_get_cipherbyname("aes-128-cbc");
++ if (cipher == NULL) {
++ TSSerr(TPM_F_TPM_DECRYPT_SRK_PW, TPM_R_DECRYPT_SRK_PW_FAILED);
++ free(aes_pw);
++ return 1;
++ }
++ dgst = EVP_sha256();
++
++ EVP_BytesToKey(cipher, dgst, aes_salt, (unsigned char *)aes_pw, sizeof(SRK_DEC_PW) - 1, 1, key, iv);
++
++ ctx = EVP_CIPHER_CTX_new();
++ /* Don't set key or IV right away; we want to check lengths */
++ if (!EVP_CipherInit_ex(ctx, cipher, NULL, NULL, NULL, 0)) {
++ TSSerr(TPM_F_TPM_DECRYPT_SRK_PW, TPM_R_DECRYPT_SRK_PW_FAILED);
++ free(aes_pw);
++ return 1;
++ }
++
++ OPENSSL_assert(EVP_CIPHER_CTX_key_length(ctx) == 16);
++ OPENSSL_assert(EVP_CIPHER_CTX_iv_length(ctx) == 16);
++
++ if (!EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, 0)) {
++ TSSerr(TPM_F_TPM_DECRYPT_SRK_PW, TPM_R_DECRYPT_SRK_PW_FAILED);
++ free(aes_pw);
++ return 1;
++ }
++
++ if (!EVP_CipherUpdate(ctx, dec_data, &dec_data_len, indata, in_len)) {
++ /* Error */
++ TSSerr(TPM_F_TPM_DECRYPT_SRK_PW, TPM_R_DECRYPT_SRK_PW_FAILED);
++ free(aes_pw);
++ EVP_CIPHER_CTX_free(ctx);
++ return 1;
++ }
++
++ if (!EVP_CipherFinal_ex(ctx, dec_data + dec_data_len, &dec_data_lenfinal)) {
++ /* Error */
++ TSSerr(TPM_F_TPM_DECRYPT_SRK_PW, TPM_R_DECRYPT_SRK_PW_FAILED);
++ free(aes_pw);
++ EVP_CIPHER_CTX_free(ctx);
++ return 1;
++ }
++
++ dec_data_len = dec_data_len + dec_data_lenfinal;
++
++ memcpy(outdata, dec_data, dec_data_len);
++ *out_len = dec_data_len;
++
++ free(aes_pw);
++ EVP_CIPHER_CTX_free(ctx);
++
++ return 0;
++}
++
+ int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+ {
+ TSS_RESULT result;
+@@ -305,8 +417,50 @@ int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+ return 0;
+ }
+
+- srkPasswd = getenv("TPM_SRK_PW");
++ srkPasswd = getenv("TPM_SRK_ENC_PW");
+ if (NULL != srkPasswd) {
++ int in_len = strlen(srkPasswd);
++ int out_len;
++ unsigned char *out_buf;
++
++ if (!in_len || in_len % 4) {
++ Tspi_Context_CloseObject(hContext, hSRK);
++ free(auth);
++ TSSerr(TPM_F_TPM_LOAD_SRK, TPM_R_REQUEST_FAILED);
++ return 0;
++ }
++
++ out_len = in_len * 3 / 4;
++ out_buf = malloc(out_len);
++ if (NULL == out_buf) {
++ Tspi_Context_CloseObject(hContext, hSRK);
++ free(auth);
++ TSSerr(TPM_F_TPM_LOAD_SRK, TPM_R_REQUEST_FAILED);
++ return 0;
++ }
++
++ if (tpm_decode_base64(srkPasswd, strlen(srkPasswd),
++ out_buf, &out_len)) {
++ Tspi_Context_CloseObject(hContext, hSRK);
++ free(auth);
++ free(out_buf);
++ TSSerr(TPM_F_TPM_LOAD_SRK, TPM_R_REQUEST_FAILED);
++ return 0;
++ }
++
++ if (tpm_decrypt_srk_pw(out_buf, out_len,
++ auth, &authlen)) {
++ Tspi_Context_CloseObject(hContext, hSRK);
++ free(auth);
++ free(out_buf);
++ TSSerr(TPM_F_TPM_LOAD_SRK, TPM_R_REQUEST_FAILED);
++ return 0;
++ }
++ secretMode = TSS_SECRET_MODE_PLAIN;
++ free(out_buf);
++ }
++#ifdef TPM_SRK_PLAIN_PW
++ else if (NULL != (srkPasswd = getenv("TPM_SRK_PW")) {
+ if (0 == strcmp(srkPasswd, "#WELLKNOWN#")) {
+ memset(auth, 0, TPM_WELL_KNOWN_KEY_LEN);
+ secretMode = TSS_SECRET_MODE_SHA1;
+@@ -319,6 +473,7 @@ int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+ authlen = strlen(auth);
+ }
+ }
++#endif
+ else {
+ if (!tpm_engine_get_auth(ui, (char *)auth, 128,
+ "SRK authorization: ", cb_data)) {
+diff --git a/e_tpm.h b/e_tpm.h
+index 6316e0b..56ff202 100644
+--- a/e_tpm.h
++++ b/e_tpm.h
+@@ -66,6 +66,8 @@ void ERR_TSS_error(int function, int reason, char *file, int line);
+ #define TPM_F_TPM_FILL_RSA_OBJECT 116
+ #define TPM_F_TPM_ENGINE_GET_AUTH 117
+ #define TPM_F_TPM_CREATE_SRK_POLICY 118
++#define TPM_F_TPM_DECODE_BASE64 119
++#define TPM_F_TPM_DECRYPT_SRK_PW 120
+
+ /* Reason codes. */
+ #define TPM_R_ALREADY_LOADED 100
+@@ -96,6 +98,8 @@ void ERR_TSS_error(int function, int reason, char *file, int line);
+ #define TPM_R_ID_INVALID 125
+ #define TPM_R_UI_METHOD_FAILED 126
+ #define TPM_R_UNKNOWN_SECRET_MODE 127
++#define TPM_R_DECODE_BASE64_FAILED 128
++#define TPM_R_DECRYPT_SRK_PW_FAILED 129
+
+ /* structure pointed to by the RSA object's app_data pointer */
+ struct rsa_app_data
+diff --git a/e_tpm_err.c b/e_tpm_err.c
+index 25a5d0f..439e267 100644
+--- a/e_tpm_err.c
++++ b/e_tpm_err.c
+@@ -235,6 +235,8 @@ static ERR_STRING_DATA TPM_str_functs[] = {
+ {ERR_PACK(0, TPM_F_TPM_BIND_FN, 0), "TPM_BIND_FN"},
+ {ERR_PACK(0, TPM_F_TPM_FILL_RSA_OBJECT, 0), "TPM_FILL_RSA_OBJECT"},
+ {ERR_PACK(0, TPM_F_TPM_ENGINE_GET_AUTH, 0), "TPM_ENGINE_GET_AUTH"},
++ {ERR_PACK(0, TPM_F_TPM_DECODE_BASE64, 0), "TPM_DECODE_BASE64"},
++ {ERR_PACK(0, TPM_F_TPM_DECRYPT_SRK_PW, 0), "TPM_DECRYPT_SRK_PW"},
+ {0, NULL}
+ };
+
+@@ -265,6 +267,8 @@ static ERR_STRING_DATA TPM_str_reasons[] = {
+ {TPM_R_FILE_READ_FAILED, "failed reading the key file"},
+ {TPM_R_ID_INVALID, "engine id doesn't match"},
+ {TPM_R_UI_METHOD_FAILED, "ui function failed"},
++ {TPM_R_DECODE_BASE64_FAILED, "decode base64 failed"},
++ {TPM_R_DECRYPT_SRK_PW_FAILED, "decrypt srk password failed"},
+ {0, NULL}
+ };
+
+--
+2.9.3
+
diff --git a/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0004-tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0004-tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch
new file mode 100644
index 0000000..076704d
--- /dev/null
+++ b/meta-tpm/recipes-tpm/openssl-tpm-engine/files/0004-tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch
@@ -0,0 +1,34 @@
+From fb44e2814fd819c086f9a4c925427f89c0e8cec6 Mon Sep 17 00:00:00 2001
+From: Limeng <Meng.Li@windriver.com>
+Date: Fri, 21 Jul 2017 16:32:02 +0800
+Subject: [PATCH] tpm:openssl-tpm-engine: change variable c type from char
+ into int
+
+refer to getopt_long() function definition, its return value type is
+int. So, change variable c type from char into int.
+On arm platform, when getopt_long() calling fails, if we define c as
+char type, its value will be 255, not -1. This will cause code enter
+wrong case.
+
+Signed-off-by: Meng Li <Meng.Li@windriver.com>
+---
+ create_tpm_key.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/create_tpm_key.c b/create_tpm_key.c
+index 7b94d62..f30af90 100644
+--- a/create_tpm_key.c
++++ b/create_tpm_key.c
+@@ -148,7 +148,8 @@ int main(int argc, char **argv)
+ ASN1_OCTET_STRING *blob_str;
+ unsigned char *blob_asn1 = NULL;
+ int asn1_len;
+- char *filename, c, *openssl_key = NULL;
++ char *filename, *openssl_key = NULL;
++ int c;
+ int option_index, auth = 0, popup = 0, wrap = 0;
+ int wellknownkey = 0;
+ UINT32 enc_scheme = TSS_ES_RSAESPKCSV15;
+--
+1.7.9.5
+
diff --git a/meta-tpm/recipes-tpm/openssl-tpm-engine/openssl-tpm-engine_0.4.2.bb b/meta-tpm/recipes-tpm/openssl-tpm-engine/openssl-tpm-engine_0.4.2.bb
new file mode 100644
index 0000000..4854f70
--- /dev/null
+++ b/meta-tpm/recipes-tpm/openssl-tpm-engine/openssl-tpm-engine_0.4.2.bb
@@ -0,0 +1,78 @@
+DESCRIPTION = "OpenSSL secure engine based on TPM hardware"
+HOMEPAGE = "https://sourceforge.net/projects/trousers/"
+SECTION = "security/tpm"
+
+LICENSE = "openssl"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=11f0ee3af475c85b907426e285c9bb52"
+
+DEPENDS += "openssl trousers"
+
+SRC_URI = "\
+ git://git.code.sf.net/p/trousers/openssl_tpm_engine \
+ file://0001-create-tpm-key-support-well-known-key-option.patch \
+ file://0002-libtpm-support-env-TPM_SRK_PW.patch \
+ file://0003-Fix-not-building-libtpm.la.patch \
+ file://0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch \
+ file://0004-tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch \
+"
+SRCREV = "bbc2b1af809f20686e0d3553a62f0175742c0d60"
+
+S = "${WORKDIR}/git"
+
+inherit autotools-brokensep
+
+# The definitions below are used to decrypt the srk password.
+# It is allowed to define the values in 3 forms: string, hex number and
+# the hybrid, e.g,
+# srk_dec_pw = "incendia"
+# srk_dec_pw = "\x69\x6e\x63\x65\x6e\x64\x69\x61"
+# srk_dec_pw = "\x1""nc""\x3""nd""\x1""a"
+#
+# Due to the limit of escape character, the hybrid must be written in
+# above style. The actual values defined below in C code style are:
+# srk_dec_pw[] = { 0x01, 'n', 'c', 0x03, 'n', 'd', 0x01, 'a' };
+# srk_dec_salt[] = { 'r', 0x00, 0x00, 't' };
+srk_dec_pw ?= "\\"\\\x1\\"\\"nc\\"\\"\\\x3\\"\\"nd\\"\\"\\\x1\\"\\"a\\""
+srk_dec_salt ?= "\\"r\\"\\"\\\x00\\\x00\\"\\"t\\""
+
+CFLAGS_append += "-DSRK_DEC_PW=${srk_dec_pw} -DSRK_DEC_SALT=${srk_dec_salt}"
+
+# Uncomment below line if using the plain srk password for development
+#CFLAGS_append += "-DTPM_SRK_PLAIN_PW"
+
+do_configure_prepend() {
+ cd "${S}"
+ cp LICENSE COPYING
+ touch NEWS AUTHORS ChangeLog
+}
+
+do_install_append() {
+ install -m 0755 -d "${D}${libdir}/engines"
+ install -m 0755 -d "${D}${prefix}/local/ssl/lib/engines"
+ install -m 0755 -d "${D}${libdir}/ssl/engines"
+
+ cp -f "${D}${libdir}/openssl/engines/libtpm.so.0.0.0" "${D}${libdir}/libtpm.so.0"
+ cp -f "${D}${libdir}/openssl/engines/libtpm.so.0.0.0" "${D}${libdir}/engines/libtpm.so"
+ cp -f "${D}${libdir}/openssl/engines/libtpm.so.0.0.0" "${D}${prefix}/local/ssl/lib/engines/libtpm.so"
+ mv -f "${D}${libdir}/openssl/engines/libtpm.so.0.0.0" "${D}${libdir}/ssl/engines/libtpm.so"
+ mv -f "${D}${libdir}/openssl/engines/libtpm.la" "${D}${libdir}/ssl/engines/libtpm.la"
+ rm -rf "${D}${libdir}/openssl"
+}
+
+FILES_${PN}-staticdev += "${libdir}/ssl/engines/libtpm.la"
+FILES_${PN}-dbg += "\
+ ${libdir}/ssl/engines/.debug \
+ ${libdir}/engines/.debug \
+ ${prefix}/local/ssl/lib/engines/.debug \
+"
+FILES_${PN} += "\
+ ${libdir}/ssl/engines/libtpm.so* \
+ ${libdir}/engines/libtpm.so* \
+ ${libdir}/libtpm.so* \
+ ${prefix}/local/ssl/lib/engines/libtpm.so* \
+"
+
+RDEPENDS_${PN} += "libcrypto libtspi"
+
+INSANE_SKIP_${PN} = "libdir"
+INSANE_SKIP_${PN}-dbg = "libdir"
--
2.7.4


[meta-security][PATCH 3/4] tpm2-abrmd: add package

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../tpm2-abrmd/files/tpm2-abrmd-init.sh | 65 ++++++++++++++++++++++
.../tpm2-abrmd/files/tpm2-abrmd.default | 1 +
.../recipes-tpm/tpm2-abrmd/tpm2-abrmd_1.1.1.bb | 54 ++++++++++++++++++
3 files changed, 120 insertions(+)
create mode 100644 meta-tpm/recipes-tpm/tpm2-abrmd/files/tpm2-abrmd-init.sh
create mode 100644 meta-tpm/recipes-tpm/tpm2-abrmd/files/tpm2-abrmd.default
create mode 100644 meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_1.1.1.bb

diff --git a/meta-tpm/recipes-tpm/tpm2-abrmd/files/tpm2-abrmd-init.sh b/meta-tpm/recipes-tpm/tpm2-abrmd/files/tpm2-abrmd-init.sh
new file mode 100644
index 0000000..c8dfb7d
--- /dev/null
+++ b/meta-tpm/recipes-tpm/tpm2-abrmd/files/tpm2-abrmd-init.sh
@@ -0,0 +1,65 @@
+#!/bin/sh
+
+### BEGIN INIT INFO
+# Provides: tpm2-abrmd
+# Required-Start: $local_fs $remote_fs $network
+# Required-Stop: $local_fs $remote_fs $network
+# Should-Start:
+# Should-Stop:
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: starts tpm2-abrmd
+# Description: tpm2-abrmd implements the TCG resource manager
+### END INIT INFO
+
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+DAEMON=/usr/sbin/tpm2-abrmd
+NAME=tpm2-abrmd
+DESC="TCG TSS2 Access Broker and Resource Management daemon"
+USER="tss"
+
+test -x "${DAEMON}" || exit 0
+
+# Read configuration variable file if it is present
+[ -r /etc/default/$NAME ] && . /etc/default/$NAME
+
+case "${1}" in
+ start)
+ echo -n "Starting $DESC: "
+
+ if [ ! -e /dev/tpm* ]
+ then
+ echo "device driver not loaded, skipping."
+ exit 0
+ fi
+
+ start-stop-daemon --start --quiet --oknodo --background --pidfile /var/run/${NAME}.pid --user ${USER} --chuid ${USER} --exec ${DAEMON} -- ${DAEMON_OPTS}
+ RETVAL="$?"
+ echo "$NAME."
+ [ "$RETVAL" = 0 ] && pidof $DAEMON > /var/run/${NAME}.pid
+ exit $RETVAL
+ ;;
+
+ stop)
+ echo -n "Stopping $DESC: "
+
+ start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/${NAME}.pid --user ${USER} --exec ${DAEMON}
+ RETVAL="$?"
+ echo "$NAME."
+ rm -f /var/run/${NAME}.pid
+ exit $RETVAL
+ ;;
+
+ restart|force-reload)
+ "${0}" stop
+ sleep 1
+ "${0}" start
+ exit $?
+ ;;
+ *)
+ echo "Usage: ${NAME} {start|stop|restart|force-reload|status}" >&2
+ exit 3
+ ;;
+esac
+
+exit 0
diff --git a/meta-tpm/recipes-tpm/tpm2-abrmd/files/tpm2-abrmd.default b/meta-tpm/recipes-tpm/tpm2-abrmd/files/tpm2-abrmd.default
new file mode 100644
index 0000000..987978a
--- /dev/null
+++ b/meta-tpm/recipes-tpm/tpm2-abrmd/files/tpm2-abrmd.default
@@ -0,0 +1 @@
+DAEMON_OPTS="--tcti=device --logger=syslog --max-connections=20 --max-transient-objects=20 --fail-on-loaded-trans"
diff --git a/meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_1.1.1.bb b/meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_1.1.1.bb
new file mode 100644
index 0000000..27e2408
--- /dev/null
+++ b/meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_1.1.1.bb
@@ -0,0 +1,54 @@
+SUMMARY = "TPM2 Access Broker & Resource Manager"
+DESCRIPTION = "This is a system daemon implementing the TPM2 access \
+broker (TAB) & Resource Manager (RM) spec from the TCG. The daemon (tpm2-abrmd) \
+is implemented using Glib and the GObject system. In this documentation and \
+in the code we use `tpm2-abrmd` and `tabrmd` interchangeably. \
+"
+SECTION = "security/tpm"
+
+LICENSE = "BSD-2-Clause"
+LIC_FILES_CHKSUM = "file://${S}/LICENSE;md5=500b2e742befc3da00684d8a1d5fd9da"
+
+DEPENDS += "autoconf-archive dbus glib-2.0 pkgconfig tpm2.0-tss glib-2.0-native"
+
+SRC_URI = "\
+ git://github.com/01org/tpm2-abrmd.git \
+ file://tpm2-abrmd-init.sh \
+ file://tpm2-abrmd.default \
+"
+SRCREV = "c2ccda956bf15165770682dd5c578c58ee5fa6e2"
+
+S = "${WORKDIR}/git"
+
+inherit autotools pkgconfig systemd update-rc.d useradd
+
+SYSTEMD_PACKAGES += "${PN}"
+SYSTEMD_SERVICE_${PN} = "tpm2-abrmd.service"
+SYSTEMD_AUTO_ENABLE_${PN} = "disable"
+
+INITSCRIPT_NAME = "${PN}"
+INITSCRIPT_PARAMS = "start 99 2 3 4 5 . stop 19 0 1 6 ."
+
+USERADD_PACKAGES = "${PN}"
+GROUPADD_PARAM_${PN} = "tss"
+USERADD_PARAM_${PN} = "--system -M -d /var/lib/tpm -s /bin/false -g tss tss"
+
+PACKAGECONFIG ?="udev"
+PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd', '', d)}"
+
+PACKAGECONFIG[systemd] = "--with-systemdsystemunitdir=${systemd_system_unitdir}, --with-systemdsystemunitdir=no"
+PACKAGECONFIG[udev] = "--with-udevrulesdir=${sysconfdir}/udev/rules.d, --without-udevrulesdir"
+
+do_install_append() {
+ install -d "${D}${sysconfdir}/init.d"
+ install -m 0755 "${WORKDIR}/tpm2-abrmd-init.sh" "${D}${sysconfdir}/init.d/tpm2-abrmd"
+
+ install -d "${D}${sysconfdir}/default"
+ install -m 0644 "${WORKDIR}/tpm2-abrmd.default" "${D}${sysconfdir}/default/tpm2-abrmd"
+}
+
+FILES_${PN} += "${libdir}/systemd/system-preset"
+
+RDEPENDS_${PN} += "libgcc dbus-glib libtss2 libtctidevice libtctisocket"
+
+BBCLASSEXTEND = "native"
--
2.7.4


[meta-security][PATCH 2/4] tpm-quote-tools: Add package

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../tpm-quote-tools/tpm-quote-tools_1.0.4.bb | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 meta-tpm/recipes-tpm/tpm-quote-tools/tpm-quote-tools_1.0.4.bb

diff --git a/meta-tpm/recipes-tpm/tpm-quote-tools/tpm-quote-tools_1.0.4.bb b/meta-tpm/recipes-tpm/tpm-quote-tools/tpm-quote-tools_1.0.4.bb
new file mode 100644
index 0000000..8486d00
--- /dev/null
+++ b/meta-tpm/recipes-tpm/tpm-quote-tools/tpm-quote-tools_1.0.4.bb
@@ -0,0 +1,23 @@
+SUMMARY = "The TPM Quote Tools is a collection of programs that provide support \
+ for TPM based attestation using the TPM quote mechanism. \
+ "
+DESCRIPTION = "The TPM Quote Tools is a collection of programs that provide support \
+ for TPM based attestation using the TPM quote mechanism. The manual \
+ page for tpm_quote_tools provides a usage overview. \
+ \
+ TPM Quote Tools has been tested with TrouSerS on Linux and NTRU on \
+ Windows XP. It was ported to Windows using MinGW and MSYS. \
+ "
+HOMEPAGE = "https://sourceforge.net/projects/tpmquotetools/"
+SECTION = "security/tpm"
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://COPYING;md5=8ec30b01163d242ecf07d9cd84e3611f"
+
+DEPENDS = "libtspi tpm-tools"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/tpmquotetools/${PV}/${BP}.tar.gz"
+
+SRC_URI[md5sum] = "6e194f5bc534301bbaef53dc6d22c233"
+SRC_URI[sha256sum] = "10dc4eade02635557a9496b388360844cd18e7864e2eb882f5e45ab2fa405ae2"
+
+inherit autotools
--
2.7.4


[meta-security][PATCH 1/4] pcr-extend: add new package

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-tpm/recipes-tpm/pcr-extend/pcr-extend_git.bb | 25 +++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 meta-tpm/recipes-tpm/pcr-extend/pcr-extend_git.bb

diff --git a/meta-tpm/recipes-tpm/pcr-extend/pcr-extend_git.bb b/meta-tpm/recipes-tpm/pcr-extend/pcr-extend_git.bb
new file mode 100644
index 0000000..0cc4f63
--- /dev/null
+++ b/meta-tpm/recipes-tpm/pcr-extend/pcr-extend_git.bb
@@ -0,0 +1,25 @@
+SUMMARY = "Command line utility to extend hash of arbitrary data into a TPMs PCR."
+HOMEPAGE = "https://github.com/flihp/pcr-extend"
+SECTION = "security/tpm"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+DEPENDS = "libtspi"
+
+PV = "0.1+git${SRCPV}"
+SRCREV = "c02ad8f628b3d99f6d4c087b402fe31a40ee6316"
+
+SRC_URI = "git://github.com/flihp/pcr-extend.git "
+
+inherit autotools
+
+S = "${WORKDIR}/git"
+
+do_compile() {
+ oe_runmake -C ${S}/src
+}
+
+do_install() {
+ install -d ${D}${bindir}
+ oe_runmake -C ${S}/src DESTDIR="${D}" install
+}
--
2.7.4


Re: u-boot recipe: Missing dependencies

Eric Schwarz
 

Hi Ross,

DEPENDS += "bc-native dtc-native"
+DEPENDS_append = " python-native"
+DEPENDS_append_x86-64 = " iasl-native swig-native"
Don't _append when you can just extend the assignment above.
I just did it that way for the moment since I wanted to circumvent merge
conflicts when I upgrade the underlying recipes from openembedded.

Depending on python-native does nothing as the binary isn't in $PATH still.
I thought any Yocto native binaries built are in the PATH automatically. - How
to fix this/do it correctly?

Can you provide a configuration to make U-Boot build on x86 for testing?
I put now some patches in ordered manner on top of the original recipes from
openembedded.
However, before sending I would like to fix two issues so the recipes can go
into mainline immediately.

1.) I am working w/ -morty Yocto branch at the moment. The 'u-boot.inc' from
openembedded does not work w/ -morty.
I get the following error "AttributeError: module 'bb.utils' has no
attribute 'filter'". Building w/ the original -morty 'u-boot.inc' works.
2.) There is an issue w/ the U-Boot build system that it needs the "libgcc.a"
from the local host system [1]. I circumvented this by checking in my
"libgcc.a" and patching the U-Boot makefile accordingly. This must be
fixed in U-boot.

[1]... https://www.mail-archive.com/yocto@yoctoproject.org/msg36721.html

Cheers
Eric


Solved : Re: Problems building U-Boot for x86_64

Ferry Toth <ftoth@...>
 

Op Fri, 25 Aug 2017 22:30:42 +0000, schreef Ferry Toth:

Op Fri, 25 Aug 2017 21:22:40 +0200, schreef Ferry Toth:

Khem Raj wrote:




On 8/23/17 3:40 PM, Ferry Toth wrote:
Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj:

On 8/23/17 2:29 PM, Ferry Toth wrote:
Ferry Toth wrote:

Khem Raj wrote:

On 8/22/17 11:41 PM, Ferry Toth wrote:
I am having trouble building a specific U-Boot version with
Yocto. Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it
builds fine.

I am extending meta-intel-edison to build a 64 bit Poke Morty,
with a vanilla 64-bit kernel (4.12). This is working quite well.

My host is x86_64, the target is core2 with tune=core-64.

Without 64bit tune I can build U-Boot fine. With 64bit it can
not link, appearently because it needs lbgcc.a
what is exact error message ? is it while compiling host bits or
target bits ?
The failing line is:
x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m
elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3
--wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic
--no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds
arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o
arch/x86/lib/built-in.o board/intel/edison/built-in.o
cmd/built-in.o common/built-in.o disk/built-in.o
drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o
drivers/i2c/built-in.o drivers/mmc/built-in.o
drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o
drivers/mtd/spi/built- in.o drivers/net/built-in.o
drivers/net/phy/built-in.o drivers/pci/built- in.o
drivers/power/built-in.o drivers/power/battery/built-in.o
drivers/power/domain/built-in.o
drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o
drivers/power/pmic/built-in.o drivers/power/regulator/built-in.o
drivers/serial/built-in.o drivers/spi/built-in.o
drivers/usb/common/built-in.o drivers/usb/dwc3/built- in.o
drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o
drivers/usb/gadget/built-in.o drivers/usb/gadget/udc/built-in.o
drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o
drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o
drivers/usb/ulpi/built-in.o dts/built-in.o fs/built-in.o
lib/built-in.o net/built-in.o test/built-in.o test/dm/built-in.o
--end-group arch/x86/lib/lib.a -Map u-boot.map ERROR: oe_runmake
failed arch/x86/lib/built-in.o: In function `__wrap___udivdi3':
/home/ferry/tmp/edison-intel/my/edison-
morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
v2017.03-
r0/git/arch/x86/lib/gcc.c:25: undefined reference to
`__normal___udivdi3'
I as believe the missing lib is libgcc.a I just my sysroot and
found it here:
the linker cmdline above does not link with libgcc and there might
be a good reason for that, many standalone applications dont link
with libgcc intentionally. You could look into the code and see if
it can be written differently such that gcc does not have to invoke
a helper function from gcc runtime. Another option is to link with
libgcc explicitly
If change my setup to build for a 32bit target, it build u-boot
without error.
compiler may not be generating calls for the missing function.

When I build the same git outside yocto on 64bit with multilib
installed it also builds without error. In that case the make command
would be: make -j8 edison_defconfig
same is possible. Can you do readelf -sW gcc.o and see if there is a
undefined reference to __normal___udivdi3
20: 00000000 22 FUNC GLOBAL HIDDEN 4 __wrap___divdi3 21:
00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___divdi3 22:
00000000 22 FUNC GLOBAL HIDDEN 6 __wrap___udivdi3 23:
00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___udivdi3 24:
00000000 22 FUNC GLOBAL HIDDEN 8 __wrap___moddi3 25:
00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___moddi3 26:
00000000 22 FUNC GLOBAL HIDDEN 10 __wrap___umoddi3 27:
00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___umoddi3
AFAIKT when building for a 32-bit target is only that U-Boot makefile is
called with CROSS_COMPILE=i686-poky-linux- CC=i686-poky-linux-gcc
instead of CROSS_COMPILE=x86_64-poky-linux- CC=x86_64-poky-linux-gcc.

Result from readelf -sW gcc.o built wuth i686:

20: 00000000 27 FUNC GLOBAL HIDDEN 4 __wrap___divdi3 21:
00000000 0 NOTYPE GLOBAL DEFAULT UND __normal___divdi3 22:
00000000 27 FUNC GLOBAL HIDDEN 6 __wrap___udivdi3 23: 00000000
0 NOTYPE GLOBAL DEFAULT UND __normal___udivdi3 24: 00000000 27
FUNC GLOBAL HIDDEN 8 __wrap___moddi3 25: 00000000 0 NOTYPE
GLOBAL DEFAULT UND __normal___moddi3 26: 00000000 27 FUNC GLOBAL
HIDDEN 10 __wrap___umoddi3 27: 00000000 0 NOTYPE GLOBAL DEFAULT
UND __normal___umoddi3

The path to libs and incs is the same (x86_64...) and I can't find any
libgcc.a there. Still it links in this case.

Maybe in the 64-bit case I need to add i686-poky-linux-gcc to native and
modify the recipe to use that?


My conclusion: I have some bb variable set to the wrong value or I
need to get multilib installed into /..../sysroots/x86_64-linux/lib.

So how to do that?

sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/
sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32-
linux/6.2.0/
sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/
sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/

How compile log shows:
NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
CC=x86_64-poky-linux-gcc --sysroot=/..../sysroots/edison V=1
HOSTCC=gcc -isystem/..../sysroots/x86_64-linux/usr/include -O2
-pipe -L/..../sysroots/x86_64-linux/usr/lib
-L/..../sysroots/x86_64-linux/lib
-Wl,-rpath-link,/..../sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/..../sysroots/x86_64-linux/lib
-Wl,-rpath,/..../sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/..../sysroots/x86_64-linux/lib -Wl,-O1 -C
/..../out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
v2017.03-r0/git
O=/..../out/linux64/build/tmp/work/edison-poky-linux/u-
boot/edison-v2017.03-r0/build edison_defconfig

(.... my edits to shorten the uninteresting part of the path)

I would think: --sysroot points to /edison dir which actually
contains libgcc.a, but -i, _l and -W1 options point to host dirs
that don't have the lib.


I attempted to add multilib, but although that immediately
exposed bugs in other recipes but actually adds libgcc.a, it
does that for the target sysroot only.

And for some reason, U-Boot is built with the native gcc
(x86_64-linux),
and multilib does not add libgcc.a to that sysroot.

So, how do I add multilib to -native sysroot, preferably only to
-native and not to the target, as the target has not further use
for it?

Strangest thing is in u-boot.inc there is:
EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX}
CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}" V=1'
EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
${BUILD_LDFLAGS}"'

But when I check my log file:
NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
CC=x86_64-poky-linux- gcc ......

So TARGET_PREFIX resolves to x86_64-poky-linux, but I think my
target is core2_64 (or something like that). Is that normal for
U-Boot?
thats ok.


I am a little lost, so any help would be greatly appreciated
I added multilib to the meta0intel-edison-bsp machine conf:
#multilib
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " lib32-libgcc"

This exposes a lot recipy bugs in other places that needed to be fixed
first.

Then I changed IMAGE_INSTALL += "u-boot" to "lib32_u-boot". Now it builds
without error.

Now I changed IMAGE_INSTALL tot EXTRA_IMAGEDEPENDS. I believe that will
prevent u-boot and the otherwise unecessary multilib to be installed on
the image. Not sure if that really works out as I hope.

All of this now causes populate_sdk to fail, but I will post that
seperately.

Thanks all for the usefull comments.

Ferry

--

--
--


Re: pkg-config search directories

eliya.mir@gmail.com <eliya.mir@...>
 

Hi Ross, 
I am still trying to configure pkg-config. 

Running bitbake glmark2 recipe results with an error :  
Checking for 'gl'                        : not found.

looking into the log file : 
Checking for 'gl'
['/home/wzbwjj/vpm/GR_Yocto/build/tmp/sysroots/x86_64-linux/usr/bin/pkg-config', 'gl', '--cflags', '--libs']
err: Package gl was not found in the pkg-config search path.
Perhaps you should add the directory containing `gl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gl' found

not found
from /home/wzbwjj/vpm/GR_Yocto/build/tmp/work/corei7-64-poky-linux/glmark2/2014.03+AUTOINC+fa71af2dfa-r0/git: The configuration failed


Thanks!



On Tue, Oct 3, 2017 at 6:40 PM, Burton, Ross <ross.burton@...> wrote:
On 3 October 2017 at 16:36, eliya.mir@... <eliya.mir@...> wrote:
Thanks Ross, 
That is the issue : default pkg-config does not search host paths - How to edit its search paths ? 

"If you *really* want to link against host binaries and not building your own native recipes for it then see qemu.inc for an example of how to steal the host pkg-config path and use it at configure time."

Ross


Re: [meta-rockchip] The various rockchip layers

Mirza Krak <mirza.krak@...>
 

2017-10-08 5:39 GMT+02:00 Trevor Woerner <twoerner@gmail.com>:
On Sat, Oct 7, 2017 at 7:03 PM, Mirza Krak <mirza.krak@gmail.com> wrote:
Thank you for taking the time and explaining the current and previous
state. It is highly appreciated.


As I started digging to check the current state of the different
layers it was quite clear to me that there where two different sets.
One is maintained by Rockchip [1] and the other one by the community
[2].
Don't forget https://github.com/jackmitch/meta-tinker ;-)
Yeah, noticed that one. Neat little layer that the meta-rockchip
should try and consume :).


And it made sense to me initially. I do not know the full background
story with the Rockchip layers (would be nice if someone could tell it
:)) on what the intent was with "community" Rockchip layers.
Romain started meta-rockchip initially, then I joined, then people
from Rockchip joined later.
Ok, that explains it a bit.


But as I looked in to it further it was quite clear to me that the
Rockchip maintained layers are more "up to date" then the community
ones. And then I started thinking on why are not these merged and we
could focus effort on maintaining one layer.
The main goal Romain and I have is to have a meta-rockchip that helps
users run upstream code on their rockchip devices. My guess is that
the main goal of the Rockchip meta-rockchip is to demonstrate the
performance of the rockchip SoC (usually via vendor kernels, vendor
bootloaders, binary blobs, etc.)

There are a couple things that are interesting:

- The Rockchip maintained layers state that they do accept
contributions trough pull-requests on github. So nothing stopping us
there?
They are quite friendly, but they have their goals.

- The Rockchip maintained layers supports more "community" boards then
the community layers does. Bit odd? :)
The rockchip people are paid to maintain meta-rockchip as part of
their day-jobs, Romain and I aren't. I buy my own boards, I haven't
received any hardware support, so my contributions tend to focus on
boards I actually have. I would rather have support for boards I can
actually test and therefore actually have rather than guessing whether
stuff will work. Not to mention I have to find time to work on this
after other "more important" things are done :-)
That is of course fully understandable.

- The community layers are a bit outdated on older Yocto branches,
master branch seems active though.
Mostly a time issue. I build master with firefly-rk3288 every night
with all the latest master updates and try to fix any issues that come
up. I don't have the resources, unfortunately, to keep my finger on
various past releases.
Also understandable.


- Trevor and Romain (maintainers of the community layers) are listed
as maintainers of the Rockchip layers? [4]
Initially the Rockchip people would send pull requests for the one
meta-rockchip layer. Many of those pull requests were to add recipes
pointing to vendor kernels/bootloaders and binary blobs. Also they
would send patches for boards that (at those times) weren't available
or sometimes weren't even announced! We pushed back on some of the
contributions, not just for philosophical reasons but sometimes for
technical reasons as well. They weren't happy with our slow response
times and push-back so they just forked and went on their own way.
When they forked they forgot to change some of the boilerplate stuff
that should have been changed (such as the maintainers). So yes,
Romain and I are listed as the maintainers of the Rockchip
meta-rockchip layer, but we're not :-)
This explains a lot thanks.

It's on my TODO list to send them some patches for things like that :-)

What I am really after is better understanding the workflow working
with Rockchip SOC`s and Yocto and that is why I am raising questions
to do so :).

My plan was getting involved in one of the Rockchip layers as I have
some improvements and I have some ideas for further improvements. And
the goal with this email was to figure out where.
Every once in a while I try to carve out some time to try the Rockchip
meta-rockchip layer and see how things are going. Maybe it's just a
coincidence, but often they don't build for me. Looking through their
instructions they seem to want lots of control over a user's
setup/configuration (i.e. by using repo to pull specific versions of a
specific set of layers, then using their own setup tool). My goal is
to have a layer that works any way the user wants to work (e.g.
distroless with openembedded-core, or with poky, or with angstrom,
etc...). When I use their instructions I do have more success (but not
always), but I don't believe that's how BSP layers should work. I
don't think it's a good situation when a user must use a specific
distro, or specific layers at specific commit points, or a specific
setup tool in order to build for a MACHINE successfully.
I actually recently was in the situation on choosing of one of
meta-rockchip layers and I ended up with the Rockchip one, mostly
since it had Tinkerboard support and 4.4 vendor kernel. It built for
me at least :).

I am not totally against using repo and manifest to help users setup a
simple "demo" (and it is quite common to use this). As the BSP layer
does not really provide you with anything cool beside booting to a
console, if one is to provide a demo layer (which is quite common to
demo X11, Walyand, and Qt as examples) making it easier to get started
with development. But the BSP layer should of course work standalone.


I'm hoping that one day
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11881 will get
accepted. If/When that happens then it will be theoretically possible
to have both a set of upstream recipes and a set of vendor recipes
within the same BSP layer. Maybe at that point the two (three?) layers
can come together. Unfortunately there doesn't seem to be much
interest in BSP layers outside of the BSP community. I'll probably
just have to add the support to the layer itself in order to gain this
functionality (as do the FSL layers, which is where this idea
originates).
This is certainly a interesting change but IMO not required to have
multiple u-boots, Linux kernels etc. The Freescale layer is by far
more complex (due to the number of boards/SOCs supported) and makes
sense there, most other BSP layers maybe do not that kind of
complexity and not the same need I guess.


I am hoping for a better situation in the future. I'm glad for any
suggestions, patches, testing, etc. For example, the meta-rockchip I
help maintain still uses a vendor u-boot although I've been told the
upstream should work fine; I just haven't had the time to investigate.
Also, I'd like to add a linux-stable recipe for 4.13 (similar to
meta-odroid) but I can't seem to get the defconfig right. Also, I have
a firefly-rk3399 and a tinker-rk3288, but haven't had the time to get
anything into a state I can push publicly.
It is quite obvious to me that any attempted efforts should be
directed to the community layers as this was once the base of the
Rockchip layers.

I do have some time and ambition to spend I will list some ideas here
so that they can be shot down before I start working on them (some
things might not align with your goals of the layer):

- Synchronize the Rockchip and community layers. There are some
goodies in the Rockchip layers that would be nice to pull in.
Especially the vendor 4.4 kernel with GPU support and accompanied
binary blobs (that should work with Qt, Wayland, X11), I have tested
X11 my self. Running mainline is nice but without the GPU support your
are really not utilized the true power of the SoC`s. And IMO this
should be the default kernel as it provides the most functionality.

- Bring in various boards from Rockchip to community layer. I know
your wrote that you do not like to bring in boards that can not test,
but you will never have all the boards :). When bringing in the
various boards we should also try and get people interested in
maintaining them, that could be one condition on bring in boards that
you do not have.

- Bring in more vendor kernels (tinkerboard, phycore, firefly?) who
all have their own forks. Again mainline is nice but does not provide
the same functionality as the vendor kernels.

- Consolidate machine configurations. I started working on something
targeting the Rockchip layer here [2]

- Add proper extlinux support [1], instead of hardcoding it in the gpt
image classes.

- Move away from custom image classes to WIC, I am running this in a
custom layer and it works just fine.

- There seems to be a lot of "stale/dead" code in the community
rockchip layer. Old kernels and "petitboot" that might not be used
today? This is basically a clean-up task.

- I kinda like the meta-rockchip-extra layer to provide more "capable"
demo images for testing purpose.

Also the ambition would be to try and get Rockchip involved again in
the community layer instead of forking or at least push changes to
community layer if they want to keep the fork.

There is probably more but I will stop here for now :).


Never a dull moment :-D
We would not be doing this otherwise :).

[1]. https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/uboot-extlinux-config.bbclass
[2]. https://github.com/mirzak/meta-rockchip/commits/consolidate-machines

--
Best Regards
Mirza


Re: [meta-rockchip] The various rockchip layers

Trevor Woerner
 

On Sat, Oct 7, 2017 at 7:03 PM, Mirza Krak <mirza.krak@gmail.com> wrote:
As I started digging to check the current state of the different
layers it was quite clear to me that there where two different sets.
One is maintained by Rockchip [1] and the other one by the community
[2].
Don't forget https://github.com/jackmitch/meta-tinker ;-)

And it made sense to me initially. I do not know the full background
story with the Rockchip layers (would be nice if someone could tell it
:)) on what the intent was with "community" Rockchip layers.
Romain started meta-rockchip initially, then I joined, then people
from Rockchip joined later.

But as I looked in to it further it was quite clear to me that the
Rockchip maintained layers are more "up to date" then the community
ones. And then I started thinking on why are not these merged and we
could focus effort on maintaining one layer.
The main goal Romain and I have is to have a meta-rockchip that helps
users run upstream code on their rockchip devices. My guess is that
the main goal of the Rockchip meta-rockchip is to demonstrate the
performance of the rockchip SoC (usually via vendor kernels, vendor
bootloaders, binary blobs, etc.)

There are a couple things that are interesting:

- The Rockchip maintained layers state that they do accept
contributions trough pull-requests on github. So nothing stopping us
there?
They are quite friendly, but they have their goals.

- The Rockchip maintained layers supports more "community" boards then
the community layers does. Bit odd? :)
The rockchip people are paid to maintain meta-rockchip as part of
their day-jobs, Romain and I aren't. I buy my own boards, I haven't
received any hardware support, so my contributions tend to focus on
boards I actually have. I would rather have support for boards I can
actually test and therefore actually have rather than guessing whether
stuff will work. Not to mention I have to find time to work on this
after other "more important" things are done :-)

- The community layers are a bit outdated on older Yocto branches,
master branch seems active though.
Mostly a time issue. I build master with firefly-rk3288 every night
with all the latest master updates and try to fix any issues that come
up. I don't have the resources, unfortunately, to keep my finger on
various past releases.

- Trevor and Romain (maintainers of the community layers) are listed
as maintainers of the Rockchip layers? [4]
Initially the Rockchip people would send pull requests for the one
meta-rockchip layer. Many of those pull requests were to add recipes
pointing to vendor kernels/bootloaders and binary blobs. Also they
would send patches for boards that (at those times) weren't available
or sometimes weren't even announced! We pushed back on some of the
contributions, not just for philosophical reasons but sometimes for
technical reasons as well. They weren't happy with our slow response
times and push-back so they just forked and went on their own way.
When they forked they forgot to change some of the boilerplate stuff
that should have been changed (such as the maintainers). So yes,
Romain and I are listed as the maintainers of the Rockchip
meta-rockchip layer, but we're not :-)

It's on my TODO list to send them some patches for things like that :-)

What I am really after is better understanding the workflow working
with Rockchip SOC`s and Yocto and that is why I am raising questions
to do so :).

My plan was getting involved in one of the Rockchip layers as I have
some improvements and I have some ideas for further improvements. And
the goal with this email was to figure out where.
Every once in a while I try to carve out some time to try the Rockchip
meta-rockchip layer and see how things are going. Maybe it's just a
coincidence, but often they don't build for me. Looking through their
instructions they seem to want lots of control over a user's
setup/configuration (i.e. by using repo to pull specific versions of a
specific set of layers, then using their own setup tool). My goal is
to have a layer that works any way the user wants to work (e.g.
distroless with openembedded-core, or with poky, or with angstrom,
etc...). When I use their instructions I do have more success (but not
always), but I don't believe that's how BSP layers should work. I
don't think it's a good situation when a user must use a specific
distro, or specific layers at specific commit points, or a specific
setup tool in order to build for a MACHINE successfully.

I'm hoping that one day
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11881 will get
accepted. If/When that happens then it will be theoretically possible
to have both a set of upstream recipes and a set of vendor recipes
within the same BSP layer. Maybe at that point the two (three?) layers
can come together. Unfortunately there doesn't seem to be much
interest in BSP layers outside of the BSP community. I'll probably
just have to add the support to the layer itself in order to gain this
functionality (as do the FSL layers, which is where this idea
originates).

I am hoping for a better situation in the future. I'm glad for any
suggestions, patches, testing, etc. For example, the meta-rockchip I
help maintain still uses a vendor u-boot although I've been told the
upstream should work fine; I just haven't had the time to investigate.
Also, I'd like to add a linux-stable recipe for 4.13 (similar to
meta-odroid) but I can't seem to get the defconfig right. Also, I have
a firefly-rk3399 and a tinker-rk3288, but haven't had the time to get
anything into a state I can push publicly.

Never a dull moment :-D


Re: [meta-rockchip] The various rockchip layers

Khem Raj
 

On Sat, Oct 7, 2017 at 4:03 PM, Mirza Krak <mirza.krak@gmail.com> wrote:
Hi all.

I recently started working with Rockchip SoC`s and I currently have a
Tinkerboard and a FireFly-RK3288 board. And as I recently enter the
Yocto Rockchip world I have some comments and questions on the current
setup/workflow which I found a bit confusing when starting out.

As I started digging to check the current state of the different
layers it was quite clear to me that there where two different sets.
One is maintained by Rockchip [1] and the other one by the community
[2].

And it made sense to me initially. I do not know the full background
story with the Rockchip layers (would be nice if someone could tell it
:)) on what the intent was with "community" Rockchip layers.

But as I looked in to it further it was quite clear to me that the
Rockchip maintained layers are more "up to date" then the community
ones. And then I started thinking on why are not these merged and we
could focus effort on maintaining one layer.

There are a couple things that are interesting:

- The Rockchip maintained layers state that they do accept
contributions trough pull-requests on github. So nothing stopping us
there?

- The Rockchip maintained layers supports more "community" boards then
the community layers does. Bit odd? :)

- The community layers are a bit outdated on older Yocto branches,
master branch seems active though.

- Trevor and Romain (maintainers of the community layers) are listed
as maintainers of the Rockchip layers? [4]
Its not a good situation, While it is good that both layers are maintained, it
should be clear in its purpose. It could be that github layer supports products
and might have binary stuff and may not work with latest upstreams and the
community layer while supporting lesser number of boards is kept uptodate
with respective upstreams. Ideally, it would be good if both layers were
in sync.


What I am really after is better understanding the workflow working
with Rockchip SOC`s and Yocto and that is why I am raising questions
to do so :).

My plan was getting involved in one of the Rockchip layers as I have
some improvements and I have some ideas for further improvements. And
the goal with this email was to figure out where.

[1]. https://github.com/rockchip-linux
[2]. http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/
[3]. http://freescale.github.io/doc/release-notes/2.2/#the-differences-between-project-name-and-freescale-release-name
[4]. https://github.com/rockchip-linux/meta-rockchip/blob/master/README#L65-L66
--
Best Regards
Mirza
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[meta-security][PATCH 2/2] README: update with basic info

Armin Kuster
 

needed to pass yocto-check-layer

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-tpm/README | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/meta-tpm/README b/meta-tpm/README
index e69de29..bbc70bb 100644
--- a/meta-tpm/README
+++ b/meta-tpm/README
@@ -0,0 +1,4 @@
+meta-tpm layer
+==============
+
+This layer contains base TPM recipes.
--
2.7.4


[meta-security][PATCH 1/2] swtpm: fix cuse depends

Armin Kuster
 

if cuse is enabled, depend on fuse which is in meta-filesystems
throw error is layer is missing.

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb b/meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb
index 14f668b..952de1a 100644
--- a/meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb
+++ b/meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb
@@ -3,7 +3,7 @@ LICENSE = "BSD-3-Clause"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fe8092c832b71ef20dfe4c6d3decb3a8"
SECTION = "apps"

-DEPENDS = "libtasn1 fuse expect socat glib-2.0 libtpm libtpm-native"
+DEPENDS = "libtasn1 expect socat glib-2.0 libtpm libtpm-native"

# configure checks for the tools already during compilation and
# then swtpm_setup needs them at runtime
@@ -32,7 +32,7 @@ PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux',
PACKAGECONFIG[openssl] = "--with-openssl, --without-openssl, openssl"
PACKAGECONFIG[gnutls] = "--with-gnutls, --without-gnutls, gnutls"
PACKAGECONFIG[selinux] = "--with-selinux, --without-selinux, libselinux"
-PACKAGECONFIG[cuse] = "--with-cuse, --without-cuse"
+PACKAGECONFIG[cuse] = "--with-cuse, --without-cuse, fuse"

EXTRA_OECONF += "--with-tss-user=${TSS_USER} --with-tss-group=${TSS_GROUP}"

@@ -55,3 +55,9 @@ USERADD_PARAM_${PN} = "--system -g ${TSS_GROUP} --home-dir \
RDEPENDS_${PN} = "libtpm expect socat bash"

BBCLASSEXTEND = "native nativesdk"
+
+python() {
+ if 'cuse' in d.getVar('PACKAGECONFIG') and \
+ 'filesystems-layer' not in d.getVar('BBFILE_COLLECTIONS').split():
+ raise bb.parse.SkipRecipe('Cuse enabled which requires meta-filesystems to be present.')
+}
--
2.7.4


[meta-rockchip] The various rockchip layers

Mirza Krak <mirza.krak@...>
 

Hi all.

I recently started working with Rockchip SoC`s and I currently have a
Tinkerboard and a FireFly-RK3288 board. And as I recently enter the
Yocto Rockchip world I have some comments and questions on the current
setup/workflow which I found a bit confusing when starting out.

As I started digging to check the current state of the different
layers it was quite clear to me that there where two different sets.
One is maintained by Rockchip [1] and the other one by the community
[2].

And it made sense to me initially. I do not know the full background
story with the Rockchip layers (would be nice if someone could tell it
:)) on what the intent was with "community" Rockchip layers.

But as I looked in to it further it was quite clear to me that the
Rockchip maintained layers are more "up to date" then the community
ones. And then I started thinking on why are not these merged and we
could focus effort on maintaining one layer.

There are a couple things that are interesting:

- The Rockchip maintained layers state that they do accept
contributions trough pull-requests on github. So nothing stopping us
there?

- The Rockchip maintained layers supports more "community" boards then
the community layers does. Bit odd? :)

- The community layers are a bit outdated on older Yocto branches,
master branch seems active though.

- Trevor and Romain (maintainers of the community layers) are listed
as maintainers of the Rockchip layers? [4]

What I am really after is better understanding the workflow working
with Rockchip SOC`s and Yocto and that is why I am raising questions
to do so :).

My plan was getting involved in one of the Rockchip layers as I have
some improvements and I have some ideas for further improvements. And
the goal with this email was to figure out where.

[1]. https://github.com/rockchip-linux
[2]. http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/
[3]. http://freescale.github.io/doc/release-notes/2.2/#the-differences-between-project-name-and-freescale-release-name
[4]. https://github.com/rockchip-linux/meta-rockchip/blob/master/README#L65-L66
--
Best Regards
Mirza


Re: [meta-raspberry-pi] needing newer or patched version of g++

Khem Raj
 

On Sat, Oct 7, 2017 at 9:38 AM, Bill Jenkins <bill@korgrd.com> wrote:

On Sep 15, 2017, at 8:02 AM, Bill Jenkins <bill@korgrd.com> wrote:


On Sep 15, 2017, at 7:43 AM, Khem Raj <raj.khem@gmail.com> wrote:

On Fri, Sep 15, 2017 at 7:35 AM, Bill Jenkins <bill@korgrd.com> wrote:

On Sep 15, 2017, at 6:54 AM, Khem Raj <raj.khem@gmail.com> wrote:

On Thu, Sep 14, 2017 at 10:14 PM, Bill Jenkins <bill@korgrd.com> wrote:
After creating an SDK for a 32-bit Raspberry Pi3 target, I ran into the following compiler error when
compiling an application using the SDK:

internal compiler error: Max. number of generated reload insns per insn is achieved (90)

It turns out that a patch was submitted for g++ early last year for the above problem,
We need to backport the patch to 6.3.0 and regenerate SDK. If you can
point to patch that will be helpful.
Thanks Khem, here's a link to the commit:

https://github.com/gcc-mirror/gcc/commit/4fe01ba94e99e792ebe9da2ccb3b071aa1bac388#diff-af18d9175d034b2b3726f1ddc05fae55
OK and which release are you on ?
I've been building in the pyro branch. DISTRO_VERSION reports 2.3.2.
I hadn't heard any news on this. Is there any more information required?
Will it be possible to backport that patch to gcc 6.3.0?
Posted now here
https://patchwork.openembedded.org/patch/144754/


Re: [meta-raspberry-pi] needing newer or patched version of g++

Bill J
 

On Sep 15, 2017, at 8:02 AM, Bill Jenkins <bill@korgrd.com> wrote:


On Sep 15, 2017, at 7:43 AM, Khem Raj <raj.khem@gmail.com> wrote:

On Fri, Sep 15, 2017 at 7:35 AM, Bill Jenkins <bill@korgrd.com> wrote:

On Sep 15, 2017, at 6:54 AM, Khem Raj <raj.khem@gmail.com> wrote:

On Thu, Sep 14, 2017 at 10:14 PM, Bill Jenkins <bill@korgrd.com> wrote:
After creating an SDK for a 32-bit Raspberry Pi3 target, I ran into the following compiler error when
compiling an application using the SDK:

internal compiler error: Max. number of generated reload insns per insn is achieved (90)

It turns out that a patch was submitted for g++ early last year for the above problem,
We need to backport the patch to 6.3.0 and regenerate SDK. If you can
point to patch that will be helpful.
Thanks Khem, here's a link to the commit:

https://github.com/gcc-mirror/gcc/commit/4fe01ba94e99e792ebe9da2ccb3b071aa1bac388#diff-af18d9175d034b2b3726f1ddc05fae55
OK and which release are you on ?
I've been building in the pyro branch. DISTRO_VERSION reports 2.3.2.
I hadn't heard any news on this. Is there any more information required?
Will it be possible to backport that patch to gcc 6.3.0?

Cheers,
Bill



but apparently that
patch is not in the 6.3.0 version within the SDK. When I try to specify a newer version,
(by using PREFERRED_VERSION_gcc-cross-${TARGET_ARCH}) bitbake reports that only 5.4.0 or 6.3.0
are available. Any suggestions on how to resolve this? (i.e. is there some way to use a newer g++ or to
apply the patch?)

Thanks,
Bill
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Missing /etc/resolv.conf

Paul D. DeRocco
 

(Yocto Pyro, using systemd configured with resolved, networkd, timedated,
timesyncd)

/etc/resolv.conf is supposed to be symlinked to
/run/systemd/resolve/resolv.conf, which gets updated with the DNS address
received from DHCP, but it's not. Looking through systemd_232.bb, I see
that do_install() uses sed to edit /usr/lib/tmpfiles.d/etc.conf to set up
this link. When I run the system, I see that etc.conf does indeed have
this edited line, but there is no /etc/resolv.conf.
systemd-tmpfiles-setup.service runs successfully. Isn't that what's
supposed to execute all the junk in /usr/lib/tmpfiles.d? All the
abovementioned servers are running.

Am I missing something?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com

15981 - 16000 of 54253