Re: [PATCH v3 0/4] kmod: help make deterministic

On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez wrote: > On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote: >> This v3 nukes the proc sysctl interface in favor for just letting userspace >> just check kernel revision. Prior to whenever this is merged

Re: [PATCH v2] mm: Allow slab_nomerge to be set at build time

On 06/20/2017 04:29 PM, Kees Cook wrote: > On Tue, Jun 20, 2017 at 4:16 PM, Randy Dunlap wrote: >> On 06/20/2017 04:09 PM, Kees Cook wrote: >>> Some hardened environments want to build kernels with slab_nomerge >>> already set (so that they do not depend on remembering to

Re: [PATCH v2] mm: Allow slab_nomerge to be set at build time

On Tue, Jun 20, 2017 at 4:16 PM, Randy Dunlap wrote: > On 06/20/2017 04:09 PM, Kees Cook wrote: >> Some hardened environments want to build kernels with slab_nomerge >> already set (so that they do not depend on remembering to set the kernel >> command line option). This is

Re: [PATCH v2] mm: Allow slab_nomerge to be set at build time

On 06/20/2017 04:09 PM, Kees Cook wrote: > Some hardened environments want to build kernels with slab_nomerge > already set (so that they do not depend on remembering to set the kernel > command line option). This is desired to reduce the risk of kernel heap > overflows being able to overwrite

Re: [PATCH 05/20] arm64: rename COMPAT to AARCH32_EL0 in Kconfig

On Mon, Jun 19, 2017 at 04:58:16PM +0100, James Morse wrote: > Hi Yury, > > On 04/06/17 12:59, Yury Norov wrote: > > From: Andrew Pinski > > > > In this patchset ILP32 ABI support is added. Additionally to AARCH32, > > which is binary-compatible with ARM, ILP32 is (mostly)

[PATCH v2] mm: Allow slab_nomerge to be set at build time

Some hardened environments want to build kernels with slab_nomerge already set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches and changes the

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

On Tue, 20 Jun 2017 08:27:36 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 20, 2017 at 4:54 PM, Yury Norov wrote: >> On Tue, Jun 20, 2017 at 04:20:43PM +0200, Arnd Bergmann wrote: >>> On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov >>> wrote:

Re: [PATCH v3 0/4] kmod: help make deterministic

On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote: > This v3 nukes the proc sysctl interface in favor for just letting userspace > just check kernel revision. Prior to whenever this is merged userspace should > try to avoid hammering more than 50 kmod threads as they can fail and

Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit

Re: [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support

On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +config ARCH_HAS_MEM_ENCRYPT > + def_bool y > + depends on X86 That one is silly. The config switch is in the x86 KConfig file, so X86 is on. If you intended to move this to some generic place outside of x86/Kconfig then this should be

Re: [PATCH v7 19/36] x86/mm: Add support to access boot related data in the clear

On Fri, Jun 16, 2017 at 01:53:26PM -0500, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted because UEFI/BIOS does not run with SME active. In order to access > this data properly it needs to be mapped decrypted. > > Update early_memremap() to

Re: [PATCH] docs: add virtualenv to Documentation's build chain

On Tue, 20 Jun 2017 16:51:40 +0200 Markus Heiser wrote: > This add a virtualenv [1] with we can control the versions > of Documentation's (python) requirements. It also changes the > default behavior, if sphinx is not installed on the OS. > > If Sphinx is not

Re: [PATCH v3 0/3] perf: xgene: Add support for SoC PMU version 3

Hi Mark and All, Do you have any comments on this patch set? Thank you! Hoan On Tue, Jun 6, 2017 at 11:02 AM, Hoan Tran wrote: > This patch set adds support for SoC-wide (AKA uncore) Performance Monitoring > Unit version 3. > > It can support up to > - 2 IOB PMU instances > -

Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

On 6/20/2017 11:17 AM, Andy Lutomirski wrote: On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: The cr3 register entry can contain the SME encryption mask that indicates the PGD is encrypted. The encryption mask should not be used when creating a virtual address

Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption mask that indicates > the PGD is encrypted. The encryption mask should not be used when > creating a virtual address from the cr3 register, so remove the SME >

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On 6/20/2017 2:38 AM, Borislav Petkov wrote: On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote: Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, encrypt the kernel in place and update the

Re: [PATCH v7 14/36] x86/mm: Insure that boot memory areas are mapped properly

On Fri, Jun 16, 2017 at 01:52:32PM -0500, Tom Lendacky wrote: > The boot data and command line data are present in memory in a decrypted > state and are copied early in the boot process. The early page fault > support will map these areas as encrypted, so before attempting to copy > them, add

Re: [PATCH] changes.rst: explain the usage of virtual environment

[...] > Am 19.06.2017 um 17:13 schrieb Markus Heiser : > >>> Typically I have a PY_ENV target in my projects, building a virtualenv >>> in a folder named ./local. [...] >> Yeah, IMHO, it makes sense to have something like that at the main build, >> as an optional

[PATCH] docs: add virtualenv to Documentation's build chain

This add a virtualenv [1] with we can control the versions of Documentation's (python) requirements. It also changes the default behavior, if sphinx is not installed on the OS. If Sphinx is not available make builds a virtualenv under Documentation/local and installs the requirements from

Re: [PATCH 16/20] arm64: signal32: move ilp32 and aarch32 common code to separated file

On Mon, Jun 19, 2017 at 05:16:42PM +0100, James Morse wrote: > Hi Yury, > > On 04/06/17 13:00, Yury Norov wrote: > > Signed-off-by: Yury Norov > > Can I offer a body for the commit message: > ILP32 needs to mix 32bit struct siginfo and 64bit sigframe for its signal >

Re: [PATCH 0/5] irq: generic-chip: resource management improvements

On Tue, 20 Jun 2017, Bartosz Golaszewski wrote: > 2017-06-20 12:41 GMT+02:00 Marc Zyngier : > > There was a kbuild report from June 1st with worrying warnings on x86_64 > > (though I couldn't see how that was related to these patches). What's > > the status of that? > > > >

Re: [PATCH v3 1/3] rtmutex: update rt-mutex-design

On Tue, 20 Jun 2017 08:22:52 +0800 Alex Shi wrote: > On 05/25/2017 01:26 PM, Alex Shi wrote: > > > > Author: Steven Rostedt > > +Updated: Alex Shi - 5/20/2017 > > > > Reviewers: Ingo Molnar, Thomas Gleixner, Thomas

Re: [PATCH 01/29] pinctrl.txt: standardize document format

On Sat, Jun 17, 2017 at 5:03 PM, Mauro Carvalho Chehab wrote: > Linus Walleij escreveu: >> Should the file be renamed pinctrl.rst now? > > If you just rename it, Sphinx will complain because it doesn't > belong to any index.rst file. As this

Re: [PATCH 0/5] irq: generic-chip: resource management improvements

On 20/06/17 11:31, Bartosz Golaszewski wrote: > 2017-05-31 18:06 GMT+02:00 Bartosz Golaszewski : >> This series is a follow-up to [1]. >> >> Some users of irq_alloc_generic_chip() are modules which can be >> removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated >>

Re: [PATCH 0/5] irq: generic-chip: resource management improvements

2017-05-31 18:06 GMT+02:00 Bartosz Golaszewski : > This series is a follow-up to [1]. > > Some users of irq_alloc_generic_chip() are modules which can be > removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated > generic chip. > > Last time it was suggested to provide

Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

On Fri, Jun 16, 2017 at 01:51:55PM -0500, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption mask that indicates > the PGD is encrypted. The encryption mask should not be used when > creating a virtual address from the cr3 register, so remove the SME > encryption mask in

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote: > Add support to the early boot code to use Secure Memory Encryption (SME). > Since the kernel has been loaded into memory in a decrypted state, encrypt > the kernel in place and update the early pagetables with the memory > encryption

Re: [PATCH v7 03/36] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

On Fri, Jun 16, 2017 at 01:50:23PM -0500, Tom Lendacky wrote: > The ioremap() function is intended for mapping MMIO. For RAM, the > memremap() function should be used. Convert calls from ioremap() to > memremap() when re-mapping RAM. > > This will be used later by SME to control how the

Re: [PATCH v2 18/31] efi-stub.txt: standardize document format

On 17 June 2017 at 17:25, Mauro Carvalho Chehab wrote: > Each text file under Documentation follows a different > format. Some doesn't even have titles! > > Change its representation to follow the adopted standard, > using ReST markups for it to be parseable by Sphinx: >