aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-10-20Merge branch 'test/linux-linaro-lsk-v3.18-android' of ↵lsk-v3.18-15.10-androidKevin Hilman
git://android.git.linaro.org/kernel/linaro-android into linux-linaro-lsk-v3.18-android
2015-10-20Merge branch 'linux-linaro-lsk-v3.18' into linux-linaro-lsk-v3.18-androidKevin Hilman
2015-10-13Merge tag 'v3.18.22' of ↵Kevin Hilman
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into linux-linaro-lsk-v3.18 Linux 3.18.22 * tag 'v3.18.22' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (178 commits) Linux 3.18.22 net: call rcu_read_lock early in process_backlog lpfc: Fix scsi prep dma buf error. rds: fix an integer overflow test in rds_info_getsockopt() net/mlx4_core: Fix wrong index in propagating port change event to VFs netlink: don't hold mutex in rcu callback when releasing mmapd ring inet: frags: fix defragmented packet's IP header for af_packet bonding: correct the MAC address for "follow" fail_over_mac policy bonding: fix destruction of bond with devices different from arphrd_ether ipv6: lock socket in ip6_datagram_connect() isdn/gigaset: reset tty->receive_room when attaching ser_gigaset bridge: mdb: fix double add notification net: Fix skb csum races when peeking net: do not process device backlog during unregistration net: pktgen: fix race between pktgen_thread_worker() and kthread_stop() bridge: mdb: zero out the local br_ip variable before use net/tipc: initialize security state for new connection socket ip_tunnel: fix ipv4 pmtu check to honor inner ip header df net: graceful exit from netif_alloc_netdev_queues() ipv6: Make MLD packets to only be processed locally ...
2015-10-13Merge branch 'android-3.18' of https://android.googlesource.com/kernel/commonAmit Pundir
* android-3.18: (65 commits) UPSTREAM: arm64: add better page protections to arm64 UPSTREAM: arm64: use fixmap for text patching UPSTREAM: arm64: remove the unnecessary arm64_swiotlb_init() UPSTREAM: arm64/efi: remove idmap manipulations from UEFI code UPSTREAM: arm64/efi: add missing call to early_ioremap_reset() UPSTREAM: arm64/efi: remove free_boot_services() and friends UPSTREAM: arm64/efi: move SetVirtualAddressMap() to UEFI stub UPSTREAM: arm64/efi: set EFI_ALLOC_ALIGN to 64 KB UPSTREAM: efi: efistub: allow allocation alignment larger than EFI_PAGE_SIZE UPSTREAM: efi: split off remapping code from efi_config_init() UPSTREAM: arm64/mm: add create_pgd_mapping() to create private page tables UPSTREAM: arm64/mm: add explicit struct_mm argument to __create_mapping() UPSTREAM: efi: efi-stub: notify on DTB absence UPSTREAM: arm64: dmi: set DMI string as dump stack arch description UPSTREAM: arm64: dmi: Add SMBIOS/DMI support UPSTREAM: dmi: add support for SMBIOS 3.0 64-bit entry point UPSTREAM: efi: dmi: add support for SMBIOS 3.0 UEFI configuration table UPSTREAM: arm64/efi: drop redundant set_bit(EFI_CONFIG_TABLES) UPSTREAM: arm64/efi: invert UEFI memory region reservation logic UPSTREAM: arm64/efi: set PE/COFF file alignment to 512 bytes ... Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Conflicts: arch/arm64/Kconfig.debug ==> Add changes from LSK commit 62b089faf1c1 "coresight: moving to new "hwtracing" directory" as well as changes from AOSP commit 43e0bfd3b440 "UPSTREAM: arm64: add better page protections to arm64". arch/arm64/kernel/efi.c arch/arm64/kernel/setup.c ==> Pick changes from AOSP commits 3b9b326050d5 "UPSTREAM: arm64/efi: move SetVirtualAddressMap() to UEFI stub" and 40ab942b678f "UPSTREAM: arm64/efi: remove idmap manipulations from UEFI code" instead. drivers/firmware/dmi_scan.c ==> Add changes from LSK commit d9b300555107 "firmware: dmi_scan: Fix ordering of product_uuid" as well as changes from AOSP commit 9390abcdbc7c "UPSTREAM: dmi: add support for SMBIOS 3.0 64-bit entry point". include/net/route.h ==> Pick changes from AOSP commit 83511cc43b56 "net: core: fix UID-based routing build" instead of Linaro commit a9e5d955dea "net: core: fix Null ptr dereference in UID-based routing". lib/lz4/lz4_decompress.c ==> Pick changes from AOSP commit e5cf8538cd09 "lz4: fix system halt at boot kernel on x86_64" instead.
2015-10-07UPSTREAM: arm64: add better page protections to arm64Laura Abbott
Add page protections for arm64 similar to those in arm. This is for security reasons to prevent certain classes of exploits. The current method: - Map all memory as either RWX or RW. We round to the nearest section to avoid creating page tables before everything is mapped - Once everything is mapped, if either end of the RWX section should not be X, we split the PMD and remap as necessary - When initmem is to be freed, we change the permissions back to RW (using stop machine if necessary to flush the TLB) - If CONFIG_DEBUG_RODATA is set, the read only sections are set read only. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Kees Cook <keescook@chromium.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit da141706aea52c1a9fbd28cb8d289b78819f5436) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I9e3f9cfa42f0adb0a06da20d62f9ea39dc3a4bef Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: use fixmap for text patchingLaura Abbott
When kernel text is marked as read only, it cannot be modified directly. Use a fixmap to modify the text instead in a similar manner to x86 and arm. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Kees Cook <keescook@chromium.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 2f896d5866107e2926dcdec34a7d40bc56dd2951) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I6587989d6eae6d7e366f84cbd3f9cb3acb6bb154 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: remove the unnecessary arm64_swiotlb_init()Ding Tianhong
The commit 3690951fc6d42f3a0903987677d0e592c49dd8db (arm64: Use swiotlb late initialisation) switches the DMA mapping code to swiotlb_tlb_late_init_with_default_size(), the arm64_swiotlb_init() will not used anymore, so remove this function. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit eb8a653137b7e74f7cdc01f814eb9d094a65aed9) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Ida77712c3601e2b213a4f3f913e25fba184153d7 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: remove idmap manipulations from UEFI codeArd Biesheuvel
Now that we have moved the call to SetVirtualAddressMap() to the stub, UEFI has no use for the ID map, so we can drop the code that installs ID mappings for UEFI memory regions. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 9679be103108926cfe9e6fd2f6829cefa77e47b0) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I78c5d9d29ba6cee70bd12a44e3ac88a88891ec4b Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: add missing call to early_ioremap_reset()Ard Biesheuvel
The early ioremap support introduced by patch bf4b558eba92 ("arm64: add early_ioremap support") failed to add a call to early_ioremap_reset() at an appropriate time. Without this call, invocations of early_ioremap etc. that are done too late will go unnoticed and may cause corruption. This is exactly what happened when the first user of this feature was added in patch f84d02755f5a ("arm64: add EFI runtime services"). The early mapping of the EFI memory map is unmapped during an early initcall, at which time the early ioremap support is long gone. Fix by adding the missing call to early_ioremap_reset() to setup_arch(), and move the offending early_memunmap() to right after the point where the early mapping of the EFI memory map is last used. Fixes: f84d02755f5a ("arm64: add EFI runtime services") Cc: <stable@vger.kernel.org> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 0e63ea48b4d8035dd0e91a3fa6fb79458b47adfb) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I50e35bc6f7866a1e3c4c1e10f604efe96be5eb85 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: remove free_boot_services() and friendsArd Biesheuvel
Now that we are calling SetVirtualAddressMap() from the stub, there is no need to reserve boot-only memory regions, which implies that there is also no reason to free them again later. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 3033b84596eaec0093b68c5711c265738eb0745d) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I78c022ebe327e1c937e8c3b1070ce794f3fd61a5 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: move SetVirtualAddressMap() to UEFI stubArd Biesheuvel
In order to support kexec, the kernel needs to be able to deal with the state of the UEFI firmware after SetVirtualAddressMap() has been called. To avoid having separate code paths for non-kexec and kexec, let's move the call to SetVirtualAddressMap() to the stub: this will guarantee us that it will only be called once (since the stub is not executed during kexec), and ensures that the UEFI state is identical between kexec and normal boot. This implies that the layout of the virtual mapping needs to be created by the stub as well. All regions are rounded up to a naturally aligned multiple of 64 KB (for compatibility with 64k pages kernels) and recorded in the UEFI memory map. The kernel proper reads those values and installs the mappings in a dedicated set of page tables that are swapped in during UEFI Runtime Services calls. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Matt Fleming <matt.fleming@intel.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit f3cdfd239da56a4cea75a2920dc326f0f45f67e3) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I2df4ed0ed8d8db5f7de3b5e4d900c6d1cf3b3038 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: set EFI_ALLOC_ALIGN to 64 KBArd Biesheuvel
Set EFI_ALLOC_ALIGN to 64 KB so that all allocations done by the stub are naturally compatible with a 64 KB granule kernel. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 1bd0abb0c924a8b28c6466cdd6bb34ea053541dc) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I3de82baa1ed24b38152dc9c1402816fc61e5157c Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: efi: efistub: allow allocation alignment larger than EFI_PAGE_SIZEArd Biesheuvel
On systems with 64 KB pages, it is preferable for UEFI memory map entries to be 64 KB aligned multiples of 64 KB, because it relieves us of having to deal with the residues. So, if EFI_ALLOC_ALIGN is #define'd by the platform, use it to round up all memory allocations made. Acked-by: Matt Fleming <matt.fleming@intel.com> Acked-by: Borislav Petkov <bp@suse.de> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit cf2b0f102cdf912eedb87b10271fa0ad582cf2c1) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I79fedd4b366bddc5f2aac25d27f04ba3963a0612 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: efi: split off remapping code from efi_config_init()Ard Biesheuvel
Split of the remapping code from efi_config_init() so that the caller can perform its own remapping. This is necessary to correctly handle virtually remapped UEFI memory regions under kexec, as efi.systab will have been updated to a virtual address. Acked-by: Matt Fleming <matt.fleming@intel.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 7bb68410ef22067b08fd52887875b8f337f89dcc) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Ib684bba9f6e8e9f72cdef1c514ea273c05a45e83 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/mm: add create_pgd_mapping() to create private page tablesArd Biesheuvel
For UEFI, we need to install the memory mappings used for Runtime Services in a dedicated set of page tables. Add create_pgd_mapping(), which allows us to allocate and install those page table entries early. Reviewed-by: Will Deacon <will.deacon@arm.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 8ce837cee8f51fb0eacb32c85461ea2f0fafc9f8) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Ide9c47e9d6491c20a1a441768f3405772cbb7eb6 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/mm: add explicit struct_mm argument to __create_mapping()Ard Biesheuvel
Currently, swapper_pg_dir and idmap_pg_dir share the init_mm mm_struct instance. To allow the introduction of other pg_dir instances, for instance, for UEFI's mapping of Runtime Services, make the struct_mm instance an explicit argument that gets passed down to the pmd and pte instantiation functions. Note that the consumers (pmd_populate/pgd_populate) of the mm_struct argument don't actually inspect it, but let's fix it for correctness' sake. Acked-by: Steve Capper <steve.capper@linaro.org> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit e1e1fddae74b72d0415965821ad00fe39aac6f13) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Ia8733d9c5ec8eba58685bf5e13b6a680a9272b20 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: efi: efi-stub: notify on DTB absenceMark Rutland
In the absence of a DTB configuration table, the EFI stub will happily continue attempting to boot a kernel, despite the fact that this kernel may not function without a description of the hardware. In this case, as with a typo'd "dtb=" option (e.g. "dbt=") or many other possible failures, the only output seen by the user will be the rather terse output from the EFI stub: EFI stub: Booting Linux Kernel... To aid those attempting to debug such failures, this patch adds a notice when no DTB is found, making the output more helpful: EFI stub: Booting Linux Kernel... EFI stub: Generating empty DTB Additionally, a positive acknowledgement is added when a user-specified DTB is in use: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from command line Similarly, a positive acknowledgement is added when a DTB from a configuration table is in use: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Roy Franz <roy.franz@linaro.org> Acked-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 0bcaa9040d058684d58c36ef273b8946996c7078) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Ia2c69ebfa0f632c43ac014312c77dafccbe02305 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: dmi: set DMI string as dump stack arch descriptionArd Biesheuvel
This sets the DMI string, containing system type, serial number, firmware version etc. as dump stack arch description, so that oopses and other kernel stack dumps automatically have this information included, if available. Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit b07bfaa3c126e4e36a2b59350b3b930aa1b121ac) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I9921f1247322d5b1594c9f381069c77c5643f14d Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: dmi: Add SMBIOS/DMI supportYi Li
SMBIOS is important for server hardware vendors. It implements a spec for providing descriptive information about the platform. Things like serial numbers, physical layout of the ports, build configuration data, and the like. Signed-off-by: Yi Li <yi.li@linaro.org> Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit d1ae8c0057921681ca489bba7efbfacbb60d0f28) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Ia4495a2335bab1b5e626a6bcd5df4ab1d287a27d Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: dmi: add support for SMBIOS 3.0 64-bit entry pointArd Biesheuvel
The DMTF SMBIOS reference spec v3.0.0 defines a new 64-bit entry point, which enables support for SMBIOS structure tables residing at a physical offset over 4 GB. This is especially important for upcoming arm64 platforms whose system RAM resides entirely above the 4 GB boundary. For the UEFI case, this code attempts to detect the new SMBIOS 3.0 header magic at the offset passed in the SMBIOS3_TABLE_GUID UEFI configuration table. If this configuration table is not provided, or if we fail to parse the header, we fall back to using the legacy SMBIOS_TABLE_GUID configuration table. This is in line with the spec, that allows both configuration tables to be provided, but mandates that they must point to the same structure table, unless the version pointed to by the 64-bit entry point is a superset of the 32-bit one. For the non-UEFI case, the detection logic is modified to look for the SMBIOS 3.0 header magic before it looks for the legacy header magic. Note that this patch is based on version 3.0.0d [draft] of the specification, which is expected not to deviate from the final version in ways that would affect the correctness of this implementation. Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Tony Luck <tony.luck@intel.com> Acked-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit fc43026278b23b3515cf8f909ec29df94b3ae1a2) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I02fae4d34964865455129f67ecc81754de9b3987 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: efi: dmi: add support for SMBIOS 3.0 UEFI configuration tableArd Biesheuvel
This adds support to the UEFI side for detecting the presence of a SMBIOS 3.0 64-bit entry point. This allows the actual SMBIOS structure table to reside at a physical offset over 4 GB, which cannot be supported by the legacy SMBIOS 32-bit entry point. Since the firmware can legally provide both entry points, store the SMBIOS 3.0 entry point in a separate variable, and let the DMI decoding layer decide which one will be used. Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit e1ccbbc9d5aa01a6c1c9c78acea6515db4f1be71) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I740a8b54d538a7a81f34b517f0ccea9fada55551 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: drop redundant set_bit(EFI_CONFIG_TABLES)Ard Biesheuvel
The EFI_CONFIG_TABLES bit already gets set by efi_config_init(), so there is no reason to set it again after this function returns successfully. Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 4e27d4754e8990da264c1e01e2f6bd8340e30cb3) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I13a64ac2630ec1db22d4d4de4ebe9597cb83e291 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: invert UEFI memory region reservation logicArd Biesheuvel
Instead of reserving the memory regions based on which types we know need to be reserved, consider only regions of the following types as free for general use by the OS: EFI_LOADER_CODE EFI_LOADER_DATA EFI_BOOT_SERVICES_CODE EFI_BOOT_SERVICES_DATA EFI_CONVENTIONAL_MEMORY Note that this also fixes a problem with the original code, which would misidentify a EFI_RUNTIME_SERVICES_DATA region as not reserved if it does not have the EFI_MEMORY_RUNTIME attribute set. However, it is perfectly legal for the firmware not to request a virtual mapping for EFI_RUNTIME_SERVICES_DATA regions that contain configuration tables, in which case the EFI_MEMORY_RUNTIME attribute would not be set. Acked-by: Roy Franz <roy.franz@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 61139eb04056bba69aeef6c481802c4ea028bf4d) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I427af832faaf82100c1f3ffb3e1649dd05e6d280 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: set PE/COFF file alignment to 512 bytesArd Biesheuvel
Change our PE/COFF header to use the minimum file alignment of 512 bytes (0x200), as mandated by the PE/COFF spec v8.3 Also update the linker script so that the Image file itself is also a round multiple of FileAlignment. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Roy Franz <roy.franz@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit a352ea3e197b3aa74deb51728b050cd4a0c6105a) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Ia9ae614f5004a7bee2254e3813d5b24d95bcff99 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: set PE/COFF section alignment to 4 KBArd Biesheuvel
Position independent AArch64 code needs to be linked and loaded at the same relative offset from a 4 KB boundary, or adrp/add and adrp/ldr pairs will not work correctly. (This is how PC relative symbol references with a 4 GB reach are emitted) We need to declare this in the PE/COFF header, otherwise the PE/COFF loader may load the Image and invoke the stub at an offset which violates this rule. Reviewed-by: Roy Franz <roy.franz@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit ea6bc80d1819f307d98c6562c8ebb2c6c1297d47) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Iae24c73314b680bf3be1dd04bd38bfa1c3209dd2 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64/efi: efistub: jump to 'stext' directly, not through the headerArd Biesheuvel
After the EFI stub has done its business, it jumps into the kernel by branching to offset #0 of the loaded Image, which is where it expects to find the header containing a 'branch to stext' instruction. However, the UEFI spec 2.1.1 states the following regarding PE/COFF image loading: "A UEFI image is loaded into memory through the LoadImage() Boot Service. This service loads an image with a PE32+ format into memory. This PE32+ loader is required to load all sections of the PE32+ image into memory." In other words, it is /not/ required to load parts of the image that are not covered by a PE/COFF section, so it may not have loaded the header at the expected offset, as it is not covered by any PE/COFF section. So instead, jump to 'stext' directly, which is at the base of the PE/COFF .text section, by supplying a symbol 'stext_offset' to efi-entry.o which contains the relative offset of stext into the Image. Also replace other open coded calculations of the same value with a reference to 'stext_offset' Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Roy Franz <roy.franz@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> (cherry picked from commit 95b395963fed02cca8849137b375528a5fc94e35) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I21548ced434a5c6eab6d763821b3ca733827d66e Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: Move some head.text functions to executable sectionLaura Abbott
The head.text section is intended to be run at early bootup before any of the regular kernel mappings have been setup. Parts of head.text may be freed back into the buddy allocator due to TEXT_OFFSET so for security requirements this memory must not be executable. The suspend/resume/hotplug code path requires some of these head.S functions to run however which means they need to be executable. Support these conflicting requirements by moving the few head.text functions that need to be executable to the text section which has the appropriate page table permissions. Tested-by: Kees Cook <keescook@chromium.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 034edabe6cf1d0dea49d4c836ba128cec90fad04) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I6b69573ab325c0092ea0b3522ad9b6f391d984ca Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: jump labels: NOP out NOP -> NOP replacementMark Rutland
In the arm64 arch_static_branch implementation we place an A64 NOP into the instruction stream and log relevant details to a jump_entry in a __jump_table section. Later this may be replaced with an immediate branch without link to the code for the unlikely case. At init time, the core calls arch_jump_label_transform_static to initialise the NOPs. On x86 this involves inserting the optimal NOP for a given microarchitecture, but on arm64 we only use the architectural NOP, and hence replace each NOP with the exact same NOP. This is somewhat pointless. Additionally, at module load time we don't call jump_label_apply_nops to patch the optimal NOPs in, unlike other architectures, but get away with this because we only use the architectural NOP anyway. A later notifier will patch NOPs with branches as required. Similarly to x86 commit 11570da1c5b1dee1 (x86/jump-label: Do not bother updating NOPs if they are correct), we can avoid patching NOPs with identical NOPs. Given that we only use a single NOP encoding, this means we can NOP-out the body of arch_jump_label_transform_static entirely. As the default __weak arch_jump_label_transform_static implementation performs a patch, we must use an empty function to achieve this. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Jiang Liu <liuj97@gmail.com> Cc: Laura Abbott <lauraa@codeaurora.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 6ddae4186886a81e22ad78ad7c6936ed36bc8225) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I9ef07c3a5a7f91418b30006850fcc0c421e147e2 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: add support to dump the kernel page tablesLaura Abbott
In a similar manner to arm, it's useful to be able to dump the page tables to verify permissions and memory types. Add a debugfs file to check the page tables. Acked-by: Steve Capper <steve.capper@linaro.org> Tested-by: Steve Capper <steve.capper@linaro.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> [will: s/BUFFERABLE/NORMAL-NC/] Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit c9465b4ec37a68425c5a574b56280dc1a7e34070) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I7fe213003721e931747baed73fb05194c5fbeb64 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: Add FIX_HOLE to permanent fixed addressesLaura Abbott
Every other architecture with permanent fixed addresses has FIX_HOLE as the first entry. This seems to be designed as a debugging aid but there are a couple of side effects of not having FIX_HOLE: - If the first fixed address is 0, fix_to_virt -> virt_to_fix triggers a BUG_ON for the virtual address being equal to FIXADDR_TOP - fix_to_virt may return a value outside of FIXADDR_START and FIXADDR_TOP which may look like a bug to a developer. Match up with other architectures and make everything clearer by adding FIX_HOLE. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit dab78b6dcb2bfc90038f35ada826844273dde4d6) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I495db3781f5b937c5e0cc47d53b18718335f78c6 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: Factor out fixmap initialization from ioremapLaura Abbott
The fixmap API was originally added for arm64 for early_ioremap purposes. It can be used for other purposes too so move the initialization from ioremap to somewhere more generic. This makes it obvious where the fixmap is being set up and allows for a cleaner implementation of __set_fixmap. Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit af86e5974d3069bd26ebcf7c046c6e59726acaaa) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I0ff13949b4468c6017d4e47558aa00cd76b773c7 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: Move cpu_resume into the text sectionLaura Abbott
The function cpu_resume currently lives in the .data section. There's no reason for it to be there since we can use relative instructions without a problem. Move a few cpu_resume data structures out of the assembly file so the .data annotation can be dropped completely and cpu_resume ends up in the read only text section. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Kees Cook <keescook@chromium.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit c3684fbb446501b48dec6677a6a9f61c215053de) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: Ie437157cd1baf98ee2534c61d47aa70035dc480b Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: Switch to adrp for loading the stub vectorsLaura Abbott
The hyp stub vectors are currently loaded using adr. This instruction has a +/- 1MB range for the loading address. If the alignment for sections is changed the address may be more than 1MB away, resulting in reclocation errors. Switch to using adrp for getting the address to ensure we aren't affected by the location of the __hyp_stub_vectors. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit ac2dec5f6c27a581f8571da605d9ba04df18330d) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I40ad3adfa5773e8ee22f53fb755143fdd7db0487 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-07UPSTREAM: arm64: Treat handle_arch_irq as a function pointerLaura Abbott
handle_arch_irq isn't actually text, it's just a function pointer. It doesn't need to be stored in the text section and doing so causes problesm if we ever want to make the kernel text read only. Declare handle_arch_irq as a proper function pointer stored in the data section. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit fcff588633e848aa728a4437ef96d437299ba03d) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I7c842503cd70881fa78bbeb47d98f15bb83f6446 Signed-off-by: Kees Cook <keescook@google.com>
2015-10-05Squashfs: Add LZ4 compression configuration optionPhillip Lougher
Add the glue code, and also update the documentation. Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
2015-10-05Squashfs: add LZ4 compression supportPhillip Lougher
Add support for reading file systems compressed with the LZ4 compression algorithm. This patch adds the LZ4 decompressor wrapper code. Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
2015-10-05lz4: fix system halt at boot kernel on x86_64Krzysztof Kolasa
Sometimes, on x86_64, decompression fails with the following error: Decompressing Linux... Decoding failed -- System halted This condition is not needed for a 64bit kernel(from commit d5e7caf): if( ... || (op + COPYLENGTH) > oend) goto _output_error macro LZ4_SECURE_COPY() tests op and does not copy any data when op exceeds the value. added by analogy to lz4_uncompress_unknownoutputsize(...) Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Tested-by: Alexander Kuleshov <kuleshovmail@gmail.com> Tested-by: Caleb Jorden <cjorden@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-05lib/lz4: Pull out constant tablesRasmus Villemoes
There's no reason to allocate the dec{32,64}table on the stack; it just wastes a bunch of instructions setting them up and, of course, also consumes quite a bit of stack. Using size_t for such small integers is a little excessive. $ scripts/bloat-o-meter /tmp/built-in.o lib/built-in.o add/remove: 2/2 grow/shrink: 2/0 up/down: 1304/-1548 (-244) function old new delta lz4_decompress_unknownoutputsize 55 718 +663 lz4_decompress 55 632 +577 dec64table - 32 +32 dec32table - 32 +32 lz4_uncompress 747 - -747 lz4_uncompress_unknownoutputsize 801 - -801 The now inlined lz4_uncompress functions used to have a stack footprint of 176 bytes (according to -fstack-usage); their inlinees have increased their stack use from 32 bytes to 48 and 80 bytes, respectively. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-05LZ4 : fix the data abort issueJeHyeon Yeon
If the part of the compression data are corrupted, or the compression data is totally fake, the memory access over the limit is possible. This is the log from my system usning lz4 decompression. [6502]data abort, halting [6503]r0 0x00000000 r1 0x00000000 r2 0xdcea0ffc r3 0xdcea0ffc [6509]r4 0xb9ab0bfd r5 0xdcea0ffc r6 0xdcea0ff8 r7 0xdce80000 [6515]r8 0x00000000 r9 0x00000000 r10 0x00000000 r11 0xb9a98000 [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc 0x820149bc [6528]spsr 0x400001f3 and the memory addresses of some variables at the moment are ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000 As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory over @oend. Signed-off-by: JeHyeon Yeon <tom.yeon@windriver.com> Reviewed-by: David Sterba <dsterba@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-01arm64: pass return address to dma_common_contiguous_remapJin Qian
Added return address to show caller function in /proc/vmallocinfo Change-Id: Ieb0bbf6ec82b561cea6ff18f0516744050dfc269
2015-10-01Initialize msg/shm IPC objects before doing ipc_addid()Linus Torvalds
(cherry pick from commit b9a532277938798b53178d5a66af6e2915cb27cf) As reported by Dmitry Vyukov, we really shouldn't do ipc_addid() before having initialized the IPC object state. Yes, we initialize the IPC object in a locked state, but with all the lockless RCU lookup work, that IPC object lock no longer means that the state cannot be seen. We already did this for the IPC semaphore code (see commit e8577d1f0329: "ipc/sem.c: fully initialize sem_array before making it visible") but we clearly forgot about msg and shm. Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Davidlohr Bueso <dbueso@suse.de> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Mark Salyzyn <salyzyn@google.com> Bug: 24551430 Change-Id: I563c0505975304331403e1825b8951f848b838cc
2015-10-01Linux 3.18.22v3.18.22Sasha Levin
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2015-10-01lowmemorykiller: trace kill events.Martijn Coenen
Allows for capturing lmk kill events and their rationale. Change-Id: Ibe215db5bb9806fc550c72c0b9832c85cbd56bf6 Signed-off-by: Martijn Coenen <maco@google.com>
2015-09-30selinux: do not check open perm on ftruncate callJeff Vander Stoep
Use the ATTR_FILE attribute to distinguish between truncate() and ftruncate() system calls. The two other cases where do_truncate is called with a filp (and therefore ATTR_FILE is set) are for coredump files and for open(O_TRUNC). In both of those cases the open permission has already been checked during file open and therefore does not need to be repeated. Commit 95dbf739313f ("SELinux: check OPEN on truncate calls") fixed a major issue where domains were allowed to truncate files without the open permission. However, it introduced a new bug where a domain with the write permission can no longer ftruncate files without the open permission, even when they receive an already open file. (cherry picked from commit b21800f304392ee5d20f411c37470183cc779f11) Bug: 22567870 Change-Id: I2525a0e244c8d635b2d0c1f966071edbb365a43a Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <pmoore@redhat.com>
2015-09-30Revert "HACK: usb: gadget: Fix enumeration on boot"Amit Pundir
Apparently we do not need this hack on Android ConfigFS gadgets. This reverts commit 2896b2909fa0655265eec0f743baae592d8d52be. Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
2015-09-30ipv6: sysctl to restrict candidate source addressesErik Kline
Per RFC 6724, section 4, "Candidate Source Addresses": It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination (the "outgoing" interface). Add a sysctl to enable this behaviour. Change-Id: Ia7de62a93bed3baed596bc16ed471f2c73ed513f Signed-off-by: Erik Kline <ek@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-30ipv6: Remove unused arguments for __ipv6_dev_get_saddr().YOSHIFUJI Hideaki
Signed-off-by: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-30ipv6: Fix finding best source address in ipv6_dev_get_saddr().YOSHIFUJI Hideaki/吉藤英明
Commit 9131f3de2 ("ipv6: Do not iterate over all interfaces when finding source address on specific interface.") did not properly update best source address available. Plus, it introduced possible NULL pointer dereference. Bug was reported by Erik Kline <ek@google.com>. Based on patch proposed by Hajime Tazaki <thehajime@gmail.com>. Fixes: 9131f3de24db4dc12199aede7d931e6703e97f3b ("ipv6: Do not iterate over all interfaces when finding source address on specific interface.") Signed-off-by: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com> Acked-by: Hajime Tazaki <thehajime@gmail.com> Acked-by: Erik Kline <ek@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-30ipv6: Do not iterate over all interfaces when finding source address on ↵YOSHIFUJI Hideaki/吉藤英明
specific interface. If outgoing interface is specified and the candidate address is restricted to the outgoing interface, it is enough to iterate over that given interface only. Change-Id: Iec17f955f3a5a0930dc11a8b8916d720d2c5f494 Signed-off-by: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com> Acked-by: Erik Kline <ek@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-30net: ipv6: allow explicitly choosing optimistic addressesErik Kline
RFC 4429 ("Optimistic DAD") states that optimistic addresses should be treated as deprecated addresses. From section 2.1: Unless noted otherwise, components of the IPv6 protocol stack should treat addresses in the Optimistic state equivalently to those in the Deprecated state, indicating that the address is available for use but should not be used if another suitable address is available. Optimistic addresses are indeed avoided when other addresses are available (i.e. at source address selection time), but they have not heretofore been available for things like explicit bind() and sendmsg() with struct in6_pktinfo, etc. This change makes optimistic addresses treated more like deprecated addresses than tentative ones. Signed-off-by: Erik Kline <ek@google.com> Acked-by: Lorenzo Colitti <lorenzo@google.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>