* Re: [PATCH 00/43] Convert doc files to ReST
From: Geert Uytterhoeven @ 2019-07-29 9:50 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
Linux Kernel Mailing List, Jonathan Corbet, Linux-Renesas
In-Reply-To: <cover.1561723979.git.mchehab+samsung@kernel.org>
Hi Mauro,
On Fri, Jun 28, 2019 at 2:25 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> This patchset contains the patches that weren't merged yet from
> part 2 and 3 of the previous ReST conversion patchset.
>
> This is based aganst linux-next (next-20190627), so they may not
> apply cleanly at docs-next.
>
> It does contain file renames, but, except for a few exceptions, the files
> are kept where they are.
>
> The first patches on this series were agreed to be merged via subsystem's
> tree, but, as they didn't appear at -next, I'm recending as a gentile
> ping.
[...]
> .../arm/{SH-Mobile => sh-mobile}/.gitignore | 0
I guess that should have been "shmobile^H^H^H^H^H^H^H^Hrenesas",
for consistency with modern naming?
For whatever it's worth keeping empty subdirectories, of course,
containing just an obsolete .gitignore file...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 0/2] Add CCPI2 PMU support
From: Ganapatrao Kulkarni @ 2019-07-29 10:54 UTC (permalink / raw)
To: Ganapatrao Kulkarni, will@kernel.org
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
corbet@lwn.net, Jayachandran Chandrasekharan Nair, Robert Richter,
Jan Glauber
In-Reply-To: <1563873380-2003-1-git-send-email-gkulkarni@marvell.com>
Hi Will,
Any comments to this patchset?
On Tue, Jul 23, 2019 at 2:46 PM Ganapatrao Kulkarni
<gkulkarni@marvell.com> wrote:
>
> Add Cavium Coherent Processor Interconnect (CCPI2) PMU
> support in ThunderX2 Uncore driver.
>
> v3: Rebased to 5.3-rc1
>
> v2: Updated with review comments [1]
>
> [1] https://lkml.org/lkml/2019/6/14/965
>
> v1: initial patch
>
> Ganapatrao Kulkarni (2):
> Documentation: perf: Update documentation for ThunderX2 PMU uncore
> driver
> drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
>
> .../admin-guide/perf/thunderx2-pmu.rst | 20 +-
> drivers/perf/thunderx2_pmu.c | 248 +++++++++++++++---
> 2 files changed, 225 insertions(+), 43 deletions(-)
>
> --
> 2.17.1
>
Thanks,
Ganapat
^ permalink raw reply
* Re: [RFC 3/7] tee: add private login method for kernel clients
From: Sumit Garg @ 2019-07-29 13:13 UTC (permalink / raw)
To: Jens Wiklander
Cc: keyrings, linux-integrity, linux-security-module, Jonathan Corbet,
dhowells, jejb, Jarkko Sakkinen, Mimi Zohar, jmorris, serge,
Ard Biesheuvel, Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, tee-dev @ lists . linaro . org
In-Reply-To: <CAHUa44GBt-8Z8ZniTraJYHgFVEUgMTjTJLEden3m2jhhY9qc-w@mail.gmail.com>
On Mon, 29 Jul 2019 at 12:39, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>
> Hi Sumit,
>
> On Tue, Jul 9, 2019 at 11:36 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > On Tue, 9 Jul 2019 at 12:33, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > >
> > > On Tue, Jul 09, 2019 at 11:26:19AM +0530, Sumit Garg wrote:
> > > > Thanks Jens for your comments.
> > > >
> > > > On Mon, 8 Jul 2019 at 21:09, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > > > >
> > > > > Hi Sumit,
> > > > >
> > > > > On Thu, Jun 13, 2019 at 04:00:29PM +0530, Sumit Garg wrote:
> > > > > > 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 this login method.
> > > > > >
> > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > ---
> > > > > > drivers/tee/tee_core.c | 6 ++++++
> > > > > > include/uapi/linux/tee.h | 2 ++
> > > > > > 2 files changed, 8 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > > > > > index 0f16d9f..4581bd1 100644
> > > > > > --- a/drivers/tee/tee_core.c
> > > > > > +++ b/drivers/tee/tee_core.c
> > > > > > @@ -334,6 +334,12 @@ static int tee_ioctl_open_session(struct tee_context *ctx,
> > > > > > goto out;
> > > > > > }
> > > > > >
> > > > > > + if (arg.clnt_login == TEE_IOCTL_LOGIN_REE_KERNEL) {
> > > > > TEE_IOCTL_LOGIN_REE_KERNEL is defined as 0x80000000 which is in the
> > > > > range specified and implementation defined by the GP spec. I wonder if
> > > > > we shouldn't filter the entire implementation defined range instead of
> > > > > just this value.
> > > >
> > > > Agree. Will rather check for entire implementation defined range:
> > > > 0x80000000 - 0xFFFFFFFF.
> > > >
> >
> > I had a second thought on this. It would be more restrictive for
> > user-space TEE client library which may need to use implementation
> > defined login method. So either we could define specific ranges for
> > kernel and user-space or we can start with single login method
> > reserved for kernel.
>
> I think we should reserve a range for kernel internal use. Only
> reserving a single single login for kernel could force us to restrict
> the API once more later, better to take a chunk now and be done with
> it. Half of 0x80000000 - 0xFFFFFFFF is probably more than enough too
> to leave a range for user space too.
>
Ok then, will rather reserve this range for kernel.
> >
> > > > >
> > > > > > + pr_err("login method not allowed for user-space client\n");
> > > > > pr_debug(), if it's needed at all.
> > > > >
> > > >
> > > > Ok will use pr_debug() instead.
> > > >
> > > > > > + rc = -EPERM;
> > > > > > + goto out;
> > > > > > + }
> > > > > > +
> > > > > > rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params);
> > > > > > if (rc)
> > > > > > goto out;
> > > > > > diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
> > > > > > index 4b9eb06..f33c69c 100644
> > > > > > --- a/include/uapi/linux/tee.h
> > > > > > +++ b/include/uapi/linux/tee.h
> > > > > > @@ -172,6 +172,8 @@ struct tee_ioctl_buf_data {
> > > > > > #define TEE_IOCTL_LOGIN_APPLICATION 4
> > > > > > #define TEE_IOCTL_LOGIN_USER_APPLICATION 5
> > > > > > #define TEE_IOCTL_LOGIN_GROUP_APPLICATION 6
> > > > > > +/* Private login method for REE kernel clients */
> > > > > It's worth noting that this is filtered by the TEE framework, compared
> > > > > to everything else which is treated opaquely.
> > > > >
> > > >
> > > > IIUC, you are referring to login filter in optee_os. Change to prevent
> > > > filter for this login method is part of this PR [1].
> > > >
> > > > [1] https://github.com/OP-TEE/optee_os/pull/3082
> > >
> > > No, I was referring to the changes in tee_ioctl_open_session() above.
> > > It's relevant for user space to know since it will be prevented from
> > > using that range of login identifiers.
> >
> > Ok, so you mean to extend the comment here for user-space to know that
> > this login method/range is filtered by the TEE framework. Will do
> > that.
> >
> > > This will restrict the user space
> > > API, but I think the risk of breakage is minimal as OP-TEE is the only
> > > in-tree driver registering in the TEE framework. I'm not aware of any
> > > out-of-tree drivers registering.
> >
> > I am not sure if I follow you here. How do you expect this change to
> > break out-of-tree TEE driver registration?
>
> It's a change in common code that put restrictions on the API.
>
Okay.
-Sumit
> Thanks,
> Jens
>
>
> >
> > -Sumit
> >
> > >
> > > Thanks,
> > > Jens
> > >
> > > >
> > > > -Sumit
> > > >
> > > > > > +#define TEE_IOCTL_LOGIN_REE_KERNEL 0x80000000
> > > > > >
> > > > > > /**
> > > > > > * struct tee_ioctl_param - parameter
> > > > > > --
> > > > > > 2.7.4
> > > > > >
> > > > >
> > > > > Thanks,
> > > > > Jens
^ permalink raw reply
* Re: [PATCH] Documentation: move Documentation/virtual to Documentation/virt
From: Jonathan Corbet @ 2019-07-29 13:55 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Christoph Hellwig, rkrcmar, jdike, richard, anton.ivanov,
linux-doc, kvm, linux-um, linux-kernel
In-Reply-To: <be4ba4a7-a21b-8c56-4517-8886a754ff55@redhat.com>
On Sat, 27 Jul 2019 00:10:32 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:
> Does the userspace API
> cover only syscall or perhaps sysfs interfaces? There are more API
> files (amd-memory-encryption.txt, cpuid.txt, halt-polling.txt msr.txt,
> ppc-pv.txt, s390-diag.txt) but, with the exception of
> amd-memory-encryption.txt and halt-polling.txt, they cover the
> emulated-hardware interfaces that KVM provides to virtual machines.
The user-space API certainly goes beyond system calls. For sysfs, I
guess, the question would be whether a given knob is something that an
application would use (userspace-api) or something that a sysadmin would
want to tweak (admin-guide).
Thanks,
jon
^ permalink raw reply
* [PATCH v2] Documentation: gpio: fix function links in the HTML docs
From: Jeremy Cline @ 2019-07-29 14:37 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Jonathan Corbet, linux-gpio, linux-doc,
linux-kernel, Jeremy Cline
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 by commit 48207d7595d2 ("gpio:
drop devm_gpiochip_remove()").
Signed-off-by: Jeremy Cline <jcline@redhat.com>
---
New in v2:
- Rebased onto v5.3-rc2
Documentation/driver-api/gpio/driver.rst | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst
index 921c71a3d683..906af220b164 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -69,9 +69,9 @@ driver code:
The code implementing a gpio_chip should support multiple instances of the
controller, preferably using the driver model. That code will configure each
-gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
-Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
-when it is unavoidable.
+gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or
+devm_gpiochip_add_data(). Removing a GPIO controller should be rare; use
+gpiochip_remove() when it is unavoidable.
Often a gpio_chip is part of an instance-specific structure with states not
exposed by the GPIO interfaces, such as addressing, power management, and more.
@@ -418,11 +418,11 @@ symbol:
If there is a need to exclude certain GPIO lines from the IRQ domain handled by
these helpers, we can set .irq.need_valid_mask of the gpiochip before
-``[devm_]gpiochip_add_data()`` is called. This allocates an .irq.valid_mask with as
-many bits set as there are GPIO lines in the chip, each bit representing line
-0..n-1. Drivers can exclude GPIO lines by clearing bits from this mask. The mask
-must be filled in before gpiochip_irqchip_add() or gpiochip_irqchip_add_nested()
-is called.
+devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
+.irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
+bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
+from this mask. The mask must be filled in before gpiochip_irqchip_add() or
+gpiochip_irqchip_add_nested() is called.
To use the helpers please keep the following in mind:
--
2.21.0
^ permalink raw reply related
* Re: [f2fs-dev] [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Chao Yu @ 2019-07-29 14:57 UTC (permalink / raw)
To: Chao Yu, Jaegeuk Kim
Cc: Daniel Rosenberg, Jonathan Corbet, linux-f2fs-devel, linux-doc,
linux-api, linux-kernel, linux-fsdevel, kernel-team
In-Reply-To: <fa07a09d-92c9-4e0b-7c2b-e87771273dce@huawei.com>
On 2019-7-29 15:22, Chao Yu wrote:
> On 2019/7/29 14:27, Jaegeuk Kim wrote:
>> On 07/28, Chao Yu wrote:
>>> On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
>>>> /* Flags that are appropriate for regular files (all but dir-specific ones). */
>>>> #define F2FS_REG_FLMASK (~(F2FS_DIRSYNC_FL | F2FS_PROJINHERIT_FL))
>>>
>>> We missed to add F2FS_CASEFOLD_FL here to exclude it in F2FS_REG_FLMASK.
>>
>> Applied.
>>
>>>
>>>> @@ -1660,7 +1660,16 @@ static int f2fs_setflags_common(struct inode *inode, u32 iflags, u32 mask)
>>>> return -EPERM;
>>>>
>>>> oldflags = fi->i_flags;
>>>> + if ((iflags ^ oldflags) & F2FS_CASEFOLD_FL) {
>>>> + if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
>>>> + return -EOPNOTSUPP;
>>>> +
>>>> + if (!S_ISDIR(inode->i_mode))
>>>> + return -ENOTDIR;
>>>>
>>>> + if (!f2fs_empty_dir(inode))
>>>> + return -ENOTEMPTY;
>>>> + }
>>
>> Modified like this:
>> @@ -1665,6 +1665,13 @@ static int f2fs_setflags_common(struct inode *inode, u32 iflags, u32 mask)
>> if (IS_NOQUOTA(inode))
>> return -EPERM;
>>
>> + if ((iflags ^ fi->i_flags) & F2FS_CASEFOLD_FL) {
>> + if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
>> + return -EOPNOTSUPP;
>> + if (!f2fs_empty_dir(inode))
>> + return -ENOTEMPTY;
>> + }
>> +
>>
>> Note that, directory is checked by above change.
>>
>> I've uploaded in f2fs.git, so could you check it out and test a bit?
>
> I've checked it out, it looks good to me now, and later I will test this new
> version.
>
> Reviewed-by: Chao Yu <yuchao0@huawei.com>
It can pass generic/556 as well.
Thanks,
>
> Thanks,
>
>>
>> Thanks,
>>
>>>
>>> I applied the patches based on last Jaegeuk's dev branch, it seems we needs to
>>> adjust above code a bit. Otherwise it looks good to me.
>>>
>>> BTW, it looks the patchset works fine with generic/556 testcase.
>>>
>>> Thanks,
>> .
>>
^ permalink raw reply
* Re: [EXTERNAL][PATCH v15 04/13] mfd/syscon: Add device_node_to_regmap()
From: Paul Burton @ 2019-07-29 16:55 UTC (permalink / raw)
To: Paul Cercueil, Lee Jones, Arnd Bergmann
Cc: Ralf Baechle, James Hogan, Jonathan Corbet, Daniel Lezcano,
Thomas Gleixner, Michael Turquette, Stephen Boyd, Jason Cooper,
Marc Zyngier, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-mips@vger.kernel.org,
linux-clk@vger.kernel.org, od@zcrc.me, Mathieu Malaterre
In-Reply-To: <20190724171615.20774-5-paul@crapouillou.net>
Lee, Arnd,
On Wed, Jul 24, 2019 at 01:16:06PM -0400, Paul Cercueil wrote:
> device_node_to_regmap() is exactly like syscon_node_to_regmap(), but it
> does not check that the node is compatible with "syscon", and won't
> attach the first clock it finds to the regmap.
>
> The rationale behind this, is that one device node with a standard
> compatible string "foo,bar" can be covered by multiple drivers sharing a
> regmap, or by a single driver doing all the job without a regmap, but
> these are implementation details which shouldn't reflect on the
> devicetree.
Does this looks like a good path forwards to you? Its use in this case
is described by Documentation/devicetree/bindings/timer/ingenic,tcu.txt
in patch 3 of the series.
If you're OK with it an ack would be appreciated so I can take the
series through mips-next, otherwise I guess we'd need to go back to the
v14 approach.
Thanks,
Paul
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v15: New patch
>
> drivers/mfd/syscon.c | 46 +++++++++++++++++++++++++-------------
> include/linux/mfd/syscon.h | 6 +++++
> 2 files changed, 36 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index b65e585fc8c6..660723276481 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -40,7 +40,7 @@ static const struct regmap_config syscon_regmap_config = {
> .reg_stride = 4,
> };
>
> -static struct syscon *of_syscon_register(struct device_node *np)
> +static struct syscon *of_syscon_register(struct device_node *np, bool check_clk)
> {
> struct clk *clk;
> struct syscon *syscon;
> @@ -51,9 +51,6 @@ static struct syscon *of_syscon_register(struct device_node *np)
> struct regmap_config syscon_config = syscon_regmap_config;
> struct resource res;
>
> - if (!of_device_is_compatible(np, "syscon"))
> - return ERR_PTR(-EINVAL);
> -
> syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> if (!syscon)
> return ERR_PTR(-ENOMEM);
> @@ -117,16 +114,18 @@ static struct syscon *of_syscon_register(struct device_node *np)
> goto err_regmap;
> }
>
> - clk = of_clk_get(np, 0);
> - if (IS_ERR(clk)) {
> - ret = PTR_ERR(clk);
> - /* clock is optional */
> - if (ret != -ENOENT)
> - goto err_clk;
> - } else {
> - ret = regmap_mmio_attach_clk(regmap, clk);
> - if (ret)
> - goto err_attach;
> + if (check_clk) {
> + clk = of_clk_get(np, 0);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + /* clock is optional */
> + if (ret != -ENOENT)
> + goto err_clk;
> + } else {
> + ret = regmap_mmio_attach_clk(regmap, clk);
> + if (ret)
> + goto err_attach;
> + }
> }
>
> syscon->regmap = regmap;
> @@ -150,7 +149,8 @@ static struct syscon *of_syscon_register(struct device_node *np)
> return ERR_PTR(ret);
> }
>
> -struct regmap *syscon_node_to_regmap(struct device_node *np)
> +static struct regmap *device_node_get_regmap(struct device_node *np,
> + bool check_clk)
> {
> struct syscon *entry, *syscon = NULL;
>
> @@ -165,13 +165,27 @@ struct regmap *syscon_node_to_regmap(struct device_node *np)
> spin_unlock(&syscon_list_slock);
>
> if (!syscon)
> - syscon = of_syscon_register(np);
> + syscon = of_syscon_register(np, check_clk);
>
> if (IS_ERR(syscon))
> return ERR_CAST(syscon);
>
> return syscon->regmap;
> }
> +
> +struct regmap *device_node_to_regmap(struct device_node *np)
> +{
> + return device_node_get_regmap(np, false);
> +}
> +EXPORT_SYMBOL_GPL(device_node_to_regmap);
> +
> +struct regmap *syscon_node_to_regmap(struct device_node *np)
> +{
> + if (!of_device_is_compatible(np, "syscon"))
> + return ERR_PTR(-EINVAL);
> +
> + return device_node_get_regmap(np, true);
> +}
> EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
>
> struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
> diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
> index 8cfda0554381..112dc66262cc 100644
> --- a/include/linux/mfd/syscon.h
> +++ b/include/linux/mfd/syscon.h
> @@ -17,12 +17,18 @@
> struct device_node;
>
> #ifdef CONFIG_MFD_SYSCON
> +extern struct regmap *device_node_to_regmap(struct device_node *np);
> extern struct regmap *syscon_node_to_regmap(struct device_node *np);
> extern struct regmap *syscon_regmap_lookup_by_compatible(const char *s);
> extern struct regmap *syscon_regmap_lookup_by_phandle(
> struct device_node *np,
> const char *property);
> #else
> +static inline struct regmap *device_node_to_regmap(struct device_node *np)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
> +
> static inline struct regmap *syscon_node_to_regmap(struct device_node *np)
> {
> return ERR_PTR(-ENOTSUPP);
> --
> 2.21.0.593.g511ec345e18
>
^ permalink raw reply
* [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Suren Baghdasaryan @ 2019-07-29 19:42 UTC (permalink / raw)
To: gregkh
Cc: lizefan, hannes, axboe, dennis, dennisszhou, mingo, peterz, akpm,
linux-mm, linux-doc, linux-kernel, kernel-team,
Suren Baghdasaryan, Nick Kralevich
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
require such a process to have setsched capability. Setting of psi trigger
thread's scheduling policy is an implementation detail and should not be
exposed to the user level. Remove the permission check by using _nocheck
version of the function.
Suggested-by: Nick Kralevich <nnk@google.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
kernel/sched/psi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7acc632c3b82..ed9a1d573cb1 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1061,7 +1061,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group *group,
mutex_unlock(&group->trigger_lock);
return ERR_CAST(kworker);
}
- sched_setscheduler(kworker->task, SCHED_FIFO, ¶m);
+ sched_setscheduler_nocheck(kworker->task, SCHED_FIFO, ¶m);
kthread_init_delayed_work(&group->poll_work,
psi_poll_work);
rcu_assign_pointer(group->poll_kworker, kworker);
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related
* Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Greg KH @ 2019-07-29 19:56 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: lizefan, hannes, axboe, dennis, dennisszhou, mingo, peterz, akpm,
linux-mm, linux-doc, linux-kernel, kernel-team, Nick Kralevich
In-Reply-To: <20190729194205.212846-1-surenb@google.com>
On Mon, Jul 29, 2019 at 12:42:05PM -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
> require such a process to have setsched capability. Setting of psi trigger
> thread's scheduling policy is an implementation detail and should not be
> exposed to the user level. Remove the permission check by using _nocheck
> version of the function.
>
> Suggested-by: Nick Kralevich <nnk@google.com>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> ---
> kernel/sched/psi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
$ ./scripts/get_maintainer.pl --file kernel/sched/psi.c
Ingo Molnar <mingo@redhat.com> (maintainer:SCHEDULER)
Peter Zijlstra <peterz@infradead.org> (maintainer:SCHEDULER)
linux-kernel@vger.kernel.org (open list:SCHEDULER)
No where am I listed there, so why did you send this "To:" me?
please fix up and resend.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Suren Baghdasaryan @ 2019-07-29 20:11 UTC (permalink / raw)
To: Greg KH
Cc: lizefan, Johannes Weiner, axboe, Dennis Zhou, Dennis Zhou,
Ingo Molnar, Peter Zijlstra, Andrew Morton, linux-mm, linux-doc,
LKML, kernel-team, Nick Kralevich
In-Reply-To: <20190729195614.GA31529@kroah.com>
On Mon, Jul 29, 2019 at 12:57 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Jul 29, 2019 at 12:42:05PM -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
> > require such a process to have setsched capability. Setting of psi trigger
> > thread's scheduling policy is an implementation detail and should not be
> > exposed to the user level. Remove the permission check by using _nocheck
> > version of the function.
> >
> > Suggested-by: Nick Kralevich <nnk@google.com>
> > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > ---
> > kernel/sched/psi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> $ ./scripts/get_maintainer.pl --file kernel/sched/psi.c
> Ingo Molnar <mingo@redhat.com> (maintainer:SCHEDULER)
> Peter Zijlstra <peterz@infradead.org> (maintainer:SCHEDULER)
> linux-kernel@vger.kernel.org (open list:SCHEDULER)
>
>
> No where am I listed there, so why did you send this "To:" me?
>
Oh, sorry about that. Both Ingo and Peter are CC'ed directly. Should I
still resend?
> please fix up and resend.
>
> greg k-h
^ permalink raw reply
* [PATCH] doc:it_IT: align translation to mainline
From: Federico Vaga @ 2019-07-29 21:58 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, Federico Vaga, Alessia Mantegazza
The patch translates the following patches in Italian:
1fb12b35e5ff kbuild: Raise the minimum required binutils version to 2.21
9c3c0c204814 isdn: remove isdn4linux
Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
---
.../translations/it_IT/process/changes.rst | 22 ++++---------------
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst
index d0874327f301..94a6499742ac 100644
--- a/Documentation/translations/it_IT/process/changes.rst
+++ b/Documentation/translations/it_IT/process/changes.rst
@@ -26,16 +26,15 @@ Prima di pensare d'avere trovato un baco, aggiornate i seguenti programmi
usando, il comando indicato dovrebbe dirvelo.
Questa lista presume che abbiate già un kernel Linux funzionante. In aggiunta,
-non tutti gli strumenti sono necessari ovunque; ovviamente, se non avete un
-modem ISDN, per esempio, probabilmente non dovreste preoccuparvi di
-isdn4k-utils.
+non tutti gli strumenti sono necessari ovunque; ovviamente, se non avete una
+PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils.
====================== ================= ========================================
Programma Versione minima Comando per verificare la versione
====================== ================= ========================================
GNU C 4.6 gcc --version
GNU make 3.81 make --version
-binutils 2.20 ld -v
+binutils 2.21 ld -v
flex 2.5.35 flex --version
bison 2.0 bison --version
util-linux 2.10o fdformat --version
@@ -49,7 +48,6 @@ btrfs-progs 0.18 btrfsck
pcmciautils 004 pccardctl -V
quota-tools 3.09 quota -V
PPP 2.4.0 pppd --version
-isdn4k-utils 3.1pre1 isdnctrl 2>&1|grep version
nfs-utils 1.0.5 showmount --version
procps 3.2.0 ps --version
oprofile 0.9 oprofiled --version
@@ -81,10 +79,7 @@ Per compilare il kernel vi servirà GNU make 3.81 o successivo.
Binutils
--------
-Il sistema di compilazione, dalla versione 4.13, per la produzione dei passi
-intermedi, si è convertito all'uso di *thin archive* (`ar T`) piuttosto che
-all'uso del *linking* incrementale (`ld -r`). Questo richiede binutils 2.20 o
-successivo.
+Per generare il kernel è necessario avere Binutils 2.21 o superiore.
pkg-config
----------
@@ -286,11 +281,6 @@ col seguente comando::
mknod /dev/ppp c 108 0
-Isdn4k-utils
-------------
-
-Per via della modifica del campo per il numero di telefono, il pacchetto
-isdn4k-utils dev'essere ricompilato o (preferibilmente) aggiornato.
NFS-utils
---------
@@ -456,10 +446,6 @@ PPP
- <ftp://ftp.samba.org/pub/ppp/>
-Isdn4k-utils
-------------
-
-- <ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/>
NFS-utils
---------
--
2.21.0
^ permalink raw reply related
* [PATCH v8 3/7] of/platform: Add functional dependency link from DT bindings
From: Saravana Kannan @ 2019-07-29 22:10 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki,
Frank Rowand, Jonathan Corbet
Cc: Saravana Kannan, devicetree, linux-kernel, David Collins,
kernel-team, linux-doc
In-Reply-To: <20190729221101.228240-1-saravanak@google.com>
Add device-links after the devices are created (but before they are
probed) by looking at common DT bindings like clocks and
interconnects.
Automatically adding device-links for functional dependencies at the
framework level provides the following benefits:
- Optimizes device probe order and avoids the useless work of
attempting probes of devices that will not probe successfully
(because their suppliers aren't present or haven't probed yet).
For example, in a commonly available mobile SoC, registering just
one consumer device's driver at an initcall level earlier than the
supplier device's driver causes 11 failed probe attempts before the
consumer device probes successfully. This was with a kernel with all
the drivers statically compiled in. This problem gets a lot worse if
all the drivers are loaded as modules without direct symbol
dependencies.
- Supplier devices like clock providers, interconnect providers, etc
need to keep the resources they provide active and at a particular
state(s) during boot up even if their current set of consumers don't
request the resource to be active. This is because the rest of the
consumers might not have probed yet and turning off the resource
before all the consumers have probed could lead to a hang or
undesired user experience.
Some frameworks (Eg: regulator) handle this today by turning off
"unused" resources at late_initcall_sync and hoping all the devices
have probed by then. This is not a valid assumption for systems with
loadable modules. Other frameworks (Eg: clock) just don't handle
this due to the lack of a clear signal for when they can turn off
resources. This leads to downstream hacks to handle cases like this
that can easily be solved in the upstream kernel.
By linking devices before they are probed, we give suppliers a clear
count of the number of dependent consumers. Once all of the
consumers are active, the suppliers can turn off the unused
resources without making assumptions about the number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
devices to change the link when they probe.
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
.../admin-guide/kernel-parameters.txt | 5 +
drivers/of/platform.c | 165 ++++++++++++++++++
2 files changed, 170 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7ccd158b3894..dba3200d3516 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3170,6 +3170,11 @@
This can be set from sysctl after boot.
See Documentation/admin-guide/sysctl/vm.rst for details.
+ of_devlink [KNL] Make device links from common DT bindings. Useful
+ for optimizing probe order and making sure resources
+ aren't turned off before the consumer devices have
+ probed.
+
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
See Documentation/debugging-via-ohci1394.txt for more
info.
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7801e25e6895..4344419a26fc 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -508,6 +508,170 @@ int of_platform_default_populate(struct device_node *root,
}
EXPORT_SYMBOL_GPL(of_platform_default_populate);
+bool of_link_is_valid(struct device_node *con, struct device_node *sup)
+{
+ of_node_get(sup);
+ /*
+ * Don't allow linking a device node as a consumer of one of its
+ * descendant nodes. By definition, a child node can't be a functional
+ * dependency for the parent node.
+ */
+ while (sup) {
+ if (sup == con) {
+ of_node_put(sup);
+ return false;
+ }
+ sup = of_get_next_parent(sup);
+ }
+ return true;
+}
+
+static int of_link_to_phandle(struct device *dev, struct device_node *sup_np)
+{
+ struct platform_device *sup_dev;
+ u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
+ int ret = 0;
+
+ /*
+ * Since we are trying to create device links, we need to find
+ * the actual device node that owns this supplier phandle.
+ * Often times it's the same node, but sometimes it can be one
+ * of the parents. So walk up the parent till you find a
+ * device.
+ */
+ while (sup_np && !of_find_property(sup_np, "compatible", NULL))
+ sup_np = of_get_next_parent(sup_np);
+ if (!sup_np)
+ return 0;
+
+ if (!of_link_is_valid(dev->of_node, sup_np)) {
+ of_node_put(sup_np);
+ return 0;
+ }
+ sup_dev = of_find_device_by_node(sup_np);
+ of_node_put(sup_np);
+ if (!sup_dev)
+ return -ENODEV;
+ if (!device_link_add(dev, &sup_dev->dev, dl_flags))
+ ret = -ENODEV;
+ put_device(&sup_dev->dev);
+ return ret;
+}
+
+static struct device_node *parse_prop_cells(struct device_node *np,
+ const char *prop, int index,
+ const char *binding,
+ const char *cell)
+{
+ struct of_phandle_args sup_args;
+
+ /* Don't need to check property name for every index. */
+ if (!index && strcmp(prop, binding))
+ return NULL;
+
+ if (of_parse_phandle_with_args(np, binding, cell, index, &sup_args))
+ return NULL;
+
+ return sup_args.np;
+}
+
+static struct device_node *parse_clocks(struct device_node *np,
+ const char *prop, int index)
+{
+ return parse_prop_cells(np, prop, index, "clocks", "#clock-cells");
+}
+
+static struct device_node *parse_interconnects(struct device_node *np,
+ const char *prop, int index)
+{
+ return parse_prop_cells(np, prop, index, "interconnects",
+ "#interconnect-cells");
+}
+
+static int strcmp_suffix(const char *str, const char *suffix)
+{
+ unsigned int len, suffix_len;
+
+ len = strlen(str);
+ suffix_len = strlen(suffix);
+ if (len <= suffix_len)
+ return -1;
+ return strcmp(str + len - suffix_len, suffix);
+}
+
+static struct device_node *parse_regulators(struct device_node *np,
+ const char *prop, int index)
+{
+ if (index || strcmp_suffix(prop, "-supply"))
+ return NULL;
+
+ return of_parse_phandle(np, prop, 0);
+}
+
+/**
+ * struct supplier_bindings - Information for parsing supplier DT binding
+ *
+ * @parse_prop: If the function cannot parse the property, return NULL.
+ * Otherwise, return the phandle listed in the property
+ * that corresponds to the index.
+ */
+struct supplier_bindings {
+ struct device_node *(*parse_prop)(struct device_node *np,
+ const char *name, int index);
+};
+
+static const struct supplier_bindings bindings[] = {
+ { .parse_prop = parse_clocks, },
+ { .parse_prop = parse_interconnects, },
+ { .parse_prop = parse_regulators, },
+ { },
+};
+
+static bool of_link_property(struct device *dev, struct device_node *con_np,
+ const char *prop)
+{
+ struct device_node *phandle;
+ struct supplier_bindings *s = bindings;
+ unsigned int i = 0;
+ bool done = true, matched = false;
+
+ while (!matched && s->parse_prop) {
+ while ((phandle = s->parse_prop(con_np, prop, i))) {
+ matched = true;
+ i++;
+ if (of_link_to_phandle(dev, phandle))
+ /*
+ * Don't stop at the first failure. See
+ * Documentation for bus_type.add_links for
+ * more details.
+ */
+ done = false;
+ }
+ s++;
+ }
+ return done ? 0 : -ENODEV;
+}
+
+static bool of_devlink;
+core_param(of_devlink, of_devlink, bool, 0);
+
+static int of_link_to_suppliers(struct device *dev)
+{
+ struct property *p;
+ bool done = true;
+
+ if (!of_devlink)
+ return 0;
+ if (unlikely(!dev->of_node))
+ return 0;
+
+ for_each_property_of_node(dev->of_node, p)
+ if (of_link_property(dev, dev->of_node, p->name))
+ done = false;
+
+ return done ? 0 : -ENODEV;
+}
+
#ifndef CONFIG_PPC
static const struct of_device_id reserved_mem_matches[] = {
{ .compatible = "qcom,rmtfs-mem" },
@@ -523,6 +687,7 @@ static int __init of_platform_default_populate_init(void)
if (!of_have_populated_dt())
return -ENODEV;
+ platform_bus_type.add_links = of_link_to_suppliers;
/*
* Handle certain compatibles explicitly, since we don't want to create
* platform_devices for every node in /reserved-memory with a
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related
* Re: [PATCH 1/7] docs: fix broken doc references due to renames
From: Paul E. McKenney @ 2019-07-29 23:17 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan,
Joel Fernandes, Jonathan Corbet, Rob Herring, Mark Rutland,
Peter Zijlstra, Ingo Molnar, Will Deacon, Alan Stern,
Andrea Parri, Boqun Feng, Nicholas Piggin, David Howells,
Jade Alglave, Luc Maranget, Akira Yokosawa, Daniel Lustig,
Jerry Hoemann, Wim Van Sebroeck, Guenter Roeck, Maarten Lankhorst,
Maxime Ripard, Sean Paul, David Airlie, Daniel Vetter, Ajay Gupta,
Don Brace, James E.J. Bottomley, Martin K. Petersen, rcu,
linux-doc, devicetree, linux-arch, linux-watchdog, dri-devel,
linux-i2c, esc.storagedev, linux-scsi, Wolfram Sang
In-Reply-To: <430ed96cb234805d1deb216e8c8559da22cc6bac.1564140865.git.mchehab+samsung@kernel.org>
On Fri, Jul 26, 2019 at 08:47:21AM -0300, Mauro Carvalho Chehab wrote:
> Some files got renamed but probably due to some merge conflicts,
> a few references still point to the old locations.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Wolfram Sang <wsa@the-dreams.de> # I2C part
> Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com> # hpwdt.rst
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
> ---
> Documentation/RCU/rculist_nulls.txt | 2 +-
> Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
> Documentation/locking/spinlocks.rst | 4 ++--
> Documentation/memory-barriers.txt | 2 +-
> Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
> Documentation/watchdog/hpwdt.rst | 2 +-
> MAINTAINERS | 10 +++++-----
> drivers/gpu/drm/drm_modes.c | 2 +-
> drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +-
> drivers/scsi/hpsa.c | 4 ++--
> 10 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt
> index 8151f0195f76..23f115dc87cf 100644
> --- a/Documentation/RCU/rculist_nulls.txt
> +++ b/Documentation/RCU/rculist_nulls.txt
> @@ -1,7 +1,7 @@
> Using hlist_nulls to protect read-mostly linked lists and
> objects using SLAB_TYPESAFE_BY_RCU allocations.
>
> -Please read the basics in Documentation/RCU/listRCU.txt
> +Please read the basics in Documentation/RCU/listRCU.rst
>
> Using special makers (called 'nulls') is a convenient way
> to solve following problem :
> diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
> index 326f29b270ad..2d325bed37e5 100644
> --- a/Documentation/devicetree/bindings/arm/idle-states.txt
> +++ b/Documentation/devicetree/bindings/arm/idle-states.txt
> @@ -703,4 +703,4 @@ cpus {
> https://www.devicetree.org/specifications/
>
> [6] ARM Linux Kernel documentation - Booting AArch64 Linux
> - Documentation/arm64/booting.txt
> + Documentation/arm64/booting.rst
> diff --git a/Documentation/locking/spinlocks.rst b/Documentation/locking/spinlocks.rst
> index 098107fb7d86..e93ec6645238 100644
> --- a/Documentation/locking/spinlocks.rst
> +++ b/Documentation/locking/spinlocks.rst
> @@ -82,7 +82,7 @@ itself. The read lock allows many concurrent readers. Anything that
> **changes** the list will have to get the write lock.
>
> NOTE! RCU is better for list traversal, but requires careful
> - attention to design detail (see Documentation/RCU/listRCU.txt).
> + attention to design detail (see Documentation/RCU/listRCU.rst).
>
> Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
> time need to do any changes (even if you don't do it every time), you have
> @@ -90,7 +90,7 @@ to get the write-lock at the very beginning.
>
> NOTE! We are working hard to remove reader-writer spinlocks in most
> cases, so please don't add a new one without consensus. (Instead, see
> - Documentation/RCU/rcu.txt for complete information.)
> + Documentation/RCU/rcu.rst for complete information.)
>
> ----
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 045bb8148fe9..1adbb8a371c7 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -548,7 +548,7 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
>
> [*] For information on bus mastering DMA and coherency please read:
>
> - Documentation/PCI/pci.rst
> + Documentation/driver-api/pci/pci.rst
> Documentation/DMA-API-HOWTO.txt
> Documentation/DMA-API.txt
>
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> index a33c2a536542..2774624ee843 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -569,7 +569,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
>
> [*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다:
>
> - Documentation/PCI/pci.rst
> + Documentation/driver-api/pci/pci.rst
> Documentation/DMA-API-HOWTO.txt
> Documentation/DMA-API.txt
>
> diff --git a/Documentation/watchdog/hpwdt.rst b/Documentation/watchdog/hpwdt.rst
> index c165d92cfd12..c824cd7f6e32 100644
> --- a/Documentation/watchdog/hpwdt.rst
> +++ b/Documentation/watchdog/hpwdt.rst
> @@ -63,7 +63,7 @@ Last reviewed: 08/20/2018
> and loop forever. This is generally not what a watchdog user wants.
>
> For those wishing to learn more please see:
> - Documentation/kdump/kdump.rst
> + Documentation/admin-guide/kdump/kdump.rst
> Documentation/admin-guide/kernel-parameters.txt (panic=)
> Your Linux Distribution specific documentation.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4e2a525e22c0..51bdbd230174 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -899,7 +899,7 @@ L: linux-iio@vger.kernel.org
> W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/adc/ad7124.c
> -F: Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt
> +F: Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
>
> ANALOG DEVICES INC AD7606 DRIVER
> M: Stefan Popa <stefan.popa@analog.com>
> @@ -4190,7 +4190,7 @@ M: Jens Axboe <axboe@kernel.dk>
> L: cgroups@vger.kernel.org
> L: linux-block@vger.kernel.org
> T: git git://git.kernel.dk/linux-block
> -F: Documentation/cgroup-v1/blkio-controller.rst
> +F: Documentation/admin-guide/cgroup-v1/blkio-controller.rst
> F: block/blk-cgroup.c
> F: include/linux/blk-cgroup.h
> F: block/blk-throttle.c
> @@ -6317,7 +6317,7 @@ FLEXTIMER FTM-QUADDEC DRIVER
> M: Patrick Havelange <patrick.havelange@essensium.com>
> L: linux-iio@vger.kernel.org
> S: Maintained
> -F: Documentation/ABI/testing/sysfs-bus-counter-ftm-quadddec
> +F: Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec
> F: Documentation/devicetree/bindings/counter/ftm-quaddec.txt
> F: drivers/counter/ftm-quaddec.c
>
> @@ -6856,7 +6856,7 @@ R: Sagi Shahar <sagis@google.com>
> R: Jon Olson <jonolson@google.com>
> L: netdev@vger.kernel.org
> S: Supported
> -F: Documentation/networking/device_drivers/google/gve.txt
> +F: Documentation/networking/device_drivers/google/gve.rst
> F: drivers/net/ethernet/google
>
> GPD POCKET FAN DRIVER
> @@ -12137,7 +12137,7 @@ M: Thomas Hellstrom <thellstrom@vmware.com>
> M: "VMware, Inc." <pv-drivers@vmware.com>
> L: virtualization@lists.linux-foundation.org
> S: Supported
> -F: Documentation/virt/paravirt_ops.txt
> +F: Documentation/virt/paravirt_ops.rst
> F: arch/*/kernel/paravirt*
> F: arch/*/include/asm/paravirt*.h
> F: include/linux/hypervisor.h
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 74a5739df506..80fcd5dc1558 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1686,7 +1686,7 @@ static int drm_mode_parse_cmdline_options(char *str, size_t len,
> *
> * Additionals options can be provided following the mode, using a comma to
> * separate each option. Valid options can be found in
> - * Documentation/fb/modedb.txt.
> + * Documentation/fb/modedb.rst.
> *
> * The intermediate drm_cmdline_mode structure is required to store additional
> * options from the command line modline like the force-enable/disable flag.
> diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c b/drivers/i2c/busses/i2c-nvidia-gpu.c
> index cfc76b5de726..5a1235fd86bb 100644
> --- a/drivers/i2c/busses/i2c-nvidia-gpu.c
> +++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
> @@ -364,7 +364,7 @@ static void gpu_i2c_remove(struct pci_dev *pdev)
> /*
> * We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
> * correctly. Without it, lspci shows runtime pm status as "D0" for the card.
> - * Documentation/power/pci.txt also insists for driver to provide this.
> + * Documentation/power/pci.rst also insists for driver to provide this.
> */
> static __maybe_unused int gpu_i2c_suspend(struct device *dev)
> {
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 43a6b5350775..eaf6177ac9ee 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -7798,7 +7798,7 @@ static void hpsa_free_pci_init(struct ctlr_info *h)
> hpsa_disable_interrupt_mode(h); /* pci_init 2 */
> /*
> * call pci_disable_device before pci_release_regions per
> - * Documentation/PCI/pci.rst
> + * Documentation/driver-api/pci/pci.rst
> */
> pci_disable_device(h->pdev); /* pci_init 1 */
> pci_release_regions(h->pdev); /* pci_init 2 */
> @@ -7881,7 +7881,7 @@ static int hpsa_pci_init(struct ctlr_info *h)
> clean1:
> /*
> * call pci_disable_device before pci_release_regions per
> - * Documentation/PCI/pci.rst
> + * Documentation/driver-api/pci/pci.rst
> */
> pci_disable_device(h->pdev);
> pci_release_regions(h->pdev);
> --
> 2.21.0
>
^ permalink raw reply
* [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Suren Baghdasaryan @ 2019-07-30 1:33 UTC (permalink / raw)
To: mingo, peterz
Cc: lizefan, hannes, axboe, dennis, dennisszhou, akpm, linux-mm,
linux-doc, linux-kernel, kernel-team, Suren Baghdasaryan,
Nick Kralevich
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
require such a process to have setsched capability. Setting of psi trigger
thread's scheduling policy is an implementation detail and should not be
exposed to the user level. Remove the permission check by using _nocheck
version of the function.
Suggested-by: Nick Kralevich <nnk@google.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
kernel/sched/psi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7acc632c3b82..ed9a1d573cb1 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1061,7 +1061,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group *group,
mutex_unlock(&group->trigger_lock);
return ERR_CAST(kworker);
}
- sched_setscheduler(kworker->task, SCHED_FIFO, ¶m);
+ sched_setscheduler_nocheck(kworker->task, SCHED_FIFO, ¶m);
kthread_init_delayed_work(&group->poll_work,
psi_poll_work);
rcu_assign_pointer(group->poll_kworker, kworker);
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related
* Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Peter Zijlstra @ 2019-07-30 8:11 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: mingo, lizefan, hannes, axboe, dennis, dennisszhou, akpm,
linux-mm, linux-doc, linux-kernel, kernel-team, Nick Kralevich,
Thomas Gleixner
In-Reply-To: <20190730013310.162367-1-surenb@google.com>
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
> require such a process to have setsched capability. Setting of psi trigger
> thread's scheduling policy is an implementation detail and should not be
> exposed to the user level. Remove the permission check by using _nocheck
> version of the function.
>
> Suggested-by: Nick Kralevich <nnk@google.com>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> ---
> kernel/sched/psi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
> index 7acc632c3b82..ed9a1d573cb1 100644
> --- a/kernel/sched/psi.c
> +++ b/kernel/sched/psi.c
> @@ -1061,7 +1061,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group *group,
> mutex_unlock(&group->trigger_lock);
> return ERR_CAST(kworker);
> }
> - sched_setscheduler(kworker->task, SCHED_FIFO, ¶m);
> + sched_setscheduler_nocheck(kworker->task, SCHED_FIFO, ¶m);
ARGGH, wtf is there a FIFO-99!! thread here at all !?
> kthread_init_delayed_work(&group->poll_work,
> psi_poll_work);
> rcu_assign_pointer(group->poll_kworker, kworker);
> --
> 2.22.0.709.g102302147b-goog
>
^ permalink raw reply
* Re: [PATCH v2] Documentation: gpio: fix function links in the HTML docs
From: Bartosz Golaszewski @ 2019-07-30 8:17 UTC (permalink / raw)
To: Jeremy Cline; +Cc: Linus Walleij, Jonathan Corbet, linux-gpio, linux-doc, LKML
In-Reply-To: <20190729143730.18660-1-jcline@redhat.com>
pon., 29 lip 2019 o 16:37 Jeremy Cline <jcline@redhat.com> 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 by commit 48207d7595d2 ("gpio:
> drop devm_gpiochip_remove()").
>
> Signed-off-by: Jeremy Cline <jcline@redhat.com>
> ---
> New in v2:
> - Rebased onto v5.3-rc2
>
> Documentation/driver-api/gpio/driver.rst | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst
> index 921c71a3d683..906af220b164 100644
> --- a/Documentation/driver-api/gpio/driver.rst
> +++ b/Documentation/driver-api/gpio/driver.rst
> @@ -69,9 +69,9 @@ driver code:
>
> The code implementing a gpio_chip should support multiple instances of the
> controller, preferably using the driver model. That code will configure each
> -gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
> -Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
> -when it is unavoidable.
> +gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or
> +devm_gpiochip_add_data(). Removing a GPIO controller should be rare; use
> +gpiochip_remove() when it is unavoidable.
>
> Often a gpio_chip is part of an instance-specific structure with states not
> exposed by the GPIO interfaces, such as addressing, power management, and more.
> @@ -418,11 +418,11 @@ symbol:
>
> If there is a need to exclude certain GPIO lines from the IRQ domain handled by
> these helpers, we can set .irq.need_valid_mask of the gpiochip before
> -``[devm_]gpiochip_add_data()`` is called. This allocates an .irq.valid_mask with as
> -many bits set as there are GPIO lines in the chip, each bit representing line
> -0..n-1. Drivers can exclude GPIO lines by clearing bits from this mask. The mask
> -must be filled in before gpiochip_irqchip_add() or gpiochip_irqchip_add_nested()
> -is called.
> +devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
> +.irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
> +bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
> +from this mask. The mask must be filled in before gpiochip_irqchip_add() or
> +gpiochip_irqchip_add_nested() is called.
>
> To use the helpers please keep the following in mind:
>
> --
> 2.21.0
>
Patch applied, thanks!
Bartosz
^ permalink raw reply
* Re: [PATCH v6 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Kevin Brodsky @ 2019-07-30 10:32 UTC (permalink / raw)
To: Vincenzo Frascino, linux-arm-kernel, linux-doc, linux-mm,
linux-arch, linux-kselftest, linux-kernel
Cc: Szabolcs Nagy, Catalin Marinas, Will Deacon, Andrey Konovalov
In-Reply-To: <20190725135044.24381-2-vincenzo.frascino@arm.com>
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 are not allowed at the
> user-kernel syscall ABI boundary.
>
> With the relaxed ABI proposed through this document, it is now possible
> to pass tagged pointers to the syscalls, when these pointers are in
> memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
>
> This change in the ABI requires a mechanism to requires the userspace
> to opt-in to such an option.
>
> Specify and document the way in which sysctl and prctl() can be used
> in combination to allow the userspace to opt-in this feature.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> CC: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Acked-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
> ---
> Documentation/arm64/tagged-address-abi.rst | 148 +++++++++++++++++++++
> 1 file changed, 148 insertions(+)
> create mode 100644 Documentation/arm64/tagged-address-abi.rst
>
> diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst
> new file mode 100644
> index 000000000000..a8ecb991de82
> --- /dev/null
> +++ b/Documentation/arm64/tagged-address-abi.rst
> @@ -0,0 +1,148 @@
> +========================
> +ARM64 TAGGED ADDRESS ABI
> +========================
> +
> +Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
> +
> +Date: 25 July 2019
> +
> +This document describes the usage and semantics of the Tagged Address
> +ABI on arm64.
> +
> +1. Introduction
> +---------------
> +
> +On arm64 the TCR_EL1.TBI0 bit has always been enabled on the kernel, hence
> +the userspace (EL0) is entitled to perform a user memory access through a
> +64-bit pointer with a non-zero top byte but the resulting pointers are not
> +allowed at the user-kernel syscall ABI boundary.
> +
> +This document describes a relaxation of the ABI that makes it possible to
> +to pass tagged pointers to the syscalls, when these pointers are in memory
One too many "to" (at the end the previous line).
> +ranges obtained as described in section 2.
> +
> +Since it is not desirable to relax the ABI to allow tagged user addresses
> +into the kernel indiscriminately, arm64 provides a new sysctl interface
> +(/proc/sys/abi/tagged_addr) that is used to prevent the applications from
> +enabling the relaxed ABI and a new prctl() interface that can be used to
> +enable or disable the relaxed ABI.
> +A detailed description of the newly introduced mechanisms will be provided
> +in section 2.
> +
> +2. ARM64 Tagged Address ABI
> +---------------------------
> +
> +From the kernel syscall interface perspective, we define, for the purposes
> +of this document, a "valid tagged pointer" as a pointer that either has a
> +zero value set in the top byte or has a non-zero value, is in memory ranges
> +privately owned by a userspace process and is obtained in one of the
> +following ways:
> +- mmap() done by the process itself, where either:
> +
> + - flags have **MAP_PRIVATE** and **MAP_ANONYMOUS**
> + - flags have **MAP_PRIVATE** and the file descriptor refers to a regular
> + file or **/dev/zero**
> +
> +- brk() system call done by the process itself (i.e. the heap area between
> + the initial location of the program break at process creation and its
> + current location).
> +- any memory mapped by the kernel in the process's address space during
> + creation and with the same restrictions as for mmap() (e.g. data, bss,
> + stack).
> +
> +The ARM64 Tagged Address ABI is an opt-in feature, and an application can
> +control it using the following:
> +
> +- **/proc/sys/abi/tagged_addr**: a new sysctl interface that can be used to
> + prevent the applications from enabling the access to the relaxed ABI.
> + The sysctl supports the following configuration options:
> +
> + - **0**: Disable the access to the ARM64 Tagged Address ABI for all
> + the applications.
> + - **1** (Default): Enable the access to the ARM64 Tagged Address ABI for
> + all the applications.
> +
> + If the access to the ARM64 Tagged Address ABI is disabled at a certain
> + point in time, all the applications that were using tagging before this
> + event occurs, will continue to use tagging.
"tagging" may be misinterpreted here. I would be more explicit by saying that the
tagged address ABI remains enabled in processes that opted in before the access got
disabled.
> +- **prctl()s**:
> +
> + - **PR_SET_TAGGED_ADDR_CTRL**: Invoked by a process, can be used to enable or
> + disable its access to the ARM64 Tagged Address ABI.
I still find the wording confusing, because "access to the ABI" is not used
consistently. The "tagged_addr" sysctl enables *access to the ABI*, that's fine.
However, PR_SET_TAGGED_ADDR_CTRL enables *the ABI itself* (which is only possible if
access to the ABI is enabled).
> +
> + The (unsigned int) arg2 argument is a bit mask describing the control mode
> + used:
> +
> + - **PR_TAGGED_ADDR_ENABLE**: Enable ARM64 Tagged Address ABI.
> +
> + The prctl(PR_SET_TAGGED_ADDR_CTRL, ...) will return -EINVAL if the ARM64
> + Tagged Address ABI is not available.
For clarity, it would be good to mention that one possible reason for the ABI not to
be available is tagged_addr == 0.
> +
> + The arguments arg3, arg4, and arg5 are ignored.
> + - **PR_GET_TAGGED_ADDR_CTRL**: can be used to check the status of the Tagged
> + Address ABI.
> +
> + The arguments arg2, arg3, arg4, and arg5 are ignored.
> +
> +The ABI properties set by the mechanisms described above are inherited by threads
> +of the same application and fork()'ed children but cleared by execve().
> +
> +When a process has successfully opted into the new ABI by invoking
> +PR_SET_TAGGED_ADDR_CTRL prctl(), this guarantees the following behaviours:
> +
> + - Every currently available syscall, except the cases mentioned in section 3, can
> + accept any valid tagged pointer. The same rule is applicable to any syscall
> + introduced in the future.
I thought Catalin wanted to drop this guarantee?
> + - If a non valid tagged pointer is passed to a syscall then the behaviour
> + is undefined.
> + - Every valid tagged pointer is expected to work as an untagged one.
> + - The kernel preserves any valid tagged pointer and returns it to the
> + userspace unchanged (i.e. on syscall return) in all the cases except the
> + ones documented in the "Preserving tags" section of tagged-pointers.txt.
> +
> +A definition of the meaning of tagged pointers on arm64 can be found in:
> +Documentation/arm64/tagged-pointers.txt.
> +
> +3. ARM64 Tagged Address ABI Exceptions
> +--------------------------------------
> +
> +The behaviours described in section 2, with particular reference to the
> +acceptance by the syscalls of any valid tagged pointer are not applicable
> +to the following cases:
> +
> + - mmap() addr parameter.
> + - mremap() new_address parameter.
> + - prctl(PR_SET_MM, PR_SET_MM_MAP, ...) struct prctl_mm_map fields.
> + - prctl(PR_SET_MM, PR_SET_MM_MAP_SIZE, ...) struct prctl_mm_map fields.
All the PR_SET_MM options that specify pointers (PR_SET_MM_START_CODE,
PR_SET_MM_END_CODE, ...) should be excluded as well. AFAICT (but don't take my word
for it), that's all of them except PR_SET_MM_EXE_FILE. Conversely, PR_SET_MM_MAP_SIZE
should not be excluded (it does not pass a prctl_mm_map struct, and the pointer to
unsigned int can be tagged).
Kevin
> +
> +Any attempt to use non-zero tagged pointers will lead to undefined behaviour.
> +
> +4. Example of correct usage
> +---------------------------
> +.. code-block:: c
> +
> + void main(void)
> + {
> + static int tbi_enabled = 0;
> + unsigned long tag = 0;
> +
> + char *ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
> + MAP_ANONYMOUS, -1, 0);
> +
> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE,
> + 0, 0, 0) == 0)
> + tbi_enabled = 1;
> +
> + if (ptr == (void *)-1) /* MAP_FAILED */
> + return -1;
> +
> + if (tbi_enabled)
> + tag = rand() & 0xff;
> +
> + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
> +
> + *ptr = 'a';
> +
> + ...
> + }
> +
^ permalink raw reply
* [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-07-30 12:23 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, casey, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, linux-arm-kernel, tee-dev, Sumit Garg
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 registered kernel shared memory with TEE.
Patch #3 enables support for private kernel login method required for
cases like trusted keys where we don't wan't user-space to directly access
TEE service to retrieve trusted key contents.
Rest of the patches from #4 to #6 adds support for TEE based trusted keys.
This patch-set has been tested with OP-TEE based pseudo TA which can be
found here [1].
Also, this patch-set is dependent on generic Trusted Keys framework
patch-set [2].
[1] https://github.com/OP-TEE/optee_os/pull/3082
[2] https://lkml.org/lkml/2019/7/18/284
Changes in v2:
1. Add reviewed-by tags for patch #1 and #2.
2. Incorporate comments from Jens for patch #3.
3. Switch to use generic trusted keys framework.
Sumit Garg (6):
tee: optee: allow kernel pages to register as shm
tee: enable support to register kernel memory
tee: add private login method for kernel clients
KEYS: trusted: Introduce TEE based Trusted Keys
doc: keys: Document usage of TEE based Trusted Keys
MAINTAINERS: Add entry for TEE based Trusted Keys
Documentation/security/keys/index.rst | 1 +
Documentation/security/keys/tee-trusted.rst | 93 +++++++++
MAINTAINERS | 9 +
drivers/tee/optee/call.c | 7 +
drivers/tee/tee_core.c | 6 +
drivers/tee/tee_shm.c | 16 +-
include/keys/trusted-type.h | 3 +
include/keys/trusted_tee.h | 66 +++++++
include/linux/tee_drv.h | 1 +
include/uapi/linux/tee.h | 8 +
security/keys/Kconfig | 3 +
security/keys/trusted-keys/Makefile | 3 +-
security/keys/trusted-keys/trusted-tee.c | 282 ++++++++++++++++++++++++++++
security/keys/trusted-keys/trusted.c | 3 +
14 files changed, 498 insertions(+), 3 deletions(-)
create mode 100644 Documentation/security/keys/tee-trusted.rst
create mode 100644 include/keys/trusted_tee.h
create mode 100644 security/keys/trusted-keys/trusted-tee.c
--
2.7.4
^ permalink raw reply
* [RFC v2 1/6] tee: optee: allow kernel pages to register as shm
From: Sumit Garg @ 2019-07-30 12:23 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, casey, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, linux-arm-kernel, tee-dev, Sumit Garg
In-Reply-To: <1564489420-677-1-git-send-email-sumit.garg@linaro.org>
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 <sumit.garg@linaro.org>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
---
drivers/tee/optee/call.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
index aa94270..bce45b1 100644
--- a/drivers/tee/optee/call.c
+++ b/drivers/tee/optee/call.c
@@ -553,6 +553,13 @@ static int check_mem_type(unsigned long start, size_t num_pages)
struct mm_struct *mm = current->mm;
int rc;
+ /*
+ * Allow kernel address to register with OP-TEE as kernel
+ * pages are configured as normal memory only.
+ */
+ if (virt_addr_valid(start))
+ return 0;
+
down_read(&mm->mmap_sem);
rc = __check_mem_type(find_vma(mm, start),
start + num_pages * PAGE_SIZE);
--
2.7.4
^ permalink raw reply related
* [RFC v2 2/6] tee: enable support to register kernel memory
From: Sumit Garg @ 2019-07-30 12:23 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, casey, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, linux-arm-kernel, tee-dev, Sumit Garg
In-Reply-To: <1564489420-677-1-git-send-email-sumit.garg@linaro.org>
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 <sumit.garg@linaro.org>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
---
drivers/tee/tee_shm.c | 16 ++++++++++++++--
include/linux/tee_drv.h | 1 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 2da026f..5c69b89 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -9,6 +9,7 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/tee_drv.h>
+#include <linux/uio.h>
#include "tee_private.h"
static void tee_shm_release(struct tee_shm *shm)
@@ -224,13 +225,14 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr,
{
struct tee_device *teedev = ctx->teedev;
const u32 req_flags = TEE_SHM_DMA_BUF | TEE_SHM_USER_MAPPED;
+ const u32 req_ker_flags = TEE_SHM_DMA_BUF | TEE_SHM_KERNEL_MAPPED;
struct tee_shm *shm;
void *ret;
int rc;
int num_pages;
unsigned long start;
- if (flags != req_flags)
+ if (flags != req_flags && flags != req_ker_flags)
return ERR_PTR(-ENOTSUPP);
if (!tee_device_get(teedev))
@@ -264,7 +266,17 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr,
goto err;
}
- rc = get_user_pages_fast(start, num_pages, FOLL_WRITE, shm->pages);
+ if (flags & TEE_SHM_USER_MAPPED) {
+ rc = get_user_pages_fast(start, num_pages, FOLL_WRITE,
+ shm->pages);
+ } else {
+ const struct kvec kiov = {
+ .iov_base = (void *)start,
+ .iov_len = PAGE_SIZE
+ };
+
+ rc = get_kernel_pages(&kiov, num_pages, 0, shm->pages);
+ }
if (rc > 0)
shm->num_pages = rc;
if (rc != num_pages) {
diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
index 7a03f68..dedf8fa 100644
--- a/include/linux/tee_drv.h
+++ b/include/linux/tee_drv.h
@@ -26,6 +26,7 @@
#define TEE_SHM_REGISTER BIT(3) /* Memory registered in secure world */
#define TEE_SHM_USER_MAPPED BIT(4) /* Memory mapped in user space */
#define TEE_SHM_POOL BIT(5) /* Memory allocated from pool */
+#define TEE_SHM_KERNEL_MAPPED BIT(6) /* Memory mapped in kernel space */
struct device;
struct tee_device;
--
2.7.4
^ permalink raw reply related
* [RFC v2 3/6] tee: add private login method for kernel clients
From: Sumit Garg @ 2019-07-30 12:23 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, casey, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, linux-arm-kernel, tee-dev, Sumit Garg
In-Reply-To: <1564489420-677-1-git-send-email-sumit.garg@linaro.org>
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 method range: (0x80000000 - 0xFFFFFFFF).
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
drivers/tee/tee_core.c | 6 ++++++
include/uapi/linux/tee.h | 8 ++++++++
2 files changed, 14 insertions(+)
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
index 0f16d9f..2c2f646 100644
--- a/drivers/tee/tee_core.c
+++ b/drivers/tee/tee_core.c
@@ -334,6 +334,12 @@ static int tee_ioctl_open_session(struct tee_context *ctx,
goto out;
}
+ if (arg.clnt_login & TEE_IOCTL_LOGIN_MASK) {
+ pr_debug("login method not allowed for user-space client\n");
+ rc = -EPERM;
+ goto out;
+ }
+
rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params);
if (rc)
goto out;
diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
index 4b9eb06..a0a3d52 100644
--- a/include/uapi/linux/tee.h
+++ b/include/uapi/linux/tee.h
@@ -172,6 +172,14 @@ struct tee_ioctl_buf_data {
#define TEE_IOCTL_LOGIN_APPLICATION 4
#define TEE_IOCTL_LOGIN_USER_APPLICATION 5
#define TEE_IOCTL_LOGIN_GROUP_APPLICATION 6
+/*
+ * Disallow user-space to use GP implementation specific login
+ * method range (0x80000000 - 0xFFFFFFFF). This range is rather
+ * being reserved for REE kernel clients or TEE implementation.
+ */
+#define TEE_IOCTL_LOGIN_MASK 0x80000000
+/* Private login method for REE kernel clients */
+#define TEE_IOCTL_LOGIN_REE_KERNEL 0x80000000
/**
* struct tee_ioctl_param - parameter
--
2.7.4
^ permalink raw reply related
* [RFC v2 4/6] KEYS: trusted: Introduce TEE based Trusted Keys
From: Sumit Garg @ 2019-07-30 12:23 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, casey, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, linux-arm-kernel, tee-dev, Sumit Garg
In-Reply-To: <1564489420-677-1-git-send-email-sumit.garg@linaro.org>
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 <sumit.garg@linaro.org>
---
include/keys/trusted-type.h | 3 +
include/keys/trusted_tee.h | 66 ++++++++
security/keys/Kconfig | 3 +
security/keys/trusted-keys/Makefile | 3 +-
security/keys/trusted-keys/trusted-tee.c | 282 +++++++++++++++++++++++++++++++
security/keys/trusted-keys/trusted.c | 3 +
6 files changed, 359 insertions(+), 1 deletion(-)
create mode 100644 include/keys/trusted_tee.h
create mode 100644 security/keys/trusted-keys/trusted-tee.c
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 5559010..e0df5df 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -67,6 +67,9 @@ extern struct key_type key_type_trusted;
#if defined(CONFIG_TCG_TPM)
extern struct trusted_key_ops tpm_trusted_key_ops;
#endif
+#if defined(CONFIG_TEE)
+extern struct trusted_key_ops tee_trusted_key_ops;
+#endif
#define TRUSTED_DEBUG 0
diff --git a/include/keys/trusted_tee.h b/include/keys/trusted_tee.h
new file mode 100644
index 0000000..ab58ffd
--- /dev/null
+++ b/include/keys/trusted_tee.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Linaro Ltd.
+ *
+ * Author:
+ * Sumit Garg <sumit.garg@linaro.org>
+ */
+
+#ifndef __TEE_TRUSTED_KEY_H
+#define __TEE_TRUSTED_KEY_H
+
+#include <linux/tee_drv.h>
+
+#define DRIVER_NAME "tee-trusted-key"
+
+/*
+ * Get random data for symmetric key
+ *
+ * [out] memref[0] Random data
+ *
+ * Result:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ */
+#define TA_CMD_GET_RANDOM 0x0
+
+/*
+ * Seal trusted key using hardware unique key
+ *
+ * [in] memref[0] Plain key
+ * [out] memref[1] Sealed key datablob
+ *
+ * Result:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ */
+#define TA_CMD_SEAL 0x1
+
+/*
+ * Unseal trusted key using hardware unique key
+ *
+ * [in] memref[0] Sealed key datablob
+ * [out] memref[1] Plain key
+ *
+ * Result:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ */
+#define TA_CMD_UNSEAL 0x2
+
+/**
+ * struct trusted_key_private - TEE Trusted key private data
+ * @dev: TEE based Trusted key device.
+ * @ctx: TEE context handler.
+ * @session_id: Trusted key TA session identifier.
+ * @shm_pool: Memory pool shared with TEE device.
+ */
+struct trusted_key_private {
+ struct device *dev;
+ struct tee_context *ctx;
+ u32 session_id;
+ u32 data_rate;
+ struct tee_shm *shm_pool;
+};
+
+#endif
diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index dd31343..0d5e37c 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -88,6 +88,9 @@ config TRUSTED_KEYS
if the boot PCRs and other criteria match. Userspace will only ever
see encrypted blobs.
+ It also provides support for alternative TEE based Trusted keys
+ generation and sealing in case TPM isn't present.
+
If you are unsure as to whether this is required, answer N.
config ENCRYPTED_KEYS
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index 6ecadfb..5fcf2ae 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -4,4 +4,5 @@
#
obj-$(CONFIG_TRUSTED_KEYS) += trusted.o \
- trusted-tpm.o
+ trusted-tpm.o \
+ trusted-tee.o
diff --git a/security/keys/trusted-keys/trusted-tee.c b/security/keys/trusted-keys/trusted-tee.c
new file mode 100644
index 0000000..724a73c
--- /dev/null
+++ b/security/keys/trusted-keys/trusted-tee.c
@@ -0,0 +1,282 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Linaro Ltd.
+ *
+ * Author:
+ * Sumit Garg <sumit.garg@linaro.org>
+ */
+
+#include <linux/err.h>
+#include <linux/key-type.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/uuid.h>
+
+#include <keys/trusted-type.h>
+#include <keys/trusted_tee.h>
+
+static struct trusted_key_private pvt_data;
+
+/*
+ * Have the TEE seal(encrypt) the symmetric key
+ */
+static int tee_key_seal(struct trusted_key_payload *p, char *datablob)
+{
+ int ret = 0;
+ struct tee_ioctl_invoke_arg inv_arg;
+ struct tee_param param[4];
+ struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
+
+ memset(&inv_arg, 0, sizeof(inv_arg));
+ memset(¶m, 0, sizeof(param));
+
+ reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
+ p->key_len, TEE_SHM_DMA_BUF |
+ TEE_SHM_KERNEL_MAPPED);
+ if (IS_ERR(reg_shm_in)) {
+ dev_err(pvt_data.dev, "key shm register failed\n");
+ return PTR_ERR(reg_shm_in);
+ }
+
+ reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
+ sizeof(p->blob), TEE_SHM_DMA_BUF |
+ TEE_SHM_KERNEL_MAPPED);
+ if (IS_ERR(reg_shm_out)) {
+ dev_err(pvt_data.dev, "blob shm register failed\n");
+ ret = PTR_ERR(reg_shm_out);
+ goto out;
+ }
+
+ inv_arg.func = TA_CMD_SEAL;
+ inv_arg.session = pvt_data.session_id;
+ inv_arg.num_params = 4;
+
+ param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
+ param[0].u.memref.shm = reg_shm_in;
+ param[0].u.memref.size = p->key_len;
+ param[0].u.memref.shm_offs = 0;
+ param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+ param[1].u.memref.shm = reg_shm_out;
+ param[1].u.memref.size = sizeof(p->blob);
+ param[1].u.memref.shm_offs = 0;
+
+ ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+ if ((ret < 0) || (inv_arg.ret != 0)) {
+ dev_err(pvt_data.dev, "TA_CMD_SEAL invoke err: %x\n",
+ inv_arg.ret);
+ ret = -EFAULT;
+ } else {
+ p->blob_len = param[1].u.memref.size;
+ }
+
+out:
+ if (reg_shm_out)
+ tee_shm_free(reg_shm_out);
+ if (reg_shm_in)
+ tee_shm_free(reg_shm_in);
+
+ return ret;
+}
+
+/*
+ * Have the TEE unseal(decrypt) the symmetric key
+ */
+static int tee_key_unseal(struct trusted_key_payload *p, char *datablob)
+{
+ int ret = 0;
+ struct tee_ioctl_invoke_arg inv_arg;
+ struct tee_param param[4];
+ struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
+
+ memset(&inv_arg, 0, sizeof(inv_arg));
+ memset(¶m, 0, sizeof(param));
+
+ reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
+ p->blob_len, TEE_SHM_DMA_BUF |
+ TEE_SHM_KERNEL_MAPPED);
+ if (IS_ERR(reg_shm_in)) {
+ dev_err(pvt_data.dev, "blob shm register failed\n");
+ return PTR_ERR(reg_shm_in);
+ }
+
+ reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
+ sizeof(p->key), TEE_SHM_DMA_BUF |
+ TEE_SHM_KERNEL_MAPPED);
+ if (IS_ERR(reg_shm_out)) {
+ dev_err(pvt_data.dev, "key shm register failed\n");
+ ret = PTR_ERR(reg_shm_out);
+ goto out;
+ }
+
+ inv_arg.func = TA_CMD_UNSEAL;
+ inv_arg.session = pvt_data.session_id;
+ inv_arg.num_params = 4;
+
+ param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
+ param[0].u.memref.shm = reg_shm_in;
+ param[0].u.memref.size = p->blob_len;
+ param[0].u.memref.shm_offs = 0;
+ param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+ param[1].u.memref.shm = reg_shm_out;
+ param[1].u.memref.size = sizeof(p->key);
+ param[1].u.memref.shm_offs = 0;
+
+ ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+ if ((ret < 0) || (inv_arg.ret != 0)) {
+ dev_err(pvt_data.dev, "TA_CMD_UNSEAL invoke err: %x\n",
+ inv_arg.ret);
+ ret = -EFAULT;
+ } else {
+ p->key_len = param[1].u.memref.size;
+ }
+
+out:
+ if (reg_shm_out)
+ tee_shm_free(reg_shm_out);
+ if (reg_shm_in)
+ tee_shm_free(reg_shm_in);
+
+ return ret;
+}
+
+/*
+ * Have the TEE generate random symmetric key
+ */
+static int tee_get_random(unsigned char *key, size_t key_len)
+{
+ int ret = 0;
+ struct tee_ioctl_invoke_arg inv_arg;
+ struct tee_param param[4];
+ struct tee_shm *reg_shm = NULL;
+
+ memset(&inv_arg, 0, sizeof(inv_arg));
+ memset(¶m, 0, sizeof(param));
+
+ reg_shm = tee_shm_register(pvt_data.ctx, (unsigned long)key, key_len,
+ TEE_SHM_DMA_BUF | TEE_SHM_KERNEL_MAPPED);
+ if (IS_ERR(reg_shm)) {
+ dev_err(pvt_data.dev, "random key shm register failed\n");
+ return PTR_ERR(reg_shm);
+ }
+
+ inv_arg.func = TA_CMD_GET_RANDOM;
+ inv_arg.session = pvt_data.session_id;
+ inv_arg.num_params = 4;
+
+ param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+ param[0].u.memref.shm = reg_shm;
+ param[0].u.memref.size = key_len;
+ param[0].u.memref.shm_offs = 0;
+
+ ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+ if ((ret < 0) || (inv_arg.ret != 0)) {
+ dev_err(pvt_data.dev, "TA_CMD_GET_RANDOM invoke err: %x\n",
+ inv_arg.ret);
+ ret = -EFAULT;
+ } else {
+ ret = param[0].u.memref.size;
+ }
+
+ tee_shm_free(reg_shm);
+
+ return ret;
+}
+
+static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
+{
+ if (ver->impl_id == TEE_IMPL_ID_OPTEE)
+ return 1;
+ else
+ return 0;
+}
+
+static int trusted_key_probe(struct device *dev)
+{
+ struct tee_client_device *rng_device = to_tee_client_device(dev);
+ int ret = 0, err = -ENODEV;
+ struct tee_ioctl_open_session_arg sess_arg;
+
+ memset(&sess_arg, 0, sizeof(sess_arg));
+
+ /* Open context with TEE driver */
+ pvt_data.ctx = tee_client_open_context(NULL, optee_ctx_match, NULL,
+ NULL);
+ if (IS_ERR(pvt_data.ctx))
+ return -ENODEV;
+
+ /* Open session with hwrng Trusted App */
+ memcpy(sess_arg.uuid, rng_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
+ sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
+ sess_arg.num_params = 0;
+
+ ret = tee_client_open_session(pvt_data.ctx, &sess_arg, NULL);
+ if ((ret < 0) || (sess_arg.ret != 0)) {
+ dev_err(dev, "tee_client_open_session failed, err: %x\n",
+ sess_arg.ret);
+ err = -EINVAL;
+ goto out_ctx;
+ }
+ pvt_data.session_id = sess_arg.session;
+
+ ret = register_key_type(&key_type_trusted);
+ if (ret < 0)
+ goto out_sess;
+
+ pvt_data.dev = dev;
+
+ return 0;
+
+out_sess:
+ tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
+out_ctx:
+ tee_client_close_context(pvt_data.ctx);
+
+ return err;
+}
+
+static int trusted_key_remove(struct device *dev)
+{
+ unregister_key_type(&key_type_trusted);
+ tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
+ tee_client_close_context(pvt_data.ctx);
+
+ return 0;
+}
+
+static const struct tee_client_device_id trusted_key_id_table[] = {
+ {UUID_INIT(0xf04a0fe7, 0x1f5d, 0x4b9b,
+ 0xab, 0xf7, 0x61, 0x9b, 0x85, 0xb4, 0xce, 0x8c)},
+ {}
+};
+
+MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
+
+static struct tee_client_driver trusted_key_driver = {
+ .id_table = trusted_key_id_table,
+ .driver = {
+ .name = DRIVER_NAME,
+ .bus = &tee_bus_type,
+ .probe = trusted_key_probe,
+ .remove = trusted_key_remove,
+ },
+};
+
+static int __init init_tee_trusted(void)
+{
+ return driver_register(&trusted_key_driver.driver);
+}
+
+static void __exit cleanup_tee_trusted(void)
+{
+ driver_unregister(&trusted_key_driver.driver);
+}
+
+struct trusted_key_ops tee_trusted_key_ops = {
+ .migratable = 0, /* non-migratable */
+ .init = init_tee_trusted,
+ .seal = tee_key_seal,
+ .unseal = tee_key_unseal,
+ .get_random = tee_get_random,
+ .cleanup = cleanup_tee_trusted,
+};
+EXPORT_SYMBOL_GPL(tee_trusted_key_ops);
diff --git a/security/keys/trusted-keys/trusted.c b/security/keys/trusted-keys/trusted.c
index 8f00fde..a0a171f 100644
--- a/security/keys/trusted-keys/trusted.c
+++ b/security/keys/trusted-keys/trusted.c
@@ -27,6 +27,9 @@ static struct trusted_key_ops *available_tk_ops[] = {
#if defined(CONFIG_TCG_TPM)
&tpm_trusted_key_ops,
#endif
+#if defined(CONFIG_TEE)
+ &tee_trusted_key_ops,
+#endif
};
static struct trusted_key_ops *tk_ops;
--
2.7.4
^ permalink raw reply related
* [RFC v2 5/6] doc: keys: Document usage of TEE based Trusted Keys
From: Sumit Garg @ 2019-07-30 12:23 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, casey, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, linux-arm-kernel, tee-dev, Sumit Garg
In-Reply-To: <1564489420-677-1-git-send-email-sumit.garg@linaro.org>
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 <sumit.garg@linaro.org>
---
Documentation/security/keys/index.rst | 1 +
Documentation/security/keys/tee-trusted.rst | 93 +++++++++++++++++++++++++++++
2 files changed, 94 insertions(+)
create mode 100644 Documentation/security/keys/tee-trusted.rst
diff --git a/Documentation/security/keys/index.rst b/Documentation/security/keys/index.rst
index 647d58f..f9ef557 100644
--- a/Documentation/security/keys/index.rst
+++ b/Documentation/security/keys/index.rst
@@ -9,3 +9,4 @@ Kernel Keys
ecryptfs
request-key
trusted-encrypted
+ tee-trusted
diff --git a/Documentation/security/keys/tee-trusted.rst b/Documentation/security/keys/tee-trusted.rst
new file mode 100644
index 0000000..ef03745
--- /dev/null
+++ b/Documentation/security/keys/tee-trusted.rst
@@ -0,0 +1,93 @@
+======================
+TEE based Trusted Keys
+======================
+
+TEE based Trusted Keys provides an alternative approach for providing Trusted
+Keys in case TPM chip isn't present.
+
+Trusted Keys use a TEE service/device both to generate and to seal the keys.
+Keys are sealed under a hardware unique key in the TEE, and only unsealed by
+the TEE.
+
+For more information about TEE, refer to ``Documentation/tee.txt``.
+
+Usage::
+
+ keyctl add trusted name "new keylen" ring
+ keyctl add trusted name "load hex_blob" ring
+ keyctl print keyid
+
+"keyctl print" returns an ascii hex copy of the sealed key, which is in format
+specific to TEE device implementation. The key length for new keys are always
+in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
+
+Examples of trusted key and its usage as 'master' key for encrypted key usage:
+
+More details about encrypted keys can be found here:
+``Documentation/security/keys/trusted-encrypted.rst``
+
+Create and save a trusted key named "kmk" of length 32 bytes::
+
+ $ keyctl add trusted kmk "new 32" @u
+ 754414669
+
+ $ keyctl show
+ Session Keyring
+ 827385718 --alswrv 0 65534 keyring: _uid_ses.0
+ 274124851 --alswrv 0 65534 \_ keyring: _uid.0
+ 754414669 --als-rv 0 0 \_ trusted: kmk
+
+ $ keyctl print 754414669
+ 15676790697861b422175596ae001c2f505cea2c6f3ebbc5fb08eeb1f343a07e
+
+ $ keyctl pipe 754414669 > kmk.blob
+
+Load a trusted key from the saved blob::
+
+ $ keyctl add trusted kmk "load `cat kmk.blob`" @u
+ 491638700
+
+ $ keyctl print 491638700
+ 15676790697861b422175596ae001c2f505cea2c6f3ebbc5fb08eeb1f343a07e
+
+The initial consumer of trusted keys is EVM, which at boot time needs a high
+quality symmetric key for HMAC protection of file metadata. The use of a
+TEE based trusted key provides security that the EVM key has not been
+compromised by a user level problem and tied to particular hardware.
+
+Create and save an encrypted key "evm" using the above trusted key "kmk":
+
+option 1: omitting 'format'::
+
+ $ keyctl add encrypted evm "new trusted:kmk 32" @u
+ 608915065
+
+option 2: explicitly defining 'format' as 'default'::
+
+ $ keyctl add encrypted evm "new default trusted:kmk 32" @u
+ 608915065
+
+ $ keyctl print 608915065
+ default trusted:kmk 32 f380ac588a925f488d5be007cf23e4c900b8b652ab62241c8
+ ed54906189b6659d139d619d4b51752a2645537b11fd44673f13154a65b3f595d5fb2131
+ 2fe45529ea0407c644ea4026f2a1a75661f2c9b66
+
+ $ keyctl pipe 608915065 > evm.blob
+
+Load an encrypted key "evm" from saved blob::
+
+ $ keyctl add encrypted evm "load `cat evm.blob`" @u
+ 831684262
+
+ $ keyctl print 831684262
+ default trusted:kmk 32 f380ac588a925f488d5be007cf23e4c900b8b652ab62241c8
+ ed54906189b6659d139d619d4b51752a2645537b11fd44673f13154a65b3f595d5fb2131
+ 2fe45529ea0407c644ea4026f2a1a75661f2c9b66
+
+Other uses for trusted and encrypted keys, such as for disk and file encryption
+are anticipated. In particular the 'ecryptfs' encrypted keys format can be used
+to mount an eCryptfs filesystem. More details about the usage can be found in
+the file ``Documentation/security/keys/ecryptfs.rst``.
+
+Another format 'enc32' can be used to support encrypted keys with payload size
+of 32 bytes.
--
2.7.4
^ permalink raw reply related
* [RFC v2 6/6] MAINTAINERS: Add entry for TEE based Trusted Keys
From: Sumit Garg @ 2019-07-30 12:23 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, casey, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, linux-arm-kernel, tee-dev, Sumit Garg
In-Reply-To: <1564489420-677-1-git-send-email-sumit.garg@linaro.org>
Add MAINTAINERS entry for TEE based Trusted Keys framework.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
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/keys/trusted-type.h
F: security/keys/trusted.c
F: security/keys/trusted.h
+KEYS-TEE-TRUSTED
+M: Sumit Garg <sumit.garg@linaro.org>
+L: linux-integrity@vger.kernel.org
+L: keyrings@vger.kernel.org
+S: Supported
+F: Documentation/security/keys/tee-trusted.rst
+F: include/keys/trusted_tee.h
+F: security/keys/trusted-keys/trusted-tee.c
+
KEYS/KEYRINGS:
M: David Howells <dhowells@redhat.com>
L: keyrings@vger.kernel.org
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v5 1/3] driver core: platform: Add an error message to platform_get_irq*()
From: Markus Elfring @ 2019-07-30 12:30 UTC (permalink / raw)
To: Stephen Boyd, Greg Kroah-Hartman, kernel-janitors, linux-doc
Cc: linux-kernel, Rob Herring, Bartlomiej Zolnierkiewicz,
Javier Martinez Canillas, Andrzej Hajda, Mark Brown, Russell King,
Marek Szyprowski, Rafael J . Wysocki, Andy Shevchenko
In-Reply-To: <20190730053845.126834-2-swboyd@chromium.org>
…
> +++ 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
> + *
> + * Gets an IRQ for a platform device and prints an error message if finding the
> + * IRQ fails. Device drivers should check the return value for errors so as to
> + * not pass a negative integer value to the request_irq() APIs.
> + *
> + * Example:
> + * int irq = platform_get_irq(pdev, 0);
> + * if (irq < 0)
> + * return irq;
> + *
> + * Return: IRQ number on success, negative error number on failure.
> + */
…
Thanks for your extension of the description for this programming interface.
I imagine that adjustments for this software documentation format can make it
safer to extract desired API properties.
Would you like to improve provided information any further?
Regards,
Markus
^ 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