CONFIG_FIPS without module loading support?

CONFIG_FIPS without module loading support?

[NTU]

Hello,

CRYPTO_FIPS depends on MODULE_SIG and I understand why it would as you
wouldn't want unsigned modules from external sources being loaded. If
CONFIG_MODULES is disabled though (no module loading) there are no
modules to sign in the first place.

Wouldn't it make more sense for CONFIG_FIPS to depend on (MODULE_SIG
[=y] && CONFIG_MODULES [y]) ?

Thank you!

Alec Ari

Re: CONFIG_FIPS without module loading support?

[Stephan Mueller]

Am Mittwoch, 31. August 2016, 20:32:42 CEST schrieb NTU:

Hi NTU,

> Hello,
> 
> CRYPTO_FIPS depends on MODULE_SIG and I understand why it would as you
> wouldn't want unsigned modules from external sources being loaded. If
> CONFIG_MODULES is disabled though (no module loading) there are no
> modules to sign in the first place.
> 
> Wouldn't it make more sense for CONFIG_FIPS to depend on (MODULE_SIG
> [=y] && CONFIG_MODULES [y]) ?
> 
> Thank you!

Yes, that is correct.
> 
> Alec Ari
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



Ciao
Stephan

Re: CONFIG_FIPS without module loading support?

[NTU]

Ok, can we merge that in?

Alec Ari

Re: CONFIG_FIPS without module loading support?

[Herbert Xu]

NTU <neotheuser@gmail.com> wrote:
> Ok, can we merge that in?

We can if you send us a patch :)
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: CONFIG_FIPS without module loading support?

[NTU]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Hello,

I've never written a patch before to the official kernel mailing list
(that I remember) so please forgive me if I didn't send this in
properly. I've generated this using git format-patch HEAD~ --stdout &>
kconfig_fix_for_fips.patch and have attached the file in this email,
gathering as much as I could from the Documentation/SubmittingPatches
page.

Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
must be enabled if FIPS is selected, but in the dependencies for FIPS,
if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
enabled. Which one is true?

Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
more of the DRBG types must be selected. If this is indeed true,
shouldn't the options within CRYPTO_DRBG_MENU be converted to
choice/endchoice versus just booleans? One selection for
CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
for both? Should I submit patches for these as well,
feedback/thoughts?

Thank you!

Alec Ari

[-- Attachment #2: kconfig_fix_for_fips.patch --]
[-- Type: text/x-patch, Size: 1029 bytes --]

From 3f6b786edef09042ff78bc7b4d61fc5a8f8cf657 Mon Sep 17 00:00:00 2001
From: Alec Ari <neotheuser@gmail.com>
Date: Wed, 14 Sep 2016 18:52:04 -0500
Subject: [PATCH] Fix Kconfig dependencies for FIPS

Currently FIPS depends on MODULE_SIG, even if MODULES is disabled.
This change allows the enabling of FIPS without support for modules.

If module loading support is enabled, only then does
FIPS require MODULE_SIG.

Signed-off-by: Alec Ari <neotheuser@gmail.com>
---
 crypto/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 84d7148..fd28805 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -24,7 +24,7 @@ comment "Crypto core or helper"
 config CRYPTO_FIPS
 	bool "FIPS 200 compliance"
 	depends on (CRYPTO_ANSI_CPRNG || CRYPTO_DRBG) && !CRYPTO_MANAGER_DISABLE_TESTS
-	depends on MODULE_SIG
+	depends on (MODULE_SIG || !MODULES)
 	help
 	  This options enables the fips boot option which is
 	  required if you want to system to operate in a FIPS 200
-- 
2.7.3

Re: CONFIG_FIPS without module loading support?

[Stephan Mueller]

Am Mittwoch, 14. September 2016, 19:18:43 CEST schrieb NTU:

Hi NTU,

> Hello,
> 
> I've never written a patch before to the official kernel mailing list
> (that I remember) so please forgive me if I didn't send this in
> properly. I've generated this using git format-patch HEAD~ --stdout &>
> kconfig_fix_for_fips.patch and have attached the file in this email,
> gathering as much as I could from the Documentation/SubmittingPatches
> page.

Please read Documentation/SubmittingPatches
> 
> Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
> must be enabled if FIPS is selected, but in the dependencies for FIPS,
> if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
> enabled. Which one is true?

The latter one. The X9.31 DRNG is not approved in FIPS mode any more.
> 
> Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
> more of the DRBG types must be selected. If this is indeed true,
> shouldn't the options within CRYPTO_DRBG_MENU be converted to
> choice/endchoice versus just booleans? One selection for
> CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
> for both? Should I submit patches for these as well,
> feedback/thoughts?

Not sure what you want to gain from it. All that the booleans do is to mark 
which types of DRBG are to be compliled. The selector whether the DRBG is 
compiled at all is CRYPTO_DRBG.

Ciao
Stephan

Re: CONFIG_FIPS without module loading support?

[NTU]

What did I miss from the SubmittingPatches page? Some constructive
criticism please? Step 1 is skipped due to the fact I'm using git,
patch is in proper form. Step 2, I described the patch. 3, it's one
line, so it cannot be separated. Step 4, checkpatch.pl says it's good.
The section in 5 confused me a little bit. 6, the patch is plain text.
7, it is under 300k (easily.) 8, doing it right now. 9, ok. 10, PATCH
is included in the subject. 11, it is signed, says signed off at the
bottom of the comment section. 12 I don't think is applicable to this?
13, not applicable again? 14, it is in canonical format, comment lines
do not exceed 70 characters, it has a marker line, diff output etc. 15
confused me a little. 16 it is not a series of patches.

If ANSI_CPRNG is not approved anymore for FIPS, the help section
should be updated then.

As for converting the DRBG booleans to choice, it is so that way users
cannot have both options disabled, in the case they don't read the
help for it.

Alec

On Wed, Sep 14, 2016 at 11:58 PM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Mittwoch, 14. September 2016, 19:18:43 CEST schrieb NTU:
>
> Hi NTU,
>
>> Hello,
>>
>> I've never written a patch before to the official kernel mailing list
>> (that I remember) so please forgive me if I didn't send this in
>> properly. I've generated this using git format-patch HEAD~ --stdout &>
>> kconfig_fix_for_fips.patch and have attached the file in this email,
>> gathering as much as I could from the Documentation/SubmittingPatches
>> page.
>
> Please read Documentation/SubmittingPatches
>>
>> Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
>> must be enabled if FIPS is selected, but in the dependencies for FIPS,
>> if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
>> enabled. Which one is true?
>
> The latter one. The X9.31 DRNG is not approved in FIPS mode any more.
>>
>> Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
>> more of the DRBG types must be selected. If this is indeed true,
>> shouldn't the options within CRYPTO_DRBG_MENU be converted to
>> choice/endchoice versus just booleans? One selection for
>> CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
>> for both? Should I submit patches for these as well,
>> feedback/thoughts?
>
> Not sure what you want to gain from it. All that the booleans do is to mark
> which types of DRBG are to be compliled. The selector whether the DRBG is
> compiled at all is CRYPTO_DRBG.
>
> Ciao
> Stephan

Re: CONFIG_FIPS without module loading support?

[Stephan Mueller]

Am Donnerstag, 15. September 2016, 12:06:20 CEST schrieb NTU:

Hi NTU,

> What did I miss from the SubmittingPatches page? Some constructive

The patch should be inline to the email -- see all other patch submissions. 
Then, the email subject should be appropriate.

> criticism please? Step 1 is skipped due to the fact I'm using git,
> patch is in proper form. Step 2, I described the patch. 3, it's one
> line, so it cannot be separated. Step 4, checkpatch.pl says it's good.
> The section in 5 confused me a little bit. 6, the patch is plain text.
> 7, it is under 300k (easily.) 8, doing it right now. 9, ok. 10, PATCH
> is included in the subject. 11, it is signed, says signed off at the
> bottom of the comment section. 12 I don't think is applicable to this?
> 13, not applicable again? 14, it is in canonical format, comment lines
> do not exceed 70 characters, it has a marker line, diff output etc. 15
> confused me a little. 16 it is not a series of patches.
> 
> If ANSI_CPRNG is not approved anymore for FIPS, the help section
> should be updated then.
> 
> As for converting the DRBG booleans to choice, it is so that way users
> cannot have both options disabled, in the case they don't read the
> help for it.
> 
> Alec
> 
> On Wed, Sep 14, 2016 at 11:58 PM, Stephan Mueller <smueller@chronox.de> 
wrote:
> > Am Mittwoch, 14. September 2016, 19:18:43 CEST schrieb NTU:
> > 
> > Hi NTU,
> > 
> >> Hello,
> >> 
> >> I've never written a patch before to the official kernel mailing list
> >> (that I remember) so please forgive me if I didn't send this in
> >> properly. I've generated this using git format-patch HEAD~ --stdout &>
> >> kconfig_fix_for_fips.patch and have attached the file in this email,
> >> gathering as much as I could from the Documentation/SubmittingPatches
> >> page.
> > 
> > Please read Documentation/SubmittingPatches
> > 
> >> Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
> >> must be enabled if FIPS is selected, but in the dependencies for FIPS,
> >> if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
> >> enabled. Which one is true?
> > 
> > The latter one. The X9.31 DRNG is not approved in FIPS mode any more.
> > 
> >> Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
> >> more of the DRBG types must be selected. If this is indeed true,
> >> shouldn't the options within CRYPTO_DRBG_MENU be converted to
> >> choice/endchoice versus just booleans? One selection for
> >> CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
> >> for both? Should I submit patches for these as well,
> >> feedback/thoughts?
> > 
> > Not sure what you want to gain from it. All that the booleans do is to
> > mark
> > which types of DRBG are to be compliled. The selector whether the DRBG is
> > compiled at all is CRYPTO_DRBG.
> > 
> > Ciao
> > Stephan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



Ciao
Stephan