Re: [PATCH v3 5/7] KVM: PPC: reimplements LOAD_VSX/STORE_VSX instruction mmio emulation with analyse_intr() input

Hi Paul, On Tue, May 22, 2018 at 07:41:51PM +1000, Paul Mackerras wrote: > On Mon, May 21, 2018 at 01:24:24PM +0800, wei.guo.si...@gmail.com wrote: > > From: Simon Guo > > > > This patch reimplements LOAD_VSX/STORE_VSX instruction MMIO emulation with > > analyse_intr()

Re: [RFC v4 4/4] hotplug/drcinfo: Code cleanup for devices

See below. On 05/22/2018 04:39 PM, Nathan Fontenot wrote: > On 05/22/2018 11:37 AM, Michael Bringmann wrote: >> This patch extends the use of a common parse function for the >> ibm,drc-info property that can be modified by a callback function >> to the hotplug device processing. Candidate code

Re: [RFC v4 3/4] hotplug/drcinfo: Fix hot-add CPU issues

See below. On 05/22/2018 04:31 PM, Nathan Fontenot wrote: > On 05/22/2018 11:37 AM, Michael Bringmann wrote: >> This patch applies a common parse function for the ibm,drc-info >> property that can be modified by a callback function to the >> hot-add CPU code. Candidate code is replaced by a call

Re: [RFC v4 2/4] hotplug/drcinfo: Provide parser with callback

See below. On 05/22/2018 04:23 PM, Nathan Fontenot wrote: > On 05/22/2018 11:37 AM, Michael Bringmann wrote: >> This patch provides a common parse function for the ibm,drc-info >> property that can be modified by a callback function. The caller >> provides a pointer to the function and a pointer

Re: [RFC v4 2/4] hotplug/drcinfo: Provide parser with callback

See below. On 05/22/2018 04:02 PM, Nathan Fontenot wrote: > On 05/22/2018 11:37 AM, Michael Bringmann wrote: >> This patch provides a common parse function for the ibm,drc-info >> property that can be modified by a callback function. The caller >> provides a pointer to the function and a pointer

[PATCH v7 13/14] ima: Write modsig to the measurement list

Add modsig support to the "sig" template field, allowing the the contents of the modsig to be included in the measurement list. Suggested-by: Mimi Zohar Signed-off-by: Thiago Jung Bauermann --- security/integrity/ima/ima.h | 7

[PATCH v7 14/14] ima: Store the measurement again when appraising a modsig

If the IMA template contains the 'sig' field, then the modsig should be added to the measurement list when the file is appraised, and that is what normally happens. But If a measurement rule caused a file containing a modsig to be measured before a different rule causes it to be appraised, the

[PATCH v7 12/14] ima: Add new "d-sig" template field

Define new "d-sig" template field which holds the digest that is expected to match the one contained in the modsig. Suggested-by: Mimi Zohar Signed-off-by: Thiago Jung Bauermann --- Documentation/security/IMA-templates.rst | 5 +

[PATCH v7 11/14] ima: Implement support for module-style appended signatures

Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case both are present in the same file, IMA will first check whether the key used by the xattr signature is present in the kernel keyring. If not, it will try the appended signature.

[PATCH v7 10/14] ima: Add modsig appraise_type option for module-style appended signatures

Introduce the modsig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule: appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig With this rule, IMA will accept either a

[PATCH v7 09/14] ima: Export func_tokens

ima_read_modsig() will need it so that it can show an error message. Signed-off-by: Thiago Jung Bauermann --- security/integrity/ima/ima.h| 2 ++ security/integrity/ima/ima_policy.c | 12 ++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH v7 08/14] ima: Introduce is_signed()

With the introduction of another IMA signature type (modsig), some places will need to check for both of them. It is cleaner to do that if there's a helper function to tell whether an xattr_value represents an IMA signature. Suggested-by: Mimi Zohar Signed-off-by:

[PATCH v7 07/14] integrity: Select CONFIG_KEYS instead of depending on it

This avoids a dependency cycle in soon-to-be-introduced CONFIG_IMA_APPRAISE_MODSIG: it will select CONFIG_MODULE_SIG_FORMAT which in turn selects CONFIG_KEYS. Kconfig then complains that CONFIG_INTEGRITY_SIGNATURE depends on CONFIG_KEYS. Signed-off-by: Thiago Jung Bauermann

[PATCH v7 06/14] integrity: Introduce asymmetric_sig_has_known_key()

IMA will only look for a modsig if the xattr sig references a key which is not in the expected kernel keyring. To that end, introduce asymmetric_sig_has_known_key(). The logic of extracting the key used in the xattr sig is factored out from asymmetric_verify() so that it can be used by the new

[PATCH v7 04/14] integrity: Introduce struct evm_xattr

Even though struct evm_ima_xattr_data includes a fixed-size array to hold a SHA1 digest, most of the code ignores the array and uses the struct to mean "type indicator followed by data of unspecified size" and tracks the real size of what the struct represents in a separate length variable. The

[PATCH v7 05/14] integrity: Introduce integrity_keyring_from_id()

IMA will need to obtain the keyring used to verify file signatures so that it can verify the module-style signature appended to files. Signed-off-by: Thiago Jung Bauermann Signed-off-by: Mimi Zohar --- security/integrity/digsig.c| 28

[PATCH v7 03/14] PKCS#7: Introduce pkcs7_get_digest()

IMA will need to access the digest of the PKCS7 message (as calculated by the kernel) before the signature is verified, so introduce pkcs7_get_digest() for that purpose. Also, modify pkcs7_digest() to detect when the digest was already calculated so that it doesn't have to do redundant work.

[PATCH v7 02/14] PKCS#7: Refactor verify_pkcs7_signature() and add pkcs7_get_message_sig()

IMA will need to verify a PKCS#7 which has already been parsed. For this reason, factor out the code which does that from verify_pkcs7_signature() into a new function which takes a struct pkcs7_message instead of a data buffer. In addition, IMA will need to know the key that signed a given PKCS#7

[PATCH v7 01/14] MODSIGN: Export module signature definitions

IMA will use the module_signature format for append signatures, so export the relevant definitions and factor out the code which verifies that the appended signature trailer is valid. Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it and be able to use validate_module_sig()

[PATCH v7 00/14] Appended signatures support for IMA appraisal

Hello, The main difference in this version is the addition of the last patch, which ensures that there will always be a measurement entry containing the appended modsig if one was used to appraise the file. The patch description and comments in the code should explain in which circumstances the

[RFC v5 7/7] migration/memory: Support 'ibm,dynamic-memory-v2'

migration/memory: This patch adds recognition for changes to the associativity of memory blocks described by 'ibm,dynamic-memory-v2' in order to update local and general kernel data structures to reflect those changes. Support builds upon previous patches to check for associativity changes in

[RFC v7 6/7] migration/memory: Update memory for assoc changes

migration/memory: This patch adds more recognition for changes to the associativity of memory blocks described by the device-tree properties and updates local and general kernel data structures to reflect those changes. These differences may include: * Evaluating 'ibm,dynamic-memory' properties

[RFC v7 5/7] powerpc/mobility: Add lock/unlock device hotplug

powerpc/mobility: Add device lock/unlock to PowerPC 'mobility' operation to delay the operation of CPU DLPAR work queue operations by the 'readd' activity until after any changes to the corresponding device-tree properties have been written. Signed-off-by: Michael Bringmann

[RFC v7 4/7] powerpc/dlpar: Provide CPU readd operation

powerpc/dlpar: Provide hotplug CPU 'readd by index' operation to support LPAR Post Migration state updates. When such changes are invoked by the PowerPC 'mobility' code, they will be queued up so that modifications to CPU properties will take place after the new property value is written to the

[RFC v7 3/7] migration/dlpar: Add operation queuing function

migration/dlpar: This patch adds function dlpar_queue_action() which will queue a worker function to invoke an operation according to resource type, action code, and DRC index. Initial usage is for the 'readd' CPU and Memory blocks identified as having changed their associativity during a

[RFC v7 2/7] powerpc/cpu: Conditionally acquire/release DRC index

powerpc/cpu: Modify dlpar_cpu_add and dlpar_cpu_remove to allow the skipping of DRC index acquire or release operations during the CPU add or remove operations. This is intended to support subsequent changes to provide a 'CPU readd' operation. Signed-off-by: Michael Bringmann

[RFC v7 1/7] powerpc/drmem: Export 'dynamic-memory' loader

powerpc/drmem: Export many of the functions of DRMEM to parse "ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during hotplug operations and for Post Migration events. Also modify the DRMEM initialization code to allow it to, * Be called after system initialization * Provide a separate user copy

[RFC v7 0/7] powerpc/hotplug: Fix affinity assoc for LPAR migration

The migration of LPARs across Power systems affects many attributes including that of the associativity of memory blocks and CPUs. The patches in this set execute when a system is coming up fresh upon a migration target. They are intended to, * Recognize changes to the associativity of memory

Re: [RFC v5 6/6] migration/memory: Update memory for assoc changes

This patch was intended to apply the necessary changes for the 'ibm,dynamic-memory[-v2]' properties. Before the advent of the LMB representation, that code took up a lot more space. At this point, it has shrunk to only one line of unique change. I was hoping to include it here rather than

Re: [RFC v5 3/6] migration/dlpar: Add device readd queuing function

On 05/22/2018 03:24 PM, Thomas Falcon wrote: > On 05/21/2018 12:52 PM, Michael Bringmann wrote: >> migration/dlpar: This patch adds function dlpar_readd_action() >> which will queue a worker function to 'readd' a device in the >> system. Such devices must be identified by a 'resource' type >>

Re: [RFC v5 2/6] powerpc/cpu: Conditionally acquire/release DRC index

Okay. Moving validity check mentioned at bottom of patch to 4/6, Provide CPU readd operation. On 05/22/2018 03:17 PM, Nathan Fontenot wrote: > On 05/21/2018 12:52 PM, Michael Bringmann wrote: >> powerpc/cpu: Modify dlpar_cpu_add and dlpar_cpu_remove to allow the >> skipping of DRC index acquire

[RFC v5 6/6] migration/memory: Update memory for assoc changes

migration/memory: This patch adds more recognition for changes to the associativity of memory blocks described by the device-tree properties and updates local and general kernel data structures to reflect those changes. These differences may include: * Evaluating 'ibm,dynamic-memory' properties

[RFC v5 5/6] powerpc/mobility: Add lock/unlock device hotplug

powerpc/mobility: Add device lock/unlock to PowerPC 'mobility' operation to delay the operation of CPU DLPAR work queue operations by the 'readd' activity until after any changes to the corresponding device-tree properties have been written. Signed-off-by: Michael Bringmann

[RFC v5 4/6] powerpc/dlpar: Provide CPU readd operation

powerpc/dlpar: Provide hotplug CPU 'readd by index' operation to support LPAR Post Migration state updates. When such changes are invoked by the PowerPC 'mobility' code, they will be queued up so that modifications to CPU properties will take place after the new property value is written to the

[RFC v5 3/6] migration/dlpar: Add device readd queuing function

migration/dlpar: This patch adds function dlpar_readd_action() which will queue a worker function to 'readd' a device in the system. Such devices must be identified by a 'resource' type and a drc_index to be readded. Signed-off-by: Michael Bringmann ---

[RFC v5 2/6] powerpc/cpu: Conditionally acquire/release DRC index

powerpc/cpu: Modify dlpar_cpu_add and dlpar_cpu_remove to allow the skipping of DRC index acquire or release operations during the CPU add or remove operations. This is intended to support subsequent changes to provide a 'CPU readd' operation. Signed-off-by: Michael Bringmann

[RFC v5 1/6] powerpc/drmem: Export 'dynamic-memory' loader

powerpc/drmem: Export many of the functions of DRMEM to parse "ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during hotplug operations and for Post Migration events. Also modify the DRMEM initialization code to allow it to, * Be called after system initialization * Provide a separate user copy

[RFC v6 0/6] powerpc/hotplug: Fix affinity assoc for LPAR migration

The migration of LPARs across Power systems affects many attributes including that of the associativity of memory blocks and CPUs. The patches in this set execute when a system is coming up fresh upon a migration target. They are intended to, * Recognize changes to the associativity of memory

Re: [RFC v4 4/4] hotplug/drcinfo: Code cleanup for devices

On 05/22/2018 11:37 AM, Michael Bringmann wrote: > This patch extends the use of a common parse function for the > ibm,drc-info property that can be modified by a callback function > to the hotplug device processing. Candidate code is replaced by > a call to the parser including a pointer to a

Re: [RFC v4 3/4] hotplug/drcinfo: Fix hot-add CPU issues

On 05/22/2018 11:37 AM, Michael Bringmann wrote: > This patch applies a common parse function for the ibm,drc-info > property that can be modified by a callback function to the > hot-add CPU code. Candidate code is replaced by a call to the > parser including a pointer to a local context-specific

Re: [RFC v4 2/4] hotplug/drcinfo: Provide parser with callback

On 05/22/2018 11:37 AM, Michael Bringmann wrote: > This patch provides a common parse function for the ibm,drc-info > property that can be modified by a callback function. The caller > provides a pointer to the function and a pointer to their unique > data, and the parser provides the current lmb

Re: [RFC PATCH] powerpc/fsl: Add barrier_nospec implementation for NXP PowerPC Book E

On Tue, 2018-05-22 at 10:10 +0300, Diana Craciun wrote: > Implement the barrier_nospec as a isync;sync instruction sequence. > The implementation uses the infrastructure built for BOOK3S 64 > with the difference that for NXP platforms there is no firmware involved > and the need for a speculation

Re: [RFC v5 6/6] migration/memory: Update memory for assoc changes

On 05/21/2018 12:52 PM, Michael Bringmann wrote: > migration/memory: This patch adds more recognition for changes to > the associativity of memory blocks described by the device-tree > properties and updates local and general kernel data structures to > reflect those changes. These differences

Re: [RFC v5 3/6] migration/dlpar: Add device readd queuing function

On 05/21/2018 12:52 PM, Michael Bringmann wrote: > migration/dlpar: This patch adds function dlpar_readd_action() > which will queue a worker function to 'readd' a device in the > system. Such devices must be identified by a 'resource' type > and a drc_index to be readded. The function in the

Re: [RFC v4 2/4] hotplug/drcinfo: Provide parser with callback

On 05/22/2018 11:37 AM, Michael Bringmann wrote: > This patch provides a common parse function for the ibm,drc-info > property that can be modified by a callback function. The caller > provides a pointer to the function and a pointer to their unique > data, and the parser provides the current lmb

Re: [RFC v4 1/4] hotplug/drcinfo: Simplify parse ibm, drc-info structs

On 05/22/2018 11:37 AM, Michael Bringmann wrote: > Replace use of of_prop_next_u32() in when parsing 'ibm,drc-info' > structure to simplify and reduce parsing code. > You mention that this patch is to fix the parsing of the drc-info struct, but you end up making changes to the parsing code in

Re: [RFC v5 2/6] powerpc/cpu: Conditionally acquire/release DRC index

On 05/21/2018 12:52 PM, Michael Bringmann wrote: > powerpc/cpu: Modify dlpar_cpu_add and dlpar_cpu_remove to allow the > skipping of DRC index acquire or release operations during the CPU > add or remove operations. This is intended to support subsequent > changes to provide a 'CPU readd'

Re: [PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps

On Tue, 22 May 2018 22:46:13 +0530, Sandipan Das wrote: > + if (info.nr_jited_func_lens && info.jited_func_lens) { > + struct kernel_sym *sym = NULL; > + unsigned char *img = buf; > + __u64 *ksyms = NULL; > +

Re: [PATCH bpf-next v3 07/10] bpf: fix multi-function JITed dump obtained via syscall

On Tue, 22 May 2018 22:46:10 +0530, Sandipan Das wrote: > Currently, for multi-function programs, we cannot get the JITed > instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD > command. Because of this, userspace tools such as bpftool fail > to identify a multi-function program as

Re: [PATCH bpf-next v3 06/10] tools: bpftool: resolve calls without using imm field

On Tue, 22 May 2018 22:46:09 +0530, Sandipan Das wrote: > Currently, we resolve the callee's address for a JITed function > call by using the imm field of the call instruction as an offset > from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further > use this address to get the callee's

[PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps

This splits up the contiguous JITed dump obtained via the bpf system call into more relatable chunks for each function in the program. If the kernel symbols corresponding to these are known, they are printed in the header for each JIT image dump otherwise the masked start address is printed.

[PATCH bpf-next v3 09/10] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the JITed image lengths of each function in a multi-function program. Signed-off-by: Sandipan Das --- tools/include/uapi/linux/bpf.h | 2 ++ 1 file changed, 2

[PATCH bpf-next v3 08/10] bpf: get JITed image lengths of functions via syscall

This adds new two new fields to struct bpf_prog_info. For multi-function programs, these fields can be used to pass a list of the JITed image lengths of each function for a given program to userspace using the bpf system call with the BPF_OBJ_GET_INFO_BY_FD command. This can be used by userspace

[PATCH bpf-next v3 07/10] bpf: fix multi-function JITed dump obtained via syscall

Currently, for multi-function programs, we cannot get the JITed instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD command. Because of this, userspace tools such as bpftool fail to identify a multi-function program as being JITed or not. With the JIT enabled and the test program

[PATCH bpf-next v3 04/10] bpf: get kernel symbol addresses via syscall

This adds new two new fields to struct bpf_prog_info. For multi-function programs, these fields can be used to pass a list of kernel symbol addresses for all functions in a given program to userspace using the bpf system call with the BPF_OBJ_GET_INFO_BY_FD command. When bpf_jit_kallsyms is

[PATCH bpf-next v3 06/10] tools: bpftool: resolve calls without using imm field

Currently, we resolve the callee's address for a JITed function call by using the imm field of the call instruction as an offset from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further use this address to get the callee's kernel symbol's name. For some architectures, such as powerpc64,

[PATCH bpf-next v3 05/10] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the addresses of the kernel symbols corresponding to each function in a program. Signed-off-by: Sandipan Das --- v3: - Move new fields to the end of

[PATCH bpf-next v3 03/10] bpf: powerpc64: add JIT support for multi-function programs

This adds support for bpf-to-bpf function calls in the powerpc64 JIT compiler. The JIT compiler converts the bpf call instructions to native branch instructions. After a round of the usual passes, the start addresses of the JITed images for the callee functions are known. Finally, to fixup the

[PATCH bpf-next v3 02/10] bpf: powerpc64: pad function address loads with NOPs

For multi-function programs, loading the address of a callee function to a register requires emitting instructions whose count varies from one to five depending on the nature of the address. Since we come to know of the callee's address only before the extra pass, the number of instructions

[PATCH bpf-next v3 01/10] bpf: support 64-bit offsets for bpf function calls

The imm field of a bpf instruction is a signed 32-bit integer. For JITed bpf-to-bpf function calls, it holds the offset of the start address of the callee's JITed image from __bpf_call_base. For some architectures, such as powerpc64, this offset may be as large as 64 bits and cannot be

[PATCH bpf-next v3 00/10] bpf: enhancements for multi-function programs

v3: - Change base tree tag to bpf-next. - Incorporate review comments from Alexei, Daniel and Jakub. - Make sure that the JITed image does not grow or shrink after the last pass due to the way the instruction sequence used to load a callee's address maybe optimized. - Make additional

[RFC v4 4/4] hotplug/drcinfo: Code cleanup for devices

This patch extends the use of a common parse function for the ibm,drc-info property that can be modified by a callback function to the hotplug device processing. Candidate code is replaced by a call to the parser including a pointer to a local context-specific functions, and local data. In

[RFC v4 3/4] hotplug/drcinfo: Fix hot-add CPU issues

This patch applies a common parse function for the ibm,drc-info property that can be modified by a callback function to the hot-add CPU code. Candidate code is replaced by a call to the parser including a pointer to a local context-specific functions, and local data. In addition, a bug in the

[RFC v4 2/4] hotplug/drcinfo: Provide parser with callback

This patch provides a common parse function for the ibm,drc-info property that can be modified by a callback function. The caller provides a pointer to the function and a pointer to their unique data, and the parser provides the current lmb set from the struct. The callback function may return

[RFC v4 1/4] hotplug/drcinfo: Simplify parse ibm,drc-info structs

Replace use of of_prop_next_u32() in when parsing 'ibm,drc-info' structure to simplify and reduce parsing code. Signed-off-by: Michael Bringmann Fixes: 3f38000eda48 ("powerpc/firmware: Add definitions for new drc-info firmware feature" -- end of patch series applied to

[RFC v4 0/4] powerpc/drcinfo: Fix bugs 'ibm,drc-info' property

This patch set corrects some errors and omissions in the previous set of patches adding support for the "ibm,drc-info" property to powerpc systems. Unfortunately, some errors in the previous patch set break things in some of the DLPAR operations. In particular when attempting to hot-add a new

[PATCH v3 3/3] powerpc/lib: optimise PPC32 memcmp

At the time being, memcmp() compares two chunks of memory byte per byte. This patch optimises the comparison by comparing word by word. A small benchmark performed on an 8xx comparing two chuncks of 512 bytes performed 10 times gives: Before : 5852274 TB ticks After: 1488638 TB ticks

[PATCH v3 2/3] powerpc/lib: optimise 32 bits __clear_user()

Rewrite clear_user() on the same principle as memset(0), making use of dcbz to clear complete cache lines. This code is a copy/paste of memset(), with some modifications in order to retrieve remaining number of bytes to be cleared, as it needs to be returned in case of error. On a MPC885,

[PATCH v3 1/3] powerpc/lib: move PPC32 specific functions out of string.S

In preparation of optimisation patches, move PPC32 specific memcmp() and __clear_user() into string_32.S Signed-off-by: Christophe Leroy --- arch/powerpc/lib/Makefile| 5 +-- arch/powerpc/lib/string.S| 61 -

[PATCH v3 0/3] powerpc/lib: Optimisation of string functions for PPC32 - part 1

This serie intends to optimise string functions for PPC32 in the same spirit as already done on PPC64. The first patch moves PPC32 specific functions from string.S into a dedicated file named string_32.S The second patch rewrites __clear_user() by using dcbz intruction The third patch rewrites

Re: [PATCH] pseries/memory-hotplug: Only update DT once per memory DLPAR request

Hi Michael, I sent this patch out several weeks ago, just wanted to make sure it hasn't fallen off your radar. Thanks, -Nathan On 04/20/2018 03:29 PM, Nathan Fontenot wrote: > The updates to powerpc numa and memory hotplug code now use the > in-kernel LMB array instead of the device tree. This

Re: [PATCH v7 2/3] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()

Le 22/05/2018 à 16:38, Nicholas Piggin a écrit : On Tue, 22 May 2018 16:02:56 +0200 (CEST) Christophe Leroy wrote: Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every userspace instruction miss") has shown that limiting the read of faulting instruction

[PATCH stable 4.16 14/14] powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit

From: Nicholas Piggin commit a048a07d7f4535baa4cbad6bc024f175317ab938 upstream. On some CPUs we can prevent a vulnerability related to store-to-load forwarding by preventing store forwarding between privilege domains, by inserting a barrier in kernel entry and exit paths.

[PATCH stable 4.16 13/14] powerpc: Move default security feature flags

From: Mauricio Faria de Oliveira commit e7347a86830f38dc3e40c8f7e28c04412b12a2e7 upstream. This moves the definition of the default security feature flags (i.e., enabled by default) closer to the security feature flags. This can be used to restore current flags to

[PATCH stable 4.16 12/14] powerpc/pseries: Fix clearing of security feature flags

From: Mauricio Faria de Oliveira commit 0f9bdfe3c77091e8704d2e510eb7c2c2c6cde524 upstream. The H_CPU_BEHAV_* flags should be checked for in the 'behaviour' field of 'struct h_cpu_char_result' -- 'character' is for H_CPU_CHAR_* flags. Found by playing around with

[PATCH stable 4.16 11/14] powerpc/64s: Wire up cpu_show_spectre_v2()

commit d6fbe1c55c55c6937cbea3531af7da84ab7473c3 upstream. Add a definition for cpu_show_spectre_v2() to override the generic version. This has several permuations, though in practice some may not occur we cater for any combination. The most verbose is: Mitigation: Indirect branch

[PATCH stable 4.16 10/14] powerpc/64s: Wire up cpu_show_spectre_v1()

commit 56986016cb8cd9050e601831fe89f332b4e3c46e upstream. Add a definition for cpu_show_spectre_v1() to override the generic version. Currently this just prints "Not affected" or "Vulnerable" based on the firmware flag. Although the kernel does have array_index_nospec() in a few places, we

[PATCH stable 4.16 09/14] powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()

commit 2e4a16161fcd324b1f9bf6cb6856529f7eaf0689 upstream. Now that we have the security flags we can simplify the code in pseries_setup_rfi_flush() because the security flags have pessimistic defaults. Signed-off-by: Michael Ellerman ---

[PATCH stable 4.16 08/14] powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()

commit 37c0bdd00d3ae83369ab60a6712c28e11e6458d5 upstream. Now that we have the security flags we can significantly simplify the code in pnv_setup_rfi_flush(), because we can use the flags instead of checking device tree properties and because the security flags have pessimistic defaults.

[PATCH stable 4.16 06/14] powerpc/64s: Move cpu_show_meltdown()

commit 8ad33041563a10b34988800c682ada14b2612533 upstream. This landed in setup_64.c for no good reason other than we had nowhere else to put it. Now that we have a security-related file, that is a better place for it so move it. Signed-off-by: Michael Ellerman ---

[PATCH stable 4.16 07/14] powerpc/64s: Enhance the information in cpu_show_meltdown()

commit ff348355e9c72493947be337bb4fae4fc1a41eba upstream. Now that we have the security feature flags we can make the information displayed in the "meltdown" file more informative. Signed-off-by: Michael Ellerman --- arch/powerpc/include/asm/security_features.h | 1 +

[PATCH stable 4.16 05/14] powerpc/powernv: Set or clear security feature flags

commit 77addf6e95c8689e478d607176b399a6242a777e upstream. Now that we have feature flags for security related things, set or clear them based on what we see in the device tree provided by firmware. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/powernv/setup.c

[PATCH stable 4.16 04/14] powerpc/pseries: Set or clear security feature flags

commit f636c14790ead6cc22cf62279b1f8d7e11a67116 upstream. Now that we have feature flags for security related things, set or clear them based on what we receive from the hypercall. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/pseries/setup.c | 43

[PATCH stable 4.16 03/14] powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags

commit c4bc36628d7f8b664657d8bd6ad1c44c177880b7 upstream. Add some additional values which have been defined for the H_GET_CPU_CHARACTERISTICS hypercall. Signed-off-by: Michael Ellerman --- arch/powerpc/include/asm/hvcall.h | 3 +++ 1 file changed, 3 insertions(+) diff

[PATCH stable 4.16 02/14] powerpc: Add security feature flags for Spectre/Meltdown

commit 9a868f634349e62922c226834aa23e3d1329ae7f upstream. This commit adds security feature flags to reflect the settings we receive from firmware regarding Spectre/Meltdown mitigations. The feature names reflect the names we are given by firmware on bare metal machines. See the hostboot source

[PATCH stable 4.16 01/14] powerpc/rfi-flush: Always enable fallback flush on pseries

commit 84749a58b6e382f109abf1e734bc4dd43c2c25bb upstream. This ensures the fallback flush area is always allocated on pseries, so in case a LPAR is migrated from a patched to an unpatched system, it is possible to enable the fallback flush in the target system. Signed-off-by: Michael Ellerman

[PATCH stable 4.16 00/14] powerpc backports for 4.16

Hi Greg, Please queue up this series of patches for 4.16 if you have no objections. These are mostly clean backports but one or two required some fixing up, hench the backport. cheers Mauricio Faria de Oliveira (2): powerpc/pseries: Fix clearing of security feature flags powerpc: Move

Re: [PATCH v7 2/3] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()

On Tue, 22 May 2018 16:02:56 +0200 (CEST) Christophe Leroy wrote: > Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every > userspace instruction miss") has shown that limiting the read of > faulting instruction to likely cases improves performance. > > This

[PATCH v7 3/3] powerpc/mm: Use instruction symbolic names in store_updates_sp()

Use symbolic names defined in asm/ppc-opcode.h instead of hardcoded values. Signed-off-by: Christophe Leroy --- v7: New arch/powerpc/include/asm/ppc-opcode.h | 1 + arch/powerpc/mm/fault.c | 26 +- 2 files changed, 14

[PATCH v7 2/3] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()

Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every userspace instruction miss") has shown that limiting the read of faulting instruction to likely cases improves performance. This patch goes further into this direction by limiting the read of the faulting instruction to the only

[PATCH v7 1/3] powerpc/mm: Move get_user() out of store_updates_sp()

In preparation of the following patch which will focus on calling that get_user() only when necessary, this patch takes out of store_updates_sp() the call to get_user() used to read the faulting instruction. Signed-off-by: Christophe Leroy --- v7: New

[FIX PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

This configuration variable will be used to build the code needed to handle speculative page fault. By default it is turned off, and activated depending on architecture support, ARCH_HAS_PTE_SPECIAL, SMP and MMU. The architecture support is needed since the speculative page fault handler is

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

On 17/05/2018 18:36, Randy Dunlap wrote: > Hi, > > On 05/17/2018 04:06 AM, Laurent Dufour wrote: >> This configuration variable will be used to build the code needed to >> handle speculative page fault. >> >> By default it is turned off, and activated depending on architecture >> support,

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

On 17/05/2018 19:19, Matthew Wilcox wrote: > On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote: >>> +If the speculative page fault fails because of a concurrency is >> >> because a concurrency is > > While one can use concurrency as a noun,

Re: [PATCH v3 24/29] KVM: PPC: Book3S PR: Support TAR handling for PR KVM HTM.

On Mon, May 21, 2018 at 12:09:41PM +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > Currently guest kernel doesn't handle TAR fac unavailable and it always > runs with TAR bit on. PR KVM will lazily enable TAR. TAR is not a > frequent-use reg and it is not

Re: [PATCH v3 5/7] KVM: PPC: reimplements LOAD_VSX/STORE_VSX instruction mmio emulation with analyse_intr() input

On Mon, May 21, 2018 at 01:24:24PM +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > This patch reimplements LOAD_VSX/STORE_VSX instruction MMIO emulation with > analyse_intr() input. It utilizes VSX_FPCONV/VSX_SPLAT/SIGNEXT exported > by analyse_instr() and

[PATCH v2 4/4] powerpc/perf: Unregister thread-imc if core-imc not supported

Since thread-imc internally use the core-imc hardware infrastructure and is depended on it, having thread-imc in the kernel in the absence of core-imc is trivial. Patch disables thread-imc, if core-imc is not registered. Signed-off-by: Anju T Sudhakar Reviewed-by:

[PATCH v2 3/4] powerpc/perf: Return appropriate value for unknown domain

Return proper error code for unknown domain during IMC initialization. Signed-off-by: Anju T Sudhakar Reviewed-by: Madhavan Srinivasan --- arch/powerpc/perf/imc-pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 2/4] powerpc/perf: Replace the direct return with goto statement

Replace the direct return statement in imc_mem_init() with goto, to adhere to the kernel coding style. Signed-off-by: Anju T Sudhakar Reviewed-by: Madhavan Srinivasan --- arch/powerpc/perf/imc-pmu.c | 18 ++ 1 file

[PATCH v2 1/4] powerpc/perf: Rearrange memory freeing in imc init

When any of the IMC (In-Memory Collection counter) devices fail to initialize, imc_common_mem_free() frees set of memory. In doing so, pmu_ptr pointer is also freed. But pmu_ptr pointer is used in subsequent function (imc_common_cpuhp_mem_free()) which is wrong. Patch here reorders the code to

  1   2   >