- 08 Nov, 2017 1 commit
-
-
Ingo Molnar authored
The UMIP series is based on top of changes already queued up in the x86/mpx branch, so merge it. Signed-off-by:Ingo Molnar <mingo@kernel.org>
-
- 07 Nov, 2017 32 commits
-
-
kbuild test robot authored
arch/x86/kernel/crash.c:627:34-37: ERROR: Missing resource_size with res arch/x86/kernel/crash.c:528:16-19: ERROR: Missing resource_size with res Use resource_size function on resource object instead of explicit computation. Generated by: scripts/coccinelle/api/resource_size.cocci Fixes: 1d2e733b ("resource: Provide resource struct in resource walk callback") Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Kees Cook <keescook@chromium.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: kbuild-all@01.org Cc: tipbuild@zytor.com Cc: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20171107191801.GA91887@lkp-snb01
-
Brijesh Singh authored
The guest physical memory area holding the struct pvclock_wall_clock and struct pvclock_vcpu_time_info are shared with the hypervisor. It periodically updates the contents of the memory. When SEV is active, the encryption attributes from the shared memory pages must be cleared so that both hypervisor and guest can access the data. Signed-off-by:
Brijesh Singh <brijesh.singh@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
-
Brijesh Singh authored
When SEV is active, guest memory is encrypted with a guest-specific key, a guest memory region shared with the hypervisor must be mapped as decrypted before it can be shared. Signed-off-by:
-
Brijesh Singh authored
KVM guest defines three per-CPU variables (steal-time, apf_reason, and kvm_pic_eoi) which are shared between a guest and a hypervisor. When SEV is active, memory is encrypted with a guest-specific key, and if the guest OS wants to share the memory region with the hypervisor then it must clear the C-bit (i.e set decrypted) before sharing it. DEFINE_PER_CPU_DECRYPTED can be used to define the per-CPU variables which will be shared between a guest and a hypervisor. Signed-off-by:
Tejun Heo <tj@kernel.org> Reviewed-by:
-
Brijesh Singh authored
Some KVM-specific custom MSRs share the guest physical address with the hypervisor in early boot. When SEV is active, the shared physical address must be mapped with memory encryption attribute cleared so that both hypervisor and guest can access the data. Add APIs to change the memory encryption attribute in early boot code. Signed-off-by:
-
Tom Lendacky authored
Secure Encrypted Virtualization (SEV) does not support string I/O, so unroll the string I/O operation into a loop operating on one element at a time. [ tglx: Gave the static key a real name instead of the obscure __sev ] Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Tom Lendacky authored
Early in the boot process, add checks to determine if the kernel is running with Secure Encrypted Virtualization (SEV) active. Checking for SEV requires checking that the kernel is running under a hypervisor (CPUID 0x00000001, bit 31), that the SEV feature is available (CPUID 0x8000001f, bit 1) and then checking a non-interceptable SEV MSR (0xc0010131, bit 0). This check is required so that during early compressed kernel booting the pagetables (both the boot pagetables and KASLR pagetables (if enabled) are updated to include the encryption mask so that when the kernel is decompressed into encrypted memory, it can boot properly. After the kernel is decompressed and continues booting the same logic is used to check if SEV is active and set a flag indicating so. This allows to distinguish between SME and SEV, each of which have unique differences in how certain things are handled: e.g. DMA (always bounce buffered with SEV) or EFI tables (always access decrypted with SME). Signed-off-by:
-
Tom Lendacky authored
DMA access to encrypted memory cannot be performed when SEV is active. In order for DMA to properly work when SEV is active, the SWIOTLB bounce buffers must be used. Signed-off-by:
-
Tom Lendacky authored
In order for memory pages to be properly mapped when SEV is active, it's necessary to use the PAGE_KERNEL protection attribute as the base protection. This ensures that memory mapping of, e.g. ACPI tables, receives the proper mapping attributes. Signed-off-by:
-
Tom Lendacky authored
In preperation for a new function that will need additional resource information during the resource walk, update the resource walk callback to pass the resource structure. Since the current callback start and end arguments are pulled from the resource structure, the callback functions can obtain them from the resource structure directly. Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
-
Tom Lendacky authored
The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() functions each have much of the same code. Create a new function that consolidates the common code from these functions in one place to reduce the amount of duplicated code. Signed-off-by:
-
Tom Lendacky authored
EFI data is encrypted when the kernel is run under SEV. Update the page table references to be sure the EFI memory areas are accessed encrypted. Signed-off-by:
-
Tom Lendacky authored
The current code checks only for sme_active() when determining whether to perform the encryption attribute change. Include sev_active() in this check so that memory attribute changes can occur under SME and SEV. Signed-off-by:
-
Tom Lendacky authored
When Secure Encrypted Virtualization (SEV) is active, boot data (such as EFI related data, setup data) is encrypted and needs to be accessed as such when mapped. Update the architecture override in early_memremap to keep the encryption attribute when mapping this data. Signed-off-by:
-
Tom Lendacky authored
When SEV is active the trampoline area will need to be in encrypted memory so only mark the area decrypted if SME is active. Signed-off-by:
-
Tom Lendacky authored
When SEV is active the initrd/initramfs will already have already been placed in memory encrypted so do not try to encrypt it. Signed-off-by:
-
Tom Lendacky authored
Provide support for Secure Encrypted Virtualization (SEV). This initial support defines a flag that is used by the kernel to determine if it is running with SEV active. Signed-off-by:
-
Brijesh Singh authored
Update the AMD memory encryption document describing the Secure Encrypted Virtualization (SEV) feature. Signed-off-by:
-
Zhou Chengming authored
We use alternatives_text_reserved() to check if the address is in the fixed pieces of alternative reserved, but the problem is that we don't hold the smp_alt mutex when call this function. So the list traversal may encounter a deleted list_head if another path is doing alternatives_smp_module_del(). One solution is that we can hold smp_alt mutex before call this function, but the difficult point is that the callers of this functions, arch_prepare_kprobe() and arch_prepare_optimized_kprobe(), are called inside the text_mutex. So we must hold smp_alt mutex before we go into these arch dependent code. But we can't now, the smp_alt mutex is the arch dependent part, only x86 has it. Maybe we can export another arch dependent callback to solve this. But there is a simpler way to handle this problem. We can reuse the text_mutex to protect smp_alt_modules instead of using another mutex. And all the arch dependent checks of kprobes are inside the text_mutex, so it's safe now. Signed-off-by:
Zhou Chengming <zhouchengming1@huawei.com> Reviewed-by:
Masami Hiramatsu <mhiramat@kernel.org> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@suse.de Fixes: 2cfa1978 "ftrace/alternatives: Introducing *_text_reserved functions" Link: http://lkml.kernel.org/r/1509585501-79466-1-git-send-email-zhouchengming1@huawei.comSigned-off-by:
-
Changbin Du authored
Some of the files generated by the build process were not listed. Signed-off-by:
Changbin Du <changbin.du@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: yamada.masahiro@socionext.com Link: http://lkml.kernel.org/r/1509939179-7556-5-git-send-email-changbin.du@intel.comSigned-off-by:
-
Changbin Du authored
It avoids the following warning triggered by newer versions of mkisofs: -input-charset not specified, using utf-8 (detected in locale settings) Signed-off-by: -
Changbin Du authored
Recently I failed to build isoimage target, because the path of isolinux.bin changed to /usr/xxx/ISOLINUX/isolinux.bin, as well as ldlinux.c32 which changed to /usr/xxx/syslinux/modules/bios/ldlinux.c32. This patch improves the file search logic: - Show a error message instead of silent fail. - Add above new paths. Signed-off-by:
-
Changbin Du authored
The build messages for fdimage/isoimage generation are pretty unstructured, just the raw shell command blocks are printed. Emit shortened messages similar to existing kbuild messages, and move the Makefile commands into a separate shell script - which is much easier to handle. This patch factors out the commands used for fdimage/isoimage generation from arch/x86/boot/Makefile to a new script arch/x86/boot/genimage.sh. Then it adds the new kbuild command 'genimage' which invokes the new script. All fdimages/isoimage files are now generated by a call to 'genimage' with different parameters. Now 'make isoimage' becomes: ... Kernel: arch/x86/boot/bzImage is ready (#30) GENIMAGE arch/x86/boot/image.iso Size of boot image is 4 sectors -> No emulation 15.37% done, estimate finish Sun Nov 5 23:36:57 2017 30.68% done, estimate finish Sun Nov 5 23:36:57 2017 46.04% done, estimate finish Sun Nov 5 23:36:57 2017 61.35% done, estimate finish Sun Nov 5 23:36:57 2017 76.69% done, estimate finish Sun Nov 5 23:36:57 2017 92.00% done, estimate finish Sun Nov 5 23:36:57 2017 Total translation table size: 2048 Total rockridge attributes bytes: 659 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 0 32608 extents written (63 MB) Kernel: arch/x86/boot/image.iso is ready Before: Kernel: arch/x86/boot/bzImage is ready (#63) rm -rf arch/x86/boot/isoimage mkdir arch/x86/boot/isoimage for i in lib lib64 share end ; do \ if [ -f /usr/$i/syslinux/isolinux.bin ] ; then \ cp /usr/$i/syslinux/isolinux.bin arch/x86/boot/isoimage ; \ if [ -f /usr/$i/syslinux/ldlinux.c32 ]; then \ cp /usr/$i/syslinux/ldlinux.c32 arch/x86/boot/isoimage ; \ fi ; \ break ; \ fi ; \ if [ $i = end ] ; then exit 1 ; fi ; \ done ... Suggested-by:
-
Andy Lutomirski authored
We weren't testing the .limit and .limit_in_pages fields very well. Add more tests. This addition seems to trigger the "bits 16:19 are undefined" issue that was fixed in an earlier patch. I think that, at least on my CPU, the high nibble of the limit ends in LAR bits 16:19. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bpetkov@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/5601c15ea9b3113d288953fd2838b18bedf6bc67.1509794321.git.luto@kernel.orgSigned-off-by:
-
Andy Lutomirski authored
Now that the main test infrastructure supports the GDT, run tests that will pass the kernel's GDT permission tests against the GDT. Signed-off-by:
-
Andy Lutomirski authored
Much of the test design could apply to set_thread_area() (i.e. GDT), not just modify_ldt(). Add set_thread_area() to the install_valid_mode() helper. Signed-off-by:
-
Andy Lutomirski authored
Bits 19:16 of LAR's result are undefined, and some upcoming improvements to the test case seem to trigger this. Mask off those bits to avoid spurious failures. commit 5b781c7e ("x86/tls: Forcibly set the accessed bit in TLS segments") adds a valid case in which LAR's output doesn't quite agree with set_thread_area()'s input. This isn't triggered in the test as is, but it will be if we start calling set_thread_area() with the accessed bit clear. Work around this discrepency. I've added a Fixes tag so that -stable can pick this up if neccesary. Signed-off-by:
-
Andy Lutomirski authored
On new enough glibc, the pkey syscalls numbers are available. Check first before defining them to avoid warnings like: protection_keys.c:198:0: warning: "SYS_pkey_alloc" redefined Signed-off-by:
-
Ingo Molnar authored
Kept this commit separate from the re-tabulation changes, to make the changes easier to review: - add better explanation for entries with no explanation - fix/enhance the text of some of the entries - fix the vertical alignment of some of the feature number definitions - fix inconsistent capitalization - ... and lots of other small details i.e. make it all more of a coherent unit, instead of a patchwork of years of additions. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20171031121723.28524-4-mingo@kernel.orgSigned-off-by:
-
Ingo Molnar authored
Over the years asm/cpufeatures.h has become somewhat of a mess: the original tabulation style was too narrow, while x86 feature names also kept growing in length, creating frequent field width overflows. Re-tabulate it to make it wider and easier to read/modify. Also harmonize the tabulation of the other defines in this file to match it. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20171031121723.28524-3-mingo@kernel.orgSigned-off-by:
-
Ingo Molnar authored
Conflicts: arch/x86/entry/syscalls/Makefile Signed-off-by: -
Ingo Molnar authored
Conflicts: arch/x86/kernel/cpu/Makefile Signed-off-by:
-
- 06 Nov, 2017 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wqLinus Torvalds authored
Pull workqueue fix from Tejun Heo: "Another fix for a really old bug. It only affects drain_workqueue() which isn't used often and even then triggers only during a pretty small race window, so it isn't too surprising that it stayed hidden for so long. The fix is straight-forward and low-risk. Kudos to Li Bin for reporting and fixing the bug" * 'for-4.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Fix NULL pointer dereference
-
Tobin C. Harding authored
Currently we are leaking addresses from the kernel to user space. This script is an attempt to find some of those leakages. Script parses `dmesg` output and /proc and /sys files for hex strings that look like kernel addresses. Only works for 64 bit kernels, the reason being that kernel addresses on 64 bit kernels have 'ffff' as the leading bit pattern making greping possible. On 32 kernels we don't have this luxury. Scripts is _slightly_ smarter than a straight grep, we check for false positives (all 0's or all 1's, and vsyscall start/finish addresses). [ I think there is a lot of room for improvement here, but it's already useful, so I'm merging it as-is. The whole "hash %p format" series is expected to go into 4.15, but will not fix %x users, and will not incentivize people to look at what they are leaking. - Linus ] Signed-off-by:
Tobin C. Harding <me@tobin.cc> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
Pull crypto fixes from Herbert Xu: "This fixes an unaligned panic in x86/sha-mb and a bug in ccm that triggers with certain underlying implementations" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: ccm - preserve the IV buffer crypto: x86/sha1-mb - fix panic due to unaligned access crypto: x86/sha256-mb - fix panic due to unaligned access
-
Borislav Petkov authored
... so that the difference is obvious. No functionality change. Signed-off-by:
-
Ingo Molnar authored
Concentrate x86 MM and asm related changes into a single super-topic, in preparation for larger changes. Signed-off-by: -
Ingo Molnar authored
Signed-off-by:
-
- 05 Nov, 2017 1 commit
-
-
Linus Torvalds authored
-
