- 06 Apr, 2016 40 commits
-
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1566505 Currently a new mount of an existing hierarchy always reuses the original super block, even when the new mount is in a cgroup namespace. This sometimes conflicts with the user namespace mount support, which requires a new mount of an existing super block to be in the same user namespace as the original mount. When mounting from non-init cgroup and user namespaces sget() will fail. To fix this we can pass a pointer to the cgroup ns to kernfs when mounting, causing kernfs_test_super() to no longer match super blocks from different cgroup namespaces. However we do wish to continue sharing the cgroup_root between mounts of the same heirarchy. The cgroup_root's lifetime is governed by the reference count of its cgrp member, but this is a percpu reference count and is not well suited to this new situation. Instead a new reference count is added to the cgroup_root structure to track the number of super blocks sharing that root, and this refcnt is used to determine when to put the cgroup reference. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1566505 These are required mount options, thus there is no need to initialize the values in struct fuse_mount_data. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1566505 In a userns mount some on-disk inodes may have ids which do not map into s_user_ns, in which case the in-kernel inodes are owned by invalid users. The superblock owner should be able to change attributes of these inodes but cannot. However it is unsafe to grant the superblock owner privileged access to all inodes in the superblock since proc, sysfs, etc. use DAC to protect files which may not belong to s_user_ns. The problem is restricted to only inodes where the owner or group is an invalid user. We can work around this by allowing users with CAP_CHOWN in s_user_ns to change an invalid owner or group id, so long as the other id is either invalid or mappable in s_user_ns. After changing ownership the user will be privileged towards the inode and thus able to change other attributes. As an precaution, checks for invalid ids are added to the proc and kernfs setattr interfaces. These filesystems are not expected to have inodes with invalid ids, but if it does happen any setattr operations will return -EPERM. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1566505 This ensures that quotas that aren't valid on disk never make it into the hash table. inodes with ids which don't map into s_user_ns will now have no quota enforcement. Signed-off-by:
-
Catalin Marinas authored
BugLink: http://bugs.launchpad.net/bugs/1566518 The set_pte_at() function must update the hardware PTE_RDONLY bit depending on the state of the PTE_WRITE and PTE_DIRTY bits of the given entry value. However, it currently only performs this for pte_valid() entries, ignoring PTE_PROT_NONE. The side-effect is that PROT_NONE mappings would not have the PTE_RDONLY bit set. Without CONFIG_ARM64_HW_AFDBM, this is not an issue since such PROT_NONE pages are not accessible anyway. With commit 2f4b829c ("arm64: Add support for hardware updates of the access and dirty pte bits"), the ptep_set_wrprotect() function was re-written to cope with automatic hardware updates of the dirty state. As an optimisation, only PTE_RDONLY is checked to assess the "dirty" status. Since set_pte_at() does not set this bit for PROT_NONE mappings, such pages may be considered "dirty" as a result of ptep_set_wrprotect(). This patch updates the pte_valid() check to pte_present() in set_pte_at(). It also adds PTE_PROT_NONE to the swap entry bits comment. Fixes: 2f4b829c ("arm64: Add support for hardware updates of the access and dirty pte bits") Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reported-by:
Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com> Tested-by:
Ganapatrao Kulkarni <gkulkarni@cavium.com> Cc: <stable@vger.kernel.org> (cherry picked from commit fdc69e7d) Signed-off-by:
dann frazier <dann.frazier@canonical.com> Signed-off-by:
-
Catalin Marinas authored
BugLink: http://bugs.launchpad.net/bugs/1566518 Currently, set_pte_at() only checks the software PTE_WRITE bit for user mappings when it sets or clears the hardware PTE_RDONLY accordingly. The kernel ptes are written directly without any modification, relying solely on the protection bits in macros like PAGE_KERNEL. However, modifying kernel pte attributes via pte_wrprotect() would be ignored by set_pte_at(). Since pte_wrprotect() does not set PTE_RDONLY (it only clears PTE_WRITE), the new permission is not taken into account. This patch changes set_pte_at() to adjust the read-only permission for kernel ptes as well. As a side effect, existing PROT_* definitions used for kernel ioremap*() need to include PTE_DIRTY | PTE_WRITE. (additionally, white space fix for PTE_KERNEL_ROX) Acked-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Tested-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> (cherry picked from commit ac15bd63) Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linus&id=59b9023c356c54e5f468029fa504461d04c0f02b commit b37d83a6 ("usb: Parse the new USB 3.1 SuperSpeedPlus Isoc endpoint companion descriptor") caused a regression in 4.6-rc1 and fails to parse SuperSpeed endpoint companion descriptors. The new SuperSpeedPlus Isoc endpoint companion parsing code incorrectly decreased the the remaining buffer size before comparing the size with the expected length of the descriptor. This lead to possible failure in reading the SuperSpeed endpoint companion descriptor of the last endpoint, displaying a message like: "No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0 ep 129: using minimum values" Fix it by decreasing the size after comparing it. Also finish all the SS endpoint companion parsing before calling SSP isoc endpoint parsing function. Fixes: b37d83a6Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 The transfer burst count (TBC) field in the Isoc TRB does not fit the new larger burst count available for USB 3.1 SSP Isoc tranfers. xhci 1.1 solved this by reusing the TD size field for transfer burst count. The Mult field was outgrown as well. xhci 1.1 controllers can calculate Mult itself and is not set if the new layout is used. xhci 1.1 controllers that support the new Isoc TRB format expose a Extended TBC Capability (ETC). To take the new format into use the xhci host controller driver needs to set a Extended TBC Enable (ETE) bit. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 Clean up xhci_queue_isoc_tx() and helpers to prepare them for USB 3.1 and xhci 1.1 isoc TRB changes. Only functional change is adding xhci version 1.1 to the BEI flag check toghether with xhci version 1.0. Both versions behave the same. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 SuperSpeedPlus doubled the number of transactions per service interval the isoc endpoints supports. To support this, xhci 1.1 added Large ESIT Capability (LEC), which takes into use new bits in the endpoint context to fit the parameters. If xhci supports LEC, and the device has a SuperSpeedPlus Isoc companion descriptor then take into use the high bits of max esit payload, and skip calculating the Mult field as it wouldn't fit. LEC capable host will calculate the Mult based on other paramenters. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 xhci_endpoint_init() and helper functions were a bit messy. Adding the higher bandwidth SuperSpeedPlus Isoc support on top of it would make it even harder to read. No functional changes. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 USB 3.1 devices that support precision time measurement have an additional PTM cabaility descriptor as part of the full BOS descriptor Look for this descriptor while parsing the BOS descriptor, and store it in struct usb_hub_bos if it exists. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 USB 3.1 devices can return a new SuperSpeedPlus isoc endpoint companion descriptor for a isochronous endpoint that requires more than 48K bytes per Service Interval. The new descriptor immediately follows the old USB 3.0 SuperSpeed Endpoint Companion and will provide a new BytesPerInterval value. It is parsed and stored in struct usb_host_endpoint with the other endpoint related descriptors, and should be used by USB3.1 capable hosts to reserve bus time in the schedule. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 USB3.1 specifies a SuperSpeedPlus Isoc endpoint companion descriptor which is returned as part of the devices complete configuration descriptor. It contains number of bytes per service interval which is needed when reserving bus time in the schedule for transfers over 48K bytes per service interval. If bmAttributes bit 7 is set in the old SuperSpeed Endpoint Companion descriptor, it will be ollowed by the new SuperSpeedPlus Isoc Endpoint Companion descriptor. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 The speed field of the input slot context should represent the speed the device is working at. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 If a xhci controller does not provide a protocol speed ID (PSI) table, a default one should be used instead. Add the default values to the SuperSpeedPlus device capability. Overwrite the default ones if a PSI table exists. See xHCI 1.1 sectio 7.2.2.1.1 for more info Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 In most cases the devices with the speed set to USB_SPEED_SUPER_PLUS are handled like regular SuperSpeed devices. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 The same way as SuperSpeed devices show "5000" as device speed we wan't to show "10000" as the default speed for SuperSpeedPlus devices in sysfs. Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 A hcd roothub that supports HCD_USB31 is running at SuperSpeedPlus speed Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1519623 Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by:
-
Tyler Hicks authored
When header files in security/apparmor/includes/ pull in other header files in that directory, they should only include the file name. This fixes a build failure reported by Tycho when using `make bindeb-pkg` to build the Ubuntu kernel tree but, confusingly, isn't seen when building with `fakeroot debian/rules binary-generic`. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Reported-by:
Tycho Andersen <tycho.andersen@canonical.com> Cc: John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Harald Freudenberger authored
BugLink: http://bugs.launchpad.net/bugs/1558275 When the prng device driver calls misc_register() there is the possibility to also provide the recommented file permissions. This fix now gives useful values (0644) where previously just the default was used (resulting in 0600 for the device file). Signed-off-by:
Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 74b2375e) Signed-off-by:
-
Hui Wang authored
BugLink: http://bugs.launchpad.net/bugs/1564712 The front mic jack (pink color) can't detect any plug or unplug. After applying this fix, both detecting function and recording function work well. BugLink: https://bugs.launchpad.net/bugs/1564712 Cc: stable@vger.kernel.org Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> (back ported from commit e549d190) Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1556228 Just like CX20722, CX7024 codec also requires the power down at reboot in order to reduce the noise at reboot/shutdown. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=113511 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1565765Signed-off-by:
-
Josh Boyer authored
BugLink: http://bugs.launchpad.net/bugs/1566221 There is currently no way to verify the resume image when returning from hibernate. This might compromise the signed modules trust model, so until we can work with signed hibernate images we disable it in a secure modules environment. Signed-off-by:
Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Josh Boyer authored
BugLink: http://bugs.launchpad.net/bugs/1566221 UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit for use with efi_enabled. Signed-off-by:
-
Josh Boyer authored
BugLink: http://bugs.launchpad.net/bugs/1566221 The functionality of the config option is dependent upon the platform being UEFI based. Reflect this in the config deps. Signed-off-by:
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 UEFI Secure Boot provides a mechanism for ensuring that the firmware will only load signed bootloaders and kernels. Certain use cases may also require that all kernel modules also be signed. Add a configuration option that enforces this automatically when enabled. Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1566221 Defer enforcing signed module loading, but other secure boot checks are still valid. Signed-off-by:
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 Writing to MSRs should not be allowed if module loading is restricted, since it could lead to execution of arbitrary code in kernel mode. Based on a patch by Kees Cook. Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 kexec permits the loading and execution of arbitrary code in ring 0, which is something that module signing enforcement is meant to prevent. It makes sense to disable kexec in this situation. Signed-off-by:
-
Josh Boyer authored
BugLink: http://bugs.launchpad.net/bugs/1566221 This option allows userspace to pass the RSDP address to the kernel, which makes it possible for a user to circumvent any restrictions imposed on loading modules. Disable it in that case. Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 Allowing users to write to address space makes it possible for the kernel to be subverted, avoiding module loading restrictions. Prevent this when any restrictions have been imposed on loading modules. Signed-off-by:
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 We have no way of validating what all of the Asus WMI methods do on a given machine, and there's a risk that some will allow hardware state to be manipulated in such a way that arbitrary code can be executed in the kernel, circumventing module loading restrictions. Prevent that if any of these features are enabled. Signed-off-by:
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 custom_method effectively allows arbitrary access to system memory, making it possible for an attacker to circumvent restrictions on module loading. Disable it if any such restrictions have been enabled. Signed-off-by:
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 IO port access would permit users to gain access to PCI configuration registers, which in turn (on a lot of hardware) give access to MMIO register space. This would potentially permit root to trigger arbitrary DMA, so lock it down by default. Signed-off-by:
-
