user/sven/linux.git/arch, branch v3.4.92

crypto: s390 - Fix aes-xts parameter corruption

2014-06-07T23:02:15Z

commit 9dda2769af4f3f3093434648c409bb351120d9e8 upstream. Some s390 crypto algorithms incorrectly use the crypto_tfm structure to store private data. As the tfm can be shared among multiple threads, this can result in data corruption. This patch fixes aes-xts by moving the xts and pcc parameter blocks from the tfm onto the stack (48 + 96 bytes). Signed-off-by: Gerald Schaefer Signed-off-by: Herbert Xu [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Qiang Huang Signed-off-by: Greg Kroah-Hartman

crypto: s390 - Fix aes-cbc IV corruption

2014-06-07T23:02:15Z

commit f262f0f5cad0c9eca61d1d383e3b67b57dcbe5ea upstream. The cbc-aes-s390 algorithm incorrectly places the IV in the tfm data structure. As the tfm is shared between multiple threads, this introduces a possibility of data corruption. This patch fixes this by moving the parameter block containing the IV and key onto the stack (the block is 48 bytes long). The same bug exists elsewhere in the s390 crypto system and they will be fixed in subsequent patches. Signed-off-by: Herbert Xu [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Qiang Huang Signed-off-by: Greg Kroah-Hartman

x86/efi: Fix dummy variable buffer allocation

2014-06-07T23:02:10Z

commit b8cb62f82103083a6e8fa5470bfe634a2c06514d upstream. 1. Check for allocation failure 2. Clear the buffer contents, as they may actually be written to flash 3. Don't leak the buffer Compile-tested only. [ Tested successfully on my buggy ASUS machine - Matt ] Signed-off-by: Ben Hutchings Signed-off-by: Matt Fleming Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

Modify UEFI anti-bricking code

2014-06-07T23:02:10Z

commit f8b8404337de4e2466e2e1139ea68b1f8295974f upstream. This patch reworks the UEFI anti-bricking code, including an effective reversion of cc5a080c and 31ff2f20. It turns out that calling QueryVariableInfo() from boot services results in some firmware implementations jumping to physical addresses even after entering virtual mode, so until we have 1:1 mappings for UEFI runtime space this isn't going to work so well. Reverting these gets us back to the situation where we'd refuse to create variables on some systems because they classify deleted variables as "used" until the firmware triggers a garbage collection run, which they won't do until they reach a lower threshold. This results in it being impossible to install a bootloader, which is unhelpful. Feedback from Samsung indicates that the firmware doesn't need more than 5KB of storage space for its own purposes, so that seems like a reasonable threshold. However, there's still no guarantee that a platform will attempt garbage collection merely because it drops below this threshold. It seems that this is often only triggered if an attempt to write generates a genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to create a variable larger than the remaining space. This should fail, but if it somehow succeeds we can then immediately delete it. I've tested this on the UEFI machines I have available, but I don't have a Samsung and so can't verify that it avoids the bricking problem. Signed-off-by: Matthew Garrett Signed-off-by: Lee, Chun-Y [ dummy variable cleanup ] Signed-off-by: Matt Fleming [bwh: Backported to 3.2: the reverted changes were never applied here] Signed-off-by: Ben Hutchings Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

x86,efi: Implement efi_no_storage_paranoia parameter

2014-06-07T23:02:10Z

commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2 upstream. Using this parameter one can disable the storage_size/2 check if he is really sure that the UEFI does sane gc and fulfills the spec. This parameter is useful if a devices uses more than 50% of the storage by default. The Intel DQSW67 desktop board is such a sucker for exmaple. Signed-off-by: Richard Weinberger Signed-off-by: Matt Fleming [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

efi: Export efi_query_variable_store() for efivars.ko

2014-06-07T23:02:10Z

commit 3668011d4ad556224f7c012c1e870a6eaa0e59da upstream. Fixes build with CONFIG_EFI_VARS=m which was broken after the commit "x86, efivars: firmware bug workarounds should be in platform code". Signed-off-by: Sergey Vlasov Signed-off-by: Matt Fleming Signed-off-by: Ben Hutchings Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

x86,efi: Check max_size only if it is non-zero.

2014-06-07T23:02:10Z

commit 7791c8423f1f7f4dad94e753bae67461d5b80be8 upstream. Some EFI implementations return always a MaximumVariableSize of 0, check against max_size only if it is non-zero. My Intel DQ67SW desktop board has such an implementation. Signed-off-by: Richard Weinberger Signed-off-by: Matt Fleming Signed-off-by: Ben Hutchings Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

x86, efivars: firmware bug workarounds should be in platform code

2014-06-07T23:02:10Z

commit a6e4d5a03e9e3587e88aba687d8f225f4f04c792 upstream. Let's not burden ia64 with checks in the common efivars code that we're not writing too much data to the variable store. That kind of thing is an x86 firmware bug, plain and simple. efi_query_variable_store() provides platforms with a wrapper in which they can perform checks and workarounds for EFI variable storage bugs. Cc: H. Peter Anvin Cc: Matthew Garrett Signed-off-by: Matt Fleming [xr: Backported to 3.4: adjust context] Signed-off-by: Rui Xiang Signed-off-by: Greg Kroah-Hartman

x86/Sandy Bridge: mark arrays in init functions as initconst

2014-06-07T23:02:09Z

commit 91c90db1aa92a50fa1d7f289502b49ddb46a90d3 upstream. commit ab3cd8670e0b3fcde7f029e1503ed3c5138e9571 upstream. Mark static arrays as __initconst so they get removed when the init sections are flushed. Reported-by: Mathias Krause Link: http://lkml.kernel.org/r/75F4BEE6-CB0E-4426-B40B-697451677738@googlemail.com Signed-off-by: H. Peter Anvin Signed-off-by: Ben Hutchings Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

ptrace/x86: Partly fix set_task_blockstep()->update_debugctlmsr() logic

2014-06-07T23:02:09Z

commit 95cf00fa5d5e2a200a2c044c84bde8389a237e02 upstream. Afaics the usage of update_debugctlmsr() and TIF_BLOCKSTEP in step.c was always very wrong. 1. update_debugctlmsr() was simply unneeded. The child sleeps TASK_TRACED, __switch_to_xtra(next_p => child) should notice TIF_BLOCKSTEP and set/clear DEBUGCTLMSR_BTF after resume if needed. 2. It is wrong. The state of DEBUGCTLMSR_BTF bit in CPU register should always match the state of current's TIF_BLOCKSTEP bit. 3. Even get_debugctlmsr() + update_debugctlmsr() itself does not look right. Irq can change other bits in MSR_IA32_DEBUGCTLMSR register or the caller can be preempted in between. 4. It is not safe to play with TIF_BLOCKSTEP if task != current. DEBUGCTLMSR_BTF and TIF_BLOCKSTEP should always match each other if the task is running. The tracee is stopped but it can be SIGKILL'ed right before set/clear_tsk_thread_flag(). However, now that uprobes uses user_enable_single_step(current) we can't simply remove update_debugctlmsr(). So this patch adds the additional "task == current" check and disables irqs to avoid the race with interrupts/preemption. Unfortunately this patch doesn't solve the last problem, we need another fix. Probably we should teach ptrace_stop() to set/clear single/block stepping after resume. And afaics there is yet another problem: perf can play with MSR_IA32_DEBUGCTLMSR from nmi, this obviously means that even __switch_to_xtra() has problems. Signed-off-by: Oleg Nesterov Signed-off-by: Ben Hutchings Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

user/sven/linux.git/arch, branch v3.4.92

crypto: s390 - Fix aes-xts parameter corruption

crypto: s390 - Fix aes-cbc IV corruption

x86/efi: Fix dummy variable buffer allocation

Modify UEFI anti-bricking code

x86,efi: Implement efi_no_storage_paranoia parameter

efi: Export efi_query_variable_store() for efivars.ko

x86,efi: Check max_size only if it is non-zero.

x86, efivars: firmware bug workarounds should be in platform code

x86/Sandy Bridge: mark arrays in __init functions as __initconst

ptrace/x86: Partly fix set_task_blockstep()->update_debugctlmsr() logic

x86/Sandy Bridge: mark arrays in init functions as initconst