On Mon, Jul 29, 2019 at 06:33:10PM -0700, Suren Baghdasaryan wrote:
> When a process creates a new trigger by writing into /proc/pressure/*
> files, permissions to write such a file should be used to determine whether
> the process is allowed to do so or not. Current implementation would also
> req
pon., 29 lip 2019 o 16:37 Jeremy Cline napisał(a):
>
> The shorthand [_data] and [devm_] cause the HTML documentation to not
> link to the function documentation properly. This expands the references
> to the complete function names with the exception of
> devm_gpiochip_remove() which was dropped
Some more comments. Mostly minor wording issues, except the prctl() exclusion
at the end.
On 25/07/2019 14:50, Vincenzo Frascino wrote:
On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
the userspace (EL0) is allowed to set a non-zero value in the
top byte but the resulting pointers a
Add support for TEE based trusted keys where TEE provides the functionality
to seal and unseal trusted keys using hardware unique key.
Refer to Documentation/tee.txt for detailed information about TEE.
Signed-off-by: Sumit Garg
---
include/keys/trusted-type.h | 3 +
include/keys/
Provide documentation for usage of TEE based Trusted Keys via existing
user-space "keyctl" utility. Also, document various use-cases.
Signed-off-by: Sumit Garg
---
Documentation/security/keys/index.rst | 1 +
Documentation/security/keys/tee-trusted.rst | 93 +
Enable support to register kernel memory reference with TEE. This change
will allow TEE bus drivers to register memory references.
Signed-off-by: Sumit Garg
Reviewed-by: Jarkko Sakkinen
Reviewed-by: Jens Wiklander
---
drivers/tee/tee_shm.c | 16 ++--
include/linux/tee_drv.h | 1
Add support for TEE based trusted keys where TEE provides the functionality
to seal and unseal trusted keys using hardware unique key. Also, this is
an alternative in case platform doesn't possess a TPM device.
This series also adds some TEE features like:
Patch #1, #2 enables support for registe
Kernel pages are marked as normal type memory only so allow kernel pages
to be registered as shared memory with OP-TEE.
Signed-off-by: Sumit Garg
Reviewed-by: Jarkko Sakkinen
Reviewed-by: Jens Wiklander
---
drivers/tee/optee/call.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/dri
There are use-cases where user-space shouldn't be allowed to communicate
directly with a TEE device which is dedicated to provide a specific
service for a kernel client. So add a private login method for kernel
clients and disallow user-space to open-session using GP implementation
defined login me
Add MAINTAINERS entry for TEE based Trusted Keys framework.
Signed-off-by: Sumit Garg
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ce06877..0b61ecf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8930,6 +8930,15 @@ F: include/k
…
> +++ b/drivers/base/platform.c
…
> @@ -163,6 +158,33 @@ int platform_get_irq(struct platform_device *dev,
> unsigned int num)
> return -ENXIO;
> #endif
> }
> +
> +/**
> + * platform_get_irq - get an IRQ for a device
> + * @dev: platform device
> + * @num: IRQ number index
> + *
> + * Ge
On Fri, Jul 26, 2019 at 11:23 AM Joel Fernandes (Google)
wrote:
>
> The page_idle tracking feature currently requires looking up the pagemap
> for a process followed by interacting with /sys/kernel/mm/page_idle.
> Looking up PFN from pagemap in Android devices is not supported by
> unprivileged pr
Hi Kevin,
On 7/30/19 11:32 AM, Kevin Brodsky wrote:
> Some more comments. Mostly minor wording issues, except the prctl() exclusion
> at
> the end.
>
> On 25/07/2019 14:50, Vincenzo Frascino wrote:
>> On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
>> the userspace (EL0) is allowed t
On 30/07/2019 14:25, Vincenzo Frascino wrote:
Hi Kevin,
On 7/30/19 11:32 AM, Kevin Brodsky wrote:
Some more comments. Mostly minor wording issues, except the prctl() exclusion at
the end.
On 25/07/2019 14:50, Vincenzo Frascino wrote:
On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
Hi Kevin,
On 7/30/19 2:57 PM, Kevin Brodsky wrote:
> On 30/07/2019 14:25, Vincenzo Frascino wrote:
>> Hi Kevin,
>>
>> On 7/30/19 11:32 AM, Kevin Brodsky wrote:
>>> Some more comments. Mostly minor wording issues, except the prctl()
>>> exclusion at
>>> the end.
>>>
>>> On 25/07/2019 14:50, Vincen
On 30/07/2019 15:24, Vincenzo Frascino wrote:
Hi Kevin,
On 7/30/19 2:57 PM, Kevin Brodsky wrote:
On 30/07/2019 14:25, Vincenzo Frascino wrote:
Hi Kevin,
On 7/30/19 11:32 AM, Kevin Brodsky wrote:
Some more comments. Mostly minor wording issues, except the prctl() exclusion at
the end.
On 25/
Assumption never checked, should fail if the mounter creds are not
sufficient.
Signed-off-by: Mark Salyzyn
Cc: Miklos Szeredi
Cc: Jonathan Corbet
Cc: Vivek Goyal
Cc: Eric W. Biederman
Cc: Amir Goldstein
Cc: Randy Dunlap
Cc: Stephen Smalley
Cc: linux-unio...@vger.kernel.org
Cc: linux-doc@vg
Patch series:
overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh
fs: __vfs_getxattr nesting paradigm
overlayfs: internal getxattr operations without sepolicy checking
overlayfs: override_creds=off option bypass creator_cred
The first three patches address fundamental security
Add a per-thread PF_NO_SECURITY flag that ensures that nested calls
that result in vfs_getxattr do not fall under security framework
scrutiny. Use cases include selinux when acquiring the xattr data
to evaluate security, and internal trusted xattr data soleley managed
by the filesystem drivers.
T
Check impure, opaque, origin & meta xattr with no sepolicy audit
(using __vfs_getxattr) since these operations are internal to
overlayfs operations and do not disclose any data. This became
an issue for credential override off since sys_admin would have
been required by the caller; whereas would h
By default, all access to the upper, lower and work directories is the
recorded mounter's MAC and DAC credentials. The incoming accesses are
checked against the caller's credentials.
If the principles of least privilege are applied, the mounter's
credentials might not overlap the credentials of t
On 7/26/19 2:30 PM, Mark Salyzyn wrote:
On 7/25/19 10:04 PM, Amir Goldstein wrote:
On Thu, Jul 25, 2019 at 7:22 PM Mark Salyzyn wrote:
On 7/25/19 8:43 AM, Amir Goldstein wrote:
On Thu, Jul 25, 2019 at 6:03 PM Mark Salyzyn
wrote:
On 7/24/19 10:48 PM, Amir Goldstein wrote:
On Wed, Jul 24, 201
On 7/30/19 8:55 AM, Stephen Smalley wrote:
On 7/26/19 2:30 PM, Mark Salyzyn wrote:
On 7/25/19 10:04 PM, Amir Goldstein wrote:
On Thu, Jul 25, 2019 at 7:22 PM Mark Salyzyn
wrote:
On 7/25/19 8:43 AM, Amir Goldstein wrote:
On Thu, Jul 25, 2019 at 6:03 PM Mark Salyzyn
wrote:
On 7/24/19 10:48 P
Patch series:
overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh
Add flags option to get xattr method paired to __vfs_getxattr
overlayfs: handle XATTR_NOSECURITY flag for get xattr method
overlayfs: internal getxattr operations without sepolicy checking
overlayfs: override_cred
Assumption never checked, should fail if the mounter creds are not
sufficient.
Signed-off-by: Mark Salyzyn
Cc: Miklos Szeredi
Cc: Jonathan Corbet
Cc: Vivek Goyal
Cc: Eric W. Biederman
Cc: Amir Goldstein
Cc: Randy Dunlap
Cc: Stephen Smalley
Cc: linux-unio...@vger.kernel.org
Cc: linux-doc@vg
Because of the overlayfs getxattr recursion, the incoming inode fails
to update the selinux sid resulting in avc denials being reported
against a target context of u:object_r:unlabeled:s0.
Solution is to respond to the XATTR_NOSECURITY flag in get xattr
method that calls the __vfs_getxattr handler
By default, all access to the upper, lower and work directories is the
recorded mounter's MAC and DAC credentials. The incoming accesses are
checked against the caller's credentials.
If the principles of least privilege are applied, the mounter's
credentials might not overlap the credentials of t
Check impure, opaque, origin & meta xattr with no sepolicy audit
(using __vfs_getxattr) since these operations are internal to
overlayfs operations and do not disclose any data. This became
an issue for credential override off since sys_admin would have
been required by the caller; whereas would h
On Tue, Jul 30, 2019 at 1:11 AM Peter Zijlstra wrote:
>
> On Mon, Jul 29, 2019 at 06:33:10PM -0700, Suren Baghdasaryan wrote:
> > When a process creates a new trigger by writing into /proc/pressure/*
> > files, permissions to write such a file should be used to determine whether
> > the process is
The documentation for these functions indicates that callers don't need
to hold a lock while calling them, but that documentation is only in one
place under "IDA Usage". Let's state the same information on each IDA
function so that it's clear what the calling context requires.
Furthermore, let's do
On Tue, Jul 30, 2019 at 02:07:52PM -0700, Stephen Boyd wrote:
> The documentation for these functions indicates that callers don't need
> to hold a lock while calling them, but that documentation is only in one
> place under "IDA Usage". Let's state the same information on each IDA
> function so th
Quoting Matthew Wilcox (2019-07-30 14:12:50)
> On Tue, Jul 30, 2019 at 02:07:52PM -0700, Stephen Boyd wrote:
> > The documentation for these functions indicates that callers don't need
> > to hold a lock while calling them, but that documentation is only in one
> > place under "IDA Usage". Let's st
The documentation for these functions indicates that callers don't need
to hold a lock while calling them, but that documentation is only in one
place under "IDA Usage". Let's state the same information on each IDA
function so that it's clear what the calling context requires.
Furthermore, let's do
These two functions are deprecated. Users should call ida_alloc() or
ida_free() respectively instead. Add documentation to this effect until
the macro can be removed.
Cc: Greg KH
Cc: Tri Vo
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Stephen Boyd
---
include/linux/idr.h |
On Fri, Jul 26, 2019 at 09:51:35AM -0300, Mauro Carvalho Chehab wrote:
> There are 4 RCU articles that are written on html format.
>
> The way they are, they can't be part of the Linux Kernel
> documentation body nor share the styles and pdf output.
>
> So, convert them to ReST format.
>
> This
On 7/30/2019 10:28 AM, Mark Salyzyn wrote:
> Patch series:
Please add linux-security-mod...@vger.kernel.org to the CC
for all changes affecting handling of security xattrs.
>
> overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh
> Add flags option to get xattr method paired to
On Tue, Jul 30, 2019 at 02:22:50PM -0700, Paul E. McKenney wrote:
> On Fri, Jul 26, 2019 at 09:51:35AM -0300, Mauro Carvalho Chehab wrote:
> > There are 4 RCU articles that are written on html format.
> >
> > The way they are, they can't be part of the Linux Kernel
> > documentation body nor share
Em Tue, 30 Jul 2019 14:22:50 -0700
"Paul E. McKenney" escreveu:
> On Fri, Jul 26, 2019 at 09:51:35AM -0300, Mauro Carvalho Chehab wrote:
> > There are 4 RCU articles that are written on html format.
> >
> > The way they are, they can't be part of the Linux Kernel
> > documentation body nor share
Em Tue, 30 Jul 2019 17:50:07 -0400
Joel Fernandes escreveu:
> On Tue, Jul 30, 2019 at 02:22:50PM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 26, 2019 at 09:51:35AM -0300, Mauro Carvalho Chehab wrote:
> > > There are 4 RCU articles that are written on html format.
> > >
> > > The way they ar
On Fri, Jul 26, 2019 at 04:14:05PM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 26 Jul 2019 14:02:01 -0400
> Joel Fernandes escreveu:
>
> > On Fri, Jul 26, 2019 at 09:51:35AM -0300, Mauro Carvalho Chehab wrote:
> > [snip]
> > > +| until the assignment to ``gp``, by which time both fields are ful
On Sat, Jul 27, 2019 at 12:37:54PM -0300, Mauro Carvalho Chehab wrote:
> Em Sat, 27 Jul 2019 14:14:53 +
> Joel Fernandes escreveu:
>
> > On Fri, Jul 26, 2019 at 04:01:37PM -0300, Mauro Carvalho Chehab wrote:
> > > The books at tools/memory-model/Documentation are very well
> > > formatted. Co
On Tue, Jul 30, 2019 at 07:00:28PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 30 Jul 2019 17:50:07 -0400
> Joel Fernandes escreveu:
>
> > On Tue, Jul 30, 2019 at 02:22:50PM -0700, Paul E. McKenney wrote:
> > > On Fri, Jul 26, 2019 at 09:51:35AM -0300, Mauro Carvalho Chehab wrote:
> > > > The
Em Tue, 30 Jul 2019 18:17:01 -0400
Joel Fernandes escreveu:
> On Sat, Jul 27, 2019 at 12:37:54PM -0300, Mauro Carvalho Chehab wrote:
> > Em Sat, 27 Jul 2019 14:14:53 +
> > Joel Fernandes escreveu:
> >
> > > On Fri, Jul 26, 2019 at 04:01:37PM -0300, Mauro Carvalho Chehab wrote:
> > > > T
Em Tue, 30 Jul 2019 18:21:30 -0400
Joel Fernandes escreveu:
> On Tue, Jul 30, 2019 at 07:00:28PM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 30 Jul 2019 17:50:07 -0400
> > Joel Fernandes escreveu:
> >
> > > On Tue, Jul 30, 2019 at 02:22:50PM -0700, Paul E. McKenney wrote:
> > > > On Fri
This patch is a respin of the RCU ReST patch from Mauro [1].
I updated his changelog, and made some fixes.
[1] https://www.spinics.net/lists/rcu/msg00750.html
Joel Fernandes (Google) (2):
docs: rcu: Correct links referring to titles
docs: rcu: Increase toctree to 3
Mauro Carvalho Chehab (1):
do
Mauro's auto conversion broken these links, fix them.
Signed-off-by: Joel Fernandes (Google)
---
.../Tree-RCU-Memory-Ordering.rst | 17 ++--
.../RCU/Design/Requirements/Requirements.rst | 90 ---
2 files changed, 47 insertions(+), 60 deletions(-)
diff --git
a/Docu
These documents are long and have various sections. Provide a good
toc nesting level.
Signed-off-by: Joel Fernandes (Google)
---
Documentation/RCU/index.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RCU/index.rst b/Documentation/RCU/index.rst
index 94427dc
On Tue, Jul 30, 2019 at 08:00:57PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 30 Jul 2019 18:21:30 -0400
> Joel Fernandes escreveu:
>
> > On Tue, Jul 30, 2019 at 07:00:28PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Tue, 30 Jul 2019 17:50:07 -0400
> > > Joel Fernandes escreveu:
> > >
> >
On Tue, Jul 30, 2019 at 06:50:51PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 30 Jul 2019 14:22:50 -0700
> "Paul E. McKenney" escreveu:
>
> > On Fri, Jul 26, 2019 at 09:51:35AM -0300, Mauro Carvalho Chehab wrote:
> > > There are 4 RCU articles that are written on html format.
> > >
> > > The
Em Tue, 30 Jul 2019 19:10:29 -0400
"Joel Fernandes (Google)" escreveu:
> Mauro's auto conversion broken these links, fix them.
They actually worked here with the Sphinx I used, but yeah, the way it
is is a way cleaner.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
> .../Tree-RCU-Memory-Or
Em Tue, 30 Jul 2019 19:10:30 -0400
"Joel Fernandes (Google)" escreveu:
> These documents are long and have various sections. Provide a good
> toc nesting level.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
> Documentation/RCU/index.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On Tue, Jul 30, 2019 at 04:37:20PM -0700, Paul E. McKenney wrote:
> On Tue, Jul 30, 2019 at 06:50:51PM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 30 Jul 2019 14:22:50 -0700
> > "Paul E. McKenney" escreveu:
> >
> > > On Fri, Jul 26, 2019 at 09:51:35AM -0300, Mauro Carvalho Chehab wrote:
> > >
Em Tue, 30 Jul 2019 17:04:55 -0700
"Paul E. McKenney" escreveu:
> On Tue, Jul 30, 2019 at 04:37:20PM -0700, Paul E. McKenney wrote:
> > On Tue, Jul 30, 2019 at 06:50:51PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Tue, 30 Jul 2019 14:22:50 -0700
> > > "Paul E. McKenney" escreveu:
> > >
>
On Tue, Jul 30, 2019 at 09:47:22PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 30 Jul 2019 17:04:55 -0700
> "Paul E. McKenney" escreveu:
>
> > On Tue, Jul 30, 2019 at 04:37:20PM -0700, Paul E. McKenney wrote:
> > > On Tue, Jul 30, 2019 at 06:50:51PM -0300, Mauro Carvalho Chehab wrote:
> > > >
Em Tue, 30 Jul 2019 18:06:24 -0700
"Paul E. McKenney" escreveu:
> On Tue, Jul 30, 2019 at 09:47:22PM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 30 Jul 2019 17:04:55 -0700
> > "Paul E. McKenney" escreveu:
> > > This appears to come from Documentation/output/latex/RCU.tex.
> > > There is nev
On Fri, Jul 26, 2019 at 11:23:19AM -0400, Joel Fernandes (Google) wrote:
> This patch updates the documentation with the new page_idle tracking
> feature which uses virtual address indexing.
>
> Signed-off-by: Joel Fernandes (Google)
One nit below, otherwise
Reviewed-by: Mike Rapoport
> ---
>
56 matches
Mail list logo
