Date   

#golang: go fetches dependencies in compile phase

Juergen Landwehr
 

Hi Alex,

OK, understood.

If the "local download cache path" is well-known (this is not by any chance $DL_DIR?), then we could create a tar from the vendor directory (which is created when you call "go mod vendor" and contains all the downloaded dependencies) and put this tar file into the download cache.

Before actually calling "go mod vendor", we would first check, if there is a tar file for the vendor directory in the download cache and if so simply unpack the tar.

Does this make sense, or am I too naive and this is just nonsense?

Jürgen


Re: #golang: go fetches dependencies in compile phase

Alexander Kanavin
 

On Mon, 12 Apr 2021 at 13:47, Juergen Landwehr <juergen.landwehr@...> wrote:
But dependency management in go is not that arbitrary as it may seem. 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?

Reproducibility means anyone can run a build at any point in the future even if the upstream repositories are gone, so all inputs must be stored in a local download cache, which is the other thing SRC_URI guarantees, in addition to verifying integrity of the inputs.

Alex


#golang: go fetches dependencies in compile phase

Juergen Landwehr
 

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. 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?

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 & ...

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.

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:))


Re: #golang: go fetches dependencies in compile phase

Robert Berger
 

On 09/04/2021 16:53, Juergen Landwehr wrote:
Hi,
we are developing an application in go and use the "go-mod" bb-class from poky. This works fine.
However, the problem is, that the dependencies in go.mod are now fetched in the compile phase and not in the fetch phase.
Alexander (whom you cc'ed here as well) wrote a long time ago on the mailing list[1] about this stuff.

We have a couple of issues with those "modern" languages like go, which behave quite differently from good old Unix stuff. So the paradigm on which the whole Bitbake/OpenEmbedded/Yocto system was built does not quite apply for those.

Don't get me wrong, you can also do stupidities like git clone via make or cmake, but this is most likely not the way those tools should be used.

1) "Guaranteed __NOT__ reproducible builds"(C)

Go pulls in dependencies by itself, which might explain why it's in the compile phase and not it the fetch phase.

This leads to many interesting issues, like "guaranteed __NOT__ reproducible builds"(C). The problem is, that you don't have any influence on dependencies of dependencies. Someone changes somewhere a dependency on github and the party starts.

1.1) One sane solution to "please give me always the same input" is what Konrad already mentioned in combination with a local golang proxy.

2) Open Source License Compliance

If you pull in all those funny dependencies and also link things statically, like with go, Open Source License Compliance is getting very interesting.

People typically just use the license of the top level "main" entry point. In reality you would need to check all the dependency tree for licenses. You should also check if it's legally allowed to combine the licenses and in case it's allowed what are implications of GPLvx, LGPLv2, LGPLv3 without exceptions for your product.

[1] https://www.yoctoproject.org/pipermail/yocto/2017-March/035028.html

Regards,

Robert


#golang: go fetches dependencies in compile phase

Juergen Landwehr
 

Hello Konrad,

thanks for your reply.

It is interesting that you mention vendoring, because we tried this approach as well. We started to develop a "go-mod-vendor.bbclass", which retrieves the
application source code in "do_fetch_append" and then calls "go mod vendor".

The big problem was, that in that phase there is not yet a go executable available for the recipe, so we downloaded our own go version, which makes this approach a bit ugly.

But there is already a go version installed on the build host, right? In "poky/meta/recipes-devtools/go" I found a "go-native_1.14.bb" recipe.
So can we use this go exectuable somehow by adding a dependency (e.g. DEPENDS="go-native") and then use a path to the go exectuable that is guaranteed to work?

The other alternative (defining a recipe for each dependent go module) sounds really painful. Especially as we have quite a few dependencies, which have dependencies as well.
I see the point, that doing it that way makes it more visible and more Yocto like, but thinking about it gives me headaches already :)

Thanks again.


Re: bitbake controlling memory use

Mike Looijmans
 

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@...
W: www.topic.nl

Please consider the environment before printing this e-mail
On 11-04-2021 17:23, Gmane Admin via lists.yoctoproject.org wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).
Been there, done that (8/16 cores with 8GB RAM).

The major cause is that bitbake will not just spawn 16 compiler threads, it will actually spawn up to 16 "do_compile" tasks which may spawn 16 compiler processes each, thus you'll be running a whopping 256 compilers. Bitbake may spawn a total of n^2 threads by default with "n" the detected number of cores.

The workaround I used was to limit the number of bitbake threads but leave the make threads at 16. Since most software these days is using parallel make, the impact on the build time of reducing the bb threads to 8 or 4 is negligible.

As for translating this into a bitbake feature, an implementation that comes to mind is to add a "weight" to each task. Most tasks would get a weight of just "1", but a (multithreaded) compile would be weighted "8" (some formula involving the number of CPUs) or so. This would stop bitbake spawning more processes early so that you don't get into the n^2 threads problem, and the number of processed that bitbake will spawn will be close to linear agin instead of quadratic as is is now.

Recipes that have excessive memory loads (usually C++ template meta-programming) can then just increase the weighting for the compile task.


--
Mike Looijmans


Re: bitbake controlling memory use

Robert Berger
 

Hi,

My comments are in-line.

On 11/04/2021 18:23, Gmane Admin wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).
16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.
The RAM usage depends heavily on what you are building ;) - It could be some crazy C++ stuff ;)

Is Linux your build host?

Then you can use cgroups to limit resources like memory.

Do you use a build container? It uses cgroups underneath.

e.g. docker:

https://docs.docker.com/config/containers/resource_constraints/

Regards,

Robert


Re: bitbake controlling memory use

Chen Qi
 

I think you write a script to do all the WATCH-STOP-CONTINUE stuff.
e.g.
memwatch bitbake core-image-minimal
Options could be added.
e.g.
memwatch --interval 5 --logfile test.log bitbake core-image-minimal

This script first becomes a session leader, then forks to start the 'bitbake' command as its child process.
Then, every several seconds (say 10s by default), it checks the current memory usage, and according to its policy, determines whether to stop/continue some process or not.

For stopping the process, you can first get all its child process by simply using the 'ps' command.
e.g.
$ ps o vsize,comm,pid -s 28303 | sort -n -r
317284 emacs           12883
 28912 ps              36302
 26248 sort            36303
 21432 man             24797
 17992 bash            28303
  9852 pager           24807
   VSZ COMMAND           PID

Then skip the bitbake processes, stop the first one that uses the largest memory, record its PID.

For continuing processes, just start it according to the records. Maybe using FILO by default?

Best Regards,
Chen Qi

On 04/11/2021 11:23 PM, Gmane Admin wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.

In fact the swapping is so excessive that just this single recipe determines largely the total image build time. However restricting bitbake (or actually parallel make) to use only 4 cores + HT sounds also like a waste.

I know this has been looked at in the past, but I think it needs fundamental resolving (other then, hé, why not add just another stick of memory).

What I do manually when I run into swapping so bad my desktop becomes unresponsive is ssh from another machine and then stop (not kill) the processes that use the most memory.

These then get swapped out, but not back in, allowing the remaining tasks to complete without swapping. Then when sufficient memory becomes free again I continue the stopped processes.

Isn't this something that could be added to bitbake to automate using memory efficiently?







Re: bitbake controlling memory use

Alexander Kanavin
 

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 :)

Alex


On Sun, 11 Apr 2021 at 18:08, Gmane Admin <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>> 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





Re: bitbake controlling memory use

Gmane Admin
 

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>> 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


Re: bitbake controlling memory use

Alexander Kanavin
 

On Sun, 11 Apr 2021 at 17:49, Gmane Admin <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


Re: bitbake controlling memory use

Gmane Admin
 

Op 11-04-2021 om 17:27 schreef Alexander Kanavin:
This has been discussed several times in the past - the conclusion usually is that first this needs to be addresses upstream in make and ninja, e.g. that they support throttling new compiler instances when memory gets tight. Once that is available, bitbake can follow by throttling its own tasks as well.
Alex
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 normally it's not an issue (compiling c), but sometimes compiling c++ it explodes (I saw 4GB ram in use for 1 g++ and there were 4 of them).

On Sun, 11 Apr 2021 at 17:23, Gmane Admin <gley-yocto@m.gmane-mx.org <mailto:gley-yocto@m.gmane-mx.org>> wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes
16. However I have (only?) 16GB of RAM (+24GB swap space).
16GB of RAM has always been more then enough with 4 core + HT, but now
building certain recipes (nodejs, but rust will probably do it as well)
eats up more memory then there actually is RAM causing excessive
swapping.
In fact the swapping is so excessive that just this single recipe
determines largely the total image build time. However restricting
bitbake (or actually parallel make) to use only 4 cores + HT sounds
also
like a waste.
I know this has been looked at in the past, but I think it needs
fundamental resolving (other then, hé, why not add just another
stick of
memory).
What I do manually when I run into swapping so bad my desktop becomes
unresponsive is ssh from another machine and then stop (not kill) the
processes that use the most memory.
These then get swapped out, but not back in, allowing the remaining
tasks to complete without swapping. Then when sufficient memory becomes
free again I continue the stopped processes.
Isn't this something that could be added to bitbake to automate using
memory efficiently?


Re: bitbake controlling memory use

Alexander Kanavin
 

This has been discussed several times in the past - the conclusion usually is that first this needs to be addresses upstream in make and ninja, e.g. that they support throttling new compiler instances when memory gets tight. Once that is available, bitbake can follow by throttling its own tasks as well.

Alex


On Sun, 11 Apr 2021 at 17:23, Gmane Admin <gley-yocto@m.gmane-mx.org> wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes
16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now
building certain recipes (nodejs, but rust will probably do it as well)
eats up more memory then there actually is RAM causing excessive swapping.

In fact the swapping is so excessive that just this single recipe
determines largely the total image build time. However restricting
bitbake (or actually parallel make) to use only 4 cores + HT sounds also
like a waste.

I know this has been looked at in the past, but I think it needs
fundamental resolving (other then, hé, why not add just another stick of
memory).

What I do manually when I run into swapping so bad my desktop becomes
unresponsive is ssh from another machine and then stop (not kill) the
processes that use the most memory.

These then get swapped out, but not back in, allowing the remaining
tasks to complete without swapping. Then when sufficient memory becomes
free again I continue the stopped processes.

Isn't this something that could be added to bitbake to automate using
memory efficiently?





bitbake controlling memory use

Gmane Admin
 

My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.

In fact the swapping is so excessive that just this single recipe determines largely the total image build time. However restricting bitbake (or actually parallel make) to use only 4 cores + HT sounds also like a waste.

I know this has been looked at in the past, but I think it needs fundamental resolving (other then, hé, why not add just another stick of memory).

What I do manually when I run into swapping so bad my desktop becomes unresponsive is ssh from another machine and then stop (not kill) the processes that use the most memory.

These then get swapped out, but not back in, allowing the remaining tasks to complete without swapping. Then when sufficient memory becomes free again I continue the stopped processes.

Isn't this something that could be added to bitbake to automate using memory efficiently?


Re: #golang: go fetches dependencies in compile phase

Konrad Weihmann <kweihmann@...>
 

Well AFAIK your observation is correct, go-mod.bbclass doesn't work a in BB_NO_NETWORK-safe manner.
What you could do is to provide all the dependencies manually and add them via DEPENDS, which is grant the behavior expected.

The bad thing about go is that chances of circular dependencies of go modules are relatively high.

I've also seen a few approaches using vendoring to escape this, but I'm afraid none of the code is pretty well tested nor publicly available.

If you'd ask me, I would go the long painful road of providing each required go module as a recipe of it's own and inject it into the final recipe - this also makes it pretty visible what you're pulling into your build in terms of licensing a.s.o.

On 09.04.21 15:53, Juergen Landwehr wrote:
Hi,
we are developing an application in go and use the "go-mod" bb-class from poky. This works fine.
However, the problem is, that the dependencies in go.mod are now fetched in the compile phase and not in the fetch phase.
This is not allowed in our project setup and kind of contradicts the Yocto paradigmn of having a fetch and a compile phase.
Is there a way to avoid this or some other solution that we could use?
Thanks,
Jürgen


#golang: go fetches dependencies in compile phase

Juergen Landwehr
 

Hi,
 
we are developing an application in go and use the "go-mod" bb-class from poky. This works fine.
 
However, the problem is, that the dependencies in go.mod are now fetched in the compile phase and not in the fetch phase.
 
This is not allowed in our project setup and kind of contradicts the Yocto paradigmn of having a fetch and a compile phase.
 
Is there a way to avoid this or some other solution that we could use?
 
Thanks,
 
Jürgen


pycoral recipe

Marek Belisko
 

Hi,

Just want to ask if anyone working/can share a recipe for a pycoral
package (https://github.com/google-coral/pycoral). I have some
barebone but seems not straightforward. It's using bazel build system
and as I understand it needs to add some patch for adding yocto
compiler otherwise it fails with:

Error in which: Program argument of which() may not contains a / or a
\ ('arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4
-mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/home/test/recipe-sysroot' given)

Any suggestions?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


[meta-security][PATCH 2/2] Define secure images with parsec-service and parsec-tool included and add the images into gitlab CI

Anton Antonov
 

From: Anton Antonov <anton.antonov@...>

Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
.gitlab-ci.yml | 25 +++++++++++++++++++++++++
kas/kas-security-parsec.yml | 21 +++++++++++++++++++++
kas/qemuarm-parsec.yml | 6 ++++++
kas/qemuarm64-parsec.yml | 6 ++++++
kas/qemuppc-parsec.yml | 6 ++++++
kas/qemux86-64-parsec.yml | 6 ++++++
kas/qemux86-parsec.yml | 6 ++++++
7 files changed, 76 insertions(+)
create mode 100644 kas/kas-security-parsec.yml
create mode 100644 kas/qemuarm-parsec.yml
create mode 100644 kas/qemuarm64-parsec.yml
create mode 100644 kas/qemuppc-parsec.yml
create mode 100644 kas/qemux86-64-parsec.yml
create mode 100644 kas/qemux86-parsec.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 1442239..323285a 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -151,3 +151,28 @@ qemux86-test:
script:
- kas build --target security-test-image kas/$CI_JOB_NAME.yml
- kas build -c testimage --target security-test-image kas/$CI_JOB_NAME.yml
+
+qemux86-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
+
+qemux86-64-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
+
+qemuarm-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
+
+qemuarm-64-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
+
+qemuppc-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
diff --git a/kas/kas-security-parsec.yml b/kas/kas-security-parsec.yml
new file mode 100644
index 0000000..6152f0c
--- /dev/null
+++ b/kas/kas-security-parsec.yml
@@ -0,0 +1,21 @@
+header:
+ version: 9
+ includes:
+ - kas-security-base.yml
+
+repos:
+ meta-security:
+ layers:
+ meta-parsec:
+
+ meta-rust:
+ url: https://github.com/meta-rust/meta-rust.git
+ refspec: master
+
+ meta-clang:
+ url: https://github.com/kraj/meta-clang.git
+ refspec: master
+
+local_conf_header:
+ meta-parsec: |
+ IMAGE_INSTALL_append = " parsec-service parsec-tool"
diff --git a/kas/qemuarm-parsec.yml b/kas/qemuarm-parsec.yml
new file mode 100644
index 0000000..cef2818
--- /dev/null
+++ b/kas/qemuarm-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemuarm
diff --git a/kas/qemuarm64-parsec.yml b/kas/qemuarm64-parsec.yml
new file mode 100644
index 0000000..9b593bc
--- /dev/null
+++ b/kas/qemuarm64-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemuarm64
diff --git a/kas/qemuppc-parsec.yml b/kas/qemuppc-parsec.yml
new file mode 100644
index 0000000..1176d13
--- /dev/null
+++ b/kas/qemuppc-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemuppc
diff --git a/kas/qemux86-64-parsec.yml b/kas/qemux86-64-parsec.yml
new file mode 100644
index 0000000..ec39c14
--- /dev/null
+++ b/kas/qemux86-64-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemux86-64
diff --git a/kas/qemux86-parsec.yml b/kas/qemux86-parsec.yml
new file mode 100644
index 0000000..370947d
--- /dev/null
+++ b/kas/qemux86-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemux86
--
2.20.1


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

Anton Antonov
 

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 \
+"
--
2.20.1


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

Ming Liu <liu.ming50@...>
 

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-framewor=
k-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.b=
b
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.b=
b
@@ -14,6 +14,9 @@ LIC_FILES_CHKSUM =3D "file://${COREBASE}/meta/COPYING.M=
IT;md5=3D3da9cfbcb788c80a0384
# to this recipe can just point towards one of its own files.
IMA_POLICY ?=3D "ima-policy-hashed"
=20
+# Force proceed IMA procedure even 'no_ima' boot parameter is available.
+IMA_FORCE ?=3D "false"
+
SRC_URI =3D " file://ima"
=20
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
}
=20
FILES_${PN} =3D "/init.d ${sysconfdir}"
diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framewor=
k-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/i=
ma
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/i=
ma
@@ -2,11 +2,16 @@
#
# Loads IMA policy into the kernel.
=20
+force_ima=3D@@FORCE_IMA@@
+
ima_enabled() {
- if [ "$bootparam_no_ima" =3D "true" ]; then
+ if [ "$force_ima" =3D "true" ]; then
+ return 0
+ elif [ "$bootparam_no_ima" =3D "true" ]; then
return 1
+ else
+ return 0
fi
- return 0
}
=20
ima_run() {
--=20
2.29.0

4341 - 4360 of 57387