Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 05 9月, 2012 1 次提交
  3. 02 8月, 2012 1 次提交
  5. 01 8月, 2012 8 次提交
  7. 31 7月, 2012 23 次提交
  9. 30 7月, 2012 4 次提交
    • M
      common: DMA-mapping: add DMA_ATTR_SKIP_CPU_SYNC attribute · bdf5e487
      由 Marek Szyprowski 提交于 
      This patch adds DMA_ATTR_SKIP_CPU_SYNC attribute to the DMA-mapping
subsystem.

By default dma_map_{single,page,sg} functions family transfer a given
buffer from CPU domain to device domain. Some advanced use cases might
require sharing a buffer between more than one device. This requires
having a mapping created separately for each device and is usually
performed by calling dma_map_{single,page,sg} function more than once
for the given buffer with device pointer to each device taking part in
the buffer sharing. The first call transfers a buffer from 'CPU' domain
to 'device' domain, what synchronizes CPU caches for the given region
(usually it means that the cache has been flushed or invalidated
depending on the dma direction). However, next calls to
dma_map_{single,page,sg}() for other devices will perform exactly the
same sychronization operation on the CPU cache. CPU cache sychronization
might be a time consuming operation, especially if the buffers are
large, so it is highly recommended to avoid it if possible.
DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
the CPU cache for the given buffer assuming that it has been already
transferred to 'device' domain. This attribute can be also used for
dma_unmap_{single,page,sg} functions family to force buffer to stay in
device domain after releasing a mapping for it. Use this attribute with
care!
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NKyungmin Park <kyungmin.park@samsung.com>
      bdf5e487
    • M
      common: DMA-mapping: add DMA_ATTR_NO_KERNEL_MAPPING attribute · d5724f17
      由 Marek Szyprowski 提交于 
      This patch adds DMA_ATTR_NO_KERNEL_MAPPING attribute which lets the
platform to avoid creating a kernel virtual mapping for the allocated
buffer. On some architectures creating such mapping is non-trivial task
and consumes very limited resources (like kernel virtual address space
or dma consistent address space). Buffers allocated with this attribute
can be only passed to user space by calling dma_mmap_attrs().
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d5724f17
    • M
      ARM: dma-mapping: remove custom consistent dma region · e9da6e99
      由 Marek Szyprowski 提交于 
      This patch changes dma-mapping subsystem to use generic vmalloc areas
for all consistent dma allocations. This increases the total size limit
of the consistent allocations and removes platform hacks and a lot of
duplicated code.

Atomic allocations are served from special pool preallocated on boot,
because vmalloc areas cannot be reliably created in atomic context.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NMinchan Kim <minchan@kernel.org>
      e9da6e99
    • K
      fs: add link restrictions · 800179c9
      由 Kees Cook 提交于 
      This adds symlink and hardlink restrictions to the Linux VFS.

Symlinks:

A long-standing class of security issues is the symlink-based
time-of-check-time-of-use race, most commonly seen in world-writable
directories like /tmp. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely
incomplete list of hundreds of examples across the years, please see:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp

The solution is to permit symlinks to only be followed when outside
a sticky world-writable directory, or when the uid of the symlink and
follower match, or when the directory owner matches the symlink's owner.

Some pointers to the history of earlier discussion that I could find:

 1996 Aug, Zygo Blaxell
  http://marc.info/?l=bugtraq&m=87602167419830&w=2
 1996 Oct, Andrew Tridgell
  http://lkml.indiana.edu/hypermail/linux/kernel/9610.2/0086.html
 1997 Dec, Albert D Cahalan
  http://lkml.org/lkml/1997/12/16/4
 2005 Feb, Lorenzo Hernández García-Hierro
  http://lkml.indiana.edu/hypermail/linux/kernel/0502.0/1896.html
 2010 May, Kees Cook
  https://lkml.org/lkml/2010/5/30/144

Past objections and rebuttals could be summarized as:

 - Violates POSIX.
   - POSIX didn't consider this situation and it's not useful to follow
     a broken specification at the cost of security.
 - Might break unknown applications that use this feature.
   - Applications that break because of the change are easy to spot and
     fix. Applications that are vulnerable to symlink ToCToU by not having
     the change aren't. Additionally, no applications have yet been found
     that rely on this behavior.
 - Applications should just use mkstemp() or O_CREATE|O_EXCL.
   - True, but applications are not perfect, and new software is written
     all the time that makes these mistakes; blocking this flaw at the
     kernel is a single solution to the entire class of vulnerability.
 - This should live in the core VFS.
   - This should live in an LSM. (https://lkml.org/lkml/2010/5/31/135)
 - This should live in an LSM.
   - This should live in the core VFS. (https://lkml.org/lkml/2010/8/2/188)

Hardlinks:

On systems that have user-writable directories on the same partition
as system files, a long-standing class of security issues is the
hardlink-based time-of-check-time-of-use race, most commonly seen in
world-writable directories like /tmp. The common method of exploitation
of this flaw is to cross privilege boundaries when following a given
hardlink (i.e. a root process follows a hardlink created by another
user). Additionally, an issue exists where users can "pin" a potentially
vulnerable setuid/setgid file so that an administrator will not actually
upgrade a system fully.

The solution is to permit hardlinks to only be created when the user is
already the existing file's owner, or if they already have read/write
access to the existing file.

Many Linux users are surprised when they learn they can link to files
they have no access to, so this change appears to follow the doctrine
of "least surprise". Additionally, this change does not violate POSIX,
which states "the implementation may require that the calling process
has permission to access the existing file"[1].

This change is known to break some implementations of the "at" daemon,
though the version used by Fedora and Ubuntu has been fixed[2] for
a while. Otherwise, the change has been undisruptive while in use in
Ubuntu for the last 1.5 years.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/linkat.html
[2] http://anonscm.debian.org/gitweb/?p=collab-maint/at.git;a=commitdiff;h=f4114656c3a6c6f6070e315ffdf940a49eda3279

This patch is based on the patches in Openwall and grsecurity, along with
suggestions from Al Viro. I have added a sysctl to enable the protected
behavior, and documentation.
Signed-off-by: NKees Cook <keescook@chromium.org>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      800179c9
  11. 29 7月, 2012 1 次提交
    • T
      ALSA: hda - Workaround for silent output on VAIO Z with ALC889 · e427c237
      由 Takashi Iwai 提交于 
      On recent kernels, Realtek codec parser tries to optimize the routing
aggressively and take the headphone output as primary at first.  This
caused a regression on VAIO Z with ALC889, the silent output from the
speaker.

The problem seems that the speaker pin must be connected to the first
DAC (0x02) on this machine by some reason although the codec itself
advertises the flexible routing with any DACs.

This patch adds a fix-up for choosing the speaker pin as the primary
so that the right DAC is assigned on this device.
Reported-and-tested-by: NAdam Williamson <awilliam@redhat.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e427c237
  13. 28 7月, 2012 1 次提交
    • A
      asus-wmi: enable resume on lid open · c0b91b6d
      由 AceLan Kao 提交于 
      According to the ASUS WMI spec., to enable resume on lid open should
use the device ID(0x00120032), but it doesn't work indeed.

After discussing with ASUS' BIOS engineer, they say wake on lid open
doesn't have a uniq device ID(0x00120032) in the BIOS. It shares the same
device ID with deep S3(0x00120031), and the deep S3(resume on lid open)
is disable by default.

Adding this option in asus wmi sysfs
   /sys/devices/platform/<platform>/lid_resume
so that userspace apps can enable/disable this feature by themselves.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      c0b91b6d
  15. 27 7月, 2012 1 次提交