Date   

[meta-rockchip][PATCH v2] trusted-firmware-a: use 1500000 baud for serial console

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

TF-A runs between two u-boot stages which both uses 1500000 baud, it
just makes no sense to use the same UART at a different rate.

Here is a sample session with the successive stages, with TF-A artificial=
ly
separated for emphasis:

[20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
[20210406-175438.135956] Channel 0: DDR3, 933MHz
[20210406-175438.236974] BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS=3D1 Die=
BW=3D16 Size=3D1024MB
[20210406-175438.237000] Channel 1: DDR3, 933MHz
[20210406-175438.237004] BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS=3D1 Die=
BW=3D16 Size=3D1024MB
[20210406-175438.237008] 256B stride
[20210406-175438.237012] Trying to boot from BOOTROM
[20210406-175438.237015] Returning to boot ROM...
[20210406-175438.237018]
[20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +000=
0)
[20210406-175438.573431] Trying to boot from MMC1

[20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty
[20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020

[20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
[20210406-175441.393429]
[20210406-175441.393433] SoC: Rockchip rk3399

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
.../files/serial-console-baudrate.patch | 36 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 5 +++
2 files changed, 41 insertions(+)
create mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-b=
audrate.patch

Changes in v2:
- added Upstream-Status tag

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate=
.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.pat=
ch
new file mode 100644
index 0000000..2d6e9bf
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,36 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@blade-group.com>
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 1500000.
+Upstream-Status: Inappropriate[other]
+
+TF-A runs between two u-boot stages which both uses 1500000 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce6=
2.
+Main reason for that change stated in https://developer.trustedfirmware.=
org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.
+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk=
3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
++++ b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**********************************************************************=
****
+ * UART related constants
+ **********************************************************************=
****/
+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 1500000
+ #define RK3399_UART_CLOCK 24000000
+=20
+ /**********************************************************************=
********
+--=20
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend=
b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 =3D " virtual/arm-none-eabi-gcc-nat=
ive"
=20
COMPATIBLE_MACHINE_append_rk3399 =3D "|rk3399"
COMPATIBLE_MACHINE_append_rk3328 =3D "|rk3328"
+
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+SRC_URI +=3D "\
+ file://serial-console-baudrate.patch \
+"
--=20
2.30.2


Re: [PATCH yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list

Nicolas Dechesne
 



On Wed, Apr 7, 2021 at 10:16 AM Nicolas Dechesne <nicolas.dechesne@...> wrote:
hey!

On Wed, Apr 7, 2021 at 9:31 AM Quentin Schulz <foss@...> wrote:
Hi Michael,

On April 6, 2021 10:58:20 PM UTC, Michael Halstead <mhalstead@...> wrote:
>All new releases are Sphinx ready so we exclude old tags and build for
>all the rest.

Thanks for starting this!
 
>
>Signed-off-by: Michael Halstead <mhalstead@...>
>---
> scripts/run-docs-build | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
>diff --git a/scripts/run-docs-build b/scripts/run-docs-build
>index 910f03d..13df34a 100755
>--- a/scripts/run-docs-build
>+++ b/scripts/run-docs-build
>@@ -7,6 +7,7 @@ ypdocs=$2/documentation/
> bbdocs=$3/doc/
> docs_buildtools=/srv/autobuilder/autobuilder.yoctoproject.org/pub/buildtools/x86_64-buildtools-docs-nativesdk-standalone-3.2+snapshot-20201105.sh
> outputdir=$builddir/output
>+excluded_tags="yocto-3.1.4 yocto-3.1.3 yocto-3.1.2 yocto-3.1.1 yocto-3.1 yocto-3.0.1 yocto-3.0 yocto-2.6.4 yocto-2.6.3 yocto-2.7.1 yocto-2.6.2 yocto-2.7 yocto-2.6.1 yocto-2.6 yocto-2.5.2 yocto-2.5.1 yocto-2.4.4 yocto-2.4.3 yocto-2.5 yocto-2.3.4 yocto-1.0.2 yocto-1.1.2 yocto-1.2.2 yocto-1.2.1 yocto-1.3 yocto-1.3.1 yocto-1.3.2 yocto-1.4.3 yocto-1.4.2 yocto-1.4.1 yocto-1.4 yocto-2.1.3 yocto-2.4.2 yocto-2.1.1 yocto-2.1.2 yocto-2.0.3 yocto-1.8.2 yocto-2.2.3 yocto-2.4.1 yocto-2.3.3 yocto-2.3.2 yocto-2.4 yocto-2.2.2 yocto-2.3.1 yocto-2.3 yocto-2.2.1 yocto-2.0.2 yocto-2.2 yocto-2.1 yocto-2.0.1 yocto-2.0 yocto-1.8.1 yocto-1.7.3 yocto-1.6.3 yocto-1.7.2 yocto-1.8 yocto-1.5.1"
>
>
> cd $builddir
>@@ -77,13 +78,18 @@ for branch in dunfell gatesgarth hardknott; do
> done
>
> # Yocto Project releases/tags
>-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do
>+cd $ypdocs
>+for tag in $(git tag -l  |grep 'yocto-' |sort); do

IIUC the man page,
git tag --list 'yocto-*' | sort

sort -V is even better since it does "natural sort of (version) numbers within text", let's get ready for 3.10 ;) 
 
And using -V, how about something along these lines:

v_sphinx='yocto-3.1.5'
for v in $(git tag --list 'yocto-*'); do
    first=$(printf '%s\n%s' $v $v_sphinx | sort -V | head -n1)
    if [ "$first" = "$v_sphinx" ]; then
        echo "Yocto $v uses Sphinx!"
    fi
done

and it outputs the following when I run it locally:

Yocto yocto-3.1.5 uses Sphinx!
Yocto yocto-3.1.6 uses Sphinx!
Yocto yocto-3.2 uses Sphinx!
Yocto yocto-3.2.1 uses Sphinx!
Yocto yocto-3.2.2 uses Sphinx!
Yocto yocto-3.2.3 uses Sphinx!



would be doing the same thing as the one command with grep above.
Discovered it recently so just wanted to share.

I guess this is something we can also do for bitbake Sphinx documentation?

yes.

Well, in fact no , we shouldn't, is a short answer ;) 

Here is the long answer.. 

For bitbake and YP, we currently publish: master, master-next and 'stable' branches (e.g. 1.46, 1.48, 1.50 for bitbake dunfell, gatesgarth, hardknott for YP). Then we also publish YP releases (and point releases), e.g. 3.1.5 and beyond, but  we don't publish anything for releases/point release of bitbake, At least just yet. And it's a 'bug'. Since the YP docs includes links (with intersphinx)  to bitbake docs, then when we look at a master, master-next or any branches on docs.yp.org, then the links are correct. for example if you look at

vs

this page has links to bitbake and it points respectively to:
and

Which is correct. 

[Side note: I've noticed that the hardknott page is wrong, since
I will send a patch for that]

Now if we look at a YP release, such as 
it has this link:

which is not correct, since it links to a bitbake 'branch' docs build, and not a bitbake 'release' docs build. 


 

Removed the git context inadvertently but, is =~ some bash built-in? I don't know what's the shebang on top but maybe we want to force it to bash since I'm not sure it's POSIX "compliant" anymore? 

It is bash already. 
 

Reviewed-by: Quentin Schulz <foss@...>

Thanks,
Quentin


Re: No significant diff b/w qemux86 and qemuarm poky build of core-image-minimal

Khem Raj
 

On Tue, Mar 30, 2021 at 2:20 PM Khem Raj <raj.khem@gmail.com> wrote:



On 3/30/21 1:48 PM, Ross Burton wrote:
On Tue, 30 Mar 2021 at 20:41, Khem Raj <raj.khem@gmail.com> wrote:
Thanks for this infor Randy, really appreciated, I think I will also
look at the h/w angle.
Khem: if you can reproduce this on demand with a clean build (ie
oe-init-build-env with a clean build directory, just set DL_DIR) then
enabling buildstats would give some interesting metrics.
buildstats-diff can compare two build runs and tell you what the
differences are.
yeah this is doing world build of not only core but several other layers
included a usual build takes around 10 hrs for this machine config, I am
planning to

1. Collect build stats
2. buiid another qemu machine on this VM

it could very well be rotting hardware underneath the VM.
To close the loop, it turned out to be the case that CPU performance
on VM has deteriorated
which stress-ng showed. The VM has been rebuilt and everything seems
to be holding fine now.
Thanks for your help and chiming in.

Ross


[PATCH v2 yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list

Michael Halstead
 

Build Sphinx docs for all versions newer than yocto-3.1.5 inclusive.
Integrate suggestions from Quentin Schulz and Nicolas Dechesne.

Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
---
scripts/run-docs-build | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 910f03d..52bd567 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -77,13 +77,19 @@ for branch in dunfell gatesgarth hardknott; do
done

# Yocto Project releases/tags
-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do
- cd $ypdocs
- git checkout yocto-$tag
- make clean
- make publish
- mkdir $outputdir/$tag
- cp -r ./_build/final/* $outputdir/$tag
+v_sphinx='yocto-3.1.5' #This and newer versions have Sphinx docs.
+cd $ypdocs
+for tag in $(git tag --list 'yocto-*'); do
+ first=$(printf '%s\n%s' $tag $v_sphinx | sort --version-sort | head -n1)
+ if [ "$first" = "$v_sphinx" ]; then
+ cd $ypdocs
+ git checkout $tag
+ make clean
+ make publish
+ version=$(echo $tag | cut -c7-)
+ mkdir $outputdir/$version
+ cp -r ./_build/final/* $outputdir/$version
+ fi
done

# Update switchers.js with the copy from master ypdocs
--
2.30.2


Yocto Project Summit - registration open

Trevor Woerner
 

Registration is now open for the upcoming Yocto Project Summit!!

details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
CfP: https://pretalx.com/yocto-project-summit-2021/cfp
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

PS: Don't forget to get in your talk proposals! The CfP closes April 25th


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

Trevor Woerner
 

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

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

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

== attendees ==
Trevor Woerner, Stephen Jolley, Richard Purdie, Steve Sakoman, Peter
Kjellerstedt, Armin Kuster, Scott Murray, Michael Halstead, Bruce Ashfield,
Saul Wold, Joshua Watt, Jon Mason, Jan-Simon Möller, Randy MacLeod, Paul
Barker, Denys Dmytriyenko, Rob Wolley, sakib.sajal@windriver, Tim Orling,
Ross Burton, Philip Ballister, Daiane Angolini, Trevor Gamblin, Alejandro H

== notes ==
- close to building 3.3-rc1
- still need changelog, migration guide, release notes, etc
- released 3.2.3
- change to allow qemu to run from tmpfs
- can’t use cgroups
- lots of version upgrades, need to wait for 3.4
- ~50 intermittent AB issues
- planning doc available for 3.4

== general ==
RP: still thinking about what to do with docs for 3.3, still need to wait on
changelog, migration, release notes before we can release


RP: lots of I/O copying the qemu images before starting up the tests, causing
some of the timeouts, therefore the move to running from tmpfs


Bruce: there are some perf-tests things missing from master-next
RP: oops, missed it


SteveS: is the tmpfs something we want to backport to dunfell
RP: ultimately yes. low risk. but give it time on the AB first before merging.
should be a nice simple change


StephenJ: we were supposed to do a 3.1.7 last week but there wasn’t anything
for it
SteveS: i didn’t want to get in the way of master releases. there is another
bitbake change that i’d like to get in too, but we can do that anytime
StephenJ: we’ll want it behind the master release, but it should come out
sometime this month. i also have 3.1.8, 3.1.9, and 3.1.10 in the planning
docs, as milestones
RP: we’ll get 3.3 build, then we can do the next 3.1.y after that


PaulB: prserv modernization (async-io json-rpc startup/shutdown readonly-mode)
i’ve now got all that done, oe-selftest is passing, bitbake self-test
is passing. still have another day of tidying up. should it be sent as an
RFC?
RP: it’s good timing. i think it’s 3.4 material and it’s a good time to
put it out there (see 3.4 planning doc).
RP: PaulG also put out some patches to make the fetcher more efficient
regarding kernel fetching which also sounds like 3.4 material. master-next
is where i’m putting 3.4 things for now.
PaulB: i think they’re all bitbake patches, and there’s one oe-core patch.
for the RFC i’ll just send it all together and we can split them up later
JPEW: can you CC me please
PaulB: np


Randy: memory-resident bitbake as the default?
RP: i’d like to see it, but depends on whether we can get all the bugs
worked out before. the blocker was that enabling it for oe-selftest causes
carnage. we need to figure out why, it shouldn’t cause any issues, but
it does. once we can get oe-selftest working then i’m game for enabling
it by default and simply fixing anything that comes up. this change
retrofits bitbake to do something it wasn’t designed to do. there’s
some assumption somewhere that’s being violated that we don’t know
RP: the tmpfs change i just made is a good example of showing you how to
change every test
TrevorG: re doc change, i submitted a v2 (thanks MichaelO for review) and
added instructions. i think we want something added to the -dev manual?
RP: yes, we now have a doc person and we want to cover the AB in the test
manual. the test manual we currently have is just a start, mostly
pointers, but i’d like to see it expanded
TimO: i’d like to add a ptest for python or ptest for perl section too to
the test manual


RP: re AB-int. can we list out what’s in the I/O queue that the kernel is
processing? i’m guessing not (security reasons) but it would be great if
it could. in the past we’ve listed out processes that are occurring when
failures occur; that allowed us to identify an issue with building webkit,
but there’s only so much a process listing will give us and there are
other stats we should look at at failure time
Randy: yes, we’ve looked at a bunch of stuff, but most of them need root
permissions
RP: if the tools are standard then we can give access to those tools to the
poky builder user
RP: with more tooling we’ll probably see a lot of these qemu startup issues
and we’ll probably also see lots of bitbake timeout (60s no response)
issues. iow, a large set of issues, i’m hoping, will condense down to a
handful of issues. there was also a libgomp issue that JPEW was seeing,
but even after that fix we’re still seeing the AB-int issues


TimO: patchwork. have we looked at upgrading to a newer version
MichaelH: i’m trying to get a -dev version working, i’d like to pull you
in (TimO) to help if you’re available
TimO: yes, that’d be great
RP: MichaelH is setting up a -dev instance of patchwork to see if we can get a
bunch of things working (i.e. integrate with AB, integrate with testing,
etc) to see if this is viable
TimO: my analysis (from last year) was that the ozlabs one was really old, but
the freedesktop.org patchwork version is better
MichaelH: and in the past year it looks like the ozlabs one has pulled in all
the things from fd.o and is now, in fact, ahead of the ozlabs one. so
that’s the one that i’ve been working with (i.e. ozlabs)
RP: i think the new system is a lot easier to work with, it seems easier to
pull patches in


ScottM: (to Armin) moving libseccomp to meta-oe. maybe we should move it right
to oe-core?
Armin: it can go anywhere. Khem had an issue with it.
TimO: i think there are some things in meta-virt that need it
ScottM: i have some customers that need it, i always enable it, i used it with
systemd
Bruce: i debugged a k3s issue for ~3 months that turned out to be a libseccomp
issue, so it seems “needed” in most virt setups
RP: we need to be known as being able to support virtualization and handling
these sorts of issues for our users, so i’m open to taking it in oe-core
<Armin agrees to prepare a patch for oe-core>
RP: i can take something like that in master-next for now, even though master
isn’t open yet for new things. there are a bunch of things that we need
to consider moving to oe-core (this (seccomp), rust, etc) so now’s a
good time to have these discussions
PaulB: i’m for it, i’ve bumped up against some issues that could use these
things


Bruce: there are some virt recipes that try to download things in do_compile,
and that’s not a good thing
ScottM: there was a presentation doing this at the last conference
PaulB: maybe we should think about disabling network access during compile?


Armin: rustc in a devshell? mine always segfaults
Randy: depends on the args passed to rustc. can’t remember off the top of my
head.
Armin: segfault with stackX. sounds like the file issue like we were having
with pseudo. version 7 is going to need clang, so i want to get this done
first.


TimO: there’s talk of using rust for device drivers in the kernel, anyone
using any or planning on using any?
Randy: probably in upcoming kernels
TimO: we’ll need to figure out how to do that
Randy: we’ll have to figure that out when the time comes


RP: any other 3.4 issues?
TimO: recipetool for perl (which i’m working on). also ptest/pytest plugin
to make ptest output generic and consistent
RossB: another discussion to talk about changing the ptest output? it’d be
nice to migrate to a more structured, common format
TimO: <agree>
RP: i think this could be something that is added piece-meal, it doesn’t
have to be invasive, or all-or-nothing
Saul: i’m hoping to get the qmp stuff figured out for 3.4


RP: ptest-runner, anibal found and fixed some issues which i’ve pulled into
the next build. i don’t think they’ll cause anything to blow up
Randy: fixes in ptest-runner are pretty important
RP: i also upgraded diffoscope since it was causing hangs. they release every
week, so the release numbers increase rapidly, but the changes are small


TimO: RossB and i talked about upgrading matchbox to wayland, but i doubt
that’ll land for 3.4
RP: there are lots of changes in this area
ScottM: i’m interested too. maybe use libwayland
TimO: yes, that’s what we were thinking
RP: it’s a good time to start planning and thinking about it, maybe 3.4 or
3.5
JPEW: i looked at posh (phone gnome shell) advantage is that it can run any
gnome application unmodified, but it does need a lot of dependencies
TrevorG: i was looking at that too recently and thought it was good. i looked
at a competitor that didn’t do as well
JPEW: you need everything to build gnome-3 but then don't end up building
gnome 3 ;-)


Re: [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console

Trevor Woerner
 

On Wed, Apr 7, 2021 at 9:27 AM Joshua Watt <jpewhacker@gmail.com> wrote:
Please add Upstream-Status:
https://wiki.yoctoproject.org/wiki/Best_Known_Methods_(BKMs)_for_Package_Updating#Patch_Upstreaming


Re: [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console

Joshua Watt
 


On 4/6/21 6:47 PM, Yann Dirson wrote:
From: Yann Dirson <yann@...>

TF-A runs between two u-boot stages which both uses 1500000 baud, it
just makes no sense to use the same UART at a different rate.

Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:

 [20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
 [20210406-175438.135956] Channel 0: DDR3, 933MHz
 [20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
 [20210406-175438.237000] Channel 1: DDR3, 933MHz
 [20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
 [20210406-175438.237008] 256B stride
 [20210406-175438.237012] Trying to boot from BOOTROM
 [20210406-175438.237015] Returning to boot ROM...
 [20210406-175438.237018]
 [20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +0000)
 [20210406-175438.573431] Trying to boot from MMC1

 [20210406-175438.589254] NOTICE:  BL31: v2.3():v2.3-dirty
 [20210406-175440.534055] NOTICE:  BL31: Built : 15:56:43, Apr 20 2020

 [20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
 [20210406-175441.393429]
 [20210406-175441.393433] SoC: Rockchip rk3399

Very good. TF-A should work "out of the box" in meta-rockchip, so I think changing it's baudrate to 1500000 makes sense at this point (at least until u-boot can pass the DTB)


Signed-off-by: Yann Dirson <yann@...>
---
 .../files/serial-console-baudrate.patch       | 35 +++++++++++++++++++
 .../trusted-firmware-a_%.bbappend             |  5 +++
 2 files changed, 40 insertions(+)
 create mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
new file mode 100644
index 0000000..10b5a2b
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,35 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@...>
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 1500000.
+
+TF-A runs between two u-boot stages which both uses 1500000 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
+Main reason for that change stated in https://developer.trustedfirmware.org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.

Please add Upstream-Status:


+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
++++ b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**************************************************************************
+  * UART related constants
+  **************************************************************************/
+-#define RK3399_BAUDRATE			115200
++#define RK3399_BAUDRATE			1500000
+ #define RK3399_UART_CLOCK		24000000
+ 
+ /******************************************************************************
+-- 
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"
 
 COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
 COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI += "\
+    file://serial-console-baudrate.patch \
+"




QA notification for completed autobuilder build (yocto-3.3.rc2)

Pokybuild User <pokybuild@...>
 

A build flagged for QA (yocto-3.3.rc2) was completed on the autobuilder and is available at:


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


Build hash information:

bitbake: a1848a481e36b729c8e4130c394b1d462d4b488a
meta-arm: 219fd34b7676ffedd1a1ad3626ec4337391975f4
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 01cfc99a8f960917433a8a46b41bb4febb5b1993
meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
oecore: 14241ed09f9ed317045cf75a6d08416d3579bb8d
poky: e1839b58ebe05242a52fe050aa9a08140136aa0a



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org


Re: #yocto #sdk -XILINX/vivado dependencies #yocto #sdk

Monsees, Steven C (US)
 

No the vivado module sets up key variables, the lib path, and the include paths for building Xilinx low level drivers built into bootapp/kernel...

I need to be able to include these components in actual SDK build...

Steve

-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Tuesday, April 6, 2021 4:28 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk -XILINX/vivado dependencies

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


there is KERNEL_MODULE_AUTOLOAD which could be used to load modules on boot, don't know if that suffices to what you need but worth looking into.

On Tue, Apr 6, 2021 at 12:47 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



Working with zeus, aarch64, with Xilinx vivado dependencies…

Kerenl image and bootapp build and run correctly, need to be able to
build EXT SDK,,,



How do I incorporate the dependencies of the low level Xilinx FPGA support (i.e. “vivado”) into the Ext SDK build env ?



Is there a way to build in support so that the “module load” command would be usable from the “.conf” or the env-setup script, (i.e. “module load vivado…” ?



Thanks,

Steve






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

Anton Antonov
 

This patch fixes the issue:

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

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

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

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

DEPENDS = "openssl"

--
2.20.1


dpkg-scanpackages from my recipe

Mauro Ziliani
 

Hi all.
I'd like to use dpkg-scanpackages inside my recipe

The recipe copies some deb package into my folder ${D}/myfolder
Then I'd like to apply dpkg-scanpackages to ${D}/myfolder


I miss last step.
Running dpkg-scanpackages ${D}/myfolder ends with and error.
Dpkg.pm missing

How can I "install" Dpkg.pm so I can use dpkg-scanpackages directly from my recipe?

Best regards,
  MZ


Re: [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console

Zoran
 

Sure it is awkward when all tools have come to default
to 115200, but then is the situation so different from
when we transitioned from, say, 9600?
These are historical reasons. It started as 600, 1200, then quickly
jumped to 9600 (4x), stayed some time there, and then transitioned via
19600 to final 115200. But I also see baud rates of 57600.

115200/9600 = 12 The serial speed transmission was the issue here.

Hopefully someone from Rockchip will answer :)
Could not agree more with you on the statement. Hopefully! ;)

When working on this platform everyone now has his tools setup
for 1500000, because that's the vendor BSP settings. Would we
have good technical reasons to switch back ?
Since most of them use 115200. And clock divisors are adjusted to that
baud rate, my best guess.

Maybe the reason for that is that the base clocking tree frequency for
Rockchip could not derive 115200, rather 150000?!

Zee
_______

On Wed, Apr 7, 2021 at 10:55 AM Yann Dirson <yann.dirson@blade-group.com> wrote:

Le mer. 7 avr. 2021 à 06:07, Zoran Stojsavljevic
<zoran.stojsavljevic@gmail.com> a écrit :

+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 1500000
+ #define RK3399_UART_CLOCK 24000000
Interesting... For years (a few decades) everybody has used 115200 as
the standard setup for UART, as global definition.
Sure it is awkward when all tools have come to default to 115200, but then
is the situation so different form when we transitionned from, say, 9600 ?

Why suddenly somebody changed the UART baud rate to be non-standard?
From the speed point of view???

Don't think so.
Hopefully someone from Rockchip will answer :)

Should U-Boot be adjusted to the standard baud rate of 115200 for RK3399?
When working on this platform everyone now has his tools setup for 1500000,
because that's the vendor BSP settings. Would we have good technical reasons
to switch back ?



My two cent addendum/thinking,
Zee
_______


On Wed, Apr 7, 2021 at 1:47 AM Yann Dirson <yann.dirson@blade-group.com> wrote:

From: Yann Dirson <yann@blade-group.com>

TF-A runs between two u-boot stages which both uses 1500000 baud, it
just makes no sense to use the same UART at a different rate.

Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:

[20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
[20210406-175438.135956] Channel 0: DDR3, 933MHz
[20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
[20210406-175438.237000] Channel 1: DDR3, 933MHz
[20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
[20210406-175438.237008] 256B stride
[20210406-175438.237012] Trying to boot from BOOTROM
[20210406-175438.237015] Returning to boot ROM...
[20210406-175438.237018]
[20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +0000)
[20210406-175438.573431] Trying to boot from MMC1

[20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty
[20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020

[20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
[20210406-175441.393429]
[20210406-175441.393433] SoC: Rockchip rk3399

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
.../files/serial-console-baudrate.patch | 35 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 5 +++
2 files changed, 40 insertions(+)
create mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
new file mode 100644
index 0000000..10b5a2b
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,35 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@blade-group.com>
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 1500000.
+
+TF-A runs between two u-boot stages which both uses 1500000 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
+Main reason for that change stated in https://developer.trustedfirmware.org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.
+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
++++ b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**************************************************************************
+ * UART related constants
+ **************************************************************************/
+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 1500000
+ #define RK3399_UART_CLOCK 24000000
+
+ /******************************************************************************
+--
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"

COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI += "\
+ file://serial-console-baudrate.patch \
+"
--
2.30.2





--
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech


Re: [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console

Zoran
 

+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 1500000
+ #define RK3399_UART_CLOCK 24000000
Interesting... For years (a few decades) everybody has used 115200 as
the standard setup for UART, as global definition.

Why suddenly somebody changed the UART baud rate to be non-standard?
From the speed point of view???

Don't think so.

Should U-Boot be adjusted to the standard baud rate of 115200 for RK3399?

My two cent addendum/thinking,
Zee
_______


On Wed, Apr 7, 2021 at 1:47 AM Yann Dirson <yann.dirson@blade-group.com> wrote:

From: Yann Dirson <yann@blade-group.com>

TF-A runs between two u-boot stages which both uses 1500000 baud, it
just makes no sense to use the same UART at a different rate.

Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:

[20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
[20210406-175438.135956] Channel 0: DDR3, 933MHz
[20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
[20210406-175438.237000] Channel 1: DDR3, 933MHz
[20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
[20210406-175438.237008] 256B stride
[20210406-175438.237012] Trying to boot from BOOTROM
[20210406-175438.237015] Returning to boot ROM...
[20210406-175438.237018]
[20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +0000)
[20210406-175438.573431] Trying to boot from MMC1

[20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty
[20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020

[20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
[20210406-175441.393429]
[20210406-175441.393433] SoC: Rockchip rk3399

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
.../files/serial-console-baudrate.patch | 35 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 5 +++
2 files changed, 40 insertions(+)
create mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
new file mode 100644
index 0000000..10b5a2b
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,35 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@blade-group.com>
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 1500000.
+
+TF-A runs between two u-boot stages which both uses 1500000 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
+Main reason for that change stated in https://developer.trustedfirmware.org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.
+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
++++ b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**************************************************************************
+ * UART related constants
+ **************************************************************************/
+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 1500000
+ #define RK3399_UART_CLOCK 24000000
+
+ /******************************************************************************
+--
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"

COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI += "\
+ file://serial-console-baudrate.patch \
+"
--
2.30.2




Re: [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console

Yann Dirson
 

Le mer. 7 avr. 2021 à 06:07, Zoran Stojsavljevic
<zoran.stojsavljevic@gmail.com> a écrit :

+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 1500000
+ #define RK3399_UART_CLOCK 24000000
Interesting... For years (a few decades) everybody has used 115200 as
the standard setup for UART, as global definition.
Sure it is awkward when all tools have come to default to 115200, but then
is the situation so different form when we transitionned from, say, 9600 ?

Why suddenly somebody changed the UART baud rate to be non-standard?
From the speed point of view???

Don't think so.
Hopefully someone from Rockchip will answer :)

Should U-Boot be adjusted to the standard baud rate of 115200 for RK3399?
When working on this platform everyone now has his tools setup for 1500000,
because that's the vendor BSP settings. Would we have good technical reasons
to switch back ?



My two cent addendum/thinking,
Zee
_______


On Wed, Apr 7, 2021 at 1:47 AM Yann Dirson <yann.dirson@blade-group.com> wrote:

From: Yann Dirson <yann@blade-group.com>

TF-A runs between two u-boot stages which both uses 1500000 baud, it
just makes no sense to use the same UART at a different rate.

Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:

[20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
[20210406-175438.135956] Channel 0: DDR3, 933MHz
[20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
[20210406-175438.237000] Channel 1: DDR3, 933MHz
[20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
[20210406-175438.237008] 256B stride
[20210406-175438.237012] Trying to boot from BOOTROM
[20210406-175438.237015] Returning to boot ROM...
[20210406-175438.237018]
[20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +0000)
[20210406-175438.573431] Trying to boot from MMC1

[20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty
[20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020

[20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
[20210406-175441.393429]
[20210406-175441.393433] SoC: Rockchip rk3399

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
.../files/serial-console-baudrate.patch | 35 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 5 +++
2 files changed, 40 insertions(+)
create mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
new file mode 100644
index 0000000..10b5a2b
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,35 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@blade-group.com>
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 1500000.
+
+TF-A runs between two u-boot stages which both uses 1500000 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
+Main reason for that change stated in https://developer.trustedfirmware.org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.
+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
++++ b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**************************************************************************
+ * UART related constants
+ **************************************************************************/
+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 1500000
+ #define RK3399_UART_CLOCK 24000000
+
+ /******************************************************************************
+--
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"

COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI += "\
+ file://serial-console-baudrate.patch \
+"
--
2.30.2





--
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech


Re: [PATCH yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list

Nicolas Dechesne
 

hey!

On Wed, Apr 7, 2021 at 9:31 AM Quentin Schulz <foss@...> wrote:
Hi Michael,

On April 6, 2021 10:58:20 PM UTC, Michael Halstead <mhalstead@...> wrote:
>All new releases are Sphinx ready so we exclude old tags and build for
>all the rest.

Thanks for starting this!
 
>
>Signed-off-by: Michael Halstead <mhalstead@...>
>---
> scripts/run-docs-build | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
>diff --git a/scripts/run-docs-build b/scripts/run-docs-build
>index 910f03d..13df34a 100755
>--- a/scripts/run-docs-build
>+++ b/scripts/run-docs-build
>@@ -7,6 +7,7 @@ ypdocs=$2/documentation/
> bbdocs=$3/doc/
> docs_buildtools=/srv/autobuilder/autobuilder.yoctoproject.org/pub/buildtools/x86_64-buildtools-docs-nativesdk-standalone-3.2+snapshot-20201105.sh
> outputdir=$builddir/output
>+excluded_tags="yocto-3.1.4 yocto-3.1.3 yocto-3.1.2 yocto-3.1.1 yocto-3.1 yocto-3.0.1 yocto-3.0 yocto-2.6.4 yocto-2.6.3 yocto-2.7.1 yocto-2.6.2 yocto-2.7 yocto-2.6.1 yocto-2.6 yocto-2.5.2 yocto-2.5.1 yocto-2.4.4 yocto-2.4.3 yocto-2.5 yocto-2.3.4 yocto-1.0.2 yocto-1.1.2 yocto-1.2.2 yocto-1.2.1 yocto-1.3 yocto-1.3.1 yocto-1.3.2 yocto-1.4.3 yocto-1.4.2 yocto-1.4.1 yocto-1.4 yocto-2.1.3 yocto-2.4.2 yocto-2.1.1 yocto-2.1.2 yocto-2.0.3 yocto-1.8.2 yocto-2.2.3 yocto-2.4.1 yocto-2.3.3 yocto-2.3.2 yocto-2.4 yocto-2.2.2 yocto-2.3.1 yocto-2.3 yocto-2.2.1 yocto-2.0.2 yocto-2.2 yocto-2.1 yocto-2.0.1 yocto-2.0 yocto-1.8.1 yocto-1.7.3 yocto-1.6.3 yocto-1.7.2 yocto-1.8 yocto-1.5.1"
>
>
> cd $builddir
>@@ -77,13 +78,18 @@ for branch in dunfell gatesgarth hardknott; do
> done
>
> # Yocto Project releases/tags
>-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do
>+cd $ypdocs
>+for tag in $(git tag -l  |grep 'yocto-' |sort); do

IIUC the man page,
git tag --list 'yocto-*' | sort

sort -V is even better since it does "natural sort of (version) numbers within text", let's get ready for 3.10 ;) 
 
And using -V, how about something along these lines:

v_sphinx='yocto-3.1.5'
for v in $(git tag --list 'yocto-*'); do
    first=$(printf '%s\n%s' $v $v_sphinx | sort -V | head -n1)
    if [ "$first" = "$v_sphinx" ]; then
        echo "Yocto $v uses Sphinx!"
    fi
done

and it outputs the following when I run it locally:

Yocto yocto-3.1.5 uses Sphinx!
Yocto yocto-3.1.6 uses Sphinx!
Yocto yocto-3.2 uses Sphinx!
Yocto yocto-3.2.1 uses Sphinx!
Yocto yocto-3.2.2 uses Sphinx!
Yocto yocto-3.2.3 uses Sphinx!



would be doing the same thing as the one command with grep above.
Discovered it recently so just wanted to share.

I guess this is something we can also do for bitbake Sphinx documentation?

yes.
 

Removed the git context inadvertently but, is =~ some bash built-in? I don't know what's the shebang on top but maybe we want to force it to bash since I'm not sure it's POSIX "compliant" anymore? 

It is bash already. 
 

Reviewed-by: Quentin Schulz <foss@...>

Thanks,
Quentin


Re: [PATCH yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list

Quentin Schulz
 

Hi Michael,

On April 6, 2021 10:58:20 PM UTC, Michael Halstead <mhalstead@linuxfoundation.org> wrote:
All new releases are Sphinx ready so we exclude old tags and build for
all the rest.

Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
---
scripts/run-docs-build | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 910f03d..13df34a 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -7,6 +7,7 @@ ypdocs=$2/documentation/
bbdocs=$3/doc/
docs_buildtools=/srv/autobuilder/autobuilder.yoctoproject.org/pub/buildtools/x86_64-buildtools-docs-nativesdk-standalone-3.2+snapshot-20201105.sh
outputdir=$builddir/output
+excluded_tags="yocto-3.1.4 yocto-3.1.3 yocto-3.1.2 yocto-3.1.1 yocto-3.1 yocto-3.0.1 yocto-3.0 yocto-2.6.4 yocto-2.6.3 yocto-2.7.1 yocto-2.6.2 yocto-2.7 yocto-2.6.1 yocto-2.6 yocto-2.5.2 yocto-2.5.1 yocto-2.4.4 yocto-2.4.3 yocto-2.5 yocto-2.3.4 yocto-1.0.2 yocto-1.1.2 yocto-1.2.2 yocto-1.2.1 yocto-1.3 yocto-1.3.1 yocto-1.3.2 yocto-1.4.3 yocto-1.4.2 yocto-1.4.1 yocto-1.4 yocto-2.1.3 yocto-2.4.2 yocto-2.1.1 yocto-2.1.2 yocto-2.0.3 yocto-1.8.2 yocto-2.2.3 yocto-2.4.1 yocto-2.3.3 yocto-2.3.2 yocto-2.4 yocto-2.2.2 yocto-2.3.1 yocto-2.3 yocto-2.2.1 yocto-2.0.2 yocto-2.2 yocto-2.1 yocto-2.0.1 yocto-2.0 yocto-1.8.1 yocto-1.7.3 yocto-1.6.3 yocto-1.7.2 yocto-1.8 yocto-1.5.1"


cd $builddir
@@ -77,13 +78,18 @@ for branch in dunfell gatesgarth hardknott; do
done

# Yocto Project releases/tags
-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do
+cd $ypdocs
+for tag in $(git tag -l |grep 'yocto-' |sort); do
IIUC the man page,
git tag --list 'yocto-*' | sort
would be doing the same thing as the one command with grep above.
Discovered it recently so just wanted to share.

I guess this is something we can also do for bitbake Sphinx documentation?

Removed the git context inadvertently but, is =~ some bash built-in? I don't know what's the shebang on top but maybe we want to force it to bash since I'm not sure it's POSIX "compliant" anymore?

Reviewed-by: Quentin Schulz <foss@0leil.net>

Thanks,
Quentin


[meta-security][PATCH 5/5] README: cleanup

Armin Kuster
 

Add note about rust.

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
README | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/README b/README
index f223fee..eb15366 100644
--- a/README
+++ b/README
@@ -11,28 +11,19 @@ This layer depends on:

URI: git://git.openembedded.org/openembedded-core
branch: master
- revision: HEAD
- prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-oe
branch: master
- revision: HEAD
- prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-perl
branch: master
- revision: HEAD
- prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-python
branch: master
- revision: HEAD
- prio: default

URI: git://git.openembedded.org/meta-openembedded/meta-networking
branch: master
- revision: HEAD
- prio: default
+

Adding the security layer to your build
========================================
@@ -51,11 +42,23 @@ other layers needed. e.g.:
/path/to/meta-openembedded/meta-perl \
/path/to/meta-openembedded/meta-python \
/path/to/meta-openembedded/meta-networking \
- /path/to/layer/meta-security \
+ /path/to/layer/meta-security "
+
+Optional Rust dependancy
+======================================
+If you want to use the latest Suricata that needs rust, you will need to clone
+
+ URI: https://github.com/meta-rust/meta-rust.git
+ branch: master
+
+ BBLAYERS += "/path/to/layer/meta-rust"
+
+This will activate the dynamic-layer mechanism and pull in the newer suricata
+


Maintenance
------------
+======================================

Send pull requests, patches, comments or questions to yocto@lists.yoctoproject.org

--
2.25.1


[meta-security][PATCH 3/5] suricata: update to 6.0.2

Armin Kuster
 

needs rust

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../recipes-ids/suricata/files/fixup.patch | 32 +
.../recipes-ids/suricata/files/run-ptest | 3 +
.../suricata/files/suricata.service | 20 +
.../recipes-ids/suricata/files/suricata.yaml | 1326 +++++++++++++++++
.../suricata/files/tmpfiles.suricata | 2 +
.../suricata/files/volatiles.03_suricata | 2 +
.../recipes-ids/suricata/libhtp_0.5.37.bb | 27 +
.../recipes-ids/suricata/suricata.inc | 8 +
.../recipes-ids/suricata/suricata_6.0.2.bb | 193 +++
9 files changed, 1613 insertions(+)
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/files/fixup.patch
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/files/run-ptest
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/files/suricata.service
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/files/suricata.yaml
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/files/tmpfiles.suricata
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/files/volatiles.03_suricata
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/libhtp_0.5.37.bb
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/suricata.inc
create mode 100644 dynamic-layers/meta-rust/recipes-ids/suricata/suricata_6.0.2.bb

diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/files/fixup.patch b/dynamic-layers/meta-rust/recipes-ids/suricata/files/fixup.patch
new file mode 100644
index 0000000..fc44ce6
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/files/fixup.patch
@@ -0,0 +1,32 @@
+Skip pkg Makefile from using its own rust steps
+
+Upstream-Status: OE Specific
+
+Signed-off-by: Armin Kuster <akuster808@gmail.com>
+
+Index: suricata-6.0.2/Makefile.am
+===================================================================
+--- suricata-6.0.2.orig/Makefile.am
++++ suricata-6.0.2/Makefile.am
+@@ -7,7 +7,7 @@ EXTRA_DIST = ChangeLog COPYING LICENSE s
+ $(SURICATA_UPDATE_DIR) \
+ lua \
+ acsite.m4
+-SUBDIRS = $(HTP_DIR) rust src qa rules doc contrib etc python ebpf \
++SUBDIRS = $(HTP_DIR) src qa rules doc contrib etc python ebpf \
+ $(SURICATA_UPDATE_DIR)
+
+ CLEANFILES = stamp-h[0-9]*
+Index: suricata-6.0.2/Makefile.in
+===================================================================
+--- suricata-6.0.2.orig/Makefile.in
++++ suricata-6.0.2/Makefile.in
+@@ -426,7 +426,7 @@ EXTRA_DIST = ChangeLog COPYING LICENSE s
+ lua \
+ acsite.m4
+
+-SUBDIRS = $(HTP_DIR) rust src qa rules doc contrib etc python ebpf \
++SUBDIRS = $(HTP_DIR) src qa rules doc contrib etc python ebpf \
+ $(SURICATA_UPDATE_DIR)
+
+ CLEANFILES = stamp-h[0-9]*
diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/files/run-ptest b/dynamic-layers/meta-rust/recipes-ids/suricata/files/run-ptest
new file mode 100644
index 0000000..666ba9c
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/files/run-ptest
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+suricata -u
diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/files/suricata.service b/dynamic-layers/meta-rust/recipes-ids/suricata/files/suricata.service
new file mode 100644
index 0000000..a99a76e
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/files/suricata.service
@@ -0,0 +1,20 @@
+[Unit]
+Description=Suricata IDS/IDP daemon
+After=network.target
+Requires=network.target
+Documentation=man:suricata(8) man:suricatasc(8)
+Documentation=https://redmine.openinfosecfoundation.org/projects/suricata/wiki
+
+[Service]
+Type=simple
+CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
+RestrictAddressFamilies=
+ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml eth0
+ExecReload=/bin/kill -HUP $MAINPID
+PrivateTmp=yes
+ProtectHome=yes
+ProtectSystem=yes
+
+[Install]
+WantedBy=multi-user.target
+
diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/files/suricata.yaml b/dynamic-layers/meta-rust/recipes-ids/suricata/files/suricata.yaml
new file mode 100644
index 0000000..8d06a27
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/files/suricata.yaml
@@ -0,0 +1,1326 @@
+%YAML 1.1
+---
+
+# Suricata configuration file. In addition to the comments describing all
+# options in this file, full documentation can be found at:
+# https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricatayaml
+
+
+# Number of packets allowed to be processed simultaneously. Default is a
+# conservative 1024. A higher number will make sure CPU's/CPU cores will be
+# more easily kept busy, but may negatively impact caching.
+#
+# If you are using the CUDA pattern matcher (mpm-algo: ac-cuda), different rules
+# apply. In that case try something like 60000 or more. This is because the CUDA
+# pattern matcher buffers and scans as many packets as possible in parallel.
+#max-pending-packets: 1024
+
+# Runmode the engine should use. Please check --list-runmodes to get the available
+# runmodes for each packet acquisition method. Defaults to "autofp" (auto flow pinned
+# load balancing).
+#runmode: autofp
+
+# Specifies the kind of flow load balancer used by the flow pinned autofp mode.
+#
+# Supported schedulers are:
+#
+# round-robin - Flows assigned to threads in a round robin fashion.
+# active-packets - Flows assigned to threads that have the lowest number of
+# unprocessed packets (default).
+# hash - Flow alloted usihng the address hash. More of a random
+# technique. Was the default in Suricata 1.2.1 and older.
+#
+#autofp-scheduler: active-packets
+
+# If suricata box is a router for the sniffed networks, set it to 'router'. If
+# it is a pure sniffing setup, set it to 'sniffer-only'.
+# If set to auto, the variable is internally switch to 'router' in IPS mode
+# and 'sniffer-only' in IDS mode.
+# This feature is currently only used by the reject* keywords.
+host-mode: auto
+
+# Run suricata as user and group.
+#run-as:
+# user: suri
+# group: suri
+
+# Default pid file.
+# Will use this file if no --pidfile in command options.
+#pid-file: /var/run/suricata.pid
+
+# Daemon working directory
+# Suricata will change directory to this one if provided
+# Default: "/"
+#daemon-directory: "/"
+
+# Preallocated size for packet. Default is 1514 which is the classical
+# size for pcap on ethernet. You should adjust this value to the highest
+# packet size (MTU + hardware header) on your system.
+#default-packet-size: 1514
+
+# The default logging directory. Any log or output file will be
+# placed here if its not specified with a full path name. This can be
+# overridden with the -l command line parameter.
+default-log-dir: /var/log/suricata/
+
+# Unix command socket can be used to pass commands to suricata.
+# An external tool can then connect to get information from suricata
+# or trigger some modifications of the engine. Set enabled to yes
+# to activate the feature. You can use the filename variable to set
+# the file name of the socket.
+unix-command:
+ enabled: no
+ #filename: custom.socket
+
+# Configure the type of alert (and other) logging you would like.
+outputs:
+
+ # a line based alerts log similar to Snort's fast.log
+ - fast:
+ enabled: yes
+ filename: fast.log
+ append: yes
+ #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
+
+ # Extensible Event Format (nicknamed EVE) event log in JSON format
+ - eve-log:
+ enabled: yes
+ type: file #file|syslog|unix_dgram|unix_stream
+ filename: eve.json
+ # the following are valid when type: syslog above
+ #identity: "suricata"
+ #facility: local5
+ #level: Info ## possible levels: Emergency, Alert, Critical,
+ ## Error, Warning, Notice, Info, Debug
+ types:
+ - alert
+ - http:
+ extended: yes # enable this for extended logging information
+ # custom allows additional http fields to be included in eve-log
+ # the example below adds three additional fields when uncommented
+ #custom: [Accept-Encoding, Accept-Language, Authorization]
+ - dns
+ - tls:
+ extended: yes # enable this for extended logging information
+ - files:
+ force-magic: no # force logging magic on all logged files
+ force-md5: no # force logging of md5 checksums
+ #- drop
+ - ssh
+
+ # alert output for use with Barnyard2
+ - unified2-alert:
+ enabled: yes
+ filename: unified2.alert
+
+ # File size limit. Can be specified in kb, mb, gb. Just a number
+ # is parsed as bytes.
+ #limit: 32mb
+
+ # Sensor ID field of unified2 alerts.
+ #sensor-id: 0
+
+ # HTTP X-Forwarded-For support by adding the unified2 extra header that
+ # will contain the actual client IP address or by overwriting the source
+ # IP address (helpful when inspecting traffic that is being reversed
+ # proxied).
+ xff:
+ enabled: no
+ # Two operation modes are available, "extra-data" and "overwrite". Note
+ # that in the "overwrite" mode, if the reported IP address in the HTTP
+ # X-Forwarded-For header is of a different version of the packet
+ # received, it will fall-back to "extra-data" mode.
+ mode: extra-data
+ # Header name were the actual IP address will be reported, if more than
+ # one IP address is present, the last IP address will be the one taken
+ # into consideration.
+ header: X-Forwarded-For
+
+ # a line based log of HTTP requests (no alerts)
+ - http-log:
+ enabled: yes
+ filename: http.log
+ append: yes
+ #extended: yes # enable this for extended logging information
+ #custom: yes # enabled the custom logging format (defined by customformat)
+ #customformat: "%{%D-%H:%M:%S}t.%z %{X-Forwarded-For}i %H %m %h %u %s %B %a:%p -> %A:%P"
+ #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
+
+ # a line based log of TLS handshake parameters (no alerts)
+ - tls-log:
+ enabled: no # Log TLS connections.
+ filename: tls.log # File to store TLS logs.
+ append: yes
+ #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
+ #extended: yes # Log extended information like fingerprint
+ certs-log-dir: certs # directory to store the certificates files
+
+ # a line based log of DNS requests and/or replies (no alerts)
+ - dns-log:
+ enabled: no
+ filename: dns.log
+ append: yes
+ #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
+
+ # a line based log to used with pcap file study.
+ # this module is dedicated to offline pcap parsing (empty output
+ # if used with another kind of input). It can interoperate with
+ # pcap parser like wireshark via the suriwire plugin.
+ - pcap-info:
+ enabled: no
+
+ # Packet log... log packets in pcap format. 2 modes of operation: "normal"
+ # and "sguil".
+ #
+ # In normal mode a pcap file "filename" is created in the default-log-dir,
+ # or are as specified by "dir". In Sguil mode "dir" indicates the base directory.
+ # In this base dir the pcaps are created in th directory structure Sguil expects:
+ #
+ # $sguil-base-dir/YYYY-MM-DD/$filename.<timestamp>
+ #
+ # By default all packets are logged except:
+ # - TCP streams beyond stream.reassembly.depth
+ # - encrypted streams after the key exchange
+ #
+ - pcap-log:
+ enabled: no
+ filename: log.pcap
+
+ # File size limit. Can be specified in kb, mb, gb. Just a number
+ # is parsed as bytes.
+ limit: 1000mb
+
+ # If set to a value will enable ring buffer mode. Will keep Maximum of "max-files" of size "limit"
+ max-files: 2000
+
+ mode: normal # normal or sguil.
+ #sguil-base-dir: /nsm_data/
+ #ts-format: usec # sec or usec second format (default) is filename.sec usec is filename.sec.usec
+ use-stream-depth: no #If set to "yes" packets seen after reaching stream inspection depth are ignored. "no" logs all packets
+
+ # a full alerts log containing much information for signature writers
+ # or for investigating suspected false positives.
+ - alert-debug:
+ enabled: no
+ filename: alert-debug.log
+ append: yes
+ #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
+
+ # alert output to prelude (http://www.prelude-technologies.com/) only
+ # available if Suricata has been compiled with --enable-prelude
+ - alert-prelude:
+ enabled: no
+ profile: suricata
+ log-packet-content: no
+ log-packet-header: yes
+
+ # Stats.log contains data from various counters of the suricata engine.
+ # The interval field (in seconds) tells after how long output will be written
+ # on the log file.
+ - stats:
+ enabled: yes
+ filename: stats.log
+ interval: 8
+
+ # a line based alerts log similar to fast.log into syslog
+ - syslog:
+ enabled: no
+ # reported identity to syslog. If ommited the program name (usually
+ # suricata) will be used.
+ #identity: "suricata"
+ facility: local5
+ #level: Info ## possible levels: Emergency, Alert, Critical,
+ ## Error, Warning, Notice, Info, Debug
+
+ # a line based information for dropped packets in IPS mode
+ - drop:
+ enabled: no
+ filename: drop.log
+ append: yes
+ #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
+
+ # output module to store extracted files to disk
+ #
+ # The files are stored to the log-dir in a format "file.<id>" where <id> is
+ # an incrementing number starting at 1. For each file "file.<id>" a meta
+ # file "file.<id>.meta" is created.
+ #
+ # File extraction depends on a lot of things to be fully done:
+ # - stream reassembly depth. For optimal results, set this to 0 (unlimited)
+ # - http request / response body sizes. Again set to 0 for optimal results.
+ # - rules that contain the "filestore" keyword.
+ - file-store:
+ enabled: no # set to yes to enable
+ log-dir: files # directory to store the files
+ force-magic: no # force logging magic on all stored files
+ force-md5: no # force logging of md5 checksums
+ #waldo: file.waldo # waldo file to store the file_id across runs
+
+ # output module to log files tracked in a easily parsable json format
+ - file-log:
+ enabled: no
+ filename: files-json.log
+ append: yes
+ #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
+
+ force-magic: no # force logging magic on all logged files
+ force-md5: no # force logging of md5 checksums
+
+# Magic file. The extension .mgc is added to the value here.
+#magic-file: /usr/share/file/magic
+magic-file: /usr/share/misc/magic.mgc
+
+# When running in NFQ inline mode, it is possible to use a simulated
+# non-terminal NFQUEUE verdict.
+# This permit to do send all needed packet to suricata via this a rule:
+# iptables -I FORWARD -m mark ! --mark $MARK/$MASK -j NFQUEUE
+# And below, you can have your standard filtering ruleset. To activate
+# this mode, you need to set mode to 'repeat'
+# If you want packet to be sent to another queue after an ACCEPT decision
+# set mode to 'route' and set next-queue value.
+# On linux >= 3.1, you can set batchcount to a value > 1 to improve performance
+# by processing several packets before sending a verdict (worker runmode only).
+# On linux >= 3.6, you can set the fail-open option to yes to have the kernel
+# accept the packet if suricata is not able to keep pace.
+nfq:
+# mode: accept
+# repeat-mark: 1
+# repeat-mask: 1
+# route-queue: 2
+# batchcount: 20
+# fail-open: yes
+
+#nflog support
+nflog:
+ # netlink multicast group
+ # (the same as the iptables --nflog-group param)
+ # Group 0 is used by the kernel, so you can't use it
+ - group: 2
+ # netlink buffer size
+ buffer-size: 18432
+ # put default value here
+ - group: default
+ # set number of packet to queue inside kernel
+ qthreshold: 1
+ # set the delay before flushing packet in the queue inside kernel
+ qtimeout: 100
+ # netlink max buffer size
+ max-size: 20000
+
+# af-packet support
+# Set threads to > 1 to use PACKET_FANOUT support
+af-packet:
+ - interface: eth0
+ # Number of receive threads (>1 will enable experimental flow pinned
+ # runmode)
+ threads: 1
+ # Default clusterid. AF_PACKET will load balance packets based on flow.
+ # All threads/processes that will participate need to have the same
+ # clusterid.
+ cluster-id: 99
+ # Default AF_PACKET cluster type. AF_PACKET can load balance per flow or per hash.
+ # This is only supported for Linux kernel > 3.1
+ # possible value are:
+ # * cluster_round_robin: round robin load balancing
+ # * cluster_flow: all packets of a given flow are send to the same socket
+ # * cluster_cpu: all packets treated in kernel by a CPU are send to the same socket
+ cluster-type: cluster_flow
+ # In some fragmentation case, the hash can not be computed. If "defrag" is set
+ # to yes, the kernel will do the needed defragmentation before sending the packets.
+ defrag: yes
+ # To use the ring feature of AF_PACKET, set 'use-mmap' to yes
+ use-mmap: yes
+ # Ring size will be computed with respect to max_pending_packets and number
+ # of threads. You can set manually the ring size in number of packets by setting
+ # the following value. If you are using flow cluster-type and have really network
+ # intensive single-flow you could want to set the ring-size independantly of the number
+ # of threads:
+ #ring-size: 2048
+ # On busy system, this could help to set it to yes to recover from a packet drop
+ # phase. This will result in some packets (at max a ring flush) being non treated.
+ #use-emergency-flush: yes
+ # recv buffer size, increase value could improve performance
+ # buffer-size: 32768
+ # Set to yes to disable promiscuous mode
+ # disable-promisc: no
+ # Choose checksum verification mode for the interface. At the moment
+ # of the capture, some packets may be with an invalid checksum due to
+ # offloading to the network card of the checksum computation.
+ # Possible values are:
+ # - kernel: use indication sent by kernel for each packet (default)
+ # - yes: checksum validation is forced
+ # - no: checksum validation is disabled
+ # - auto: suricata uses a statistical approach to detect when
+ # checksum off-loading is used.
+ # Warning: 'checksum-validation' must be set to yes to have any validation
+ #checksum-checks: kernel
+ # BPF filter to apply to this interface. The pcap filter syntax apply here.
+ #bpf-filter: port 80 or udp
+ # You can use the following variables to activate AF_PACKET tap od IPS mode.
+ # If copy-mode is set to ips or tap, the traffic coming to the current
+ # interface will be copied to the copy-iface interface. If 'tap' is set, the
+ # copy is complete. If 'ips' is set, the packet matching a 'drop' action
+ # will not be copied.
+ #copy-mode: ips
+ #copy-iface: eth1
+ - interface: eth1
+ threads: 1
+ cluster-id: 98
+ cluster-type: cluster_flow
+ defrag: yes
+ # buffer-size: 32768
+ # disable-promisc: no
+ # Put default values here
+ - interface: default
+ #threads: 2
+ #use-mmap: yes
+
+legacy:
+ uricontent: enabled
+
+# You can specify a threshold config file by setting "threshold-file"
+# to the path of the threshold config file:
+# threshold-file: /etc/suricata/threshold.config
+
+# The detection engine builds internal groups of signatures. The engine
+# allow us to specify the profile to use for them, to manage memory on an
+# efficient way keeping a good performance. For the profile keyword you
+# can use the words "low", "medium", "high" or "custom". If you use custom
+# make sure to define the values at "- custom-values" as your convenience.
+# Usually you would prefer medium/high/low.
+#
+# "sgh mpm-context", indicates how the staging should allot mpm contexts for
+# the signature groups. "single" indicates the use of a single context for
+# all the signature group heads. "full" indicates a mpm-context for each
+# group head. "auto" lets the engine decide the distribution of contexts
+# based on the information the engine gathers on the patterns from each
+# group head.
+#
+# The option inspection-recursion-limit is used to limit the recursive calls
+# in the content inspection code. For certain payload-sig combinations, we
+# might end up taking too much time in the content inspection code.
+# If the argument specified is 0, the engine uses an internally defined
+# default limit. On not specifying a value, we use no limits on the recursion.
+detect-engine:
+ - profile: medium
+ - custom-values:
+ toclient-src-groups: 2
+ toclient-dst-groups: 2
+ toclient-sp-groups: 2
+ toclient-dp-groups: 3
+ toserver-src-groups: 2
+ toserver-dst-groups: 4
+ toserver-sp-groups: 2
+ toserver-dp-groups: 25
+ - sgh-mpm-context: auto
+ - inspection-recursion-limit: 3000
+ # When rule-reload is enabled, sending a USR2 signal to the Suricata process
+ # will trigger a live rule reload. Experimental feature, use with care.
+ #- rule-reload: true
+ # If set to yes, the loading of signatures will be made after the capture
+ # is started. This will limit the downtime in IPS mode.
+ #- delayed-detect: yes
+
+# Suricata is multi-threaded. Here the threading can be influenced.
+threading:
+ # On some cpu's/architectures it is beneficial to tie individual threads
+ # to specific CPU's/CPU cores. In this case all threads are tied to CPU0,
+ # and each extra CPU/core has one "detect" thread.
+ #
+ # On Intel Core2 and Nehalem CPU's enabling this will degrade performance.
+ #
+ set-cpu-affinity: no
+ # Tune cpu affinity of suricata threads. Each family of threads can be bound
+ # on specific CPUs.
+ cpu-affinity:
+ - management-cpu-set:
+ cpu: [ 0 ] # include only these cpus in affinity settings
+ - receive-cpu-set:
+ cpu: [ 0 ] # include only these cpus in affinity settings
+ - decode-cpu-set:
+ cpu: [ 0, 1 ]
+ mode: "balanced"
+ - stream-cpu-set:
+ cpu: [ "0-1" ]
+ - detect-cpu-set:
+ cpu: [ "all" ]
+ mode: "exclusive" # run detect threads in these cpus
+ # Use explicitely 3 threads and don't compute number by using
+ # detect-thread-ratio variable:
+ # threads: 3
+ prio:
+ low: [ 0 ]
+ medium: [ "1-2" ]
+ high: [ 3 ]
+ default: "medium"
+ - verdict-cpu-set:
+ cpu: [ 0 ]
+ prio:
+ default: "high"
+ - reject-cpu-set:
+ cpu: [ 0 ]
+ prio:
+ default: "low"
+ - output-cpu-set:
+ cpu: [ "all" ]
+ prio:
+ default: "medium"
+ #
+ # By default Suricata creates one "detect" thread per available CPU/CPU core.
+ # This setting allows controlling this behaviour. A ratio setting of 2 will
+ # create 2 detect threads for each CPU/CPU core. So for a dual core CPU this
+ # will result in 4 detect threads. If values below 1 are used, less threads
+ # are created. So on a dual core CPU a setting of 0.5 results in 1 detect
+ # thread being created. Regardless of the setting at a minimum 1 detect
+ # thread will always be created.
+ #
+ detect-thread-ratio: 1.5
+
+# Cuda configuration.
+cuda:
+ # The "mpm" profile. On not specifying any of these parameters, the engine's
+ # internal default values are used, which are same as the ones specified in
+ # in the default conf file.
+ mpm:
+ # The minimum length required to buffer data to the gpu.
+ # Anything below this is MPM'ed on the CPU.
+ # Can be specified in kb, mb, gb. Just a number indicates it's in bytes.
+ # A value of 0 indicates there's no limit.
+ data-buffer-size-min-limit: 0
+ # The maximum length for data that we would buffer to the gpu.
+ # Anything over this is MPM'ed on the CPU.
+ # Can be specified in kb, mb, gb. Just a number indicates it's in bytes.
+ data-buffer-size-max-limit: 1500
+ # The ring buffer size used by the CudaBuffer API to buffer data.
+ cudabuffer-buffer-size: 500mb
+ # The max chunk size that can be sent to the gpu in a single go.
+ gpu-transfer-size: 50mb
+ # The timeout limit for batching of packets in microseconds.
+ batching-timeout: 2000
+ # The device to use for the mpm. Currently we don't support load balancing
+ # on multiple gpus. In case you have multiple devices on your system, you
+ # can specify the device to use, using this conf. By default we hold 0, to
+ # specify the first device cuda sees. To find out device-id associated with
+ # the card(s) on the system run "suricata --list-cuda-cards".
+ device-id: 0
+ # No of Cuda streams used for asynchronous processing. All values > 0 are valid.
+ # For this option you need a device with Compute Capability > 1.0.
+ cuda-streams: 2
+
+# Select the multi pattern algorithm you want to run for scan/search the
+# in the engine. The supported algorithms are b2g, b2gc, b2gm, b3g, wumanber,
+# ac and ac-gfbs.
+#
+# The mpm you choose also decides the distribution of mpm contexts for
+# signature groups, specified by the conf - "detect-engine.sgh-mpm-context".
+# Selecting "ac" as the mpm would require "detect-engine.sgh-mpm-context"
+# to be set to "single", because of ac's memory requirements, unless the
+# ruleset is small enough to fit in one's memory, in which case one can
+# use "full" with "ac". Rest of the mpms can be run in "full" mode.
+#
+# There is also a CUDA pattern matcher (only available if Suricata was
+# compiled with --enable-cuda: b2g_cuda. Make sure to update your
+# max-pending-packets setting above as well if you use b2g_cuda.
+
+mpm-algo: ac
+
+# The memory settings for hash size of these algorithms can vary from lowest
+# (2048) - low (4096) - medium (8192) - high (16384) - higher (32768) - max
+# (65536). The bloomfilter sizes of these algorithms can vary from low (512) -
+# medium (1024) - high (2048).
+#
+# For B2g/B3g algorithms, there is a support for two different scan/search
+# algorithms. For B2g the scan algorithms are B2gScan & B2gScanBNDMq, and
+# search algorithms are B2gSearch & B2gSearchBNDMq. For B3g scan algorithms
+# are B3gScan & B3gScanBNDMq, and search algorithms are B3gSearch &
+# B3gSearchBNDMq.
+#
+# For B2g the different scan/search algorithms and, hash and bloom
+# filter size settings. For B3g the different scan/search algorithms and, hash
+# and bloom filter size settings. For wumanber the hash and bloom filter size
+# settings.
+
+pattern-matcher:
+ - b2gc:
+ search-algo: B2gSearchBNDMq
+ hash-size: low
+ bf-size: medium
+ - b2gm:
+ search-algo: B2gSearchBNDMq
+ hash-size: low
+ bf-size: medium
+ - b2g:
+ search-algo: B2gSearchBNDMq
+ hash-size: low
+ bf-size: medium
+ - b3g:
+ search-algo: B3gSearchBNDMq
+ hash-size: low
+ bf-size: medium
+ - wumanber:
+ hash-size: low
+ bf-size: medium
+
+# Defrag settings:
+
+defrag:
+ memcap: 32mb
+ hash-size: 65536
+ trackers: 65535 # number of defragmented flows to follow
+ max-frags: 65535 # number of fragments to keep (higher than trackers)
+ prealloc: yes
+ timeout: 60
+
+# Enable defrag per host settings
+# host-config:
+#
+# - dmz:
+# timeout: 30
+# address: [192.168.1.0/24, 127.0.0.0/8, 1.1.1.0/24, 2.2.2.0/24, "1.1.1.1", "2.2.2.2", "::1"]
+#
+# - lan:
+# timeout: 45
+# address:
+# - 192.168.0.0/24
+# - 192.168.10.0/24
+# - 172.16.14.0/24
+
+# Flow settings:
+# By default, the reserved memory (memcap) for flows is 32MB. This is the limit
+# for flow allocation inside the engine. You can change this value to allow
+# more memory usage for flows.
+# The hash-size determine the size of the hash used to identify flows inside
+# the engine, and by default the value is 65536.
+# At the startup, the engine can preallocate a number of flows, to get a better
+# performance. The number of flows preallocated is 10000 by default.
+# emergency-recovery is the percentage of flows that the engine need to
+# prune before unsetting the emergency state. The emergency state is activated
+# when the memcap limit is reached, allowing to create new flows, but
+# prunning them with the emergency timeouts (they are defined below).
+# If the memcap is reached, the engine will try to prune flows
+# with the default timeouts. If it doens't find a flow to prune, it will set
+# the emergency bit and it will try again with more agressive timeouts.
+# If that doesn't work, then it will try to kill the last time seen flows
+# not in use.
+# The memcap can be specified in kb, mb, gb. Just a number indicates it's
+# in bytes.
+
+flow:
+ memcap: 64mb
+ hash-size: 65536
+ prealloc: 10000
+ emergency-recovery: 30
+
+# This option controls the use of vlan ids in the flow (and defrag)
+# hashing. Normally this should be enabled, but in some (broken)
+# setups where both sides of a flow are not tagged with the same vlan
+# tag, we can ignore the vlan id's in the flow hashing.
+vlan:
+ use-for-tracking: true
+
+# Specific timeouts for flows. Here you can specify the timeouts that the
+# active flows will wait to transit from the current state to another, on each
+# protocol. The value of "new" determine the seconds to wait after a hanshake or
+# stream startup before the engine free the data of that flow it doesn't
+# change the state to established (usually if we don't receive more packets
+# of that flow). The value of "established" is the amount of
+# seconds that the engine will wait to free the flow if it spend that amount
+# without receiving new packets or closing the connection. "closed" is the
+# amount of time to wait after a flow is closed (usually zero).
+#
+# There's an emergency mode that will become active under attack circumstances,
+# making the engine to check flow status faster. This configuration variables
+# use the prefix "emergency-" and work similar as the normal ones.
+# Some timeouts doesn't apply to all the protocols, like "closed", for udp and
+# icmp.
+
+flow-timeouts:
+
+ default:
+ new: 30
+ established: 300
+ closed: 0
+ emergency-new: 10
+ emergency-established: 100
+ emergency-closed: 0
+ tcp:
+ new: 60
+ established: 3600
+ closed: 120
+ emergency-new: 10
+ emergency-established: 300
+ emergency-closed: 20
+ udp:
+ new: 30
+ established: 300
+ emergency-new: 10
+ emergency-established: 100
+ icmp:
+ new: 30
+ established: 300
+ emergency-new: 10
+ emergency-established: 100
+
+# Stream engine settings. Here the TCP stream tracking and reassembly
+# engine is configured.
+#
+# stream:
+# memcap: 32mb # Can be specified in kb, mb, gb. Just a
+# # number indicates it's in bytes.
+# checksum-validation: yes # To validate the checksum of received
+# # packet. If csum validation is specified as
+# # "yes", then packet with invalid csum will not
+# # be processed by the engine stream/app layer.
+# # Warning: locally generated trafic can be
+# # generated without checksum due to hardware offload
+# # of checksum. You can control the handling of checksum
+# # on a per-interface basis via the 'checksum-checks'
+# # option
+# prealloc-sessions: 2k # 2k sessions prealloc'd per stream thread
+# midstream: false # don't allow midstream session pickups
+# async-oneside: false # don't enable async stream handling
+# inline: no # stream inline mode
+# max-synack-queued: 5 # Max different SYN/ACKs to queue
+#
+# reassembly:
+# memcap: 64mb # Can be specified in kb, mb, gb. Just a number
+# # indicates it's in bytes.
+# depth: 1mb # Can be specified in kb, mb, gb. Just a number
+# # indicates it's in bytes.
+# toserver-chunk-size: 2560 # inspect raw stream in chunks of at least
+# # this size. Can be specified in kb, mb,
+# # gb. Just a number indicates it's in bytes.
+# # The max acceptable size is 4024 bytes.
+# toclient-chunk-size: 2560 # inspect raw stream in chunks of at least
+# # this size. Can be specified in kb, mb,
+# # gb. Just a number indicates it's in bytes.
+# # The max acceptable size is 4024 bytes.
+# randomize-chunk-size: yes # Take a random value for chunk size around the specified value.
+# # This lower the risk of some evasion technics but could lead
+# # detection change between runs. It is set to 'yes' by default.
+# randomize-chunk-range: 10 # If randomize-chunk-size is active, the value of chunk-size is
+# # a random value between (1 - randomize-chunk-range/100)*randomize-chunk-size
+# # and (1 + randomize-chunk-range/100)*randomize-chunk-size. Default value
+# # of randomize-chunk-range is 10.
+#
+# raw: yes # 'Raw' reassembly enabled or disabled.
+# # raw is for content inspection by detection
+# # engine.
+#
+# chunk-prealloc: 250 # Number of preallocated stream chunks. These
+# # are used during stream inspection (raw).
+# segments: # Settings for reassembly segment pool.
+# - size: 4 # Size of the (data)segment for a pool
+# prealloc: 256 # Number of segments to prealloc and keep
+# # in the pool.
+#
+stream:
+ memcap: 32mb
+ checksum-validation: yes # reject wrong csums
+ inline: auto # auto will use inline mode in IPS mode, yes or no set it statically
+ reassembly:
+ memcap: 128mb
+ depth: 1mb # reassemble 1mb into a stream
+ toserver-chunk-size: 2560
+ toclient-chunk-size: 2560
+ randomize-chunk-size: yes
+ #randomize-chunk-range: 10
+ #raw: yes
+ #chunk-prealloc: 250
+ #segments:
+ # - size: 4
+ # prealloc: 256
+ # - size: 16
+ # prealloc: 512
+ # - size: 112
+ # prealloc: 512
+ # - size: 248
+ # prealloc: 512
+ # - size: 512
+ # prealloc: 512
+ # - size: 768
+ # prealloc: 1024
+ # - size: 1448
+ # prealloc: 1024
+ # - size: 65535
+ # prealloc: 128
+
+# Host table:
+#
+# Host table is used by tagging and per host thresholding subsystems.
+#
+host:
+ hash-size: 4096
+ prealloc: 1000
+ memcap: 16777216
+
+# Logging configuration. This is not about logging IDS alerts, but
+# IDS output about what its doing, errors, etc.
+logging:
+
+ # The default log level, can be overridden in an output section.
+ # Note that debug level logging will only be emitted if Suricata was
+ # compiled with the --enable-debug configure option.
+ #
+ # This value is overriden by the SC_LOG_LEVEL env var.
+ default-log-level: notice
+
+ # The default output format. Optional parameter, should default to
+ # something reasonable if not provided. Can be overriden in an
+ # output section. You can leave this out to get the default.
+ #
+ # This value is overriden by the SC_LOG_FORMAT env var.
+ #default-log-format: "[%i] %t - (%f:%l) <%d> (%n) -- "
+
+ # A regex to filter output. Can be overridden in an output section.
+ # Defaults to empty (no filter).
+ #
+ # This value is overriden by the SC_LOG_OP_FILTER env var.
+ default-output-filter:
+
+ # Define your logging outputs. If none are defined, or they are all
+ # disabled you will get the default - console output.
+ outputs:
+ - console:
+ enabled: yes
+ - file:
+ enabled: no
+ filename: /var/log/suricata.log
+ - syslog:
+ enabled: yes
+ facility: local5
+ format: "[%i] <%d> -- "
+
+# Tilera mpipe configuration. for use on Tilera TILE-Gx.
+mpipe:
+
+ # Load balancing modes: "static", "dynamic", "sticky", or "round-robin".
+ load-balance: dynamic
+
+ # Number of Packets in each ingress packet queue. Must be 128, 512, 2028 or 65536
+ iqueue-packets: 2048
+
+ # List of interfaces we will listen on.
+ inputs:
+ - interface: xgbe2
+ - interface: xgbe3
+ - interface: xgbe4
+
+
+ # Relative weight of memory for packets of each mPipe buffer size.
+ stack:
+ size128: 0
+ size256: 9
+ size512: 0
+ size1024: 0
+ size1664: 7
+ size4096: 0
+ size10386: 0
+ size16384: 0
+
+# PF_RING configuration. for use with native PF_RING support
+# for more info see http://www.ntop.org/PF_RING.html
+pfring:
+ - interface: eth0
+ # Number of receive threads (>1 will enable experimental flow pinned
+ # runmode)
+ threads: 1
+
+ # Default clusterid. PF_RING will load balance packets based on flow.
+ # All threads/processes that will participate need to have the same
+ # clusterid.
+ cluster-id: 99
+
+ # Default PF_RING cluster type. PF_RING can load balance per flow or per hash.
+ # This is only supported in versions of PF_RING > 4.1.1.
+ cluster-type: cluster_flow
+ # bpf filter for this interface
+ #bpf-filter: tcp
+ # Choose checksum verification mode for the interface. At the moment
+ # of the capture, some packets may be with an invalid checksum due to
+ # offloading to the network card of the checksum computation.
+ # Possible values are:
+ # - rxonly: only compute checksum for packets received by network card.
+ # - yes: checksum validation is forced
+ # - no: checksum validation is disabled
+ # - auto: suricata uses a statistical approach to detect when
+ # checksum off-loading is used. (default)
+ # Warning: 'checksum-validation' must be set to yes to have any validation
+ #checksum-checks: auto
+ # Second interface
+ #- interface: eth1
+ # threads: 3
+ # cluster-id: 93
+ # cluster-type: cluster_flow
+ # Put default values here
+ - interface: default
+ #threads: 2
+
+pcap:
+ - interface: eth0
+ # On Linux, pcap will try to use mmaped capture and will use buffer-size
+ # as total of memory used by the ring. So set this to something bigger
+ # than 1% of your bandwidth.
+ #buffer-size: 16777216
+ #bpf-filter: "tcp and port 25"
+ # Choose checksum verification mode for the interface. At the moment
+ # of the capture, some packets may be with an invalid checksum due to
+ # offloading to the network card of the checksum computation.
+ # Possible values are:
+ # - yes: checksum validation is forced
+ # - no: checksum validation is disabled
+ # - auto: suricata uses a statistical approach to detect when
+ # checksum off-loading is used. (default)
+ # Warning: 'checksum-validation' must be set to yes to have any validation
+ #checksum-checks: auto
+ # With some accelerator cards using a modified libpcap (like myricom), you
+ # may want to have the same number of capture threads as the number of capture
+ # rings. In this case, set up the threads variable to N to start N threads
+ # listening on the same interface.
+ #threads: 16
+ # set to no to disable promiscuous mode:
+ #promisc: no
+ # set snaplen, if not set it defaults to MTU if MTU can be known
+ # via ioctl call and to full capture if not.
+ #snaplen: 1518
+ # Put default values here
+ - interface: default
+ #checksum-checks: auto
+
+pcap-file:
+ # Possible values are:
+ # - yes: checksum validation is forced
+ # - no: checksum validation is disabled
+ # - auto: suricata uses a statistical approach to detect when
+ # checksum off-loading is used. (default)
+ # Warning: 'checksum-validation' must be set to yes to have checksum tested
+ checksum-checks: auto
+
+# For FreeBSD ipfw(8) divert(4) support.
+# Please make sure you have ipfw_load="YES" and ipdivert_load="YES"
+# in /etc/loader.conf or kldload'ing the appropriate kernel modules.
+# Additionally, you need to have an ipfw rule for the engine to see
+# the packets from ipfw. For Example:
+#
+# ipfw add 100 divert 8000 ip from any to any
+#
+# The 8000 above should be the same number you passed on the command
+# line, i.e. -d 8000
+#
+ipfw:
+
+ # Reinject packets at the specified ipfw rule number. This config
+ # option is the ipfw rule number AT WHICH rule processing continues
+ # in the ipfw processing system after the engine has finished
+ # inspecting the packet for acceptance. If no rule number is specified,
+ # accepted packets are reinjected at the divert rule which they entered
+ # and IPFW rule processing continues. No check is done to verify
+ # this will rule makes sense so care must be taken to avoid loops in ipfw.
+ #
+ ## The following example tells the engine to reinject packets
+ # back into the ipfw firewall AT rule number 5500:
+ #
+ # ipfw-reinjection-rule-number: 5500
+
+# Set the default rule path here to search for the files.
+# if not set, it will look at the current working dir
+default-rule-path: /etc/suricata/rules
+rule-files:
+ - botcc.rules
+ - ciarmy.rules
+ - compromised.rules
+ - drop.rules
+ - dshield.rules
+ - emerging-activex.rules
+ - emerging-attack_response.rules
+ - emerging-chat.rules
+ - emerging-current_events.rules
+ - emerging-dns.rules
+ - emerging-dos.rules
+ - emerging-exploit.rules
+ - emerging-ftp.rules
+ - emerging-games.rules
+ - emerging-icmp_info.rules
+# - emerging-icmp.rules
+ - emerging-imap.rules
+ - emerging-inappropriate.rules
+ - emerging-malware.rules
+ - emerging-misc.rules
+ - emerging-mobile_malware.rules
+ - emerging-netbios.rules
+ - emerging-p2p.rules
+ - emerging-policy.rules
+ - emerging-pop3.rules
+ - emerging-rpc.rules
+ - emerging-scada.rules
+ - emerging-scan.rules
+ - emerging-shellcode.rules
+ - emerging-smtp.rules
+ - emerging-snmp.rules
+ - emerging-sql.rules
+ - emerging-telnet.rules
+ - emerging-tftp.rules
+ - emerging-trojan.rules
+ - emerging-user_agents.rules
+ - emerging-voip.rules
+ - emerging-web_client.rules
+ - emerging-web_server.rules
+ - emerging-web_specific_apps.rules
+ - emerging-worm.rules
+ - tor.rules
+ - decoder-events.rules # available in suricata sources under rules dir
+ - stream-events.rules # available in suricata sources under rules dir
+ - http-events.rules # available in suricata sources under rules dir
+ - smtp-events.rules # available in suricata sources under rules dir
+ - dns-events.rules # available in suricata sources under rules dir
+ - tls-events.rules # available in suricata sources under rules dir
+
+classification-file: /etc/suricata/classification.config
+reference-config-file: /etc/suricata/reference.config
+
+# Holds variables that would be used by the engine.
+vars:
+
+ # Holds the address group vars that would be passed in a Signature.
+ # These would be retrieved during the Signature address parsing stage.
+ address-groups:
+
+ HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
+
+ EXTERNAL_NET: "!$HOME_NET"
+
+ HTTP_SERVERS: "$HOME_NET"
+
+ SMTP_SERVERS: "$HOME_NET"
+
+ SQL_SERVERS: "$HOME_NET"
+
+ DNS_SERVERS: "$HOME_NET"
+
+ TELNET_SERVERS: "$HOME_NET"
+
+ AIM_SERVERS: "$EXTERNAL_NET"
+
+ DNP3_SERVER: "$HOME_NET"
+
+ DNP3_CLIENT: "$HOME_NET"
+
+ MODBUS_CLIENT: "$HOME_NET"
+
+ MODBUS_SERVER: "$HOME_NET"
+
+ ENIP_CLIENT: "$HOME_NET"
+
+ ENIP_SERVER: "$HOME_NET"
+
+ # Holds the port group vars that would be passed in a Signature.
+ # These would be retrieved during the Signature port parsing stage.
+ port-groups:
+
+ HTTP_PORTS: "80"
+
+ SHELLCODE_PORTS: "!80"
+
+ ORACLE_PORTS: 1521
+
+ SSH_PORTS: 22
+
+ DNP3_PORTS: 20000
+
+# Set the order of alerts bassed on actions
+# The default order is pass, drop, reject, alert
+action-order:
+ - pass
+ - drop
+ - reject
+ - alert
+
+# IP Reputation
+#reputation-categories-file: /etc/suricata/iprep/categories.txt
+#default-reputation-path: /etc/suricata/iprep
+#reputation-files:
+# - reputation.list
+
+# Host specific policies for defragmentation and TCP stream
+# reassembly. The host OS lookup is done using a radix tree, just
+# like a routing table so the most specific entry matches.
+host-os-policy:
+ # Make the default policy windows.
+ windows: [0.0.0.0/0]
+ bsd: []
+ bsd-right: []
+ old-linux: []
+ linux: [10.0.0.0/8, 192.168.1.100, "8762:2352:6241:7245:E000:0000:0000:0000"]
+ old-solaris: []
+ solaris: ["::1"]
+ hpux10: []
+ hpux11: []
+ irix: []
+ macos: []
+ vista: []
+ windows2k3: []
+
+
+# Limit for the maximum number of asn1 frames to decode (default 256)
+asn1-max-frames: 256
+
+# When run with the option --engine-analysis, the engine will read each of
+# the parameters below, and print reports for each of the enabled sections
+# and exit. The reports are printed to a file in the default log dir
+# given by the parameter "default-log-dir", with engine reporting
+# subsection below printing reports in its own report file.
+engine-analysis:
+ # enables printing reports for fast-pattern for every rule.
+ rules-fast-pattern: yes
+ # enables printing reports for each rule
+ rules: yes
+
+#recursion and match limits for PCRE where supported
+pcre:
+ match-limit: 3500
+ match-limit-recursion: 1500
+
+# Holds details on the app-layer. The protocols section details each protocol.
+# Under each protocol, the default value for detection-enabled and "
+# parsed-enabled is yes, unless specified otherwise.
+# Each protocol covers enabling/disabling parsers for all ipprotos
+# the app-layer protocol runs on. For example "dcerpc" refers to the tcp
+# version of the protocol as well as the udp version of the protocol.
+# The option "enabled" takes 3 values - "yes", "no", "detection-only".
+# "yes" enables both detection and the parser, "no" disables both, and
+# "detection-only" enables detection only(parser disabled).
+app-layer:
+ protocols:
+ tls:
+ enabled: yes
+ detection-ports:
+ dp: 443
+
+ #no-reassemble: yes
+ dcerpc:
+ enabled: yes
+ ftp:
+ enabled: yes
+ ssh:
+ enabled: yes
+ smtp:
+ enabled: yes
+ imap:
+ enabled: detection-only
+ msn:
+ enabled: detection-only
+ smb:
+ enabled: yes
+ detection-ports:
+ dp: 139
+ # smb2 detection is disabled internally inside the engine.
+ #smb2:
+ # enabled: yes
+ dns:
+ # memcaps. Globally and per flow/state.
+ #global-memcap: 16mb
+ #state-memcap: 512kb
+
+ # How many unreplied DNS requests are considered a flood.
+ # If the limit is reached, app-layer-event:dns.flooded; will match.
+ #request-flood: 500
+
+ tcp:
+ enabled: yes
+ detection-ports:
+ dp: 53
+ udp:
+ enabled: yes
+ detection-ports:
+ dp: 53
+ http:
+ enabled: yes
+ # memcap: 64mb
+
+ ###########################################################################
+ # Configure libhtp.
+ #
+ #
+ # default-config: Used when no server-config matches
+ # personality: List of personalities used by default
+ # request-body-limit: Limit reassembly of request body for inspection
+ # by http_client_body & pcre /P option.
+ # response-body-limit: Limit reassembly of response body for inspection
+ # by file_data, http_server_body & pcre /Q option.
+ # double-decode-path: Double decode path section of the URI
+ # double-decode-query: Double decode query section of the URI
+ #
+ # server-config: List of server configurations to use if address matches
+ # address: List of ip addresses or networks for this block
+ # personalitiy: List of personalities used by this block
+ # request-body-limit: Limit reassembly of request body for inspection
+ # by http_client_body & pcre /P option.
+ # response-body-limit: Limit reassembly of response body for inspection
+ # by file_data, http_server_body & pcre /Q option.
+ # double-decode-path: Double decode path section of the URI
+ # double-decode-query: Double decode query section of the URI
+ #
+ # uri-include-all: Include all parts of the URI. By default the
+ # 'scheme', username/password, hostname and port
+ # are excluded. Setting this option to true adds
+ # all of them to the normalized uri as inspected
+ # by http_uri, urilen, pcre with /U and the other
+ # keywords that inspect the normalized uri.
+ # Note that this does not affect http_raw_uri.
+ # Also, note that including all was the default in
+ # 1.4 and 2.0beta1.
+ #
+ # meta-field-limit: Hard size limit for request and response size
+ # limits. Applies to request line and headers,
+ # response line and headers. Does not apply to
+ # request or response bodies. Default is 18k.
+ # If this limit is reached an event is raised.
+ #
+ # Currently Available Personalities:
+ # Minimal
+ # Generic
+ # IDS (default)
+ # IIS_4_0
+ # IIS_5_0
+ # IIS_5_1
+ # IIS_6_0
+ # IIS_7_0
+ # IIS_7_5
+ # Apache_2
+ ###########################################################################
+ libhtp:
+
+ default-config:
+ personality: IDS
+
+ # Can be specified in kb, mb, gb. Just a number indicates
+ # it's in bytes.
+ request-body-limit: 3072
+ response-body-limit: 3072
+
+ # inspection limits
+ request-body-minimal-inspect-size: 32kb
+ request-body-inspect-window: 4kb
+ response-body-minimal-inspect-size: 32kb
+ response-body-inspect-window: 4kb
+ # Take a random value for inspection sizes around the specified value.
+ # This lower the risk of some evasion technics but could lead
+ # detection change between runs. It is set to 'yes' by default.
+ #randomize-inspection-sizes: yes
+ # If randomize-inspection-sizes is active, the value of various
+ # inspection size will be choosen in the [1 - range%, 1 + range%]
+ # range
+ # Default value of randomize-inspection-range is 10.
+ #randomize-inspection-range: 10
+
+ # decoding
+ double-decode-path: no
+ double-decode-query: no
+
+ server-config:
+
+ #- apache:
+ # address: [192.168.1.0/24, 127.0.0.0/8, "::1"]
+ # personality: Apache_2
+ # # Can be specified in kb, mb, gb. Just a number indicates
+ # # it's in bytes.
+ # request-body-limit: 4096
+ # response-body-limit: 4096
+ # double-decode-path: no
+ # double-decode-query: no
+
+ #- iis7:
+ # address:
+ # - 192.168.0.0/24
+ # - 192.168.10.0/24
+ # personality: IIS_7_0
+ # # Can be specified in kb, mb, gb. Just a number indicates
+ # # it's in bytes.
+ # request-body-limit: 4096
+ # response-body-limit: 4096
+ # double-decode-path: no
+ # double-decode-query: no
+
+# Profiling settings. Only effective if Suricata has been built with the
+# the --enable-profiling configure flag.
+#
+profiling:
+ # Run profiling for every xth packet. The default is 1, which means we
+ # profile every packet. If set to 1000, one packet is profiled for every
+ # 1000 received.
+ #sample-rate: 1000
+
+ # rule profiling
+ rules:
+
+ # Profiling can be disabled here, but it will still have a
+ # performance impact if compiled in.
+ enabled: yes
+ filename: rule_perf.log
+ append: yes
+
+ # Sort options: ticks, avgticks, checks, matches, maxticks
+ sort: avgticks
+
+ # Limit the number of items printed at exit.
+ limit: 100
+
+ # per keyword profiling
+ keywords:
+ enabled: yes
+ filename: keyword_perf.log
+ append: yes
+
+ # packet profiling
+ packets:
+
+ # Profiling can be disabled here, but it will still have a
+ # performance impact if compiled in.
+ enabled: yes
+ filename: packet_stats.log
+ append: yes
+
+ # per packet csv output
+ csv:
+
+ # Output can be disabled here, but it will still have a
+ # performance impact if compiled in.
+ enabled: no
+ filename: packet_stats.csv
+
+ # profiling of locking. Only available when Suricata was built with
+ # --enable-profiling-locks.
+ locks:
+ enabled: no
+ filename: lock_stats.log
+ append: yes
+
+# Suricata core dump configuration. Limits the size of the core dump file to
+# approximately max-dump. The actual core dump size will be a multiple of the
+# page size. Core dumps that would be larger than max-dump are truncated. On
+# Linux, the actual core dump size may be a few pages larger than max-dump.
+# Setting max-dump to 0 disables core dumping.
+# Setting max-dump to 'unlimited' will give the full core dump file.
+# On 32-bit Linux, a max-dump value >= ULONG_MAX may cause the core dump size
+# to be 'unlimited'.
+
+coredump:
+ max-dump: unlimited
+
+napatech:
+ # The Host Buffer Allowance for all streams
+ # (-1 = OFF, 1 - 100 = percentage of the host buffer that can be held back)
+ hba: -1
+
+ # use_all_streams set to "yes" will query the Napatech service for all configured
+ # streams and listen on all of them. When set to "no" the streams config array
+ # will be used.
+ use-all-streams: yes
+
+ # The streams to listen on
+ streams: [1, 2, 3]
+
+# Includes. Files included here will be handled as if they were
+# inlined in this configuration file.
+#include: include1.yaml
+#include: include2.yaml
diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/files/tmpfiles.suricata b/dynamic-layers/meta-rust/recipes-ids/suricata/files/tmpfiles.suricata
new file mode 100644
index 0000000..fbf3784
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/files/tmpfiles.suricata
@@ -0,0 +1,2 @@
+#Type Path Mode UID GID Age Argument
+d /var/log/suricata 0755 root root
diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/files/volatiles.03_suricata b/dynamic-layers/meta-rust/recipes-ids/suricata/files/volatiles.03_suricata
new file mode 100644
index 0000000..4627bd3
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/files/volatiles.03_suricata
@@ -0,0 +1,2 @@
+# <type> <owner> <group> <mode> <path> <linksource>
+d root root 0755 /var/log/suricata none
diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/libhtp_0.5.37.bb b/dynamic-layers/meta-rust/recipes-ids/suricata/libhtp_0.5.37.bb
new file mode 100644
index 0000000..34e72e9
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/libhtp_0.5.37.bb
@@ -0,0 +1,27 @@
+SUMMARY = "LibHTP is a security-aware parser for the HTTP protocol and the related bits and pieces."
+
+require suricata.inc
+
+LIC_FILES_CHKSUM = "file://LICENSE;beginline=1;endline=2;md5=596ab7963a1a0e5198e5a1c4aa621843"
+
+SRC_URI = "git://github.com/OISF/libhtp.git;protocol=https;branch=0.5.x"
+SRCREV = "eaa2db29e65e7f2691c18a9022aeb5fb836ec5f1"
+
+DEPENDS = "zlib"
+
+inherit autotools-brokensep pkgconfig
+
+CFLAGS += "-D_DEFAULT_SOURCE"
+
+#S = "${WORKDIR}/suricata-${VER}/${BPN}"
+
+S = "${WORKDIR}/git"
+
+do_configure () {
+ cd ${S}
+ ./autogen.sh
+ oe_runconf
+}
+
+RDEPENDS_${PN} += "zlib"
+
diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/suricata.inc b/dynamic-layers/meta-rust/recipes-ids/suricata/suricata.inc
new file mode 100644
index 0000000..85f419e
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/suricata.inc
@@ -0,0 +1,8 @@
+HOMEPAGE = "http://suricata-ids.org/"
+SECTION = "security Monitor/Admin"
+LICENSE = "GPLv2"
+
+VER = "6.0.2"
+SRC_URI = "http://www.openinfosecfoundation.org/download/suricata-${VER}.tar.gz"
+
+SRC_URI[sha256sum] = "5e4647a07cb31b5d6d0049972a45375c137de908a964a44e2d6d231fa3ad4b52"
diff --git a/dynamic-layers/meta-rust/recipes-ids/suricata/suricata_6.0.2.bb b/dynamic-layers/meta-rust/recipes-ids/suricata/suricata_6.0.2.bb
new file mode 100644
index 0000000..a4255d2
--- /dev/null
+++ b/dynamic-layers/meta-rust/recipes-ids/suricata/suricata_6.0.2.bb
@@ -0,0 +1,193 @@
+SUMMARY = "The Suricata Engine is an Open Source Next Generation Intrusion Detection and Prevention Engine"
+
+require suricata.inc
+
+DEPENDS = "lz4 libhtp"
+
+LIC_FILES_CHKSUM = "file://LICENSE;beginline=1;endline=2;md5=c70d8d3310941dcdfcd1e02800a1f548"
+
+SRC_URI += " \
+ file://volatiles.03_suricata \
+ file://tmpfiles.suricata \
+ file://suricata.yaml \
+ file://suricata.service \
+ file://run-ptest \
+ file://fixup.patch \
+ "
+
+SRC_URI += " \
+ crate://crates.io/autocfg/1.0.1 \
+ crate://crates.io/semver-parser/0.7.0 \
+ crate://crates.io/arrayvec/0.4.12 \
+ crate://crates.io/ryu/1.0.5 \
+ crate://crates.io/libc/0.2.86 \
+ crate://crates.io/bitflags/1.2.1 \
+ crate://crates.io/version_check/0.9.2 \
+ crate://crates.io/memchr/2.3.4 \
+ crate://crates.io/nodrop/0.1.14 \
+ crate://crates.io/cfg-if/0.1.9 \
+ crate://crates.io/static_assertions/0.3.4 \
+ crate://crates.io/getrandom/0.1.16 \
+ crate://crates.io/cfg-if/1.0.0 \
+ crate://crates.io/siphasher/0.3.3 \
+ crate://crates.io/ppv-lite86/0.2.10 \
+ crate://crates.io/proc-macro-hack/0.5.19 \
+ crate://crates.io/proc-macro2/0.4.30 \
+ crate://crates.io/unicode-xid/0.1.0 \
+ crate://crates.io/syn/0.15.44 \
+ crate://crates.io/build_const/0.2.1 \
+ crate://crates.io/num-derive/0.2.5 \
+ crate://crates.io/base64/0.11.0 \
+ crate://crates.io/widestring/0.4.3 \
+ crate://crates.io/md5/0.7.0 \
+ crate://crates.io/uuid/0.8.2 \
+ crate://crates.io/byteorder/1.4.2 \
+ crate://crates.io/semver/0.9.0 \
+ crate://crates.io/nom/5.1.1 \
+ crate://crates.io/num-traits/0.2.14 \
+ crate://crates.io/num-integer/0.1.44 \
+ crate://crates.io/num-bigint/0.2.6 \
+ crate://crates.io/num-bigint/0.3.1 \
+ crate://crates.io/num-rational/0.2.4 \
+ crate://crates.io/num-complex/0.2.4 \
+ crate://crates.io/num-iter/0.1.42 \
+ crate://crates.io/phf_shared/0.8.0 \
+ crate://crates.io/crc/1.8.1 \
+ crate://crates.io/rustc_version/0.2.3 \
+ crate://crates.io/phf/0.8.0 \
+ crate://crates.io/lexical-core/0.6.7 \
+ crate://crates.io/time/0.1.44 \
+ crate://crates.io/quote/0.6.13 \
+ crate://crates.io/rand_core/0.5.1 \
+ crate://crates.io/rand_chacha/0.2.2 \
+ crate://crates.io/rand_pcg/0.2.1 \
+ crate://crates.io/num-traits/0.1.43 \
+ crate://crates.io/rand/0.7.3 \
+ crate://crates.io/enum_primitive/0.1.1 \
+ crate://crates.io/phf_generator/0.8.0 \
+ crate://crates.io/phf_codegen/0.8.0 \
+ crate://crates.io/tls-parser/0.9.4 \
+ crate://crates.io/num/0.2.1 \
+ crate://crates.io/rusticata-macros/2.1.0 \
+ crate://crates.io/ntp-parser/0.4.0 \
+ crate://crates.io/der-oid-macro/0.2.0 \
+ crate://crates.io/der-parser/3.0.4 \
+ crate://crates.io/ipsec-parser/0.5.0 \
+ crate://crates.io/x509-parser/0.6.5 \
+ crate://crates.io/der-parser/4.1.0 \
+ crate://crates.io/snmp-parser/0.6.0 \
+ crate://crates.io/kerberos-parser/0.5.0 \
+ crate://crates.io/wasi/0.10.0+wasi-snapshot-preview1 \
+ crate://crates.io/winapi/0.3.9 \
+ crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
+ crate://crates.io/log/0.4.0 \
+ crate://crates.io/rand_hc/0.2.0 \
+ crate://crates.io/wasi/0.9.0+wasi-snapshot-preview1 \
+ "
+
+# test case support
+SRC_URI += " \
+ crate://crates.io/test-case/1.0.1 \
+ crate://crates.io/proc-macro2/1.0.1 \
+ crate://crates.io/quote/1.0.1 \
+ crate://crates.io/syn/1.0.1 \
+ crate://crates.io/unicode-xid/0.2.0 \
+ "
+
+inherit autotools pkgconfig python3native systemd ptest cargo
+
+EXTRA_OECONF += " --disable-debug \
+ --disable-gccmarch-native \
+ --enable-non-bundled-htp \
+ --disable-suricata-update \
+ --with-libhtp-includes=${STAGING_INCDIR} --with-libhtp-libraries=${STAGING_LIBDIR} \
+ "
+
+CARGO_SRC_DIR = "rust"
+
+B = "${S}"
+
+PACKAGECONFIG ??= "jansson file pcre yaml python pcap cap-ng net nfnetlink nss nspr "
+PACKAGECONFIG_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 'unittests', '', d)}"
+
+PACKAGECONFIG[pcre] = "--with-libpcre-includes=${STAGING_INCDIR} --with-libpcre-libraries=${STAGING_LIBDIR}, ,libpcre ,"
+PACKAGECONFIG[yaml] = "--with-libyaml-includes=${STAGING_INCDIR} --with-libyaml-libraries=${STAGING_LIBDIR}, ,libyaml ,"
+PACKAGECONFIG[pcap] = "--with-libpcap-includes=${STAGING_INCDIR} --with-libpcap-libraries=${STAGING_LIBDIR}, ,libpcap"
+PACKAGECONFIG[cap-ng] = "--with-libcap_ng-includes=${STAGING_INCDIR} --with-libcap_ng-libraries=${STAGING_LIBDIR}, ,libcap-ng , "
+PACKAGECONFIG[net] = "--with-libnet-includes=${STAGING_INCDIR} --with-libnet-libraries=${STAGING_LIBDIR}, , libnet,"
+PACKAGECONFIG[nfnetlink] = "--with-libnfnetlink-includes=${STAGING_INCDIR} --with-libnfnetlink-libraries=${STAGING_LIBDIR}, ,libnfnetlink ,"
+PACKAGECONFIG[nfq] = "--enable-nfqueue, --disable-nfqueue,libnetfilter-queue,"
+
+PACKAGECONFIG[jansson] = "--with-libjansson-includes=${STAGING_INCDIR} --with-libjansson-libraries=${STAGING_LIBDIR},,jansson, jansson"
+PACKAGECONFIG[file] = ",,file, file"
+PACKAGECONFIG[nss] = "--with-libnss-includes=${STAGING_INCDIR} --with-libnss-libraries=${STAGING_LIBDIR}, nss, nss,"
+PACKAGECONFIG[nspr] = "--with-libnspr-includes=${STAGING_INCDIR} --with-libnspr-libraries=${STAGING_LIBDIR}, nspr, nspr,"
+PACKAGECONFIG[python] = "--enable-python, --disable-python, python3, python3-core"
+PACKAGECONFIG[unittests] = "--enable-unittests, --disable-unittests,"
+
+export logdir = "${localstatedir}/log"
+
+CACHED_CONFIGUREVARS = "ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes"
+
+do_configure_prepend () {
+ oe_runconf
+}
+
+do_compile () {
+ # we do this to bypass the make provided by this pkg
+ # patches Makefile to skip the subdir
+ cargo_do_compile
+
+ # Finish building
+ cd ${S}
+ make
+}
+
+do_install () {
+ install -d ${D}${sysconfdir}/suricata
+
+ oe_runmake install DESTDIR=${D}
+
+ install -d ${D}${sysconfdir}/suricata ${D}${sysconfdir}/default/volatiles
+ install -m 0644 ${WORKDIR}/volatiles.03_suricata ${D}${sysconfdir}/default/volatiles/03_suricata
+
+ install -m 0644 ${S}/threshold.config ${D}${sysconfdir}/suricata
+ install -m 0644 ${S}/suricata.yaml ${D}${sysconfdir}/suricata
+
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
+ install -d ${D}${sysconfdir}/tmpfiles.d
+ install -m 0644 ${WORKDIR}/tmpfiles.suricata ${D}${sysconfdir}/tmpfiles.d/suricata.conf
+
+ install -d ${D}${systemd_unitdir}/system
+ sed -e s:/etc:${sysconfdir}:g \
+ -e s:/var/run:/run:g \
+ -e s:/var:${localstatedir}:g \
+ -e s:/usr/bin:${bindir}:g \
+ -e s:/bin/kill:${base_bindir}/kill:g \
+ -e s:/usr/lib:${libdir}:g \
+ ${WORKDIR}/suricata.service > ${D}${systemd_unitdir}/system/suricata.service
+ fi
+
+ # Remove /var/run as it is created on startup
+ rm -rf ${D}${localstatedir}/run
+
+ sed -i -e "s:#!.*$:#!${USRBINPATH}/env ${PYTHON_PN}:g" ${D}${bindir}/suricatasc
+ sed -i -e "s:#!.*$:#!${USRBINPATH}/env ${PYTHON_PN}:g" ${D}${bindir}/suricatactl
+}
+
+pkg_postinst_ontarget_${PN} () {
+if command -v systemd-tmpfiles >/dev/null; then
+ systemd-tmpfiles --create ${sysconfdir}/tmpfiles.d/suricata.conf
+elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
+ ${sysconfdir}/init.d/populate-volatile.sh update
+fi
+}
+
+SYSTEMD_PACKAGES = "${PN}"
+
+PACKAGES =+ "${PN}-python"
+FILES_${PN} += "${systemd_unitdir} ${sysconfdir}/tmpfiles.d"
+FILES_${PN}-python = "${bindir}/suricatasc ${PYTHON_SITEPACKAGES_DIR}"
+
+CONFFILES_${PN} = "${sysconfdir}/suricata/suricata.yaml"
--
2.25.1


[meta-security][PATCH 4/5] layer.conf: add dynamic-layer for rust pkg

Armin Kuster
 

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

diff --git a/conf/layer.conf b/conf/layer.conf
index fd21da1..906e024 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -12,3 +12,7 @@ BBFILE_PRIORITY_security = "8"
LAYERSERIES_COMPAT_security = "hardknott"

LAYERDEPENDS_security = "core openembedded-layer perl-layer networking-layer meta-python"
+
+BBFILES_DYNAMIC += " \
+rust-layer:${LAYERDIR}/dynamic-layers/meta-rust/recipes-*/*/*.bb \
+"
--
2.25.1

4081 - 4100 of 57104