Hi Jon,
I was on a long holiday. I will re-send a V2 patch without that document in
the next days
On Thursday, September 20, 2018 10:35:11 PM CEST Jonathan Corbet wrote:
> On Thu, 20 Sep 2018 14:29:57 -0600
>
> Jonathan Corbet wrote:
> > On Sun, 9 Sep 2018 18:16:41 +0200
> >
> > Federico Vag
* Baoquan He wrote:
> In Documentation/x86/x86_64/mm.txt, the style of descritions about
> memory region layout is a little confusing:
>
> - mix size in TB with 'bits'
> - sometimes mention a size in the description and sometimes not
> - sometimes list holes by address, sometimes only as an
From: Bartosz Golaszewski
We check if the pointer returned by __nvmem_device_get() is not NULL
while we should actually check if it is not IS_ERR(nvmem). Fix it.
While we're at it: fix the next error path where we should assign an
error value to cell before returning.
Signed-off-by: Bartosz Gol
wt., 2 paź 2018 o 11:42 Bartosz Golaszewski napisał(a):
>
> From: Bartosz Golaszewski
>
> We check if the pointer returned by __nvmem_device_get() is not NULL
> while we should actually check if it is not IS_ERR(nvmem). Fix it.
>
> While we're at it: fix the next error path where we should assign
From: Bartosz Golaszewski
We check if the pointer returned by __nvmem_device_get() is not NULL
while we should actually check if it is not IS_ERR(nvmem). Fix it.
While we're at it: fix the next error path where we should assign an
error value to cell before returning.
Signed-off-by: Bartosz Gol
On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
> "lsm.enable=...", this removes the LSM-specific enabling logic from
> SELinux.
>
> Signed-off-by: Kees Cook
> ---
> .../admin-guide/kernel-parameters.txt | 9 --
> se
This patch makes the untagged_addr macro accept all kinds of address types
(void *, unsigned long, etc.) and allows not to specify type casts in each
place where it is used. This is done by using __typeof__.
Signed-off-by: Andrey Konovalov
---
arch/arm64/include/asm/uaccess.h | 3 ++-
1 file cha
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.
Right now the
This patch adds a simple test, that calls the uname syscall with a
tagged user pointer as an argument. Without the kernel accepting tagged
user pointers the test fails with EFAULT.
Signed-off-by: Andrey Konovalov
---
tools/testing/selftests/arm64/.gitignore | 1 +
tools/testing/selftests/a
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get_user_pages, that is used
by the futex syscall). Since a user can provided tagged addresses, we need
to handle such case.
Add untagging to gup.c functions that use user addresses fo
In copy_mount_options a user address is being subtracted from TASK_SIZE.
If the address is lower than TASK_SIZE, the size is calculated to not
allow the exact_copy_from_user() call to cross TASK_SIZE boundary.
However if the address is tagged, then the size will be calculated
incorrectly.
Untag th
Document the changes in Documentation/arm64/tagged-pointers.txt.
Signed-off-by: Andrey Konovalov
---
Documentation/arm64/tagged-pointers.txt | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.txt
b/Documentation/arm
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel, the untagged_addr macro needs to be defined
for all architectures.
Define it as a noop for other architectures besides arm64
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_from_user and others, so here we
need to handle the case of tagged user addresses separately.
Untag user pointers passed to these functions.
Signed-off-by: Andrey Konovalov
---
lib
copy_from_user (and a few other similar functions) are used to copy data
from user memory into the kernel memory or vice versa. Since a user can
provided a tagged pointer to one of the syscalls that use copy_from_user,
we need to correctly handle such pointers.
Do this by untagging user pointers i
On Fri, Sep 28, 2018 at 7:50 PM, Catalin Marinas
wrote:
> On Mon, Sep 17, 2018 at 07:01:00PM +0200, Andrey Konovalov wrote:
>> Looking at patch #8 ("usb, arm64: untag user addresses in devio") in
>> this series, it seems that that devio ioctl actually accepts a pointer
>> into a vma, so we should
On Fri, Sep 21, 2018 at 5:13 PM, Andrey Konovalov wrote:
> This patch updates KASAN documentation to reflect the addition of the new
> tag-based mode.
>
> Signed-off-by: Andrey Konovalov
> ---
> Documentation/dev-tools/kasan.rst | 232 ++
> 1 file changed, 138 inserti
Hi Stephen,
The Compiler Attributes series has been stable for 10+ days. To
increase testing before 4.20, I would to request it being picked up
for -next.
The changes w.r.t. v5 in the LKML:
- Rebased on top of next-20180928, which required removing
aligned_largest, which was removed by 9503cd9
On 10/02/2018 08:12 AM, Paul Moore wrote:
On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
SELinux.
Signed-off-by: Kees Cook
---
.../admin-guide/kernel-paramet
On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley wrote:
> On 10/02/2018 08:12 AM, Paul Moore wrote:
>>
>> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
>>>
>>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>>> "lsm.enable=...", this removes the LSM-specific enabling logic from
On 10/02/2018 10:44 AM, Kees Cook wrote:
On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley wrote:
On 10/02/2018 08:12 AM, Paul Moore wrote:
On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-
On Fri, Sep 21, 2018 at 08:03:26AM -0700, Yu-cheng Yu wrote:
> To support XSAVES system states, change some names to distinguish
> user and system states.
I don't understand what the logic here is. SDM says:
XSAVES—Save Processor Extended States Supervisor
the stress being on "Supervisor" - why
On Tue, 2018-10-02 at 17:29 +0200, Borislav Petkov wrote:
> On Fri, Sep 21, 2018 at 08:03:26AM -0700, Yu-cheng Yu wrote:
> > To support XSAVES system states, change some names to distinguish
> > user and system states.
>
> I don't understand what the logic here is. SDM says:
>
> XSAVES—Save Proce
On 10/02/2018 09:21 AM, Yu-cheng Yu wrote:
> On Tue, 2018-10-02 at 17:29 +0200, Borislav Petkov wrote:
>> On Fri, Sep 21, 2018 at 08:03:26AM -0700, Yu-cheng Yu wrote:
>>> To support XSAVES system states, change some names to distinguish
>>> user and system states.
>> I don't understand what the log
Hello together,
On 8/18/18 3:15 AM, Waiman Long wrote:
On 08/17/2018 12:45 PM, Davidlohr Bueso wrote:
Cc'ing Manfred.
On Mon, 18 Jun 2018, Waiman Long wrote:
The maximum number of unique System V IPC identifiers was limited to
32k. That limit should be big enough for most use cases.
Howeve
‐‐‐ Original Message ‐‐‐
On Tuesday, October 2, 2018 4:57 PM, Stephen Smalley wrote:
> On 10/02/2018 10:44 AM, Kees Cook wrote:
>
> > On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley s...@tycho.nsa.gov wrote:
> >
> > > On 10/02/2018 08:12 AM, Paul Moore wrote:
> > >
> > > > On Mon, Oct 1,
On Tue, Oct 2, 2018 at 7:58 AM, Stephen Smalley wrote:
> On 10/02/2018 10:44 AM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley wrote:
>>>
>>> On 10/02/2018 08:12 AM, Paul Moore wrote:
On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
>
>
> Since
On Tue, Oct 02, 2018 at 09:30:52AM -0700, Dave Hansen wrote:
> > Good point. However, "system" is more indicative; CET states are per-task
> > and
> > not "Supervisor". Do we want to go back to "Supervisor" or add comments?
>
> This is one of those things where the SDM language does not match w
On 10/02/2018 09:37 AM, Borislav Petkov wrote:
> This patch's commit message is not even close. So I'd very much
> appreciate a more verbose explanation, even if it repeats itself at
> places.
Yep, totally agree.
On Tue, 2018-10-02 at 09:39 -0700, Dave Hansen wrote:
> On 10/02/2018 09:37 AM, Borislav Petkov wrote:
> > This patch's commit message is not even close. So I'd very much
> > appreciate a more verbose explanation, even if it repeats itself at
> > places.
>
> Yep, totally agree.
Ok, I will work on
On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
wrote:
> It's always documented as: "selinux=1 security=selinux" so security= should
> still do the job and selinux=1 become no-op, no?
The v3 patch set worked this way, yes. (The per-LSM enable defaults
were set by the LSM. Only in the case of "lsm.d
Hi Nicolin,
On Mon, Oct 01, 2018 at 06:05:22PM -0700, Nicolin Chen wrote:
> Texas Instruments INA3221 is a triple-channel shunt and bus
> voltage monitor. This patch adds a DT binding doc for it.
>
> Signed-off-by: Nicolin Chen
> ---
This version of the series looks good to me. I'll add both pa
On Tue, Oct 02, 2018 at 10:05:18AM -0700, Guenter Roeck wrote:
> Hi Nicolin,
>
> On Mon, Oct 01, 2018 at 06:05:22PM -0700, Nicolin Chen wrote:
> > Texas Instruments INA3221 is a triple-channel shunt and bus
> > voltage monitor. This patch adds a DT binding doc for it.
> >
> > Signed-off-by: Nicol
On Fri, Sep 21, 2018 at 08:03:27AM -0700, Yu-cheng Yu wrote:
> XSAVES saves both system and user states. The Linux kernel
> currently does not save/restore any system states. This patch
> creates the framework for supporting system states.
... and needs a lot more text explaining *why* it is doi
On 10/02/2018 12:32 PM, Manfred Spraul wrote:
> Hello together,
>
> On 8/18/18 3:15 AM, Waiman Long wrote:
>> On 08/17/2018 12:45 PM, Davidlohr Bueso wrote:
>>> Cc'ing Manfred.
>>>
>>> On Mon, 18 Jun 2018, Waiman Long wrote:
>>>
The maximum number of unique System V IPC identifiers was limited
On 10/02/2018 12:54 PM, Kees Cook wrote:
On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
wrote:
It's always documented as: "selinux=1 security=selinux" so security= should
still do the job and selinux=1 become no-op, no?
The v3 patch set worked this way, yes. (The per-LSM enable defaults
were s
On 10/02/2018 09:54 AM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
> wrote:
>> It's always documented as: "selinux=1 security=selinux" so security= should
>> still do the job and selinux=1 become no-op, no?
>
> The v3 patch set worked this way, yes. (The per-LSM enable defau
On Tue, Oct 2, 2018 at 11:33 AM, Stephen Smalley wrote:
> On 10/02/2018 12:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
>> wrote:
>>>
>>> It's always documented as: "selinux=1 security=selinux" so security=
>>> should
>>> still do the job and selinux=1 become no-op,
On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
wrote:
> Under the current scheme
>
> lsm.enabled=selinux
>
> could actually mean selinux,yama,loadpin,something_else are
> enabled. If we extend this behavior to when full stacking lands
>
> lsm.enabled=selinux,yama
>
> might mean selinux,yama,apparm
On 10/02/2018 12:17 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> wrote:
>> Under the current scheme
>>
>> lsm.enabled=selinux
>>
>> could actually mean selinux,yama,loadpin,something_else are
>> enabled. If we extend this behavior to when full stacking lands
>>
>> lsm.en
Hello, Waiman.
My apologies for the delay.
On Mon, Aug 27, 2018 at 01:50:18PM -0400, Waiman Long wrote:
> My current code has explicitly assumed the following relationship for
> partition root.
>
> cpus_allowed = effective_cpus + reserved_cpus
>
> Also effective_cpus cannot be empty. Specif
On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
wrote:
> On 10/02/2018 12:17 PM, Kees Cook wrote:
>> I could define CONFIG_LSM_ENABLE as being "additive" to
>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>
> Oh sure lets deal with my complaint about too many ways to c
On 10/02/2018 04:06 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> My apologies for the delay.
>
> On Mon, Aug 27, 2018 at 01:50:18PM -0400, Waiman Long wrote:
>> My current code has explicitly assumed the following relationship for
>> partition root.
>>
>> cpus_allowed = effective_cpus + reserved_c
Current phrasing is ambiguous since it's unclear if attaching to a
children through PTRACE_TRACEME requires CAP_SYS_PTRACE. Rephrase the
sentence to make that clear.
Signed-off-by: Yves-Alexis Perez
---
Documentation/admin-guide/LSM/Yama.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
On Tue, Oct 2, 2018 at 1:47 PM, Yves-Alexis Perez wrote:
> Current phrasing is ambiguous since it's unclear if attaching to a
> children through PTRACE_TRACEME requires CAP_SYS_PTRACE. Rephrase the
> sentence to make that clear.
>
> Signed-off-by: Yves-Alexis Perez
Thanks! Yes, this makes things
On Tue, Oct 02, 2018 at 10:47:23PM +0200, Yves-Alexis Perez wrote:
> Current phrasing is ambiguous since it's unclear if attaching to a
> children through PTRACE_TRACEME requires CAP_SYS_PTRACE. Rephrase the
> sentence to make that clear.
I disagree that your sentence makes that clear. How about:
On Tue, Oct 2, 2018 at 1:52 PM, Matthew Wilcox wrote:
> On Tue, Oct 02, 2018 at 10:47:23PM +0200, Yves-Alexis Perez wrote:
>> Current phrasing is ambiguous since it's unclear if attaching to a
>> children through PTRACE_TRACEME requires CAP_SYS_PTRACE. Rephrase the
>> sentence to make that clear.
On Tue, 2018-10-02 at 13:52 -0700, Matthew Wilcox wrote:
> On Tue, Oct 02, 2018 at 10:47:23PM +0200, Yves-Alexis Perez wrote:
> > Current phrasing is ambiguous since it's unclear if attaching to a
> > children through PTRACE_TRACEME requires CAP_SYS_PTRACE. Rephrase the
> > sentence to make that cl
On 10/02/2018 01:29 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
> wrote:
>> On 10/02/2018 12:17 PM, Kees Cook wrote:
>>> I could define CONFIG_LSM_ENABLE as being "additive" to
>>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>>
>> Oh sure l
Hi Miguel,
On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda
wrote:
>
> The Compiler Attributes series has been stable for 10+ days. To
> increase testing before 4.20, I would to request it being picked up
> for -next.
>
> The changes w.r.t. v5 in the LKML:
>
> - Rebased on top of next-20180928
On Mon, 1 Oct 2018, Kees Cook wrote:
> This partially reverts commit 58eacfffc417 ("init, tracing: instrument
> security and console initcall trace events") since security init calls
> are about to no longer resemble regular init calls.
>
> Signed-off-by: Kees Cook
> Reviewed-by: Casey Schaufler
On Mon, 1 Oct 2018, Kees Cook wrote:
> Since the struct lsm_info table is not an initcall, we can just move it
> into INIT_DATA like all the other tables.
>
> Signed-off-by: Kees Cook
> Reviewed-by: Casey Schaufler
> Reviewed-by: John Johansen
Reviewed-by: James Morris
--
James Morris
On Mon, 1 Oct 2018, Kees Cook wrote:
> Instead of using argument-based initializers, switch to defining the
> contents of struct lsm_info on a per-LSM basis. This also drops
> the final use of the now inaccurate "initcall" naming.
>
> Signed-off-by: Kees Cook
> Reviewed-by: Casey Schaufler
Re
On Tue, Oct 2, 2018 at 2:11 PM Stephen Rothwell wrote:
>
> Hi Miguel,
>
> On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda
> wrote:
> >
> > The Compiler Attributes series has been stable for 10+ days. To
> > increase testing before 4.20, I would to request it being picked up
> > for -next.
> >
> >
On Mon, 1 Oct 2018, Kees Cook wrote:
> Booting with "lsm.debug" will report future details on how LSM ordering
> decisions are being made.
>
> Signed-off-by: Kees Cook
> Reviewed-by: Casey Schaufler
> Reviewed-by: John Johansen
Reviewed-by: James Morris
--
James Morris
On Mon, 1 Oct 2018, Kees Cook wrote:
> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.
I guess we could have a boot param which specifies what to do if any LSM
fails to init, as I think some folks will want to stop execution at th
On Tue, Oct 2, 2018 at 2:20 PM, James Morris wrote:
> On Mon, 1 Oct 2018, Kees Cook wrote:
>
>> LSM initialization failures have traditionally been ignored. We should
>> at least WARN when something goes wrong.
>
> I guess we could have a boot param which specifies what to do if any LSM
> fails to
Hi Stephen,
On Tue, Oct 2, 2018 at 11:11 PM Stephen Rothwell wrote:
>
> Hi Miguel,
>
> On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda
> wrote:
> >
> > The Compiler Attributes series has been stable for 10+ days. To
> > increase testing before 4.20, I would to request it being picked up
> > for
On Tue, 2 Oct 2018, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> wrote:
> > Under the current scheme
> >
> > lsm.enabled=selinux
> >
> > could actually mean selinux,yama,loadpin,something_else are
> > enabled. If we extend this behavior to when full stacking lands
> >
> > l
Hi Nick,
On Tue, Oct 2, 2018 at 11:16 PM Nick Desaulniers
wrote:
>
> On Tue, Oct 2, 2018 at 2:11 PM Stephen Rothwell wrote:
> >
> > Hi Miguel,
> >
> > On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda
> > wrote:
> > >
> > > The Compiler Attributes series has been stable for 10+ days. To
> > > inc
Miguel Ojeda wrote on Wed, Oct 03, 2018:
> As I have read, -next is supposed to be a vision of what the merge
> window will look like after merging everything, i.e. ideally -rc1. For
> that to work for files out-of-tree (like these ones, which are not
> maintained by a single tree), changes should
Hi Miguel,
On Wed, 3 Oct 2018 00:36:52 +0200 Dominique Martinet
wrote:
>
> Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > As I have read, -next is supposed to be a vision of what the merge
> > window will look like after merging everything, i.e. ideally -rc1. For
> > that to work for files out-of-
On Tue, Oct 2, 2018 at 3:06 PM, James Morris wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
>
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> wrote:
>> > Under the current scheme
>> >
>> > lsm.enabled=selinux
>> >
>> > could actually mean selinux,yama,loadpin,something_else are
>> > enabled.
On Wed, Oct 03, 2018 at 12:12:10AM +0200, Miguel Ojeda wrote:
> As I have read, -next is supposed to be a vision of what the merge
> window will look like after merging everything, i.e. ideally -rc1. For
> that to work for files out-of-tree (like these ones, which are not
> maintained by a single t
On 10/02/2018 03:06 PM, James Morris wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
>
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> wrote:
>>> Under the current scheme
>>>
>>> lsm.enabled=selinux
>>>
>>> could actually mean selinux,yama,loadpin,something_else are
>>> enabled. If we extend t
On 10/02/2018 04:06 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 3:06 PM, James Morris wrote:
>> On Tue, 2 Oct 2018, Kees Cook wrote:
>>
>>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>>> wrote:
Under the current scheme
lsm.enabled=selinux
could actually mean selinux
On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
wrote:
> On 10/02/2018 04:06 PM, Kees Cook wrote:
>> I think the current proposal (in the other thread) is likely the
>> sanest approach:
>>
>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>> - All e
On 10/02/2018 04:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
> wrote:
>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>> I think the current proposal (in the other thread) is likely the
>>> sanest approach:
>>>
>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>> - Drop
On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
wrote:
> On 10/02/2018 04:54 PM, Kees Cook wrote:
>> That's not how I have it currently. It's a comma-separated a string,
>> including the reserved name "all". The default would just be
>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way
On Fri, Sep 21, 2018 at 08:03:43AM -0700, Yu-cheng Yu wrote:
> WRUSS is a new kernel-mode instruction but writes directly
> to user shadow stack memory. This is used to construct
> a return address on the shadow stack for the signal
> handler.
>
> This instruction can fault if the user shadow sta
On Fri, Sep 21, 2018 at 08:03:48AM -0700, Yu-cheng Yu wrote:
> Create a guard area between VMAs, to detect memory corruption.
Do I understand correctly that with this patch a user space program
no longer be able to place two mappings back to back? If it is so,
it will likely break a lot of things;
On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov wrote:
>
> On Fri, Sep 21, 2018 at 08:03:48AM -0700, Yu-cheng Yu wrote:
> > Create a guard area between VMAs, to detect memory corruption.
>
> Do I understand correctly that with this patch a user space program
> no longer be able to place two ma
72 matches
Mail list logo
