linux-stable.git/drivers/char/hw_random, branch linux-2.6.26.y

crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()

2008-08-20T18:05:15+00:00

crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()

[ Upstream commit: e49140120c88eb99db1a9172d9ac224c0f2bbdd2 ]

Wolfgang Walter reported this oops on his via C3 using padlock for
AES-encryption:

##################################################################

BUG: unable to handle kernel NULL pointer dereference at 000001f0
IP: [] __switch_to+0x30/0x117
*pde = 00000000
Oops: 0002 [#1] PREEMPT
Modules linked in:

Pid: 2071, comm: sleep Not tainted (2.6.26 #11)
EIP: 0060:[] EFLAGS: 00010002 CPU: 0
EIP is at __switch_to+0x30/0x117
EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300
ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000)
Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046
   c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000
   c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0
Call Trace:
[] ? schedule+0x285/0x2ff
[] ? pm_qos_requirement+0x3c/0x53
[] ? acpi_processor_idle+0x0/0x434
[] ? cpu_idle+0x73/0x7f
[] ? rest_init+0x61/0x63
=======================

Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end()
around the padlock instructions fix the oops.

Suresh wrote:

These padlock instructions though don't use/touch SSE registers, but it behaves
similar to other SSE instructions. For example, it might cause DNA faults
when cr0.ts is set. While this is a spurious DNA trap, it might cause
oops with the recent fpu code changes.

This is the code sequence  that is probably causing this problem:

a) new app is getting exec'd and it is somewhere in between
start_thread() and flush_old_exec() in the load_xyz_binary()

b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is
cleared.

c) Now we get an interrupt/softirq which starts using these encrypt/decrypt
routines in the network stack. This generates a math fault (as
cr0.ts is '1') which sets TS_USEDFPU and restores the math that is
in the task's xstate.

d) Return to exec code path, which does start_thread() which does
free_thread_xstate() and sets xstate pointer to NULL while
the TS_USEDFPU is still set.

e) At the next context switch from the new exec'd task to another task,
we have a scenarios where TS_USEDFPU is set but xstate pointer is null.
This can cause an oops during unlazy_fpu() in __switch_to()

Now:

1) This should happen with or with out pre-emption. Viro also encountered
similar problem with out CONFIG_PREEMPT.

2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because
kernel_fpu_begin() will manually do a clts() and won't run in to the
situation of setting TS_USEDFPU in step "c" above.

3) This was working before the fpu changes, because its a spurious
math fault  which doesn't corrupt any fpu/sse registers and the task's
math state was always in an allocated state.

With out the recent lazy fpu allocation changes, while we don't see oops,
there is a possible race still present in older kernels(for example,
while kernel is using kernel_fpu_begin() in some optimized clear/copy
page and an interrupt/softirq happens which uses these padlock
instructions generating DNA fault).

This is the failing scenario that existed even before the lazy fpu allocation
changes:

0. CPU's TS flag is set

1. kernel using FPU in some optimized copy  routine and while doing
kernel_fpu_begin() takes an interrupt just before doing clts()

2. Takes an interrupt and ipsec uses padlock instruction. And we
take a DNA fault as TS flag is still set.

3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts

4. We complete the padlock routine

5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes
the optimized copy routine and does kernel_fpu_end(). At this point,
we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll
set and not cleared.

6. Now kernel resumes its user operation. And at the next context
switch, kernel sees it has do a FP save as TS_USEDFPU is still set
and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu()
will take a DNA fault, as cr0.ts is '1' and now, because we are
in __switch_to(), math_state_restore() will get confused and will
restore the next task's FP state and will save it in prev tasks's FP state.
Remember, in __switch_to() we are already on the stack of the next task
but take a DNA fault for the prev task.

This causes the fpu leakage.

Fix the padlock instruction usage by calling them inside the
context of new routines irq_ts_save/restore(), which clear/restore cr0.ts
manually in the interrupt context. This will not generate spurious DNA
in the  context of the interrupt which will fix the oops encountered and
the possible FPU leakage issue.

Reported-and-bisected-by: Wolfgang Walter 
Signed-off-by: Suresh Siddha 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

intel_rng: make device not found a warning

2008-06-13T01:05:41+00:00

Since many distros load this driver by default (throw it against the wall
and see what sticks method).  Change the error message severity level to
avoid alarming users.  Isn't it annoying when users actually read the
error logs...

Signed-off-by: Stephen Hemminger 
Cc: Michael Buesch 
Acked-by: Jan Beulich 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

virtio: An entropy device, as suggested by hpa.

2008-05-30T05:09:44+00:00

Note that by itself, having a "hardware" random generator does very
little: you should probably run "rngd" in your guest to feed this into
the kernel entropy pool.

Included:
	virtio_rng: dont use vmalloced addresses for virtio

	If virtio_rng is build as a module, random_data is an address
	in vmalloc space. As virtio expects guest real addresses, this
	can cause any kind of funny behaviour, so lets allocate
	random_data dynamically with kmalloc.

	Signed-off-by: Christian Borntraeger 

Signed-off-by: Rusty Russell

Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2008-04-21T22:57:09+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  [HWRNG] omap: Minor updates
  [CRYPTO] kconfig: Ordering cleanup
  [CRYPTO] all: Clean up init()/fini()
  [CRYPTO] padlock-aes: Use generic setkey function
  [CRYPTO] aes: Export generic setkey
  [CRYPTO] api: Make the crypto subsystem fully modular
  [CRYPTO] cts: Add CTS mode required for Kerberos AES support
  [CRYPTO] lrw: Replace all adds to big endians variables with be*_add_cpu
  [CRYPTO] tcrypt: Change the XTEA test vectors
  [CRYPTO] tcrypt: Shrink the tcrypt module
  [CRYPTO] tcrypt: Change the usage of the test vectors
  [CRYPTO] api: Constify function pointer tables
  [CRYPTO] aes-x86-32: Remove unused return code
  [CRYPTO] tcrypt: Shrink speed templates
  [CRYPTO] tcrypt: Group common speed templates
  [CRYPTO] sha512: Rename sha512 to sha512_generic
  [CRYPTO] sha384: Hardware acceleration for s390
  [CRYPTO] sha512: Hardware acceleration for s390
  [CRYPTO] s390: Generic sha_update and sha_final
  [CRYPTO] api: Switch to proc_create()

[HWRNG] omap: Minor updates

2008-04-21T02:19:34+00:00

Minor cleanups to the OMAP RNG:

 - Comment update re RNG status:
     * yes, it works on 16xx; "rngtest" is quite happy
     * it's fast enough that polling vs IRQ is a non-issue
 - Get rid of BUG_ON
 - Help GCC not be stupid about inlining (object code shrink)
 - Remove "sparse" warning
 - Cope with new hotplug rule requiring "platform:" modalias

And make the file header match kernel conventions.

Signed-off-by: David Brownell 
Signed-off-by: Herbert Xu

PM: Remove destroy_suspended_device()

2008-04-20T02:10:28+00:00

After 2.6.24 there was a plan to make the PM core acquire all device
semaphores during a suspend/hibernation to protect itself from
concurrent operations involving device objects.  That proved to be
too heavy-handed and we found a better way to achieve the goal, but
before it happened, we had introduced the functions
device_pm_schedule_removal() and destroy_suspended_device() to allow
drivers to "safely" destroy a suspended device and we had adapted some
drivers to use them.  Now that these functions are no longer necessary,
it seems reasonable to remove them and modify their users to use the
normal device unregistration instead.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Signed-off-by: Greg Kroah-Hartman

[S390] hw_random: allow rng_dev_read() to return hardware errors.

2008-04-17T05:47:02+00:00

The api for hardware random number generators is currently limited to
devices that never fail. If the hardware is registered as a source for
random numbers it has to work. This prevents the use of i/o based
random number devices where the i/o might fail.

Add a check for errors after the read from a hardware random number device.

This patch is required to support large random numbers retrieved
from the CEX2C cards on System z.

Signed-off-by: Ralph Wuerthner 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Heiko Carstens

hw_random doc updates

2008-03-25T02:22:19+00:00

Update documentation for the hw_random support to be current:

 - Documentation/hw_random.txt has been updated to reflect the
   current code:  it's a framework now, a "core" with a small
   sysfs interface, that hardware-specific drivers plug in to.
   Text specific to Intel hardware is now at the end.

 - Kconfig now references the Documentation/hw_random.txt file
   and better explains what this really does.

Both chunks of documentation now higlight the fact that the kernel entropy
pool is maintained by "rngd", and this driver has nothing directly to do with
that important task.

Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

via-rng: enable secondary noise source on CPUs where it is present

2008-02-06T18:41:05+00:00

In the padlock spec:

"SRC Bits[9:8] Noise source select (I): These bits control the two noise
 sources on the processor that input bits to the accumulation buffers.
 On Nehemiah processors prior to stepping 8, these bits are reserved
 and undefined. The default RESET state is both bits = 0."

Signed-off-by: Dave Jones 
Tested-by: Udo van den Heuvel 
Cc: Michael Buesch 
Cc: folkert van Heusden 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

HWRNG: add possibility to remove hwrng devices during suspend/resume

2008-02-05T17:44:23+00:00

Make it possible to unregister a Hardware Random Number Generator
device object in a safe way during a suspend/resume cycle.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Michael Buesch 
Cc: Michael Buesch 
Cc: Pavel Machek 
Cc: "John W. Linville" 
Cc: Alan Stern 
Cc: Len Brown 
Cc: Greg KH 
Cc: Kay Sievers 
Cc: Richard Purdie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds