* Re: [PATCH 2/3] treewide: trivial: fix s/poped/popped/ typo
From: Masami Hiramatsu @ 2019-06-07 14:22 UTC (permalink / raw)
To: George G. Davis
Cc: Jonathan Corbet, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Jiri Kosina, Steven Rostedt, Andi Kleen, Jann Horn, Nadav Amit,
open list:DOCUMENTATION, open list
In-Reply-To: <1559766612-12178-2-git-send-email-george_davis@mentor.com>
On Wed, 5 Jun 2019 16:30:10 -0400
"George G. Davis" <george_davis@mentor.com> wrote:
> Fix a couple of s/poped/popped/ typos.
>
> Cc: Jiri Kosina <trivial@kernel.org>
> Signed-off-by: George G. Davis <george_davis@mentor.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
> ---
> Documentation/arm/mem_alignment | 2 +-
> arch/x86/kernel/kprobes/core.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/arm/mem_alignment b/Documentation/arm/mem_alignment
> index 6335fcacbba9..e110e2781039 100644
> --- a/Documentation/arm/mem_alignment
> +++ b/Documentation/arm/mem_alignment
> @@ -1,4 +1,4 @@
> -Too many problems poped up because of unnoticed misaligned memory access in
> +Too many problems popped up because of unnoticed misaligned memory access in
> kernel code lately. Therefore the alignment fixup is now unconditionally
> configured in for SA11x0 based targets. According to Alan Cox, this is a
> bad idea to configure it out, but Russell King has some good reasons for
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 6afd8061dbae..d3243d93daf4 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -813,7 +813,7 @@ __used __visible void *trampoline_handler(struct pt_regs *regs)
> continue;
> /*
> * Return probes must be pushed on this hash list correct
> - * order (same as return order) so that it can be poped
> + * order (same as return order) so that it can be popped
> * correctly. However, if we find it is pushed it incorrect
> * order, this means we find a function which should not be
> * probed, because the wrong order entry is pushed on the
> --
> 2.7.4
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Mimi Zohar @ 2019-06-07 14:24 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, stable,
linux-kernel, silviu.vlasceanu
In-Reply-To: <20190606112620.26488-3-roberto.sassu@huawei.com>
Hi Roberto,
Thank you for updating the patch description.
On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
> IMA and EVM have been designed as two independent subsystems: the first for
> checking the integrity of file data; the second for checking file metadata.
> Making them independent allows users to adopt them incrementally.
>
> The point of intersection is in IMA-Appraisal, which calls
> evm_verifyxattr() to ensure that security.ima wasn't modified during an
> offline attack. The design choice, to ensure incremental adoption, was to
> continue appraisal verification if evm_verifyxattr() returns
> INTEGRITY_UNKNOWN. This value is returned when EVM is not enabled in the
> kernel configuration, or if the HMAC key has not been loaded yet.
>
> Although this choice appears legitimate, it might not be suitable for
> hardened systems, where the administrator expects that access is denied if
> there is any error. An attacker could intentionally delete the EVM keys
> from the system and set the file digest in security.ima to the actual file
> digest so that the final appraisal status is INTEGRITY_PASS.
Assuming that the EVM HMAC key is stored in the initramfs, not on some
other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
would be limited to the rootfs filesystem.
>
> This patch allows such hardened systems to strictly enforce an access
> control policy based on the validity of signatures/HMACs, by introducing
> two new values for the ima_appraise= kernel option: enforce-evm and
> log-evm.
>
This patch defines a global policy requiring EVM on all filesystems.
I've previously suggested extending the IMA policy to support
enforcing or maybe exempting EVM on a per IMA policy rule basis. As
seen by the need for an additional patch, included in this patch set,
which defines a temporary random number HMAC key to address
INTEGRITY_UNKNOWN on the rootfs filesystem, exempting certain
filesystems on a per policy rule basis might be simpler and achieve
similar results.
I'd like to hear other people's thoughts on defining a temporary,
random number HMAC key.
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Roberto Sassu @ 2019-06-07 14:40 UTC (permalink / raw)
To: Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, stable,
linux-kernel, silviu.vlasceanu
In-Reply-To: <1559917462.4278.253.camel@linux.ibm.com>
On 6/7/2019 4:24 PM, Mimi Zohar wrote:
> Hi Roberto,
>
> Thank you for updating the patch description.
Hi Mimi
no problem.
> On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
>> IMA and EVM have been designed as two independent subsystems: the first for
>> checking the integrity of file data; the second for checking file metadata.
>> Making them independent allows users to adopt them incrementally.
>>
>> The point of intersection is in IMA-Appraisal, which calls
>> evm_verifyxattr() to ensure that security.ima wasn't modified during an
>> offline attack. The design choice, to ensure incremental adoption, was to
>> continue appraisal verification if evm_verifyxattr() returns
>> INTEGRITY_UNKNOWN. This value is returned when EVM is not enabled in the
>> kernel configuration, or if the HMAC key has not been loaded yet.
>>
>> Although this choice appears legitimate, it might not be suitable for
>> hardened systems, where the administrator expects that access is denied if
>> there is any error. An attacker could intentionally delete the EVM keys
>> from the system and set the file digest in security.ima to the actual file
>> digest so that the final appraisal status is INTEGRITY_PASS.
>
> Assuming that the EVM HMAC key is stored in the initramfs, not on some
> other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
> would be limited to the rootfs filesystem.
There is another issue. The HMAC key, like the public keys, should be
loaded when appraisal is disabled. This means that we have to create a
trusted key at early boot and defer the unsealing.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Mimi Zohar @ 2019-06-07 15:08 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, stable,
linux-kernel, silviu.vlasceanu
In-Reply-To: <93459fe8-f9b6-fe45-1ca7-2efb8854dc8b@huawei.com>
On Fri, 2019-06-07 at 16:40 +0200, Roberto Sassu wrote:
> > On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
> >> Although this choice appears legitimate, it might not be suitable for
> >> hardened systems, where the administrator expects that access is denied if
> >> there is any error. An attacker could intentionally delete the EVM keys
> >> from the system and set the file digest in security.ima to the actual file
> >> digest so that the final appraisal status is INTEGRITY_PASS.
> >
> > Assuming that the EVM HMAC key is stored in the initramfs, not on some
> > other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
> > would be limited to the rootfs filesystem.
>
> There is another issue. The HMAC key, like the public keys, should be
> loaded when appraisal is disabled. This means that we have to create a
> trusted key at early boot and defer the unsealing.
There is no need for IMA to appraise the public key file signature,
since the certificate is signed by a key on the builtin/secondary
trusted keyring. With CONFIG_IMA_LOAD_X509 enabled, the public key
can be loaded onto the IMA keyring with IMA-appraisal enabled, but
without verifying the file signature.
Mimi
^ permalink raw reply
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Roberto Sassu @ 2019-06-07 15:14 UTC (permalink / raw)
To: Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, stable,
linux-kernel, silviu.vlasceanu
In-Reply-To: <1559920112.4278.264.camel@linux.ibm.com>
On 6/7/2019 5:08 PM, Mimi Zohar wrote:
> On Fri, 2019-06-07 at 16:40 +0200, Roberto Sassu wrote:
>>> On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
>
>>>> Although this choice appears legitimate, it might not be suitable for
>>>> hardened systems, where the administrator expects that access is denied if
>>>> there is any error. An attacker could intentionally delete the EVM keys
>>>> from the system and set the file digest in security.ima to the actual file
>>>> digest so that the final appraisal status is INTEGRITY_PASS.
>>>
>>> Assuming that the EVM HMAC key is stored in the initramfs, not on some
>>> other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
>>> would be limited to the rootfs filesystem.
>>
>> There is another issue. The HMAC key, like the public keys, should be
>> loaded when appraisal is disabled. This means that we have to create a
>> trusted key at early boot and defer the unsealing.
>
> There is no need for IMA to appraise the public key file signature,
> since the certificate is signed by a key on the builtin/secondary
> trusted keyring. With CONFIG_IMA_LOAD_X509 enabled, the public key
> can be loaded onto the IMA keyring with IMA-appraisal enabled, but
> without verifying the file signature.
Yes, but access to the files containing the master key and the EVM key
is denied if appraisal is enabled.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* [PATCH 0/4] Documentation: x86: resctrl_ui.txt fixes and clarification
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
While updating resctrl_ui.rst for arm64 support these things stuck
out as being unclear or no longer true.
(I've shortened the CC list to just RDT+Documentation)
Thanks,
James Morse (4):
Documentation: x86: Contiguous cbm isn't all X86
Documentation: x86: Remove cdpl2 unspported statement and fix
capitalisation
Documentation: x86: Clarify MBA takes MB as referring to mba_sc
Documentation: x86: fix some typos
Documentation/x86/resctrl_ui.rst | 30 ++++++++++++++++++------------
1 file changed, 18 insertions(+), 12 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH 1/4] Documentation: x86: Contiguous cbm isn't all X86
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
In-Reply-To: <20190607151409.15476-1-james.morse@arm.com>
Since commit 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature")
resctrl has supported non-contiguous cache bit masks. The interface
for this is currently try-it-and-see.
Update the documentation to say Intel CPUs have this requirement,
instead of X86.
Cc: Babu Moger <Babu.Moger@amd.com>
Signed-off-by: James Morse <james.morse@arm.com>
---
Documentation/x86/resctrl_ui.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 225cfd4daaee..066f94e53418 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -342,7 +342,7 @@ For cache resources we describe the portion of the cache that is available
for allocation using a bitmask. The maximum value of the mask is defined
by each cpu model (and may be different for different cache levels). It
is found using CPUID, but is also provided in the "info" directory of
-the resctrl file system in "info/{resource}/cbm_mask". X86 hardware
+the resctrl file system in "info/{resource}/cbm_mask". Intel hardware
requires that these masks have all the '1' bits in a contiguous block. So
0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9
and 0xA are not. On a system with a 20-bit mask each bit represents 5%
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] Documentation: x86: Remove cdpl2 unspported statement and fix capitalisation
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
In-Reply-To: <20190607151409.15476-1-james.morse@arm.com>
"L2 cache does not support code and data prioritization". This isn't
true, elsewhere the document says it can be enabled with the cdpl2
mount option.
While we're here, these sample strings have lower-case code/data,
which isn't how the kernel exports them.
Signed-off-by: James Morse <james.morse@arm.com>
---
Documentation/x86/resctrl_ui.rst | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 066f94e53418..638cd987937d 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -418,16 +418,22 @@ L3 schemata file details (CDP enabled via mount option to resctrl)
When CDP is enabled L3 control is split into two separate resources
so you can specify independent masks for code and data like this::
- L3data:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
- L3code:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L3DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L3CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
L2 schemata file details
------------------------
-L2 cache does not support code and data prioritization, so the
-schemata format is always::
+CDP is supported at L2 using the 'cdpl2' mount option. The schemata
+format is either::
L2:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+or
+
+ L2DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L2CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+
Memory bandwidth Allocation (default mode)
------------------------------------------
--
2.20.1
^ permalink raw reply related
* [PATCH 3/4] Documentation: x86: Clarify MBA takes MB as referring to mba_sc
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
In-Reply-To: <20190607151409.15476-1-james.morse@arm.com>
"If the MBA is specified in MB then user can enter the max b/w in MB"
is a tautology. How can the user know if the schemata takes a percentage
or a MB/s value?
This is referring to whether the software controller is interpreting
the schemata's value. Make this clear.
Signed-off-by: James Morse <james.morse@arm.com>
---
Documentation/x86/resctrl_ui.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 638cd987937d..866b66aa289b 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -677,8 +677,8 @@ allocations can overlap or not. The allocations specifies the maximum
b/w that the group may be able to use and the system admin can configure
the b/w accordingly.
-If the MBA is specified in MB(megabytes) then user can enter the max b/w in MB
-rather than the percentage values.
+If resctrl is using the software controller (mba_sc) then user can enter the
+max b/w in MB rather than the percentage values.
::
# echo "L3:0=3;1=c\nMB:0=1024;1=500" > /sys/fs/resctrl/p0/schemata
--
2.20.1
^ permalink raw reply related
* [PATCH 4/4] Documentation: x86: fix some typos
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
In-Reply-To: <20190607151409.15476-1-james.morse@arm.com>
These are all obvious typos.
Signed-off-by: James Morse <james.morse@arm.com>
---
Documentation/x86/resctrl_ui.rst | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 866b66aa289b..5368cedfb530 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -40,7 +40,7 @@ mount options are:
Enable the MBA Software Controller(mba_sc) to specify MBA
bandwidth in MBps
-L2 and L3 CDP are controlled seperately.
+L2 and L3 CDP are controlled separately.
RDT features are orthogonal. A particular system may support only
monitoring, only control, or both monitoring and control. Cache
@@ -118,7 +118,7 @@ related to allocation:
Corresponding region is pseudo-locked. No
sharing allowed.
-Memory bandwitdh(MB) subdirectory contains the following files
+Memory bandwidth(MB) subdirectory contains the following files
with respect to allocation:
"min_bandwidth":
@@ -209,7 +209,7 @@ All groups contain the following files:
CPUs to/from this group. As with the tasks file a hierarchy is
maintained where MON groups may only include CPUs owned by the
parent CTRL_MON group.
- When the resouce group is in pseudo-locked mode this file will
+ When the resource group is in pseudo-locked mode this file will
only be readable, reflecting the CPUs associated with the
pseudo-locked region.
@@ -380,7 +380,7 @@ where L2 external is 10GBps (hence aggregate L2 external bandwidth is
240GBps) and L3 external bandwidth is 100GBps. Now a workload with '20
threads, having 50% bandwidth, each consuming 5GBps' consumes the max L3
bandwidth of 100GBps although the percentage value specified is only 50%
-<< 100%. Hence increasing the bandwidth percentage will not yeild any
+<< 100%. Hence increasing the bandwidth percentage will not yield any
more bandwidth. This is because although the L2 external bandwidth still
has capacity, the L3 external bandwidth is fully used. Also note that
this would be dependent on number of cores the benchmark is run on.
@@ -398,7 +398,7 @@ In order to mitigate this and make the interface more user friendly,
resctrl added support for specifying the bandwidth in MBps as well. The
kernel underneath would use a software feedback mechanism or a "Software
Controller(mba_sc)" which reads the actual bandwidth using MBM counters
-and adjust the memowy bandwidth percentages to ensure::
+and adjust the memory bandwidth percentages to ensure::
"actual bandwidth < user specified bandwidth".
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Mimi Zohar @ 2019-06-07 15:25 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu
In-Reply-To: <773c3301-7861-f28b-813a-1f2ff657bae8@huawei.com>
On Fri, 2019-06-07 at 17:14 +0200, Roberto Sassu wrote:
> On 6/7/2019 5:08 PM, Mimi Zohar wrote:
> > On Fri, 2019-06-07 at 16:40 +0200, Roberto Sassu wrote:
> >>> On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
> >
> >>>> Although this choice appears legitimate, it might not be suitable for
> >>>> hardened systems, where the administrator expects that access is denied if
> >>>> there is any error. An attacker could intentionally delete the EVM keys
> >>>> from the system and set the file digest in security.ima to the actual file
> >>>> digest so that the final appraisal status is INTEGRITY_PASS.
> >>>
> >>> Assuming that the EVM HMAC key is stored in the initramfs, not on some
> >>> other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
> >>> would be limited to the rootfs filesystem.
> >>
> >> There is another issue. The HMAC key, like the public keys, should be
> >> loaded when appraisal is disabled. This means that we have to create a
> >> trusted key at early boot and defer the unsealing.
> >
> > There is no need for IMA to appraise the public key file signature,
> > since the certificate is signed by a key on the builtin/secondary
> > trusted keyring. With CONFIG_IMA_LOAD_X509 enabled, the public key
> > can be loaded onto the IMA keyring with IMA-appraisal enabled, but
> > without verifying the file signature.
>
> Yes, but access to the files containing the master key and the EVM key
> is denied if appraisal is enabled.
This is a key loading ordering issue. Assuming you load the IMA key
first, you should be able to verify the master and EVM keys.
Mimi
^ permalink raw reply
* Re: [PATCH v7 05/27] x86/fpu/xstate: Add XSAVES system states for shadow stack
From: Yu-cheng Yu @ 2019-06-07 16:14 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607070725.GN3419@hirez.programming.kicks-ass.net>
On Fri, 2019-06-07 at 09:07 +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 01:06:24PM -0700, Yu-cheng Yu wrote:
> > Intel Control-flow Enforcement Technology (CET) introduces the
> > following MSRs.
> >
> > MSR_IA32_U_CET (user-mode CET settings),
> > MSR_IA32_PL3_SSP (user-mode shadow stack),
> > MSR_IA32_PL0_SSP (kernel-mode shadow stack),
> > MSR_IA32_PL1_SSP (Privilege Level 1 shadow stack),
> > MSR_IA32_PL2_SSP (Privilege Level 2 shadow stack).
> >
> > Introduce them into XSAVES system states.
> >
> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> > ---
> > arch/x86/include/asm/fpu/types.h | 22 +++++++++++++++++++++
> > arch/x86/include/asm/fpu/xstate.h | 4 +++-
> > arch/x86/include/uapi/asm/processor-flags.h | 2 ++
> > arch/x86/kernel/fpu/xstate.c | 10 ++++++++++
> > 4 files changed, 37 insertions(+), 1 deletion(-)
>
> And yet, no changes to msr-index.h !?
You are right. I will move msr-index.h changes to here.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 18/27] mm: Introduce do_mmap_locked()
From: Yu-cheng Yu @ 2019-06-07 16:16 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607074707.GD3463@hirez.programming.kicks-ass.net>
On Fri, 2019-06-07 at 09:47 +0200, Peter Zijlstra wrote:
> On Fri, Jun 07, 2019 at 09:43:22AM +0200, Peter Zijlstra wrote:
> > On Thu, Jun 06, 2019 at 01:06:37PM -0700, Yu-cheng Yu wrote:
> > > There are a few places that need do_mmap() with mm->mmap_sem held.
> > > Create an in-line function for that.
> > >
> > > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> > > ---
> > > include/linux/mm.h | 18 ++++++++++++++++++
> > > 1 file changed, 18 insertions(+)
> > >
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 398f1e1c35e5..7cf014604848 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -2411,6 +2411,24 @@ static inline void mm_populate(unsigned long addr,
> > > unsigned long len)
> > > static inline void mm_populate(unsigned long addr, unsigned long len) {}
> > > #endif
> > >
> > > +static inline unsigned long do_mmap_locked(unsigned long addr,
> > > + unsigned long len, unsigned long prot, unsigned long flags,
> > > + vm_flags_t vm_flags)
> > > +{
> > > + struct mm_struct *mm = current->mm;
> > > + unsigned long populate;
> > > +
> > > + down_write(&mm->mmap_sem);
> > > + addr = do_mmap(NULL, addr, len, prot, flags, vm_flags, 0,
> > > + &populate, NULL);
> >
> > Funny thing how do_mmap() takes a file pointer as first argument and
> > this thing explicitly NULLs that. That more or less invalidates the name
> > do_mmap_locked().
> >
> > > + up_write(&mm->mmap_sem);
> > > +
> > > + if (populate)
> > > + mm_populate(addr, populate);
> > > +
> > > + return addr;
> > > +}
>
> You also don't retain that last @uf argument.
>
> I'm thikning you're better off adding a helper to the cet.c file; call
> it cet_mmap() or whatever.
Ok, I will fix that.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Yu-cheng Yu @ 2019-06-07 16:17 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607075822.GR3419@hirez.programming.kicks-ass.net>
On Fri, 2019-06-07 at 09:58 +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote:
> > An ELF file's .note.gnu.property indicates features the executable file
> > can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> > indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or
> > GNU_PROPERTY_X86_FEATURE_1_SHSTK.
> >
> > With this patch, if an arch needs to setup features from ELF properties,
> > it needs CONFIG_ARCH_USE_GNU_PROPERTY to be set, and a specific
> > arch_setup_property().
> >
> > For example, for X86_64:
> >
> > int arch_setup_property(void *ehdr, void *phdr, struct file *f, bool inter)
> > {
> > int r;
> > uint32_t property;
> >
> > r = get_gnu_property(ehdr, phdr, f, GNU_PROPERTY_X86_FEATURE_1_AND,
> > &property);
> > ...
> > }
> >
> > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
>
> Did HJ write this patch as suggested by that SoB chain? If so, you lost
> a From: line on top, if not, the SoB thing is invalid.
I will fix that.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-07 16:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607080832.GT3419@hirez.programming.kicks-ass.net>
On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
> > Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
> > that allows execution of legacy, non-IBT compatible library by an
> > IBT-enabled application. When set, each bit in the bitmap indicates
> > one page of legacy code.
> >
> > The bitmap is allocated and setup from the application.
> > +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
> > +{
> > + u64 r;
> > +
> > + if (!current->thread.cet.ibt_enabled)
> > + return -EINVAL;
> > +
> > + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
> > + return -EINVAL;
> > +
> > + current->thread.cet.ibt_bitmap_addr = bitmap;
> > + current->thread.cet.ibt_bitmap_size = size;
> > +
> > + /*
> > + * Turn on IBT legacy bitmap.
> > + */
> > + modify_fpu_regs_begin();
> > + rdmsrl(MSR_IA32_U_CET, r);
> > + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
> > + wrmsrl(MSR_IA32_U_CET, r);
> > + modify_fpu_regs_end();
> > +
> > + return 0;
> > +}
>
> So you just program a random user supplied address into the hardware.
> What happens if there's not actually anything at that address or the
> user munmap()s the data after doing this?
This function checks the bitmap's alignment and size, and anything else is the
app's responsibility. What else do you think the kernel should check?
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Andy Lutomirski @ 2019-06-07 16:35 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <aa8a92ef231d512b5c9855ef416db050b5ab59a6.camel@intel.com>
> On Jun 7, 2019, at 9:23 AM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>
>> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
>>> On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
>>> Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
>>> that allows execution of legacy, non-IBT compatible library by an
>>> IBT-enabled application. When set, each bit in the bitmap indicates
>>> one page of legacy code.
>>>
>>> The bitmap is allocated and setup from the application.
>>> +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
>>> +{
>>> + u64 r;
>>> +
>>> + if (!current->thread.cet.ibt_enabled)
>>> + return -EINVAL;
>>> +
>>> + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
>>> + return -EINVAL;
>>> +
>>> + current->thread.cet.ibt_bitmap_addr = bitmap;
>>> + current->thread.cet.ibt_bitmap_size = size;
>>> +
>>> + /*
>>> + * Turn on IBT legacy bitmap.
>>> + */
>>> + modify_fpu_regs_begin();
>>> + rdmsrl(MSR_IA32_U_CET, r);
>>> + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
>>> + wrmsrl(MSR_IA32_U_CET, r);
>>> + modify_fpu_regs_end();
>>> +
>>> + return 0;
>>> +}
>>
>> So you just program a random user supplied address into the hardware.
>> What happens if there's not actually anything at that address or the
>> user munmap()s the data after doing this?
>
> This function checks the bitmap's alignment and size, and anything else is the
> app's responsibility. What else do you think the kernel should check?
>
One might reasonably wonder why this state is privileged in the first place and, given that, why we’re allowing it to be written like this.
Arguably we should have another prctl to lock these values (until exec) as a gardening measure.
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-07 16:39 UTC (permalink / raw)
To: Andy Lutomirski, Yu-cheng Yu
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <76B7B1AE-3AEA-4162-B539-990EF3CCE2C2@amacapital.net>
On 6/7/19 9:35 AM, Andy Lutomirski wrote:
> One might reasonably wonder why this state is privileged in the first
> place and, given that, why we’re allowing it to be written like
> this.
I think it's generally a good architectural practice to make things like
this privileged. They're infrequent so can survive the cost of a trip
in/out of the kernel and are a great choke point to make sure the OS is
involved. I wish we had the same for MPX or pkeys per-task "setup".
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-07 16:45 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <76B7B1AE-3AEA-4162-B539-990EF3CCE2C2@amacapital.net>
On Fri, 2019-06-07 at 09:35 -0700, Andy Lutomirski wrote:
> > On Jun 7, 2019, at 9:23 AM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
> >
> > > On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
> > > > On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
> > > > Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
> > > > that allows execution of legacy, non-IBT compatible library by an
> > > > IBT-enabled application. When set, each bit in the bitmap indicates
> > > > one page of legacy code.
> > > >
> > > > The bitmap is allocated and setup from the application.
> > > > +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
> > > > +{
> > > > + u64 r;
> > > > +
> > > > + if (!current->thread.cet.ibt_enabled)
> > > > + return -EINVAL;
> > > > +
> > > > + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
> > > > + return -EINVAL;
> > > > +
> > > > + current->thread.cet.ibt_bitmap_addr = bitmap;
> > > > + current->thread.cet.ibt_bitmap_size = size;
> > > > +
> > > > + /*
> > > > + * Turn on IBT legacy bitmap.
> > > > + */
> > > > + modify_fpu_regs_begin();
> > > > + rdmsrl(MSR_IA32_U_CET, r);
> > > > + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
> > > > + wrmsrl(MSR_IA32_U_CET, r);
> > > > + modify_fpu_regs_end();
> > > > +
> > > > + return 0;
> > > > +}
> > >
> > > So you just program a random user supplied address into the hardware.
> > > What happens if there's not actually anything at that address or the
> > > user munmap()s the data after doing this?
> >
> > This function checks the bitmap's alignment and size, and anything else is
> > the
> > app's responsibility. What else do you think the kernel should check?
> >
>
> One might reasonably wonder why this state is privileged in the first place
> and, given that, why we’re allowing it to be written like this.
>
> Arguably we should have another prctl to lock these values (until exec) as a
> gardening measure.
We can prevent the bitmap from being set more than once. I will test it.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Andy Lutomirski @ 2019-06-07 17:05 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <ac8827d7b516f4b58e1df20f45b94998d36c418c.camel@intel.com>
> On Jun 7, 2019, at 9:45 AM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>
> On Fri, 2019-06-07 at 09:35 -0700, Andy Lutomirski wrote:
>>> On Jun 7, 2019, at 9:23 AM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>>>
>>>>> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
>>>>> On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
>>>>> Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
>>>>> that allows execution of legacy, non-IBT compatible library by an
>>>>> IBT-enabled application. When set, each bit in the bitmap indicates
>>>>> one page of legacy code.
>>>>>
>>>>> The bitmap is allocated and setup from the application.
>>>>> +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
>>>>> +{
>>>>> + u64 r;
>>>>> +
>>>>> + if (!current->thread.cet.ibt_enabled)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
>>>>> + return -EINVAL;
>>>>> +
>>>>> + current->thread.cet.ibt_bitmap_addr = bitmap;
>>>>> + current->thread.cet.ibt_bitmap_size = size;
>>>>> +
>>>>> + /*
>>>>> + * Turn on IBT legacy bitmap.
>>>>> + */
>>>>> + modify_fpu_regs_begin();
>>>>> + rdmsrl(MSR_IA32_U_CET, r);
>>>>> + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
>>>>> + wrmsrl(MSR_IA32_U_CET, r);
>>>>> + modify_fpu_regs_end();
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>
>>>> So you just program a random user supplied address into the hardware.
>>>> What happens if there's not actually anything at that address or the
>>>> user munmap()s the data after doing this?
>>>
>>> This function checks the bitmap's alignment and size, and anything else is
>>> the
>>> app's responsibility. What else do you think the kernel should check?
>>>
>>
>> One might reasonably wonder why this state is privileged in the first place
>> and, given that, why we’re allowing it to be written like this.
>>
>> Arguably we should have another prctl to lock these values (until exec) as a
>> gardening measure.
>
> We can prevent the bitmap from being set more than once. I will test it.
>
I think it would be better to make locking an explicit opt-in.
^ permalink raw reply
* [PATCH] lib/string_helpers: fix some kerneldoc warnings
From: Jonathan Corbet @ 2019-06-07 17:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, linux-doc
Due to some sad limitations in how kerneldoc comments are parsed, the
documentation in lib/string_helpers.c generates these warnings:
./lib/string_helpers.c:236: WARNING: Unexpected indentation.
./lib/string_helpers.c:241: WARNING: Block quote ends without a blank line; unexpected unindent.
./lib/string_helpers.c:446: WARNING: Unexpected indentation.
./lib/string_helpers.c:451: WARNING: Block quote ends without a blank line; unexpected unindent.
./lib/string_helpers.c:474: WARNING: Unexpected indentation.
Rework the comments to obtain something like the desired result.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
lib/string_helpers.c | 77 +++++++++++++++++++++++---------------------
1 file changed, 40 insertions(+), 37 deletions(-)
diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index 29c490e5d478..a9f5ef9289e6 100644
--- a/lib/string_helpers.c
+++ b/lib/string_helpers.c
@@ -230,35 +230,36 @@ static bool unescape_special(char **src, char **dst)
* @src: source buffer (escaped)
* @dst: destination buffer (unescaped)
* @size: size of the destination buffer (0 to unlimit)
- * @flags: combination of the flags (bitwise OR):
- * %UNESCAPE_SPACE:
+ * @flags: combination of the flags.
+ *
+ * Description:
+ * The function unquotes characters in the given string.
+ *
+ * Because the size of the output will be the same as or less than the size of
+ * the input, the transformation may be performed in place.
+ *
+ * Caller must provide valid source and destination pointers. Be aware that
+ * destination buffer will always be NULL-terminated. Source string must be
+ * NULL-terminated as well. The supported flags are::
+ *
+ * UNESCAPE_SPACE:
* '\f' - form feed
* '\n' - new line
* '\r' - carriage return
* '\t' - horizontal tab
* '\v' - vertical tab
- * %UNESCAPE_OCTAL:
+ * UNESCAPE_OCTAL:
* '\NNN' - byte with octal value NNN (1 to 3 digits)
- * %UNESCAPE_HEX:
+ * UNESCAPE_HEX:
* '\xHH' - byte with hexadecimal value HH (1 to 2 digits)
- * %UNESCAPE_SPECIAL:
+ * UNESCAPE_SPECIAL:
* '\"' - double quote
* '\\' - backslash
* '\a' - alert (BEL)
* '\e' - escape
- * %UNESCAPE_ANY:
+ * UNESCAPE_ANY:
* all previous together
*
- * Description:
- * The function unquotes characters in the given string.
- *
- * Because the size of the output will be the same as or less than the size of
- * the input, the transformation may be performed in place.
- *
- * Caller must provide valid source and destination pointers. Be aware that
- * destination buffer will always be NULL-terminated. Source string must be
- * NULL-terminated as well.
- *
* Return:
* The amount of the characters processed to the destination buffer excluding
* trailing '\0' is returned.
@@ -440,7 +441,29 @@ static bool escape_hex(unsigned char c, char **dst, char *end)
* @isz: source buffer size
* @dst: destination buffer (escaped)
* @osz: destination buffer size
- * @flags: combination of the flags (bitwise OR):
+ * @flags: combination of the flags
+ * @only: NULL-terminated string containing characters used to limit
+ * the selected escape class. If characters are included in @only
+ * that would not normally be escaped by the classes selected
+ * in @flags, they will be copied to @dst unescaped.
+ *
+ * Description:
+ * The process of escaping byte buffer includes several parts. They are applied
+ * in the following sequence.
+ *
+ * 1. The character is matched to the printable class, if asked, and in
+ * case of match it passes through to the output.
+ * 2. The character is not matched to the one from @only string and thus
+ * must go as-is to the output.
+ * 3. The character is checked if it falls into the class given by @flags.
+ * %ESCAPE_OCTAL and %ESCAPE_HEX are going last since they cover any
+ * character. Note that they actually can't go together, otherwise
+ * %ESCAPE_HEX will be ignored.
+ *
+ * Caller must provide valid source and destination pointers. Be aware that
+ * destination buffer will not be NULL-terminated, thus caller have to append
+ * it if needs. The supported flags are::
+ *
* %ESCAPE_SPACE: (special white space, not space itself)
* '\f' - form feed
* '\n' - new line
@@ -463,26 +486,6 @@ static bool escape_hex(unsigned char c, char **dst, char *end)
* all previous together
* %ESCAPE_HEX:
* '\xHH' - byte with hexadecimal value HH (2 digits)
- * @only: NULL-terminated string containing characters used to limit
- * the selected escape class. If characters are included in @only
- * that would not normally be escaped by the classes selected
- * in @flags, they will be copied to @dst unescaped.
- *
- * Description:
- * The process of escaping byte buffer includes several parts. They are applied
- * in the following sequence.
- * 1. The character is matched to the printable class, if asked, and in
- * case of match it passes through to the output.
- * 2. The character is not matched to the one from @only string and thus
- * must go as-is to the output.
- * 3. The character is checked if it falls into the class given by @flags.
- * %ESCAPE_OCTAL and %ESCAPE_HEX are going last since they cover any
- * character. Note that they actually can't go together, otherwise
- * %ESCAPE_HEX will be ignored.
- *
- * Caller must provide valid source and destination pointers. Be aware that
- * destination buffer will not be NULL-terminated, thus caller have to append
- * it if needs.
*
* Return:
* The total size of the escaped output that would be generated for
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] Documentation: DMA-API: fix a function name of max_mapping_size
From: Jonathan Corbet @ 2019-06-07 17:10 UTC (permalink / raw)
To: Yoshihiro Shimoda; +Cc: jroedel, hch, m.szyprowski, linux-doc, iommu
In-Reply-To: <1559893633-6852-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On Fri, 7 Jun 2019 16:47:13 +0900
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> wrote:
> The exported function name is dma_max_mapping_size(), not
> dma_direct_max_mapping_size() so that this patch fixes
> the function name in the documentation.
>
> Fixes: 133d624b1cee ("dma: Introduce dma_max_mapping_size()")
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> Documentation/DMA-API.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
> index 0076150..e47c63b 100644
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -198,7 +198,7 @@ call to set the mask to the value returned.
> ::
>
> size_t
> - dma_direct_max_mapping_size(struct device *dev);
> + dma_max_mapping_size(struct device *dev);
>
> Returns the maximum size of a mapping for the device. The size parameter
> of the mapping functions like dma_map_single(), dma_map_page() and
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Documentation/dm-init: fix multi device example
From: Jonathan Corbet @ 2019-06-07 17:13 UTC (permalink / raw)
To: Helen Koike
Cc: dm-devel, swboyd, wad, keescook, snitzer, linux-doc,
richard.weinberger, linux-kernel, linux-lvm, enric.balletbo,
kernel, agk
In-Reply-To: <20190604182719.15944-1-helen.koike@collabora.com>
On Tue, 4 Jun 2019 15:27:19 -0300
Helen Koike <helen.koike@collabora.com> wrote:
> The example in the docs regarding multiple device-mappers is invalid (it
> has a wrong number of arguments), it's a left over from previous
> versions of the patch.
> Replace the example with an valid and tested one.
>
> Signed-off-by: Helen Koike <helen.koike@collabora.com>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Documentation: fix typo CLOCK_MONONOTNIC_COARSE
From: Jonathan Corbet @ 2019-06-07 17:22 UTC (permalink / raw)
To: Aurelien Thierry
Cc: Arnd Bergmann, John Stultz, Thomas Gleixner, Linus Walleij,
Randy Dunlap, linux-doc, trivial
In-Reply-To: <593f6e44-af55-ac7c-1c67-12e515028fe5@quoscient.io>
On Fri, 7 Jun 2019 10:07:02 +0200
Aurelien Thierry <aurelien.thierry@quoscient.io> wrote:
> Fix typo in documentation file timekeeping.rst: CLOCK_MONONOTNIC_COARSE
> should be CLOCK_MONOTONIC_COARSE.
>
> Signed-off-by: Aurelien Thierry <aurelien.thierry@quoscient.io>
> ---
> Documentation/core-api/timekeeping.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/core-api/timekeeping.rst
> b/Documentation/core-api/timekeeping.rst
> index 93cbeb9daec0..5f87d9c8b04d 100644
> --- a/Documentation/core-api/timekeeping.rst
> +++ b/Documentation/core-api/timekeeping.rst
> @@ -111,7 +111,7 @@ Some additional variants exist for more specialized
> cases:
> void ktime_get_coarse_raw_ts64( struct timespec64 * )
>
> These are quicker than the non-coarse versions, but less accurate,
> - corresponding to CLOCK_MONONOTNIC_COARSE and CLOCK_REALTIME_COARSE
> + corresponding to CLOCK_MONOTONIC_COARSE and CLOCK_REALTIME_COARSE
> in user space, along with the equivalent boottime/tai/raw
> timebase not available in user space.
Patch applied; congratulations on what appears to be your first kernel
patch!
Note that this patch was badly corrupted by your mailer; it took me a
while to unmangle it. Before sending your next one, I'd recommend being
sure that you can email it to yourself and apply the result. There are
some hints in Documentation/process/email-clients.rst.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH trivial] Documentation: tee: Grammar s/the its/its/
From: Jonathan Corbet @ 2019-06-07 17:23 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Jens Wiklander, Jiri Kosina, linux-doc, linux-kernel
In-Reply-To: <20190607110729.12734-1-geert+renesas@glider.be>
On Fri, 7 Jun 2019 13:07:29 +0200
Geert Uytterhoeven <geert+renesas@glider.be> wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/tee.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/tee.txt b/Documentation/tee.txt
> index 56ea85ffebf24545..afacdf2fd1de5455 100644
> --- a/Documentation/tee.txt
> +++ b/Documentation/tee.txt
> @@ -32,7 +32,7 @@ User space (the client) connects to the driver by opening /dev/tee[0-9]* or
> memory.
>
> - TEE_IOC_VERSION lets user space know which TEE this driver handles and
> - the its capabilities.
> + its capabilities.
>
> - TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH trivial] Documentation: net: dsa: Grammar s/the its/its/
From: Jonathan Corbet @ 2019-06-07 17:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S . Miller, Jiri Kosina, netdev, linux-doc, linux-kernel
In-Reply-To: <20190607110842.12876-1-geert+renesas@glider.be>
On Fri, 7 Jun 2019 13:08:42 +0200
Geert Uytterhoeven <geert+renesas@glider.be> wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/networking/dsa/dsa.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst
> index ca87068b9ab904a9..563d56c6a25c924e 100644
> --- a/Documentation/networking/dsa/dsa.rst
> +++ b/Documentation/networking/dsa/dsa.rst
> @@ -531,7 +531,7 @@ Bridge VLAN filtering
> a software implementation.
>
> .. note:: VLAN ID 0 corresponds to the port private database, which, in the context
> - of DSA, would be the its port-based VLAN, used by the associated bridge device.
> + of DSA, would be its port-based VLAN, used by the associated bridge device.
>
> - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a
> Forwarding Database entry, the switch hardware should be programmed to delete
> @@ -554,7 +554,7 @@ Bridge VLAN filtering
> associated with this VLAN ID.
>
> .. note:: VLAN ID 0 corresponds to the port private database, which, in the context
> - of DSA, would be the its port-based VLAN, used by the associated bridge device.
> + of DSA, would be its port-based VLAN, used by the associated bridge device.
Applied, thanks.
jon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox