Date   

Re: #golang: go fetches dependencies in compile phase

Robert Berger
 

Hi,

My comments are inline.

On 12/04/2021 14:47, Juergen Landwehr wrote:
Hi Robert,
thanks for your thoughts.
I see your point and the last thing I want is "NOT reproducable builds".
But dependency management in go is not that arbitrary as it may seem.
... if everybody does what they are supposed to - which is not the case.

Dependencies and their version is stored in "go.mod". To ensure reproducable builds, hashes for each dependency and version are stored in "go.sum". Both files are in git and together with a local golang proxy, this should ensure reproducable builds, right?
This does not sound too bad. This would also mean, that if the outside repo dies you can still build and that you know what's on your proxy.

To ensure that licences are valid and did not change over time, we developed a little tool, that goes through all dependencies and creates the following output, which we insert into our recipe:
LICENSE = "Apache-2.0 & MIT & MIT & BSD-2-Clause & BSD-3-Clause & ...
Here you

1) Totally lost which License comes from which module and I hope 2 times MIT is just a typo.

Of course if you are really serious about licensing you should use a tool like fossology, upload all your sources there and inspect them.
You will be surprised.

There are a couple of tools out there which scan your sources and some which claim to do stuff with golang as well.

2) Do you check if the licenses are compatible?

MIT and Apache are compatible:

some googling:

"Both the Apache License and the MIT license are permissive, so incorporating MIT licensed code into your Apache licensed project is certainly allowed. Just be sure to attribute the original author for the parts your incorporated and include a copy of the MIT License terms, as required by the license."

Apache and BSD should also be OK:

some googling:

"In both of them you must:

Include copyright

But in Apache, unlike BSD you must:

Include License
State Changes
Include Notice
"

LIC_FILES_CHKSUM = " \
file://${S}/src/${GO_IMPORT}/vendor/github.com/coreos/go-oidc/LICENSE;md5=d2794c0df5b907fdace235a619d80314 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/go-playground/locales/LICENSE;md5=3ccbda375ee345400ad1da85ba522301 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/go-playground/universal-translator/LICENSE;md5=2e2b21ef8f61057977d27c727c84bef1 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/godbus/dbus/v5/LICENSE;md5=09042bd5c6c96a2b9e45ddf1bc517eed \
file://${S}/src/${GO_IMPORT}/vendor/github.com/golang/gddo/LICENSE;md5=4c728948788b1a02f33ae4e906546eef \
...
This is a manual step and whenever dependencies change we have to create this list again and add it to the recipe, but it contains all the required license information and makes them visible in the recipe.
really all?

You search through every single file of a go module and it's dependencies? Or just the license text, if there is one?

It might pollute the recipe a bit, but luckily we do not have thousands of dependencies like some npm projects. So I think it is still manageable. And is it much less work, than defining a recipe for each dependency.
So we would
* guarantee reproducable builds
* use the programming language (in our case golang) to handle dependency management
* ensure that licenses are visible and correct
I mean it is not perfect and still a compromise, but it should work without breaking reproducable builds or causing license issues?
What do you think?
Regards,
Jürgen
PS: Thanks for the link. I was not aware of this discussion (it is quite a bit to read:))
Regards,

Robert


Re: Cannot execute nodejs

Alessandro Tagliapietra
 

I was able to solve it by forcing recompiling nodejs with `bitbake -f -c compile nodejs`

Not sure what happened there

--
Alessandro Tagliapietra



On Wed, Apr 14, 2021 at 11:51 AM Alessandro Tagliapietra <tagliapietra.alessandro@...> wrote:
Hi everyone,

I've installed nodejs and node-red  by using meta-oe and meta-iot-cloud, with

IMAGE_INSTALL_append = " nodejs node-red bash"

it was initially working but then I've got some pseudo aborts that fixed automatically and then I saw that:
 - /usr/bin/node doesn't have the +x flag
 - the file is 1.1G big (however the image is 200MB)
 - trying to run it says "cannot execute binary file: Exec format error"

any idea why?

Target is core-image-minimal with machine qemuarm.
I've checked the source of the file with `oe-pkgdata-util find-path` it came from the nodejs recipe. I've also tried bitbake -c clean nodejs and nothing changed



Cannot execute nodejs

Alessandro Tagliapietra
 

Hi everyone,

I've installed nodejs and node-red  by using meta-oe and meta-iot-cloud, with

IMAGE_INSTALL_append = " nodejs node-red bash"

it was initially working but then I've got some pseudo aborts that fixed automatically and then I saw that:
 - /usr/bin/node doesn't have the +x flag
 - the file is 1.1G big (however the image is 200MB)
 - trying to run it says "cannot execute binary file: Exec format error"

any idea why?

Target is core-image-minimal with machine qemuarm.
I've checked the source of the file with `oe-pkgdata-util find-path` it came from the nodejs recipe. I've also tried bitbake -c clean nodejs and nothing changed


#yocto #sdk SDK_EXTRA_TOOLS inclussion of python-native and devtool #yocto #sdk

Monsees, Steven C (US)
 

 

Working with zeus 3.0.4, extended SDK…

 

Could someone explain what I overlooked, or why this issue pops up with python-native support inclusion ?

 

Thanks…

 

When I add in native-python3 support

 

#

# Additional SDK Setup variables

#

 

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

 

SDK_EXTRA_TOOLS = "  \

     nativesdk-python3-pprint \

     nativesdk-python3-pickle \

     nativesdk-python3-shell \

     nativesdk-python3-modules \

     nativesdk-python3-distutils \

     nativesdk-python3-xml \

     nativesdk-python3-compile \

     nativesdk-python3-six \

     nativesdk-cmake \

     "

 

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

 

I see the following error with devtool:

 

13:07 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH

13:08 smonsees@yix490016 /disk0/scratch/smonsees>. /disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux

SDK environment now set up; additionally you may now run devtool to perform development tasks.

Run devtool --help for further details.

13:08 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help

/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3: /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real: /opt/limws/3.0.4/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3: line 5: /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real: Success

 

If I remove the “native-python” components, the issue goes away:

 

SDK_EXTRA_TOOLS = "  \

    nativesdk-cmake \

    "

 

14:09 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH

14:11 smonsees@yix490016 /disk0/scratch/smonsees>. /disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux

SDK environment now set up; additionally you may now run devtool to perform development tasks.

Run devtool --help for further details.

14:11 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help

NOTE: Starting bitbake server...

usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]

               [--color COLOR] [-h]

               <subcommand> ...

 

OpenEmbedded development tool

 

options:

  --basepath BASEPATH   Base directory of SDK / build directory

  --bbpath BBPATH       Explicitly specify the BBPATH, rather than getting it

                        from the metadata

  -d, --debug           Enable debug output

  -q, --quiet           Print only errors

  --color COLOR         Colorize output (where COLOR is auto, always, never)

  -h, --help            show this help message and exit

 

subcommands:

  Beginning work on a recipe:

    add                   Add a new recipe

    modify                Modify the source for an existing recipe

    upgrade               Upgrade an existing recipe

  Getting information:

    status                Show workspace status

    search                Search available recipes

    latest-version        Report the latest version of an existing recipe

    check-upgrade-status  Report upgradability for multiple (or all) recipes

  Working on a recipe in the workspace:

    build                 Build a recipe

    rename                Rename a recipe file in the workspace

    edit-recipe           Edit a recipe file

    find-recipe           Find a recipe file

    configure-help        Get help on configure script options

    update-recipe         Apply changes from external source tree to recipe

    reset                 Remove a recipe from your workspace

    finish                Finish working on a recipe in your workspace

  Testing changes on target:

    deploy-target         Deploy recipe output files to live target machine

    undeploy-target       Undeploy recipe output files in live target machine

    package               Build packages for a recipe

    build-image           Build image including workspace recipe packages

    runqemu               Run QEMU on the specified image

  Advanced:

    build-sdk             Build a derivative SDK of this one

    extract               Extract the source for an existing recipe

    sync                  Synchronize the source tree for an existing recipe

    export                Export workspace into a tar archive

    import                Import exported tar archive into workspace

    menuconfig            Alter build-time configuration for a recipe

  SDK maintenance:

    sdk-update            Update SDK components

    sdk-install           Install additional SDK components

Use devtool <subcommand> --help to get help on a specific command

14:11 smonsees@yix490016 /disk0/scratch/smonsees>

 

 


Yocto Technical Team Minutes, Engineering Sync, for April 13, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for April 13, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== announcements ==
The upcoming Yocto Project Summit is taking place May 25-26 2021
details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
CfP: https://pretalx.com/yocto-project-summit-2021/cfp
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Alexandre Belloni, Jere Viikari, Richard
Purdie, Scott Murray, Peter Kjellerstedt, Armin Kuster, Saul Wold, Steve
Sakoman, Randy MacLeod, Trevor Gamblin, Ross Burton, Bruce Ashfield, Paul
Barker, sakib.sajal@WR, Tim Orling, Joshua Watt, Alejandro H

== notes ==
- 3.3-rc2 had a clean QA, waiting on TSC approval and release notes update
- 3.3-rc1 was abandoned due to build issue
- 3.1.7 building as we speak
- prserv rework and git fetcher work underway

== general ==
RP: relatively quiet week, couple of issues here and there bitbake setscene
(covered vs not-covered)
Ross: interesting cycle, lots of good work
RP: agreed, community effort
RP: i think the next release won’t be as quiet, there are a number of things
that we need to shake up


Randy: Sakib and I have some filters enabled to capture stats when AB issues
occur. ready to be enabled. tested locally but our cluster isn’t pushed
as hard as the real AB


JPEW: next release in Oct?
RP: yes, see report sent by S Jolley
JPEW: then the release after that is the LTS?
RP: yes, Spring 2022.
RP: however, we need to get buy-in from members. the first was an experiment,
it seems good
JPEW: LTS works for me. seems like lots of BSP vendors focused on LTS which
made it easy to build across a large range of MACHINEs
Randy: yocto LTS or kernel LTS?
JPEW: yocto LTS, we’re stuck with vendor kernels for the most part
RP: informal survey wrt LTS: general feeling that it was liked among member
companies
RP: can we “prove” the value of LTS with data? perhaps CVE fixes?
Saul: lots of problems collecting data (e.g. we don’t even know how people
are using it)
AlexB: premirrors for poky?
RP: true, but there are guidelines wrt the use of that data
RP: to be a true comparison we’d have to compare LTS to a non-LTS, but
non-LTS don’t occur over the same time-span, so a comparison might be
hard. maybe CVE commits
SS: I do have data since June of CVE adds/removes etc. but the data can get
confusing
RP: what if we looked at the data wrt each point release
SS: it’s possible, it’ll take time. we could also try to increase the
number of dot releases


TrevorW: i don’t think Dunfell is y2038 safe
AlexB: i *know* it’s not safe, need kernel and glibc
TrevorW: okay, is this something that we’re going to worry about for dunfell
RP: i’ve been getting private emails on this topic (not sure why they’re
private) so it is something we should look at. i recommend we start a wiki
page. some people say we need a 5.10 kernel to be compatible
AlexB: i think 5.5 is good enough
PaulB: i think some people are saying 5.10 because it is an LTS kernel (?)
AlexB: time_t from 32 to 64 bits
JPEW: should be easy to test in qemu
AlexB: there are lots of places that need fixing, lots and lots just in
oe-core, nevermind meta-oe
RP: we can break the ABI in our builds
TrevorW: is this something we want to do in dunfell
RP: if there are easy fixes okay, but probably not in the context of dunfell.
i’m happy to see dunfell fixed, but a wholesale kernel upgrade might be
out of scope
AlexB: the 5.4 kernel is probably fine, the biggest issue is the glibc, and i
doubt it’ll get backported


TimO: python parsing
RP: there are some classes that are python nightmares. parsing in
bitbake context has a lot of overhead whereas parsing outside of
bitbake reduces the memory overhead. so there are pros and cons.
package.bbclass and patch.bbclass and a lot of the code in utils needs to
be moved/re-arranged. there might be compatibility issues, the question is
how to balance compatibility vs cleanup


Randy: we’ve seen issues where VMs with 46GB run out of memory. some people
say it’s an underlying issue with cmake or meson. but is this an
underlying issue, or is it something bitbake should handle?
RP: tricky question. it’s hard to tell how much load a job is going to
generate. shared job pool between make and bbthreads might be a viable way
to improve things. but there are limits to what bitbake can do. throttling
down the number of thread used by, for example, c++ builds or webkit are
useful. perhaps a global include file that puts limits
JPEW: it’d be nice to specify parallel make without having to specify the
“-j”, makes it clumsy to update in a script when you have to keep
parsing out the -j and then putting it back in again
RP: probably need a 2nd variable. parallel-make is really old, regressing
gracefully is the trick
Randy: handling things like ninja is hard
JPEW: ninja is meant to be simple
RossB: i think there’s a samurai update to ninja that has more options
JPEW: there is an open issue to add job server support to ninja
RP: which sounds like they don’t want to
ScottM: there was a patch suggested, which was rejected. we could add it
ourselves, but then we’d have to support it
RP: i wonder if samurai supports it
RossB: not quite, but there are bits and pieces, so maybe they’d take the
patch
RP: maybe check bugzilla, i’m sure i documented this somewhere


TimO: ptest output consistency. switching output formats might be too late,
there are already so many tools etc. would that be a true statement?
RP: we can *add* a new output format, just don’t throw away the old ones. it
would have to be opt-in but we don’t want a flag day


[meta-rockchip][PATCH v2 6/6] WIP kernel config feature for OP-TEE activation

Yann Dirson
 

From: Yann Dirson <yann@...>

FIXME:
- provide an .scc with proper information
- maybe bundle with dts overlay
- select a more suitable path in config namespace
---
recipes-kernel/linux/files/bsp/tee.cfg | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/tee.cfg

diff --git a/recipes-kernel/linux/files/bsp/tee.cfg b/recipes-kernel/linu=
x/files/bsp/tee.cfg
new file mode 100644
index 0000000..82213a5
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/tee.cfg
@@ -0,0 +1,2 @@
+CONFIG_TEE=3Dm
+CONFIG_OPTEE=3Dm
--=20
2.30.2


[meta-rockchip][PATCH v2 5/6] WIP nanopi-m4: declare OP-TEE presence in devicetree

Yann Dirson
 

From: Yann Dirson <yann@...>

FIXME:

- this is not specific to the board, and would indeed apply to any SoC
supported by OP-TEE.
- should rather be selected by "optee" in DISTRO_FEATURES, maybe using
a dts overlay
---
.../0001-nanopi-declare-optee-presence.patch | 30 +++++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 1 +
2 files changed, 31 insertions(+)
create mode 100644 recipes-kernel/linux/files/0001-nanopi-declare-optee-=
presence.patch

diff --git a/recipes-kernel/linux/files/0001-nanopi-declare-optee-presenc=
e.patch b/recipes-kernel/linux/files/0001-nanopi-declare-optee-presence.p=
atch
new file mode 100644
index 0000000..aede781
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-nanopi-declare-optee-presence.patch
@@ -0,0 +1,30 @@
+From 30cb714e717990276a5fabc50dc616c83b223ee7 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@...>
+Date: Mon, 12 Apr 2021 15:50:26 +0200
+Subject: [PATCH] nanopi: declare optee presence
+
+---
+ arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dts | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dts b/arch/ar=
m64/boot/dts/rockchip/rk3399-nanopi-m4.dts
+index 60358ab8c7df..ef11639b03f6 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dts
+@@ -16,6 +16,13 @@ / {
+ model =3D "FriendlyElec NanoPi M4";
+ compatible =3D "friendlyarm,nanopi-m4", "rockchip,rk3399";
+=20
++ firmware {
++ optee {
++ compatible =3D "linaro,optee-tz";
++ method =3D "smc";
++ };
++ };
++
+ vdd_5v: vdd-5v {
+ compatible =3D "regulator-fixed";
+ regulator-name =3D "vdd_5v";
+--=20
+2.30.2
+
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 9658681..97b3238 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -2,6 +2,7 @@ FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
=20
SRC_URI_append =3D "\
file://bsp;type=3Dkmeta;subdir=3Dkernel-meta \
+ file://0001-nanopi-declare-optee-presence.patch \
"
=20
COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
--=20
2.30.2


[meta-rockchip][PATCH v2 4/6] WIP optee-os: rk3399 support

Yann Dirson
 

From: Yann Dirson <yann@...>

This is the current state of working patches being discussed in
https://github.com/OP-TEE/optee_os/issues/4542
---
conf/machine/include/rk3399.inc | 2 +
...399-enable-serial-console-by-default.patch | 46 +++++++++++++++++++
.../optee/files/rk3399-boot-fix.patch | 13 ++++++
recipes-security/optee/optee%.bbappend | 2 +
recipes-security/optee/optee-os_%.bbappend | 9 ++++
5 files changed, 72 insertions(+)
create mode 100644 recipes-security/optee/files/0001-rk3399-enable-seria=
l-console-by-default.patch
create mode 100644 recipes-security/optee/files/rk3399-boot-fix.patch
create mode 100644 recipes-security/optee/optee-os_%.bbappend

diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk339=
9.inc
index f6b7826..9ac434e 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -13,6 +13,8 @@ KBUILD_DEFCONFIG ?=3D "defconfig"
KERNEL_CLASSES =3D "kernel-fitimage"
KERNEL_IMAGETYPE =3D "fitImage"
=20
+OPTEEMACHINE =3D "rockchip-rk3399"
+
TFA_PLATFORM =3D "rk3399"
TFA_BUILD_TARGET =3D "bl31"
=20
diff --git a/recipes-security/optee/files/0001-rk3399-enable-serial-conso=
le-by-default.patch b/recipes-security/optee/files/0001-rk3399-enable-ser=
ial-console-by-default.patch
new file mode 100644
index 0000000..31daef7
--- /dev/null
+++ b/recipes-security/optee/files/0001-rk3399-enable-serial-console-by-d=
efault.patch
@@ -0,0 +1,46 @@
+From 0e2cbe08532a1344aab62f21b032ce6171e50f49 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@...>
+Date: Mon, 12 Apr 2021 10:49:18 +0200
+Subject: [PATCH] rk3399: enable serial console by default
+Upstream-Status: Submitted [https://github.com/OP-TEE/optee_os/pull/4551=
]
+
+Signed-off-by: Yann Dirson <yann@...>
+---
+ core/arch/arm/plat-rockchip/conf.mk | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+Index: git/core/arch/arm/plat-rockchip/conf.mk
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+--- git.orig/core/arch/arm/plat-rockchip/conf.mk
++++ git/core/arch/arm/plat-rockchip/conf.mk
+@@ -26,8 +26,6 @@ CFG_EARLY_CONSOLE_BAUDRATE ?=3D 1500000
+ CFG_EARLY_CONSOLE_CLK_IN_HZ ?=3D 24000000
+ endif
+=20
+-CFG_EARLY_CONSOLE ?=3D n
+-
+ ifeq ($(PLATFORM_FLAVOR),rk3399)
+ include core/arch/arm/cpu/cortex-armv8-0.mk
+ $(call force,CFG_TEE_CORE_NB_CORE,6)
+@@ -37,6 +35,12 @@ CFG_TZDRAM_START ?=3D 0x30000000
+ CFG_TZDRAM_SIZE ?=3D 0x02000000
+ CFG_SHMEM_START ?=3D 0x32000000
+ CFG_SHMEM_SIZE ?=3D 0x00400000
++
++CFG_EARLY_CONSOLE ?=3D y
++CFG_EARLY_CONSOLE_BASE ?=3D UART2_BASE
++CFG_EARLY_CONSOLE_SIZE ?=3D UART2_SIZE
++CFG_EARLY_CONSOLE_BAUDRATE ?=3D 1500000
++CFG_EARLY_CONSOLE_CLK_IN_HZ ?=3D 24000000
+ endif
+=20
+ ifeq ($(PLATFORM_FLAVOR),px30)
+@@ -47,6 +51,8 @@ CFG_TZDRAM_START ?=3D 0x30000000
+ CFG_TZDRAM_SIZE ?=3D 0x02000000
+ CFG_SHMEM_START ?=3D 0x32000000
+ CFG_SHMEM_SIZE ?=3D 0x00400000
++
++CFG_EARLY_CONSOLE ?=3D n
+ endif
+=20
+ ifeq ($(platform-flavor-armv8),1)
diff --git a/recipes-security/optee/files/rk3399-boot-fix.patch b/recipes=
-security/optee/files/rk3399-boot-fix.patch
new file mode 100644
index 0000000..d346157
--- /dev/null
+++ b/recipes-security/optee/files/rk3399-boot-fix.patch
@@ -0,0 +1,13 @@
+Index: git/core/arch/arm/kernel/entry_a64.S
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+--- git.orig/core/arch/arm/kernel/entry_a64.S
++++ git/core/arch/arm/kernel/entry_a64.S
+@@ -219,7 +219,7 @@ clear_nex_bss:
+ adr_l x0, __text_start
+ ldr x1, cached_mem_end
+ sub x1, x1, x0
+- bl dcache_cleaninv_range
++/* bl dcache_cleaninv_range*/
+=20
+=20
+ /*
diff --git a/recipes-security/optee/optee%.bbappend b/recipes-security/op=
tee/optee%.bbappend
index 2a8722a..ec11863 100644
--- a/recipes-security/optee/optee%.bbappend
+++ b/recipes-security/optee/optee%.bbappend
@@ -1,2 +1,4 @@
+COMPATIBLE_MACHINE_rk3399 ?=3D "rk3399"
+
inherit features_check
REQUIRED_DISTRO_FEATURES =3D "optee"
diff --git a/recipes-security/optee/optee-os_%.bbappend b/recipes-securit=
y/optee/optee-os_%.bbappend
new file mode 100644
index 0000000..eceb694
--- /dev/null
+++ b/recipes-security/optee/optee-os_%.bbappend
@@ -0,0 +1,9 @@
+EXTRA_OEMAKE_append_rk3399 =3D " \
+ CFG_CORE_ASLR=3Dn \
+"
+
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+SRC_URI +=3D "\
+ file://rk3399-boot-fix.patch \
+ file://0001-rk3399-enable-serial-console-by-default.patch \
+"
--=20
2.30.2


[meta-rockchip][PATCH v2 3/6] u-boot: include optee-os as BL32 when requested by DISTRO_FEATURE

Yann Dirson
 

From: Yann Dirson <yann@...>

This causes OP-TEE to get included into the u-boot.itb fitImage so u-boot
can load it for the trusted-firmware-a BL31 to run it.

This is configured automatically when DISTRO_FEATURE includes "optee".

Signed-off-by: Yann Dirson <yann@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-b=
oot%.bbappend
index 95c019d..d947815 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -5,6 +5,8 @@ do_compile_append_rock2-square () {
fi
}
=20
+# TF-A, when supported
+
ATF_DEPENDS ??=3D ""
=20
EXTRA_OEMAKE_append_rk3399 =3D " BL31=3D${DEPLOY_DIR_IMAGE}/bl31-rk3399.=
elf"
@@ -14,3 +16,10 @@ ATF_DEPENDS_rk3328 =3D " virtual/trusted-firmware-a:do=
_deploy"
=20
do_compile[depends] .=3D "${ATF_DEPENDS}"
=20
+# OP-TEE, dependent on "optee" DISTRO_FEATURES
+
+OPTEE_OEMAKE ?=3D " TEE=3D${DEPLOY_DIR_IMAGE}/optee/tee.elf"
+
+EXTRA_OEMAKE_append =3D " ${PACKAGECONFIG_CONFARGS}"
+PACKAGECONFIG[optee] =3D "${OPTEE_OEMAKE},,optee-os"
+PACKAGECONFIG_append =3D " ${@bb.utils.filter('DISTRO_FEATURES', 'optee'=
, d)}"
--=20
2.30.2


[meta-rockchip][PATCH v2 2/6] truster-firmware-a: include optee support when requested by DISTRO_FEATURE

Yann Dirson
 

From: Yann Dirson <yann@...>

This instructs TF-A to:

- load OP-TEE OS as BL32, but still relies on the actual image to be
provided through other means, eg. in u-boot.itb
- run opteed as Secure Payload Dispatcher

This is configured automatically when DISTRO_FEATURE includes "optee".

Signed-off-by: Yann Dirson <yann@...>
---
.../trusted-firmware-a_%.bbappend | 14 ++++++++++++++
1 file changed, 14 insertions(+)

diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend=
b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 1942c17..9887b6e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -9,3 +9,17 @@ FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
SRC_URI +=3D "\
file://serial-console-baudrate.patch \
"
+
+# OP-TEE, dependent on "optee" DISTRO_FEATURES
+
+OPTEE_OEMAKE ?=3D " \
+ BL32=3D${STAGING_DIR_TARGET}${nonarch_base_libdir}/firmware/tee-head=
er_v2.bin \
+ BL32_EXTRA1=3D${STAGING_DIR_TARGET}${nonarch_base_libdir}/firmware/t=
ee-pager_v2.bin \
+ BL32_EXTRA2=3D${STAGING_DIR_TARGET}${nonarch_base_libdir}/firmware/t=
ee-pageable_v2.bin \
+ "
+
+EXTRA_OEMAKE_append =3D " ${PACKAGECONFIG_CONFARGS}"
+PACKAGECONFIG[optee] =3D "${OPTEE_OEMAKE},,optee-os"
+PACKAGECONFIG_append =3D " ${@bb.utils.filter('DISTRO_FEATURES', 'optee'=
, d)}"
+
+TFA_SPD =3D "${@bb.utils.contains('PACKAGECONFIG', 'optee', 'opteed', ''=
, d)}"
--=20
2.30.2


[meta-rockchip][PATCH v2 0/6] WIP/RFC OP-TEE support for ARM and rk3399

Yann Dirson
 

From: Yann Dirson <yann@...>

This tries to provide a generic framework for easier OP-TEE support in
BSP layers. It would probably make sense to have the generic parts in
meta-arm when they are finalized. Today the kernel/dts handling is
still not properly done, and patches to fix rk3399 support in OP-TEE
have not yet been merged upstream, and I'm mostly posting this to
gather comments on the whole idea.

Changes from v1:
- fix last-minute typo in TFA_SPD setting, which led to optee not being =
started
- use PACKAGECONFIG[optee] to simplify recipes as suggested on meta-arm =
ml

Yann Dirson (6):
optee: condition for "optee" DISTRO_FEATURE
truster-firmware-a: include optee support when requested by
DISTRO_FEATURE
u-boot: include optee-os as BL32 when requested by DISTRO_FEATURE
WIP optee-os: rk3399 support
WIP nanopi-m4: declare OP-TEE presence in devicetree
WIP kernel config feature for OP-TEE activation

conf/machine/include/rk3399.inc | 2 +
.../trusted-firmware-a_%.bbappend | 14 ++++++
recipes-bsp/u-boot/u-boot%.bbappend | 9 ++++
.../0001-nanopi-declare-optee-presence.patch | 30 ++++++++++++
recipes-kernel/linux/files/bsp/tee.cfg | 2 +
recipes-kernel/linux/linux-yocto%.bbappend | 1 +
...399-enable-serial-console-by-default.patch | 46 +++++++++++++++++++
.../optee/files/rk3399-boot-fix.patch | 13 ++++++
recipes-security/optee/optee%.bbappend | 4 ++
recipes-security/optee/optee-os_%.bbappend | 9 ++++
10 files changed, 130 insertions(+)
create mode 100644 recipes-kernel/linux/files/0001-nanopi-declare-optee-=
presence.patch
create mode 100644 recipes-kernel/linux/files/bsp/tee.cfg
create mode 100644 recipes-security/optee/files/0001-rk3399-enable-seria=
l-console-by-default.patch
create mode 100644 recipes-security/optee/files/rk3399-boot-fix.patch
create mode 100644 recipes-security/optee/optee%.bbappend
create mode 100644 recipes-security/optee/optee-os_%.bbappend

--=20
2.30.2


[meta-rockchip][PATCH v2 1/6] optee: condition for "optee" DISTRO_FEATURE

Yann Dirson
 

From: Yann Dirson <yann@...>

This effectively sets up a single switch to activate OP-TEE support.
Disabling optee-* recipes when the feature is not set is not the
primary goal, though it can occasionally be handy to catch
dependencies pulling them without using the new DISTRO_FEATURE, which
provides a safeguard to ensure downstream recipes in need of upgrade
will fail early.

The main value for this flag is for dependent recipes to know when to
activate the OP-TEE support, rather than having to control each of
them separately:

- u-boot
- trusted-firmware-a
- kernel

Signed-off-by: Yann Dirson <yann@...>
---
recipes-security/optee/optee%.bbappend | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 recipes-security/optee/optee%.bbappend

diff --git a/recipes-security/optee/optee%.bbappend b/recipes-security/op=
tee/optee%.bbappend
new file mode 100644
index 0000000..2a8722a
--- /dev/null
+++ b/recipes-security/optee/optee%.bbappend
@@ -0,0 +1,2 @@
+inherit features_check
+REQUIRED_DISTRO_FEATURES =3D "optee"
--=20
2.30.2


Re: [meta-security][PATCH] Clearly define clang toolchain in Parsec recipes

Armin Kuster
 

merged,
Thanks

On 4/12/21 8:30 AM, Anton Antonov wrote:
Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
.../recipes-parsec/parsec-service/parsec-service_0.7.0.bb | 4 ++--
meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
index b3f7b21..0e14955 100644
--- a/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
+++ b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
@@ -10,8 +10,8 @@ SRC_URI += "crate://crates.io/parsec-service/${PV} \
file://parsec-tmpfiles.conf \
"

-DEPENDS = "clang-native tpm2-tss"
-INSANE_SKIP_${PN} += "dev-deps"
+DEPENDS = "tpm2-tss"
+TOOLCHAIN = "clang"

CARGO_BUILD_FLAGS += " --features all-providers,cryptoki/generate-bindings,tss-esapi/generate-bindings"

diff --git a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
index 939e771..35c65c0 100644
--- a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
+++ b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
@@ -7,8 +7,7 @@ inherit cargo
SRC_URI += "crate://crates.io/parsec-tool/${PV} \
"

-DEPENDS = "clang-native"
-INSANE_SKIP_${PN} += "dev-deps"
+TOOLCHAIN = "clang"

do_install() {
install -d ${D}/${bindir}



Re: [meta-security][PATCH 1/2] Add meta-parsec layer into meta-security.

Armin Kuster
 

Merged,

Thanks

On 4/9/21 4:14 AM, Anton Antonov wrote:
From: Anton Antonov <anton.antonov@...>

The layer contains recipes for Parsec service version 0.7.0 and parsec-tool version 0.3.0. The Parsec service is built with all supported providers and deployed with the MbedCrypto provider enabled. Both systemd and sysv-init are supported.

Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
meta-parsec/README.md | 186 ++++++++++++++++++
meta-parsec/conf/layer.conf | 14 ++
.../parsec-service/files/cryptoki.patch | 18 ++
.../parsec-service/files/parsec-tmpfiles.conf | 2 +
.../parsec-service/files/parsec_init | 63 ++++++
.../parsec-service/files/systemd.patch | 19 ++
.../parsec-service/parsec-service_0.7.0.bb | 67 +++++++
.../parsec-service/parsec-service_0.7.0.inc | 147 ++++++++++++++
.../parsec-tool/parsec-tool_0.3.0.bb | 18 ++
.../parsec-tool/parsec-tool_0.3.0.inc | 127 ++++++++++++
10 files changed, 661 insertions(+)
create mode 100644 meta-parsec/README.md
create mode 100644 meta-parsec/conf/layer.conf
create mode 100644 meta-parsec/recipes-parsec/parsec-service/files/cryptoki.patch
create mode 100644 meta-parsec/recipes-parsec/parsec-service/files/parsec-tmpfiles.conf
create mode 100755 meta-parsec/recipes-parsec/parsec-service/files/parsec_init
create mode 100644 meta-parsec/recipes-parsec/parsec-service/files/systemd.patch
create mode 100644 meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
create mode 100644 meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.inc
create mode 100644 meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
create mode 100644 meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.inc

diff --git a/meta-parsec/README.md b/meta-parsec/README.md
new file mode 100644
index 0000000..a2736b6
--- /dev/null
+++ b/meta-parsec/README.md
@@ -0,0 +1,186 @@
+meta-parsec layer
+==============
+
+This layer contains recipes for the Parsec service with Mbed-Crypto,
+Pkcs11 and TPM providers and parsec tools.
+
+Dependencies
+============
+
+This layer depends on:
+
+ URI: git://git.openembedded.org/meta-openembedded
+ branch: master
+ revision: HEAD
+ prio: default
+
+ URI git://git.yoctoproject.org/meta-security
+ branch: master
+ revision: HEAD
+ prio: default
+
+ URI https://github.com/meta-rust/meta-rust.git
+ branch: master
+ revision: HEAD
+ prio: default
+
+ URI https://github.com/kraj/meta-clang.git
+ branch: master
+ revision: HEAD
+ prio: default
+
+Adding the meta-parsec layer to your build
+==========================================
+
+In order to use this layer, you need to make the build system aware of it.
+
+You can add it to the build system by adding the
+location of the meta-parsec layer to bblayers.conf, along with any
+other layers needed. e.g.:
+
+ BBLAYERS ?= " \
+ /path/to/yocto/meta \
+ /path/to/yocto/meta-yocto \
+ /path/to/yocto/meta-yocto-bsp \
+ /path/to/meta-openembedded/meta-oe \
+ /path/to/meta-openembedded/meta-python \
+ /path/to/meta-rust \
+ /path/to/meta-clang \
+ /path/to/meta-security/meta-tpm \
+ /path/to/meta-security/meta-parsec \
+ "
+
+To include the Parsec service into your image add following into the
+local.conf:
+
+ IMAGE_INSTALL_append = " parsec-service"
+
+ The Parsec service will be deployed into the image built with all the supported
+providers and with the default config file from the Parsec repository:
+https://github.com/parallaxsecond/parsec/blob/main/config.toml
+ The default Parsec service config file contains the MbedCrypto provider
+enabled. The config file needs to be updated to use the Parsec service
+with other providers like TPM or PKCS11. The required procedures are
+covered in Parsec documentation.
+https://parallaxsecond.github.io/parsec-book/
+
+Updating recipes
+================
+
+ The parsec-service and parsec-tool recipes use include files with lists
+of all rust crates required. This allows bitbake to fetch all the necessary
+dependent crates, as well as a pegged version of the crates.io index,
+to ensure maximum reproducibility.
+ It's recommended to use cargo-bitbake to generate include files for new
+versions of parsec recipes.
+https://github.com/meta-rust/cargo-bitbake
+
+ When you have crago-bitbake built:
+1. Checkout the required version of parsec repository.
+2. Run cargo-bitbake inside the repository. It will produce a BB file.
+3. Create a new include file with SRC_URI and LIC_FILES_CHKSUM from the BB file.
+
+Manual testing with runqemu
+===========================
+
+ This layer also contains a recipe for pasec-tool which can be used for
+manual testing of the Parsec service:
+
+ IMAGE_INSTALL_append += " parsec-tools"
+
+ There are a series of Parsec Demo videos showing how to use parsec-tool
+to test the Parsec service base functionality:
+https://www.youtube.com/watch?v=ido0CyUdMHM&list=PLKjl7IFAwc4S7WQqqphCsyy6DPDxJ2Skg&index=4
+
+ You can use runqemu to start a VM with a built image file and run
+manual tests with parsec-tool.
+
+1. MbedCrypto provider
+ The default Parsec service config file contains the MbedCrypto provider
+enabled. No changes required for manual testing.
+
+2. PKCS11 provider
+ The Software HSM can be used for manual testing of the provider by
+including it into your test image:
+
+ IMAGE_INSTALL_append += " softhsm"
+
+Inside the running VM:
+- Stop Parsec
+```bash
+systemctl stop parsec
+```
+- Initialise a token and notice the result slot number
+```bash
+softhsm2-util --init-token --slot 0 --label "Parsec Service" --pin 123456 --so-pin 123456
+```
+- Change the token ownership:
+```bash
+for d in /var/lib/softhsm/tokens/*; do chown -R parsec $d; done
+```
+- Enable the PKCS11 provider and update its parameters in the Parsec config file
+/etc/parsec/config.toml
+```
+library_path = "/usr/lib/softhsm/libsofthsm2.so"
+slot_number = <slot number>
+user_pin = "123456"
+```
+- Start Parsec
+```bash
+systemctl start parsec
+```
+
+3. TPM provider
+ The IBM Software TPM service can be used for manual testing of the provider by
+including it into your test image:
+
+ IMAGE_INSTALL_append += " ibmswtpm2 tpm2-tools libtss2 libtss2-tcti-mssim"
+
+Inside the running VM:
+- Stop Parsec
+```bash
+systemctl stop parsec
+```
+- Start and configure the Software TPM server
+```bash
+ /usr/bin/tpm_server &
+ sleep 5
+ /usr/bin/tpm2_startup -c -T mssim
+ /usr/bin/tpm2_changeauth -c owner tpm_pass
+```
+- Enable the TPM provider and update its parameters in the Parsec config file
+/etc/parsec/config.toml
+```
+tcti = "mssim"
+owner_hierarchy_auth = "hex:74706d5f70617373"
+```
+- Start Parsec
+```bash
+systemctl start parsec
+```
+
+Maintenance
+-----------
+
+Send pull requests, patches, comments or questions to yocto@...
+
+When sending single patches, please using something like:
+'git send-email -1 --to yocto@... --subject-prefix=meta-parsec][PATCH'
+
+These values can be set as defaults for this repository:
+
+$ git config sendemail.to yocto@...
+$ git config format.subjectPrefix meta-parsec][PATCH
+
+Now you can just do 'git send-email origin/master' to send all local patches.
+
+Maintainers: Anton Antonov <Anton.Antonov@...>
+ Armin Kuster <akuster808@...>
+
+
+License
+=======
+
+All metadata is MIT licensed unless otherwise stated. Source code included
+in tree for individual recipes is under the LICENSE stated in each recipe
+(.bb file) unless otherwise stated.
diff --git a/meta-parsec/conf/layer.conf b/meta-parsec/conf/layer.conf
new file mode 100644
index 0000000..2d4aa12
--- /dev/null
+++ b/meta-parsec/conf/layer.conf
@@ -0,0 +1,14 @@
+# We have a conf and classes directory, add to BBPATH
+BBPATH .= ":${LAYERDIR}"
+
+# We have a recipes directory, add to BBFILES
+BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
+
+BBFILE_COLLECTIONS += "parsec-layer"
+BBFILE_PATTERN_parsec-layer = "^${LAYERDIR}/"
+BBFILE_PRIORITY_parsec-layer = "5"
+
+LAYERSERIES_COMPAT_parsec-layer = "hardknott gatesgarth"
+
+LAYERDEPENDS_parsec-layer = "core rust-layer clang-layer tpm-layer"
+BBLAYERS_LAYERINDEX_NAME_parsec-layer = "meta-parsec"
diff --git a/meta-parsec/recipes-parsec/parsec-service/files/cryptoki.patch b/meta-parsec/recipes-parsec/parsec-service/files/cryptoki.patch
new file mode 100644
index 0000000..c234479
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/files/cryptoki.patch
@@ -0,0 +1,18 @@
+
+Use cryptoki v0.1.1 which supports the "generate-bindings" feature
+required for building Parsec service 0.7.0 in Yocto.
+
+Signed-off-by: Anton Antonov <Anton.Antonov@...>
+Upstream-Status: Submitted
+
+--- a/Cargo.toml 2021-04-01 10:29:50.333687763 +0100
++++ b/Cargo.toml 2021-04-01 10:27:13.051860002 +0100
+@@ -37,7 +37,7 @@
+ version = "1.3.1"
+
+ [dependencies.cryptoki]
+-version = "0.1.0"
++version = "0.1.1"
+ features = ["psa-crypto-conversions"]
+ optional = true
+
diff --git a/meta-parsec/recipes-parsec/parsec-service/files/parsec-tmpfiles.conf b/meta-parsec/recipes-parsec/parsec-service/files/parsec-tmpfiles.conf
new file mode 100644
index 0000000..fe576a2
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/files/parsec-tmpfiles.conf
@@ -0,0 +1,2 @@
+#Type Path Mode User Group Age Argument
+d /run/parsec 755 parsec parsec - -
diff --git a/meta-parsec/recipes-parsec/parsec-service/files/parsec_init b/meta-parsec/recipes-parsec/parsec-service/files/parsec_init
new file mode 100755
index 0000000..58a2897
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/files/parsec_init
@@ -0,0 +1,63 @@
+#! /bin/sh -e
+
+# ------------------------------------------------------------------------------
+# Copyright (c) 2021, Arm Limited, All Rights Reserved
+# SPDX-License-Identifier: Apache-2.0
+#
+# Licensed under the Apache License, Version 2.0 (the "License"); you may
+# not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+# ------------------------------------------------------------------------------
+
+# Parsec Service SysV init script
+
+test -x /usr/libexec/parsec/parsec || exit 0
+
+case "$1" in
+ start)
+ echo -n "Starting Parsec daemon: "
+ if [ ! -f /etc/parsec/config.toml ]; then
+ echo "There is no Parsec service configuration file."
+ else
+ if [ ! -d /run/parsec ]; then
+ mkdir /run/parsec
+ chown parsec:parsec /run/parsec
+ chmod 755 /run/parsec
+ fi
+ # start-stop-daemon used in poky busybox doesn't support
+ # '--chdir' parameter. So, let's do it manually
+ cd /var/lib/parsec
+ RUST_LOG=info start-stop-daemon --oknodo --start --background \
+ --chuid parsec:parsec --exec /usr/libexec/parsec/parsec \
+ -- --config /etc/parsec/config.toml
+ echo "parsec."
+ fi
+ ;;
+ stop)
+ echo -n "Stopping Parsec daemon: "
+ start-stop-daemon --oknodo --stop --exec /usr/libexec/parsec/parsec
+ echo "parsec."
+ ;;
+ reload)
+ echo -n "Reloading Parsec daemon: "
+ start-stop-daemon --stop --signal SIGHUP --exec /usr/libexec/parsec/parsec
+ echo "parsec."
+ ;;
+ restart|force-reload)
+ $0 stop
+ $0 start
+ ;;
+ *)
+ echo "Usage: /etc/init.d/parsec {start|stop|restart|reload|force-reload}"
+ exit 1
+esac
+
+exit 0
diff --git a/meta-parsec/recipes-parsec/parsec-service/files/systemd.patch b/meta-parsec/recipes-parsec/parsec-service/files/systemd.patch
new file mode 100644
index 0000000..c01ff06
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/files/systemd.patch
@@ -0,0 +1,19 @@
+
+Run the Parsec service as parsec user in /var/lib/parsec/ working directory.
+
+Signed-off-by: Anton Antonov <Anton.Antonov@...>
+Upstream-Status: Inappropriate [deployment configuration]
+
+--- a/systemd-daemon/parsec.service 2021-03-28 18:34:18.703196235 +0100
++++ b/systemd-daemon/parsec.service 2021-03-28 18:35:14.279830299 +0100
+@@ -3,7 +3,9 @@
+ Documentation=https://parallaxsecond.github.io/parsec-book/parsec_service/install_parsec_linux.html
+
+ [Service]
+-WorkingDirectory=/home/parsec/
++User=parsec
++Group=parsec
++WorkingDirectory=/var/lib/parsec/
+ ExecStart=/usr/libexec/parsec/parsec --config /etc/parsec/config.toml
+
+ [Install]
diff --git a/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
new file mode 100644
index 0000000..b3f7b21
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
@@ -0,0 +1,67 @@
+SUMMARY = "Platform AbstRaction for SECurity Daemon"
+HOMEPAGE = "https://github.com/parallaxsecond/parsec"
+LICENSE = "Apache-2.0"
+
+inherit cargo
+
+SRC_URI += "crate://crates.io/parsec-service/${PV} \
+ file://parsec_init \
+ file://systemd.patch \
+ file://parsec-tmpfiles.conf \
+"
+
+DEPENDS = "clang-native tpm2-tss"
+INSANE_SKIP_${PN} += "dev-deps"
+
+CARGO_BUILD_FLAGS += " --features all-providers,cryptoki/generate-bindings,tss-esapi/generate-bindings"
+
+inherit systemd
+SYSTEMD_SERVICE_${PN} = "parsec.service"
+
+inherit update-rc.d
+INITSCRIPT_NAME = "parsec"
+
+# A local file can be defined in build/local.conf
+# The file should also be included into SRC_URI then
+PARSEC_CONFIG ?= "${S}/config.toml"
+
+do_install_append () {
+ # Binaries
+ install -d -m 700 -o parsec -g parsec "${D}${libexecdir}/parsec"
+ install -m 700 -o parsec -g parsec "${WORKDIR}/build/target/${CARGO_TARGET_SUBDIR}/parsec" ${D}${libexecdir}/parsec/parsec
+
+ # Config file
+ install -d -m 700 -o parsec -g parsec "${D}${sysconfdir}/parsec"
+ install -m 400 -o parsec -g parsec "${PARSEC_CONFIG}" ${D}${sysconfdir}/parsec/config.toml
+
+ # Data dir
+ install -d -m 700 -o parsec -g parsec "${D}${localstatedir}/lib/parsec"
+
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
+ install -d ${D}${systemd_unitdir}/system
+ install -m 644 ${S}/systemd-daemon/parsec.service ${D}${systemd_unitdir}/system
+
+ install -d ${D}${libdir}/tmpfiles.d
+ install -m 644 ${WORKDIR}/parsec-tmpfiles.conf ${D}${libdir}/tmpfiles.d
+ fi
+
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'true', 'false', d)}; then
+ install -d ${D}${sysconfdir}/init.d
+ install -m 755 ${WORKDIR}/parsec_init ${D}${sysconfdir}/init.d/parsec
+ fi
+}
+
+inherit useradd
+USERADD_PACKAGES = "${PN}"
+USERADD_PARAM_${PN} = "-r -g parsec -s /bin/false -d ${localstatedir}/lib/parsec parsec"
+GROUPADD_PARAM_${PN} = "-r parsec"
+
+FILES_${PN} += " \
+ ${sysconfdir}/parsec/config.toml \
+ ${libexecdir}/parsec/parsec \
+ ${systemd_unitdir}/system/parsec.service \
+ ${libdir}/tmpfiles.d/parsec-tmpfiles.conf \
+ ${sysconfdir}/init.d/parsec \
+"
+
+require parsec-service_${PV}.inc
diff --git a/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.inc b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.inc
new file mode 100644
index 0000000..59a47f9
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.inc
@@ -0,0 +1,147 @@
+# This file is created from parsec-service repository Cargo.lock using cargo-bitbake tool
+
+SRC_URI += " \
+ crate://crates.io/aho-corasick/0.7.15 \
+ crate://crates.io/ansi_term/0.11.0 \
+ crate://crates.io/anyhow/1.0.38 \
+ crate://crates.io/atty/0.2.14 \
+ crate://crates.io/autocfg/1.0.1 \
+ crate://crates.io/base64/0.12.3 \
+ crate://crates.io/base64/0.13.0 \
+ crate://crates.io/bincode/1.3.2 \
+ crate://crates.io/bindgen/0.56.0 \
+ crate://crates.io/bindgen/0.57.0 \
+ crate://crates.io/bitfield/0.13.2 \
+ crate://crates.io/bitflags/1.2.1 \
+ crate://crates.io/byteorder/1.3.4 \
+ crate://crates.io/bytes/0.5.6 \
+ crate://crates.io/bytes/1.0.1 \
+ crate://crates.io/cc/1.0.67 \
+ crate://crates.io/cexpr/0.4.0 \
+ crate://crates.io/cfg-if/1.0.0 \
+ crate://crates.io/clang-sys/1.1.1 \
+ crate://crates.io/clap/2.33.3 \
+ crate://crates.io/cmake/0.1.45 \
+ crate://crates.io/cryptoauthlib-sys/0.1.0 \
+ crate://crates.io/cryptoki-sys/0.1.1 \
+ crate://crates.io/cryptoki/0.1.1 \
+ crate://crates.io/derivative/2.2.0 \
+ crate://crates.io/either/1.6.1 \
+ crate://crates.io/enumflags2/0.6.4 \
+ crate://crates.io/enumflags2_derive/0.6.4 \
+ crate://crates.io/env_logger/0.8.3 \
+ crate://crates.io/fixedbitset/0.2.0 \
+ crate://crates.io/getrandom/0.2.2 \
+ crate://crates.io/glob/0.3.0 \
+ crate://crates.io/hashbrown/0.9.1 \
+ crate://crates.io/heck/0.3.2 \
+ crate://crates.io/hermit-abi/0.1.18 \
+ crate://crates.io/hex/0.4.3 \
+ crate://crates.io/hostname-validator/1.0.0 \
+ crate://crates.io/humantime/2.1.0 \
+ crate://crates.io/indexmap/1.6.2 \
+ crate://crates.io/itertools/0.8.2 \
+ crate://crates.io/itertools/0.9.0 \
+ crate://crates.io/lazy_static/1.4.0 \
+ crate://crates.io/lazycell/1.3.0 \
+ crate://crates.io/libc/0.2.89 \
+ crate://crates.io/libloading/0.7.0 \
+ crate://crates.io/log/0.4.14 \
+ crate://crates.io/mbox/0.5.0 \
+ crate://crates.io/memchr/2.3.4 \
+ crate://crates.io/multimap/0.8.3 \
+ crate://crates.io/nom/5.1.2 \
+ crate://crates.io/num-bigint/0.3.2 \
+ crate://crates.io/num-complex/0.3.1 \
+ crate://crates.io/num-derive/0.3.3 \
+ crate://crates.io/num-integer/0.1.44 \
+ crate://crates.io/num-iter/0.1.42 \
+ crate://crates.io/num-rational/0.3.2 \
+ crate://crates.io/num-traits/0.2.14 \
+ crate://crates.io/num/0.3.1 \
+ crate://crates.io/num_cpus/1.13.0 \
+ crate://crates.io/oid/0.1.1 \
+ crate://crates.io/parsec-interface/0.24.0 \
+ crate://crates.io/peeking_take_while/0.1.2 \
+ crate://crates.io/petgraph/0.5.1 \
+ crate://crates.io/picky-asn1-der/0.2.4 \
+ crate://crates.io/picky-asn1-x509/0.4.0 \
+ crate://crates.io/picky-asn1/0.3.1 \
+ crate://crates.io/pkg-config/0.3.19 \
+ crate://crates.io/ppv-lite86/0.2.10 \
+ crate://crates.io/proc-macro-error-attr/1.0.4 \
+ crate://crates.io/proc-macro-error/1.0.4 \
+ crate://crates.io/proc-macro2/1.0.24 \
+ crate://crates.io/prost-build/0.6.1 \
+ crate://crates.io/prost-build/0.7.0 \
+ crate://crates.io/prost-derive/0.6.1 \
+ crate://crates.io/prost-derive/0.7.0 \
+ crate://crates.io/prost-types/0.6.1 \
+ crate://crates.io/prost-types/0.7.0 \
+ crate://crates.io/prost/0.6.1 \
+ crate://crates.io/prost/0.7.0 \
+ crate://crates.io/psa-crypto-sys/0.8.0 \
+ crate://crates.io/psa-crypto/0.8.0 \
+ crate://crates.io/quote/1.0.9 \
+ crate://crates.io/rand/0.8.3 \
+ crate://crates.io/rand_chacha/0.3.0 \
+ crate://crates.io/rand_core/0.6.2 \
+ crate://crates.io/rand_hc/0.3.0 \
+ crate://crates.io/redox_syscall/0.2.5 \
+ crate://crates.io/regex-syntax/0.6.23 \
+ crate://crates.io/regex/1.4.5 \
+ crate://crates.io/remove_dir_all/0.5.3 \
+ crate://crates.io/rust-cryptoauthlib/0.1.0 \
+ crate://crates.io/rustc-hash/1.1.0 \
+ crate://crates.io/rustc_version/0.2.3 \
+ crate://crates.io/same-file/1.0.6 \
+ crate://crates.io/sd-notify/0.2.0 \
+ crate://crates.io/secrecy/0.7.0 \
+ crate://crates.io/semver-parser/0.7.0 \
+ crate://crates.io/semver/0.9.0 \
+ crate://crates.io/serde/1.0.124 \
+ crate://crates.io/serde_bytes/0.11.5 \
+ crate://crates.io/serde_derive/1.0.124 \
+ crate://crates.io/shlex/0.1.1 \
+ crate://crates.io/signal-hook-registry/1.3.0 \
+ crate://crates.io/signal-hook/0.3.7 \
+ crate://crates.io/stable_deref_trait/1.2.0 \
+ crate://crates.io/strsim/0.8.0 \
+ crate://crates.io/structopt-derive/0.4.14 \
+ crate://crates.io/structopt/0.3.21 \
+ crate://crates.io/strum_macros/0.19.4 \
+ crate://crates.io/syn/1.0.64 \
+ crate://crates.io/synstructure/0.12.4 \
+ crate://crates.io/tempfile/3.2.0 \
+ crate://crates.io/termcolor/1.1.2 \
+ crate://crates.io/textwrap/0.11.0 \
+ crate://crates.io/thiserror-impl/1.0.24 \
+ crate://crates.io/thiserror/1.0.24 \
+ crate://crates.io/threadpool/1.8.1 \
+ crate://crates.io/toml/0.5.8 \
+ crate://crates.io/tss-esapi-sys/0.1.0 \
+ crate://crates.io/tss-esapi/5.0.0 \
+ crate://crates.io/unicode-segmentation/1.7.1 \
+ crate://crates.io/unicode-width/0.1.8 \
+ crate://crates.io/unicode-xid/0.2.1 \
+ crate://crates.io/users/0.11.0 \
+ crate://crates.io/uuid/0.8.2 \
+ crate://crates.io/vec_map/0.8.2 \
+ crate://crates.io/version/3.0.0 \
+ crate://crates.io/version_check/0.9.3 \
+ crate://crates.io/walkdir/2.3.1 \
+ crate://crates.io/wasi/0.10.2+wasi-snapshot-preview1 \
+ crate://crates.io/which/3.1.1 \
+ crate://crates.io/which/4.0.2 \
+ crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi-util/0.1.5 \
+ crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi/0.3.9 \
+ crate://crates.io/zeroize/1.2.0 \
+ crate://crates.io/zeroize_derive/1.0.1 \
+ file://cryptoki.patch \
+"
+
+LIC_FILES_CHKSUM = " \
+ file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57 \
+"
diff --git a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
new file mode 100644
index 0000000..939e771
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
@@ -0,0 +1,18 @@
+SUMMARY = "Parsec Command Line Interface"
+HOMEPAGE = "https://github.com/parallaxsecond/parsec-tool"
+LICENSE = "Apache-2.0"
+
+inherit cargo
+
+SRC_URI += "crate://crates.io/parsec-tool/${PV} \
+"
+
+DEPENDS = "clang-native"
+INSANE_SKIP_${PN} += "dev-deps"
+
+do_install() {
+ install -d ${D}/${bindir}
+ install -m 755 "${B}/target/${TARGET_SYS}/release/parsec-tool" "${D}${bindir}/parsec-tool"
+}
+
+require parsec-tool_${PV}.inc
diff --git a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.inc b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.inc
new file mode 100644
index 0000000..9560dcf
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.inc
@@ -0,0 +1,127 @@
+# This file is created from parsec-tool repository Cargo.lock using cargo-bitbake tool
+
+SRC_URI += " \
+ crate://crates.io/aho-corasick/0.7.15 \
+ crate://crates.io/ansi_term/0.11.0 \
+ crate://crates.io/ansi_term/0.12.1 \
+ crate://crates.io/anyhow/1.0.38 \
+ crate://crates.io/atty/0.2.14 \
+ crate://crates.io/autocfg/1.0.1 \
+ crate://crates.io/base64/0.13.0 \
+ crate://crates.io/bincode/1.3.1 \
+ crate://crates.io/bitflags/1.2.1 \
+ crate://crates.io/block-buffer/0.9.0 \
+ crate://crates.io/byteorder/1.4.2 \
+ crate://crates.io/bytes/0.5.6 \
+ crate://crates.io/cc/1.0.66 \
+ crate://crates.io/cfg-if/1.0.0 \
+ crate://crates.io/clap/2.33.3 \
+ crate://crates.io/clap/3.0.0-beta.2 \
+ crate://crates.io/clap_derive/3.0.0-beta.2 \
+ crate://crates.io/cmake/0.1.45 \
+ crate://crates.io/cpuid-bool/0.1.2 \
+ crate://crates.io/derivative/2.2.0 \
+ crate://crates.io/digest/0.9.0 \
+ crate://crates.io/either/1.6.1 \
+ crate://crates.io/env_logger/0.8.3 \
+ crate://crates.io/fixedbitset/0.2.0 \
+ crate://crates.io/form_urlencoded/1.0.0 \
+ crate://crates.io/generic-array/0.14.4 \
+ crate://crates.io/getrandom/0.2.2 \
+ crate://crates.io/hashbrown/0.9.1 \
+ crate://crates.io/heck/0.3.2 \
+ crate://crates.io/hermit-abi/0.1.18 \
+ crate://crates.io/humantime/2.1.0 \
+ crate://crates.io/idna/0.2.1 \
+ crate://crates.io/indexmap/1.6.1 \
+ crate://crates.io/itertools/0.8.2 \
+ crate://crates.io/lazy_static/1.4.0 \
+ crate://crates.io/libc/0.2.86 \
+ crate://crates.io/log/0.4.14 \
+ crate://crates.io/matches/0.1.8 \
+ crate://crates.io/memchr/2.3.4 \
+ crate://crates.io/multimap/0.8.2 \
+ crate://crates.io/num-bigint/0.3.1 \
+ crate://crates.io/num-complex/0.3.1 \
+ crate://crates.io/num-derive/0.3.3 \
+ crate://crates.io/num-integer/0.1.44 \
+ crate://crates.io/num-iter/0.1.42 \
+ crate://crates.io/num-rational/0.3.2 \
+ crate://crates.io/num-traits/0.2.14 \
+ crate://crates.io/num/0.3.1 \
+ crate://crates.io/oid/0.1.1 \
+ crate://crates.io/once_cell/1.5.2 \
+ crate://crates.io/opaque-debug/0.3.0 \
+ crate://crates.io/os_str_bytes/2.4.0 \
+ crate://crates.io/parsec-client/0.12.0 \
+ crate://crates.io/parsec-interface/0.24.0 \
+ crate://crates.io/pem/0.8.3 \
+ crate://crates.io/percent-encoding/2.1.0 \
+ crate://crates.io/petgraph/0.5.1 \
+ crate://crates.io/picky-asn1-der/0.2.4 \
+ crate://crates.io/picky-asn1/0.3.1 \
+ crate://crates.io/ppv-lite86/0.2.10 \
+ crate://crates.io/proc-macro-error-attr/1.0.4 \
+ crate://crates.io/proc-macro-error/1.0.4 \
+ crate://crates.io/proc-macro2/1.0.24 \
+ crate://crates.io/prost-build/0.6.1 \
+ crate://crates.io/prost-derive/0.6.1 \
+ crate://crates.io/prost-types/0.6.1 \
+ crate://crates.io/prost/0.6.1 \
+ crate://crates.io/psa-crypto-sys/0.8.0 \
+ crate://crates.io/psa-crypto/0.8.0 \
+ crate://crates.io/quote/1.0.9 \
+ crate://crates.io/rand/0.8.3 \
+ crate://crates.io/rand_chacha/0.3.0 \
+ crate://crates.io/rand_core/0.6.2 \
+ crate://crates.io/rand_hc/0.3.0 \
+ crate://crates.io/redox_syscall/0.2.5 \
+ crate://crates.io/regex-syntax/0.6.22 \
+ crate://crates.io/regex/1.4.3 \
+ crate://crates.io/remove_dir_all/0.5.3 \
+ crate://crates.io/same-file/1.0.6 \
+ crate://crates.io/secrecy/0.7.0 \
+ crate://crates.io/serde/1.0.123 \
+ crate://crates.io/serde_bytes/0.11.5 \
+ crate://crates.io/serde_derive/1.0.123 \
+ crate://crates.io/sha2/0.9.3 \
+ crate://crates.io/strsim/0.10.0 \
+ crate://crates.io/strsim/0.8.0 \
+ crate://crates.io/structopt-derive/0.4.14 \
+ crate://crates.io/structopt/0.3.21 \
+ crate://crates.io/syn/1.0.60 \
+ crate://crates.io/synstructure/0.12.4 \
+ crate://crates.io/tempfile/3.2.0 \
+ crate://crates.io/termcolor/1.1.2 \
+ crate://crates.io/textwrap/0.11.0 \
+ crate://crates.io/textwrap/0.12.1 \
+ crate://crates.io/thiserror-impl/1.0.23 \
+ crate://crates.io/thiserror/1.0.23 \
+ crate://crates.io/thread_local/1.1.3 \
+ crate://crates.io/tinyvec/1.1.1 \
+ crate://crates.io/tinyvec_macros/0.1.0 \
+ crate://crates.io/typenum/1.12.0 \
+ crate://crates.io/unicode-bidi/0.3.4 \
+ crate://crates.io/unicode-normalization/0.1.17 \
+ crate://crates.io/unicode-segmentation/1.7.1 \
+ crate://crates.io/unicode-width/0.1.8 \
+ crate://crates.io/unicode-xid/0.2.1 \
+ crate://crates.io/url/2.2.0 \
+ crate://crates.io/users/0.10.0 \
+ crate://crates.io/uuid/0.8.2 \
+ crate://crates.io/vec_map/0.8.2 \
+ crate://crates.io/version_check/0.9.2 \
+ crate://crates.io/walkdir/2.3.1 \
+ crate://crates.io/wasi/0.10.2+wasi-snapshot-preview1 \
+ crate://crates.io/which/3.1.1 \
+ crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi-util/0.1.5 \
+ crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi/0.3.9 \
+ crate://crates.io/zeroize/1.2.0 \
+ crate://crates.io/zeroize_derive/1.0.1 \
+"
+
+LIC_FILES_CHKSUM = " \
+ file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57 \
+"



Re: [meta-security][PATCH] initramfs-framework-ima: introduce IMA_FORCE

Armin Kuster
 

merged,
Thanks

On 4/8/21 11:38 AM, Ming Liu wrote:
From: Ming Liu <liu.ming50@...>

Introduce IMA_FORCE to allow the IMA policy be applied forcely even
'no_ima' boot parameter is available.

This ensures the end users have a way to disable 'no_ima' support if
they want to, because it may expose a security risk if an attacker can
find a way to change kernel arguments, it will easily bypass rootfs
authenticity checks.

Signed-off-by: Sergio Prado <sergio.prado@...>
Signed-off-by: Ming Liu <liu.ming50@...>
---
.../initrdscripts/initramfs-framework-ima.bb | 5 +++++
.../initrdscripts/initramfs-framework-ima/ima | 9 +++++++--
2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
index 77f6f7c..6471c53 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
@@ -14,6 +14,9 @@ LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384
# to this recipe can just point towards one of its own files.
IMA_POLICY ?= "ima-policy-hashed"

+# Force proceed IMA procedure even 'no_ima' boot parameter is available.
+IMA_FORCE ?= "false"
+
SRC_URI = " file://ima"

inherit features_check
@@ -23,6 +26,8 @@ do_install () {
install -d ${D}/${sysconfdir}/ima
install -d ${D}/init.d
install ${WORKDIR}/ima ${D}/init.d/20-ima
+
+ sed -i "s/@@FORCE_IMA@@/${IMA_FORCE}/g" ${D}/init.d/20-ima
}

FILES_${PN} = "/init.d ${sysconfdir}"
diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
index cff26a3..8971494 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
@@ -2,11 +2,16 @@
#
# Loads IMA policy into the kernel.

+force_ima=@@FORCE_IMA@@
+
ima_enabled() {
- if [ "$bootparam_no_ima" = "true" ]; then
+ if [ "$force_ima" = "true" ]; then
+ return 0
+ elif [ "$bootparam_no_ima" = "true" ]; then
return 1
+ else
+ return 0
fi
- return 0
}

ima_run() {



Re: [meta-security][PATCH] Use libest "main" branch instead of "master".

Armin Kuster
 

merged

thanks,
armin

On 4/7/21 3:19 AM, Anton Antonov wrote:
This patch fixes the issue:

WARNING: libest-3.2.0-r0 do_fetch: Failed to fetch URL git://github.com/cisco/libest, attempting MIRRORS if available
ERROR: libest-3.2.0-r0 do_fetch: Fetcher failure: Unable to find revision 4ca02c6d7540f2b1bcea278a4fbe373daac7103b in branch master even from upstream
ERROR: libest-3.2.0-r0 do_fetch: Fetcher failure for URL: 'git://github.com/cisco/libest'. Unable to fetch URL from any source.

Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
recipes-security/libest/libest_3.2.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/libest/libest_3.2.0.bb b/recipes-security/libest/libest_3.2.0.bb
index f993bd6..5b6dc99 100644
--- a/recipes-security/libest/libest_3.2.0.bb
+++ b/recipes-security/libest/libest_3.2.0.bb
@@ -6,7 +6,7 @@ LICENSE = "OpenSSL"
LIC_FILES_CHKSUM = "file://LICENSE;md5=ecb78acde8e3b795de8ef6b61aed5885"

SRCREV = "4ca02c6d7540f2b1bcea278a4fbe373daac7103b"
-SRC_URI = "git://github.com/cisco/libest"
+SRC_URI = "git://github.com/cisco/libest;branch=main"

DEPENDS = "openssl"




Re: [meta-security][PATCH] meta: drop IMA_POLICY from policy recipes

Armin Kuster
 

merged.

thanks
-armin

On 3/22/21 6:02 AM, liu.ming50@... wrote:
From: Ming Liu <liu.ming50@...>

IMA_POLICY is being referred as policy recipe name in some places and it
is also being referred as policy file in other places, they are
conflicting with each other which make it impossible to set a IMA_POLICY
global variable in config file.

Fix it by dropping IMA_POLICY definitions from policy recipes

Signed-off-by: Ming Liu <liu.ming50@...>
---
.../ima-policy-appraise-all_1.0.bb | 9 ++-------
.../ima_policy_hashed/ima-policy-hashed_1.0.bb | 9 ++-------
.../ima_policy_simple/ima-policy-simple_1.0.bb | 9 ++-------
3 files changed, 6 insertions(+), 21 deletions(-)

diff --git a/meta-integrity/recipes-security/ima_policy_appraise_all/ima-policy-appraise-all_1.0.bb b/meta-integrity/recipes-security/ima_policy_appraise_all/ima-policy-appraise-all_1.0.bb
index da62a4c..84ea161 100644
--- a/meta-integrity/recipes-security/ima_policy_appraise_all/ima-policy-appraise-all_1.0.bb
+++ b/meta-integrity/recipes-security/ima_policy_appraise_all/ima-policy-appraise-all_1.0.bb
@@ -2,19 +2,14 @@ SUMMARY = "IMA sample simple appraise policy "
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

-# This policy file will get installed as /etc/ima/ima-policy.
-# It is located via the normal file search path, so a .bbappend
-# to this recipe can just point towards one of its own files.
-IMA_POLICY ?= "ima_policy_appraise_all"
-
-SRC_URI = " file://${IMA_POLICY}"
+SRC_URI = " file://ima_policy_appraise_all"

inherit features_check
REQUIRED_DISTRO_FEATURES = "ima"

do_install () {
install -d ${D}/${sysconfdir}/ima
- install ${WORKDIR}/${IMA_POLICY} ${D}/${sysconfdir}/ima/ima-policy
+ install ${WORKDIR}/ima_policy_appraise_all ${D}/${sysconfdir}/ima/ima-policy
}

FILES_${PN} = "${sysconfdir}/ima"
diff --git a/meta-integrity/recipes-security/ima_policy_hashed/ima-policy-hashed_1.0.bb b/meta-integrity/recipes-security/ima_policy_hashed/ima-policy-hashed_1.0.bb
index ebb0426..ff7169e 100644
--- a/meta-integrity/recipes-security/ima_policy_hashed/ima-policy-hashed_1.0.bb
+++ b/meta-integrity/recipes-security/ima_policy_hashed/ima-policy-hashed_1.0.bb
@@ -2,13 +2,8 @@ SUMMARY = "IMA sample hash policy"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

-# This policy file will get installed as /etc/ima/ima-policy.
-# It is located via the normal file search path, so a .bbappend
-# to this recipe can just point towards one of its own files.
-IMA_POLICY ?= "ima_policy_hashed"
-
SRC_URI = " \
- file://${IMA_POLICY} \
+ file://ima_policy_hashed \
"

inherit features_check
@@ -16,7 +11,7 @@ REQUIRED_DISTRO_FEATURES = "ima"

do_install () {
install -d ${D}/${sysconfdir}/ima
- install ${WORKDIR}/${IMA_POLICY} ${D}/${sysconfdir}/ima/ima-policy
+ install ${WORKDIR}/ima_policy_hashed ${D}/${sysconfdir}/ima/ima-policy
}

FILES_${PN} = "${sysconfdir}/ima"
diff --git a/meta-integrity/recipes-security/ima_policy_simple/ima-policy-simple_1.0.bb b/meta-integrity/recipes-security/ima_policy_simple/ima-policy-simple_1.0.bb
index cb4b6b8..0e56aec 100644
--- a/meta-integrity/recipes-security/ima_policy_simple/ima-policy-simple_1.0.bb
+++ b/meta-integrity/recipes-security/ima_policy_simple/ima-policy-simple_1.0.bb
@@ -2,19 +2,14 @@ SUMMARY = "IMA sample simple policy"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

-# This policy file will get installed as /etc/ima/ima-policy.
-# It is located via the normal file search path, so a .bbappend
-# to this recipe can just point towards one of its own files.
-IMA_POLICY ?= "ima_policy_simple"
-
-SRC_URI = " file://${IMA_POLICY}"
+SRC_URI = " file://ima_policy_simple"

inherit features_check
REQUIRED_DISTRO_FEATURES = "ima"

do_install () {
install -d ${D}/${sysconfdir}/ima
- install ${WORKDIR}/${IMA_POLICY} ${D}/${sysconfdir}/ima/ima-policy
+ install ${WORKDIR}/ima_policy_simple ${D}/${sysconfdir}/ima/ima-policy
}

FILES_${PN} = "${sysconfdir}/ima"


[meta-security][PATCH] gitlab-ci: Move all parsec builds into a separate job

Anton Antonov
 

Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
.gitlab-ci.yml | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f673ef6..f155ba0 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -27,7 +27,6 @@ qemux86:
extends: .build
script:
- kas build --target security-build-image kas/$CI_JOB_NAME.yml
- - kas build --target security-build-image kas/$CI_JOB_NAME-parsec.yml
- kas build --target security-build-image kas/$CI_JOB_NAME-comp.yml
- kas build --target harden-image-minimal kas/$CI_JOB_NAME-harden.yml
- kas build --target integrity-image-minimal kas/$CI_JOB_NAME-ima.yml
@@ -36,7 +35,6 @@ qemux86-64:
extends: .build
script:
- kas build --target security-build-image kas/$CI_JOB_NAME.yml
- - kas build --target security-build-image kas/$CI_JOB_NAME-parsec.yml
- kas build --target dm-verity-image-initramfs kas/$CI_JOB_NAME-dm-verify.yml
- kas build --target integrity-image-minimal kas/$CI_JOB_NAME-ima.yml

@@ -44,20 +42,17 @@ qemuarm:
extends: .build
script:
- kas build --target security-build-image kas/$CI_JOB_NAME.yml
- - kas build --target security-build-image kas/$CI_JOB_NAME-parsec.yml

qemuarm64:
extends: .build
script:
- kas build --target security-build-image kas/$CI_JOB_NAME.yml
- - kas build --target security-build-image kas/$CI_JOB_NAME-parsec.yml
- kas build --target integrity-image-minimal kas/$CI_JOB_NAME-ima.yml

qemuppc:
extends: .build
script:
- kas build --target security-build-image kas/$CI_JOB_NAME.yml
- - kas build --target security-build-image kas/$CI_JOB_NAME-parsec.yml

qemumips64:
extends: .build
@@ -127,3 +122,12 @@ qemux86-test:
- kas build --target security-test-image kas/$CI_JOB_NAME.yml
- kas build -c testimage --target security-test-image kas/$CI_JOB_NAME.yml

+
+parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/qemuarm-$CI_JOB_NAME.yml
+ - kas build --target security-build-image kas/qemuarm64-$CI_JOB_NAME.yml
+ - kas build --target security-build-image kas/qemux86-$CI_JOB_NAME.yml
+ - kas build --target security-build-image kas/qemux86-64-$CI_JOB_NAME.yml
+ - kas build --target security-build-image kas/qemuppc-$CI_JOB_NAME.yml
--
2.20.1


Re: bitbake controlling memory use

Richard Purdie
 

On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:
On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:
make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

   -l [N], --load-average[=N], --max-load[=N]
                               Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)
During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237

Cheers,

Richard


Re: bitbake controlling memory use

Khem Raj
 

I use

BUILDHISTORY_COMMIT_forcevariable = "1"
PARALLEL_MAKE = "-j 11"
BB_NUMBER_THREADS = "11"
INHERIT += "rm_work"
XZ_DEFAULTS = "--threads=8"

On Tue, Apr 13, 2021 at 6:15 PM Randy MacLeod
<randy.macleod@...> wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:
make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

-l [N], --load-average[=N], --max-load[=N]
Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)
During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.

Someone mentioned that while ninja has not been open to accepting any
patches that would complicate and potentially slow down builds, there
is a fork of ninja calls 'samurai' that does seem to be open to some
improvements that we could benefit from.

It was also suggested that there were existing defects in the YP BZ (2)
but I didn't find any earlier and it's too late in my day to start
looking now! If no one replies with a relevant BZ ID, I'll create one.

I'm sure I missed some things that were mentioned but Trevor Woerner
sometimes takes notes so I'll check on them once / if they are sent out.

../Randy


1) https://www.yoctoproject.org/public-virtual-meetings/

2) https://bugzilla.yoctoproject.org/


Alex

On Sun, 11 Apr 2021 at 18:08, Gmane Admin <gley-yocto@m.gmane-mx.org
<mailto:gley-yocto@m.gmane-mx.org>> wrote:

Op 11-04-2021 om 17:55 schreef Alexander Kanavin:
> On Sun, 11 Apr 2021 at 17:49, Gmane Admin
<gley-yocto@m.gmane-mx.org <mailto:gley-yocto@m.gmane-mx.org>
> <mailto:gley-yocto@m.gmane-mx.org
<mailto:gley-yocto@m.gmane-mx.org>>> wrote:
>
> Yes, and make project doesn't care, because make is called
with -j
> 16 so
> that is what it does.
>
> So here's my pitch: bitbake can stop processes spawned by
make, because
> it knows that it started make on 4 recipies, each with -j 16. The
> individual makes don't know about each other.
>
>
> And neither they should. They can simply abstain from spawning new
> compilers if used RAM is, say, at 90% total. Then bitbake does
not have
> to get involved in babysitting those makes.
>
> Alex
Bitbake does a lot of babysitting anyway :-) And is pretty good at
it too.

To me, fixing make et al. is more work and less effective then adding a
feature to bitbake. The only way to know how much memory the compiler
will use for each spawned compiler is to let it run. And then it's
too late.

This memory issue is all over our eco system and nobody cares (kernel,
make etc.) The only thing moving is systemd's oom killer will arrive
and
start killing processes. So that will just stop our builds from
completing.

Yeah, I prefer a babysitter over a child murderer :-)

Ferry








--
# Randy MacLeod
# Wind River Linux


4701 - 4720 of 57806