Date   

Re: systemd, ELF binaries and runtime dependency tracking

Luca Bocassi
 

On Tue, 2021-06-01 at 09:23 -0700, Khem Raj wrote:

On 6/1/21 9:13 AM, Luca Boccassi wrote:
On Tue, 2021-06-01 at 07:58 -0700, Khem Raj wrote:
On 5/31/21 3:40 PM, Paul Eggleton wrote:
Hi folks

Upstream in the systemd project, a proposal has been made to add a special
section to output ELF binaries to record soft runtime dependencies, so that
they could be read and utilised by distribution build systems such as ours
(they would be translated into RRECOMMENDS in our case). At the moment that
doesn't seem to have generated a huge amount of interest in the traditional
distro space, but would it be interesting for us?

https://github.com/systemd/systemd/pull/17416

For clarity, we (Microsoft) will volunteer to do the integration assuming the
above pull request gets reopened and merged, which is more likely if we
express our interest.
Finding dlopen dependencies is a neat idea, but it has to be accepted
cross distro, and also applications have to manually declare it in code
if I understand systemd's patch correctly. This will be hard to
accomplish as you can see changes are spread across apps from distro
point of view. Perhaps there is a smarter way of detecting adding them
in ELF spec itself and then have tools like linker help implement this
and also possibly collect the information or guide the users to achieve
this would be helpful.
Yes ideally ELF shared objects/the linker/the loader would support weak
symbols (like dylib on OSX). Unfortunately they do not, and it seems
there's no interest to add it becasue there's no concrete use case that
shows it's useful. But that cannot happen until there's some support
for it. Chicken and egg...
right and thats why I will be reluctant to go too far at distro level
unless there is general interest in wider communities as it can make us
an island.

There have been lots of theoretical discussions about pros and cons,
and my hope was that if at least one distro could find it useful, and
could show that it is in practice useful and the theoretical issues are
not that problematic and could be solved, others would follow suit.
you could tool it as a packageconfig for systemd alone and run with it
and see how it pans out.

So leaving aside other distros, is this something that would concretely
benefit the Yocto project for handling the systemd recipe? There are
currently 12 dlopen()-based optional dependencies in systemd, and the
number grows with each release.
we could certainly try that, provided systemd upstream is supportive of it.
Yeah, I was thinking of starting from the systemd recipe only. Given
the project has to add support for it, a distro-wide rollout wouldn't
make much sense anyway.

--
Kind regards,
Luca Boccassi


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Swapna Nannapaneni
 

Example helps. Thanks!!


On Mon, May 31, 2021 at 2:05 AM Zoran <zoran.stojsavljevic@...> wrote:
What about the following:
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

To be enhanced/added with the following:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-hardknott/README.md

Best Regards,
Zee
_______

On Fri, May 28, 2021 at 3:02 PM Swapna Nannapaneni
<sayinswapna@...> wrote:
>
> Typo. No leading space  INIT_MANAGER = "sysvinit".
>
> Thanks,
> Priya.
>
> On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
>>
>> > you don't want the leading space.
>>
>> I got the idea from reading
>> https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection
>>
>> But this is exactly why we need some explicit examples. :-)
>>
>> Zee
>> _______
>>
>> On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:
>> >
>> > On Fri, 28 May 2021, Zoran wrote:
>> >
>> > > > Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf
>> > >
>> > > Is it INIT_MANAGER  = " sysvinit" , or INIT_MANAGER  = "sysvinit" (no
>> > > blank at the beginning)?
>> > >
>> > > Thank you,
>> > > Zee
>> >
>> >   you don't want the leading space.
>> >
>> > rday




Re: systemd, ELF binaries and runtime dependency tracking

Khem Raj
 

On 6/1/21 9:13 AM, Luca Boccassi wrote:
On Tue, 2021-06-01 at 07:58 -0700, Khem Raj wrote:

On 5/31/21 3:40 PM, Paul Eggleton wrote:
Hi folks

Upstream in the systemd project, a proposal has been made to add a special
section to output ELF binaries to record soft runtime dependencies, so that
they could be read and utilised by distribution build systems such as ours
(they would be translated into RRECOMMENDS in our case). At the moment that
doesn't seem to have generated a huge amount of interest in the traditional
distro space, but would it be interesting for us?

https://github.com/systemd/systemd/pull/17416

For clarity, we (Microsoft) will volunteer to do the integration assuming the
above pull request gets reopened and merged, which is more likely if we
express our interest.
Finding dlopen dependencies is a neat idea, but it has to be accepted
cross distro, and also applications have to manually declare it in code
if I understand systemd's patch correctly. This will be hard to
accomplish as you can see changes are spread across apps from distro
point of view. Perhaps there is a smarter way of detecting adding them
in ELF spec itself and then have tools like linker help implement this
and also possibly collect the information or guide the users to achieve
this would be helpful.
Yes ideally ELF shared objects/the linker/the loader would support weak
symbols (like dylib on OSX). Unfortunately they do not, and it seems
there's no interest to add it becasue there's no concrete use case that
shows it's useful. But that cannot happen until there's some support
for it. Chicken and egg...
right and thats why I will be reluctant to go too far at distro level unless there is general interest in wider communities as it can make us an island.

There have been lots of theoretical discussions about pros and cons,
and my hope was that if at least one distro could find it useful, and
could show that it is in practice useful and the theoretical issues are
not that problematic and could be solved, others would follow suit.
you could tool it as a packageconfig for systemd alone and run with it and see how it pans out.

So leaving aside other distros, is this something that would concretely
benefit the Yocto project for handling the systemd recipe? There are
currently 12 dlopen()-based optional dependencies in systemd, and the
number grows with each release.
we could certainly try that, provided systemd upstream is supportive of it.


Re: systemd, ELF binaries and runtime dependency tracking

Luca Bocassi
 

On Tue, 2021-06-01 at 07:58 -0700, Khem Raj wrote:

On 5/31/21 3:40 PM, Paul Eggleton wrote:
Hi folks

Upstream in the systemd project, a proposal has been made to add a special
section to output ELF binaries to record soft runtime dependencies, so that
they could be read and utilised by distribution build systems such as ours
(they would be translated into RRECOMMENDS in our case). At the moment that
doesn't seem to have generated a huge amount of interest in the traditional
distro space, but would it be interesting for us?

https://github.com/systemd/systemd/pull/17416

For clarity, we (Microsoft) will volunteer to do the integration assuming the
above pull request gets reopened and merged, which is more likely if we
express our interest.
Finding dlopen dependencies is a neat idea, but it has to be accepted
cross distro, and also applications have to manually declare it in code
if I understand systemd's patch correctly. This will be hard to
accomplish as you can see changes are spread across apps from distro
point of view. Perhaps there is a smarter way of detecting adding them
in ELF spec itself and then have tools like linker help implement this
and also possibly collect the information or guide the users to achieve
this would be helpful.
Yes ideally ELF shared objects/the linker/the loader would support weak
symbols (like dylib on OSX). Unfortunately they do not, and it seems
there's no interest to add it becasue there's no concrete use case that
shows it's useful. But that cannot happen until there's some support
for it. Chicken and egg...

There have been lots of theoretical discussions about pros and cons,
and my hope was that if at least one distro could find it useful, and
could show that it is in practice useful and the theoretical issues are
not that problematic and could be solved, others would follow suit.

So leaving aside other distros, is this something that would concretely
benefit the Yocto project for handling the systemd recipe? There are
currently 12 dlopen()-based optional dependencies in systemd, and the
number grows with each release.

--
Kind regards,
Luca Boccassi


Yocto Technical Team Minutes, Engineering Sync, for June 1 2021

Trevor Woerner
 

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

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

== attendees ==
Trevor Woerner, Stephen Jolley, Colin McAllister, Armin Kuster, Joshua Watt,
Steve Sakoman, Saul Wold, Richard Purdie, Philip Ballister, Bruce Ashfield,
Randy MacLeod, Michael Ambrus, Michael Halstead, Daiane Angolini, Peter
Kjellerstedt, Trevor Gamblin, Ross Burton, Tim Orling, Alexandre Belloni,
Jan-Simon Möller, Scott Murray, Tony Tascioglu

== notes ==
- 3.4 M1 (honister) to be built next week
- 3.1.8 (dunfell) passed QA, waiting final approval for release
- CVE issue count: master=6, hardknott=14
- AUH to run more regularly
- multiconfig issues still not ironed out
- ptest based on core-image-minimal instead of core-image-sato
- record high levels of AB intermittent issues

== general ==
RP: AB int issues seemed to be helped by limited the number of threads used
for compression


RP: two cases of trying to talk to upstream but found problems with our
logging, upstream says “go away and fix your logging” before we can
continue discussions


PeterK: question about yocto-poky tags
RP: we stopped adding “hardknott-pokyversion” (e.g. “hardknott-25.0”)
tags and this broke PeterK’s workflow. i would prefer to move away from
these tags and use yocto tags instead
PeterK: i’m okay moving to something new. “hardknott-3.3.1” would be
better than “hardknott-25.0”. also, could we wait and not change this
in the middle of a release series? (i.e. wait for the first release of
honister).
RP: i need to talk to MichaelH and Vineela and figure something out
RP: this is part of a larger task to rationalize the release process a bit
better (e.g. also need to tie in the documentation releases too with Nico)
RP: this tells us that people are using some of these things that we didn’t
think were being used
MichaelH: Vineela and I have a couple other release things we need to go
over, i’ll make a meeting. we could add tags going backwards so we
can transition now. this would give us some correlation to the tags in
openembedded etc


TimO: freenode?
RP: we didn’t do anything last week (due to Summit). i think Nico needs to
coordinate with MichaelH. i believe we are moving over to libera.chat
Scott: fd.o seems to have moved to OFTC
TrevorW: do we have ops in #yocto and #oe?
RP: yes
TimO + PhilipB: we’ve got slack too
JPEW: matrix integration too?
TimO: yes Jan-Simon


JPEW: SBOM
RP: please discuss on licensing email list
RP: i think there’s a plugfest going on and i don’t think anyone from YP
has signed up
Randy: Mark from WR is attending
RP: i’d like to fly the YP flag there
JPEW: details?
RP: https://docs.google.com/forms/d/e/1FAIpQLSdVOewc3uCZh39inX4X7QsA_jaQMqyrEiLFrWEZEpWxRCi3eQ/viewform
Philip: who’s interested in showing up at the plugfest?
JPEW: i would, but 22nd doesn’t work for me
Philip: i could go
??: what’s the layer?
Saul: meta-doubleopen
Ross: 22 doesn’t work for me either, but i could help put stuff together
beforehand


TrevorW: videos for YPS are up
https://www.youtube.com/playlist?list=PLD4M5FoHz-TwWYbaJwduH8ZYNYvva76QQ
https://elinux.org/YPS_May2021_Presentations


Jan-Simon: what’s the procedure for updating layerindex?
RP: PaulE is an admin
Ross: I was added recently
RP: MichaelH who are the admins?
MichaelH: myself, PaulE, Ross, JaMa, Nico, Randy
TimO: PaulE recently added me too
J-S: there are a lot of issues with the layerindex (e.g. emails bouncing)


Randy: should we move the next monthly meeting to avoid the 4th of July?
RP: sounds good, we’ll move it to July 13th


Re: systemd, ELF binaries and runtime dependency tracking

Khem Raj
 

On 5/31/21 3:40 PM, Paul Eggleton wrote:
Hi folks
Upstream in the systemd project, a proposal has been made to add a special
section to output ELF binaries to record soft runtime dependencies, so that
they could be read and utilised by distribution build systems such as ours
(they would be translated into RRECOMMENDS in our case). At the moment that
doesn't seem to have generated a huge amount of interest in the traditional
distro space, but would it be interesting for us?
https://github.com/systemd/systemd/pull/17416
For clarity, we (Microsoft) will volunteer to do the integration assuming the
above pull request gets reopened and merged, which is more likely if we
express our interest.
Finding dlopen dependencies is a neat idea, but it has to be accepted cross distro, and also applications have to manually declare it in code if I understand systemd's patch correctly. This will be hard to accomplish as you can see changes are spread across apps from distro point of view. Perhaps there is a smarter way of detecting adding them in ELF spec itself and then have tools like linker help implement this
and also possibly collect the information or guide the users to achieve this would be helpful.

Cheers
Paul


Yocto Project Status WW22`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M1

Next Deadline: 7th June 2021 YP 3.4 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • The first milestone of 3.4, M1 is due to be built next week.
  • YP 3.1.8 is has passed QA with one minor/intermittent ptest issue found and awaits final approval for release
  • We have a 10th anniversary T-shirt and some other Yocto Project items (hoody, stickers, mugs etc.) now available at https://yoctoproject.org/shop (EU and Americas sources)
  • The Yocto Project Virtual Summit was held last week and seemed successful, thanks to everyone who helped organize it or participated.
  • Master is now at 6 open CVE issues (one should be fixed by the curl upgrade) and hardknott is now at 14 open issues. Some pending patches to hardknott should reduce the count further.
  • We are going to trial running the AUH more regularly to try and keep on top of recipe upgrade issues and reduce the size of the batches being processed.
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others. Richard is trying to fix but trying to fix autobuilder issues and other problems and these are slow builds to debug.
  • We have cleaned up the ptest images to be built around the minimal image rather than being tied to sato.
  • Intermittent autobuilder issues continue to occur and are now at a record high level. You  can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 build date 2021/06/07
  • YP 3.4 M1 Release date 2021/06/18
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.8 is being reviewed for release
  • YP 3.1.9 build date 2021/06/21
  • YP 3.1.9 release date 2021/07/02
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

Stephen Jolley
 

All,

 

Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (6/1) 

 

Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

 

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

 

When            Monthly from 8am to 9am on the first Tuesday Pacific Time

Where           Zoom Meeting: https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09

 

We are tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit?pli=1 Please request access if you want to assist in editing them.  The world should have view access.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


systemd, ELF binaries and runtime dependency tracking

Paul Eggleton <paul.eggleton@...>
 

Hi folks

Upstream in the systemd project, a proposal has been made to add a special
section to output ELF binaries to record soft runtime dependencies, so that
they could be read and utilised by distribution build systems such as ours
(they would be translated into RRECOMMENDS in our case). At the moment that
doesn't seem to have generated a huge amount of interest in the traditional
distro space, but would it be interesting for us?

https://github.com/systemd/systemd/pull/17416

For clarity, we (Microsoft) will volunteer to do the integration assuming the
above pull request gets reopened and merged, which is more likely if we
express our interest.

Cheers
Paul


M+ & H bugs with Milestone Movements WW22

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

12465

test case test_check_rpm_install_removal_log_file_size failed

randy.macleod@...

richard.purdie@...

3.99

3.4 M1

 

13768

base-files do_package fatal error in subprocess

randy.macleod@...

mingli.yu@...

3.3 M4

3.4 M2

 

13819

No clue when CONNECTIVITY_CHECK_URIS is unaccessible

randy.macleod@...

mingli.yu@...

3.3 M4

3.4 M2

 

14020

environment-setup script in multilib eSDK doesn't work for multilib variant

randy.macleod@...

liezhi.yang@...

3.3 M4

3.4 M1

 

14047

eSDK: python3.5.real: No such file or directory

randy.macleod@...

bluelightning@...

3.3 M3

3.4 M1

 

14060

devtool modify fails when applied on recipes using patches

randy.macleod@...

bluelightning@...

3.3 M3

3.4 M2

 

14100

SDKPATH should not reference SDK_VERSION

randy.macleod@...

ydirson@...

3.3 M3

3.4 M1

 

14120

pkg_postinst_ontarget_${PN}

randy.macleod@...

pokylinux@...

3.3 M3

3.4 M1

 

14146

Post-patch hook fails with submodules and PATCHTOOL=git and PATCH_COMMIT_FUNCTIONS=1

randy.macleod@...

bluelightning@...

3.3 M3

3.4 M2

 

14168

#new-recipe-makefile-based-package does not exist anymore

randy.macleod@...

michael.opdenacker@...

3.3 M3

3.4 M2

 

14192

gcc/kernel: crypto/aegis128-neon-inner.c can not be built anymore

randy.macleod@...

raj.khem@...

3.3 M3

3.4 M1

 

14254

oe-selftest-centos: gotoolchain.oeGoToolchainSelfTest.test_go_dep_build failed

randy.macleod@...

raj.khem@...

3.3 M3

3.4 M1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW22!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

6

akuster808@...

1

trevor.gamblin@...

1

richard.purdie@...

1

alexandre.belloni@...

1

nicolas.dechesne@...

1

JPEWhacker@...

1

Grand Total

12

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW22 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 106 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

ross@...

32

richard.purdie@...

31

david.reyna@...

22

bruce.ashfield@...

20

michael.opdenacker@...

20

bluelightning@...

12

trevor.gamblin@...

11

akuster808@...

11

timothy.t.orling@...

11

JPEWhacker@...

11

sakib.sajal@...

10

randy.macleod@...

9

kai.kang@...

8

hongxu.jia@...

6

Qi.Chen@...

6

mingli.yu@...

6

tony.tascioglu@...

5

raj.khem@...

5

chee.yang.lee@...

5

yi.zhao@...

4

alexandre.belloni@...

3

mostthingsweb@...

3

alejandro@...

2

yf3yu@...

2

jaewon@...

2

ydirson@...

2

jon.mason@...

2

pokylinux@...

2

mshah@...

2

john.kaldas.enpj@...

1

shachar@...

1

liezhi.yang@...

1

dl9pf@...

1

mister_rs@...

1

open.source@...

1

devendra.tewari@...

1

Martin.Jansa@...

1

mhalstead@...

1

douglas.royds@...

1

stacygaikovaia@...

1

diego.sueiro@...

1

yoctoproject@...

1

kergoth@...

1

nicolas.dechesne@...

1

thomas.perrot@...

1

mark.hatle@...

1

naveen.kumar.saini@...

1

saul.wold@...

1

Nathan.Dunne@...

1

jeanmarie.lemetayer@...

1

kexin.hao@...

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  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

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 353 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.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

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

 


Bitbake failure

Cris Scott
 

Not sure who to ask about this.

Using https://push.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/lighttpd/lighttpd_1.4.59.bb to build lighttpd, bitbake fails, and I receive tons of messages that look like:

 

ERROR: lighttpd-1.4.59-r0 do_package_qa: QA Issue: /usr/lib/mod_staticfile.so contained in package lighttpd-module-staticfile requires libc.so.6(GLIBC_2.4), but no providers found in RDEPENDS_lighttpd-module-staticfile? [file-rdeps]

 

 

Can someone point me in the right direction to resolve this?

 

-Bill

 


kernel init debug features

Monsees, Steven C (US)
 

 

I have kernels based off “rocko” and “zeus” for both Arm and Intel… all using sysvinit (not systemd).

 

Under the Yocto build system, how can I easily set the following kernel configuration variables based on the build for testing/debug ?

 

·        sched_rt_period_us

·        sched_rt_runtime_us

·        overcommit_memory

 

thanks,

Steve


Conditionally install files depending on locale

Amr Bekhit
 

Hello,

I'm trying to put together a recipe where I conditionally install files depending on the image locale. I can see from the reference manual that Yocto will use the contents of IMAGE_LINGUAS to install locales during the root filesystem construction process. How can I go about creating locales for my custom packages/recipes?


[meta-security][PATCH 4/4] meta-hardening/initscripts: missed overide.

Armin Kuster
 

Helps pass YCL.

Signed-off-by: Armin Kuster <akuster808@...>
---
.../recipes-core/initscripts/initscripts_1.0.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-hardening/recipes-core/initscripts/initscripts_1.0.bbappend b/meta-hardening/recipes-core/initscripts/initscripts_1.0.bbappend
index 896b039..f943cb3 100644
--- a/meta-hardening/recipes-core/initscripts/initscripts_1.0.bbappend
+++ b/meta-hardening/recipes-core/initscripts/initscripts_1.0.bbappend
@@ -1,4 +1,4 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+FILESEXTRAPATHS_prepend_harden := "${THISDIR}/files:"

SRC_URI_append_harden = " file://mountall.sh"

--
2.25.1


[meta-security][PATCH 3/4] meta-integrity: YCL fixups

Armin Kuster
 

We wont need the linux-% once the kernel-feature class is included in
core.
Move the inherit into the image itself.
Drop kernel patches not being used.

Signed-off-by: Armin Kuster <akuster808@...>
---
.../images/integrity-image-minimal.bb | 2 +
.../recipes-kernel/linux/linux-%.bbappend | 5 -
.../0001-ima-fix-ima_inode_post_setattr.patch | 51 -------
...for-creating-files-using-the-mknodat.patch | 138 ------------------
...-file-hash-setting-by-user-to-fix-an.patch | 60 --------
5 files changed, 2 insertions(+), 254 deletions(-)
delete mode 100644 meta-integrity/recipes-kernel/linux/linux-%.bbappend
delete mode 100644 meta-integrity/recipes-kernel/linux/linux/0001-ima-fix-ima_inode_post_setattr.patch
delete mode 100644 meta-integrity/recipes-kernel/linux/linux/0002-ima-add-support-for-creating-files-using-the-mknodat.patch
delete mode 100644 meta-integrity/recipes-kernel/linux/linux/Revert-ima-limit-file-hash-setting-by-user-to-fix-an.patch

diff --git a/meta-integrity/recipes-core/images/integrity-image-minimal.bb b/meta-integrity/recipes-core/images/integrity-image-minimal.bb
index 1a3a30a..4e7895a 100644
--- a/meta-integrity/recipes-core/images/integrity-image-minimal.bb
+++ b/meta-integrity/recipes-core/images/integrity-image-minimal.bb
@@ -13,6 +13,8 @@ IMAGE_INSTALL = "\
LICENSE = "MIT"

inherit core-image
+inherit ${@bb.utils.contains('DISTRO_FEATURES', 'modsign', 'kernel-modsign', '', d)}
+

export IMAGE_BASENAME = "integrity-image-minimal"

diff --git a/meta-integrity/recipes-kernel/linux/linux-%.bbappend b/meta-integrity/recipes-kernel/linux/linux-%.bbappend
deleted file mode 100644
index f9a48cd..0000000
--- a/meta-integrity/recipes-kernel/linux/linux-%.bbappend
+++ /dev/null
@@ -1,5 +0,0 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "ima", " features/ima/ima.scc", "" ,d)}"
-
-KERNEL_FEATURES_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'modsign', ' features/ima/modsign.scc', '', d)}"
-
-inherit ${@bb.utils.contains('DISTRO_FEATURES', 'modsign', 'kernel-modsign', '', d)}
diff --git a/meta-integrity/recipes-kernel/linux/linux/0001-ima-fix-ima_inode_post_setattr.patch b/meta-integrity/recipes-kernel/linux/linux/0001-ima-fix-ima_inode_post_setattr.patch
deleted file mode 100644
index 64016dd..0000000
--- a/meta-integrity/recipes-kernel/linux/linux/0001-ima-fix-ima_inode_post_setattr.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 45ea681ebc0dd44aaec5d3cc4143b9722070d3ac Mon Sep 17 00:00:00 2001
-From: Mimi Zohar <zohar@...>
-Date: Tue, 8 Mar 2016 16:43:55 -0500
-Subject: [PATCH] ima: fix ima_inode_post_setattr
-
-Changing file metadata (eg. uid, guid) could result in having to
-re-appraise a file's integrity, but does not change the "new file"
-status nor the security.ima xattr. The IMA_PERMIT_DIRECTIO and
-IMA_DIGSIG_REQUIRED flags are policy rule specific. This patch
-only resets these flags, not the IMA_NEW_FILE or IMA_DIGSIG flags.
-
-With this patch, changing the file timestamp will not remove the
-file signature on new files.
-
-Upstream-Status: Accepted [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/security/integrity/ima/ima_appraise.c?id=42a4c603198f0d45b7aa936d3ac6ba1b8bd14a1b]
-
-Reported-by: Dmitry Rozhkov <dmitry.rozhkov@...>
-Signed-off-by: Mimi Zohar <zohar@...>
----
- security/integrity/ima/ima_appraise.c | 2 +-
- security/integrity/integrity.h | 1 +
- 2 files changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
-index 4df493e..a384ba1 100644
---- a/security/integrity/ima/ima_appraise.c
-+++ b/security/integrity/ima/ima_appraise.c
-@@ -327,7 +327,7 @@ void ima_inode_post_setattr(struct dentry *dentry)
- if (iint) {
- iint->flags &= ~(IMA_APPRAISE | IMA_APPRAISED |
- IMA_APPRAISE_SUBMASK | IMA_APPRAISED_SUBMASK |
-- IMA_ACTION_FLAGS);
-+ IMA_ACTION_RULE_FLAGS);
- if (must_appraise)
- iint->flags |= IMA_APPRAISE;
- }
-diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
-index 0fc9519..f9decae 100644
---- a/security/integrity/integrity.h
-+++ b/security/integrity/integrity.h
-@@ -28,6 +28,7 @@
-
- /* iint cache flags */
- #define IMA_ACTION_FLAGS 0xff000000
-+#define IMA_ACTION_RULE_FLAGS 0x06000000
- #define IMA_DIGSIG 0x01000000
- #define IMA_DIGSIG_REQUIRED 0x02000000
- #define IMA_PERMIT_DIRECTIO 0x04000000
---
-2.5.0
-
diff --git a/meta-integrity/recipes-kernel/linux/linux/0002-ima-add-support-for-creating-files-using-the-mknodat.patch b/meta-integrity/recipes-kernel/linux/linux/0002-ima-add-support-for-creating-files-using-the-mknodat.patch
deleted file mode 100644
index 6ab7ce2..0000000
--- a/meta-integrity/recipes-kernel/linux/linux/0002-ima-add-support-for-creating-files-using-the-mknodat.patch
+++ /dev/null
@@ -1,138 +0,0 @@
-From baaec960e9e7be0b526eaf831b079ddfe5c15124 Mon Sep 17 00:00:00 2001
-From: Mimi Zohar <zohar@...>
-Date: Thu, 10 Mar 2016 18:19:20 +0200
-Subject: [PATCH] ima: add support for creating files using the mknodat
- syscall
-
-Commit 3034a14 "ima: pass 'opened' flag to identify newly created files"
-stopped identifying empty files as new files. However new empty files
-can be created using the mknodat syscall. On systems with IMA-appraisal
-enabled, these empty files are not labeled with security.ima extended
-attributes properly, preventing them from subsequently being opened in
-order to write the file data contents. This patch marks these empty
-files, created using mknodat, as new in order to allow the file data
-contents to be written.
-
-Files with security.ima xattrs containing a file signature are considered
-"immutable" and can not be modified. The file contents need to be
-written, before signing the file. This patch relaxes this requirement
-for new files, allowing the file signature to be written before the file
-contents.
-
-Upstream-Status: Accepted [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/security/integrity/ima/ima_appraise.c?id=05d1a717ec0430c916a749b94eb90ab74bbfa356]
-
-Signed-off-by: Mimi Zohar <zohar@...>
----
- fs/namei.c | 2 ++
- include/linux/ima.h | 7 ++++++-
- security/integrity/ima/ima_appraise.c | 3 +++
- security/integrity/ima/ima_main.c | 32 +++++++++++++++++++++++++++++++-
- 4 files changed, 42 insertions(+), 2 deletions(-)
-
-diff --git a/fs/namei.c b/fs/namei.c
-index ccd7f98..19502da 100644
---- a/fs/namei.c
-+++ b/fs/namei.c
-@@ -3526,6 +3526,8 @@ retry:
- switch (mode & S_IFMT) {
- case 0: case S_IFREG:
- error = vfs_create(path.dentry->d_inode,dentry,mode,true);
-+ if (!error)
-+ ima_post_path_mknod(dentry);
- break;
- case S_IFCHR: case S_IFBLK:
- error = vfs_mknod(path.dentry->d_inode,dentry,mode,
-diff --git a/include/linux/ima.h b/include/linux/ima.h
-index 120ccc5..7f51971 100644
---- a/include/linux/ima.h
-+++ b/include/linux/ima.h
-@@ -20,7 +20,7 @@ extern void ima_file_free(struct file *file);
- extern int ima_file_mmap(struct file *file, unsigned long prot);
- extern int ima_module_check(struct file *file);
- extern int ima_fw_from_file(struct file *file, char *buf, size_t size);
--
-+extern void ima_post_path_mknod(struct dentry *dentry);
- #else
- static inline int ima_bprm_check(struct linux_binprm *bprm)
- {
-@@ -52,6 +52,11 @@ static inline int ima_fw_from_file(struct file *file, char *buf, size_t size)
- return 0;
- }
-
-+static inline void ima_post_path_mknod(struct dentry *dentry)
-+{
-+ return;
-+}
-+
- #endif /* CONFIG_IMA */
-
- #ifdef CONFIG_IMA_APPRAISE
-diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
-index 4df493e..20806ea 100644
---- a/security/integrity/ima/ima_appraise.c
-+++ b/security/integrity/ima/ima_appraise.c
-@@ -274,6 +274,11 @@ out:
- xattr_value->type != EVM_IMA_XATTR_DIGSIG)) {
- if (!ima_fix_xattr(dentry, iint))
- status = INTEGRITY_PASS;
-+ } else if ((inode->i_size == 0) &&
-+ (iint->flags & IMA_NEW_FILE) &&
-+ (xattr_value &&
-+ xattr_value->type == EVM_IMA_XATTR_DIGSIG)) {
-+ status = INTEGRITY_PASS;
- }
- integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, filename,
- op, cause, rc, 0);
-diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
-index eeee00dc..705bf78 100644
---- a/security/integrity/ima/ima_main.c
-+++ b/security/integrity/ima/ima_main.c
-@@ -242,7 +242,8 @@ static int process_measurement(struct file *file, int mask, int function,
- ima_audit_measurement(iint, pathname);
-
- out_digsig:
-- if ((mask & MAY_WRITE) && (iint->flags & IMA_DIGSIG))
-+ if ((mask & MAY_WRITE) && (iint->flags & IMA_DIGSIG) &&
-+ !(iint->flags & IMA_NEW_FILE))
- rc = -EACCES;
- kfree(xattr_value);
- out_free:
-@@ -310,6 +311,35 @@ int ima_file_check(struct file *file, int mask, int opened)
- EXPORT_SYMBOL_GPL(ima_file_check);
-
- /**
-+ * ima_post_path_mknod - mark as a new inode
-+ * @dentry: newly created dentry
-+ *
-+ * Mark files created via the mknodat syscall as new, so that the
-+ * file data can be written later.
-+ */
-+void ima_post_path_mknod(struct dentry *dentry)
-+{
-+ struct integrity_iint_cache *iint;
-+ struct inode *inode;
-+ int must_appraise;
-+
-+ if (!dentry || !dentry->d_inode)
-+ return;
-+
-+ inode = dentry->d_inode;
-+ if (inode->i_size != 0)
-+ return;
-+
-+ must_appraise = ima_must_appraise(inode, MAY_ACCESS, FILE_CHECK);
-+ if (!must_appraise)
-+ return;
-+
-+ iint = integrity_inode_get(inode);
-+ if (iint)
-+ iint->flags |= IMA_NEW_FILE;
-+}
-+
-+/**
- * ima_module_check - based on policy, collect/store/appraise measurement.
- * @file: pointer to the file to be measured/appraised
- *
---
-2.5.0
-
diff --git a/meta-integrity/recipes-kernel/linux/linux/Revert-ima-limit-file-hash-setting-by-user-to-fix-an.patch b/meta-integrity/recipes-kernel/linux/linux/Revert-ima-limit-file-hash-setting-by-user-to-fix-an.patch
deleted file mode 100644
index 157c007..0000000
--- a/meta-integrity/recipes-kernel/linux/linux/Revert-ima-limit-file-hash-setting-by-user-to-fix-an.patch
+++ /dev/null
@@ -1,60 +0,0 @@
-From a34d61850b680c152e1dcc958ee83c3ab3261c3d Mon Sep 17 00:00:00 2001
-From: Patrick Ohly <patrick.ohly@...>
-Date: Tue, 15 Nov 2016 10:10:23 +0100
-Subject: [PATCH] Revert "ima: limit file hash setting by user to fix and log
- modes"
-
-This reverts commit c68ed80c97d9720f51ef31fe91560fdd1e121533.
-
-The original motivation was security hardening ("File hashes are
-automatically set and updated and should not be manually set.")
-
-However, that hardening ignores and breaks some valid use cases:
-- File hashes might not be set because the file is currently
- outside of the policy and therefore have to be set by the
- creator. Examples:
- - Booting into an initramfs with an IMA-enabled kernel but
- without setting an IMA policy, then installing
- the OS onto the target partition by unpacking a rootfs archive
- which has the file hashes pre-computed.
- - Unpacking a file into a staging area with meta data (like owner)
- that leaves the file outside of the current policy, then changing
- the meta data such that it becomes part of the current policy.
-- "should not be set manually" implies that the creator is aware
- of IMA semantic, the current system's configuration, and then
- skips setting file hashes in security.ima if (and only if) the
- kernel would prevent it. That's not the case for standard, unmodified
- tools. Example: unpacking an archive with security.ima xattrs with
- bsdtar or GNU tar.
-
-Upstream-Status: Submitted [https://sourceforge.net/p/linux-ima/mailman/message/35492824/]
-
-Signed-off-by: Patrick Ohly <patrick.ohly@...>
----
- security/integrity/ima/ima_appraise.c | 8 ++------
- 1 file changed, 2 insertions(+), 6 deletions(-)
-
-diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
-index 4b9b4a4..b8b2dd9 100644
---- a/security/integrity/ima/ima_appraise.c
-+++ b/security/integrity/ima/ima_appraise.c
-@@ -385,14 +385,10 @@ int ima_inode_setxattr(struct dentry *dentry, const char *xattr_name,
- result = ima_protect_xattr(dentry, xattr_name, xattr_value,
- xattr_value_len);
- if (result == 1) {
-- bool digsig;
--
- if (!xattr_value_len || (xvalue->type >= IMA_XATTR_LAST))
- return -EINVAL;
-- digsig = (xvalue->type == EVM_IMA_XATTR_DIGSIG);
-- if (!digsig && (ima_appraise & IMA_APPRAISE_ENFORCE))
-- return -EPERM;
-- ima_reset_appraise_flags(d_backing_inode(dentry), digsig);
-+ ima_reset_appraise_flags(d_backing_inode(dentry),
-+ (xvalue->type == EVM_IMA_XATTR_DIGSIG) ? 1 : 0);
- result = 0;
- }
- return result;
---
-2.1.4
-
--
2.25.1


[meta-security][PATCH 2/4] meta-tpm: remove linux-yocto

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
.../recipes-kernel/linux/linux-yocto/tpm.cfg | 8 --------
.../recipes-kernel/linux/linux-yocto/tpm.scc | 3 ---
.../recipes-kernel/linux/linux-yocto/tpm2.cfg | 6 ------
.../recipes-kernel/linux/linux-yocto/tpm2.scc | 3 ---
.../linux/linux-yocto/tpm_i2c.cfg | 15 ---------------
.../linux/linux-yocto/tpm_i2c.scc | 6 ------
.../linux/linux-yocto/tpm_x86.cfg | 4 ----
.../recipes-kernel/linux/linux-yocto/vtpm.cfg | 5 -----
.../recipes-kernel/linux/linux-yocto/vtpm.scc | 4 ----
.../linux/linux-yocto_5.%.bbappend | 17 -----------------
10 files changed, 71 deletions(-)
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/tpm.cfg
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/tpm.scc
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/tpm2.cfg
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/tpm2.scc
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/tpm_i2c.cfg
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/tpm_i2c.scc
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/tpm_x86.cfg
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/vtpm.cfg
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto/vtpm.scc
delete mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto_5.%.bbappend

diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm.cfg b/meta-tpm/recipes-kernel/linux/linux-yocto/tpm.cfg
deleted file mode 100644
index 8782823..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm.cfg
+++ /dev/null
@@ -1,8 +0,0 @@
-CONFIG_HW_RANDOM_TPM=y
-CONFIG_TCG_TPM=y
-CONFIG_TCG_TIS_CORE=y
-CONFIG_TCG_TIS=y
-CONFIG_SECURITYFS=y
-CONFIG_TCG_NSC=m
-CONFIG_TCG_ATMEL=m
-CONFIG_TCG_INFINEON=m
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm.scc b/meta-tpm/recipes-kernel/linux/linux-yocto/tpm.scc
deleted file mode 100644
index 2949ed4..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm.scc
+++ /dev/null
@@ -1,3 +0,0 @@
-define KFEATURE_DESCRIPTION "Enable TPM"
-
-kconf hardware tpm.cfg
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm2.cfg b/meta-tpm/recipes-kernel/linux/linux-yocto/tpm2.cfg
deleted file mode 100644
index a81b54d..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm2.cfg
+++ /dev/null
@@ -1,6 +0,0 @@
-CONFIG_HW_RANDOM_TPM=y
-CONFIG_TCG_TPM=y
-CONFIG_TCG_TIS_CORE=y
-CONFIG_TCG_TIS=y
-CONFIG_TCG_CRB=y
-CONFIG_SECURITYFS=y
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm2.scc b/meta-tpm/recipes-kernel/linux/linux-yocto/tpm2.scc
deleted file mode 100644
index 088148f..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm2.scc
+++ /dev/null
@@ -1,3 +0,0 @@
-define KFEATURE_DESCRIPTION "Enable TPM 2.0"
-
-kconf hardware tpm2.cfg
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_i2c.cfg b/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_i2c.cfg
deleted file mode 100644
index 59993f9..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_i2c.cfg
+++ /dev/null
@@ -1,15 +0,0 @@
-CONFIG_HW_RANDOM_TPM=y
-CONFIG_TCG_TPM=y
-CONFIG_TCG_TIS_CORE=y
-CONFIG_TCG_TIS=y
-CONFIG_SECURITYFS=y
-
-CONFIG_REGMAP_I2C=y
-CONFIG_I2C_BOARDINFO=y
-CONFIG_I2C_COMPAT=y
-CONFIG_RTC_I2C_AND_SPI=y
-
-CONFIG_TCG_TIS_I2C_ATMEL=m
-CONFIG_TCG_TIS_I2C_INFINEON=m
-CONFIG_TCG_TIS_I2C_NUVOTON=m
-CONFIG_TCG_TIS_ST33ZP24_I2C=m
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_i2c.scc b/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_i2c.scc
deleted file mode 100644
index 0e4eedb..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_i2c.scc
+++ /dev/null
@@ -1,6 +0,0 @@
-define KFEATURE_DESCRIPTION "Enable TPM i2c"
-
-include features/i2c/i2c.scc
-
-kconf hardware tpm_i2c.cfg
-
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_x86.cfg b/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_x86.cfg
deleted file mode 100644
index 8be331a..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/tpm_x86.cfg
+++ /dev/null
@@ -1,4 +0,0 @@
-CONFIG_TCG_NSC=m
-CONFIG_TCG_ATMEL=m
-CONFIG_TCG_INFINEON=m
-CONFIG_TCG_TIS_ST33ZP24=m
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/vtpm.cfg b/meta-tpm/recipes-kernel/linux/linux-yocto/vtpm.cfg
deleted file mode 100644
index a8b3758..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/vtpm.cfg
+++ /dev/null
@@ -1,5 +0,0 @@
-CONFIG_HW_RANDOM_TPM=y
-CONFIG_TCG_TPM=y
-CONFIG_TCG_VTPM_PROXY=y
-CONFIG_SECURITYFS=y
-~
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto/vtpm.scc b/meta-tpm/recipes-kernel/linux/linux-yocto/vtpm.scc
deleted file mode 100644
index e842da6..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto/vtpm.scc
+++ /dev/null
@@ -1,4 +0,0 @@
-define KFEATURE_DESCRIPTION "Enable vTPM"
-
-kconf hardware vtpm.cfg
-
diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto_5.%.bbappend b/meta-tpm/recipes-kernel/linux/linux-yocto_5.%.bbappend
deleted file mode 100644
index cea8b1b..0000000
--- a/meta-tpm/recipes-kernel/linux/linux-yocto_5.%.bbappend
+++ /dev/null
@@ -1,17 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto:"
-
-# Enable tpm in kernel
-SRC_URI_append_x86 = " \
- ${@bb.utils.contains('MACHINE_FEATURES', 'tpm', 'file://tpm.scc', '', d)} \
- ${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 'file://tpm2.scc', '', d)} \
- "
-
-SRC_URI_append_x86-64 = " \
- ${@bb.utils.contains('MACHINE_FEATURES', 'tpm', 'file://tpm.scc', '', d)} \
- ${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 'file://tpm2.scc', '', d)} \
- "
-
-SRC_URI += " \
- ${@bb.utils.contains('MACHINE_FEATURES', 'tpm_i2c', 'file://tpm_i2c.scc', '', d)} \
- ${@bb.utils.contains('MACHINE_FEATURES', 'vtpm', 'file://vtpm.scc', '', d)} \
- "
--
2.25.1


[meta-security][PATCH 1/4] linux-yocto: remove bbappend

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-kernel/linux/linux-yocto-dev.bbappend | 3 ---
recipes-kernel/linux/linux-yocto_5.%.bbappend | 3 ---
2 files changed, 6 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-yocto-dev.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto_5.%.bbappend

diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
deleted file mode 100644
index fa536d0..0000000
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ /dev/null
@@ -1,3 +0,0 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
diff --git a/recipes-kernel/linux/linux-yocto_5.%.bbappend b/recipes-kernel/linux/linux-yocto_5.%.bbappend
deleted file mode 100644
index fa536d0..0000000
--- a/recipes-kernel/linux/linux-yocto_5.%.bbappend
+++ /dev/null
@@ -1,3 +0,0 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
--
2.25.1

4101 - 4120 of 57800