Choose a better name for the include hearder guard used in rtl871x_io.h.
'_IO_H_' is to generic and does not match the comment after the #endif.
Use '_RTL871X_IO_H_' instead.
Also make the comments in the #endif /* XXX */ match the name used in
#ifndef.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20190818150609.3376-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As reported by erofs-utils fuzzer, 2 conditions
can happen in corrupted images, which can cause
unexpected behaviors.
- access the same pcluster one more time;
- access the tail end pcluster again, e.g.
_ access again (will trigger tail merging)
|
1 2 3 1 2 -> 1 2 3 1
|_ tail end of the chain \___/ (unexpected behavior)
Let's detect and avoid them now.
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Link: https://lore.kernel.org/r/20190821030908.40282-1-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As reported by erofs-utils fuzzer, Lookback distance should
be a positive number, so it should be actually looked back
rather than spinning.
Fixes: 02827e1796 ("staging: erofs: add erofs_map_blocks_iter")
Cc: <stable@vger.kernel.org> # 4.19+
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Link: https://lore.kernel.org/r/20190819103426.87579-7-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In preparation to update to bu21013_tp driver properly annotate GPIOs
property (the INT GPIOs are active low, not open drain), and also define
interrupt lines so we do not have to have special conversion in the driver.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For arm32 xdp sockets mmap2 is preferred, so use it if it's defined.
Declaration of __NR_mmap can be skipped and it breaks build.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
For 64-bit there is no reason to use vmap/vunmap, so use page_address
as it was initially. For 32 bits, in some apps, like in samples
xdpsock_user.c when number of pgs in use is quite big, the kmap
memory can be not enough, despite on this, kmap looks like is
deprecated in such cases as it can block and should be used rather
for dynamic mm.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Drop __NR_mmap2 fork in flavor of LFS, that is _FILE_OFFSET_BITS=64
(glibc & bionic) / LARGEFILE64_SOURCE (for musl) decision. It allows
mmap() to use 64bit offset that is passed to mmap2 syscall. As result
pgoff is not truncated and no need to use direct access to mmap2 for
32 bits systems.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
The pmem infrastructure uses memcpy_mcsafe in the pmem layer so as to
convert machine check exceptions into a return value on failure in case
a machine check exception is encountered during the memcpy. The return
value is the number of bytes remaining to be copied.
This patch largely borrows from the copyuser_power7 logic and does not add
the VMX optimizations, largely to keep the patch simple. If needed those
optimizations can be folded in.
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
[arbab@linux.ibm.com: Added symbol export]
Co-developed-by: Santosh Sivaraj <santosh@fossix.org>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190820081352.8641-7-santosh@fossix.org
If we take a UE on one of the instructions with a fixup entry, set nip
to continue execution at the fixup entry. Stop processing the event
further or print it.
Co-developed-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190820081352.8641-6-santosh@fossix.org
Certain architecture specific operating modes (e.g., in powerpc machine
check handler that is unable to access vmalloc memory), the
search_exception_tables cannot be called because it also searches the
module exception tables if entry is not found in the kernel exception
table.
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190820081352.8641-5-santosh@fossix.org
The function doesn't get used outside this file, so make it static.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190820081352.8641-4-santosh@fossix.org
The current code would fail on huge pages addresses, since the shift would
be incorrect. Use the correct page shift value returned by
__find_linux_pte() to get the correct physical address. The code is more
generic and can handle both regular and compound pages.
Fixes: ba41e1e1cc ("powerpc/mce: Hookup derror (load/store) UE errors")
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
[arbab@linux.ibm.com: Fixup pseries_do_memory_failure()]
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190820081352.8641-3-santosh@fossix.org
Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
match what's in the documentation example.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
snd_soc_remove_dai_link() has card connected dai_link check. but
1) we need to call list_del() anyway,
because it is "remove" function,
2) It is doing many thing for this card / dai_link already
before checking dai_link.
This patch removes poinless dai_link check
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/875zms1ldm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_initialize_card_lists() is doing card related
INIT_LIST_HEAD(), but, it is already doing at
snd_soc_register_card(). We don't need to do it separately.
This patch merges these.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/877e781ldq.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Register map for i.MX8QM is similar with i.MX6 series. Integration
of SAI IP into i.MX8QM SOC features a FIFO size of 64 X 32 bits samples.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20190814082911.665-3-daniel.baluta@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SAI module on imx8qm features a register map similar with imx6 series
(it doesn't have VERID and PARAM registers at the beginning
of address spece).
Also, it has one FIFO which can help up to 64 * 32 bit samples.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20190814082911.665-2-daniel.baluta@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the timestamp of module linker scripts are not checked.
Add them to the dependency of modules so they are correctly rebuilt.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These three variables are not intended to be tweaked by users.
Move them from kbuild.rst to makefiles.rst.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now that the single target build descends into sub-directories in the
same way as the normal build, these dummy Makefiles are not needed
any more.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the single target build directly descends into the directory
of the target. For example,
$ make foo/bar/baz.o
... directly descends into foo/bar/.
On the other hand, the normal build usually descends one directory at
a time, i.e. descends into foo/, and then foo/bar/.
This difference causes some problems.
[1] miss subdir-asflags-y, subdir-ccflags-y in upper Makefiles
The options in subdir-{as,cc}flags-y take effect in the current
and its sub-directories. In other words, they are inherited
downward. In the example above, the single target will miss
subdir-{as,cc}flags-y if they are defined in foo/Makefile.
[2] could be built in a different directory
As Documentation/kbuild/modules.rst section 4.3 says, Kbuild can
handle files that are spread over several sub-directories.
The build rule of foo/bar/baz.o may not necessarily be specified in
foo/bar/Makefile. It might be specifies in foo/Makefile as follows:
[foo/Makefile]
obj-y := bar/baz.o
This often happens when a module is so big that its source files
are divided into sub-directories.
In this case, there is no Makefile in the foo/bar/ directory, yet
the single target descends into foo/bar/, then fails due to the
missing Makefile. You can still do 'make foo/bar/' for partial
building, but cannot do 'make foo/bar/baz.s'. I believe the single
target '%.s' is a useful feature for inspecting the compiler output.
Some modules work around this issue by putting an empty Makefile
in every sub-directory.
This commit fixes those problems by making the single target build
descend in the same way as the normal build does.
Another change is the single target build will observe the CONFIG
options. Previously, it allowed users to build the foo.o even when
the corresponding CONFIG_FOO is disabled:
obj-$(CONFIG_FOO) += foo.o
In the new behavior, the single target build will just fail and show
"No rule to make target ..." (or "Nothing to be done for ..." if the
stale object already exists, but cannot be updated).
The disadvantage of this commit is the build speed. Now that the
single target build visits every directory and parses lots of
Makefiles, it is slower than before. (But, I hope it will not be
too slow.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
When kallsyms generation happens, temporary vmlinux outputs are linked
but the quiet make output didn't report it, giving the impression that
the prior command is taking longer than expected.
Instead, report the linking step explicitly. While at it, this
consolidates the repeated "kallsyms generation step" into a single
function and removes the existing copy/pasting.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
scripts/headers_check.pl can detect references to CONFIG options in
exported headers, but it has been disabled for more than a decade.
Reverting commit 7e3fa56141 ("kbuild: drop check for CONFIG_ in
headers_check") would emit the following warnings for headers_check
on x86:
usr/include/mtd/ubi-user.h:283: leaks CONFIG_MTD_UBI_BEB_LIMIT to userspace where it is not valid
usr/include/linux/cm4000_cs.h:26: leaks CONFIG_COMPAT to userspace where it is not valid
usr/include/linux/pkt_cls.h:301: leaks CONFIG_NET_CLS_ACT to userspace where it is not valid
usr/include/linux/videodev2.h:2465: leaks CONFIG_VIDEO_ADV_DEBUG to userspace where it is not valid
usr/include/linux/bpf.h:249: leaks CONFIG_EFFICIENT_UNALIGNED_ACCESS to userspace where it is not valid
usr/include/linux/bpf.h:819: leaks CONFIG_CGROUP_NET_CLASSID to userspace where it is not valid
usr/include/linux/bpf.h:1011: leaks CONFIG_IP_ROUTE_CLASSID to userspace where it is not valid
usr/include/linux/bpf.h:1742: leaks CONFIG_BPF_KPROBE_OVERRIDE to userspace where it is not valid
usr/include/linux/bpf.h:1747: leaks CONFIG_FUNCTION_ERROR_INJECTION to userspace where it is not valid
usr/include/linux/bpf.h:1936: leaks CONFIG_XFRM to userspace where it is not valid
usr/include/linux/bpf.h:2184: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid
usr/include/linux/bpf.h:2210: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid
usr/include/linux/bpf.h:2227: leaks CONFIG_SOCK_CGROUP_DATA to userspace where it is not valid
usr/include/linux/bpf.h:2311: leaks CONFIG_NET to userspace where it is not valid
usr/include/linux/bpf.h:2348: leaks CONFIG_NET to userspace where it is not valid
usr/include/linux/bpf.h:2422: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid
usr/include/linux/bpf.h:2528: leaks CONFIG_NET to userspace where it is not valid
usr/include/linux/pktcdvd.h:37: leaks CONFIG_CDROM_PKTCDVD_WCACHE to userspace where it is not valid
usr/include/linux/hw_breakpoint.h:27: leaks CONFIG_HAVE_MIXED_BREAKPOINTS_REGS to userspace where it is not valid
usr/include/linux/raw.h:17: leaks CONFIG_MAX_RAW_DEVS to userspace where it is not valid
usr/include/linux/elfcore.h:62: leaks CONFIG_BINFMT_ELF_FDPIC to userspace where it is not valid
usr/include/linux/eventpoll.h:82: leaks CONFIG_PM_SLEEP to userspace where it is not valid
usr/include/linux/atmdev.h:104: leaks CONFIG_COMPAT to userspace where it is not valid
usr/include/asm-generic/unistd.h:651: leaks CONFIG_MMU to userspace where it is not valid
usr/include/asm-generic/bitsperlong.h:9: leaks CONFIG_64BIT to userspace where it is not valid
usr/include/asm-generic/fcntl.h:119: leaks CONFIG_64BIT to userspace where it is not valid
usr/include/asm/auxvec.h:14: leaks CONFIG_IA32_EMULATION to userspace where it is not valid
usr/include/asm/e820.h:14: leaks CONFIG_NODES_SHIFT to userspace where it is not valid
usr/include/asm/e820.h:39: leaks CONFIG_X86_PMEM_LEGACY to userspace where it is not valid
usr/include/asm/e820.h:49: leaks CONFIG_INTEL_TXT to userspace where it is not valid
usr/include/asm/mman.h:7: leaks CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS to userspace where it is not valid
Most of these are false positives because scripts/headers_check.pl
parses comment lines.
It is also false negative. arch/x86/include/uapi/asm/auxvec.h contains
CONFIG_IA32_EMULATION and CONFIG_X86_64, but the only former is reported.
It would be possible to fix scripts/headers_check.pl, of course.
However, we already have some duplicated checks between headers_check
and CONFIG_UAPI_HEADER_TEST. At this moment of time, there are still
dozens of headers excluded from the header test (usr/include/Makefile),
but we might be able to remove headers_check eventually.
I re-implemented it in scripts/headers_install.sh by using sed because
the most of code in scripts/headers_install.sh is written in sed.
This patch works like this:
[1] Run scripts/unifdef first because we need to drop the code
surrounded by #ifdef __KERNEL__ ... #endif
[2] Remove all C style comments. The sed code is somewhat complicated
since we need to deal with both single and multi line comments.
Precisely speaking, a comment block is replaced with a space just
in case.
CONFIG_FOO/* this is a comment */CONFIG_BAR
should be converted into:
CONFIG_FOO CONFIG_BAR
instead of:
CONFIG_FOOCONFIG_BAR
[3] Match CONFIG_... pattern. It correctly matches to all CONFIG
options that appear in a single line.
After this commit, this would detect the following warnings, all of
which are real ones.
warning: include/uapi/linux/pktcdvd.h: leak CONFIG_CDROM_PKTCDVD_WCACHE to user-space
warning: include/uapi/linux/hw_breakpoint.h: leak CONFIG_HAVE_MIXED_BREAKPOINTS_REGS to user-space
warning: include/uapi/linux/raw.h: leak CONFIG_MAX_RAW_DEVS to user-space
warning: include/uapi/linux/elfcore.h: leak CONFIG_BINFMT_ELF_FDPIC to user-space
warning: include/uapi/linux/eventpoll.h: leak CONFIG_PM_SLEEP to user-space
warning: include/uapi/linux/atmdev.h: leak CONFIG_COMPAT to user-space
warning: include/uapi/asm-generic/fcntl.h: leak CONFIG_64BIT to user-space
warning: arch/x86/include/uapi/asm/auxvec.h: leak CONFIG_IA32_EMULATION to user-space
warning: arch/x86/include/uapi/asm/auxvec.h: leak CONFIG_X86_64 to user-space
warning: arch/x86/include/uapi/asm/mman.h: leak CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS to user-space
However, it is not nice to show them right now. I created a list of
existing leakages. They are not warned, but a new leakage will be
blocked by the 0-day bot.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
The in-kernel build and external module build have similar code
for descending into sub-directories.
Factor out the code into the common place.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
There is no need to set 0 to variables such as config-targets,
mixed-targets, etc.
Unset instead of setting 0 in order to use 'ifdef' to test them.
I also renamed:
config-targets -> config-build
mixed-targets -> mixed-build
dot-config -> need-config
to clarify what we are doing.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
'make clean' descends into ./Kbuild, but does not clean anything
since everything is added to no-clean-files.
There is no need to descend to ./Kbuild in the first place.
We can drop the no-clean-files assignment.
With this, there is no more user of no-clean-files. I will keep it
for a while to see whether a new user will appear.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Since the R8A774C0 SoC uses DU{0,1} only, the register block length
should be 0x40000.
Based on commit 06585ed38b ("arm64: dts: renesas: r8a77990: Fix
register range of display node") for R-Car E3.
Fixes: 8ed3a6b223 ("arm64: dts: renesas: r8a774c0: Add display output support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
TTM assumes that drivers initialize the embedded GEM object before
calling the ttm_bo_init() function. This is not currently the case
in the Nouveau driver. Fix this by splitting up nouveau_bo_new()
into nouveau_bo_alloc() and nouveau_bo_init() so that the GEM can
be initialized before TTM BO initialization when necessary.
Fixes: b96f3e7c80 ("drm/ttm: use gem vma_node")
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814093524.GA31345@ulmo
Do not expose the base VA (it appears in debugfs). Instead,
record the PA, which at least can be used to precisely identify
the associated irqchip and domain.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The context used to store the key blob used a fixed 80 bytes
buffer. And all the set_key functions did not even check the given key
size. With CCA variable length AES cipher keys there come key blobs
with about 136 bytes and maybe in the future there will arise the need
to store even bigger key blobs.
This patch reworks the paes set_key functions and the context
buffers to work with small key blobs (<= 128 bytes) directly in the
context buffer and larger blobs by allocating additional memory and
storing the pointer in the context buffer. If there has been memory
allocated for storing a key blob, it also needs to be freed on release
of the tfm. So all the paes ciphers now have a init and exit function
implemented for this job.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Introduce new ioctls and structs to be used with these new ioctls
which are able to handle CCA AES secure keys and CCA AES cipher keys:
PKEY_GENSECK2: Generate secure key, version 2.
Generate either a CCA AES secure key or a CCA AES cipher key.
PKEY_CLR2SECK2: Generate secure key from clear key value, version 2.
Construct a CCA AES secure key or CCA AES cipher key from a given
clear key value.
PKEY_VERIFYKEY2: Verify the given secure key, version 2.
Check for correct key type. If cardnr and domain are given, also
check if this apqn is able to handle this type of key. If cardnr and
domain are 0xFFFF, on return these values are filled with an apqn
able to handle this key. The function also checks for the master key
verification patterns of the key matching to the current or
alternate mkvp of the apqn. CCA AES cipher keys are also checked
for CPACF export allowed (CPRTCPAC flag). Currently CCA AES secure
keys and CCA AES cipher keys are supported (may get extended in the
future).
PKEY_KBLOB2PROTK2: Transform a key blob (of any type) into
a protected key, version 2. Difference to version 1 is only that
this new ioctl has additional parameters to provide a list of
apqns to be used for the transformation.
PKEY_APQNS4K: Generate a list of APQNs based on the key blob given.
Is able to find out which type of secure key is given (CCA AES
secure key or CCA AES cipher key) and tries to find all matching
crypto cards based on the MKVP and maybe other criterias (like CCA
AES cipher keys need a CEX6C or higher). The list of APQNs is
further filtered by the key's mkvp which needs to match to either
the current mkvp or the alternate mkvp (which is the old mkvp on CCA
adapters) of the apqns. The flags argument may be used to limit the
matching apqns. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the
current mkvp of each apqn is compared. Likewise with the
PKEY_FLAGS_MATCH_ALT_MKVP. If both are given it is assumed to return
apqns where either the current or the alternate mkvp matches. If no
matching APQN is found, the ioctl returns with 0 but the
apqn_entries value is 0.
PKEY_APQNS4KT: Generate a list of APQNs based on the key type given.
Build a list of APQNs based on the given key type and maybe further
restrict the list by given master key verification patterns.
For different key types there may be different ways to match the
master key verification patterns. For CCA keys (CCA data key and CCA
cipher key) the first 8 bytes of cur_mkvp refer to the current mkvp
value of the apqn and the first 8 bytes of the alt_mkvp refer to the
old mkvp. The flags argument controls if the apqns current and/or
alternate mkvp should match. If the PKEY_FLAGS_MATCH_CUR_MKVP is
given, only the current mkvp of each apqn is compared. Likewise with
the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given, it is assumed to
return apqns where either the current or the alternate mkvp
matches. If no matching APQN is found, the ioctl returns with 0 but
the apqn_entries value is 0.
These new ioctls are now prepared for another new type of secure key
blob which may come in the future. They all use a pointer to the key
blob and a key blob length information instead of some hardcoded byte
array. They all use the new enums pkey_key_type, pkey_key_size and
pkey_key_info for getting/setting key type, key size and additional
info about the key. All but the PKEY_VERIFY2 ioctl now work based on a
list of apqns. This list is walked through trying to perform the
operation on exactly this apqn without any further checking (like card
type or online state). If the apqn fails, simple the next one in the
list is tried until success (return 0) or the end of the list is
reached (return -1 with errno ENODEV). All apqns in the list need to
be exact apqns (0xFFFF as any card or domain is not allowed). There
are two new ioctls which can be used to build a list of apqns based on
a key or key type and maybe restricted by match to a current or
alternate master key verifcation pattern.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
This patch adds low level functions, structs and defines to support
CCA AES cipher keys:
- struct cipherkeytoken can be used for an inside view of the CCA AES
cipher key token blob.
- function cca_cipher2protkey() derives an CPACF protected key from an
CCA AES cipher key.
- function cca_gencipherkey() generates an CCA AES cipher key with
random value.
- function cca_findcard2() constructs a list of apqns based on input
constrains like min hardware type, mkvp values.
- cca_check_secaescipherkey() does a check on the given CCA AES cipher
key blob.
- cca_clr2cipherkey() generates an CCA AES cipher key from a given
clear key value.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Rework and extension of the cca_findcard function to be prepared for
other types of secure key blobs. Split the function and extract an
internal function which has no awareness of key blobs any
more. Improve this function and the helper code around to be able to
check for a minimal crypto card hardware level (Background: the newer
AES cipher keys need to match to the master key verification pattern
and need to have a crypto card CEX6 or higher).
No API change, neither for the in-kernel API nor the ioctl interface.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
There are a lot of pkey functions exported as in-kernel callable
API functions but not used at all. This patch narrows down the
pkey in-kernel API to what is currently only used and exploited.
Within the kernel just use u32 without any leading __u32. Also
functions declared in a header file in arch/s390/include/asm
don't need a comment 'In-kernel API', this is by definition,
otherwise the header file would be in arch/s390/include/uapi/asm.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Make a usable value out of "mem" option once and for all. Kasan memory
allocator just takes memory_end or online memory size as allocation
base. If memory_end is not aligned paging structures allocated in kasan
end up unaligned as well. So this change fixes potential kasan crash
as well.
Fixes: 78333d1f90 ("s390/kasan: add support for mem= kernel parameter")
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Use common arch_stack_walk infrastructure to avoid duplicated code and
avoid taking care of the stack storage and filtering.
Common code also uses try_get_task_stack/put_task_stack when needed which
have been missing in our code, which also solves potential problem for us.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Reading other running task's stack can be a dangerous endeavor. Kasan
stack memory access instrumentation includes special prologue and epilogue
to mark/remove red zones in shadow memory between stack variables. For
that reason there is always a race between a task reading value in other
task's stack and that other task returning from a function and entering
another one generating different red zones pattern.
To avoid kasan reports simply perform uninstrumented memory reads.
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
With THREAD_INFO_IN_TASK (which is selected on s390) task's stack usage
is refcounted and should always be protected by get/put when touching
other task's stack to avoid race conditions with task's destruction code.
Fixes: d5c352cdd0 ("s390: move thread_info into task_struct")
Cc: stable@vger.kernel.org # v4.10+
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
s390 kasan code uses sclp_early_printk to report initialization
failures. The code doing that should not be instrumented, because kasan
shadow memory has not been set up yet. Even though sclp_early_core.c is
compiled with instrumentation disabled it uses strlen function, which
is instrumented and would produce shadow memory access if used. To
avoid that, introduce uninstrumented __strlen function to be used
instead.
Before commit 7e0d92f002 ("s390/kasan: improve string/memory functions
checks") few string functions (including strlen) were escaping kasan
instrumentation due to usage of platform specific versions which are
implemented in inline assembly.
Fixes: 7e0d92f002 ("s390/kasan: improve string/memory functions checks")
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Clean uncompressed kernel .bss section in the startup code before
the uncompressed kernel is executed. At this point of time initrd and
certificates have been already rescued. Uncompressed kernel .bss size
is known from vmlinux_info. It is also taken into consideration during
uncompressed kernel positioning by kaslr (so it is safe to clean it).
With that uncompressed kernel is starting with .bss section zeroed and
no .bss section usage restrictions apply. Which makes chkbss checks for
uncompressed kernel objects obsolete and they can be removed.
early_nobss.c is also not needed anymore. Parts of it which are still
relevant are moved to early.c. Kasan initialization code is now called
directly from head64 (early.c is instrumented and should not be
executed before kasan shadow memory is set up).
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Static variable kirin_dw_pcie_ops, of type dw_pcie_ops, is used only
once, when it is assigned to the constant field ops of variable pci
(having type dw_pcie) so kirin_dw_pcie_ops is never modified.
Make it constant to protect it from unintended modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Christophe JAILLET