* Re: [PATCH] padata: make the sequence counter an atomic_t
From: Herbert Xu @ 2013-10-25 9:26 UTC (permalink / raw)
To: Mathias Krause; +Cc: Steffen Klassert, linux-crypto
In-Reply-To: <526A29E0.8070204@secunet.com>
On Fri, Oct 25, 2013 at 10:20:48AM +0200, Mathias Krause wrote:
> On 08.10.2013 14:08, Steffen Klassert wrote:
> > On Wed, Oct 02, 2013 at 03:40:45PM +0200, Mathias Krause wrote:
> >> Using a spinlock to atomically increase a counter sounds wrong -- we've
> >> atomic_t for this!
> >>
> >> Also move 'seq_nr' to a different cache line than 'lock' to reduce cache
> >> line trashing. This has the nice side effect of decreasing the size of
> >> struct parallel_data from 192 to 128 bytes for a x86-64 build, e.g.
> >> occupying only two instead of three cache lines.
> >>
> >> Those changes results in a 5% performance increase on an IPsec test run
> >> using pcrypt.
> >>
> >> Btw. the seq_lock spinlock was never explicitly initialized -- one more
> >> reason to get rid of it.
> >>
> >> Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
> >
> > Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
> >
> > Herbert can you take this one?
>
> Ping, Herbert? Anything wrong with the patch?
Sorry I don't seem to have this patch in my mail box. Can you
resend it please?
Thanks!
--
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
^ permalink raw reply
* Re: [PATCH] padata: make the sequence counter an atomic_t
From: Mathias Krause @ 2013-10-25 10:13 UTC (permalink / raw)
To: Herbert Xu; +Cc: Steffen Klassert, linux-crypto
In-Reply-To: <20131025092644.GA20145@gondor.apana.org.au>
On 25.10.2013 11:26, Herbert Xu wrote:
> On Fri, Oct 25, 2013 at 10:20:48AM +0200, Mathias Krause wrote:
>> On 08.10.2013 14:08, Steffen Klassert wrote:
>>> On Wed, Oct 02, 2013 at 03:40:45PM +0200, Mathias Krause wrote:
>>>> Using a spinlock to atomically increase a counter sounds wrong -- we've
>>>> atomic_t for this!
>>>>
>>>> Also move 'seq_nr' to a different cache line than 'lock' to reduce cache
>>>> line trashing. This has the nice side effect of decreasing the size of
>>>> struct parallel_data from 192 to 128 bytes for a x86-64 build, e.g.
>>>> occupying only two instead of three cache lines.
>>>>
>>>> Those changes results in a 5% performance increase on an IPsec test run
>>>> using pcrypt.
>>>>
>>>> Btw. the seq_lock spinlock was never explicitly initialized -- one more
>>>> reason to get rid of it.
>>>>
>>>> Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
>>> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
>>>
>>> Herbert can you take this one?
>> Ping, Herbert? Anything wrong with the patch?
>
> Sorry I don't seem to have this patch in my mail box. Can you
> resend it please?
I send it to linux-crypto and Steffen only. Will resend it directed to
you, now.
>
> Thanks!
^ permalink raw reply
* [PATCH RESEND] padata: make the sequence counter an atomic_t
From: Mathias Krause @ 2013-10-25 10:14 UTC (permalink / raw)
To: Herbert Xu; +Cc: Steffen Klassert, linux-crypto, Mathias Krause
In-Reply-To: <20131025092644.GA20145@gondor.apana.org.au>
Using a spinlock to atomically increase a counter sounds wrong -- we've
atomic_t for this!
Also move 'seq_nr' to a different cache line than 'lock' to reduce cache
line trashing. This has the nice side effect of decreasing the size of
struct parallel_data from 192 to 128 bytes for a x86-64 build, e.g.
occupying only two instead of three cache lines.
Those changes results in a 5% performance increase on an IPsec test run
using pcrypt.
Btw. the seq_lock spinlock was never explicitly initialized -- one more
reason to get rid of it.
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/linux/padata.h | 3 +--
kernel/padata.c | 9 ++++-----
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/include/linux/padata.h b/include/linux/padata.h
index 86292be..4386946 100644
--- a/include/linux/padata.h
+++ b/include/linux/padata.h
@@ -129,10 +129,9 @@ struct parallel_data {
struct padata_serial_queue __percpu *squeue;
atomic_t reorder_objects;
atomic_t refcnt;
+ atomic_t seq_nr;
struct padata_cpumask cpumask;
spinlock_t lock ____cacheline_aligned;
- spinlock_t seq_lock;
- unsigned int seq_nr;
unsigned int processed;
struct timer_list timer;
};
diff --git a/kernel/padata.c b/kernel/padata.c
index 07af2c9..2abd25d 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -46,6 +46,7 @@ static int padata_index_to_cpu(struct parallel_data *pd, int cpu_index)
static int padata_cpu_hash(struct parallel_data *pd)
{
+ unsigned int seq_nr;
int cpu_index;
/*
@@ -53,10 +54,8 @@ static int padata_cpu_hash(struct parallel_data *pd)
* seq_nr mod. number of cpus in use.
*/
- spin_lock(&pd->seq_lock);
- cpu_index = pd->seq_nr % cpumask_weight(pd->cpumask.pcpu);
- pd->seq_nr++;
- spin_unlock(&pd->seq_lock);
+ seq_nr = atomic_inc_return(&pd->seq_nr);
+ cpu_index = seq_nr % cpumask_weight(pd->cpumask.pcpu);
return padata_index_to_cpu(pd, cpu_index);
}
@@ -429,7 +428,7 @@ static struct parallel_data *padata_alloc_pd(struct padata_instance *pinst,
padata_init_pqueues(pd);
padata_init_squeues(pd);
setup_timer(&pd->timer, padata_reorder_timer, (unsigned long)pd);
- pd->seq_nr = 0;
+ atomic_set(&pd->seq_nr, -1);
atomic_set(&pd->reorder_objects, 0);
atomic_set(&pd->refcnt, 0);
pd->pinst = pinst;
--
1.7.2.5
^ permalink raw reply related
* [PATCH] crypto: blkcipher: do not read unutialised walk->flags
From: Michal Nazarewicz @ 2013-10-25 11:27 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: linux-crypto, linux-kernel, Michal Nazarewicz
From: Michal Nazarewicz <mina86@mina86.com>
blkcipher_walk_virt, blkcipher_walk_virt_block and
blkcipher_walk_phys functions modify the walk->flags by using
a binary “&=” or “|=” operator. This translate to read followed by
a write. However, the walk->flags is usually not initialised so the
read returns garbage.
At the same time, those functions call blkcipher_walk_first which
then calls blkcipher_walk_next function which zeroes all flags
except for BLKCIPHER_WALK_PHYS. This means, that the read done in
the virt, virt_block and phys functions is completely meaningless.
Dropping the read and changing “&=”/“|=” with a plain assignment
clears the confusion without changing any functionality of the API.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
---
Admittedly, I'm not familiar with the crypto API, but I believe
this to be a valid change. This has actually been prompted by
Coverity scan which detects the read of initialised data.
crypto/blkcipher.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index a79e7e9..3fb99d8 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -305,7 +305,7 @@ static inline int blkcipher_copy_iv(struct blkcipher_walk *walk,
int blkcipher_walk_virt(struct blkcipher_desc *desc,
struct blkcipher_walk *walk)
{
- walk->flags &= ~BLKCIPHER_WALK_PHYS;
+ walk->flags = 0;
walk->blocksize = crypto_blkcipher_blocksize(desc->tfm);
return blkcipher_walk_first(desc, walk);
}
@@ -314,7 +314,7 @@ EXPORT_SYMBOL_GPL(blkcipher_walk_virt);
int blkcipher_walk_phys(struct blkcipher_desc *desc,
struct blkcipher_walk *walk)
{
- walk->flags |= BLKCIPHER_WALK_PHYS;
+ walk->flags = BLKCIPHER_WALK_PHYS;
walk->blocksize = crypto_blkcipher_blocksize(desc->tfm);
return blkcipher_walk_first(desc, walk);
}
@@ -352,7 +352,7 @@ int blkcipher_walk_virt_block(struct blkcipher_desc *desc,
struct blkcipher_walk *walk,
unsigned int blocksize)
{
- walk->flags &= ~BLKCIPHER_WALK_PHYS;
+ walk->flags = 0;
walk->blocksize = blocksize;
return blkcipher_walk_first(desc, walk);
}
--
1.8.4
^ permalink raw reply related
* Re: crypto: skcipher - Use eseqiv even on UP machines
From: David Miller @ 2013-10-25 21:57 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev, linux-crypto
In-Reply-To: <20131025065049.GB31491@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 25 Oct 2013 08:50:49 +0200
> On Thu, Oct 24, 2013 at 08:41:49PM +0800, Herbert Xu wrote:
>> Hi:
>>
>> Previously we would use eseqiv on all async ciphers in all cases,
>> and sync ciphers if we have more than one CPU. This meant that
>> chainiv is only used in the case of sync ciphers on a UP machine.
>>
>> As chainiv may aid attackers by making the IV predictable, even
>> though this risk itself is small, the above usage pattern causes
>> it to further leak information about the host.
>>
>> This patch addresses these issues by using eseqiv even if we're
>> on a UP machine.
>>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>>
>
> That's fine by me.
>
> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
I'm ok with this too:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH] CRYPTO: omap-sham: Add missing modalias
From: Pali Rohár @ 2013-10-26 21:00 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: linux-crypto, linux-kernel, Joni Lapilainen
From: Joni Lapilainen <joni.lapilainen@gmail.com>
Signed-off-by: Joni Lapilainen <joni.lapilainen@gmail.com>
---
drivers/crypto/omap-sham.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 8bdde57..236db0a 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -2033,3 +2033,4 @@ module_platform_driver(omap_sham_driver);
MODULE_DESCRIPTION("OMAP SHA1/MD5 hw acceleration support.");
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Dmitry Kasatkin");
+MODULE_ALIAS("platform:omap-sham");
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-28 15:40 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: sandy harris, linux-kernel, linux-crypto
In-Reply-To: <2579337.FPgJGgHYdz@tauon>
Am Freitag, 11. Oktober 2013, 20:38:51 schrieb Stephan Mueller:
Hi Ted,
>Hi,
>
>the CPU Jitter RNG [1] is a true random number generator that is
>intended to work in user and kernel space equally well on a large
>number of different CPUs. The heart of the RNG is about 30 lines of
>code. The current implementation allows seamless hooking into the
>kernel crypto API as well as the Linux /dev/random driver. With its
>inherent non- blocking behavior, it could solve the problem of a
>blocking /dev/random.
>
>Over the last months, new tests were executed. The list of tests now
>cover all major operating systems and CPU types as well as microkernels
>of NOVA, Fiasco.OC and Pistacio. More than 200 different systems are
>tested. And for those, the tests show that the Jitter RNG produces
>high- quality output. See [2] appendix F for details.
Apart from adding more test results from more systems (now including
Windows), I added more updates:
- The structure of the Linux kernel code is updated such that the common
C code can go to straight to the lib/ directory or any other directory
that seems suitable for common code. If it is of help, I can create a
patch file to add the CPU Jitter RNG to the Linux kernel code instead of
manually copying into a kernel tree for testing it with random.c.
- Based on Sandy Harris' discussion in
http://permalink.gmane.org/gmane.comp.encryption.general/16219, the
patch for random.c is updated that the initialization function of the
entropy pools init_std_data now contains a call to the CPU Jitter RNG to
mix in 256 bits of entropy when the entropy pool is filled.
If it is accepted that the CPU Jitter RNG delivers entropy, the latter
update may now allow us to get rid of storing the seed file during
shutdown and restoring it during the next boot sequence.
Please see the latest patch to random.c in the file patches/linux-3.11-
random.patch delivered with [1].
Ciao
Stephan
[1] http://www.chronox.de/jent/jitterentropy-20131028.tar.bz2
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Henrique de Moraes Holschuh @ 2013-10-28 16:06 UTC (permalink / raw)
To: Stephan Mueller
Cc: Theodore Ts'o, sandy harris, linux-kernel, linux-crypto
In-Reply-To: <2049321.gMV6JUDze7@tauon>
On Mon, 28 Oct 2013, Stephan Mueller wrote:
> If it is accepted that the CPU Jitter RNG delivers entropy, the latter
> update may now allow us to get rid of storing the seed file during
> shutdown and restoring it during the next boot sequence.
That's a 4096-bit safety net (uncredited entropy) which at least Debian
shall not remove.
I think Debian also dumps some low-entropy-per-bit crap into /dev/random
during boot (again, not credited), such as the boot kernel logs. We could
increase the density of that entropy a lot using gzip -0 or something like
that... is an uncredited low-entropy-per-bit dump into the pool detrimental
to its quality?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-28 16:15 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Theodore Ts'o, sandy harris, linux-kernel, linux-crypto
In-Reply-To: <20131028160623.GD15440@khazad-dum.debian.net>
Am Montag, 28. Oktober 2013, 14:06:23 schrieb Henrique de Moraes
Holschuh:
Hi Henrique,
>On Mon, 28 Oct 2013, Stephan Mueller wrote:
>> If it is accepted that the CPU Jitter RNG delivers entropy, the
>> latter
>> update may now allow us to get rid of storing the seed file during
>> shutdown and restoring it during the next boot sequence.
>
>That's a 4096-bit safety net (uncredited entropy) which at least Debian
>shall not remove.
That is correct, and I did not want have such safety net removed.
I have to correct my initial statement: there is a possibility where the
CPU Jitter RNG may not deliver data: when the timer resolution is too
coarse. Thus, please disregard my notion to remove the user space
seeding.
My goal is that the entropy pools are filled with entropy at the time
when they are created so that they will deliver good random data if the
system has a high resolution timer (which is almost always the case as
shown with my tests).
>
>I think Debian also dumps some low-entropy-per-bit crap into
>/dev/random during boot (again, not credited), such as the boot kernel
>logs. We could increase the density of that entropy a lot using gzip
>-0 or something like that... is an uncredited low-entropy-per-bit dump
>into the pool detrimental to its quality?
Any mixing of data into the entropy pools can never diminish the
entropy, but just further mix the data.
Note, a simple write of data into the device files will never update the
entropy estimator that is behind the blocking of /dev/random. All that
is done by the write to the device files is the mixing of the entropy
pools of blocking_pool and nonblocking_pool (and not input_pool).
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Theodore Ts'o @ 2013-10-28 21:45 UTC (permalink / raw)
To: Stephan Mueller; +Cc: sandy harris, linux-kernel, linux-crypto
In-Reply-To: <2049321.gMV6JUDze7@tauon>
Fundamentally, what worries me about this scheme (actually, causes the
hair on the back of my neck to rise up on end) is this statement in
your documentation[1]:
When looking at the sequence of time deltas gathered
during testing [D] , no pattern can be detected. Therefore, the
fluctuation and the resulting distribution are not based on a
repeating pattern and must be considered random.
[1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
Just because we can't detect a pattern does **not** mean that it is
not based on a repeating pattern, and therefore must be considered
random. We can't detect a pattern in RDRAND, so does that mean it's
automatically random? Why, no.
If all you have is the output of "AES_ENCRPYT(NSA_KEY, i++)". and
NSA_KEY is not known to you, you won't be able to detect a pattern,
either. But I can guarantee to you that it's not random...
It may be that there is some very complex state which is hidden inside
the the CPU execution pipeline, the L1 cache, etc., etc. But just
because *you* can't figure it out, and just because *I* can't figure
it out doesn't mean that it is ipso facto something which a really
bright NSA analyst working in Fort Meade can't figure out. (Or heck,
a really clever Intel engineer who has full visibility into the
internal design of an Intel CPU....)
Now, it may be that in practice, an adversary won't be able to carry
out a practical attack because there will be external interrupts that
the adversary won't be able to put into his or her model of your CPU
--- for example, from network interrupts or keyboard interrupts. But
in that case, it's to measure just the interrupt, because it may be
that the 32 interrupts that you got while extracting 128 bits of
entropy from your jitter engine was only 32 bits of entropy, and the
rest could be determined by someone with sufficient knowledge and
understanding of the internal guts of the CPU. (Treating this
obscurity as security is probably not a good idea; we have to assume
the NSA can get its hands on anything it wants, even internal,
super-secret, "black cover" Intel documents. :-)
To be honest, I have exactly the same worry about relying on HDD
interrupts. The theoretical basis of this resulting in true
randomness is based on a 1994 paper by Don Davis: "Cryptographic
randomness from air turbulence in disk drives"[2]:
[2] http://world.std.com/~dtd/random/forward.pdf
The problem is that almost two decades later, the technology of HDD's,
and certainly SSD (which didn't exist back then) have changed quite a
lot. It is not obvious to me how much entropy you can really get from
observing the disk completion times if you assume that the adversary
has complete knowledge to the relative timing and block numbers of the
disk accesses from the OS (for example, if we boot multiple mobile
phone from flash for the first time, how many bits of entropy are
there really?)
But at least back in 1994, there was an attempt to come up with a
physical theory as to where the entropy was coming from, and then as
much work as possible to rule out other possible causes of the
uncertainty.
So if you want to really convince the world that CPU jitter is random,
it's not enough to claim that it you can't see a pattern. What you
need to do is to remove all possible sources of the uncertainty, and
show that there is still no discernable pattern after you do things
like (a) run in kernel space, on an otherwise quiscent computer, (b)
disable interrupts, so that any uncertainty can't be coming from
interrupts, etc., Try to rule it all out, and then see if you still
get uncertainty.
If you think it is from DRAM timing, first try accessing the same
memory location in kernel code with the interrupts off, over and over
again, so that the memory is pinned into L1 cache. You should be able
to get consistent results. If you can, then if you then try to read
from DRAM with the L1 and L2 caches disabled, and with interrupts
turned off, etc, and see if you get consistent results or inconsistent
results. If you get consistent results in both cases, then your
hypothesis is disproven. If you get consistent results with the
memory pinned in L1 cache, and inconsistent results when the L1 and L2
cache are disabled, then maybe the timing of DRAM reads really are
introducing entropy. But the point is you need to test each part of
the system in isolation, so you can point at a specific part of the
system and say, *that*'s where at least some uncertainty which an
adversary can not reverse engineer, and here is the physical process
from which the choatic air patterns, or quantum effects, etc., which
is hypothesized to cause the uncertainty.
And note that when you do this, you can't use any unbiasing or
whitening techniques --- you want to use the raw timings, and then do
things like look very hard for any kind of patterns; Don Davis used
FFT's because he wanted to look for any patterns that might be
introduced by the rotating plattern, which would presumably would show
up in a frequency domain analysis even if it was invisible in the time
domain.
If you don't do all of this work, there is no way to know for sure
where the entropy is coming from. And if you don't know, that's when
you have to be very, very conservative, and use a very large
engineering safety margin. Currently we use the high resolution CPU
counter, plus the interrupted IP, and we mix all of this together from
64 interrupts, and we count this as a single bit of entropy. I *hope*
that at least one of those interrupts has sufficient unpredictably,
perhaps because the remote attacker can't know when a LAN interrupt
has happened, such that have a single bit of entropy.
Maybe someone can prove that there is more entropy because of some
instability between the oscillator used by the CPU clock and the one
used by the ethernet NIC, and so I'm being hopelessly
over-conservative. Perhaps; but until we know for sure, using a
similar analysis to what I described above, I'd much rather be slow
than be potentially insecure.
The jitter "entropy collector" may be able to generate more
"randomness" much more quickly, but is the resulting numbers really
more secure? Other people will have to judge for themselves, but this
is why I'm not convinced.
Best regards,
- Ted
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-29 8:42 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: sandy harris, linux-kernel, linux-crypto
In-Reply-To: <20131028214549.GA31746@thunk.org>
Am Montag, 28. Oktober 2013, 17:45:49 schrieb Theodore Ts'o:
Hi Theodore,
first of all, thank you for your thoughts.
And, before we continue any discussion, please consider that all the big
testing that is done to analyze the jitter so far did (a) not include
any whitening schema (cryptographic or otherwise) and (b) did not even
include the processing done inside the RNG. The testing in appendix F of
the documentation just measures the execution time of some instructions
-- the very heart of the RNG, and not more. And only if these show
variations, then I conclude the RNG can be used.
[...]
>
>It may be that there is some very complex state which is hidden inside
>the the CPU execution pipeline, the L1 cache, etc., etc. But just
>because *you* can't figure it out, and just because *I* can't figure
>it out doesn't mean that it is ipso facto something which a really
>bright NSA analyst working in Fort Meade can't figure out. (Or heck,
>a really clever Intel engineer who has full visibility into the
>internal design of an Intel CPU....)
I concur here. But so are all sources of /dev/random too. As you have
outlined later, your HDD fluctuations may not be as trustworthy as we
think. The key strokes and their timings can be obtained from
electromagnetic emanation. Lastly, the use of the fast_pool using
interrupts may still show a correlation with the other noise sources as
they all generate interrupts. But I diverge as we talk about my RNG and
do not analyze random.c.
So, I guess we all agree on the notion that entropy is *relative*. Some
information may be more entropic to one than to the other. However, for
us, it shall be entropy enough to counter our adversary.
>
>Now, it may be that in practice, an adversary won't be able to carry
>out a practical attack because there will be external interrupts that
>the adversary won't be able to put into his or her model of your CPU
>--- for example, from network interrupts or keyboard interrupts. But
>in that case, it's to measure just the interrupt, because it may be
>that the 32 interrupts that you got while extracting 128 bits of
>entropy from your jitter engine was only 32 bits of entropy, and the
>rest could be determined by someone with sufficient knowledge and
>understanding of the internal guts of the CPU. (Treating this
>obscurity as security is probably not a good idea; we have to assume
>the NSA can get its hands on anything it wants, even internal,
>super-secret, "black cover" Intel documents. :-)
Again, I concur. But since I have seen the jitter with quite similar
size on all the major CPUs we have around us (Intel, AMD, Sparc, POWER,
PowerPC, ARM, MIPS, zSeries), I guess you need to update your statement
to "... even internal, super-secret, "black cover" documents that are
synchronized among all the different chip vendors". :-)
[...]
Thanks again to your ideas below in testing the issue more.
>
>So if you want to really convince the world that CPU jitter is random,
>it's not enough to claim that it you can't see a pattern. What you
>need to do is to remove all possible sources of the uncertainty, and
>show that there is still no discernable pattern after you do things
>like (a) run in kernel space, on an otherwise quiscent computer, (b)
Re: (a) that is what I already did. The kernel implementation of the RNG
is capable of that testing. Moreover, that is what I already did in
section 5.1. It is easy for everybody to redo the testing by simply
compiling the kernel module, load it and look into
/sys/kernel/debug/jitterentropy. There you find some files that are
direct interfaces to the RNG. In particular, the file stat-fold is the
key to redo the testing that covers appendix F of my document (as
mentioned above, there is no postprocessing of the raw variations when
you read that file).
>disable interrupts, so that any uncertainty can't be coming from
>interrupts, etc., Try to rule it all out, and then see if you still
>get uncertainty.
When I did testing on all systems, interrupts are easily visible by the
larger "variations". When compiling the test results in appendix F, all
measurements that are a tad higher than the majority of the variations
are simply removed to focus on the worst case. I.e. the measurements and
the results *already* exclude any interrupts, scheduling impacts.
Regarding, caches, may I ask you to look into appendix F.46 of the
current document version? I conducted tests that tried to disable /
remove the impact of: system call context switches, flushing the
instruction pipeline, flushing of all caches, disabling preemtion,
flushing TLB, executing the code exclusively on one CPU core, disabling
of power management and frequency scaling.
All these tests show *no* deterioration in jitter, i.e. the jitter is
still there. The only exception is the power management where I see some
small jitter drop off, which is analyzed and concluded to be
unproblematic.
>
>If you think it is from DRAM timing, first try accessing the same
>memory location in kernel code with the interrupts off, over and over
>again, so that the memory is pinned into L1 cache. You should be able
That is what the testing already does. I constantly access some piece of
memory millions of times and measure the execution time of the operation
on that memory location. As mentioned above, interrupts are disregarded
in any case.
And, jitter is there.
>to get consistent results. If you can, then if you then try to read
>from DRAM with the L1 and L2 caches disabled, and with interrupts
Based on this suggestion, I now added the tests in Appendix F.46.8 where
I disable the caches and the tests in Appendix F.46.9 where I disable
the caches and interrupts.
The results show that the jitter even goes way up -- thus, jitter that
is sufficient is even more present when disabling the caches and
interrupts.
>turned off, etc, and see if you get consistent results or inconsistent
>results. If you get consistent results in both cases, then your
>hypothesis is disproven. If you get consistent results with the
Currently, the hypothesis is *not* disproven.
>memory pinned in L1 cache, and inconsistent results when the L1 and L2
>cache are disabled, then maybe the timing of DRAM reads really are
>introducing entropy. But the point is you need to test each part of
>the system in isolation, so you can point at a specific part of the
>system and say, *that*'s where at least some uncertainty which an
>adversary can not reverse engineer, and here is the physical process
>from which the choatic air patterns, or quantum effects, etc., which
>is hypothesized to cause the uncertainty.
As I tried quite a number of different variations on disabling /
enabling features in appendix F.46, I am out of ideas what else I should
try.
>
>And note that when you do this, you can't use any unbiasing or
>whitening techniques --- you want to use the raw timings, and then do
>things like look very hard for any kind of patterns; Don Davis used
Again, there is no whitening, and not even the RNG processing involved.
All I am doing is simple timing analysis of some fixed set of
instructions -- i.e. the very heart of the RNG.
[..]
>
>The jitter "entropy collector" may be able to generate more
>"randomness" much more quickly, but is the resulting numbers really
>more secure? Other people will have to judge for themselves, but this
>is why I'm not convinced.
May I ask to recheck appendix F.46 again?
Thanks
Stephan
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Theodore Ts'o @ 2013-10-29 13:24 UTC (permalink / raw)
To: Stephan Mueller; +Cc: sandy harris, linux-kernel, linux-crypto
In-Reply-To: <3160817.9DcncHidey@tauon>
On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
> Based on this suggestion, I now added the tests in Appendix F.46.8 where
> I disable the caches and the tests in Appendix F.46.9 where I disable
> the caches and interrupts.
What you've added in F.46 is a good start, but as a suggestiom,
instead of disabling one thing at a time, try disabling *everything*
and then see what you get, and then enabling one thing at a time. The
best thing is if you can get to the point where the amount of entropy
is close to zero. Then as you add things back, there's a much better
sense of where the unpredictability might be coming from, and whether
the unpredictability is coming from something which is fundamentally
arising from something which is chaotic or quantum effect, or just
because we don't have a good way of modelling the behavior of the
L1/L2 cache (for example) and that is spoofing your entropy estimator.
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-29 14:00 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: sandy harris, linux-kernel, linux-crypto
In-Reply-To: <20131029132448.GB691@thunk.org>
Am Dienstag, 29. Oktober 2013, 09:24:48 schrieb Theodore Ts'o:
Hi Theodore,
>On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
>> Based on this suggestion, I now added the tests in Appendix F.46.8
>> where I disable the caches and the tests in Appendix F.46.9 where I
>> disable the caches and interrupts.
>
>What you've added in F.46 is a good start, but as a suggestiom,
>instead of disabling one thing at a time, try disabling *everything*
>and then see what you get, and then enabling one thing at a time. The
>best thing is if you can get to the point where the amount of entropy
>is close to zero. Then as you add things back, there's a much better
I will try to do that.
But please see the different lower boundary values in the different
subsections of F.46: none of them fall when I disable or change anything
in the base system (except the power management -- where I added
additional analyses). Some of the changes imply that the jitter
increases when I disable certain support.
Thus, expect that we will not see a significant drop in the jitter as
you fear or expect.
Yet, I will try and report back.
Though, does anybody has an idea how to flush/disable branch prediction
on x86 (short of using an ARM where I can disable the branch prediction
unit with CP15)? That is the last unit that I do not have a handle on.
>sense of where the unpredictability might be coming from, and whether
>the unpredictability is coming from something which is fundamentally
>arising from something which is chaotic or quantum effect, or just
>because we don't have a good way of modelling the behavior of the
>L1/L2 cache (for example) and that is spoofing your entropy estimator.
Please note: if the jitter really comes from the oscillator effect of
the RAM clock vs. the CPU clock (which I suspect), we will not be able
to alter the jitter software wise.
The reason why I suspect that oscillating effect is the following: I
spoke with two different employees from the research departments of
major chip vendors. They mentioned that they see the very same jitter in
their measurements albeit they tried to get rid of it. So, when they
cannot get rid of that, I guess we will not be able to lower or even
eliminate the jitter significantly.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-29 22:25 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: sandy harris, linux-kernel, linux-crypto
In-Reply-To: <7861469.OAmn4h8An0@tauon>
Am Dienstag, 29. Oktober 2013, 15:00:31 schrieb Stephan Mueller:
Hi Ted,
>Am Dienstag, 29. Oktober 2013, 09:24:48 schrieb Theodore Ts'o:
>
>Hi Theodore,
>
>>On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
>>> Based on this suggestion, I now added the tests in Appendix F.46.8
>>> where I disable the caches and the tests in Appendix F.46.9 where I
>>> disable the caches and interrupts.
>>
>>What you've added in F.46 is a good start, but as a suggestiom,
>>instead of disabling one thing at a time, try disabling *everything*
>>and then see what you get, and then enabling one thing at a time. The
>>best thing is if you can get to the point where the amount of entropy
>>is close to zero. Then as you add things back, there's a much better
>
>I will try to do that.
>
>But please see the different lower boundary values in the different
>subsections of F.46: none of them fall when I disable or change
>anything in the base system (except the power management -- where I
>added additional analyses). Some of the changes imply that the jitter
>increases when I disable certain support.
>
>Thus, expect that we will not see a significant drop in the jitter as
>you fear or expect.
>
>Yet, I will try and report back.
Please have a look at the updated documentation, appendix F.46.10
provided in [1].
The interesting result is that some combinations of disabling CPU
support do reduce the CPU execution jitter. However, disabling all
support is not the lowest jitter measurement.
Though, none of the tried combinations deteriorate the measurement so
much that the execution jitter would be insufficient for use in the RNG.
[...]
>>sense of where the unpredictability might be coming from, and whether
>>the unpredictability is coming from something which is fundamentally
>>arising from something which is chaotic or quantum effect, or just
>>because we don't have a good way of modelling the behavior of the
>>L1/L2 cache (for example) and that is spoofing your entropy estimator.
>
>Please note: if the jitter really comes from the oscillator effect of
>the RAM clock vs. the CPU clock (which I suspect), we will not be able
>to alter the jitter software wise.
My current conclusion is that software can have some impact on the
execution jitter (as it is visible when executing different OSes on the
same hardware system as outlined in appendix F.45.
But none of the software impacts can deteriorate the jitter to the level
that it is not usable any more for the RNG and still keep the claim that
each output bit would have one bit of entropy.
[1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
Ciao
Stephan
^ permalink raw reply
* [PATCH] crypto: omap-aes: Fix CTR mode counter length
From: Joel Fernandes @ 2013-10-29 22:37 UTC (permalink / raw)
To: linux-crypto; +Cc: linux-omap, linux-kernel, Herbert Xu, Joel Fernandes
NIST vectors for CTR mode in testmgr.h assume the entire IV as the counter. To
get correct results that match the output of these vectors, we need to set the
counter length correctly.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ce791c2..19055a1 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -275,7 +275,7 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
if (dd->flags & FLAGS_CBC)
val |= AES_REG_CTRL_CBC;
if (dd->flags & FLAGS_CTR) {
- val |= AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_32;
+ val |= AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_128;
mask = AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_MASK;
}
if (dd->flags & FLAGS_ENCRYPT)
--
1.8.1.2
^ permalink raw reply related
* [RFC] Unaligned CTR mode tests in crypto/testmgr.h
From: Joel Fernandes @ 2013-10-30 0:11 UTC (permalink / raw)
To: jussi.kivilinna; +Cc: Linux Crypto Mailing List
Hi,
Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a unaligned
input buffer size such as 499 which is not aligned to any > 0 power of 2.
Due to this, omap-aes driver, and I think atmel-aes too error out when
encryption is requested for these buffers.
pr_err("request size is not exact amount of AES blocks\n") or a similar message.
Is this failure considered a bug? How do we fix it?
How were the result output vectors generated, did you use 0 padding? Do we 0 pad
the inputs to align in these cases to get correct results?
thanks,
-Joel
^ permalink raw reply
* Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h
From: Herbert Xu @ 2013-10-30 1:54 UTC (permalink / raw)
To: Joel Fernandes; +Cc: jussi.kivilinna, linux-crypto
In-Reply-To: <52704EAB.5000308@ti.com>
Joel Fernandes <joelf@ti.com> wrote:
> Hi,
>
> Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a unaligned
> input buffer size such as 499 which is not aligned to any > 0 power of 2.
>
> Due to this, omap-aes driver, and I think atmel-aes too error out when
> encryption is requested for these buffers.
>
> pr_err("request size is not exact amount of AES blocks\n") or a similar message.
>
> Is this failure considered a bug? How do we fix it?
Set your alignmask correctly and the crypto API will align the
input buffer for you.
Cheers,
--
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
^ permalink raw reply
* Re: [PATCH 1/3] crypto: caam - Add Platform driver for Job Ring
From: Herbert Xu @ 2013-10-30 4:11 UTC (permalink / raw)
To: Ruchika Gupta; +Cc: linux-crypto
In-Reply-To: <1382682663-18651-1-git-send-email-ruchika.gupta@freescale.com>
On Fri, Oct 25, 2013 at 12:01:01PM +0530, Ruchika Gupta wrote:
> The SEC Job Rings are now available as individual devices.
> This would enable sharing of job rings between kernel and
> user space. Job Rings can now be dynamically bound/unbound
> from kernel.
>
> Changes are made in the following layers of CAAM Driver
> 1. Controller driver
> - Does basic initialization of CAAM Block.
> - Creates platform devices for Job Rings.
> (Earlier the initialization of Job ring was done
> by the controller driver)
>
> 2. JobRing Platform driver
> - Manages the platform Job Ring devices created
> by the controller driver
>
> Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
> Reviewed-by: Garg Vakul-B16394 <vakul@freescale.com>
All applied. Thanks.
--
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
^ permalink raw reply
* Re: [PATCH RESEND] padata: make the sequence counter an atomic_t
From: Herbert Xu @ 2013-10-30 4:11 UTC (permalink / raw)
To: Mathias Krause; +Cc: Steffen Klassert, linux-crypto
In-Reply-To: <1382696055-24264-1-git-send-email-mathias.krause@secunet.com>
On Fri, Oct 25, 2013 at 12:14:15PM +0200, Mathias Krause wrote:
> Using a spinlock to atomically increase a counter sounds wrong -- we've
> atomic_t for this!
>
> Also move 'seq_nr' to a different cache line than 'lock' to reduce cache
> line trashing. This has the nice side effect of decreasing the size of
> struct parallel_data from 192 to 128 bytes for a x86-64 build, e.g.
> occupying only two instead of three cache lines.
>
> Those changes results in a 5% performance increase on an IPsec test run
> using pcrypt.
>
> Btw. the seq_lock spinlock was never explicitly initialized -- one more
> reason to get rid of it.
>
> Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Patch applied. Thanks!
--
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
^ permalink raw reply
* Re: [PATCH] CRYPTO: omap-sham: Add missing modalias
From: Herbert Xu @ 2013-10-30 4:11 UTC (permalink / raw)
To: Pali Rohár
Cc: David S. Miller, linux-crypto, linux-kernel, Joni Lapilainen
In-Reply-To: <1382821241-31180-1-git-send-email-pali.rohar@gmail.com>
On Sat, Oct 26, 2013 at 11:00:41PM +0200, Pali Rohár wrote:
> From: Joni Lapilainen <joni.lapilainen@gmail.com>
>
> Signed-off-by: Joni Lapilainen <joni.lapilainen@gmail.com>
Patch applied.
--
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
^ permalink raw reply
* Re: [PATCH] crypto: omap-aes: Fix CTR mode counter length
From: Herbert Xu @ 2013-10-30 4:11 UTC (permalink / raw)
To: Joel Fernandes; +Cc: linux-crypto, linux-omap, linux-kernel
In-Reply-To: <1383086258-22186-1-git-send-email-joelf@ti.com>
On Tue, Oct 29, 2013 at 05:37:38PM -0500, Joel Fernandes wrote:
> NIST vectors for CTR mode in testmgr.h assume the entire IV as the counter. To
> get correct results that match the output of these vectors, we need to set the
> counter length correctly.
>
> Signed-off-by: Joel Fernandes <joelf@ti.com>
Patch applied. Thanks!
--
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
^ permalink raw reply
* Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h
From: Jussi Kivilinna @ 2013-10-30 11:09 UTC (permalink / raw)
To: Joel Fernandes; +Cc: Linux Crypto Mailing List
In-Reply-To: <52704EAB.5000308@ti.com>
On 30.10.2013 02:11, Joel Fernandes wrote:
> Hi,
>
> Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a unaligned
> input buffer size such as 499 which is not aligned to any > 0 power of 2.
>
> Due to this, omap-aes driver, and I think atmel-aes too error out when
> encryption is requested for these buffers.
>
> pr_err("request size is not exact amount of AES blocks\n") or a similar message.
>
> Is this failure considered a bug? How do we fix it?
Counter mode turns block cipher into stream cipher and implementation must handle
buffer lengths that do not match the block size of underlying block cipher.
>
> How were the result output vectors generated, did you use 0 padding? Do we 0 pad
> the inputs to align in these cases to get correct results?
See crypto/ctr.c:crypto_ctr_crypt_final() how to handle trailing bytes when
'buflen % AES_BLOCK_SIZE != 0'.
Basically, you encrypt the last counter block to generate the last keystream
block and xor only the 'buflen % AES_BLOCK_SIZE' bytes of last keystream block
with the tail bytes of source buffer:
key_last[0..15] = ENC(K, counter[0..15]);
dst_last[0..trailbytes-1] = src_last[0..trailbytes-1] ^ key_last[0..trailbytes-1];
/* key_last[trailbytes..15] discarded. */
Or if you want to use hardware that only does block-size aligned CTR encryption,
you can pad input to block size aligned length, do encryption, and then discard
those padding bytes after encryption:
src_padded[0..trailbytes-1] = src_last[0..trailbytes-1]
src_padded[trailbytes..15] = /* don't care, can be anything/uninitialized */
src_padded[0..15] = ENC_HW_CTR(src_padded[0..15]);
dst_last[0..trailbytes-1] = src_padded[0..trailbytes-1];
/* src_padded[trailbytes..15] discarded. */
Here, ENC_HW_CTR(in) internally does:
keystream[0..15] = ENC(K, counter[0..15]); INC_CTR(counter);
out[0..15] = in[0..15] ^ keystream[0..15];
-Jussi
>
> thanks,
>
> -Joel
> --
> 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
>
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Sandy Harris @ 2013-10-30 12:59 UTC (permalink / raw)
To: Theodore Ts'o, Stephan Mueller, sandy harris, LKML,
linux-crypto
In-Reply-To: <20131028214549.GA31746@thunk.org>
Theodore Ts'o <tytso@mit.edu> wrote:
> Fundamentally, what worries me about this scheme (actually, causes the
> hair on the back of my neck to rise up on end) is this statement in
> your documentation[1]:
>
> When looking at the sequence of time deltas gathered
> during testing [D] , no pattern can be detected. Therefore, the
> fluctuation and the resulting distribution are not based on a
> repeating pattern and must be considered random.
>
> [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
>
> Just because we can't detect a pattern does **not** mean that it is
> not based on a repeating pattern, and therefore must be considered
> random. We can't detect a pattern in RDRAND, so does that mean it's
> automatically random? Why, no.
> ...
> It may be that there is some very complex state which is hidden inside
> the the CPU execution pipeline, the L1 cache, etc., etc. But just
> because *you* can't figure it out, and just because *I* can't figure
> it out doesn't mean that it is ipso facto something which a really
> bright NSA analyst working in Fort Meade can't figure out. (Or heck,
> a really clever Intel engineer who has full visibility into the
> internal design of an Intel CPU....)
>
> Now, it may be that in practice, an adversary won't be able to carry
> out a practical attack ...
It seems worth noting here that Ted's reasons for skepticism
apply not just to Stephan's Jitter generator, but to others such
as Havege (already in Debian) which are based on differences
in speed of arithmetic operations, presumably due to cache
& TLB misses, pipeline stalls, etc. Also to ones based on
variations in delays from timer calls such as my maxwell(8).
It is also worth mentioning that, while Stephan has done
thorough testing on a range of CPUs, others have test
& rationale info as well. The Havege papers have a lot,
my maxwell paper has a little, and there's:
McGuire, Okech & Schiesser,
Analysis of inherent randomness of the Linux kernel,
http://lwn.net/images/conf/rtlws11/random-hardware.pdf
I know my stuff is not an adequate answer to Ted, but
I suspect some of the others may be.
^ permalink raw reply
* RE: [RFC] Unaligned CTR mode tests in crypto/testmgr.h
From: Fernandes, Joel @ 2013-10-30 18:34 UTC (permalink / raw)
To: Herbert Xu; +Cc: jussi.kivilinna@mbnet.fi, linux-crypto@vger.kernel.org
In-Reply-To: <20131030015424.GA1855@gondor.apana.org.au>
> -----Original Message-----
> From: Herbert Xu [mailto:herbert@gondor.hengli.com.au]
> Sent: Tuesday, October 29, 2013 8:54 PM
> To: Fernandes, Joel
> Cc: jussi.kivilinna@mbnet.fi; linux-crypto@vger.kernel.org
> Subject: Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h
>
> Joel Fernandes <joelf@ti.com> wrote:
> > Hi,
> >
> > Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a
> > unaligned input buffer size such as 499 which is not aligned to any > 0
> power of 2.
> >
> > Due to this, omap-aes driver, and I think atmel-aes too error out when
> > encryption is requested for these buffers.
> >
> > pr_err("request size is not exact amount of AES blocks\n") or a similar
> message.
> >
> > Is this failure considered a bug? How do we fix it?
>
> Set your alignmask correctly and the crypto API will align the input buffer for
> you.
Thanks! I'll try this today and follow up with a patch if I can get past the error.
Regards,
-Joel
^ permalink raw reply
* Re: [PATCH 29/51] DMA-API: ata: pata_octeon_cf: convert to use dma_coerce_mask_and_coherent()
From: Geert Uytterhoeven @ 2013-10-30 19:08 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, Linux MMC List,
Linux Fbdev development list, linux-nvme,
linux-ide@vger.kernel.org, driverdevel, linux-samsung-soc, scsi,
e1000-devel, Linux-Next, b43-dev, Linux Media Mailing List,
devicetree, DRI Development, linux-tegra,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Solarflare linux maintainers, netdev@vger.kernel.org
In-Reply-To: <E1VMmAk-0007iq-IU@rmk-PC.arm.linux.org.uk>
On Thu, Sep 19, 2013 at 11:54 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c
> index c51bbb9..6231d43 100644
> --- a/drivers/ata/pata_octeon_cf.c
> +++ b/drivers/ata/pata_octeon_cf.c
> @@ -1014,8 +1014,9 @@ static int octeon_cf_probe(struct platform_device *pdev)
> }
> cf_port->c0 = ap->ioaddr.ctl_addr;
>
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> + rv = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> + if (rv)
> + return ret;
return rv;
http://kisskb.ellerman.id.au/kisskb/buildresult/9959184/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox