Date   

M+ & H bugs with Milestone Movements WW15

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW15 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

High

13604

[master-next] Distrodata.test_maintainers  fails

randy.macleod@...

kai.kang@...

3.1 M4

3.2 M1

 

13802

ltp tests fail with ssh connection lost  error intermittently

randy.macleod@...

yang.wang@...

3.1 M4

3.2 M1

Medium+

12090

bitbake resident server reconnect needed ?

richard.purdie@...

richard.purdie@...

3.99

3.2 M1

 

12367

moving or removing tmp breaks persistent bitbake server

richard.purdie@...

richard.purdie@...

3.99

3.2 M1

 

12368

persistent bitbake server does not re-parse if previous build was ctrl+C'd

richard.purdie@...

richard.purdie@...

3.99

3.2 M1

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW15!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

7

richard.purdie@...

5

timothy.t.orling@...

2

akuster@...

2

ee.peng.yeoh@...

1

changqing.li@...

1

michael@...

1

jpuhlman@...

1

david.reyna@...

1

Grand Total

21

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current Top developers on Yocto Project 3.1

Stephen Jolley
 

All,

Below is the list as of top 43 developers as of the end of WW15 of who have open medium or higher bugs and enhancements against YP 3.1.   There are 13 possible work days left until the final release candidates for YP 3.1 needs to be released.

Who

Count

richard.purdie@...

36

liezhi.yang@...

27

david.reyna@...

21

akuster808@...

16

bluelightning@...

13

bruce.ashfield@...

11

mark.morton@...

11

kai.kang@...

10

randy.macleod@...

10

Qi.Chen@...

10

ross@...

7

timothy.t.orling@...

7

trevor.gamblin@...

6

michael@...

6

pbarker@...

5

JPEWhacker@...

5

changqing.li@...

5

jon.mason@...

5

alejandro@...

4

kexin.hao@...

4

alex.kanavin@...

4

mingli.yu@...

4

matthew.zeng@...

3

hongxu.jia@...

3

mark.hatle@...

2

kergoth@...

2

mostthingsweb@...

2

jaewon@...

2

jpuhlman@...

2

yang.wang@...

2

ycnakajsph@...

2

raj.khem@...

2

seebs@...

2

limon.anibal@...

2

rpjday@...

2

amber.n.elliot@...

1

naveen.kumar.saini@...

1

anuj.mittal@...

1

denis@...

1

ee.peng.yeoh@...

1

mshah@...

1

apoorv.sangal@...

1

kai.ruhnau@...

1

scott.branden@...

1

yi.zhao@...

1

dl9pf@...

1

jonathan.yong@...

1

Martin.Jansa@...

1

maxime.roussinbelanger@...

1

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 309 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: What is the recommended method to patch a recipe?

Nicolas Dechesne
 



On Mon, Apr 13, 2020 at 12:55 PM Alexander Kanavin <alex.kanavin@...> wrote:
On Mon, 13 Apr 2020 at 12:46, Nicolas Dechesne <nicolas.dechesne@...> wrote:
A good rule of thumb is to never modify a metadata that is not yours. That applies to everything:
* if you need to modify a bb file from a 3rd party library, create a bbappend file in your layer
* if you need to modify a bbappend from a 3rd party, then create another bbappend in your layer

And by 3rd party i mean any layer/tree which is not yours (OE-core, or any other layer your are using).

I beg to differ! Bbappends are making it difficult to reason about what the recipe with all its appends is doing (because they destroy spatial locality and aren't easily visible), and I would actually discourage using them if the modification can go to the original recipe.

Ok.. you're right. Well at least my answer is not complete ;)


Is it fixing a problem? Is it adding a build option absent from the original recipe? Then please take the trouble to submit the change to the owners of the recipe.

This is correct. We should encourage everyone to report, and even better propose a fix, to the relevant layer, when the 'problem' is applicable. I didn't want to discourage that, for sure!
When developing against master, it's a no brainer. When developing against a stable branch (like probably many users), it's not as obvious. In that case I think trying to avoid 'touching' somebody else layer remains a good advice, since it makes upgrades and maintenance trickier.

 

Similarly, if a bbappend is re-setting the component version to something else (yes, people do that despite my best efforts to prohibit the practice), then a much cleaner approach is to actually make a fully copy of the recipe, or go and fix the original.

Recipes version upgrades (or downgrade) should be done in a dedicated layer owned by the 'developer', and in that case, I agree that bbappend should be prohibited, and the entire recipe should be copied.


Alex


Re: What is the recommended method to patch a recipe?

Alexander Kanavin
 

On Mon, 13 Apr 2020 at 12:46, Nicolas Dechesne <nicolas.dechesne@...> wrote:
A good rule of thumb is to never modify a metadata that is not yours. That applies to everything:
* if you need to modify a bb file from a 3rd party library, create a bbappend file in your layer
* if you need to modify a bbappend from a 3rd party, then create another bbappend in your layer

And by 3rd party i mean any layer/tree which is not yours (OE-core, or any other layer your are using).

I beg to differ! Bbappends are making it difficult to reason about what the recipe with all its appends is doing (because they destroy spatial locality and aren't easily visible), and I would actually discourage using them if the modification can go to the original recipe.

Is it fixing a problem? Is it adding a build option absent from the original recipe? Then please take the trouble to submit the change to the owners of the recipe.

Similarly, if a bbappend is re-setting the component version to something else (yes, people do that despite my best efforts to prohibit the practice), then a much cleaner approach is to actually make a fully copy of the recipe, or go and fix the original.

Alex


Re: What is the recommended method to patch a recipe?

Nicolas Dechesne
 



On Mon, Apr 13, 2020 at 10:20 AM nus1998 <nus1998@...> wrote:
Hi All,

I googled some topics on how to patch a recipe, most of them recommend to generate a corresponding <foo>.bbappend to apply the patch, I wonder if there is already a bbappend file, shall I modify the bbappend file directly, or create another layer to overwrite the bbappend file (and including the patchs in original bbappend file)?

A good rule of thumb is to never modify a metadata that is not yours. That applies to everything:
* if you need to modify a bb file from a 3rd party library, create a bbappend file in your layer
* if you need to modify a bbappend from a 3rd party, then create another bbappend in your layer

And by 3rd party i mean any layer/tree which is not yours (OE-core, or any other layer your are using).


Thanks in advance
Nus


Re: What is the recommended method to patch a recipe?

Thomas Goodwin
 

As with a lot of things, I’m sure it all depends on the scope of the change.  Personally, if I ‘own’ the original bbappend, then I consider if it’s worth establishing an override or some other similar mechanism within that bbappend, depending on what I’m developing (an image feature or something machine-specific).  If it’s a one-off for a specific build that I can lump together with other changes, then I go with a new layer specific those changes.

One thing to keep in mind is that if you create your own layer with a bbappend ,then layer priority will impact which portions of your bbappend overwrite the others and the original recipe.  You can use bitbake -e package-name to get a view of how bitbake is overlaying all changes for it.

Cheers,

Thomas

On Apr 13, 2020, 4:20 AM -0400, nus1998 <nus1998@...>, wrote:
Hi All,

I googled some topics on how to patch a recipe, most of them recommend to generate a corresponding <foo>.bbappend to apply the patch, I wonder if there is already a bbappend file, shall I modify the bbappend file directly, or create another layer to overwrite the bbappend file (and including the patchs in original bbappend file)?

Thanks in advance
Nus


What is the recommended method to patch a recipe?

nus1998 <nus1998@...>
 

Hi All,

I googled some topics on how to patch a recipe, most of them recommend to generate a corresponding <foo>.bbappend to apply the patch, I wonder if there is already a bbappend file, shall I modify the bbappend file directly, or create another layer to overwrite the bbappend file (and including the patchs in original bbappend file)?

Thanks in advance
Nus


Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

Sangeeta Jain
 

Hello all,

This is the full report for yocto-3.1.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.
No new defects are found in this cycle.

Note: Few failures are observed. These are setup issue since running tests remotely, not real yocto issue.

Thanks,
Sangeeta

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, 8 April, 2020 9:21 PM
To: pokybuild@...; yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@...>; akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

On Wed, 2020-04-08 at 04:01 +0000, pokybuild@...
wrote:
A build flagged for QA (yocto-3.1.rc2) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2


Build hash information:

bitbake: 4618da2094189e4d814b7d65672cb65c86c0626a
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: bd539ea962ee285eb71053583e3c17fa166fc610
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 1795f30d8ab73d35710ca99064c51190dc84853e
poky: 5d47cdf448b6cff5bb7cc5b0ba0426b8235ec478

There were two failures in this build due to collect-results failing. I fixed the
missing dependency on that autobuilder worker (there was already an open bug
but it wasn't fixed yet) and reran the collections scripts so the results were
added and handled.

Cheers,

Richard


Re: meta-intel: Override SERIAL_CONSOLES variable

Anuj Mittal
 

Could you send a patch please?

Thanks,

Anuj

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of
Leon Woestenberg
Sent: Saturday, April 11, 2020 04:48 AM
To: Marek Belisko <marek.belisko@...>
Cc: yocto <yocto@...>
Subject: Re: [yocto] meta-intel: Override SERIAL_CONSOLES variable

Hi all,

On Fri, Apr 10, 2020 at 8:56 AM Marek Belisko <marek.belisko@...> wrote:

Hi,

in meta-intel in machine configuration SERIAL_CONSOLES are defined as
: SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyS2"
For a more generic solution, could this be made a weak assignment?

I am on a SMARC x86-64 module which only one serial is useful, so I would like to
downtune this variable as well.

Regards,

Leon.


[PATCHv1][ptest-runner 2/2] Add support to specify multiple folder for ptest-runner

Anibal Limon
 

Enables multiple folders in -d option the current use case is to be able
specify multilib folders in the same run.

The -d option allows directories without whitespaces inside, example to
run after compile:

$ ./ptest-runner -d "test/data tests/data2/"

[YOCTO #12604]

Signed-off-by: Aníbal Limón <anibal.limon@...>
---
main.c | 91 ++++++++++++++++++++++-----------
ptest_list.c | 17 ++++++
ptest_list.h | 1 +
tests/data2/go/ptest/run-ptest | 3 ++
tests/data2/lua/ptest/run-ptest | 3 ++
utils.h | 4 +-
6 files changed, 87 insertions(+), 32 deletions(-)
create mode 100755 tests/data2/go/ptest/run-ptest
create mode 100755 tests/data2/lua/ptest/run-ptest

diff --git a/main.c b/main.c
index 01d60f7..e3a1b69 100644
--- a/main.c
+++ b/main.c
@@ -47,10 +47,43 @@
static inline void
print_usage(FILE *stream, char *progname)
{
- fprintf(stream, "Usage: %s [-d directory] [-e exclude] [-l list] [-t timeout]"
+ fprintf(stream, "Usage: %s [-d directory directory2 ...] [-e exclude] [-l list] [-t timeout]"
" [-x xml-filename] [-h] [ptest1 ptest2 ...]\n", progname);
}

+static char **
+str2array(char *str, const char *delim, int *num)
+{
+ char *c, *tok;
+ char **array;
+ int i;
+
+ c = str;
+ *num = 1;
+ while (*c) {
+ if (isspace(*c))
+ (*num)++;
+ c++;
+ }
+
+
+ array = malloc((size_t)*num * sizeof(char**));
+ CHECK_ALLOCATION(array, 1, 1);
+
+ i = 0;
+ tok = strtok_r(str, delim, &c);
+ array[i] = strdup(tok);
+ CHECK_ALLOCATION(array[i], 1, 1);
+ i++;
+ while ((tok = strtok_r(NULL, " ", &c)) != NULL) {
+ array[i] = strdup(tok);
+ CHECK_ALLOCATION(array[i], 1, 1);
+ i++;
+ }
+
+ return array;
+}
+
int
main(int argc, char *argv[])
{
@@ -59,7 +92,6 @@ main(int argc, char *argv[])
int i;
int rc;
int ptest_exclude_num = 0;
- char *c, *tok;

#ifdef MEMCHECK
mtrace();
@@ -68,7 +100,11 @@ main(int argc, char *argv[])
struct ptest_list *head, *run;
struct ptest_options opts;

- opts.directory = strdup(DEFAULT_DIRECTORY);
+ opts.dirs = malloc(sizeof(char **) * 1);
+ CHECK_ALLOCATION(opts.dirs, 1, 1);
+ opts.dirs[0] = strdup(DEFAULT_DIRECTORY);
+ CHECK_ALLOCATION(opts.dirs[0], 1, 1);
+ opts.dirs_no = 1;
opts.exclude = NULL;
opts.list = 0;
opts.timeout = DEFAULT_TIMEOUT;
@@ -78,34 +114,12 @@ main(int argc, char *argv[])
while ((opt = getopt(argc, argv, "d:e:lt:x:h")) != -1) {
switch (opt) {
case 'd':
- free(opts.directory);
- opts.directory = realpath(optarg, NULL);
- CHECK_ALLOCATION(opts.directory, 1, 1);
+ free(opts.dirs[0]);
+ free(opts.dirs);
+ opts.dirs = str2array(optarg, " ", &(opts.dirs_no));
break;
case 'e':
- c = optarg;
- ptest_exclude_num = 1;
-
- while (*c) {
- if (isspace(*c))
- ptest_exclude_num++;
- c++;
- }
-
-
- opts.exclude = malloc((size_t)ptest_exclude_num * sizeof(char));
- CHECK_ALLOCATION(opts.exclude, 1, 1);
-
- i = 0;
- tok = strtok_r(optarg, " ", &c);
- opts.exclude[i] = strdup(tok);
- CHECK_ALLOCATION(opts.exclude[i], 1, 1);
- i++;
- while ((tok = strtok_r(NULL, " ", &c)) != NULL) {
- opts.exclude[i] = strdup(tok);
- CHECK_ALLOCATION(opts.exclude[i], 1, 1);
- i++;
- }
+ opts.exclude = str2array(optarg, " ", &ptest_exclude_num);
break;
case 'l':
opts.list = 1;
@@ -140,10 +154,25 @@ main(int argc, char *argv[])
}
}

- head = get_available_ptests(opts.directory);
+ head = NULL;
+ for (i = 0; i < opts.dirs_no; i ++) {
+ struct ptest_list *tmp;
+
+ tmp = get_available_ptests(opts.dirs[i]);
+ if (tmp == NULL) {
+ fprintf(stderr, PRINT_PTESTS_NOT_FOUND_DIR, opts.dirs[i]);
+ continue;
+ }
+
+
+ if (head == NULL)
+ head = tmp;
+ else
+ head = ptest_list_extend(head, tmp);
+ }
if (head == NULL || ptest_list_length(head) == 0) {
fprintf(stderr, PRINT_PTESTS_NOT_FOUND);
- return 1;
+ return 1;
}

if (opts.list) {
diff --git a/ptest_list.c b/ptest_list.c
index a5632f8..917ef4f 100644
--- a/ptest_list.c
+++ b/ptest_list.c
@@ -216,3 +216,20 @@ ptest_list_remove(struct ptest_list *head, char *ptest, int free)

return p;
}
+
+struct ptest_list *
+ptest_list_extend(struct ptest_list *head, struct ptest_list *extend)
+{
+ struct ptest_list *p, *q;
+
+ VALIDATE_PTR_RNULL(head);
+ VALIDATE_PTR_RNULL(extend);
+
+ for (p = head; p->next != NULL; p = p->next);
+ q = extend->next;
+ p->next = q;
+
+ free(extend);
+
+ return head;
+}
diff --git a/ptest_list.h b/ptest_list.h
index e1caffc..02a64bb 100644
--- a/ptest_list.h
+++ b/ptest_list.h
@@ -64,5 +64,6 @@ extern struct ptest_list *ptest_list_search(struct ptest_list *, char *);
extern struct ptest_list *ptest_list_search_by_file(struct ptest_list *, char *, struct stat);
extern struct ptest_list *ptest_list_add(struct ptest_list *, char *, char *);
extern struct ptest_list *ptest_list_remove(struct ptest_list *, char *, int);
+extern struct ptest_list *ptest_list_extend(struct ptest_list *, struct ptest_list *);

#endif // PTEST_RUNNER_LIST_H
diff --git a/tests/data2/go/ptest/run-ptest b/tests/data2/go/ptest/run-ptest
new file mode 100755
index 0000000..d8a9ca2
--- /dev/null
+++ b/tests/data2/go/ptest/run-ptest
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+echo "go"
diff --git a/tests/data2/lua/ptest/run-ptest b/tests/data2/lua/ptest/run-ptest
new file mode 100755
index 0000000..07a7713
--- /dev/null
+++ b/tests/data2/lua/ptest/run-ptest
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+echo "lua"
diff --git a/utils.h b/utils.h
index aa53707..39832e6 100644
--- a/utils.h
+++ b/utils.h
@@ -27,13 +27,15 @@
#include "ptest_list.h"

#define PRINT_PTESTS_NOT_FOUND "No ptests found.\n"
+#define PRINT_PTESTS_NOT_FOUND_DIR "Warning: ptests not found in, %s.\n"
#define PRINT_PTESTS_AVAILABLE "Available ptests:\n"

#define CHECK_ALLOCATION(p, size, exit_on_null) \
check_allocation1(p, size, __FILE__, __LINE__, exit_on_null)

struct ptest_options {
- char *directory;
+ char **dirs;
+ int dirs_no;
char **exclude;
int list;
int timeout;
--
2.26.0


[PATCHv1][ptest-runner 1/2] Makefile: Fix TEST_LDFLAGS gcc cmdline position

Anibal Limon
 

Fixes,

...
alimon@blackbox:~/upstream/ptest-runner2$ make CC=gcc check
gcc -std=gnu99 -pedantic -Wall -Werror -I . -g -c tests/main.c -o tests/main.o
gcc -std=gnu99 -pedantic -Wall -Werror -I . -g -c tests/ptest_list.c -o tests/ptest_list.o
gcc -std=gnu99 -pedantic -Wall -Werror -I . -g -c tests/utils.c -o tests/utils.o
gcc -lm -lrt -lpthread tests/main.o tests/ptest_list.o tests/utils.o utils.o ptest_list.o -o ptest-runner-test -lcheck -lsubunit -lutil
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libcheck.a(check.o): in function `tcase_create':
(.text+0x1b3): undefined reference to `floor'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libcheck.a(check.o): in function `tcase_set_timeout':
(.text+0x66b): undefined reference to `floor'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libcheck.a(check.o): in function `check_get_clockid':
(.text+0xd03): undefined reference to `timer_create'
/usr/bin/ld: (.text+0xd25): undefined reference to `timer_delete'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libcheck.a(check_pack.o): in function `ppack':
(.text+0x4fc): undefined reference to `__pthread_register_cancel'
/usr/bin/ld: (.text+0x546): undefined reference to `__pthread_unregister_cancel'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libcheck.a(check_run.o): in function `srunner_run_tagged':
(.text+0xbf7): undefined reference to `timer_create'
/usr/bin/ld: (.text+0xc3c): undefined reference to `timer_settime'
/usr/bin/ld: (.text+0xc6c): undefined reference to `timer_delete'
collect2: error: ld returned 1 exit status
make: *** [Makefile:39: ptest-runner-test] Error 1
...

Signed-off-by: Aníbal Limón <anibal.limon@...>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index c92261b..3cca17b 100644
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,7 @@ $(EXECUTABLE): $(OBJECTS)
tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)

$(TEST_EXECUTABLE): $(TEST_OBJECTS)
- $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@ $(TEST_LIBSTATIC)
+ $(CC) $(LDFLAGS) $(TEST_OBJECTS) -o $@ $(TEST_LIBSTATIC) $(TEST_LDFLAGS)

check: $(TEST_EXECUTABLE)
./$(TEST_EXECUTABLE) -d $(TEST_DATA)
--
2.26.0


Re: meta-intel: Override SERIAL_CONSOLES variable

Leon Woestenberg
 

Hi all,

On Fri, Apr 10, 2020 at 8:56 AM Marek Belisko <marek.belisko@...> wrote:

Hi,

in meta-intel in machine configuration SERIAL_CONSOLES are defined as
: SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyS2"
For a more generic solution, could this be made a weak assignment?

I am on a SMARC x86-64 module which only one serial is useful, so I
would like to downtune this variable as well.

Regards,

Leon.


[meta-security][RFC 2/2] dm-verity: add a working example for BeagleBone Black

Bartosz Golaszewski
 

From: Bartosz Golaszewski <bgolaszewski@...>

This adds various bits and pieces to enable generating a working example
of a full chain of trust up to dm-verity-protected rootfs level on Beagle
Bone Black.

The new initramfs is quite generic and should work for other SoCs as well
when using fitImage.

The following config can be used with current master poky,
meta-openembedded & meta-security to generate a BBB image using verified
boot and dm-verity.

UBOOT_SIGN_KEYDIR = "/tmp/test-keys/"
UBOOT_SIGN_KEYNAME = "dev"
UBOOT_SIGN_ENABLE = "1"
UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
UBOOT_MACHINE_beaglebone-yocto = "am335x_boneblack_vboot_config"

IMAGE_CLASSES += "dm-verity-img"
IMAGE_FSTYPES += "wic.xz ext4"

DM_VERITY_IMAGE = "core-image-full-cmdline"
DM_VERITY_IMAGE_TYPE = "ext4"

KERNEL_CLASSES += "kernel-fitimage"
KERNEL_IMAGETYPE_beaglebone-yocto = "fitImage"

IMAGE_INSTALL_remove = " kernel-image-zimage"
IMAGE_BOOT_FILES_remove = " zImage"
IMAGE_BOOT_FILES_append = " fitImage-${INITRAMFS_IMAGE}-${MACHINE}-${MACHINE};fitImage"

# Using systemd is not strictly needed but deals nicely with read-only
# filesystem by default.
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

INITRAMFS_IMAGE = "dm-verity-image-initramfs"
INITRAMFS_FSTYPES = "cpio.gz"
INITRAMFS_IMAGE_BUNDLE = "1"

WKS_FILE = "beaglebone-yocto-verity.wks.in"

KERNEL_FEATURES_append = " features/device-mapper/dm-verity.scc"

Signed-off-by: Bartosz Golaszewski <bgolaszewski@...>
---
.../images/dm-verity-image-initramfs.bb | 26 +++++++++++
.../initrdscripts/initramfs-dm-verity.bb | 13 ++++++
.../initramfs-dm-verity/init-dm-verity.sh | 46 +++++++++++++++++++
wic/beaglebone-yocto-verity.wks.in | 15 ++++++
4 files changed, 100 insertions(+)
create mode 100644 recipes-core/images/dm-verity-image-initramfs.bb
create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity.bb
create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
create mode 100644 wic/beaglebone-yocto-verity.wks.in

diff --git a/recipes-core/images/dm-verity-image-initramfs.bb b/recipes-core/images/dm-verity-image-initramfs.bb
new file mode 100644
index 0000000..f9ea376
--- /dev/null
+++ b/recipes-core/images/dm-verity-image-initramfs.bb
@@ -0,0 +1,26 @@
+DESCRIPTION = "Simple initramfs image for mounting the rootfs over the verity device mapper."
+
+# We want a clean, minimal image.
+IMAGE_FEATURES = ""
+
+PACKAGE_INSTALL = " \
+ initramfs-dm-verity \
+ base-files \
+ busybox \
+ util-linux-mount \
+ udev \
+ cryptsetup \
+ lvm2-udevrules \
+"
+
+# Can we somehow inspect reverse dependencies to avoid these variables?
+do_rootfs[depends] += "${DM_VERITY_IMAGE}:do_image_${DM_VERITY_IMAGE_TYPE}"
+
+IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
+
+inherit core-image
+
+deploy_verity_hash() {
+ install -D -m 0644 ${DEPLOY_DIR_IMAGE}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity.env ${IMAGE_ROOTFS}/${datadir}/dm-verity.env
+}
+ROOTFS_POSTPROCESS_COMMAND += "deploy_verity_hash;"
diff --git a/recipes-core/initrdscripts/initramfs-dm-verity.bb b/recipes-core/initrdscripts/initramfs-dm-verity.bb
new file mode 100644
index 0000000..b614956
--- /dev/null
+++ b/recipes-core/initrdscripts/initramfs-dm-verity.bb
@@ -0,0 +1,13 @@
+SUMMARY = "Simple init script that uses devmapper to mount the rootfs in read-only mode protected by dm-verity"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+SRC_URI = "file://init-dm-verity.sh"
+
+do_install() {
+ install -m 0755 ${WORKDIR}/init-dm-verity.sh ${D}/init
+ install -d ${D}/dev
+ mknod -m 622 ${D}/dev/console c 5 1
+}
+
+FILES_${PN} = "/init /dev/console"
diff --git a/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh b/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
new file mode 100644
index 0000000..307d2c7
--- /dev/null
+++ b/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+RDEV=""
+ROOT_DIR="/new_root"
+
+mkdir -p /proc
+mkdir -p /sys
+mkdir -p /run
+mkdir -p /tmp
+mount -t proc proc /proc
+mount -t sysfs sysfs /sys
+mount -t devtmpfs none /dev
+
+udevd --daemon
+udevadm trigger --type=subsystems --action=add
+udevadm trigger --type=devices --action=add
+udevadm settle --timeout=10
+
+for PARAM in $(cat /proc/cmdline); do
+ case $PARAM in
+ root=*)
+ RDEV=${PARAM#root=}
+ ;;
+ esac
+done
+
+if ! [ -b $RDEV ]; then
+ echo "Missing root command line argument!"
+ exit 1
+fi
+
+case $RDEV in
+ UUID=*)
+ RDEV=$(realpath /dev/disk/by-uuid/${RDEV#UUID=})
+ ;;
+esac
+
+. /usr/share/dm-verity.env
+
+echo "Mounting $RDEV over dm-verity as the root filesystem"
+
+veritysetup --data-block-size=1024 --hash-offset=$DATA_SIZE create rootfs $RDEV $RDEV $ROOT_HASH
+mkdir -p $ROOT_DIR
+mount -o ro /dev/mapper/rootfs $ROOT_DIR
+exec switch_root $ROOT_DIR /sbin/init
diff --git a/wic/beaglebone-yocto-verity.wks.in b/wic/beaglebone-yocto-verity.wks.in
new file mode 100644
index 0000000..cd1702e
--- /dev/null
+++ b/wic/beaglebone-yocto-verity.wks.in
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2020 BayLibre SAS
+# Author: Bartosz Golaszewski <bgolaszewski@...>
+#
+# A dm-verity variant of the regular wks for beaglebone black. We need to fetch
+# the partition images from the DEPLOY_DIR_IMAGE as the rootfs source plugin will
+# not recreate the exact block device corresponding with the hash tree. We must
+# not alter the label or any other setting on the image.
+#
+# This .wks only works with the dm-verity-img class.
+
+part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4 --size 16 --sourceparams="loader=u-boot" --use-uuid
+part / --source rawcopy --ondisk mmcblk0 --sourceparams="file=${DEPLOY_DIR_IMAGE}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity"
+bootloader --append="console=ttyS0,115200"
--
2.25.0


[meta-security][RFC 1/2] classes: provide a class for generating dm-verity meta-data images

Bartosz Golaszewski
 

From: Bartosz Golaszewski <bgolaszewski@...>

This adds a class that allows to generate conversions of ext[234] and
btrfs partitions images with dm-verity hash data appended at the end as
well as a corresponding .env file containing the root hash and data
offset that can be stored in a secure location (e.g. signed fitImage)
or signed and verified at run-time on its own.

The class depends on two variables:
DM_VERITY_IMAGE: defines the name of the main image (normally the
one that is used with the bitbake command to
build the main image)
DM_VERITY_IMAGE_TYPE: defines exactly one type for which to generate
the protected image.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@...>
---
classes/dm-verity-img.bbclass | 88 +++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
create mode 100644 classes/dm-verity-img.bbclass

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
new file mode 100644
index 0000000..1c0e29b
--- /dev/null
+++ b/classes/dm-verity-img.bbclass
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2020 BayLibre SAS
+# Author: Bartosz Golaszewski <bgolaszewski@...>
+#
+# This bbclass allows creating of dm-verity protected partition images. It
+# generates a device image file with dm-verity hash data appended at the end
+# plus the corresponding .env file containing additional information needed
+# to mount the image such as the root hash in the form of ell variables. To
+# assure data integrity, the root hash must be stored in a trusted location
+# or cryptographically signed and verified.
+#
+# Usage:
+# DM_VERITY_IMAGE = "core-image-full-cmdline" # or other image
+# DM_VERITY_IMAGE_TYPE = "ext4" # or ext2, ext3 & btrfs
+# IMAGE_CLASSES += "dm-verity-img"
+#
+# The resulting image can then be used to implement the device mapper block
+# integrity checking on the target device.
+
+# Process the output from veritysetup and generate the corresponding .env
+# file. The output from veritysetup is not very machine-friendly so we need to
+# convert it to some better format. Let's drop the first line (doesn't contain
+# any useful info) and feed the rest to a script.
+process_verity() {
+ local ENV="$OUTPUT.env"
+
+ # Each line contains a key and a value string delimited by ':'. Read the
+ # two parts into separate variables and process them separately. For the
+ # key part: convert the names to upper case and replace spaces with
+ # underscores to create correct shell variable names. For the value part:
+ # just trim all white-spaces.
+ IFS=":"
+ while read KEY VAL; do
+ echo -ne "$KEY" | tr '[:lower:]' '[:upper:]' | sed 's/ /_/g' >> $ENV
+ echo -ne "=" >> $ENV
+ echo "$VAL" | tr -d " \t" >> $ENV
+ done
+
+ # Add partition size
+ echo "DATA_SIZE=$SIZE" >> $ENV
+
+ ln -sf $ENV ${IMAGE_BASENAME}-${MACHINE}.$TYPE.verity.env
+}
+
+verity_setup() {
+ local TYPE=$1
+ local INPUT=${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$TYPE
+ local SIZE=$(stat --printf="%s" $INPUT)
+ local OUTPUT=$INPUT.verity
+
+ cp -a $INPUT $OUTPUT
+
+ # Let's drop the first line of output (doesn't contain any useful info)
+ # and feed the rest to another function.
+ veritysetup --data-block-size=1024 --hash-offset=$SIZE format $OUTPUT $OUTPUT | tail -n +2 | process_verity
+}
+
+VERITY_TYPES = "ext2.verity ext3.verity ext4.verity btrfs.verity"
+IMAGE_TYPES += "${VERITY_TYPES}"
+CONVERSIONTYPES += "verity"
+CONVERSION_CMD_verity = "verity_setup ${type}"
+CONVERSION_DEPENDS_verity = "cryptsetup-native"
+
+python __anonymous() {
+ verity_image = d.getVar('DM_VERITY_IMAGE')
+ verity_type = d.getVar('DM_VERITY_IMAGE_TYPE')
+ image_fstypes = d.getVar('IMAGE_FSTYPES')
+ pn = d.getVar('PN')
+
+ if verity_image != pn:
+ return # This doesn't concern this image
+
+ if not verity_image or not verity_type:
+ bb.warn('dm-verity-img class inherited but not used')
+ return
+
+ if len(verity_type.split()) is not 1:
+ bb.fatal('DM_VERITY_IMAGE_TYPE must contain exactly one type')
+
+ d.appendVar('IMAGE_FSTYPES', ' %s.verity' % verity_type)
+
+ # If we're using wic: we'll have to use partition images and not the rootfs
+ # source plugin so add the appropriate dependency.
+ if 'wic' in image_fstypes:
+ dep = ' %s:do_image_%s' % (pn, verity_type)
+ d.appendVarFlag('do_image_wic', 'depends', dep)
+}
--
2.25.0


[meta-security][RFC 0/2] generic dm-verity support + BBB example

Bartosz Golaszewski
 

From: Bartosz Golaszewski <bgolaszewski@...>

I'm terribly sorry for spamming, but I eventually decided to resend it: not
only the tags were messed up but I also added a v2 on top. This time it
should be good.

===

This series attempts to introduce support for dm-verity in meta-security.
It depends on a series[1] I submitted for OE-core that introduces multi-stage
image deployment that's currently pending review (although the general idea
was accepted by Richard). This new way of deploying image artifacts is aimed
at solving a circular dependency problem[2] which turned out to be impossible
to resolve if all artifacts are deployed at once by the do_image_complete task.

The first patch in this series introduces a generic bbclass that allows to
generate and append dm-verity hash data at the end of the partition image.

The second patch adds support for an example verified boot image for Beagle
Bone Black where the root dm-verity hash is stored inside the signed fitImage
in an initramfs which takes care of mouting the protected rootfs.

Patch 2/2 - while made sure to work on BBB - should be generic enough to be
reusable across many platforms.

[1] https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg135694.html
[2] https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg134825.html

Bartosz Golaszewski (2):
classes: provide a class for generating dm-verity meta-data images
dm-verity: add a working example for BeagleBone Black

classes/dm-verity-img.bbclass | 88 +++++++++++++++++++
.../images/dm-verity-image-initramfs.bb | 26 ++++++
.../initrdscripts/initramfs-dm-verity.bb | 13 +++
.../initramfs-dm-verity/init-dm-verity.sh | 46 ++++++++++
wic/beaglebone-yocto-verity.wks.in | 15 ++++
5 files changed, 188 insertions(+)
create mode 100644 classes/dm-verity-img.bbclass
create mode 100644 recipes-core/images/dm-verity-image-initramfs.bb
create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity.bb
create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
create mode 100644 wic/beaglebone-yocto-verity.wks.in

--
2.25.0


Re: [OE-core][PATCH v2 0/2] generic dm-verity support + BBB example

Bartosz Golaszewski
 

pt., 10 kwi 2020 o 14:34 Bartosz Golaszewski <brgl@...> napisał(a):

From: Bartosz Golaszewski <bgolaszewski@...>

This series attempts to introduce support for dm-verity in meta-security.
It depends on a series[1] I submitted for OE-core that introduces multi-stage
image deployment that's currently pending review (although the general idea
was accepted by Richard). This new way of deploying image artifacts is aimed
at solving a circular dependency problem[2] which turned out to be impossible
to resolve if all artifacts are deployed at once by the do_image_complete task.

The first patch in this series introduces a generic bbclass that allows to
generate and append dm-verity hash data at the end of the partition image.

The second patch adds support for an example verified boot image for Beagle
Bone Black where the root dm-verity hash is stored inside the signed fitImage
in an initramfs which takes care of mouting the protected rootfs.

Patch 2/2 - while made sure to work on BBB - should be generic enough to be
reusable across many platforms.

[1] https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg135694.html
[2] https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg134825.html

Bartosz Golaszewski (2):
classes: provide a class for generating dm-verity meta-data images
dm-verity: add a working example for BeagleBone Black

classes/dm-verity-img.bbclass | 88 +++++++++++++++++++
.../images/dm-verity-image-initramfs.bb | 26 ++++++
.../initrdscripts/initramfs-dm-verity.bb | 13 +++
.../initramfs-dm-verity/init-dm-verity.sh | 46 ++++++++++
wic/beaglebone-yocto-verity.wks.in | 15 ++++
5 files changed, 188 insertions(+)
create mode 100644 classes/dm-verity-img.bbclass
create mode 100644 recipes-core/images/dm-verity-image-initramfs.bb
create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity.bb
create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
create mode 100644 wic/beaglebone-yocto-verity.wks.in

--
2.25.0
Eek, this was supposed to be tagged [meta-security]. But since I'm
posting it as an RFC I won't be resending for now.

Bart


[OE-core][PATCH v2 2/2] dm-verity: add a working example for BeagleBone Black

Bartosz Golaszewski
 

From: Bartosz Golaszewski <bgolaszewski@...>

This adds various bits and pieces to enable generating a working example
of a full chain of trust up to dm-verity-protected rootfs level on Beagle
Bone Black.

The new initramfs is quite generic and should work for other SoCs as well
when using fitImage.

The following config can be used with current master poky,
meta-openembedded & meta-security to generate a BBB image using verified
boot and dm-verity.

UBOOT_SIGN_KEYDIR = "/tmp/test-keys/"
UBOOT_SIGN_KEYNAME = "dev"
UBOOT_SIGN_ENABLE = "1"
UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
UBOOT_MACHINE_beaglebone-yocto = "am335x_boneblack_vboot_config"

IMAGE_CLASSES += "dm-verity-img"
IMAGE_FSTYPES += "wic.xz ext4"

DM_VERITY_IMAGE = "core-image-full-cmdline"
DM_VERITY_IMAGE_TYPE = "ext4"

KERNEL_CLASSES += "kernel-fitimage"
KERNEL_IMAGETYPE_beaglebone-yocto = "fitImage"

IMAGE_INSTALL_remove = " kernel-image-zimage"
IMAGE_BOOT_FILES_remove = " zImage"
IMAGE_BOOT_FILES_append = " fitImage-${INITRAMFS_IMAGE}-${MACHINE}-${MACHINE};fitImage"

# Using systemd is not strictly needed but deals nicely with read-only
# filesystem by default.
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

INITRAMFS_IMAGE = "dm-verity-image-initramfs"
INITRAMFS_FSTYPES = "cpio.gz"
INITRAMFS_IMAGE_BUNDLE = "1"

WKS_FILE = "beaglebone-yocto-verity.wks.in"

KERNEL_FEATURES_append = " features/device-mapper/dm-verity.scc"

Signed-off-by: Bartosz Golaszewski <bgolaszewski@...>
---
.../images/dm-verity-image-initramfs.bb | 26 +++++++++++
.../initrdscripts/initramfs-dm-verity.bb | 13 ++++++
.../initramfs-dm-verity/init-dm-verity.sh | 46 +++++++++++++++++++
wic/beaglebone-yocto-verity.wks.in | 15 ++++++
4 files changed, 100 insertions(+)
create mode 100644 recipes-core/images/dm-verity-image-initramfs.bb
create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity.bb
create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
create mode 100644 wic/beaglebone-yocto-verity.wks.in

diff --git a/recipes-core/images/dm-verity-image-initramfs.bb b/recipes-core/images/dm-verity-image-initramfs.bb
new file mode 100644
index 0000000..f9ea376
--- /dev/null
+++ b/recipes-core/images/dm-verity-image-initramfs.bb
@@ -0,0 +1,26 @@
+DESCRIPTION = "Simple initramfs image for mounting the rootfs over the verity device mapper."
+
+# We want a clean, minimal image.
+IMAGE_FEATURES = ""
+
+PACKAGE_INSTALL = " \
+ initramfs-dm-verity \
+ base-files \
+ busybox \
+ util-linux-mount \
+ udev \
+ cryptsetup \
+ lvm2-udevrules \
+"
+
+# Can we somehow inspect reverse dependencies to avoid these variables?
+do_rootfs[depends] += "${DM_VERITY_IMAGE}:do_image_${DM_VERITY_IMAGE_TYPE}"
+
+IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
+
+inherit core-image
+
+deploy_verity_hash() {
+ install -D -m 0644 ${DEPLOY_DIR_IMAGE}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity.env ${IMAGE_ROOTFS}/${datadir}/dm-verity.env
+}
+ROOTFS_POSTPROCESS_COMMAND += "deploy_verity_hash;"
diff --git a/recipes-core/initrdscripts/initramfs-dm-verity.bb b/recipes-core/initrdscripts/initramfs-dm-verity.bb
new file mode 100644
index 0000000..b614956
--- /dev/null
+++ b/recipes-core/initrdscripts/initramfs-dm-verity.bb
@@ -0,0 +1,13 @@
+SUMMARY = "Simple init script that uses devmapper to mount the rootfs in read-only mode protected by dm-verity"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+SRC_URI = "file://init-dm-verity.sh"
+
+do_install() {
+ install -m 0755 ${WORKDIR}/init-dm-verity.sh ${D}/init
+ install -d ${D}/dev
+ mknod -m 622 ${D}/dev/console c 5 1
+}
+
+FILES_${PN} = "/init /dev/console"
diff --git a/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh b/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
new file mode 100644
index 0000000..307d2c7
--- /dev/null
+++ b/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+RDEV=""
+ROOT_DIR="/new_root"
+
+mkdir -p /proc
+mkdir -p /sys
+mkdir -p /run
+mkdir -p /tmp
+mount -t proc proc /proc
+mount -t sysfs sysfs /sys
+mount -t devtmpfs none /dev
+
+udevd --daemon
+udevadm trigger --type=subsystems --action=add
+udevadm trigger --type=devices --action=add
+udevadm settle --timeout=10
+
+for PARAM in $(cat /proc/cmdline); do
+ case $PARAM in
+ root=*)
+ RDEV=${PARAM#root=}
+ ;;
+ esac
+done
+
+if ! [ -b $RDEV ]; then
+ echo "Missing root command line argument!"
+ exit 1
+fi
+
+case $RDEV in
+ UUID=*)
+ RDEV=$(realpath /dev/disk/by-uuid/${RDEV#UUID=})
+ ;;
+esac
+
+. /usr/share/dm-verity.env
+
+echo "Mounting $RDEV over dm-verity as the root filesystem"
+
+veritysetup --data-block-size=1024 --hash-offset=$DATA_SIZE create rootfs $RDEV $RDEV $ROOT_HASH
+mkdir -p $ROOT_DIR
+mount -o ro /dev/mapper/rootfs $ROOT_DIR
+exec switch_root $ROOT_DIR /sbin/init
diff --git a/wic/beaglebone-yocto-verity.wks.in b/wic/beaglebone-yocto-verity.wks.in
new file mode 100644
index 0000000..cd1702e
--- /dev/null
+++ b/wic/beaglebone-yocto-verity.wks.in
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2020 BayLibre SAS
+# Author: Bartosz Golaszewski <bgolaszewski@...>
+#
+# A dm-verity variant of the regular wks for beaglebone black. We need to fetch
+# the partition images from the DEPLOY_DIR_IMAGE as the rootfs source plugin will
+# not recreate the exact block device corresponding with the hash tree. We must
+# not alter the label or any other setting on the image.
+#
+# This .wks only works with the dm-verity-img class.
+
+part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4 --size 16 --sourceparams="loader=u-boot" --use-uuid
+part / --source rawcopy --ondisk mmcblk0 --sourceparams="file=${DEPLOY_DIR_IMAGE}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity"
+bootloader --append="console=ttyS0,115200"
--
2.25.0


[OE-core][PATCH v2 1/2] classes: provide a class for generating dm-verity meta-data images

Bartosz Golaszewski
 

From: Bartosz Golaszewski <bgolaszewski@...>

This adds a class that allows to generate conversions of ext[234] and
btrfs partitions images with dm-verity hash data appended at the end as
well as a corresponding .env file containing the root hash and data
offset that can be stored in a secure location (e.g. signed fitImage)
or signed and verified at run-time on its own.

The class depends on two variables:
DM_VERITY_IMAGE: defines the name of the main image (normally the
one that is used with the bitbake command to
build the main image)
DM_VERITY_IMAGE_TYPE: defines exactly one type for which to generate
the protected image.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@...>
---
classes/dm-verity-img.bbclass | 88 +++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
create mode 100644 classes/dm-verity-img.bbclass

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
new file mode 100644
index 0000000..1c0e29b
--- /dev/null
+++ b/classes/dm-verity-img.bbclass
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2020 BayLibre SAS
+# Author: Bartosz Golaszewski <bgolaszewski@...>
+#
+# This bbclass allows creating of dm-verity protected partition images. It
+# generates a device image file with dm-verity hash data appended at the end
+# plus the corresponding .env file containing additional information needed
+# to mount the image such as the root hash in the form of ell variables. To
+# assure data integrity, the root hash must be stored in a trusted location
+# or cryptographically signed and verified.
+#
+# Usage:
+# DM_VERITY_IMAGE = "core-image-full-cmdline" # or other image
+# DM_VERITY_IMAGE_TYPE = "ext4" # or ext2, ext3 & btrfs
+# IMAGE_CLASSES += "dm-verity-img"
+#
+# The resulting image can then be used to implement the device mapper block
+# integrity checking on the target device.
+
+# Process the output from veritysetup and generate the corresponding .env
+# file. The output from veritysetup is not very machine-friendly so we need to
+# convert it to some better format. Let's drop the first line (doesn't contain
+# any useful info) and feed the rest to a script.
+process_verity() {
+ local ENV="$OUTPUT.env"
+
+ # Each line contains a key and a value string delimited by ':'. Read the
+ # two parts into separate variables and process them separately. For the
+ # key part: convert the names to upper case and replace spaces with
+ # underscores to create correct shell variable names. For the value part:
+ # just trim all white-spaces.
+ IFS=":"
+ while read KEY VAL; do
+ echo -ne "$KEY" | tr '[:lower:]' '[:upper:]' | sed 's/ /_/g' >> $ENV
+ echo -ne "=" >> $ENV
+ echo "$VAL" | tr -d " \t" >> $ENV
+ done
+
+ # Add partition size
+ echo "DATA_SIZE=$SIZE" >> $ENV
+
+ ln -sf $ENV ${IMAGE_BASENAME}-${MACHINE}.$TYPE.verity.env
+}
+
+verity_setup() {
+ local TYPE=$1
+ local INPUT=${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$TYPE
+ local SIZE=$(stat --printf="%s" $INPUT)
+ local OUTPUT=$INPUT.verity
+
+ cp -a $INPUT $OUTPUT
+
+ # Let's drop the first line of output (doesn't contain any useful info)
+ # and feed the rest to another function.
+ veritysetup --data-block-size=1024 --hash-offset=$SIZE format $OUTPUT $OUTPUT | tail -n +2 | process_verity
+}
+
+VERITY_TYPES = "ext2.verity ext3.verity ext4.verity btrfs.verity"
+IMAGE_TYPES += "${VERITY_TYPES}"
+CONVERSIONTYPES += "verity"
+CONVERSION_CMD_verity = "verity_setup ${type}"
+CONVERSION_DEPENDS_verity = "cryptsetup-native"
+
+python __anonymous() {
+ verity_image = d.getVar('DM_VERITY_IMAGE')
+ verity_type = d.getVar('DM_VERITY_IMAGE_TYPE')
+ image_fstypes = d.getVar('IMAGE_FSTYPES')
+ pn = d.getVar('PN')
+
+ if verity_image != pn:
+ return # This doesn't concern this image
+
+ if not verity_image or not verity_type:
+ bb.warn('dm-verity-img class inherited but not used')
+ return
+
+ if len(verity_type.split()) is not 1:
+ bb.fatal('DM_VERITY_IMAGE_TYPE must contain exactly one type')
+
+ d.appendVar('IMAGE_FSTYPES', ' %s.verity' % verity_type)
+
+ # If we're using wic: we'll have to use partition images and not the rootfs
+ # source plugin so add the appropriate dependency.
+ if 'wic' in image_fstypes:
+ dep = ' %s:do_image_%s' % (pn, verity_type)
+ d.appendVarFlag('do_image_wic', 'depends', dep)
+}
--
2.25.0

8301 - 8320 of 57419