Re: [yocto] [meta-dpdk][PATCH] [RFC] dpdk: Remove v17
Hello On Tue, 2019-09-24 at 10:40 +0800, zhe...@windriver.com wrote: > From: He Zhe > > openvswith used not to be able to work with dpdk v18. That's one of > the reasons > why we keep v17. Now that openvswitch in meta-virtulization has been > upgraded to > v2.11, officially claimed support of dpdk18, we can drop dpdk v17. > Could you send this to meta-intel list too since the README still mentions that list as the place where patches should be sent? Just in case someone is watching Intel list for updates ... Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting, 9/24/2019
Minutes: Yocto Project Technical Team Meeting When: Tuesday, September 24, 2019 8:00 AM-9:00 AM 1. Attending: Richard, Armin, David, TrevorG, Joshua, Tim, Vineela, Stephen, Denys, Bruce, Randy * Stephen/Richard: General notes - Project status sent (http://lists.openembedded.org/pipermail/openembedded-core/2019-September/287297.html) - Built M3, QA this week, looks good, three issues have fixes or workarounds - Still Hash Equivalency server issues - Sstate growth issues - Would like to get back on schedule with M4 next week - Would like release around 25 October timeframe * Vineela: LSB artifacts? Richard: concern about build re-names, does not want to break Warrior with renamed build scripts. *Hash Equivalency server update. Richard: found many fixes. Fundamental issue around re-running sstate tasks if re-hashing. First answer was "yes", but now trying "no" because it behaves better. Joshua: problem for example around relating to do_pack and do_fetch, skipped by set_scene, but then missing do_populate_license information. Richard: Build cannot go backwards. Currently main queue already past (skipped) set_scene task. We could delay runqueue until all dependencies resolved, or re-execute skipped tasks. This would of course mess with the task count and build determinacy goes "out the window", as well as the risk of touching runqueue. Richard: current plan is to "not rerun tasks", fix other issues, then come back to this problem. * Richard: eSDK failures ow found regularly by build servers, but not on Richard's local host. Meta data is not matching expected values, so we are looking at the hashes. Devtool with unlocked task hash is misbehaving. * Denys: M3 = strace and system timeout workarounds. * Richard: Sumo issues hard to keep up to date with current staffing levels. * Richard: call out for people to help with performance issues. - David -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-openssl102-fips][PATCH V3 4/16] classes/image-enable-fips.bbclass: enable user space fips mode in image
You are correct. I had found that earlier today.
Anyway, the code has been verified as functional, and has been pushed.
Thanks!
--Mark
On 9/25/19 9:35 PM, Hongxu Jia wrote:
> Refer Fedora/RedHat's way
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.5_technical_notes/dracut
>
> To enable user space fips mode in the image recipe as part of an
> 'IMAGE_CLASSES'. Basically if FIPS-140-2 is enabled, then we can
> touch the file as a post image generation activity.
>
> Signed-off-by: Hongxu Jia
> ---
> classes/image-enable-fips.bbclass | 5 +
> conf/layer.conf | 2 ++
> 2 files changed, 7 insertions(+)
> create mode 100644 classes/image-enable-fips.bbclass
>
> diff --git a/classes/image-enable-fips.bbclass
> b/classes/image-enable-fips.bbclass
> new file mode 100644
> index 000..6c5b370
> --- /dev/null
> +++ b/classes/image-enable-fips.bbclass
> @@ -0,0 +1,5 @@
> +ROOTFS_POSTPROCESS_COMMAND_append = "enable_system_fips;"
> +enable_system_fips() {
> +install -d ${IMAGE_ROOTFS}${sysconfdir}
> +touch ${IMAGE_ROOTFS}${sysconfdir}/system-fips
> +}
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 27a872e..185f422 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -18,3 +18,5 @@ LAYERDEPENDS_meta-openssl-one-zero-two-fips = " \
> meta-openssl-one-zero-two \
> wr-template \
> "
> +
> +IMAGE_CLASSES_append = "${@'' if d.getVar('OPENSSL_FIPS_ENABLED', True) !=
> '1' else ' image-enable-fips'}"
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH V3 4/16] classes/image-enable-fips.bbclass: enable user space fips mode in image
Refer Fedora/RedHat's way
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.5_technical_notes/dracut
To enable user space fips mode in the image recipe as part of an
'IMAGE_CLASSES'. Basically if FIPS-140-2 is enabled, then we can
touch the file as a post image generation activity.
Signed-off-by: Hongxu Jia
---
classes/image-enable-fips.bbclass | 5 +
conf/layer.conf | 2 ++
2 files changed, 7 insertions(+)
create mode 100644 classes/image-enable-fips.bbclass
diff --git a/classes/image-enable-fips.bbclass
b/classes/image-enable-fips.bbclass
new file mode 100644
index 000..6c5b370
--- /dev/null
+++ b/classes/image-enable-fips.bbclass
@@ -0,0 +1,5 @@
+ROOTFS_POSTPROCESS_COMMAND_append = "enable_system_fips;"
+enable_system_fips() {
+install -d ${IMAGE_ROOTFS}${sysconfdir}
+touch ${IMAGE_ROOTFS}${sysconfdir}/system-fips
+}
diff --git a/conf/layer.conf b/conf/layer.conf
index 27a872e..185f422 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -18,3 +18,5 @@ LAYERDEPENDS_meta-openssl-one-zero-two-fips = " \
meta-openssl-one-zero-two \
wr-template \
"
+
+IMAGE_CLASSES_append = "${@'' if d.getVar('OPENSSL_FIPS_ENABLED', True) != '1'
else ' image-enable-fips'}"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Review request V2 0/16: [meta-openssl102-fips] Enable FIPS mode in Kernel and OpenSSH
On 9/25/19 10:33 PM, Mark Hatle wrote: On 9/25/19 2:23 AM, Hongxu Jia wrote: Changed in V1: - Follow Mark H's suggestions Hi Mark, Once openssh enables FIPS mode, openssh ptest will fail (mess of failure). It seems the test case of upstream openssh does not consider FIPS mode support. I search fedora, there is nothing about openssh `regress'(test suits) in FIPS mode support So I do not add additional cavs test to the ptest, just add a note to README.enable_fips Ok, that is good to know. I suspect the issue is that many of the tests are trying to use unapproved algorithms and should be skipped in FIPS mode. Something for a future patch set. I don't think it's necessary to adjust now. I did modify patch 4. We want to use the more generic IMAGE_POSTPROCESS_COMMAND instead. But otherwise I've taken it as is. I'm currently running it through a test pass, once that is complete I'll push the commits. Hi Mark, I am afraid we have to use var-ROOTFS_POSTPROCESS_COMMAND to replace, var-IMAGE_POSTPROCESS_COMMAND is used at do_image_complete, we require it to run at do_rootfs //Hongxu --Mark //Hongxu == Comments (indicate scope for each "y" above) == * Git logs [meta-openssl102-fips] commit 38849c1c52ae04eb2a3931624cd2d1446ab389d6 Author: Hongxu Jia Date: Wed Sep 25 15:03:24 2019 +0800 README.enable_fips: openssh ptest failed in fips mode Signed-off-by: Hongxu Jia commit f5b8a66c226541e73cc509a73452bbafc59f2555 Author: Hongxu Jia Date: Sun Sep 22 22:40:56 2019 +0800 README.openssh_cavstest: add CAVS tests for FIPS validation Signed-off-by: Hongxu Jia commit bd5de039c60fd2ab89f7925d3801520d742ba09a Author: Hongxu Jia Date: Sun Sep 22 21:54:41 2019 +0800 openssh: add CAVS tests for FIPS validation Refer the latest Fedora to add cavs test binary for the aes-ctr [1] and SSH KDF CAVS test driver [2] [1] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.6p1-ctr-cavstest.patch [2] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.7p1-kdf-cavs.patch (as of commit 0ca1614ae221578b6b57c61d18fda6cc970a19ce) Signed-off-by: Hongxu Jia commit b40cef8f89461342da5c6a621d95cdb19a4d8cff Author: Hongxu Jia Date: Sun Sep 22 20:55:30 2019 +0800 README.enable_fips: add steps to turn system (kernel and user space) into FIPS mode Refer RedHat/Fedora/SUSE/Oracle/IBM ways 1. Add `fips=1' to kernel option to enable FIPS mode in kernel 2. File /etc/system-fips to determine if a FIPS mode is enabled in user space, currently openssh only Refer: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-federal_standards_and_regulations-federal_information_processing_standard https://access.redhat.com/discussions/3293631 https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20131007/1124363.html https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lgdd/lgdd_r_fipsparm.html https://support.oracle.com/knowledge/Oracle%20Linux%20and%20Virtualization/2323738_1.html Signed-off-by: Hongxu Jia commit a4e3e55688b7a3666bcec95c342dab7984e7e0a3 Author: Hongxu Jia Date: Sun Sep 22 19:27:45 2019 +0800 rng-tools: fix rngd failed in fips mode The FIPS test is something done on government or more secure organizations for extra security check. ... root@qemux86-64:~# systemctl status rngd Unit rngd-tools.service could not be found. root@qemux86-64:~# systemctl status rngd rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2019-09-22 11:10:41 UTC; 18min ago Process: 317 ExecStart=/usr/sbin/rngd -f $EXTRA_ARGS (code=exited, status=0/SUCCESS) Main PID: 317 (code=exited, status=0/SUCCESS) Sep 22 11:10:37 qemux86-64 rngd[317]: RNDADDENTROPY failed: Operation not permitted Sep 22 11:10:37 qemux86-64 rngd[317]: RNDADDENTROPY failed: Operation not permitted Sep 22 11:10:37 qemux86-64 rngd[317]: too many FIPS failures, disabling entropy source ... From rngd manual, add `-i' to default ... -i, --ignorefail Ignore repeated fips failures ... After applying the fix ... rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2019-09-22 12:18:31 UTC; 4min 35s ago Main PID: 121 (rngd) Tasks: 2 Memory: 1.8M CGroup: /system.slice/rngd.service /usr/sbin/rngd -f -r /dev/hwrng -i Sep 22 12:23:06 qemux86-64 rngd[121]: RNDADDENTROPY failed: Operation not
Re: [yocto] Review request V2 0/16: [meta-openssl102-fips] Enable FIPS mode in Kernel and OpenSSH
On 9/25/19 2:23 AM, Hongxu Jia wrote: > Changed in V1: > - Follow Mark H's suggestions > > Hi Mark, > > Once openssh enables FIPS mode, openssh ptest will fail (mess of failure). > It seems the test case of upstream openssh does not consider FIPS mode > support. > I search fedora, there is nothing about openssh `regress'(test suits) in > FIPS mode support > > So I do not add additional cavs test to the ptest, just add a note > to README.enable_fips Ok, that is good to know. I suspect the issue is that many of the tests are trying to use unapproved algorithms and should be skipped in FIPS mode. Something for a future patch set. I don't think it's necessary to adjust now. I did modify patch 4. We want to use the more generic IMAGE_POSTPROCESS_COMMAND instead. But otherwise I've taken it as is. I'm currently running it through a test pass, once that is complete I'll push the commits. --Mark > //Hongxu > > == Comments (indicate scope for each "y" above) == > * Git logs > [meta-openssl102-fips] > commit 38849c1c52ae04eb2a3931624cd2d1446ab389d6 > Author: Hongxu Jia > Date: Wed Sep 25 15:03:24 2019 +0800 > > README.enable_fips: openssh ptest failed in fips mode > > Signed-off-by: Hongxu Jia > > commit f5b8a66c226541e73cc509a73452bbafc59f2555 > Author: Hongxu Jia > Date: Sun Sep 22 22:40:56 2019 +0800 > > README.openssh_cavstest: add CAVS tests for FIPS validation > > Signed-off-by: Hongxu Jia > > commit bd5de039c60fd2ab89f7925d3801520d742ba09a > Author: Hongxu Jia > Date: Sun Sep 22 21:54:41 2019 +0800 > > openssh: add CAVS tests for FIPS validation > > Refer the latest Fedora to add cavs test binary for the aes-ctr [1] > and SSH KDF CAVS test driver [2] > > [1] > http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.6p1-ctr-cavstest.patch > [2] > http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.7p1-kdf-cavs.patch > (as of commit 0ca1614ae221578b6b57c61d18fda6cc970a19ce) > > Signed-off-by: Hongxu Jia > > commit b40cef8f89461342da5c6a621d95cdb19a4d8cff > Author: Hongxu Jia > Date: Sun Sep 22 20:55:30 2019 +0800 > > README.enable_fips: add steps to turn system (kernel and user space) into > FIPS mode > > Refer RedHat/Fedora/SUSE/Oracle/IBM ways > > 1. Add `fips=1' to kernel option to enable FIPS mode in kernel > > 2. File /etc/system-fips to determine if a FIPS mode is enabled in user > space, > currently openssh only > > Refer: > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-federal_standards_and_regulations-federal_information_processing_standard > https://access.redhat.com/discussions/3293631 > > https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20131007/1124363.html > > https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lgdd/lgdd_r_fipsparm.html > > https://support.oracle.com/knowledge/Oracle%20Linux%20and%20Virtualization/2323738_1.html > > Signed-off-by: Hongxu Jia > > commit a4e3e55688b7a3666bcec95c342dab7984e7e0a3 > Author: Hongxu Jia > Date: Sun Sep 22 19:27:45 2019 +0800 > > rng-tools: fix rngd failed in fips mode > > The FIPS test is something done on government or more secure organizations > for extra security check. > ... > root@qemux86-64:~# systemctl status rngd > Unit rngd-tools.service could not be found. > root@qemux86-64:~# systemctl status rngd > rngd.service - Hardware RNG Entropy Gatherer Daemon >Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor > preset: enabled) >Active: inactive (dead) since Sun 2019-09-22 11:10:41 UTC; 18min ago > Process: 317 ExecStart=/usr/sbin/rngd -f $EXTRA_ARGS (code=exited, > status=0/SUCCESS) > Main PID: 317 (code=exited, status=0/SUCCESS) > > Sep 22 11:10:37 qemux86-64 rngd[317]: RNDADDENTROPY failed: Operation not > permitted > Sep 22 11:10:37 qemux86-64 rngd[317]: RNDADDENTROPY failed: Operation not > permitted > Sep 22 11:10:37 qemux86-64 rngd[317]: too many FIPS failures, disabling > entropy source > ... > > From rngd manual, add `-i' to default > ... > -i, --ignorefail > Ignore repeated fips failures > ... > > After applying the fix > ... > rngd.service - Hardware RNG Entropy Gatherer Daemon >Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor > preset: enabled) >Active: active (running) since Sun 2019-09-22 12:18:31 UTC; 4min 35s > ago > Main PID: 121 (rngd) > Tasks: 2 >Memory: 1.8M >CGroup: /system.slice/rngd.service >/usr/sbin/rngd -f -r /dev/hwrng -i > > Sep 22 12:23:06 qemux86-64 rngd[121]: RNDADDENTROPY failed: Operation not > permitted > ... > > Refer: > >
Re: [yocto] gitlab-ci helper scripts for OpenEmbedded builds
Hi Thomas, Le mar. 24 sept. 2019 à 14:36, Thomas Goodwin a écrit : > Hi Yann, > > Thanks for sharing! We're working through something similar using a tweak > to the CROPS docker containers and GitLab-CI (we started with autobuilder > 2, so we've actually merged quite a bit of that experience with our GitLab > setup). > Thanks for pointing me to CROPS, that will help bringing Docker support here :) > Using docker runners as our cluster, we setup volume mounts to the host > system for caching the shared state and downloads directories (as well as > other artifacts upon successful build). As part of the CI setup, we then > insert a build/conf/auto.conf file that enforces the usage of that volume > (DL_DIR and SSTATE_DIR). At the deploy stage (package feeds, etc. like > you're doing), we did the same thing -- copy out to that path so that it > ends up on the network share rather than the container. > > Also like you, we're using the "include" and "extends" instructions > throughout so that we have a top-level "common" set of CI YAML includes > alongside a growing set of repositories for each machine-specific build. > Each of those repositories follows the Yocto release branching style so > that we can trace build success to newer releases by simply creating a > branch and using the branch name for the initial clone of the layers. > > One thing that came directly from our autobuilder 2 experience is a way to > inject extra variables into the autoconf. AB2 called this *EXTRAARGS*, > which was simply a list of variables to add. For our common CI "setup" > stage, we check for a file of the same name (extraargs.conf) and append it > to the auto.conf if it exists. In this way our downstream projects can > simply include that file if necessary and version control it as new release > branches are added. > > One of the drawbacks we've seen in going this route is that every > repository has its own build timeout limit, which is always laughably > small. There's a backlog issue on GitLab for a global definition of this > value, but it's slated for 12.7 (I think). > > I'm hoping to put a write-up out soon with examples for how this all > worked together, but I want to hold off until we can get the CROPS changes > we needed upstreamed in a way that doesn't break those containers for > everyone else (something about the entrypoint doesn't appreciate the > runner's bash/shell detection script). > Looking forward to this! > Cheers, > > Thomas > > Geon Technologies, LLC > > > On Mon, Sep 23, 2019 at 5:50 PM Yann Dirson > wrote: > >> Hi all, >> >> We released our scripts to help in setting up continuous integration >> of a yocto-based project >> using Gitlab-CI. You'll find the repository at >> https://github.com/BladeGroup/gitlab-oe >> >> Although we're using this in production, it still has a couple of >> rough edges and may need >> tuning for different usages. We'd love to hear how well it fits (or >> doesn't fit ;) with other use >> cases, and will gladly consider evolutions to make it more generally >> usable. >> >> Best regards, >> -- >> Yann Dirson >> Blade / Shadow -- http://shadow.tech >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > -- Yann Dirson Blade / Shadow -- http://shadow.tech -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/3] patches for zynq7000
On 9/25/19 3:35 PM, Michal Simek wrote:
On 25. 09. 19 8:18, qwang2 wrote:
On 9/25/19 1:34 PM, Michal Simek wrote:
On 25. 09. 19 0:16, Bruce Ashfield wrote:
In message: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 0/3]
patches for zynq7000
on 23/09/2019 quanyang.w...@windriver.com wrote:
From: Quanyang Wang
Hi Bruce,
Would you please help merge these patches to linux-yocto
v5.2/standard/xlnx-soc branch?
These are now merged.
Are these changes already done upstream, or applicable to upstream ?
I just
want to make sure we aren't only fixes these in the yocto kernel when
there
are other places that we can fix as well.
We don't have this in mainline or xilinx kernel simply because none has
asked for it.
I am completely missing any manual/description how this should be tested
but I expect this is based on mainline binding.
Hi Bruce & Michal,
1. The patch "ARM: dts: zc702: Fix I2C bus warnings" fix some dtb
building warnings. And
this warnings will not happen in SDK (v4.19) and upstream. Because dtc
in SDK not check this
and in upstream the zynq-zc702 dts file is in correct format. This patch
is needed only because I
apply SDK patch to v5.2 kernel.
I just need to take a look but not a problem with it at all.
2. The patch "mmc: sdhci-of-arasan: Fix the incorrect soft reset
operation when runtime resuming"
is also because that SDK patch use old function API and v5.2.16 use a
new one.
ditto - it should be ok.
3. The patch "arm: dts: zynq: enablement of coresight topology" is for
coresight. It is not mature now
and I only simply verify it by using ptm2human, but will need more test
on this patch.
Do you have any description somewhere how to use it? Or can you please
put together any manual how to use it?
Hi Michal,
I just follow the document "Documentation/trace/coresight.txt" to test
the coresight.
On target:
root@xilinx-zynq:/sys/bus/coresight/devices# echo 1 >
f8801000.etb/enable_sink
root@xilinx-zynq:/sys/bus/coresight/devices# echo 1 >
f889c000.ptm/enable_source
root@xilinx-zynq:/sys/bus/coresight/devices# sleep 2
root@xilinx-zynq:/sys/bus/coresight/devices# echo 0 >
f889c000.ptm/enable_source
root@xilinx-zynq:/sys/bus/coresight/devices# dd if=/dev/f8801000.etb
of=/root/1.bin
8+0 records in
8+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00170529 s, 2.4 MB/s
On PC:
./ptm2human -p -i 1.bin > 1.txt
In 1.txt, I get some lines as below:
instruction addr at 0x0018, ARM state, exception (IRQ), secure state,
instruction addr at 0x80102160, ARM state,
instruction addr at 0x805ae280, ARM state,
instruction addr at 0x80177ac8, ARM state,
instruction addr at 0x80177ad8, ARM state,
instruction addr at 0x801893a8, ARM state,
instruction addr at 0x801881d8, ARM state,
instruction addr at 0x801893e8, ARM state,
I checked the System.map and the addresses like 0x80102160, 0x805ae280
are for
__irq_svc and gic_handle_irq. So these instructions which are captured
should be in a irq call routine.
But ptm2human can't parse detailedly the tracing packets.
So I can't say that the coresight function works well with this patch.
More test methods are needed to verify it.
In ./Documentation/trace/coresight.txt, it says that DS-5 and Trace32
can also parse the
tracing packets and will get more detailed data as below:
Info Tracing enabled
Instruction 106378866 0x8026B53C E52DE004 false
PUSH {lr}
Instruction 0 0x8026B540 E24DD00C false SUB
sp,sp,#0xc
Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
Instruction 0 0x8026B548 E58D3004 false STR
r3,[sp,#4]
Instruction 0 0x8026B54C E59D3004 false LDR
r3,[sp,#4]
Instruction 0 0x8026B550 E3530004 false CMP r3,#4
Instruction 0 0x8026B554 E2833001 false ADD
r3,r3,#1
Instruction 0 0x8026B558 E58D3004 false STR
r3,[sp,#4]
But I am still striving to find out how to use DS-5 to parse the data.
Is there any plan for xilinx SDK to support coresight?
Thanks,
Quanyang
M
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] [meta-openssl102-fips][PATCH 15/16] README.openssh_cavstest: add CAVS tests for FIPS validation
Signed-off-by: Hongxu Jia --- README.openssh_cavstest | 28 1 file changed, 28 insertions(+) create mode 100644 README.openssh_cavstest diff --git a/README.openssh_cavstest b/README.openssh_cavstest new file mode 100644 index 000..5d69ee5 --- /dev/null +++ b/README.openssh_cavstest @@ -0,0 +1,28 @@ +1. Install openssh-cavs to images +$ echo "IMAGE_INSTALL += 'openssh-cavs'" >> conf/local.conf +$ bitbake + +2. Run tests on target +1) ctr-cavstest +invocation (all of the following are equal): +./ctr-cavstest --algo aes128-ctr --key 987212980144b6a632e864031f52dacc --mode encrypt --data a6deca405eef2e8e4609abf3c3ccf4a6 +./ctr-cavstest --algo aes128-ctr --key 987212980144b6a632e864031f52dacc --mode encrypt --data a6deca405eef2e8e4609abf3c3ccf4a6 --iv +echo -n a6deca405eef2e8e4609abf3c3ccf4a6 | ./ctr-cavstest --algo aes128-ctr --key 987212980144b6a632e864031f52dacc --mode encrypt + +$ cd /usr/libexec +$ ./ctr-cavstest --algo aes128-ctr --key 987212980144b6a632e864031f52dacc --mode encrypt --data a6deca405eef2e8e4609abf3c3ccf4a6 +58E33554D51B0DD7A63F44B22381B1CA +$ ./ctr-cavstest --algo aes128-ctr --key 987212980144b6a632e864031f52dacc --mode encrypt --data a6deca405eef2e8e4609abf3c3ccf4a6 --iv +58E33554D51B0DD7A63F44B22381B1CA +$ echo -n a6deca405eef2e8e4609abf3c3ccf4a6 | ./ctr-cavstest --algo aes128-ctr --key 987212980144b6a632e864031f52dacc --mode encrypt +58E33554D51B0DD7A63F44B22381B1CA + +2) ssh-cavs +$ cd /usr/libexec +$ ./ssh-cavs -K 0055d50f2d163cc07cd8a93cc7c3430c30ce786b572c01ad29fec7597000cf8618d664e2ec3dcbc8bb7a1a7eb7ef67f61cdaf291625da879186ac0a5cb27af571b59612d6a6e0627344d846271959fda61c78354aa498773d59762f8ca2d0215ec590d8633de921f920d41e47b3de6ab9a3d0869e1c826d0e4adebf8e3fb646a15dea20a410b44e969f4b791ed6a67f13f1b74234004d5fa5e87eff7abc32d49bbdf44d7b0107e8f10609233b7e2b7eff74a4daf25641de7553975dac6ac1e5117df6f6dbaa1c263d23a6c3e5a3d7d49ae8a828c1e333ac3f85fbbf57b5c1a45be45e43a7be1a4707eac779b8285522d1f531fe23f890fd38a004339932b93eda4 -H d3ab91a850febb417a25d892ec48ed5952c7a5de -s d3ab91a850febb417a25d892ec48ed5952c7a5de -i 8 -e 24 -m 20 +Initial IV (client to server) = 4bb320d1679dfd3a +Initial IV (server to client) = 43dea6fdf263a308 +Encryption key (client to server) = 13048cc600b9d3cf9095aa6cf8e2ff9cf1c54ca0520c89ed +Encryption key (server to client) = 1e483c5134e901aa11fc4e0a524e7ec7b75556148a222bb0 +Integrity key (client to server) = ecef63a092b0dcc585bdc757e01b2740af57d640 +Integrity key (server to client) = 7424b05f3c44a72b4ebd281fb71f9cbe7b64d479 -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH 16/16] README.enable_fips: openssh ptest failed in fips mode
Signed-off-by: Hongxu Jia --- README.enable_fips | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.enable_fips b/README.enable_fips index 8016346..676698b 100644 --- a/README.enable_fips +++ b/README.enable_fips @@ -54,3 +54,6 @@ FIPS mode initialized - ssh-keygen # ssh-keygen -A ssh-keygen: generating new host keys: DSA DSA keys are not allowed in FIPS mode + +NOTE: Once openssh enables FIPS mode, openssh ptest will fail. The test case +of openssh does not consider FIPS mode support. -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH 12/16] rng-tools: fix rngd failed in fips mode
The FIPS test is something done on government or more secure organizations for extra security check. ... root@qemux86-64:~# systemctl status rngd Unit rngd-tools.service could not be found. root@qemux86-64:~# systemctl status rngd rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2019-09-22 11:10:41 UTC; 18min ago Process: 317 ExecStart=/usr/sbin/rngd -f $EXTRA_ARGS (code=exited, status=0/SUCCESS) Main PID: 317 (code=exited, status=0/SUCCESS) Sep 22 11:10:37 qemux86-64 rngd[317]: RNDADDENTROPY failed: Operation not permitted Sep 22 11:10:37 qemux86-64 rngd[317]: RNDADDENTROPY failed: Operation not permitted Sep 22 11:10:37 qemux86-64 rngd[317]: too many FIPS failures, disabling entropy source ... >From rngd manual, add `-i' to default ... -i, --ignorefail Ignore repeated fips failures ... After applying the fix ... rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2019-09-22 12:18:31 UTC; 4min 35s ago Main PID: 121 (rngd) Tasks: 2 Memory: 1.8M CGroup: /system.slice/rngd.service /usr/sbin/rngd -f -r /dev/hwrng -i Sep 22 12:23:06 qemux86-64 rngd[121]: RNDADDENTROPY failed: Operation not permitted ... Refer: https://www.unix.com/unix-for-advanced-and-expert-users/265510-rngd-failed-fips-test.html Signed-off-by: Hongxu Jia --- recipes-support/rng-tools/rng-tools/default | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-support/rng-tools/rng-tools/default b/recipes-support/rng-tools/rng-tools/default index b9f8e03..1ae6b33 100644 --- a/recipes-support/rng-tools/rng-tools/default +++ b/recipes-support/rng-tools/rng-tools/default @@ -1 +1 @@ -EXTRA_ARGS="-r /dev/hwrng" +EXTRA_ARGS="-r /dev/hwrng -i" -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH 11/16] rng-tools bbappend: port a copy of default from oe-core
Port it at the following commit in oe-core
http://cgit.openembedded.org/openembedded-core/commit/?id=16ced1a253c74c01ca414db2f1a010c083213b91
Signed-off-by: Hongxu Jia
---
recipes-support/rng-tools/rng-tools/default | 1 +
recipes-support/rng-tools/rng-tools_6.%.bbappend | 4
recipes-support/rng-tools/rng-tools_fips.inc | 2 ++
3 files changed, 7 insertions(+)
create mode 100644 recipes-support/rng-tools/rng-tools/default
create mode 100644 recipes-support/rng-tools/rng-tools_6.%.bbappend
create mode 100644 recipes-support/rng-tools/rng-tools_fips.inc
diff --git a/recipes-support/rng-tools/rng-tools/default
b/recipes-support/rng-tools/rng-tools/default
new file mode 100644
index 000..b9f8e03
--- /dev/null
+++ b/recipes-support/rng-tools/rng-tools/default
@@ -0,0 +1 @@
+EXTRA_ARGS="-r /dev/hwrng"
diff --git a/recipes-support/rng-tools/rng-tools_6.%.bbappend
b/recipes-support/rng-tools/rng-tools_6.%.bbappend
new file mode 100644
index 000..c487175
--- /dev/null
+++ b/recipes-support/rng-tools/rng-tools_6.%.bbappend
@@ -0,0 +1,4 @@
+FIPSINC = ""
+FIPSINC_class-target = "${@'' if d.getVar('OPENSSL_FIPS_ENABLED', True) != '1'
else 'rng-tools_fips.inc'}"
+
+require ${FIPSINC}
diff --git a/recipes-support/rng-tools/rng-tools_fips.inc
b/recipes-support/rng-tools/rng-tools_fips.inc
new file mode 100644
index 000..d5f6435
--- /dev/null
+++ b/recipes-support/rng-tools/rng-tools_fips.inc
@@ -0,0 +1,2 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/rng-tools:"
+
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH 13/16] README.enable_fips: add steps to turn system (kernel and user space) into FIPS mode
Refer RedHat/Fedora/SUSE/Oracle/IBM ways 1. Add `fips=1' to kernel option to enable FIPS mode in kernel 2. File /etc/system-fips to determine if a FIPS mode is enabled in user space, currently openssh only Refer: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-federal_standards_and_regulations-federal_information_processing_standard https://access.redhat.com/discussions/3293631 https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20131007/1124363.html https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lgdd/lgdd_r_fipsparm.html https://support.oracle.com/knowledge/Oracle%20Linux%20and%20Virtualization/2323738_1.html Signed-off-by: Hongxu Jia --- README.enable_fips | 56 ++ 1 file changed, 56 insertions(+) create mode 100644 README.enable_fips diff --git a/README.enable_fips b/README.enable_fips new file mode 100644 index 000..8016346 --- /dev/null +++ b/README.enable_fips @@ -0,0 +1,56 @@ +To turn your system (kernel and user space) into FIPS mode, follow these steps: + +1. Enable FIPS mode in kernel: +The `fips=1' kernel option needs to be added to the kernel command line so that key +generation is done with FIPS approved algorithms and continuous monitoring tests in +place: +... +[0.00] Linux version 5.3.0-yoctodev-standard (oe-user@oe-host) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Sun Sep 22 07:03:58 UTC 2019 +[0.00] Command line: root=/dev/vda rw highres=off console=ttyS0 fips=1 +[0.281178] alg: self-tests for rsa-generic (rsa) passed +[0.283124] alg: self-tests for cipher_null-generic (cipher_null) passed +[0.284199] alg: self-tests for ecb-cipher_null (ecb(cipher_null)) passed +[0.285596] alg: self-tests for sha1-generic (sha1) passed +[0.287474] alg: self-tests for sha256-generic (sha256) passed +[0.289138] alg: self-tests for sha224-generic (sha224) passed +[0.290277] alg: self-tests for des3_ede-generic (des3_ede) passed +[0.292005] alg: self-tests for aes-generic (aes) passed +[0.294431] alg: self-tests for crc32c-generic (crc32c) passed +[0.295046] alg: self-tests for drbg_pr_hmac_sha1 (stdrng) passed +[0.296927] alg: self-tests for drbg_pr_hmac_sha384 (stdrng) passed +[0.298001] alg: self-tests for drbg_pr_hmac_sha512 (stdrng) passed +[0.301064] alg: self-tests for hmac(sha256-generic) (hmac(sha256)) passed +[0.303057] alg: self-tests for drbg_pr_hmac_sha256 (stdrng) passed +[0.304026] alg: self-tests for drbg_nopr_hmac_sha1 (stdrng) passed +[0.304999] alg: self-tests for drbg_nopr_hmac_sha384 (stdrng) passed +[0.306001] alg: self-tests for drbg_nopr_hmac_sha512 (stdrng) passed +[0.307377] alg: self-tests for drbg_nopr_hmac_sha256 (stdrng) passed +[0.311120] DRBG: Continuing without Jitter RNG +[0.316952] alg: self-tests for ecdh-generic (ecdh) passed +[0.996938] alg: self-tests for jitterentropy_rng (jitterentropy_rng) passed +[3.330824] alg: self-tests for cbc(aes-generic) (cbc(aes)) passed +... + +Kernel FIPS mode verification +You have two options: +1) cat /proc/sys/crypto/fips_enabled +2) sysctl crypto.fips_enabled + +NOTE: 1 indicates enabled, while 0 indicates disabled. + + +2. Enable FIPS mode in user space (default yes) +File /etc/system-fips to determine if a FIPS module is installed and +FIPS mode is enabled + +1) openssh: +- sshd +2019-09-22T12:20:04.631097+00:00 qemux86-64 sshd[437]: FIPS mode initialized + +- ssh +# ssh root@localhost +FIPS mode initialized + +- ssh-keygen +# ssh-keygen -A +ssh-keygen: generating new host keys: DSA DSA keys are not allowed in FIPS mode -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH V2 14/16] openssh: add CAVS tests for FIPS validation
Refer the latest Fedora to add cavs test binary for the aes-ctr [1]
and SSH KDF CAVS test driver [2]
[1]
http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.6p1-ctr-cavstest.patch
[2]
http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.7p1-kdf-cavs.patch
(as of commit 0ca1614ae221578b6b57c61d18fda6cc970a19ce)
Signed-off-by: Hongxu Jia
---
.../openssh/openssh-6.6p1-ctr-cavstest.patch | 289 +
.../openssh/openssh/openssh-6.7p1-kdf-cavs.patch | 654 +
recipes-connectivity/openssh/openssh_fips.inc | 9 +
3 files changed, 952 insertions(+)
create mode 100644
recipes-connectivity/openssh/openssh/openssh-6.6p1-ctr-cavstest.patch
create mode 100644
recipes-connectivity/openssh/openssh/openssh-6.7p1-kdf-cavs.patch
diff --git
a/recipes-connectivity/openssh/openssh/openssh-6.6p1-ctr-cavstest.patch
b/recipes-connectivity/openssh/openssh/openssh-6.6p1-ctr-cavstest.patch
new file mode 100644
index 000..29371f8
--- /dev/null
+++ b/recipes-connectivity/openssh/openssh/openssh-6.6p1-ctr-cavstest.patch
@@ -0,0 +1,289 @@
+From a94a3d95439018dc7d276ec72de91af369ea413e Mon Sep 17 00:00:00 2001
+From: Hongxu Jia
+Date: Sun, 22 Sep 2019 21:32:18 +0800
+Subject: [PATCH 1/2] add CAVS test driver for the aes-ctr ciphers
+
+Original submission to Fedora, see:
+
https://lists.fedoraproject.org/pipermail/scm-commits/2012-January/715044.html
+
+this version download from:
+
http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.6p1-ctr-cavstest.patch
+ (as of commit 0ca1614ae221578b6b57c61d18fda6cc970a19ce)
+
+Makefile.in slightly modified for integration
+
+This is the makefile.in change for the normal configuration.
+
+Signed-off-by: Mark Hatle
+
+Upstream-Status: Inappropriate [oe specific]
+Signed-off-by: Hongxu Jia
+---
+ Makefile.in| 7 +-
+ ctr-cavstest.c | 215 +
+ 2 files changed, 221 insertions(+), 1 deletion(-)
+ create mode 100644 ctr-cavstest.c
+
+diff --git a/Makefile.in b/Makefile.in
+index ddd1804..cb34681 100644
+--- a/Makefile.in
b/Makefile.in
+@@ -23,6 +23,7 @@ SSH_PROGRAM=@bindir@/ssh
+ ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass
+ SFTP_SERVER=$(libexecdir)/sftp-server
+ SSH_KEYSIGN=$(libexecdir)/ssh-keysign
++CTR_CAVSTEST=$(libexecdir)/ctr-cavstest
+ SSH_PKCS11_HELPER=$(libexecdir)/ssh-pkcs11-helper
+ PRIVSEP_PATH=@PRIVSEP_PATH@
+ SSH_PRIVSEP_USER=@SSH_PRIVSEP_USER@
+@@ -60,7 +61,7 @@ EXEEXT=@EXEEXT@
+ MANFMT=@MANFMT@
+ MKDIR_P=@MKDIR_P@
+
+-TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT)
ssh-keyscan${EXEEXT} ssh-keysign${EXEEXT} ssh-pkcs11-helper$(EXEEXT)
ssh-agent$(EXEEXT) scp$(EXEEXT) sftp-server$(EXEEXT) sftp$(EXEEXT)
++TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT)
ssh-keyscan${EXEEXT} ssh-keysign${EXEEXT} ssh-pkcs11-helper$(EXEEXT)
ssh-agent$(EXEEXT) scp$(EXEEXT) sftp-server$(EXEEXT) sftp$(EXEEXT)
ctr-cavstest$(EXEEXT)
+
+ XMSS_OBJS=\
+ ssh-xmss.o \
+@@ -193,6 +194,9 @@ ssh-keysign$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keysign.o
readconf.o uidswap.o c
+ ssh-pkcs11-helper$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-pkcs11-helper.o
ssh-pkcs11.o
+ $(LD) -o $@ ssh-pkcs11-helper.o ssh-pkcs11.o $(LDFLAGS) -lssh
-lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
+
++ctr-cavstest$(EXEEXT): $(LIBCOMPAT) libssh.a ctr-cavstest.o
++ $(LD) -o $@ ctr-cavstest.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh
-lfipscheck $(LIBS)
++
+ ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o
+ $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh
-lfipscheck $(LIBS)
+
+@@ -343,6 +347,7 @@ install-files:
+ $(INSTALL) -m 0755 $(STRIP_OPT) ssh-keyscan$(EXEEXT)
$(DESTDIR)$(bindir)/ssh-keyscan$(EXEEXT)
+ $(INSTALL) -m 0755 $(STRIP_OPT) sshd$(EXEEXT)
$(DESTDIR)$(sbindir)/sshd$(EXEEXT)
+ $(INSTALL) -m 4711 $(STRIP_OPT) ssh-keysign$(EXEEXT)
$(DESTDIR)$(SSH_KEYSIGN)$(EXEEXT)
++ $(INSTALL) -m 0755 $(STRIP_OPT) ctr-cavstest$(EXEEXT)
$(DESTDIR)$(libexecdir)/ctr-cavstest$(EXEEXT)
+ $(INSTALL) -m 0755 $(STRIP_OPT) ssh-pkcs11-helper$(EXEEXT)
$(DESTDIR)$(SSH_PKCS11_HELPER)$(EXEEXT)
+ $(INSTALL) -m 0755 $(STRIP_OPT) sftp$(EXEEXT)
$(DESTDIR)$(bindir)/sftp$(EXEEXT)
+ $(INSTALL) -m 0755 $(STRIP_OPT) sftp-server$(EXEEXT)
$(DESTDIR)$(SFTP_SERVER)$(EXEEXT)
+diff --git a/ctr-cavstest.c b/ctr-cavstest.c
+new file mode 100644
+index 000..0d4776b
+--- /dev/null
b/ctr-cavstest.c
+@@ -0,0 +1,215 @@
++/*
++ *
++ * invocation (all of the following are equal):
++ * ./ctr-cavstest --algo aes128-ctr --key 987212980144b6a632e864031f52dacc
--mode encrypt --data a6deca405eef2e8e4609abf3c3ccf4a6
++ * ./ctr-cavstest --algo aes128-ctr --key 987212980144b6a632e864031f52dacc
--mode encrypt --data a6deca405eef2e8e4609abf3c3ccf4a6 --iv
++ * echo -n a6deca405eef2e8e4609abf3c3ccf4a6 | ./ctr-cavstest --algo
aes128-ctr --key
[yocto] [meta-openssl102-fips][PATCH 8/16] openssh: conditional enable fips mode
Enable fips mode according to the existence of "/etc/system-fips"
Signed-off-by: Hongxu Jia
---
.../0001-conditional-enable-fips-mode.patch| 63 ++
recipes-connectivity/openssh/openssh_fips.inc | 1 +
2 files changed, 64 insertions(+)
create mode 100644
recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
diff --git
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
new file mode 100644
index 000..b47e184
--- /dev/null
+++
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
@@ -0,0 +1,63 @@
+From ea3e5eceab28ad2c00d438efbcea2be37a1b2969 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia
+Date: Sun, 22 Sep 2019 14:31:51 +0800
+Subject: [PATCH] conditional enable fips mode
+
+Insert ssh_enable_fips_mode to ssh_malloc_init where each main app will invoke,
+enable fips mode according to the existence of "/etc/system-fips"
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia
+---
+ xmalloc.c | 24
+ 1 file changed, 24 insertions(+)
+
+diff --git a/xmalloc.c b/xmalloc.c
+index 5cc0310..0218ccd 100644
+--- a/xmalloc.c
b/xmalloc.c
+@@ -23,12 +23,20 @@
+ #include
+ #include
+
++#include
++#include
++#include
++
+ #include "xmalloc.h"
+ #include "log.h"
+
++void ssh_enable_fips_mode(void);
++
+ void
+ ssh_malloc_init(void)
+ {
++ ssh_enable_fips_mode();
++
+ #if defined(__OpenBSD__)
+ extern char *malloc_options;
+
+@@ -116,3 +124,19 @@ xasprintf(char **ret, const char *fmt, ...)
+
+ return (i);
+ }
++
++void
++ssh_enable_fips_mode(void)
++{
++if (access("/etc/system-fips", F_OK) == 0) {
++if (!FIPS_mode_set(1)) {
++/* make sure the error stack is available for some hint as
++ * to why this operation failed
++ */
++ERR_load_crypto_strings();
++ERR_print_errors_fp(stdout);
++fatal("FIPS_mode_set(): failed to enter FIPS mode!\n");
++exit(1);
++}
++}
++}
+--
+2.7.4
+
diff --git a/recipes-connectivity/openssh/openssh_fips.inc
b/recipes-connectivity/openssh/openssh_fips.inc
index 8f21264..9d25b5b 100644
--- a/recipes-connectivity/openssh/openssh_fips.inc
+++ b/recipes-connectivity/openssh/openssh_fips.inc
@@ -5,6 +5,7 @@ DEPENDS += " \
"
SRC_URI += " \
file://0001-openssh-8.0p1-fips.patch \
+file://0001-conditional-enable-fips-mode.patch \
"
do_install_append() {
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH 10/16] openssh/sshd_check_keys: don't generate ED25519 host keys in FIPS mode
Run sshd_check_keys failed:
...
2019-09-22T09:59:10.878738+00:00 qemux86-64 sshd_check_keys[419]: generating
ssh ED25519 host key...
2019-09-22T09:59:10.897617+00:00 qemux86-64 sshd_check_keys[419]: ED25519 keys
are not allowed in FIPS mode
...
If fips mode enabled (existence of "/etc/system-fips"), don't generate ED25519
host
keys in FIPS mode
Refers Fedora:
https://src.fedoraproject.org/rpms/openssh/c/00c7b7543973f237b79ee87ca697c08b71954d35
https://src.fedoraproject.org/rpms/openssh/c/3b7c8620a1df976c1c09553c1c7b99ce492d290b
Signed-off-by: Hongxu Jia
---
recipes-connectivity/openssh/openssh/sshd_check_keys | 4
1 file changed, 4 insertions(+)
diff --git a/recipes-connectivity/openssh/openssh/sshd_check_keys
b/recipes-connectivity/openssh/openssh/sshd_check_keys
index 1931dc7..338531d 100644
--- a/recipes-connectivity/openssh/openssh/sshd_check_keys
+++ b/recipes-connectivity/openssh/openssh/sshd_check_keys
@@ -71,6 +71,10 @@ for key in ${HOST_KEYS} ; do
generate_key $key ecdsa
;;
*_ed25519_key)
+FIPS=/etc/system-fips
+if [[ -r "$FIPS" ]]; then
+continue
+fi
echo " generating ssh ED25519 host key..."
generate_key $key ed25519
;;
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH V2 9/16] openssh: port a copy of sshd_check_keys from oe-core
Port it at the following commit in oe-core
http://cgit.openembedded.org/openembedded-core/commit/?id=2303d795ae96f1a60caf145a0ddf100e89c4b5b0
Signed-off-by: Hongxu Jia
---
.../openssh/openssh/sshd_check_keys| 78 ++
1 file changed, 78 insertions(+)
create mode 100644 recipes-connectivity/openssh/openssh/sshd_check_keys
diff --git a/recipes-connectivity/openssh/openssh/sshd_check_keys
b/recipes-connectivity/openssh/openssh/sshd_check_keys
new file mode 100644
index 000..1931dc7
--- /dev/null
+++ b/recipes-connectivity/openssh/openssh/sshd_check_keys
@@ -0,0 +1,78 @@
+#! /bin/sh
+
+generate_key() {
+local FILE=$1
+local TYPE=$2
+local DIR="$(dirname "$FILE")"
+
+mkdir -p "$DIR"
+ssh-keygen -q -f "${FILE}.tmp" -N '' -t $TYPE
+
+# Atomically rename file public key
+mv -f "${FILE}.tmp.pub" "${FILE}.pub"
+
+# This sync does double duty: Ensuring that the data in the temporary
+# private key file is on disk before the rename, and ensuring that the
+# public key rename is completed before the private key rename, since we
+# switch on the existence of the private key to trigger key generation.
+# This does mean it is possible for the public key to exist, but be garbage
+# but this is OK because in that case the private key won't exist and the
+# keys will be regenerated.
+#
+# In the event that sync understands arguments that limit what it tries to
+# fsync(), we provided them. If it does not, it will simply call sync()
+# which is just as well
+sync "${FILE}.pub" "$DIR" "${FILE}.tmp"
+
+mv "${FILE}.tmp" "$FILE"
+
+# sync to ensure the atomic rename is committed
+sync "$DIR"
+}
+
+# /etc/default/ssh may set SYSCONFDIR and SSHD_OPTS
+if test -f /etc/default/ssh; then
+. /etc/default/ssh
+fi
+
+[ -z "$SYSCONFDIR" ] && SYSCONFDIR=/etc/ssh
+mkdir -p $SYSCONFDIR
+
+# parse sshd options
+set -- ${SSHD_OPTS} --
+sshd_config=/etc/ssh/sshd_config
+while true ; do
+case "$1" in
+-f*) if [ "$1" = "-f" ] ; then
+sshd_config="$2"
+shift
+else
+sshd_config="${1#-f}"
+fi
+shift
+;;
+--) shift; break;;
+*) shift;;
+esac
+done
+
+HOST_KEYS=$(sed -n 's/^[ \t]*HostKey[ \t]\+\(.*\)/\1/p' "${sshd_config}")
+[ -z "${HOST_KEYS}" ] && HOST_KEYS="$SYSCONFDIR/ssh_host_rsa_key
$SYSCONFDIR/ssh_host_ecdsa_key $SYSCONFDIR/ssh_host_ed25519_key"
+
+for key in ${HOST_KEYS} ; do
+[ -f $key ] && continue
+case $key in
+*_rsa_key)
+echo " generating ssh RSA host key..."
+generate_key $key rsa
+;;
+*_ecdsa_key)
+echo " generating ssh ECDSA host key..."
+generate_key $key ecdsa
+;;
+*_ed25519_key)
+echo " generating ssh ED25519 host key..."
+generate_key $key ed25519
+;;
+esac
+done
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH V2 5/16] openssh: add generation of HMAC checksums in pkg_postinst
Refer
https://src.fedoraproject.org/rpms/openssh/c/13fa787ecc35d6c9eea9e64c1f42f49e2ee978ce
(See __spec_install_post in openssh.spec for detail)
Signed-off-by: Hongxu Jia
---
recipes-connectivity/openssh/openssh_fips.inc | 34 +++
1 file changed, 34 insertions(+)
diff --git a/recipes-connectivity/openssh/openssh_fips.inc
b/recipes-connectivity/openssh/openssh_fips.inc
index 99a3482..8f21264 100644
--- a/recipes-connectivity/openssh/openssh_fips.inc
+++ b/recipes-connectivity/openssh/openssh_fips.inc
@@ -6,3 +6,37 @@ DEPENDS += " \
SRC_URI += " \
file://0001-openssh-8.0p1-fips.patch \
"
+
+do_install_append() {
+install -d ${D}${libdir}/fipscheck
+}
+
+inherit qemu
+
+pkg_postinst_append_${PN}-ssh () {
+if [ -n "$D" ]; then
+if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode',
'true','false', d)}; then
+${@qemu_run_binary(d, '$D', '${bindir}/fipshmac')} \
+-d $D${libdir}/fipscheck $D${bindir}/ssh.${BPN}
+else
+$INTERCEPT_DIR/postinst_intercept delay_to_first_boot ${PKG}
mlprefix=${MLPREFIX}
+fi
+else
+${bindir}/fipshmac -d ${libdir}/fipscheck ${bindir}/ssh.${BPN}
+fi
+}
+
+pkg_postinst_append_${PN}-sshd () {
+if [ -n "$D" ]; then
+if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode',
'true','false', d)}; then
+${@qemu_run_binary(d, '$D', '${bindir}/fipshmac')} \
+-d $D${libdir}/fipscheck $D${sbindir}/sshd
+else
+$INTERCEPT_DIR/postinst_intercept delay_to_first_boot ${PKG}
mlprefix=${MLPREFIX}
+fi
+else
+${bindir}/fipshmac -d ${libdir}/fipscheck ${sbindir}/sshd
+fi
+}
+
+FILES_${PN} += "${libdir}/fipscheck"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH 7/16] kernel: workaround alg self-tests failure in fips mode
While kernel enable fips mode, it start alg self-test, and there is
a kernel panic at ecdh-generic
...
[0.311313] alg: ecdh: test failed on vector 2, err=-14
[0.311898] Kernel panic - not syncing: alg: self-tests for ecdh-generic
(ecdh) failed in fips mode!
...
Continue without Jitter RNG for fips to workaround alg self-tests failure,
after applying the fix:
...
[0.306633] DRBG: Continuing without Jitter RNG
[0.310550] alg: self-tests for ecdh-generic (ecdh) passed
...
Refer: https://lore.kernel.org/patchwork/patch/568693/
Signed-off-by: Hongxu Jia
---
.../0001-fips-continuing-without-Jitter-RNG.patch | 34 ++
recipes-kernel/linux/files/crypto_fips.scc | 1 +
2 files changed, 35 insertions(+)
create mode 100644
recipes-kernel/linux/files/0001-fips-continuing-without-Jitter-RNG.patch
diff --git
a/recipes-kernel/linux/files/0001-fips-continuing-without-Jitter-RNG.patch
b/recipes-kernel/linux/files/0001-fips-continuing-without-Jitter-RNG.patch
new file mode 100644
index 000..140d6a1
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-fips-continuing-without-Jitter-RNG.patch
@@ -0,0 +1,34 @@
+From fd82384acc0405ead38ea0d9712c9a1b57913c35 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia
+Date: Sun, 22 Sep 2019 10:57:02 +0800
+Subject: [PATCH] fips: continuing without Jitter RNG
+
+Continue without Jitter RNG for fips to workaround alg self-tests failure
+...
+[0.311313] alg: ecdh: test failed on vector 2, err=-14
+[0.311898] Kernel panic - not syncing: alg: self-tests for ecdh-generic
(ecdh) failed in fips mode!
+...
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia
+---
+ crypto/drbg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/crypto/drbg.c b/crypto/drbg.c
+index b6929eb..d677da5 100644
+--- a/crypto/drbg.c
b/crypto/drbg.c
+@@ -1577,7 +1577,7 @@ static int drbg_instantiate(struct drbg_state *drbg,
struct drbg_string *pers,
+ if (IS_ERR(drbg->jent)) {
+ ret = PTR_ERR(drbg->jent);
+ drbg->jent = NULL;
+- if (fips_enabled || ret != -ENOENT)
++ if (ret != -ENOENT)
+ goto free_everything;
+ pr_info("DRBG: Continuing without Jitter RNG\n");
+ }
+--
+2.7.4
+
diff --git a/recipes-kernel/linux/files/crypto_fips.scc
b/recipes-kernel/linux/files/crypto_fips.scc
index f64380a..85f8f44 100644
--- a/recipes-kernel/linux/files/crypto_fips.scc
+++ b/recipes-kernel/linux/files/crypto_fips.scc
@@ -1 +1,2 @@
kconf non-hardware crypto_fips.cfg
+patch 0001-fips-continuing-without-Jitter-RNG.patch
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH 6/16] add kernel fips mode support
A kernel compiled with CONFIG_CRYPTO_FIPS=y can be booted in fips mode
by specifying fips=1 as kernel parameter. [1][2]
/proc/sys/crypto/fips_enabled, that is presumably used by the Red Hat
modified version of OpenSSL.[3]
[1] https://www.linux.org/docs/man8/fipscheck.html
[2] https://cateee.net/lkddb/web-lkddb/CRYPTO_FIPS.html
[3] https://mta.openssl.org/pipermail/openssl-users/2017-May/005840.html
Signed-off-by: Hongxu Jia
---
classes/fips_kernel.bbclass| 4
conf/layer.conf| 4
recipes-kernel/linux/files/crypto_fips.cfg | 3 +++
recipes-kernel/linux/files/crypto_fips.scc | 1 +
4 files changed, 12 insertions(+)
create mode 100644 classes/fips_kernel.bbclass
create mode 100644 recipes-kernel/linux/files/crypto_fips.cfg
create mode 100644 recipes-kernel/linux/files/crypto_fips.scc
diff --git a/classes/fips_kernel.bbclass b/classes/fips_kernel.bbclass
new file mode 100644
index 000..064088f
--- /dev/null
+++ b/classes/fips_kernel.bbclass
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_prepend :=
"${LAYER_PATH_meta-openssl-one-zero-two-fips}/recipes-kernel/linux/files/:"
+SRC_URI_append = " \
+file://crypto_fips.scc \
+"
diff --git a/conf/layer.conf b/conf/layer.conf
index 185f422..bcf34b3 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -20,3 +20,7 @@ LAYERDEPENDS_meta-openssl-one-zero-two-fips = " \
"
IMAGE_CLASSES_append = "${@'' if d.getVar('OPENSSL_FIPS_ENABLED', True) != '1'
else ' image-enable-fips'}"
+
+LAYER_PATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}"
+
+KERNEL_CLASSES_append = " ${@bb.utils.contains('OPENSSL_FIPS_ENABLED', '1', '
fips_kernel', '',d)}"
diff --git a/recipes-kernel/linux/files/crypto_fips.cfg
b/recipes-kernel/linux/files/crypto_fips.cfg
new file mode 100644
index 000..cffdc02
--- /dev/null
+++ b/recipes-kernel/linux/files/crypto_fips.cfg
@@ -0,0 +1,3 @@
+CONFIG_CRYPTO_FIPS=y
+CONFIG_MODULE_SIG=y
+# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
diff --git a/recipes-kernel/linux/files/crypto_fips.scc
b/recipes-kernel/linux/files/crypto_fips.scc
new file mode 100644
index 000..f64380a
--- /dev/null
+++ b/recipes-kernel/linux/files/crypto_fips.scc
@@ -0,0 +1 @@
+kconf non-hardware crypto_fips.cfg
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH V2 2/16] openssh_8.%.bbappend: support fips 140-2
Port openssh-7.7p1-fips.patch from Fedora https://src.fedoraproject.org/rpms/openssh.git (as of commit 0ca1614ae221578b6b57c61d18fda6cc970a19ce) Signed-off-by: Hongxu Jia --- .../openssh/openssh/0001-openssh-8.0p1-fips.patch | 529 + recipes-connectivity/openssh/openssh_8.%.bbappend | 4 + recipes-connectivity/openssh/openssh_fips.inc | 8 + 3 files changed, 541 insertions(+) create mode 100644 recipes-connectivity/openssh/openssh/0001-openssh-8.0p1-fips.patch create mode 100644 recipes-connectivity/openssh/openssh_8.%.bbappend create mode 100644 recipes-connectivity/openssh/openssh_fips.inc diff --git a/recipes-connectivity/openssh/openssh/0001-openssh-8.0p1-fips.patch b/recipes-connectivity/openssh/openssh/0001-openssh-8.0p1-fips.patch new file mode 100644 index 000..a4b5836 --- /dev/null +++ b/recipes-connectivity/openssh/openssh/0001-openssh-8.0p1-fips.patch @@ -0,0 +1,529 @@ +From 255e5dcdec36df7222f69b253dfc05be63927ed2 Mon Sep 17 00:00:00 2001 +From: Hongxu Jia +Date: Fri, 20 Sep 2019 17:59:00 +0800 +Subject: [PATCH] openssh 8.0p1 fips + +Port openssh-7.7p1-fips.patch from Fedora +https://src.fedoraproject.org/rpms/openssh.git +(as of commit 0ca1614ae221578b6b57c61d18fda6cc970a19ce) + +Upstream-Status: Inappropriate [oe specific] + +Signed-off-by: Hongxu Jia +--- + Makefile.in | 14 +++--- + cipher-ctr.c | 3 ++- + clientloop.c | 3 ++- + dh.c | 40 + dh.h | 1 + + kex.c| 5 - + kexgexc.c| 5 + + myproposal.h | 40 + readconf.c | 17 + + sandbox-seccomp-filter.c | 3 +++ + servconf.c | 19 ++- + ssh-keygen.c | 6 ++ + ssh.c| 16 + sshconnect2.c| 11 --- + sshd.c | 19 +++ + sshkey.c | 4 + 16 files changed, 176 insertions(+), 30 deletions(-) + +diff --git a/Makefile.in b/Makefile.in +index 6f001bb..ddd1804 100644 +--- a/Makefile.in b/Makefile.in +@@ -170,31 +170,31 @@ libssh.a: $(LIBSSH_OBJS) + $(RANLIB) $@ + + ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS) +- $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHLIBS) $(LIBS) $(GSSLIBS) ++ $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck $(SSHLIBS) $(LIBS) $(GSSLIBS) + + sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS) +- $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHDLIBS) $(LIBS) $(GSSLIBS) $(K5LIBS) ++ $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck $(SSHDLIBS) $(LIBS) $(GSSLIBS) $(K5LIBS) + + scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o + $(LD) -o $@ scp.o progressmeter.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) + + ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o +- $(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ++ $(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck $(LIBS) + + ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o ssh-pkcs11-client.o +- $(LD) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ++ $(LD) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck $(LIBS) + + ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o +- $(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ++ $(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck $(LIBS) + + ssh-keysign$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keysign.o readconf.o uidswap.o compat.o +- $(LD) -o $@ ssh-keysign.o readconf.o uidswap.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ++ $(LD) -o $@ ssh-keysign.o readconf.o uidswap.o $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck $(LIBS) + + ssh-pkcs11-helper$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-pkcs11-helper.o ssh-pkcs11.o + $(LD) -o $@ ssh-pkcs11-helper.o ssh-pkcs11.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS) + + ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o +- $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS) ++ $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lfipscheck $(LIBS) + + sftp-server$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-common.o sftp-server.o sftp-server-main.o + $(LD) -o $@ sftp-server.o sftp-common.o sftp-server-main.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) +diff --git a/cipher-ctr.c b/cipher-ctr.c +index 32771f2..74fac3b 100644 +--- a/cipher-ctr.c b/cipher-ctr.c +@@ -138,7 +138,8 @@ evp_aes_128_ctr(void) + aes_ctr.do_cipher = ssh_aes_ctr; + #ifndef SSH_OLD_EVP + aes_ctr.flags = EVP_CIPH_CBC_MODE | EVP_CIPH_VARIABLE_LENGTH | +-
[yocto] [meta-openssl102-fips][PATCH V2 1/16] fipscheck: add 1.5.0
Port it from fedora:
https://src.fedoraproject.org/rpms/fipscheck
(as of commit 7e44bec705fb2b3263734f30a05c2245738cf01a)
It is required by openssh fips.
Signed-off-by: Hongxu Jia
---
.../0001-compat-fip-with-openssl-1.0.2.patch | 34 ++
recipes-support/fipscheck/fipscheck_1.5.0.bb | 30 +++
templates/feature/openssl-fips/template.conf | 2 +-
3 files changed, 65 insertions(+), 1 deletion(-)
create mode 100644
recipes-support/fipscheck/fipscheck/0001-compat-fip-with-openssl-1.0.2.patch
create mode 100644 recipes-support/fipscheck/fipscheck_1.5.0.bb
diff --git
a/recipes-support/fipscheck/fipscheck/0001-compat-fip-with-openssl-1.0.2.patch
b/recipes-support/fipscheck/fipscheck/0001-compat-fip-with-openssl-1.0.2.patch
new file mode 100644
index 000..22e5a62
--- /dev/null
+++
b/recipes-support/fipscheck/fipscheck/0001-compat-fip-with-openssl-1.0.2.patch
@@ -0,0 +1,34 @@
+From 3147ae2a63f10f9bbdd0a617b450ff8b9868e60f Mon Sep 17 00:00:00 2001
+From: Hongxu Jia
+Date: Fri, 20 Sep 2019 17:51:09 +0800
+Subject: [PATCH] compat fip with openssl 1.0.2
+
+In /usr/lib64/ssl/fips-2.0/include/openssl/opensslv.h
+...
+define OPENSSL_VERSION_NUMBER 0x1010L
+...
+Since fips include file compat with openssl 1.1.0, do not include it
+in Yocto
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia
+---
+ src/filehmac.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/src/filehmac.c b/src/filehmac.c
+index a8eef00..0b36cec 100644
+--- a/src/filehmac.c
b/src/filehmac.c
+@@ -41,7 +41,6 @@
+ #include
+
+ #if defined(WITH_OPENSSL)
+-#include
+ #include
+ #include
+ #elif defined(WITH_NSS)
+--
+2.7.4
+
diff --git a/recipes-support/fipscheck/fipscheck_1.5.0.bb
b/recipes-support/fipscheck/fipscheck_1.5.0.bb
new file mode 100644
index 000..68051d2
--- /dev/null
+++ b/recipes-support/fipscheck/fipscheck_1.5.0.bb
@@ -0,0 +1,30 @@
+SUMMARY = "A library for integrity verification of FIPS validated modules"
+DESCRIPTION = "FIPSCheck is a library for integrity verification of FIPS
validated \
+modules. The package also provides helper binaries for creation and \
+verification of the HMAC-SHA256 checksum files."
+HOMEPAGE = "https://pagure.io/fipscheck;
+SECTION = "libs/network"
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=35f2904ce138ac5fa63e7cedf96bbedf"
+
+SRC_URI = "https://releases.pagure.org/fipscheck/${BPN}-${PV}.tar.bz2 \
+ file://0001-compat-fip-with-openssl-1.0.2.patch \
+"
+SRC_URI[md5sum] = "86e756a7d2aa15f3f91033fb3eced99b"
+SRC_URI[sha256sum] =
"7ba38100ced187f44b12dd52c8c74db8f366a2a8b9da819bd3e7c6ea17f469d5"
+
+DEPENDS = " \
+openssl \
+openssl-fips \
+"
+
+inherit autotools pkgconfig
+
+EXTRA_OECONF += " \
+--disable-static \
+"
+EXTRA_OEMAKE += " \
+-I${STAGING_LIBDIR_NATIVE}/ssl/fips-2.0/include \
+"
+
diff --git a/templates/feature/openssl-fips/template.conf
b/templates/feature/openssl-fips/template.conf
index 6da678c..9a551c3 100644
--- a/templates/feature/openssl-fips/template.conf
+++ b/templates/feature/openssl-fips/template.conf
@@ -8,4 +8,4 @@ OPENSSL_FIPS_PREBUILT ??= ""
PNWHITELIST_meta-openssl-one-zero-two-fips += 'openssl-fips'
PNWHITELIST_meta-openssl-one-zero-two-fips += 'openssl-fips-example'
-
+PNWHITELIST_meta-openssl-one-zero-two-fips += 'fipscheck'
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Review request V2 0/16: [meta-openssl102-fips] Enable FIPS mode in Kernel and OpenSSH
Changed in V1: - Follow Mark H's suggestions Hi Mark, Once openssh enables FIPS mode, openssh ptest will fail (mess of failure). It seems the test case of upstream openssh does not consider FIPS mode support. I search fedora, there is nothing about openssh `regress'(test suits) in FIPS mode support So I do not add additional cavs test to the ptest, just add a note to README.enable_fips //Hongxu == Comments (indicate scope for each "y" above) == * Git logs [meta-openssl102-fips] commit 38849c1c52ae04eb2a3931624cd2d1446ab389d6 Author: Hongxu Jia Date: Wed Sep 25 15:03:24 2019 +0800 README.enable_fips: openssh ptest failed in fips mode Signed-off-by: Hongxu Jia commit f5b8a66c226541e73cc509a73452bbafc59f2555 Author: Hongxu Jia Date: Sun Sep 22 22:40:56 2019 +0800 README.openssh_cavstest: add CAVS tests for FIPS validation Signed-off-by: Hongxu Jia commit bd5de039c60fd2ab89f7925d3801520d742ba09a Author: Hongxu Jia Date: Sun Sep 22 21:54:41 2019 +0800 openssh: add CAVS tests for FIPS validation Refer the latest Fedora to add cavs test binary for the aes-ctr [1] and SSH KDF CAVS test driver [2] [1] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.6p1-ctr-cavstest.patch [2] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.7p1-kdf-cavs.patch (as of commit 0ca1614ae221578b6b57c61d18fda6cc970a19ce) Signed-off-by: Hongxu Jia commit b40cef8f89461342da5c6a621d95cdb19a4d8cff Author: Hongxu Jia Date: Sun Sep 22 20:55:30 2019 +0800 README.enable_fips: add steps to turn system (kernel and user space) into FIPS mode Refer RedHat/Fedora/SUSE/Oracle/IBM ways 1. Add `fips=1' to kernel option to enable FIPS mode in kernel 2. File /etc/system-fips to determine if a FIPS mode is enabled in user space, currently openssh only Refer: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-federal_standards_and_regulations-federal_information_processing_standard https://access.redhat.com/discussions/3293631 https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20131007/1124363.html https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lgdd/lgdd_r_fipsparm.html https://support.oracle.com/knowledge/Oracle%20Linux%20and%20Virtualization/2323738_1.html Signed-off-by: Hongxu Jia commit a4e3e55688b7a3666bcec95c342dab7984e7e0a3 Author: Hongxu Jia Date: Sun Sep 22 19:27:45 2019 +0800 rng-tools: fix rngd failed in fips mode The FIPS test is something done on government or more secure organizations for extra security check. ... root@qemux86-64:~# systemctl status rngd Unit rngd-tools.service could not be found. root@qemux86-64:~# systemctl status rngd rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2019-09-22 11:10:41 UTC; 18min ago Process: 317 ExecStart=/usr/sbin/rngd -f $EXTRA_ARGS (code=exited, status=0/SUCCESS) Main PID: 317 (code=exited, status=0/SUCCESS) Sep 22 11:10:37 qemux86-64 rngd[317]: RNDADDENTROPY failed: Operation not permitted Sep 22 11:10:37 qemux86-64 rngd[317]: RNDADDENTROPY failed: Operation not permitted Sep 22 11:10:37 qemux86-64 rngd[317]: too many FIPS failures, disabling entropy source ... From rngd manual, add `-i' to default ... -i, --ignorefail Ignore repeated fips failures ... After applying the fix ... rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2019-09-22 12:18:31 UTC; 4min 35s ago Main PID: 121 (rngd) Tasks: 2 Memory: 1.8M CGroup: /system.slice/rngd.service /usr/sbin/rngd -f -r /dev/hwrng -i Sep 22 12:23:06 qemux86-64 rngd[121]: RNDADDENTROPY failed: Operation not permitted ... Refer: https://www.unix.com/unix-for-advanced-and-expert-users/265510-rngd-failed-fips-test.html Signed-off-by: Hongxu Jia commit c3224883bec9155fb51686a908c59da31d9918f5 Author: Hongxu Jia Date: Sun Sep 22 19:27:01 2019 +0800 rng-tools bbappend: port a copy of default from oe-core Port it at the following commit in oe-core http://cgit.openembedded.org/openembedded-core/commit/?id=16ced1a253c74c01ca414db2f1a010c083213b91 Signed-off-by: Hongxu Jia commit aecc01c2e49825dcb2a78875e0562028b2636fab Author: Hongxu Jia Date: Sun Sep 22 18:48:08 2019 +0800 openssh/sshd_check_keys: don't generate ED25519 host keys in FIPS mode Run sshd_check_keys failed: ... 2019-09-22T09:59:10.878738+00:00 qemux86-64
[yocto] [meta-openssl102-fips][PATCH V2 4/16] classes/image-enable-fips.bbclass: enable user space fips mode in image
Refer Fedora/RedHat's way
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.5_technical_notes/dracut
To enable user space fips mode in the image recipe as part of an
'IMAGE_CLASSES'. Basically if FIPS-140-2 is enabled, then we can
touch the file as a post image generation activity.
Signed-off-by: Hongxu Jia
---
classes/image-enable-fips.bbclass | 5 +
conf/layer.conf | 2 ++
2 files changed, 7 insertions(+)
create mode 100644 classes/image-enable-fips.bbclass
diff --git a/classes/image-enable-fips.bbclass
b/classes/image-enable-fips.bbclass
new file mode 100644
index 000..10cc1bd
--- /dev/null
+++ b/classes/image-enable-fips.bbclass
@@ -0,0 +1,5 @@
+RPM_POSTPROCESS_COMMANDS_append = "enable_system_fips;"
+enable_system_fips() {
+install -d ${IMAGE_ROOTFS}${sysconfdir}
+touch ${IMAGE_ROOTFS}${sysconfdir}/system-fips
+}
diff --git a/conf/layer.conf b/conf/layer.conf
index 27a872e..185f422 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -18,3 +18,5 @@ LAYERDEPENDS_meta-openssl-one-zero-two-fips = " \
meta-openssl-one-zero-two \
wr-template \
"
+
+IMAGE_CLASSES_append = "${@'' if d.getVar('OPENSSL_FIPS_ENABLED', True) != '1'
else ' image-enable-fips'}"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-openssl102-fips][PATCH V2 3/16] fipscheck: add generation of the checksums in pkg_postinst
Refer https://pagure.io/fipscheck/c/489bc3ab3f73707e12b6c2644d80af5ff6fbbf70
(* fipscheck.spec.in: Add generation of the checksums in __spec_install_post.)
Signed-off-by: Hongxu Jia
---
recipes-support/fipscheck/fipscheck_1.5.0.bb | 22 ++
1 file changed, 22 insertions(+)
diff --git a/recipes-support/fipscheck/fipscheck_1.5.0.bb
b/recipes-support/fipscheck/fipscheck_1.5.0.bb
index 68051d2..9faed9c 100644
--- a/recipes-support/fipscheck/fipscheck_1.5.0.bb
+++ b/recipes-support/fipscheck/fipscheck_1.5.0.bb
@@ -27,4 +27,26 @@ EXTRA_OECONF += " \
EXTRA_OEMAKE += " \
-I${STAGING_LIBDIR_NATIVE}/ssl/fips-2.0/include \
"
+do_install_append() {
+install -d ${D}${libdir}/fipscheck
+}
+inherit qemu
+
+pkg_postinst_${PN} () {
+if [ -n "$D" ]; then
+if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode',
'true','false', d)}; then
+${@qemu_run_binary(d, '$D', '${bindir}/fipshmac')} \
+-d $D${libdir}/fipscheck $D${bindir}/fipscheck
$D${libdir}/libfipscheck.so.1.2.1 && \
+ln -s libfipscheck.so.1.2.1.hmac
$D${libdir}/fipscheck/libfipscheck.so.1.hmac
+else
+$INTERCEPT_DIR/postinst_intercept delay_to_first_boot ${PKG}
mlprefix=${MLPREFIX}
+fi
+else
+${bindir}/fipshmac -d ${libdir}/fipscheck ${bindir}/fipscheck \
+${libdir}/libfipscheck.so.1.2.1 && \
+ln -s libfipscheck.so.1.2.1.hmac
${libdir}/fipscheck/libfipscheck.so.1.hmac
+fi
+}
+
+FILES_${PN} += "${libdir}/fipscheck"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Nothing PROVIDES 'python3-dev'
Kiitos Jussi!
That solved it.
I had DEPENDS += "python3-dev" and RDEPENDS += "libpython3"
now
I have DEPENDS += "python3" and RDEPENDS += "libpython3"
I'll check if libpython3 is implicit when the image builds.
Cheers,
-Damien
On Wed, Sep 25, 2019 at 10:00 AM Jussi Kukkonen wrote:
>
>
> On Wed, 25 Sep 2019 at 09:16, Damien LEFEVRE wrote:
>
>> > On 24/09/2019 10:36, Damien LEFEVRE wrote:
>> > > Hi,
>> > >
>> > > Migrating from poky:pyro to poky:warrior.
>> > >
>> > > It looks like the python3-dev package is generated from
>> > > python3-manifest.json:
>> > >
>> > > ? ? "dev": {
>> > > ? ? ? ? "cached": [],
>> > > ? ? ? ? "files": [
>> > > ? ? ? ? ? ? "${base_libdir}/*.a",
>> > > ? ? ? ? ? ? "${base_libdir}/*.o",
>> > > ? ? ? ? ? ? "${bindir}/python*-config",
>> > > ? ? ? ? ? ? "${datadir}/aclocal",
>> > > ? ? ? ? ? ? "${datadir}/pkgconfig",
>> > > ? ? ? ? ? ? "${includedir}",
>> > > ? ? ? ? ? ? "${libdir}/*.a",
>> > > ? ? ? ? ? ? "${libdir}/*.la",
>> > > ? ? ? ? ? ? "${libdir}/*.o",
>> > > ? ? ? ? ? ? "${libdir}/lib*${SOLIBSDEV}",
>> > > ? ? ? ? ? ? "${libdir}/pkgconfig"
>> > > ? ? ? ? ],
>> > > ? ? ? ? "rdepends": [
>> > > ? ? ? ? ? ? "core"
>> > > ? ? ? ? ],
>> > > ? ? ? ? "summary": "Python development package"
>> > > ? ? },
>> > >
>> > > and this is used in python3_3.7.2.bb .
>> > >
>> > > Still I get this error: Nothing PROVIDES 'python3-dev'
>> >
>> > Are you trying to 'bitbake python3-dev'? You bitbake a recipe, not a
>> > package, so 'bitbake python3'.
>> >
>> > Ross
>>
>> Hi Ross,
>>
>> The issue is with the python3 recipe. It declares RDEPENDS_python3-dev,
>> not DEPENDS_python3-dev.
>>
>
>> I'm using the Python C API. So I need headers and so lib files at build
>> time but only so lib at runtime.
>>
>
> DEPENDing on python3 should give you the former (headers etc in sysroot at
> build time) and RDEPENDing on the correct package (maybe libpython3?)
> should give you the latter -- but RDEPENDS should be automatic if your app
> links to the library.
>
> Is this not working?
>
>
>
>>
>> I can add python3-dev to my recipe's RDEPENDS list, but bitbake
>> rightfully complains about installing -dev files to the image.
>>
>> I'll check today how to fix that.
>>
>> -Damien
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Nothing PROVIDES 'python3-dev'
On Wed, 25 Sep 2019 at 09:16, Damien LEFEVRE wrote:
> > On 24/09/2019 10:36, Damien LEFEVRE wrote:
> > > Hi,
> > >
> > > Migrating from poky:pyro to poky:warrior.
> > >
> > > It looks like the python3-dev package is generated from
> > > python3-manifest.json:
> > >
> > > ? ? "dev": {
> > > ? ? ? ? "cached": [],
> > > ? ? ? ? "files": [
> > > ? ? ? ? ? ? "${base_libdir}/*.a",
> > > ? ? ? ? ? ? "${base_libdir}/*.o",
> > > ? ? ? ? ? ? "${bindir}/python*-config",
> > > ? ? ? ? ? ? "${datadir}/aclocal",
> > > ? ? ? ? ? ? "${datadir}/pkgconfig",
> > > ? ? ? ? ? ? "${includedir}",
> > > ? ? ? ? ? ? "${libdir}/*.a",
> > > ? ? ? ? ? ? "${libdir}/*.la",
> > > ? ? ? ? ? ? "${libdir}/*.o",
> > > ? ? ? ? ? ? "${libdir}/lib*${SOLIBSDEV}",
> > > ? ? ? ? ? ? "${libdir}/pkgconfig"
> > > ? ? ? ? ],
> > > ? ? ? ? "rdepends": [
> > > ? ? ? ? ? ? "core"
> > > ? ? ? ? ],
> > > ? ? ? ? "summary": "Python development package"
> > > ? ? },
> > >
> > > and this is used in python3_3.7.2.bb .
> > >
> > > Still I get this error: Nothing PROVIDES 'python3-dev'
> >
> > Are you trying to 'bitbake python3-dev'? You bitbake a recipe, not a
> > package, so 'bitbake python3'.
> >
> > Ross
>
> Hi Ross,
>
> The issue is with the python3 recipe. It declares RDEPENDS_python3-dev,
> not DEPENDS_python3-dev.
>
> I'm using the Python C API. So I need headers and so lib files at build
> time but only so lib at runtime.
>
DEPENDing on python3 should give you the former (headers etc in sysroot at
build time) and RDEPENDing on the correct package (maybe libpython3?)
should give you the latter -- but RDEPENDS should be automatic if your app
links to the library.
Is this not working?
>
> I can add python3-dev to my recipe's RDEPENDS list, but bitbake rightfully
> complains about installing -dev files to the image.
>
> I'll check today how to fix that.
>
> -Damien
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/3] patches for zynq7000
On 9/25/19 1:34 PM, Michal Simek wrote: On 25. 09. 19 0:16, Bruce Ashfield wrote: In message: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 0/3] patches for zynq7000 on 23/09/2019 quanyang.w...@windriver.com wrote: From: Quanyang Wang Hi Bruce, Would you please help merge these patches to linux-yocto v5.2/standard/xlnx-soc branch? These are now merged. Are these changes already done upstream, or applicable to upstream ? I just want to make sure we aren't only fixes these in the yocto kernel when there are other places that we can fix as well. We don't have this in mainline or xilinx kernel simply because none has asked for it. I am completely missing any manual/description how this should be tested but I expect this is based on mainline binding. Hi Bruce & Michal, 1. The patch "ARM: dts: zc702: Fix I2C bus warnings" fix some dtb building warnings. And this warnings will not happen in SDK (v4.19) and upstream. Because dtc in SDK not check this and in upstream the zynq-zc702 dts file is in correct format. This patch is needed only because I apply SDK patch to v5.2 kernel. 2. The patch "mmc: sdhci-of-arasan: Fix the incorrect soft reset operation when runtime resuming" is also because that SDK patch use old function API and v5.2.16 use a new one. 3. The patch "arm: dts: zynq: enablement of coresight topology" is for coresight. It is not mature now and I only simply verify it by using ptm2human, but will need more test on this patch. Thanks, Quanyang Thanks, Michal -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Nothing PROVIDES 'python3-dev'
> On 24/09/2019 10:36, Damien LEFEVRE wrote:
> > Hi,
> >
> > Migrating from poky:pyro to poky:warrior.
> >
> > It looks like the python3-dev package is generated from
> > python3-manifest.json:
> >
> > ? ? "dev": {
> > ? ? ? ? "cached": [],
> > ? ? ? ? "files": [
> > ? ? ? ? ? ? "${base_libdir}/*.a",
> > ? ? ? ? ? ? "${base_libdir}/*.o",
> > ? ? ? ? ? ? "${bindir}/python*-config",
> > ? ? ? ? ? ? "${datadir}/aclocal",
> > ? ? ? ? ? ? "${datadir}/pkgconfig",
> > ? ? ? ? ? ? "${includedir}",
> > ? ? ? ? ? ? "${libdir}/*.a",
> > ? ? ? ? ? ? "${libdir}/*.la",
> > ? ? ? ? ? ? "${libdir}/*.o",
> > ? ? ? ? ? ? "${libdir}/lib*${SOLIBSDEV}",
> > ? ? ? ? ? ? "${libdir}/pkgconfig"
> > ? ? ? ? ],
> > ? ? ? ? "rdepends": [
> > ? ? ? ? ? ? "core"
> > ? ? ? ? ],
> > ? ? ? ? "summary": "Python development package"
> > ? ? },
> >
> > and this is used in python3_3.7.2.bb .
> >
> > Still I get this error: Nothing PROVIDES 'python3-dev'
>
> Are you trying to 'bitbake python3-dev'? You bitbake a recipe, not a
> package, so 'bitbake python3'.
>
> Ross
Hi Ross,
The issue is with the python3 recipe. It declares RDEPENDS_python3-dev, not
DEPENDS_python3-dev.
I'm using the Python C API. So I need headers and so lib files at build
time but only so lib at runtime.
I can add python3-dev to my recipe's RDEPENDS list, but bitbake rightfully
complains about installing -dev files to the image.
I'll check today how to fix that.
-Damien
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
