by kernel test robot

[permalink] [raw]

Subject: Re: [PATCH v43 05/15] LRNG - CPU entropy source

Hi "Stephan,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on herbert-cryptodev-2.6/master herbert-crypto-2.6/master v5.16-rc2 next-20211118]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url: https://github.com/0day-ci/linux/commits/Stephan-M-ller/dev-random-a-new-approach/20211122-005114
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git f4d77525679e289d4976ca03b620ac4cc5403205
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/4db9c892c1827b896be5479eeb9cc4ac0d0a87b5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Stephan-M-ller/dev-random-a-new-approach/20211122-005114
git checkout 4db9c892c1827b896be5479eeb9cc4ac0d0a87b5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross ARCH=alpha

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>

All warnings (new ones prefixed by >>):

>> drivers/char/lrng/lrng_es_archrandom.c:81:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
81 | static u32 inline lrng_get_arch_data_compress(u8 *outbuf, u32 requested_bits,
| ^~~~~~

vim +/inline +81 drivers/char/lrng/lrng_es_archrandom.c

80
> 81 static u32 inline lrng_get_arch_data_compress(u8 *outbuf, u32 requested_bits,
82 u32 data_multiplier)
83 {
84 SHASH_DESC_ON_STACK(shash, NULL);
85 const struct lrng_crypto_cb *crypto_cb;
86 struct lrng_drng *drng = lrng_drng_init_instance();
87 unsigned long flags;
88 u32 ent_bits = 0, i, partial_bits = 0,
89 full_bits = requested_bits * data_multiplier;
90 void *hash;
91
92 /* Calculate oversampling for SP800-90C */
93 if (lrng_sp80090c_compliant()) {
94 /* Complete amount of bits to be pulled */
95 full_bits += CONFIG_LRNG_OVERSAMPLE_ES_BITS * data_multiplier;
96 /* Full blocks that will be pulled */
97 data_multiplier = full_bits / requested_bits;
98 /* Partial block in bits to be pulled */
99 partial_bits = full_bits - (data_multiplier * requested_bits);
100 }
101
102 lrng_hash_lock(drng, &flags);
103 crypto_cb = drng->crypto_cb;
104 hash = drng->hash;
105
106 if (crypto_cb->lrng_hash_init(shash, hash))
107 goto out;
108
109 /* Hash all data from the CPU entropy source */
110 for (i = 0; i < data_multiplier; i++) {
111 ent_bits = lrng_get_arch_data(outbuf, requested_bits);
112 if (!ent_bits)
113 goto out;
114
115 if (crypto_cb->lrng_hash_update(shash, outbuf, ent_bits >> 3))
116 goto err;
117 }
118
119 /* Hash partial block, if applicable */
120 ent_bits = lrng_get_arch_data(outbuf, partial_bits);
121 if (ent_bits &&
122 crypto_cb->lrng_hash_update(shash, outbuf, ent_bits >> 3))
123 goto err;
124
125 pr_debug("pulled %u bits from CPU RNG entropy source\n", full_bits);
126
127 /* Generate the compressed data to be returned to the caller */
128 ent_bits = crypto_cb->lrng_hash_digestsize(hash) << 3;
129 if (requested_bits < ent_bits) {
130 u8 digest[LRNG_MAX_DIGESTSIZE];
131
132 if (crypto_cb->lrng_hash_final(shash, digest))
133 goto err;
134
135 /* Truncate output data to requested size */
136 memcpy(outbuf, digest, requested_bits >> 3);
137 memzero_explicit(digest, crypto_cb->lrng_hash_digestsize(hash));
138 ent_bits = requested_bits;
139 } else {
140 if (crypto_cb->lrng_hash_final(shash, outbuf))
141 goto err;
142 }
143
144 out:
145 crypto_cb->lrng_hash_desc_zero(shash);
146 lrng_hash_unlock(drng, flags);
147 return ent_bits;
148
149 err:
150 ent_bits = 0;
151 goto out;
152 }
153

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]

Attachments:

(No filename) (4.40 kB)
.config.gz (68.48 kB)
Download all attachments

2021-11-22 10:33:57

On Wed, Dec 01, 2021 at 11:02:38AM -0500, Jason A. Donenfeld wrote:
> Hi Simo,
>
> I think various folks have said this during the various discussions on this
> topic over the years, in addition to myself, but I suppose I'll reiterate my
> general views on FIPS in this context.
>
> FIPS is about compliance and certification. From a cryptographic point of
> view, there might be some good ideas, some dated ideas, some superfluous but
> harmless ideas, and so forth. But the reason that you want it for your
> customers is because you think your product will become more valuable or
> useful to customers if it checks that green compliance checkbox. I don't think
> we disagree about this being the motivation.
>
> Now typically the kernel interoperates with lots of things and implements many
> different specifications. It supports scores of network protocols, IPsec
> cipher suites, USB quirks, SCSI hacks, you name it. The implementation of
> these drivers is always up to the author and hopefully kernel developers at
> large do the best job they can with the implementation, but the hardware or
> protocol they're interfacing with is not up to the author, by virtue of it
> being external to the kernel. It's not like instantiating IPsec with single
> DES and MD4, or SM3 and SM4, etc. is so great, and it's not like the
> compendium of brilliant hacks in drivers/usb/host/pci-quirks.c is so great
> either. But these things all exist to talk to something *outside* of the
> kernel, and so we grit our teeth, and as I said, do the best we can to
> implement it well.
>
> But the RNG isn't like that. In fact, the RNG is logically *required* to be
> not anything like that: it returns random bytes, and they must not have any
> distinguishing quality with other random bytes; otherwise we have a serious
> problem that needs fixing. And so, we carry things out according to the usual
> kernel developer mindset: we implement it as best as we can, using the best
> algorithms we can find, in a way most suitable for the kernel.
>
> Then FIPS comes along and starts dictating things about *how* we implement it,
> and those things it dictates might not be exactly the same as what we would
> would be doing when doing best that we can, using the best algorithms we can
> find, and in the most suitable way for the kernel. And so it would seem that
> the goal of implementing the RNG as best as we can might potentially be at
> odds with the goal of getting that green compliance checkbox, because that
> checkbox oversteps its bounds a bit.
>
> That's not to say, of course, that we shouldn't accept input on how we
> implement our algorithms from elsewhere. On the contrary, I think random.c has
> a *lot* to gain from incorporating newer ideas, and that the formalism and
> guidance from academic cryptographers is less "academic" than it once was and
> much more real world, implementable, and suitable for our uses. But, again,
> incorporating new ideas and accepting input on how to improve our code is very
> much not the same thing as following the FIPS laundry list for that green
> compliance checkbox. Maybe some parts do overlap -- and I'd love patches that
> improve the code alongside compelling cryptographic arguments -- but, again,
> we're talking about compliance here, and not a more welcome, "hey check out
> this document I found with a bunch of great ideas we should implement."
>
> I would like the kernel to have an excellent CSPRNG, from a cryptographic
> point of view, from a performance point of view, from an API point of view. I
> think these motivations are consistent with how the kernel is generally
> developed. And I think front loading the motivations with an external
> compliance goal greatly deviates and even detracts from the way the kernel is
> generally developed.
>
> Now the above is somewhat negative on FIPS, but the question can still be
> posed: does FIPS have a path forward in the RNG in the kernel? It's obviously
> not a resounding "yes", but I don't think it's a totally certain "no" either.
> It might be possible to find some wiggle room. I'm not saying that it is
> certainly possible to do that, but it might be.
>
> Specifically, I think that if you change your perspective from, "how can we
> change the algorithms of the RNG to be FIPS" to "how can we bend FIPS within
> its limits so that having what customers want would minimally impact the
> quality of the RNG implementation or introduce undue maintenance burdens."
> This means: not refactoring the RNG into some large abstraction layer that's
> pluggable and supports multiple different implementations, not rewriting the
> world in a massive patchset, not adding clutter. Instead, perhaps there's a
> very, very minimal set of things that can be done that would be considerably
> less controversial. That will probably require from you and other FIPS
> enthusiasts some study and discussion at what the truly most minimal set of
> things required are to get you that green compliance checkbox. And hey --
> maybe it's still way too much and it doesn't work out here. But maybe it's not
> that much, or, as Greg suggested, maybe it winds up that your needs are
> actually satisfied just fine by something in userspace or userspace-adjacent.
>
> So I don't know whether the FIPS has a path forward here, but if it does, I
> think the above is the general shape it would take. And in the mean time, I'm
> of course open to reviewing patches that improve the RNG in a cryptographic or
> algorithmic sense, rather than a purely compliance one.

Hi, Jason. How do you think we could approach that then?

Are you willing to discuss the FIPS 140-3 requirements that random.c
doesn't currently meet so we can dive deeper on how we could implement
them in a way that would improve the kernel other then simply
providing compliance to FIPS?

I believe that several requirements would be beneficial to random.c
(ie, health test, oversampling, entropy data collection). But so far
we lack proper direction on how to proceed and it would be better for
us to have a clear notion of what could be accepted before putting
more effort on yet another patch set.

I believe all the distros are interested in making progress on that,
but without a general guidance it makes very hard for us to
collaborate and we end up in the current situation in which each
distro is carrying its own "hack", as Simo mentioned before. Canonical
is in the same situation as the other distros and we are carrying an
workaround to wire up the crypto DRBG to random.c in order to archive
compliance.

We could also concentrate all the discussion in the linux-crypto
mailing list to facilitate this process, since right now I believe the
MAINTAINERS file doesn't have a specific mailing list associate to
random.c

>
> Hopefully that helps you understand more about where we're coming from.
>
> Regards,
> Jason

--
Regards,
Marcelo

Attachments:

(No filename) (6.77 kB)
signature.asc (659.00 B)
Download all attachments

2021-12-10 06:46:37

by Greg Kroah-Hartman

[permalink] [raw]

Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

On Thu, Dec 09, 2021 at 10:43:37PM -0300, Marcelo Henrique Cerri wrote:
> Hi, Jason. How do you think we could approach that then?
>
> Are you willing to discuss the FIPS 140-3 requirements that random.c
> doesn't currently meet so we can dive deeper on how we could implement
> them in a way that would improve the kernel other then simply
> providing compliance to FIPS?

Discussing things doesn't usually work well. Let's see some working
patches first, that solve problems that you have with the current random
code, and we can go from there.

Again, like any other kernel patch submission, nothing new here at all.

> I believe all the distros are interested in making progress on that,
> but without a general guidance it makes very hard for us to
> collaborate and we end up in the current situation in which each
> distro is carrying its own "hack", as Simo mentioned before. Canonical
> is in the same situation as the other distros and we are carrying an
> workaround to wire up the crypto DRBG to random.c in order to archive
> compliance.

If everyone seems to think their patches are hacks, and are not worthy
of being submitted, then why do they think that somehow they are viable
for their users that are actually using them?

{sigh}

greg k-h

2021-12-10 09:30:29

On Thu, Dec 09, 2021 at 10:43:37PM -0300, Marcelo Henrique Cerri wrote:
> On Wed, Dec 01, 2021 at 11:02:38AM -0500, Jason A. Donenfeld wrote:
> > Hi Simo,
> >
> > I think various folks have said this during the various discussions on this
> > topic over the years, in addition to myself, but I suppose I'll reiterate my
> > general views on FIPS in this context.
> >
> > FIPS is about compliance and certification. From a cryptographic point of
> > view, there might be some good ideas, some dated ideas, some superfluous but
> > harmless ideas, and so forth. But the reason that you want it for your
> > customers is because you think your product will become more valuable or
> > useful to customers if it checks that green compliance checkbox. I don't think
> > we disagree about this being the motivation.
> >
> > Now typically the kernel interoperates with lots of things and implements many
> > different specifications. It supports scores of network protocols, IPsec
> > cipher suites, USB quirks, SCSI hacks, you name it. The implementation of
> > these drivers is always up to the author and hopefully kernel developers at
> > large do the best job they can with the implementation, but the hardware or
> > protocol they're interfacing with is not up to the author, by virtue of it
> > being external to the kernel. It's not like instantiating IPsec with single
> > DES and MD4, or SM3 and SM4, etc. is so great, and it's not like the
> > compendium of brilliant hacks in drivers/usb/host/pci-quirks.c is so great
> > either. But these things all exist to talk to something *outside* of the
> > kernel, and so we grit our teeth, and as I said, do the best we can to
> > implement it well.
> >
> > But the RNG isn't like that. In fact, the RNG is logically *required* to be
> > not anything like that: it returns random bytes, and they must not have any
> > distinguishing quality with other random bytes; otherwise we have a serious
> > problem that needs fixing. And so, we carry things out according to the usual
> > kernel developer mindset: we implement it as best as we can, using the best
> > algorithms we can find, in a way most suitable for the kernel.
> >
> > Then FIPS comes along and starts dictating things about *how* we implement it,
> > and those things it dictates might not be exactly the same as what we would
> > would be doing when doing best that we can, using the best algorithms we can
> > find, and in the most suitable way for the kernel. And so it would seem that
> > the goal of implementing the RNG as best as we can might potentially be at
> > odds with the goal of getting that green compliance checkbox, because that
> > checkbox oversteps its bounds a bit.
> >
> > That's not to say, of course, that we shouldn't accept input on how we
> > implement our algorithms from elsewhere. On the contrary, I think random.c has
> > a *lot* to gain from incorporating newer ideas, and that the formalism and
> > guidance from academic cryptographers is less "academic" than it once was and
> > much more real world, implementable, and suitable for our uses. But, again,
> > incorporating new ideas and accepting input on how to improve our code is very
> > much not the same thing as following the FIPS laundry list for that green
> > compliance checkbox. Maybe some parts do overlap -- and I'd love patches that
> > improve the code alongside compelling cryptographic arguments -- but, again,
> > we're talking about compliance here, and not a more welcome, "hey check out
> > this document I found with a bunch of great ideas we should implement."
> >
> > I would like the kernel to have an excellent CSPRNG, from a cryptographic
> > point of view, from a performance point of view, from an API point of view. I
> > think these motivations are consistent with how the kernel is generally
> > developed. And I think front loading the motivations with an external
> > compliance goal greatly deviates and even detracts from the way the kernel is
> > generally developed.
> >
> > Now the above is somewhat negative on FIPS, but the question can still be
> > posed: does FIPS have a path forward in the RNG in the kernel? It's obviously
> > not a resounding "yes", but I don't think it's a totally certain "no" either.
> > It might be possible to find some wiggle room. I'm not saying that it is
> > certainly possible to do that, but it might be.
> >
> > Specifically, I think that if you change your perspective from, "how can we
> > change the algorithms of the RNG to be FIPS" to "how can we bend FIPS within
> > its limits so that having what customers want would minimally impact the
> > quality of the RNG implementation or introduce undue maintenance burdens."
> > This means: not refactoring the RNG into some large abstraction layer that's
> > pluggable and supports multiple different implementations, not rewriting the
> > world in a massive patchset, not adding clutter. Instead, perhaps there's a
> > very, very minimal set of things that can be done that would be considerably
> > less controversial. That will probably require from you and other FIPS
> > enthusiasts some study and discussion at what the truly most minimal set of
> > things required are to get you that green compliance checkbox. And hey --
> > maybe it's still way too much and it doesn't work out here. But maybe it's not
> > that much, or, as Greg suggested, maybe it winds up that your needs are
> > actually satisfied just fine by something in userspace or userspace-adjacent.
> >
> > So I don't know whether the FIPS has a path forward here, but if it does, I
> > think the above is the general shape it would take. And in the mean time, I'm
> > of course open to reviewing patches that improve the RNG in a cryptographic or
> > algorithmic sense, rather than a purely compliance one.
>
> Hi, Jason. How do you think we could approach that then?
>
> Are you willing to discuss the FIPS 140-3 requirements that random.c
> doesn't currently meet so we can dive deeper on how we could implement
> them in a way that would improve the kernel other then simply
> providing compliance to FIPS?
>
> I believe that several requirements would be beneficial to random.c
> (ie, health test, oversampling, entropy data collection). But so far
> we lack proper direction on how to proceed and it would be better for
> us to have a clear notion of what could be accepted before putting
> more effort on yet another patch set.
>
> I believe all the distros are interested in making progress on that,
> but without a general guidance it makes very hard for us to
> collaborate and we end up in the current situation in which each
> distro is carrying its own "hack", as Simo mentioned before. Canonical
> is in the same situation as the other distros and we are carrying an
> workaround to wire up the crypto DRBG to random.c in order to archive
> compliance.
>

Hoping that might help with the discussion and to explain why I do
consider those solutions a "hack", that's the patch we've been using
so far to achieve SP 800-90B compliance:

https://kernel.ubuntu.com/~mhcerri/0001-UBUNTU-SAUCE-random-Use-Crypto-API-DRBG-for-urandom-.patch

> We could also concentrate all the discussion in the linux-crypto
> mailing list to facilitate this process, since right now I believe the
> MAINTAINERS file doesn't have a specific mailing list associate to
> random.c
>
> >
> > Hopefully that helps you understand more about where we're coming from.
> >
> > Regards,
> > Jason
>
> --
> Regards,
> Marcelo
>

--
Regards,
Marcelo

Attachments:

(No filename) (7.37 kB)
signature.asc (659.00 B)
Download all attachments

2022-01-10 14:12:08

by Jason A. Donenfeld

[permalink] [raw]

Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

Hi Marcelo,

On Mon, Jan 10, 2022 at 2:24 PM Marcelo Henrique Cerri
<[email protected]> wrote:
> Hoping that might help with the discussion and to explain why I do
> consider those solutions a "hack", that's the patch we've been using
> so far to achieve SP 800-90B compliance:
>
> https://kernel.ubuntu.com/~mhcerri/0001-UBUNTU-SAUCE-random-Use-Crypto-API-DRBG-for-urandom-.patch

Thanks for sending this in response to my request for it in our private thread.

Just to confirm, this little patch here gives you FIPS certification?

Jason

2022-01-10 14:31:18

by Theodore Ts'o

[permalink] [raw]

Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

On Mon, Jan 10, 2022 at 03:11:46PM +0100, Jason A. Donenfeld wrote:
> On Mon, Jan 10, 2022 at 2:24 PM Marcelo Henrique Cerri
> <[email protected]> wrote:
> > Hoping that might help with the discussion and to explain why I do
> > consider those solutions a "hack", that's the patch we've been using
> > so far to achieve SP 800-90B compliance:
> >
> > https://kernel.ubuntu.com/~mhcerri/0001-UBUNTU-SAUCE-random-Use-Crypto-API-DRBG-for-urandom-.patch
>
> Thanks for sending this in response to my request for it in our private thread.
>
> Just to confirm, this little patch here gives you FIPS certification?

There might be some FIPS certification labs that might be willing to
be taken in by the jitterentropy story, but when I've had private
communications from people who are familiar with the Intel
microarchitecture saying that jitterentropy is mostly "security by
obscurity", I'd be strongly opposed to replacing the current scheme
with something which is purely jitteretropy.

Perhaps an build-time option where one of the seeds into the CRNG is
"jitterentropy", but we keep everything else. That way, jitterentropy
can still be TSA-style "security theatre", but we're not utterly
dependant on the "the CPU microarchitecture is SOOOOOOO complicated,
it *must* be unpredictable".

- Ted

2022-01-10 14:38:29

by Jason A. Donenfeld

[permalink] [raw]

Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

Hi Ted,

On Mon, Jan 10, 2022 at 3:31 PM Theodore Ts'o <[email protected]> wrote:
> There might be some FIPS certification labs that might be willing to
> be taken in by the jitterentropy story, but when I've had private
> communications from people who are familiar with the Intel
> microarchitecture saying that jitterentropy is mostly "security by
> obscurity", I'd be strongly opposed to replacing the current scheme
> with something which is purely jitteretropy.
>
> Perhaps an build-time option where one of the seeds into the CRNG is
> "jitterentropy", but we keep everything else. That way, jitterentropy
> can still be TSA-style "security theatre", but we're not utterly
> dependant on the "the CPU microarchitecture is SOOOOOOO complicated,
> it *must* be unpredictable".

Yea, I'm not really compelled by it as something real that we'd
actually want to have for something serious. Keep in mind: this thread
isn't really about cryptography, but just about compliance nonsense.
BUT, if it turns out that the path to these people getting their green
compliance checkbox stamp isn't actually thousands of lines of new
code, but rather some glue bridging the /dev/urandom / getrandom(2)
API into the blah cryptoapi thing, that's... interesting news to me.
I'm not even saying, at this stage anyhow, that I want to do this, but
I do find it a very interesting data point. As I wrote in [1]:

> Specifically, I think that if you change your perspective from, "how can we
> change the algorithms of the RNG to be FIPS" to "how can we bend FIPS within
> its limits so that having what customers want would minimally impact the
> quality of the RNG implementation or introduce undue maintenance burdens."

We're now starting to get some idea about how this FIPS stuff bends.

Jason

[1] https://lore.kernel.org/lkml/CAHmME9qP9eYfPH+8eRvpx_tW8iAtDc-byVMvh4tFL_cABdsiOA@mail.gmail.com/

2022-01-10 15:08:18

On Tue, Jan 11, 2022 at 02:57:54PM +0500, Alexander E. Patrakov wrote:

> LD_PRELOAD is not a solution because of containers and statically-linked
> binaries.

No, it doesn't solve all problems, but the question is whether it needs
to. We're talking about the scenario where:

a) a customer requires FIPS compliance, and
b) the customer has an app that calls getrandom() and doesn't fallback,
and
c) they're doing so with statically linked binaries or container
infrastructure that doesn't allow injection of other libraries

How common is this? Does the kernel need to solve this scenario?