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

[Kees Cook]

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 userspace should
>> try to avoid hammering more than 50 kmod threads as they can fail and it'd
>> get -ENOMEM.
>>
>> We do away with the old heuristics on assuming you could end up with
>> less than max_threads/2 < 50 threads as Dmitry notes this would mean having
>> a system with 16 MiB of RAM with modules enabled. It simplifies our patch
>> "kmod: reduce atomic operations on kmod_concurrent" considerbly.
>>
>> Since the sysctl interface is gone, this no longer depends on any
>> other patches, the series is independent. As usual the series is
>> available on my linux-next 20170526-kmod-only branch which is based
>> on next-20170526.
>>
>> [0] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170526-kmod-only
>>
>>   Luis
>>
>> Luis R. Rodriguez (4):
>>   module: use list_for_each_entry_rcu() on find_module_all()
>>   kmod: reduce atomic operations on kmod_concurrent and simplify
>>   kmod: add test driver to stress test the module loader
>>   kmod: throttle kmod thread limit
>
> About a month now with no further nitpicks. What tree should these changes
> go through if there are no issues? Andrew's, Jessica's ?

Seems like going through Jessica's would make the most sense?

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Randy Dunlap]

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 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 requirements for cache layout control, increasing the difficulty of
>>> these attacks. By keeping caches unmerged, these kinds of exploits can
>>> usually only damage objects in the same cache (though the risk to metadata
>>> exploitation is unchanged).
>>>
>>> Cc: Daniel Micay 
>>> Cc: David Windsor 
>>> Cc: Eric Biggers 
>>> Signed-off-by: Kees Cook 
>>> ---
>>> v2: split out of slab whitelisting series
>>> ---
>>>  Documentation/admin-guide/kernel-parameters.txt | 10 --
>>>  init/Kconfig| 14 ++
>>>  mm/slab_common.c|  5 ++---
>>>  3 files changed, 24 insertions(+), 5 deletions(-)
>>
>>> diff --git a/init/Kconfig b/init/Kconfig
>>> index 1d3475fc9496..ce813acf2f4f 100644
>>> --- a/init/Kconfig
>>> +++ b/init/Kconfig
>>> @@ -1891,6 +1891,20 @@ config SLOB
>>>
>>>  endchoice
>>>
>>> +config SLAB_MERGE_DEFAULT
>>> + bool "Allow slab caches to be merged"
>>> + default y
>>> + help
>>> +   For reduced kernel memory fragmentation, slab caches can be
>>> +   merged when they share the same size and other characteristics.
>>> +   This carries a risk of kernel heap overflows being able to
>>> +   overwrite objects from merged caches (and more easily control
>>> +   cache layout), which makes such heap attacks easier to exploit
>>> +   by attackers. By keeping caches unmerged, these kinds of exploits
>>> +   can usually only damage objects in the same cache. To disable
>>> +   merging at runtime, "slab_nomerge" can be passed on the kernel
>>> +   command line.
>>
>>   command line or this option can be disabled in the kernel config.
> 
> Isn't that implicit in that it is Kconfig help text? Happy to add it,
> but seems redundant to me.
> 

Just trying for completeness instead of being implicit.

> 
>>
>>> +
>>>  config SLAB_FREELIST_RANDOM
>>>   default n
>>>   depends on SLAB || SLUB
>>
>> --
>> ~Randy
> 
> 
> 


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kees Cook]

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 desired to reduce the risk of kernel heap
>> overflows being able to overwrite objects from merged caches and changes
>> the requirements for cache layout control, increasing the difficulty of
>> these attacks. By keeping caches unmerged, these kinds of exploits can
>> usually only damage objects in the same cache (though the risk to metadata
>> exploitation is unchanged).
>>
>> Cc: Daniel Micay 
>> Cc: David Windsor 
>> Cc: Eric Biggers 
>> Signed-off-by: Kees Cook 
>> ---
>> v2: split out of slab whitelisting series
>> ---
>>  Documentation/admin-guide/kernel-parameters.txt | 10 --
>>  init/Kconfig| 14 ++
>>  mm/slab_common.c|  5 ++---
>>  3 files changed, 24 insertions(+), 5 deletions(-)
>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index 1d3475fc9496..ce813acf2f4f 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -1891,6 +1891,20 @@ config SLOB
>>
>>  endchoice
>>
>> +config SLAB_MERGE_DEFAULT
>> + bool "Allow slab caches to be merged"
>> + default y
>> + help
>> +   For reduced kernel memory fragmentation, slab caches can be
>> +   merged when they share the same size and other characteristics.
>> +   This carries a risk of kernel heap overflows being able to
>> +   overwrite objects from merged caches (and more easily control
>> +   cache layout), which makes such heap attacks easier to exploit
>> +   by attackers. By keeping caches unmerged, these kinds of exploits
>> +   can usually only damage objects in the same cache. To disable
>> +   merging at runtime, "slab_nomerge" can be passed on the kernel
>> +   command line.
>
>   command line or this option can be disabled in the kernel config.

Isn't that implicit in that it is Kconfig help text? Happy to add it,
but seems redundant to me.

-Kees

>
>> +
>>  config SLAB_FREELIST_RANDOM
>>   default n
>>   depends on SLAB || SLUB
>
> --
> ~Randy



-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Randy Dunlap]

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 objects from merged caches and changes
> the requirements for cache layout control, increasing the difficulty of
> these attacks. By keeping caches unmerged, these kinds of exploits can
> usually only damage objects in the same cache (though the risk to metadata
> exploitation is unchanged).
> 
> Cc: Daniel Micay 
> Cc: David Windsor 
> Cc: Eric Biggers 
> Signed-off-by: Kees Cook 
> ---
> v2: split out of slab whitelisting series
> ---
>  Documentation/admin-guide/kernel-parameters.txt | 10 --
>  init/Kconfig| 14 ++
>  mm/slab_common.c|  5 ++---
>  3 files changed, 24 insertions(+), 5 deletions(-)

> diff --git a/init/Kconfig b/init/Kconfig
> index 1d3475fc9496..ce813acf2f4f 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1891,6 +1891,20 @@ config SLOB
>  
>  endchoice
>  
> +config SLAB_MERGE_DEFAULT
> + bool "Allow slab caches to be merged"
> + default y
> + help
> +   For reduced kernel memory fragmentation, slab caches can be
> +   merged when they share the same size and other characteristics.
> +   This carries a risk of kernel heap overflows being able to
> +   overwrite objects from merged caches (and more easily control
> +   cache layout), which makes such heap attacks easier to exploit
> +   by attackers. By keeping caches unmerged, these kinds of exploits
> +   can usually only damage objects in the same cache. To disable
> +   merging at runtime, "slab_nomerge" can be passed on the kernel
> +   command line.

  command line or this option can be disabled in the kernel config.

> +
>  config SLAB_FREELIST_RANDOM
>   default n
>   depends on SLAB || SLUB

-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Yury Norov]

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) ABI-compatible.
> > 
> > From now, AARCH32_EL0 (former COMPAT) config option means the support of
> > AARCH32 userspace, ARM64_ILP32 - support of ILP32 ABI (see next patches),
> > and COMPAT indicates that one of them, or both, is enabled.
> > 
> > Where needed, CONFIG_COMPAT is changed over to use CONFIG_AARCH32_EL0 
> > instead
> 
> Nit: You have 'COMPAT' around compat_hwcap_str's definition, but its only user
> is wrapped in 'AARCH32_EL0'.
> 
> 
> After this patch
> arch/arm64/kernel/perf_callchain.c::perf_callchain_user() still has:
> > if (!compat_user_mode(regs)) {
> > /* AARCH64 mode */
> ...
> > } else {
> > #ifdef CONFIG_COMPAT
> > /* AARCH32 compat mode */
> ...
> > #endif
> > }
> 
> I think this one should become CONFIG_AARCH32_EL0. compat to this code means 
> the
> fp is 'compat_fp' in x11, and it should read a 32bit call chain from 
> user-space.
 
Thanks, will fix it. 

> This is confusing as 'is_compat_task()' matches one of aarch32 or ilp32, but
> compat_user_mode(regs) only matches aarch32 as it checks the saved spsr. I 
> can't
> see any problem caused by this today, but its going to bite someone in the
> future. Can this be renamed aarch32_user_mode()? (turns out 'a32' is the name 
> of
> just one of aarch32's instruction sets[0].)

compat_thumb_mode may be also renamed, and compat_setup_frame and
compat_setup_rt_frame, and some others. If you think that it may
confuse, I'll do rename.

Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kees Cook]

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 requirements for cache layout control, increasing the difficulty of
these attacks. By keeping caches unmerged, these kinds of exploits can
usually only damage objects in the same cache (though the risk to metadata
exploitation is unchanged).

Cc: Daniel Micay 
Cc: David Windsor 
Cc: Eric Biggers 
Signed-off-by: Kees Cook 
---
v2: split out of slab whitelisting series
---
 Documentation/admin-guide/kernel-parameters.txt | 10 --
 init/Kconfig| 14 ++
 mm/slab_common.c|  5 ++---
 3 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 7737ab5d04b2..94d8b8195cb8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3715,8 +3715,14 @@
slab_nomerge[MM]
Disable merging of slabs with similar size. May be
necessary if there is some reason to distinguish
-   allocs to different slabs. Debug options disable
-   merging on their own.
+   allocs to different slabs, especially in hardened
+   environments where the risk of heap overflows and
+   layout control by attackers can usually be
+   frustrated by disabling merging. This will reduce
+   most of the exposure of a heap attack to a single
+   cache (risks via metadata attacks are mostly
+   unchanged). Debug options disable merging on their
+   own.
For more information see Documentation/vm/slub.txt.
 
slab_max_order= [MM, SLAB]
diff --git a/init/Kconfig b/init/Kconfig
index 1d3475fc9496..ce813acf2f4f 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1891,6 +1891,20 @@ config SLOB
 
 endchoice
 
+config SLAB_MERGE_DEFAULT
+   bool "Allow slab caches to be merged"
+   default y
+   help
+ For reduced kernel memory fragmentation, slab caches can be
+ merged when they share the same size and other characteristics.
+ This carries a risk of kernel heap overflows being able to
+ overwrite objects from merged caches (and more easily control
+ cache layout), which makes such heap attacks easier to exploit
+ by attackers. By keeping caches unmerged, these kinds of exploits
+ can usually only damage objects in the same cache. To disable
+ merging at runtime, "slab_nomerge" can be passed on the kernel
+ command line.
+
 config SLAB_FREELIST_RANDOM
default n
depends on SLAB || SLUB
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 01a0fe2eb332..904a83be82de 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -47,13 +47,12 @@ static DECLARE_WORK(slab_caches_to_rcu_destroy_work,
 
 /*
  * Merge control. If this is set then no merging of slab caches will occur.
- * (Could be removed. This was introduced to pacify the merge skeptics.)
  */
-static int slab_nomerge;
+static bool slab_nomerge = !IS_ENABLED(CONFIG_SLAB_MERGE_DEFAULT);
 
 static int __init setup_slab_nomerge(char *str)
 {
-   slab_nomerge = 1;
+   slab_nomerge = true;
return 1;
 }
 
-- 
2.7.4


-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Palmer Dabbelt]

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:
>>> > On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
>>> >> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:
>
>>> > I would also notice riscv people and welcome to the discussion.
>>> >
>>> > As there is more than 1 arch that goes to be added to linux soon,
>>> > maybe it's better to upstream my ans James' patches separately
>>> > from other ilp32 patches? Arnd?
>>>
>>> Do you mean upstream those two patches slightly later? That's
>>> fine with me, I don't care much whether the old new stat is part
>>> of the syscall table for arm64-ilp32 or not, I'd leave that up to
>>> you, depending on whether you want to do the rework or not.
>>
>> I mean that if we want to deprecate rlimit and stat syscalls for
>> architectures that are under development now, it's better to upstream
>> patches that actually deprecate it as early as possible.
>
> Makes sense.
>
>>> I suppose the arm64-ilp32 could benefit from not having to support
>>> the old arm32 stat structure, but doing the new syscalls based on
>>> statx could delay the glibc port some more, as there are some open
>>> questions about how that would best be integrated.
>>
>> OK. Let's leave things as is. But then I don't see any reason to
>> add unxstat patch to ilp32 series if ilp32 will not disable it.
>
> Right, that's what I meant: let's leave the rlimit patch in your series
> as it matches the work you have already done, and is the right
> thing to do, and let's do the unxstat patch separately so it doesn't
> cause you extra work.

Thanks for the heads up.  We're in the process of submitting glibc now with the
goal of getting into 2.26, so I think that means we'll be stuck with stat.  I'm
perfectly happy to deprecate whatever is feasible, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Luis R. Rodriguez]

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 it'd
> get -ENOMEM.
> 
> We do away with the old heuristics on assuming you could end up with
> less than max_threads/2 < 50 threads as Dmitry notes this would mean having
> a system with 16 MiB of RAM with modules enabled. It simplifies our patch
> "kmod: reduce atomic operations on kmod_concurrent" considerbly.
> 
> Since the sysctl interface is gone, this no longer depends on any
> other patches, the series is independent. As usual the series is
> available on my linux-next 20170526-kmod-only branch which is based
> on next-20170526.
> 
> [0] 
> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170526-kmod-only
> 
>   Luis
> 
> Luis R. Rodriguez (4):
>   module: use list_for_each_entry_rcu() on find_module_all()
>   kmod: reduce atomic operations on kmod_concurrent and simplify
>   kmod: add test driver to stress test the module loader
>   kmod: throttle kmod thread limit

About a month now with no further nitpicks. What tree should these changes
go through if there are no issues? Andrew's, Jessica's ?

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Thomas Gleixner]

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 set when it is expected that
> an ioremap() should not have the encryption bit set. So only use the
> phys_to_virt() function if SME is not active

This does not make sense to me. What the heck has phys_to_virt() to do with
the encryption bit. Especially why would the encryption bit be set on that
mapping in the first place?

I'm probably missing something, but this want's some coherent explanation
understandable by mere mortals both in the changelog and the code comment.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Thomas Gleixner]

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

config ARCH_HAS_MEM_ENCRYPT
bool

and x86/Kconfig should have

select ARCH_HAS_MEM_ENCRYPT

and that should be selected by AMD_MEM_ENCRYPT

> +config AMD_MEM_ENCRYPT
> + bool "AMD Secure Memory Encryption (SME) support"
> + depends on X86_64 && CPU_SUP_AMD
> + ---help---
> +   Say yes to enable support for the encryption of system memory.
> +   This requires an AMD processor that supports Secure Memory
> +   Encryption (SME).

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Borislav Petkov]

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 provide an arch specific routine to modify the
> pagetable protection attributes before they are applied to the new
> mapping. This is used to remove the encryption mask for boot related data.
> 
> Update memremap() to provide an arch specific routine to determine if RAM
> remapping is allowed.  RAM remapping will cause an encrypted mapping to be
> generated. By preventing RAM remapping, ioremap_cache() will be used
> instead, which will provide a decrypted mapping of the boot related data.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/io.h |5 +
>  arch/x86/mm/ioremap.c |  179 
> +
>  include/linux/io.h|2 +
>  kernel/memremap.c |   20 -
>  mm/early_ioremap.c|   18 -
>  5 files changed, 217 insertions(+), 7 deletions(-)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jonathan Corbet]

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 available make builds a virtualenv under
> Documentation/local and installs the requirements from
> Documentation/sphinx/requirements.txt with pip [2].

I appreciate the work done on this, but I still do not think that going
off and installing external software in response to a kernel make command
is appropriate.  Any software installation must require, at a minimum, an
explicit request from the user first.

It would be nice to have, say, a script that can ensure that a target
system is capable of building the docs.  That would preferably include,
as an option, all the awful LaTeX stuff needed for a PDF build.
Preferably it would provide the option of using the system's package
manager or building a venv - but the latter only works for the sphinx
part, of course, and not LaTeX.

I totally agree with taking the pain out of setting up a build
environment, but automatically going off to pull down software off the
net and running it on some developer's build machine is not going to fly.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hoan Tran]

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
>  - 8 L3C PMU instances
>  - 2 MCB PMU instances
>  - 8 MCU PMU instances
> and these PMUs support 64 bit counter
>
> v3:
>  * Seperate acpi_pmu_probe_active_mcb_mcu_l3c for v3
>  * Consistent PMU event name
>  * Update comment
>  * Correct active MCU detection
>
> v2:
>  * Split into separate patches
>  * Use the function pointers for the PMU leaf functions
>  * Parse PMU subnode by the match table
>  * Dont allow user change agent id by config1 for SoC PMU v3
>
> Hoan Tran (3):
>   perf: xgene: Parse PMU subnode from the match table
>   perf: xgene: Move PMU leaf functions into function pointer structure
>   perf: xgene: Add support for SoC PMU version 3
>
>  drivers/perf/xgene_pmu.c | 677 
> +++
>  1 file changed, 622 insertions(+), 55 deletions(-)
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tom Lendacky]

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 from the cr3 register, so remove the SME
encryption mask in the read_cr3_pa() function.

During early boot SME will need to use a native version of read_cr3_pa(),
so create native_read_cr3_pa().

Signed-off-by: Tom Lendacky 
---
  arch/x86/include/asm/processor-flags.h |3 ++-
  arch/x86/include/asm/processor.h   |5 +
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/processor-flags.h 
b/arch/x86/include/asm/processor-flags.h
index 79aa2f9..cb6999c 100644
--- a/arch/x86/include/asm/processor-flags.h
+++ b/arch/x86/include/asm/processor-flags.h
@@ -2,6 +2,7 @@
  #define _ASM_X86_PROCESSOR_FLAGS_H

  #include 
+#include 

  #ifdef CONFIG_VM86
  #define X86_VM_MASKX86_EFLAGS_VM
@@ -33,7 +34,7 @@
   */
  #ifdef CONFIG_X86_64
  /* Mask off the address space ID bits. */
-#define CR3_ADDR_MASK 0x7000ull
+#define CR3_ADDR_MASK __sme_clr(0x7000ull)


Can you update the comment one line above, too?


Yup, will do.

Thanks,
Tom




--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Andy Lutomirski]

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
> encryption mask in the read_cr3_pa() function.
>
> During early boot SME will need to use a native version of read_cr3_pa(),
> so create native_read_cr3_pa().
>
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/processor-flags.h |3 ++-
>  arch/x86/include/asm/processor.h   |5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/processor-flags.h 
> b/arch/x86/include/asm/processor-flags.h
> index 79aa2f9..cb6999c 100644
> --- a/arch/x86/include/asm/processor-flags.h
> +++ b/arch/x86/include/asm/processor-flags.h
> @@ -2,6 +2,7 @@
>  #define _ASM_X86_PROCESSOR_FLAGS_H
>
>  #include 
> +#include 
>
>  #ifdef CONFIG_VM86
>  #define X86_VM_MASKX86_EFLAGS_VM
> @@ -33,7 +34,7 @@
>   */
>  #ifdef CONFIG_X86_64
>  /* Mask off the address space ID bits. */
> -#define CR3_ADDR_MASK 0x7000ull
> +#define CR3_ADDR_MASK __sme_clr(0x7000ull)

Can you update the comment one line above, too?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tom Lendacky]

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 early pagetables with the memory
encryption mask so that new pagetable entries will use memory encryption.

The routines to set the encryption mask and perform the encryption are
stub routines for now with functionality to be added in a later patch.

Because of the need to have the routines available to head_64.S, the
mem_encrypt.c is always built and #ifdefs in mem_encrypt.c will provide
functionality or stub routines depending on CONFIG_AMD_MEM_ENCRYPT.

Signed-off-by: Tom Lendacky 
---
  arch/x86/include/asm/mem_encrypt.h |8 +++
  arch/x86/kernel/head64.c   |   33 +-
  arch/x86/kernel/head_64.S  |   39 ++--
  arch/x86/mm/Makefile   |4 +---
  arch/x86/mm/mem_encrypt.c  |   24 ++
  5 files changed, 93 insertions(+), 15 deletions(-)


...


diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index b99d469..9a78277 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -11,6 +11,9 @@
   */
  
  #include 

+#include 
+
+#ifdef CONFIG_AMD_MEM_ENCRYPT
  
  /*

   * Since SME related variables are set early in the boot process they must
@@ -19,3 +22,24 @@
   */
  unsigned long sme_me_mask __section(.data) = 0;
  EXPORT_SYMBOL_GPL(sme_me_mask);
+
+void __init sme_encrypt_kernel(void)
+{
+}


Just the minor:

void __init sme_encrypt_kernel(void) { }

in case you have to respin.


I have to re-spin for the kbuild test error.  But given that this
function will be filled in later it's probably not worth doing the
space savings here.

Thanks,
Tom



Reviewed-by: Borislav Petkov 


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Borislav Petkov]

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 decrypted mappings so the data is accessed properly when copied.
> 
> For the initrd, encrypt this data in place. Since the future mapping of
> the initrd area will be mapped as encrypted the data will be accessed
> properly.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/mem_encrypt.h |6 +++
>  arch/x86/include/asm/pgtable.h |3 ++
>  arch/x86/kernel/head64.c   |   30 +--
>  arch/x86/kernel/setup.c|9 +
>  arch/x86/mm/kasan_init_64.c|2 +
>  arch/x86/mm/mem_encrypt.c  |   70 
> 
>  6 files changed, 115 insertions(+), 5 deletions(-)

...

> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index b7671b9..ea5e3a6 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -19,6 +19,8 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /*
>   * Since SME related variables are set early in the boot process they must
> @@ -101,6 +103,74 @@ void __init sme_early_decrypt(resource_size_t paddr, 
> unsigned long size)
>   __sme_early_enc_dec(paddr, size, false);
>  }
>  
> +static void __init __sme_early_map_unmap_mem(void *vaddr, unsigned long size,
> +  bool map)
> +{
> + unsigned long paddr = (unsigned long)vaddr - __PAGE_OFFSET;
> + pmdval_t pmd_flags, pmd;
> +
> + /* Use early_pmd_flags but remove the encryption mask */
> + pmd_flags = __sme_clr(early_pmd_flags);
> +
> + do {
> + pmd = map ? (paddr & PMD_MASK) + pmd_flags : 0;
> + __early_make_pgtable((unsigned long)vaddr, pmd);
> +
> + vaddr += PMD_SIZE;
> + paddr += PMD_SIZE;
> + size = (size <= PMD_SIZE) ? 0 : size - PMD_SIZE;
> + } while (size);
> +
> + write_cr3(__read_cr3());

local_flush_tlb() or __native_flush_tlb(). Probably the native variant
since this is early fun.

> +}
> +
> +static void __init __sme_map_unmap_bootdata(char *real_mode_data, bool map)
> +{
> + struct boot_params *boot_data;
> + unsigned long cmdline_paddr;
> +
> + /* If SME is not active, the bootdata is in the correct state */
> + if (!sme_active())
> + return;
> +
> + if (!map) {
> + /*
> +  * If unmapping, get the command line address before
> +  * unmapping the real_mode_data.
> +  */
> + boot_data = (struct boot_params *)real_mode_data;
> + cmdline_paddr = boot_data->hdr.cmd_line_ptr |
> + ((u64)boot_data->ext_cmd_line_ptr << 32);

Let it stick out:

cmdline_paddr = bd->hdr.cmd_line_ptr | ((u64)bd->ext_cmd_line_ptr << 
32);

> + }
> +
> + __sme_early_map_unmap_mem(real_mode_data, sizeof(boot_params), map);
> +
> + if (map) {
> + /*
> +  * If mapping, get the command line address after mapping
> +  * the real_mode_data.
> +  */
> + boot_data = (struct boot_params *)real_mode_data;
> + cmdline_paddr = boot_data->hdr.cmd_line_ptr |
> + ((u64)boot_data->ext_cmd_line_ptr << 32);
> + }
> +
> + if (!cmdline_paddr)
> + return;
> +
> + __sme_early_map_unmap_mem(__va(cmdline_paddr), COMMAND_LINE_SIZE, map);

Ok, so from looking at this function now - it does different things
depending on whether we map or not. So it doesn't look like a worker
function anymore and you can move the stuff back to the original callers
below. Should make the whole flow more readable.

> +}
> +
> +void __init sme_unmap_bootdata(char *real_mode_data)
> +{
> + __sme_map_unmap_bootdata(real_mode_data, false);
> +}
> +
> +void __init sme_map_bootdata(char *real_mode_data)
> +{
> + __sme_map_unmap_bootdata(real_mode_data, true);
> +}
> +
>  void __init sme_early_init(void)
>  {
>   unsigned int i;
> 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Markus Heiser]

[...]

> 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 feature,

> OK, I will prepare a RFC patch ...

For those who are interested in / lets discuss further in context
of my patch:

  https://www.mail-archive.com/linux-doc@vger.kernel.org/msg12844.html

Thanks!

-- Markus --
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Markus Heiser]

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
Documentation/sphinx/requirements.txt with pip [2].

Using virtualenv helps also to provide well tested environments. ATM the
requirements.txt defines::

  # last patch level from Sphinx-doc v1.5
  Sphinx>=1.5,<1.6

  # latest version of the RTD theme: http://docs.readthedocs.io
  sphinx_rtd_theme

To enforce a virtualenv set option VENV explicitly. E.g. on build
hosts you might want to choose a the python version explicitly and a
individually requirements-file [3] where you can stick the versions of
the installed python-packages::

  make VENV=myenv PY_REQUIRE=myenv.txt PY=3 ...

[1] https://virtualenv.pypa.io
[2] https://pip.pypa.io
[3] 
https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format

Signed-off-by: Markus Heiser 
---
 Documentation/.gitignore  |   1 +
 Documentation/Makefile|  76 --
 Documentation/Makefile.python | 116 ++
 Documentation/conf.py |   2 +-
 Documentation/doc-guide/sphinx.rst|  25 ++--
 Documentation/sphinx/requirements.txt |   9 +++
 6 files changed, 190 insertions(+), 39 deletions(-)
 create mode 100644 Documentation/Makefile.python
 create mode 100644 Documentation/sphinx/requirements.txt

diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index e74fec8..7a7c8f4 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1,2 +1,3 @@
 output
+local
 *.pyc
diff --git a/Documentation/Makefile b/Documentation/Makefile
index a423203..27c1d5a 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -14,20 +14,40 @@ PAPER =
 BUILDDIR  = $(obj)/output
 PDFLATEX  = xelatex
 LATEXOPTS = -interaction=batchmode
+VENV_ROOT = ./Documentation/local
+PY_REQUIRE= ./Documentation/sphinx/requirements.txt
 
 # User-friendly check for sphinx-build
 HAVE_SPHINX := $(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; 
else echo 0; fi)
 
-ifeq ($(HAVE_SPHINX),0)
+# User-friendly check for pdflatex
+HAVE_PDFLATEX := $(shell if which $(PDFLATEX) >/dev/null 2>&1; then echo 1; 
else echo 0; fi)
 
-.DEFAULT:
-   $(warning The '$(SPHINXBUILD)' command was not found. Make sure you 
have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to 
point to the full path of the '$(SPHINXBUILD)' executable.)
-   @echo "  SKIPSphinx $@ target."
+# If sphinx-build is not available, set 'VENV' to build a local virtualenv
+ifeq ($(HAVE_SPHINX),0)
+  VENV ?= sphinx-env
+else
+  VENV ?=
+endif
 
-else # HAVE_SPHINX
+dochelp::
+   @echo  ' Linux kernel internal documentation in different formats from 
ReST:'
+   @echo  '  htmldocs- HTML'
+   @echo  '  latexdocs   - LaTeX'
+   @echo  '  pdfdocs - PDF'
+   @echo  '  epubdocs- EPUB'
+   @echo  '  xmldocs - XML'
+   @echo  '  linkcheckdocs   - check for broken external links (will 
connect to external hosts)'
+   @echo  '  cleandocs   - clean all generated files'
+   @echo
+   @echo  '  make SPHINXDIRS="s1 s2" [target] Generate only docs of folder 
s1, s2'
+   @echo  '  valid values for SPHINXDIRS are: $(_SPHINXDIRS)'
+   @echo
+   @echo  '  make SPHINX_CONF={conf-file} [target] use *additional* 
sphinx-build'
+   @echo  '  configuration. This is e.g. useful to build with nit-picking 
config.'
+   @echo
 
-# User-friendly check for pdflatex
-HAVE_PDFLATEX := $(shell if which $(PDFLATEX) >/dev/null 2>&1; then echo 1; 
else echo 0; fi)
+include Documentation/Makefile.python
 
 # Internal variables.
 PAPEROPT_a4 = -D latex_paper_size=a4
@@ -62,13 +82,23 @@ quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath 
$(BUILDDIR)/$3/$4)
$(abspath $(srctree)/$(src)/$5) \
$(abspath $(BUILDDIR)/$3/$4)
 
-htmldocs:
+# rules to build sphinx-exe target
+ifneq ($(strip $(VENV)),)
+SPHINXBUILD = $(PY_ENV_BIN)/sphinx-build
+sphinx-exe: $(PY_ENV)
+   @:
+else  # VENV
+sphinx-exe:
+   @:
+endif # VENV
+
+htmldocs: sphinx-exe
@+$(foreach var,$(SPHINXDIRS),$(call 
loop_cmd,sphinx,html,$(var),,$(var)))
 
-linkcheckdocs:
+linkcheckdocs: sphinx-exe
@$(foreach var,$(SPHINXDIRS),$(call 
loop_cmd,sphinx,linkcheck,$(var),,$(var)))
 
-latexdocs:
+latexdocs: sphinx-exe
@+$(foreach var,$(SPHINXDIRS),$(call 
loop_cmd,sphinx,latex,$(var),latex,$(var)))
 
 ifeq ($(HAVE_PDFLATEX),0)
@@ -84,17 +114,12 @@ pdfdocs: latexdocs
 
 endif # HAVE_PDFLATEX
 
-epubdocs:
+epubdocs: sphinx-exe
@+$(foreach var,$(SPHINXDIRS),$(call 
loop_cmd,sphinx,epub,$(var),epub,$(var)))
 
-xmldocs:
+xmldocs: sphinx-exe
@+$(foreach 

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

[Yury Norov]

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
> handlers. Move the existing compat code for copying siginfo to user space and
> manipulating signal masks into signal32_common.c so it can be used to deliver
> aarch32 and ilp32 signals.

Ok

> > diff --git a/arch/arm64/include/asm/signal32.h 
> > b/arch/arm64/include/asm/signal32.h
> > index e68fcce538e1..1c4ede717bd2 100644
> > --- a/arch/arm64/include/asm/signal32.h
> > +++ b/arch/arm64/include/asm/signal32.h
> > @@ -13,6 +13,9 @@
> >   * You should have received a copy of the GNU General Public License
> >   * along with this program.  If not, see .
> >   */
> > +
> > +#include 
> > +
> >  #ifndef __ASM_SIGNAL32_H
> >  #define __ASM_SIGNAL32_H
> 
> Nit: This should go inside the guard.
 
Ok, thanks. Will fix this and all below
 
> > diff --git a/arch/arm64/kernel/signal32_common.c 
> > b/arch/arm64/kernel/signal32_common.c
> > new file mode 100644
> > index ..5bddc25dca12
> > --- /dev/null
> > +++ b/arch/arm64/kernel/signal32_common.c
> > @@ -0,0 +1,135 @@
> [...]
> > +#include 
> > +#include 
> > +#include 
> 
> What do you need ratelimit.h for?
> 
> 
> > +#include 
> > +
> > +#include 
> 
> I can't see anything using these ESR_ macros in here...
> 
> 
> > +#include 
> 
> This was for the VFP save/restore code, which you didn't move...
> 
> 
> > +#include 
> > +#include 
> 
> [...]
> 
> 
> > +int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t 
> > *from)
> [...]
> > +   case __SI_FAULT:
> > +   err |= __put_user((compat_uptr_t)(unsigned long)from->si_addr,
> > + >si_addr);
> 
> This looks tricky. si_addr comes from FAR_EL1 when user-space touches 
> something
> it shouldn't. This could be a 64bit value as ilp32 processes can still branch 
> to
> 64bit addresses in registers and generate loads that cross the invisible 4GB
> boundary. Here you truncate the 64bit address.
> Obviously this can't happen at all with aarch32, and for C programs its into
> undefined-behaviour territory, but it doesn't feel right to pass an address to
> user-space that we know is wrong... but we don't have an alternative.
> 
> This looks like a class of problem particular to ilp32/x32: 'accessed an 
> address
> you can't encode with a signal'. After a quick dig in x86's x32 code, it looks
> like they only pass the first 32bits of si_addr too.
> 
> One option is to mint a new si_code to go with SIGBUS meaning something like
> 'address overflowed si_addr'. Alternatively we could just kill tasks that do 
> this.

New SIGBUS sounds reasonable at the first glance, but I think it should be
discussed widely at first, and the patch that implements it should touch
all arches that may be affected.

Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Thomas Gleixner]

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?
> >
> > Thanks,
> >
> > M.
> > --
> > Jazz is not dead. It just smells funny...
> 
> Snap, I looked at it, determined that it was just a header included in
> include/linux/irq.h (unrelated to the patch) and forgot to comment
> about it.
> 
> I've never seen this warning on my setup and don't see it now with rc6.

Yep, that's a genuine x86 snafu. No idea how that got attributed to your
patch.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Steven Rostedt]

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 Duetsch, and Randy Dunlap
> >  
> > @@ -779,3 +554,4 @@ Updates
> >  ---
> >  
> >  This document was originally written for 2.6.17-rc3-mm1
> > +was updated on 4.12-rc1  
> 
> Hi, Steven & Sebastian,
> 
> Is there any more concern or comments on this doc?
> 

Hi Alex,

Sorry, I just haven't had time yet to take a look. I'll see if I can
allocate some time for reviewing your patches this week.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Linus Walleij]

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 is part of drivers/, I guess
> the right thing is to add it to driver-api book.
>
> The enclosed patch should be doing it (it is based on linux-next).

Hey it just applies, so I tossed in this patch too, thanks a lot!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Marc Zyngier]

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
>> generic chip.
>>
>> Last time it was suggested to provide irq_destroy_generic_chip() which
>> would undo both irq_remove_generic_chip() and irq_alloc_generic_chip().
>>
>> This functionality is provided by patch 2/5 with 1/5 adding the option
>> to only free the allocated memory.
>>
>> Patch 3/5 exports a function that will be used in the devres variant
>> of irq_alloc_generic_chip().
>>
>> Patches 4/5 and 5/5 add resource managed versions of
>> irq_alloc_generic_chip() & irq_setup_generic_chip(). They will be used
>> in drivers where applicable. Device resources are released in reverse
>> order so it's ok to call devm_irq_alloc_generic_chip() and then
>> devm_irq_setup_generic_chip().
>>
>> [1] https://lkml.org/lkml/2017/3/8/550
>>
>> Bartosz Golaszewski (5):
>>   irq: generic-chip: provide irq_free_generic_chip()
>>   irq: generic-chip: provide irq_destroy_generic_chip()
>>   irq: generic-chip: export irq_init_generic_chip() locally
>>   irq: generic-chip: provide devm_irq_alloc_generic_chip()
>>   irq: generic-chip: provide devm_irq_setup_generic_chip()
>>
>>  Documentation/driver-model/devres.txt |  2 +
>>  include/linux/irq.h   | 22 +
>>  kernel/irq/devres.c   | 86 
>> +++
>>  kernel/irq/generic-chip.c |  7 ++-
>>  kernel/irq/internals.h| 11 +
>>  5 files changed, 124 insertions(+), 4 deletions(-)
>>
>> --
>> 2.9.3
>>
> 
> Ping for v4.13.
> 
> Is there any reason not to merge it?

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?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Bartosz Golaszewski]

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 irq_destroy_generic_chip() which
> would undo both irq_remove_generic_chip() and irq_alloc_generic_chip().
>
> This functionality is provided by patch 2/5 with 1/5 adding the option
> to only free the allocated memory.
>
> Patch 3/5 exports a function that will be used in the devres variant
> of irq_alloc_generic_chip().
>
> Patches 4/5 and 5/5 add resource managed versions of
> irq_alloc_generic_chip() & irq_setup_generic_chip(). They will be used
> in drivers where applicable. Device resources are released in reverse
> order so it's ok to call devm_irq_alloc_generic_chip() and then
> devm_irq_setup_generic_chip().
>
> [1] https://lkml.org/lkml/2017/3/8/550
>
> Bartosz Golaszewski (5):
>   irq: generic-chip: provide irq_free_generic_chip()
>   irq: generic-chip: provide irq_destroy_generic_chip()
>   irq: generic-chip: export irq_init_generic_chip() locally
>   irq: generic-chip: provide devm_irq_alloc_generic_chip()
>   irq: generic-chip: provide devm_irq_setup_generic_chip()
>
>  Documentation/driver-model/devres.txt |  2 +
>  include/linux/irq.h   | 22 +
>  kernel/irq/devres.c   | 86 
> +++
>  kernel/irq/generic-chip.c |  7 ++-
>  kernel/irq/internals.h| 11 +
>  5 files changed, 124 insertions(+), 4 deletions(-)
>
> --
> 2.9.3
>

Ping for v4.13.

Is there any reason not to merge it?

Thanks,
Bartosz
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Borislav Petkov]

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 the read_cr3_pa() function.
> 
> During early boot SME will need to use a native version of read_cr3_pa(),
> so create native_read_cr3_pa().
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/processor-flags.h |3 ++-
>  arch/x86/include/asm/processor.h   |5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Borislav Petkov]

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 mask so that new pagetable entries will use memory encryption.
> 
> The routines to set the encryption mask and perform the encryption are
> stub routines for now with functionality to be added in a later patch.
> 
> Because of the need to have the routines available to head_64.S, the
> mem_encrypt.c is always built and #ifdefs in mem_encrypt.c will provide
> functionality or stub routines depending on CONFIG_AMD_MEM_ENCRYPT.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/mem_encrypt.h |8 +++
>  arch/x86/kernel/head64.c   |   33 +-
>  arch/x86/kernel/head_64.S  |   39 
> ++--
>  arch/x86/mm/Makefile   |4 +---
>  arch/x86/mm/mem_encrypt.c  |   24 ++
>  5 files changed, 93 insertions(+), 15 deletions(-)

...

> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index b99d469..9a78277 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -11,6 +11,9 @@
>   */
>  
>  #include 
> +#include 
> +
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
>  
>  /*
>   * Since SME related variables are set early in the boot process they must
> @@ -19,3 +22,24 @@
>   */
>  unsigned long sme_me_mask __section(.data) = 0;
>  EXPORT_SYMBOL_GPL(sme_me_mask);
> +
> +void __init sme_encrypt_kernel(void)
> +{
> +}

Just the minor:

void __init sme_encrypt_kernel(void) { }

in case you have to respin.

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Borislav Petkov]

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 encryption mask is
> applied to memory mappings, with certain memory locations being mapped
> decrypted vs encrypted.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/dmi.h   |8 
>  arch/x86/kernel/acpi/boot.c  |6 +++---
>  arch/x86/kernel/kdebugfs.c   |   34 +++---
>  arch/x86/kernel/ksysfs.c |   28 ++--
>  arch/x86/kernel/mpparse.c|   10 +-
>  arch/x86/pci/common.c|4 ++--
>  drivers/firmware/dmi-sysfs.c |5 +++--
>  drivers/firmware/pcdp.c  |4 ++--
>  drivers/sfi/sfi_core.c   |   22 +++---
>  9 files changed, 55 insertions(+), 66 deletions(-)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ard Biesheuvel]

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:
>
> - use proper markups for titles;
> - identify literal blocks.
>
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Ard Biesheuvel 


> ---
>  Documentation/efi-stub.txt | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
> index e15746988261..41df801f9a50 100644
> --- a/Documentation/efi-stub.txt
> +++ b/Documentation/efi-stub.txt
> @@ -1,5 +1,6 @@
> - The EFI Boot Stub
> ----
> +=
> +The EFI Boot Stub
> +=
>
>  On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
>  as a PE/COFF image, thereby convincing EFI firmware loaders to load
> @@ -25,7 +26,8 @@ a certain sense it *IS* the boot loader.
>  The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
>
>
> - How to install bzImage.efi
> +How to install bzImage.efi
> +--
>
>  The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
>  System Partition (ESP) and renamed with the extension ".efi". Without
> @@ -37,14 +39,16 @@ may not need to be renamed. Similarly for arm64, 
> arch/arm64/boot/Image
>  should be copied but not necessarily renamed.
>
>
> - Passing kernel parameters from the EFI shell
> +Passing kernel parameters from the EFI shell
> +
>
> -Arguments to the kernel can be passed after bzImage.efi, e.g.
> +Arguments to the kernel can be passed after bzImage.efi, e.g.::
>
> fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
>
>
> - The "initrd=" option
> +The "initrd=" option
> +
>
>  Like most boot loaders, the EFI stub allows the user to specify
>  multiple initrd files using the "initrd=" option. This is the only EFI
> @@ -54,9 +58,9 @@ kernel when it boots.
>  The path to the initrd file must be an absolute path from the
>  beginning of the ESP, relative path names do not work. Also, the path
>  is an EFI-style path and directory elements must be separated with
> -backslashes (\). For example, given the following directory layout,
> +backslashes (\). For example, given the following directory layout::
>
> -fs0:>
> +  fs0:>
> Kernels\
> bzImage.efi
> initrd-large.img
> @@ -66,7 +70,7 @@ fs0:>
> initrd-medium.img
>
>  to boot with the initrd-large.img file if the current working
> -directory is fs0:\Kernels, the following command must be used,
> +directory is fs0:\Kernels, the following command must be used::
>
> fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
>
> @@ -76,7 +80,8 @@ which understands relative paths, whereas the rest of the 
> command line
>  is passed to bzImage.efi.
>
>
> - The "dtb=" option
> +The "dtb=" option
> +-
>
>  For the ARM and arm64 architectures, we also need to be able to provide a
>  device tree to the kernel. This is done with the "dtb=" command line option,
> --
> 2.9.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html