Unset CONFIG_DMABUF_HEAPS_SYSTEM from gki_defconfig
so that it can be enabled as a vendor module.
This change is intended to allow partners to continue using
device/SoC-specific optimizations in their system heap implementations
when they switch from ION to DMA-BUF heaps. The ION system heap was
built-in and partners were asked to override the system heap ID with
their own if they wanted to override the GKI system heap. This
per-vendor approach to override system heap will no longer be possible
with DMA-BUF heaps since Android S aims to restrict framework access to
DMA-BUF vendor heaps by only letting it access ABI-defined vendor heaps.
VTS tests will be created to ensure that the system heap is present
at /dev/dma_heap/system and behaves as expected of the system heap.
Bug: 175697666
Bug: 155218010
Bug: 172527615
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Change-Id: Id97ed4814517339c69b99f8135e9a66e59d951a9
This patch sets CONFIG_DMABUF_HEAPS_SYSTEM to tristate and exports the
symbol dma_heap_get_dev() to allow the DMA-BUF system heap to be a
module.
This change is intended to allow partners to continue using
device/SoC-specific optimizations in their system heap implementations
when they switch from ION to DMA-BUF heaps. The ION system heap was
built-in and partners were asked to override the system heap ID with
their own if they wanted to override the GKI system heap. This
per-vendor approach to override system heap will no longer be possible
with DMA-BUF heaps since Android S aims to restrict framework access to
DMA-BUF vendor heaps by only letting it access ABI-defined vendor heaps.
VTS tests will be created to ensure that the system heap is present
at /dev/dma_heap/system and behaves as expected of the system heap.
Bug: 175697666
Bug: 155218010
Bug: 172527615
Change-Id: Iabb24d9aedde308a9b15509781dd0e6b67353e99
Signed-off-by: Hridya Valsaraju <hridya@google.com>
After recent changes to the DWC3 driver, we need the following
symbols in the symbol list.
Generated with:
BUILD_CONFIG=common/build.config.db845c build/build_abi.sh -s
Fixes: 87e01dd378 ("Revert "ANDROID: db845c_gki.fragment: Drop CONFIG_USB_DWC3 from config frament"")
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: Ifc8b74fe33a040a778d04b77cb68a9e62cb997aa
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for arm.
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 424c9102fa)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: I90eaafdc43f618ce7dcf76e1cbb8ae1ff542ead9
Bug: 176068146
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for arm64.
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit ffde703470)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: Ib21059de0928a61bd76202a67732432e88c5a5f0
Bug: 176068146
SECCOMP_CACHE will only operate on syscalls that do not access
any syscall arguments or instruction pointer. To facilitate
this we need a static analyser to know whether a filter will
return allow regardless of syscall arguments for a given
architecture number / syscall number pair. This is implemented
here with a pseudo-emulator, and stored in a per-filter bitmap.
In order to build this bitmap at filter attach time, each filter is
emulated for every syscall (under each possible architecture), and
checked for any accesses of struct seccomp_data that are not the "arch"
nor "nr" (syscall) members. If only "arch" and "nr" are examined, and
the program returns allow, then we can be sure that the filter must
return allow independent from syscall arguments.
Nearly all seccomp filters are built from these cBPF instructions:
BPF_LD | BPF_W | BPF_ABS
BPF_JMP | BPF_JEQ | BPF_K
BPF_JMP | BPF_JGE | BPF_K
BPF_JMP | BPF_JGT | BPF_K
BPF_JMP | BPF_JSET | BPF_K
BPF_JMP | BPF_JA
BPF_RET | BPF_K
BPF_ALU | BPF_AND | BPF_K
Each of these instructions are emulated. Any weirdness or loading
from a syscall argument will cause the emulator to bail.
The emulation is also halted if it reaches a return. In that case,
if it returns an SECCOMP_RET_ALLOW, the syscall is marked as good.
Emulator structure and comments are from Kees [1] and Jann [2].
Emulation is done at attach time. If a filter depends on more
filters, and if the dependee does not guarantee to allow the
syscall, then we skip the emulation of this syscall.
[1] https://lore.kernel.org/lkml/20200923232923.3142503-5-keescook@chromium.org/
[2] https://lore.kernel.org/lkml/CAG48ez1p=dR_2ikKq=xVxkoGg0fYpTBpkhJSv1w-6BG=76PAvw@mail.gmail.com/
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
Reviewed-by: Jann Horn <jannh@google.com>
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/71c7be2db5ee08905f41c3be5c1ad6e2601ce88f.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit 8e01b51a31)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: I5047f7f0d6502e5de6c047743f1053fda3025a6e
Bug: 176068146
The overhead of running Seccomp filters has been part of some past
discussions [1][2][3]. Oftentimes, the filters have a large number
of instructions that check syscall numbers one by one and jump based
on that. Some users chain BPF filters which further enlarge the
overhead. A recent work [6] comprehensively measures the Seccomp
overhead and shows that the overhead is non-negligible and has a
non-trivial impact on application performance.
We observed some common filters, such as docker's [4] or
systemd's [5], will make most decisions based only on the syscall
numbers, and as past discussions considered, a bitmap where each bit
represents a syscall makes most sense for these filters.
The fast (common) path for seccomp should be that the filter permits
the syscall to pass through, and failing seccomp is expected to be
an exceptional case; it is not expected for userspace to call a
denylisted syscall over and over.
When it can be concluded that an allow must occur for the given
architecture and syscall pair (this determination is introduced in
the next commit), seccomp will immediately allow the syscall,
bypassing further BPF execution.
Each architecture number has its own bitmap. The architecture
number in seccomp_data is checked against the defined architecture
number constant before proceeding to test the bit against the
bitmap with the syscall number as the index of the bit in the
bitmap, and if the bit is set, seccomp returns allow. The bitmaps
are all clear in this patch and will be initialized in the next
commit.
When only one architecture exists, the check against architecture
number is skipped, suggested by Kees Cook [7].
[1] https://lore.kernel.org/linux-security-module/c22a6c3cefc2412cad00ae14c1371711@huawei.com/T/
[2] https://lore.kernel.org/lkml/202005181120.971232B7B@keescook/T/
[3] https://github.com/seccomp/libseccomp/issues/116
[4] ae0ef82b90/profiles/seccomp/default.json
[5] 6743a1caf4/src/shared/seccomp-util.c (L270)
[6] Draco: Architectural and Operating System Support for System Call Security
https://tianyin.github.io/pub/draco.pdf, MICRO-53, Oct. 2020
[7] https://lore.kernel.org/bpf/202010091614.8BB0EB64@keescook/
Co-developed-by: Dimitrios Skarlatos <dskarlat@cs.cmu.edu>
Signed-off-by: Dimitrios Skarlatos <dskarlat@cs.cmu.edu>
Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
Reviewed-by: Jann Horn <jannh@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/10f91a367ec4fcdea7fc3f086de3f5f13a4a7436.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit f9d480b6ff)A
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: I50b6682e17dc6e91b5e92017361200d722282825
Bug: 176068146
Export hrtimer_expire_entry/exit tracepoints, so that vendor modules
can register probes for these tracepoints.
Bug: 175936268
Change-Id: I739f369d3b56e09f8e9061fefdf25830e37e987e
Signed-off-by: Changki Kim <changki.kim@samsung.com>
Export workqueue_execute_start/end tracepoints, so that vendor modules
can register probes for these tracepoints.
Bug: 175936268
Change-Id: Ib4c8f39ff8305a1d52fbca9d06b5e792396a3a2d
Signed-off-by: Changki Kim <changki.kim@samsung.com>
Export irq_handle_exit tracepoint, so that vendor modules
can register probes for this tracepoint.
Bug: 175936268
Change-Id: I8e1eaffb7dd2f257e9c09412aad54ecca62bf019
Signed-off-by: Changki Kim <changki.kim@samsung.com>
Add a restricted vendor hook to check whether a set of tasks can
move to other cgorup.
Bug: 175808144
Signed-off-by: Choonghoon Park <choong.park@samsung.com>
Change-Id: If7bac83e0d2d1069b1436331989c3926645eab19
Changes in 5.10.2
ptrace: Prevent kernel-infoleak in ptrace_get_syscall_info()
ktest.pl: If size of log is too big to email, email error message
ktest.pl: Fix the logic for truncating the size of the log file for email
USB: legotower: fix logical error in recent commit
USB: dummy-hcd: Fix uninitialized array use in init()
USB: add RESET_RESUME quirk for Snapscan 1212
ALSA: usb-audio: Fix potential out-of-bounds shift
ALSA: usb-audio: Fix control 'access overflow' errors from chmap
xhci: Give USB2 ports time to enter U3 in bus suspend
usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK
xhci-pci: Allow host runtime PM as default for Intel Alpine Ridge LP
xhci-pci: Allow host runtime PM as default for Intel Maple Ridge xHCI
USB: UAS: introduce a quirk to set no_write_same
USB: sisusbvga: Make console support depend on BROKEN
ALSA: pcm: oss: Fix potential out-of-bounds shift
serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access
Linux 5.10.2
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0dfd41a3ba5b102699ef78641fbe48ed16957a0f
commit d96f04d347 upstream.
It has been observed that once per 300-1300 port openings the first
transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared
as "e" on the wire). It only happened if single byte has been transmitted
right after port open, which means, DMA is not used for this transfer and
the corruption never happened afterwards.
Therefore I've carefully re-read the MDR1 errata (link below), which says
"when accessing the MDR1 registers that causes a dummy under-run condition
that will freeze the UART in IrDA transmission. In UART mode, this may
corrupt the transferred data". Strictly speaking,
omap_8250_mdr1_errataset() performs a read access and if the value is the
same as should be written, exits without errata-recommended FIFO reset.
A brief check of the serial_omap_mdr1_errataset() from the competing
omap-serial driver showed it has no read access of MDR1. After removing the
read access from omap_8250_mdr1_errataset() the data corruption never
happened any more.
Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf
Fixes: 61929cf016 ("tty: serial: Add 8250-core based omap driver")
Cc: stable@vger.kernel.org
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 862ee699fe upstream.
The console part of sisusbvga is broken vs. printk(). It uses in_atomic()
to detect contexts in which it cannot sleep despite the big fat comment in
preempt.h which says: Do not use in_atomic() in driver code.
in_atomic() does not work on kernels with CONFIG_PREEMPT_COUNT=n which
means that spin/rw_lock held regions are not detected by it.
There is no way to make this work by handing context information through to
the driver and this only can be solved once the core printk infrastructure
supports sleepable console drivers.
Make it depend on BROKEN for now.
Fixes: 1bbb4f2035 ("[PATCH] USB: sisusb[vga] update")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201019101109.603244207@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c6dde8ffd0 upstream.
The current channel-map control implementation in USB-audio driver may
lead to an error message like
"control 3:0:0:Playback Channel Map:0: access overflow"
when CONFIG_SND_CTL_VALIDATION is set. It's because the chmap get
callback clears the whole array no matter which count is set, and
rather the false-positive detection.
This patch fixes the problem by clearing only the needed array range
at usb_chmap_ctl_get().
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201211130048.6358-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 170f4869e6 upstream.
The logic for truncating the log file for emailing based on the
MAIL_MAX_SIZE option is confusing and incorrect. Simplify it and have the
tail of the log file truncated to the max size specified in the config.
Cc: stable@vger.kernel.org
Fixes: 855d8abd2e ("ktest.pl: Change the logic to control the size of the log file emailed")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8cd6bc0359 upstream.
If the size of the error log is too big to send via email, and the sending
fails, it wont email any result. This can be confusing for the user who is
waiting for an email on the completion of the tests.
If it fails to send email, then try again without the log file stating that
it failed to send an email. Obviously this will not be of use if the sending
of email failed for some other reasons, but it will at least give the user
some information when it fails for the most common reason.
Cc: stable@vger.kernel.org
Fixes: c2d84ddb33 ("ktest.pl: Add MAIL_COMMAND option to define how to send email")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Individual cpus may not support 32 bit apps in a mixed 32/64 bit
system. Enable the ASSYMETRIC_AARCH32 config option for arm64
in GKI, to support mixed architectures.
Bug: 175831712
Change-Id: Idae5b4ca869c39ad903f620a2e14f7b04e3a7686
Signed-off-by: Stephen Dickey <dickey@codeaurora.org>
On architectures that support the preservation of memblock metadata
after __init, allow drivers to call memblock_free() to free a
reservation made by early arch code. This is a hack to support the
freeing of bootsplash reservations passed to Linux by the bootloader.
(This should be reworked in future versions of Android; do not
cherry-pick this patch forward.)
Bug: 139653858
Bug: 174620135
Change-Id: I32c0ee70c33c94deff70aa548896caa9978396fb
Signed-off-by: Alistair Delva <adelva@google.com>
Export the per-cpu thermal_pressure symbol so that vendor
module can use arch_scale_thermal_pressure() API.
Bug: 175847109
Change-Id: I33a6994ac62cab883b788a5b4d57ac7a6b736971
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Export irq_handle_entry tracepoint, so that vendor modules
can register probes for this tracepoint.
Bug: 175806230
Change-Id: Iacc331f923d27f1a17065d6c0315c0c054af313e
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
This reverts commit db102bc6be ("ANDROID: GKI: Enable
CONFIG_USB_XHCI_HCD") until vendor code which contrbutes to these
drivers is removed.
Bug: 175625342
Bug: 175743419
Change-Id: I74f33dd54a8f4c498f0311990faa4f2b3524b37b
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This reverts commit b3fd6681f2 ("ANDROID: db845c_gki.fragment: Drop
CONFIG_USB_DWC3 from config frament") until vendor code which
contributes to these drivers is removed.
Bug: 175625342
Bug: 175742587
Change-Id: Ie5029527ed9b55d99d1aa0cde6e7928d124079ea
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This reverts commit 42d1d3ffd7 ("ANDROID: GKI: enable CONFIG_USB_DWC3
to be build in") until vendor code which contributes to these drivers is
removed.
Bug: 175625342
Bug: 175742587
Change-Id: Id4d0edcbefced412dc2718c4936b5ba0cf0b2211
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
