* Re: [PATCH 0/6] ReST conversion patches not applied yet
From: Mark Brown @ 2019-07-31 21:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jonathan Corbet, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, alsa-devel, Maxime Ripard, samba-technical,
devicetree, Liam Girdwood, linux-iio, Lars-Peter Clausen,
Evgeniy Dushistov, Jonathan Cameron, Peter Meerwald-Stadler,
Steve French, Alexander Shishkin, Chen-Yu Tsai, Suzuki K Poulose,
linux-cifs, Dave Kleikamp, Mark Rutland, Evgeniy Polyakov,
Mathieu Poirier, Rob Herring, jfs-discussion, linux-arm-kernel,
Hartmut Knaack, linux-spi
In-Reply-To: <20190731182729.01c98cd3@coco.lan>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Wed, Jul 31, 2019 at 06:27:29PM -0300, Mauro Carvalho Chehab wrote:
> Meanwhile, if someone needs something that it is at the wrong book, he
> can just use some search tool to seek what he needs, no matter on
> what book the relevant information is stored.
OTOH it might be weird for the intended audience of the book.
> Mark Brown <broonie@kernel.org> escreveu:
> > I don't know if it makes sense to have an embedded developer's
> > manual as well?
> Yeah, that's a good question.
> Jon is planning todo a documentation track at LPC. One of the things
> that should be discussed, IMO, is how we'll organize the books.
I'll be at Plumbers, not sure what the schedule's looking like yet
though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v9 3/7] of/platform: Add functional dependency link from DT bindings
From: Saravana Kannan @ 2019-07-31 22:17 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, kbuild test robot, linux-doc, clang-built-linux
In-Reply-To: <20190731221721.187713-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.
kbuild test robot reported clang error about missing const
Reported-by: kbuild test robot <lkp@intel.com>
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..64c4b91988f2 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;
+ const 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 v4 3/3] f2fs: Support case-insensitive file name lookups
From: Chao Yu @ 2019-08-01 1:11 UTC (permalink / raw)
To: Nathan Chancellor, Daniel Rosenberg
Cc: Jaegeuk Kim, Jonathan Corbet, linux-f2fs-devel, linux-kernel,
linux-doc, linux-fsdevel, linux-api, kernel-team
In-Reply-To: <20190731175748.GA48637@archlinux-threadripper>
Hi Nathan,
Thanks for the report! :)
On 2019/8/1 1:57, Nathan Chancellor wrote:
> Hi all,
>
> <snip>
>
>> diff --git a/fs/f2fs/hash.c b/fs/f2fs/hash.c
>> index cc82f142f811f..99e79934f5088 100644
>> --- a/fs/f2fs/hash.c
>> +++ b/fs/f2fs/hash.c
>> @@ -14,6 +14,7 @@
>> #include <linux/f2fs_fs.h>
>> #include <linux/cryptohash.h>
>> #include <linux/pagemap.h>
>> +#include <linux/unicode.h>
>>
>> #include "f2fs.h"
>>
>> @@ -67,7 +68,7 @@ static void str2hashbuf(const unsigned char *msg, size_t len,
>> *buf++ = pad;
>> }
>>
>> -f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
>> +static f2fs_hash_t __f2fs_dentry_hash(const struct qstr *name_info,
>> struct fscrypt_name *fname)
>> {
>> __u32 hash;
>> @@ -103,3 +104,35 @@ f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
>> f2fs_hash = cpu_to_le32(hash & ~F2FS_HASH_COL_BIT);
>> return f2fs_hash;
>> }
>> +
>> +f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
>> + const struct qstr *name_info, struct fscrypt_name *fname)
>> +{
>> +#ifdef CONFIG_UNICODE
>> + struct f2fs_sb_info *sbi = F2FS_SB(dir->i_sb);
>> + const struct unicode_map *um = sbi->s_encoding;
>> + int r, dlen;
>> + unsigned char *buff;
>> + struct qstr *folded;
>> +
>> + if (name_info->len && IS_CASEFOLDED(dir)) {
>> + buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
>> + if (!buff)
>> + return -ENOMEM;
>> +
>> + dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
>> + if (dlen < 0) {
>> + kvfree(buff);
>> + goto opaque_seq;
>> + }
>> + folded->name = buff;
>> + folded->len = dlen;
>> + r = __f2fs_dentry_hash(folded, fname);
>> +
>> + kvfree(buff);
>> + return r;
>> + }
>> +opaque_seq:
>> +#endif
>> + return __f2fs_dentry_hash(name_info, fname);
>> +}
>
> Clang now warns:
>
> fs/f2fs/hash.c:128:3: warning: variable 'folded' is uninitialized when used here [-Wuninitialized]
> folded->name = buff;
> ^~~~~~
> fs/f2fs/hash.c:116:21: note: initialize the variable 'folded' to silence this warning
> struct qstr *folded;
> ^
> = NULL
> 1 warning generated.
>
> I assume that it wants to be initialized with f2fs_kzalloc as well but
> I am not familiar with this code and what it expects to do.
>
> Please look into this when you get a chance!
That should be a bug, it needs to define a struct qstr type variable rather than
a pointer there.
Jaegeuk, could you fix this in you branch?
Thanks,
> Nathan
> .
>
^ permalink raw reply
* [PATCH] mailmap: add entry for Gao Xiang
From: Chao Yu @ 2019-08-01 3:17 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, gaoxiang25, chao, Chao Yu
Add entry to connect all Gao Xiang's email addresses.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
---
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailmap b/.mailmap
index 4ff3f20b4f11..00588c37e99d 100644
--- a/.mailmap
+++ b/.mailmap
@@ -79,6 +79,8 @@ Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
Frank Zago <fzago@systemfabricworks.com>
+Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
+Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
Greg Kroah-Hartman <greg@echidna.(none)>
Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman <greg@kroah.com>
--
2.18.0.rc1
^ permalink raw reply related
* Re: [PATCH] mailmap: add entry for Gao Xiang
From: Gao Xiang @ 2019-08-01 3:31 UTC (permalink / raw)
To: Chao Yu, corbet; +Cc: linux-doc, chao, Miao Xie
In-Reply-To: <20190801031750.17094-1-yuchao0@huawei.com>
On 2019/8/1 11:17, Chao Yu wrote:
> Add entry to connect all Gao Xiang's email addresses.
>
> Signed-off-by: Chao Yu <yuchao0@huawei.com>
Acked-by: Gao Xiang <gaoxiang25@huawei.com>
Thanks,
Gao Xiang
^ permalink raw reply
* Re: [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Jaegeuk Kim @ 2019-08-01 4:05 UTC (permalink / raw)
To: Chao Yu
Cc: Nathan Chancellor, Daniel Rosenberg, Jonathan Corbet,
linux-f2fs-devel, linux-kernel, linux-doc, linux-fsdevel,
linux-api, kernel-team
In-Reply-To: <5d6c5da8-ad1e-26e2-0a3d-84949cd4e9aa@huawei.com>
On 08/01, Chao Yu wrote:
> Hi Nathan,
>
> Thanks for the report! :)
>
> On 2019/8/1 1:57, Nathan Chancellor wrote:
> > Hi all,
> >
> > <snip>
> >
> >> diff --git a/fs/f2fs/hash.c b/fs/f2fs/hash.c
> >> index cc82f142f811f..99e79934f5088 100644
> >> --- a/fs/f2fs/hash.c
> >> +++ b/fs/f2fs/hash.c
> >> @@ -14,6 +14,7 @@
> >> #include <linux/f2fs_fs.h>
> >> #include <linux/cryptohash.h>
> >> #include <linux/pagemap.h>
> >> +#include <linux/unicode.h>
> >>
> >> #include "f2fs.h"
> >>
> >> @@ -67,7 +68,7 @@ static void str2hashbuf(const unsigned char *msg, size_t len,
> >> *buf++ = pad;
> >> }
> >>
> >> -f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
> >> +static f2fs_hash_t __f2fs_dentry_hash(const struct qstr *name_info,
> >> struct fscrypt_name *fname)
> >> {
> >> __u32 hash;
> >> @@ -103,3 +104,35 @@ f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
> >> f2fs_hash = cpu_to_le32(hash & ~F2FS_HASH_COL_BIT);
> >> return f2fs_hash;
> >> }
> >> +
> >> +f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
> >> + const struct qstr *name_info, struct fscrypt_name *fname)
> >> +{
> >> +#ifdef CONFIG_UNICODE
> >> + struct f2fs_sb_info *sbi = F2FS_SB(dir->i_sb);
> >> + const struct unicode_map *um = sbi->s_encoding;
> >> + int r, dlen;
> >> + unsigned char *buff;
> >> + struct qstr *folded;
> >> +
> >> + if (name_info->len && IS_CASEFOLDED(dir)) {
> >> + buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
> >> + if (!buff)
> >> + return -ENOMEM;
> >> +
> >> + dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
> >> + if (dlen < 0) {
> >> + kvfree(buff);
> >> + goto opaque_seq;
> >> + }
> >> + folded->name = buff;
> >> + folded->len = dlen;
> >> + r = __f2fs_dentry_hash(folded, fname);
> >> +
> >> + kvfree(buff);
> >> + return r;
> >> + }
> >> +opaque_seq:
> >> +#endif
> >> + return __f2fs_dentry_hash(name_info, fname);
> >> +}
> >
> > Clang now warns:
> >
> > fs/f2fs/hash.c:128:3: warning: variable 'folded' is uninitialized when used here [-Wuninitialized]
> > folded->name = buff;
> > ^~~~~~
> > fs/f2fs/hash.c:116:21: note: initialize the variable 'folded' to silence this warning
> > struct qstr *folded;
> > ^
> > = NULL
> > 1 warning generated.
> >
> > I assume that it wants to be initialized with f2fs_kzalloc as well but
> > I am not familiar with this code and what it expects to do.
> >
> > Please look into this when you get a chance!
>
> That should be a bug, it needs to define a struct qstr type variable rather than
> a pointer there.
>
> Jaegeuk, could you fix this in you branch?
Yeah, let me apply this.
--- a/fs/f2fs/hash.c
+++ b/fs/f2fs/hash.c
@@ -113,25 +113,27 @@ f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
const struct unicode_map *um = sbi->s_encoding;
int r, dlen;
unsigned char *buff;
- struct qstr *folded;
+ struct qstr folded;
- if (name_info->len && IS_CASEFOLDED(dir)) {
- buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
- if (!buff)
- return -ENOMEM;
+ if (!name_info->len || !IS_CASEFOLDED(dir))
+ goto opaque_seq;
- dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
- if (dlen < 0) {
- kvfree(buff);
- goto opaque_seq;
- }
- folded->name = buff;
- folded->len = dlen;
- r = __f2fs_dentry_hash(folded, fname);
+ buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
+ if (!buff)
+ return -ENOMEM;
+ dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
+ if (dlen < 0) {
kvfree(buff);
- return r;
+ goto opaque_seq;
}
+ folded.name = buff;
+ folded.len = dlen;
+ r = __f2fs_dentry_hash(&folded, fname);
+
+ kvfree(buff);
+ return r;
+
opaque_seq:
#endif
return __f2fs_dentry_hash(name_info, fname);
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 6:21 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYOEqe1a1DCyVYKA+oZaZ0n5hnjxdubstUnrwdUW1-4xHw@mail.gmail.com>
On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > To clarify a bit further - my thought was to support any type of trust
> > source.
>
> That could be very well accomplished via Trusted Keys abstraction
> framework [1]. A trust source just need to implement following APIs:
>
> struct trusted_key_ops ts_trusted_key_ops = {
> .migratable = 0, /* non-migratable */
> .init = init_ts_trusted,
> .seal = ts_key_seal,
> .unseal = ts_key_unseal,
> .get_random = ts_get_random,
> .cleanup = cleanup_ts_trusted,
> };
Which is basically the same as implementing a new keytype in the
kernel; abstraction is not raised in any considerable manner this way?
I chose the userspace plugin due to this, you can use userspace aids
to provide any type of service. Use the crypto library you desire to
do the magic you want.
> > With the
> > user mode helper in between anyone can easily add their own thing in
> > there.
>
> Isn't actual purpose to have trusted keys is to protect user-space
> from access to kernel keys in plain format? Doesn't user mode helper
> defeat that purpose in one way or another?
Not really. CPU is in the user mode while running the code, but the
code or the secure keydata being is not available to the 'normal'
userspace. It's like microkernel service/driver this way. The usermode
driver is part of the kernel image and it runs on top of a invisible
rootfs.
--
Janne
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 6:36 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYOKcOzSwakHhgshZcebD8ZBMSi7xQdjWYFS79=Xc+odOg@mail.gmail.com>
On Wed, Jul 31, 2019 at 5:23 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > I guess my wording was wrong, tried to say that physical TEEs in the
> > wild vary massively hardware wise. Generalizing these things is rough.
> >
>
> There are already well defined GlobalPlatform Standards to generalize
> the TEE interface. One of them is GlobalPlatform TEE Client API [1]
> which provides the basis for this TEE interface.
I'm aware of it - I have implemented a large part of the GP TEE APIs
earlier (primarily the crypto functions). Does the TEE you work with
actually support GP properly? Can I take a look at the code?
Normally the TEE implementations are well-guarded secrets and the
state of the implementation is quite random. In many cases keeping
things secret is fine from my point of view, given that it is a RoT
after all. The secrecy is the core business here. So, this is why I
opted the userspace 'secret' route - no secrets in the kernel, but
it's fine for the userspace. Umh was a logical fit to implement it.
--
Janne
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Rouven Czerwinski @ 2019-08-01 6:50 UTC (permalink / raw)
To: Janne Karhunen, Sumit Garg
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
jejb, Ard Biesheuvel, Linux Doc Mailing List, Jarkko Sakkinen,
Linux Kernel Mailing List, dhowells, linux-security-module,
keyrings, Mimi Zohar, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <CAE=NcrYz8bT9zDhS_ZcvY84fpeTDxZ-KhJKeQGGyf=o4pG2J-Q@mail.gmail.com>
On Thu, 2019-08-01 at 09:36 +0300, Janne Karhunen wrote:
> On Wed, Jul 31, 2019 at 5:23 PM Sumit Garg <sumit.garg@linaro.org>
> wrote:
>
> > > I guess my wording was wrong, tried to say that physical TEEs in
> > > the
> > > wild vary massively hardware wise. Generalizing these things is
> > > rough.
> > >
> >
> > There are already well defined GlobalPlatform Standards to
> > generalize
> > the TEE interface. One of them is GlobalPlatform TEE Client API [1]
> > which provides the basis for this TEE interface.
>
> I'm aware of it - I have implemented a large part of the GP TEE APIs
> earlier (primarily the crypto functions). Does the TEE you work with
> actually support GP properly? Can I take a look at the code?
AFAIK Sumit is working with the OP-TEE implementation, which can be
found on github: https://github.com/op-tee/optee_os
Regards,
Rouven
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 7:30 UTC (permalink / raw)
To: Rouven Czerwinski
Cc: Sumit Garg, tee-dev @ lists . linaro . org, Daniel Thompson,
Jonathan Corbet, jejb, Ard Biesheuvel, Linux Doc Mailing List,
Jarkko Sakkinen, Linux Kernel Mailing List, dhowells,
linux-security-module, keyrings, Mimi Zohar, Casey Schaufler,
linux-integrity, linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <19d9be198619e951750dedeb4d0a7f372083b42c.camel@pengutronix.de>
On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski
<r.czerwinski@pengutronix.de> wrote:
> > I'm aware of it - I have implemented a large part of the GP TEE APIs
> > earlier (primarily the crypto functions). Does the TEE you work with
> > actually support GP properly? Can I take a look at the code?
>
> AFAIK Sumit is working with the OP-TEE implementation, which can be
> found on github: https://github.com/op-tee/optee_os
Thanks, I will take a look. The fundamental problem with these things
is that there are infinite amount of ways how TEEs and ROTs can be
done in terms of the hardware and software. I really doubt there are 2
implementations in existence that are even remotely compatible in real
life. As such, all things TEE/ROT would logically really belong in the
userland and thanks to the bpfilter folks now the umh logic really
makes that possible ... I think. The key implementation I did was just
an RFC on the concept, what if we start to move the stuff that really
belongs in the userspace to this pseudo-userland. It's not kernel, but
it's not commonly accessible userland either. The shared memory would
also work without any modifications between the umh based TEE/ROT
driver and the userland if needed.
Anyway, just my .02c. I guess having any new support in the kernel for
new trust sources is good and improvement from the current state. I
can certainly make my stuff work with your setup as well, what ever
people think is the best.
--
Janne
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 7:40 UTC (permalink / raw)
To: Janne Karhunen
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAE=NcraDkm5cxE=ceq_9XkQz=NZ6KdVXkNUsdD4G2LrWz-bpDw@mail.gmail.com>
On Thu, 1 Aug 2019 at 11:51, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > To clarify a bit further - my thought was to support any type of trust
> > > source.
> >
> > That could be very well accomplished via Trusted Keys abstraction
> > framework [1]. A trust source just need to implement following APIs:
> >
> > struct trusted_key_ops ts_trusted_key_ops = {
> > .migratable = 0, /* non-migratable */
> > .init = init_ts_trusted,
> > .seal = ts_key_seal,
> > .unseal = ts_key_unseal,
> > .get_random = ts_get_random,
> > .cleanup = cleanup_ts_trusted,
> > };
>
> Which is basically the same as implementing a new keytype in the
> kernel; abstraction is not raised in any considerable manner this way?
>
It doesn't create a new keytype. There is only single keytype:
"trusted" which could be implemented via one of the trust source
available in the system like TPM, TEE etc.
> I chose the userspace plugin due to this, you can use userspace aids
> to provide any type of service. Use the crypto library you desire to
> do the magic you want.
Here TEE isn't similar to a user-space crypto library. In our case TEE
is based on ARM TrustZone which only allows TEE communications to be
initiated from privileged mode. So why would you like to route
communications via user-mode (which is less secure) when we have
standardised TEE interface available in kernel?
>
>
> > > With the
> > > user mode helper in between anyone can easily add their own thing in
> > > there.
> >
> > Isn't actual purpose to have trusted keys is to protect user-space
> > from access to kernel keys in plain format? Doesn't user mode helper
> > defeat that purpose in one way or another?
>
> Not really. CPU is in the user mode while running the code, but the
> code or the secure keydata being is not available to the 'normal'
> userspace. It's like microkernel service/driver this way. The usermode
> driver is part of the kernel image and it runs on top of a invisible
> rootfs.
>
Can you elaborate here with an example regarding how this user-mode
helper will securely communicate with a hardware based trust source
with other user-space processes denied access to that trust source?
-Sumit
>
> --
> Janne
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 7:58 UTC (permalink / raw)
To: Janne Karhunen
Cc: Rouven Czerwinski, tee-dev @ lists . linaro . org,
Daniel Thompson, Jonathan Corbet, jejb, Ard Biesheuvel,
Linux Doc Mailing List, Jarkko Sakkinen,
Linux Kernel Mailing List, dhowells, linux-security-module,
keyrings, Mimi Zohar, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <CAE=NcraqD9FNM0Gk9UGhPGi3heVzZrAKGc1gNZxoe1OnDaQ=pA@mail.gmail.com>
On Thu, 1 Aug 2019 at 13:00, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski
> <r.czerwinski@pengutronix.de> wrote:
>
> > > I'm aware of it - I have implemented a large part of the GP TEE APIs
> > > earlier (primarily the crypto functions). Does the TEE you work with
> > > actually support GP properly? Can I take a look at the code?
> >
> > AFAIK Sumit is working with the OP-TEE implementation, which can be
> > found on github: https://github.com/op-tee/optee_os
>
> Thanks, I will take a look.
For documentation, refer to: https://optee.readthedocs.io/
> The fundamental problem with these things
> is that there are infinite amount of ways how TEEs and ROTs can be
> done in terms of the hardware and software. I really doubt there are 2
> implementations in existence that are even remotely compatible in real
> life.
I agree with you regarding implementation specific nature of TEE but
having a standardized client interface does solves the problem.
> As such, all things TEE/ROT would logically really belong in the
> userland and thanks to the bpfilter folks now the umh logic really
> makes that possible ... I think. The key implementation I did was just
> an RFC on the concept, what if we start to move the stuff that really
> belongs in the userspace to this pseudo-userland. It's not kernel, but
> it's not commonly accessible userland either. The shared memory would
> also work without any modifications between the umh based TEE/ROT
> driver and the userland if needed.
>
> Anyway, just my .02c. I guess having any new support in the kernel for
> new trust sources is good and improvement from the current state. I
> can certainly make my stuff work with your setup as well, what ever
> people think is the best.
Yes your implementation can very well fit under trusted keys
abstraction framework without creating a new keytype: "ext-trusted".
-Sumit
>
>
> --
> Janne
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 7:59 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYMOXQbL5OeheFUFpTr8gte8XHHr-71-h8+qX0+R_sekDQ@mail.gmail.com>
On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > I chose the userspace plugin due to this, you can use userspace aids
> > to provide any type of service. Use the crypto library you desire to
> > do the magic you want.
>
> Here TEE isn't similar to a user-space crypto library. In our case TEE
> is based on ARM TrustZone which only allows TEE communications to be
> initiated from privileged mode. So why would you like to route
> communications via user-mode (which is less secure) when we have
> standardised TEE interface available in kernel?
The physical access guards for reading/writing the involved critical
memory are identical as far as I know? Layered security is generally a
good thing, and the userspace pass actually adds a layer, so not sure
which is really safer?
In my case the rerouting was to done generalize it. Any type of trust
source, anywhere.
> > > Isn't actual purpose to have trusted keys is to protect user-space
> > > from access to kernel keys in plain format? Doesn't user mode helper
> > > defeat that purpose in one way or another?
> >
> > Not really. CPU is in the user mode while running the code, but the
> > code or the secure keydata being is not available to the 'normal'
> > userspace. It's like microkernel service/driver this way. The usermode
> > driver is part of the kernel image and it runs on top of a invisible
> > rootfs.
>
> Can you elaborate here with an example regarding how this user-mode
> helper will securely communicate with a hardware based trust source
> with other user-space processes denied access to that trust source?
The other user mode processes will never see the device node to open.
There is none in existence for them; it only exists in the ramfs based
root for the user mode helper.
--
Janne
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 8:30 UTC (permalink / raw)
To: Sumit Garg
Cc: Rouven Czerwinski, tee-dev @ lists . linaro . org,
Daniel Thompson, Jonathan Corbet, jejb, Ard Biesheuvel,
Linux Doc Mailing List, Jarkko Sakkinen,
Linux Kernel Mailing List, dhowells, linux-security-module,
keyrings, Mimi Zohar, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <CAFA6WYPt4q+jaJbaoauXKr2qKgBHvtQ663s4t=W3nuPJPe2xpw@mail.gmail.com>
On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > Anyway, just my .02c. I guess having any new support in the kernel for
> > new trust sources is good and improvement from the current state. I
> > can certainly make my stuff work with your setup as well, what ever
> > people think is the best.
>
> Yes your implementation can very well fit under trusted keys
> abstraction framework without creating a new keytype: "ext-trusted".
The fundamental problem with the 'standardized kernel tee' still
exists - it will never be generic in real life. Getting all this in
the kernel will solve your problem and sell this particular product,
but it is quite unlikely to help that many users. If the security is
truly important to you, would you really trust any of this code to
someone else? In this day and age, I really doubt many do. Everyone
does their own thing, so this is why I really see all that as a
userspace problem.
--
Janne
^ permalink raw reply
* Re: [PATCH] doc:it_IT: translations for documents in process/
From: Federico Vaga @ 2019-08-01 9:37 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-kernel, Alessia Mantegazza
In-Reply-To: <20190731125124.46e06ab6@lwn.net>
On Wednesday, July 31, 2019 8:51:24 PM CEST Jonathan Corbet wrote:
> On Sun, 28 Jul 2019 11:20:54 +0200
>
> Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > From: Alessia Mantegazza <amantegazza@vaga.pv.it>
> >
> > Translations for the following documents in process/:
> > - email-clients
> > - management-style
> >
> > Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it>
> > Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
>
> This looks generally good, but I have to ask...
>
> > +Se la patch che avete inserito dev'essere modificata usato la finestra di
> > +scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia
> > +disabilitata
> > :menuselection:`Configurazione-->Preferenze-->Composizione-->Interruzione
> > riga`.
> Have you actually verified that the translations used in these mail
> clients matches what you have here?
Yep, I've installed all of them and gone through all menus.
But I just noticed a typo in the quoted statement, I will send a new patch:
"modificata usato" -> "modificata usando"
>
> Thanks,
>
> jon
--
Federico Vaga
http://www.federicovaga.it/
^ permalink raw reply
* Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Peter Zijlstra @ 2019-08-01 9:51 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Ingo Molnar, lizefan, Johannes Weiner, axboe, Dennis Zhou,
Dennis Zhou, Andrew Morton, linux-mm, linux-doc, LKML,
kernel-team, Nick Kralevich, Thomas Gleixner
In-Reply-To: <CAJuCfpH7NpuYKv-B9-27SpQSKhkzraw0LZzpik7_cyNMYcqB2Q@mail.gmail.com>
On Tue, Jul 30, 2019 at 10:44:51AM -0700, Suren Baghdasaryan wrote:
> On Tue, Jul 30, 2019 at 1:11 AM Peter Zijlstra <peterz@infradead.org> 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 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 !?
>
> We need psi poll_kworker to be an rt-priority thread so that psi
There is a giant difference between 'needs to be higher than OTHER' and
FIFO-99.
> notifications are delivered to the userspace without delay even when
> the CPUs are very congested. Otherwise it's easy to delay psi
> notifications by running a simple CPU hogger executing "chrt -f 50 dd
> if=/dev/zero of=/dev/null". Because these notifications are
So what; at that point that's exactly what you're asking for. Using RT
is for those who know what they're doing.
> time-critical for reacting to memory shortages we can't allow for such
> delays.
Furthermore, actual RT programs will have pre-allocated and locked any
memory they rely on. They don't give a crap about your pressure
nonsense.
> Notice that this kworker is created only if userspace creates a psi
> trigger. So unless you are using psi triggers you will never see this
> kthread created.
By marking it FIFO-99 you're in effect saying that your stupid
statistics gathering is more important than your life. It will preempt
the task that's in control of the band-saw emergency break, it will
preempt the task that's adjusting the electromagnetic field containing
this plasma flow.
That's insane.
I'm going to queue a patch to reduce this to FIFO-1, that will preempt
regular OTHER tasks but will not perturb (much) actual RT bits.
^ permalink raw reply
* Re: [PATCH] doc:it_IT: translations for documents in process/
From: Federico Vaga @ 2019-08-01 9:53 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-kernel, Alessia Mantegazza
In-Reply-To: <20864529.Q1CKeA7GMu@pcbe13614>
On Thursday, August 1, 2019 11:37:58 AM CEST Federico Vaga wrote:
> On Wednesday, July 31, 2019 8:51:24 PM CEST Jonathan Corbet wrote:
> > On Sun, 28 Jul 2019 11:20:54 +0200
> >
> > Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > > From: Alessia Mantegazza <amantegazza@vaga.pv.it>
> > >
> > > Translations for the following documents in process/:
> > > - email-clients
> > > - management-style
> > >
> > > Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it>
> > > Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
> >
> > This looks generally good, but I have to ask...
> >
> > > +Se la patch che avete inserito dev'essere modificata usato la finestra
> > > di
> > > +scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia
> > > +disabilitata
> > >
> > > :menuselection:`Configurazione-->Preferenze-->Composizione-->Interruzion
> > > :e
> > >
> > > riga`.
> >
> > Have you actually verified that the translations used in these mail
> > clients matches what you have here?
>
> Yep, I've installed all of them and gone through all menus.
P.S.
Of course, I checked on the version available on my distribution. I did not
look for translation changes on different version of the same email client @_@
But even if I do it, there is no "nice" solution to the problem
> But I just noticed a typo in the quoted statement, I will send a new patch:
>
> "modificata usato" -> "modificata usando"
>
> > Thanks,
> >
> > jon
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 10:00 UTC (permalink / raw)
To: Janne Karhunen
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAE=Ncrae6pM+WBDu9eJ7Fw2Fkvf3_YqH5tj9Tt938D4RtWcdSQ@mail.gmail.com>
On Thu, 1 Aug 2019 at 13:30, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > I chose the userspace plugin due to this, you can use userspace aids
> > > to provide any type of service. Use the crypto library you desire to
> > > do the magic you want.
> >
> > Here TEE isn't similar to a user-space crypto library. In our case TEE
> > is based on ARM TrustZone which only allows TEE communications to be
> > initiated from privileged mode. So why would you like to route
> > communications via user-mode (which is less secure) when we have
> > standardised TEE interface available in kernel?
>
> The physical access guards for reading/writing the involved critical
> memory are identical as far as I know? Layered security is generally a
> good thing, and the userspace pass actually adds a layer, so not sure
> which is really safer?
>
AFAIK, layered security is better in case we move from lower privilege
level to higher privilege level rather than in reverse order.
-Sumit
> In my case the rerouting was to done generalize it. Any type of trust
> source, anywhere.
>
>
> > > > Isn't actual purpose to have trusted keys is to protect user-space
> > > > from access to kernel keys in plain format? Doesn't user mode helper
> > > > defeat that purpose in one way or another?
> > >
> > > Not really. CPU is in the user mode while running the code, but the
> > > code or the secure keydata being is not available to the 'normal'
> > > userspace. It's like microkernel service/driver this way. The usermode
> > > driver is part of the kernel image and it runs on top of a invisible
> > > rootfs.
> >
> > Can you elaborate here with an example regarding how this user-mode
> > helper will securely communicate with a hardware based trust source
> > with other user-space processes denied access to that trust source?
>
> The other user mode processes will never see the device node to open.
> There is none in existence for them; it only exists in the ramfs based
> root for the user mode helper.
>
>
> --
> Janne
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 10:27 UTC (permalink / raw)
To: Janne Karhunen
Cc: Rouven Czerwinski, tee-dev @ lists . linaro . org,
Daniel Thompson, Jonathan Corbet, jejb, Ard Biesheuvel,
Linux Doc Mailing List, Jarkko Sakkinen,
Linux Kernel Mailing List, dhowells, linux-security-module,
keyrings, Mimi Zohar, Casey Schaufler, linux-integrity,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <CAE=NcrbujsM8wYJXq+s=o5Vy1xY1b0uKYBGvp6UP5ex70HrB2Q@mail.gmail.com>
On Thu, 1 Aug 2019 at 14:00, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > Anyway, just my .02c. I guess having any new support in the kernel for
> > > new trust sources is good and improvement from the current state. I
> > > can certainly make my stuff work with your setup as well, what ever
> > > people think is the best.
> >
> > Yes your implementation can very well fit under trusted keys
> > abstraction framework without creating a new keytype: "ext-trusted".
>
> The fundamental problem with the 'standardized kernel tee' still
> exists - it will never be generic in real life. Getting all this in
> the kernel will solve your problem and sell this particular product,
> but it is quite unlikely to help that many users. If the security is
> truly important to you, would you really trust any of this code to
> someone else? In this day and age, I really doubt many do.
There are already multiple platforms supported by OP-TEE [1] which
could benefit from this trusted keys interface.
> Everyone
> does their own thing, so this is why I really see all that as a
> userspace problem.
>
IMO, we should try to use standardized interfaces which are well
thought off rather than implementing your own.
[1] https://optee.readthedocs.io/general/platforms.html
-Sumit
>
> --
> Janne
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 10:40 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYOwcO5-cyaJf3tMMAdyVHJo=BzmCWtsjA3S8aj5g-GZxQ@mail.gmail.com>
On Thu, Aug 1, 2019 at 1:00 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > Here TEE isn't similar to a user-space crypto library. In our case TEE
> > > is based on ARM TrustZone which only allows TEE communications to be
> > > initiated from privileged mode. So why would you like to route
> > > communications via user-mode (which is less secure) when we have
> > > standardised TEE interface available in kernel?
> >
> > The physical access guards for reading/writing the involved critical
> > memory are identical as far as I know? Layered security is generally a
> > good thing, and the userspace pass actually adds a layer, so not sure
> > which is really safer?
>
> AFAIK, layered security is better in case we move from lower privilege
> level to higher privilege level rather than in reverse order.
You can look at this in many ways. Another way to look at it is that
the services should be provided with the least amount of permissions
required for the task. Further you can containerize something, the
better.
As for your PLATFORMS support: it is all nice, but there is no way to
convince op-tee or any other tee to be adopted by many real users.
Every serious user can and will do their own thing, or at very best,
buy it from someone who did their own thing and is trusted. There is
zero chance that samsung, huawei, apple, nsa, google, rambus, payment
system vendors, .. would actually share the tee (or probably even the
interfaces). It is just too vital and people do not trust each other
anymore :(
Anyway, enough about the topic from my side. I guess people will tell
what they want, I'm fine with any, and it is all progress from the
current state :)
--
Janne
^ permalink raw reply
* Re: [RFC v2 0/8] arm64: MMU enabled kexec relocation
From: Pavel Tatashin @ 2019-08-01 13:24 UTC (permalink / raw)
To: Pavel Tatashin, James Morris, Sasha Levin, Eric W. Biederman,
kexec mailing list, LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM, Marc Zyngier, James Morse,
Vladimir Murzin, Matthias Brugger, Bhupesh Sharma
In-Reply-To: <20190731153857.4045-1-pasha.tatashin@soleen.com>
I will send a new version soon, so please do not spend time reviewing
this work. In the new version I will fix MMU at EL2 issue by doing
what we are doing in hibernation: reduce to EL1 to do the copying, and
escalate back to to EL2 to branch to new kernel. Also, this will
simplify copying function by actually doing the linear copy as ttbr1
and ttbr0 are always available this way.
Thank you,
Pasha
On Wed, Jul 31, 2019 at 11:38 AM Pavel Tatashin
<pasha.tatashin@soleen.com> wrote:
>
> Changelog from previous RFC:
> - Added trans_table support for both hibernate and kexec.
> - Fixed performance issue, where enabling MMU did not yield the
> actual performance improvement.
>
> Bug:
> With the current state, this patch series works on kernels booted with EL1
> mode, but for some reason, when elevated to EL2 mode reboot freezes in
> both QEMU and on real hardware.
>
> The freeze happens in:
>
> arch/arm64/kernel/relocate_kernel.S
> turn_on_mmu()
>
> Right after sctlr_el2 is written (MMU on EL2 is enabled)
>
> msr sctlr_el2, \tmp1
>
> I've been studying all the relevant control registers for EL2, but do not
> see what might be causing this hang:
>
> MAIR_EL2 is set to be exactly the same as MAIR_EL1 0xbbff440c0400
>
> TCR_EL2 0x80843510
> Enabled bits:
> PS Physical Address Size. (0b100 44 bits, 16TB.)
> SH0 Shareability 11 Inner Shareable
> ORGN0 Normal memory, Outer Write-Back Read-Allocate Write-Allocate Cach.
> IRGN0 Normal memory, Inner Write-Back Read-Allocate Write-Allocate Cach.
> T0SZ 01 0000
>
> SCTLR_EL2 0x30e5183f
> RES1 : Reserve ones
> M : MMU enabled
> A : Align check
> C : Cacheability control
> SA : SP Alignment check enable
> IESB : Implicit Error Synchronization event
> I : Instruction access Cacheability
>
> TTBR0_EL2 0x1b3069000 (address of trans_table)
>
> Any suggestion of what else might be missing that causes this freeze when
> MMU is enabled in EL2?
>
> =====
> Here is the current data from the real hardware:
> (because of bug, I forced EL1 mode by setting el2_switch always to zero in
> cpu_soft_restart()):
>
> For this experiment, the size of kernel plus initramfs is 25M. If initramfs
> was larger, than the improvements would be even greater, as time spent in
> relocation is proportional to the size of relocation.
>
> Previously:
> kernel shutdown 0.022131328s
> relocation 0.440510736s
> kernel startup 0.294706768s
>
> Relocation was taking: 58.2% of reboot time
>
> Now:
> kernel shutdown 0.032066576s
> relocation 0.022158152s
> kernel startup 0.296055880s
>
> Now: Relocation takes 6.3% of reboot time
>
> Total reboot is x2.16 times faster.
>
> Previous approaches and discussions
> -----------------------------------
> https://lore.kernel.org/lkml/20190709182014.16052-1-pasha.tatashin@soleen.com
> reserve space for kexec to avoid relocation, involves changes to generic code
> to optimize a problem that exists on arm64 only:
>
> https://lore.kernel.org/lkml/20190716165641.6990-1-pasha.tatashin@soleen.com
> The first attempt to enable MMU, some bugs that prevented performance
> improvement. The page tables unnecessary configured idmap for the whole
> physical space.
>
> Pavel Tatashin (8):
> kexec: quiet down kexec reboot
> arm64, mm: transitional tables
> arm64: hibernate: switch to transtional page tables.
> kexec: add machine_kexec_post_load()
> arm64, kexec: move relocation function setup and clean up
> arm64, kexec: add expandable argument to relocation function
> arm64, kexec: configure transitional page table for kexec
> arm64, kexec: enable MMU during kexec relocation
>
> arch/arm64/Kconfig | 4 +
> arch/arm64/include/asm/kexec.h | 24 ++-
> arch/arm64/include/asm/pgtable-hwdef.h | 1 +
> arch/arm64/include/asm/trans_table.h | 66 ++++++
> arch/arm64/kernel/asm-offsets.c | 10 +
> arch/arm64/kernel/cpu-reset.S | 4 +-
> arch/arm64/kernel/cpu-reset.h | 8 +-
> arch/arm64/kernel/hibernate.c | 261 ++++++------------------
> arch/arm64/kernel/machine_kexec.c | 168 ++++++++++++---
> arch/arm64/kernel/relocate_kernel.S | 238 +++++++++++++++-------
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/trans_table.c | 272 +++++++++++++++++++++++++
> kernel/kexec.c | 4 +
> kernel/kexec_core.c | 8 +-
> kernel/kexec_file.c | 4 +
> kernel/kexec_internal.h | 2 +
> 16 files changed, 756 insertions(+), 319 deletions(-)
> create mode 100644 arch/arm64/include/asm/trans_table.h
> create mode 100644 arch/arm64/mm/trans_table.c
>
> --
> 2.22.0
>
^ permalink raw reply
* Re: [PATCH] doc:it_IT: translations for documents in process/
From: Jonathan Corbet @ 2019-08-01 14:00 UTC (permalink / raw)
To: Federico Vaga; +Cc: linux-doc, linux-kernel, Alessia Mantegazza
In-Reply-To: <1695846.t893fQQLz3@pcbe13614>
On Thu, 1 Aug 2019 11:53:06 +0200
Federico Vaga <federico.vaga@cern.ch> wrote:
> Of course, I checked on the version available on my distribution. I did not
> look for translation changes on different version of the same email client @_@
Hmm...normally we expect you to check all versions back to the 1991
release of the 0.01 kernel...:) I think that your diligence is more than
sufficiently due, thanks.
jon
^ permalink raw reply
* Re: [PATCH v8 0/2] fTPM: firmware TPM running in TEE
From: Jarkko Sakkinen @ 2019-08-01 16:35 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Sasha Levin, peterhuewe, jgg, corbet, linux-kernel, linux-doc,
linux-integrity, linux-kernel, thiruan, bryankel, tee-dev,
sumit.garg, rdunlap
In-Reply-To: <20190715090525.GA28477@apalos>
On Mon, Jul 15, 2019 at 12:05:25PM +0300, Ilias Apalodimas wrote:
> On Fri, Jul 12, 2019 at 06:37:58AM +0300, Jarkko Sakkinen wrote:
> > On Thu, Jul 11, 2019 at 11:10:59PM +0300, Ilias Apalodimas wrote:
> > > Will report back any issues when we start using it on real hardware
> > > rather than QEMU
> > >
> > > Thanks
> > > /Ilias
> >
> > That would awesome. PR is far away so there is time to add more
> > tested-by's. Thanks.
> >
>
> I tested the basic fucntionality on QEMU and with the code only built as a
> module. You can add my tested-by on this if you want
Thank you. Added.
/Jarkko
^ permalink raw reply
* Re: [PATCH v4] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-08-01 17:43 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-kernel, linux-integrity, linux-doc, tweek, matthewgarrett,
jorhand, rdunlap, Sasha Levin
In-Reply-To: <20190731133948.1a527db8@lwn.net>
On Wed, Jul 31, 2019 at 01:39:48PM -0600, Jonathan Corbet wrote:
> On Fri, 12 Jul 2019 18:44:32 +0300
> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
>
> > There are some weird quirks when it comes to UEFI event log. Provide a
> > brief introduction to TPM event log mechanism and describe the quirks
> > and how they can be sorted out.
> >
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> > v4: - Unfortanely -> Unfortunately
> > v3: - Add a section for refs and use a bullet list to enumerate them.
> > - Remove an invalid author info.
> > v2: - Fix one typo.
> > - Refine the last paragraph to better explain how the two halves
> > of the event log are concatenated.
> > Documentation/security/tpm/index.rst | 1 +
> > Documentation/security/tpm/tpm_event_log.rst | 55 ++++++++++++++++++++
> > 2 files changed, 56 insertions(+)
> > create mode 100644 Documentation/security/tpm/tpm_event_log.rst
>
> I've applied this, thanks. Before I could do so, though, I had to edit
> the headers, which read:
>
> > Content-Type: text/plain; charset=y
>
> "git am" *really* doesn't like "charset=y". I think this is something
> that git send-email likes to do occasionally, don't know why...
Thank you!
/Jarkko
^ permalink raw reply
* Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator
From: Suren Baghdasaryan @ 2019-08-01 18:28 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, lizefan, Johannes Weiner, axboe, Dennis Zhou,
Dennis Zhou, Andrew Morton, linux-mm, linux-doc, LKML,
kernel-team, Nick Kralevich, Thomas Gleixner
In-Reply-To: <20190801095112.GA31381@hirez.programming.kicks-ass.net>
Hi Peter,
Thanks for sharing your thoughts. I understand your point and I tend
to agree with it. I originally designed this using watchdog as the
example of a critical system health signal and in the context of
mobile device memory pressure is critical but I agree that there are
more important things in life. I checked and your proposal to change
it to FIFO-1 should still work for our purposes. Will test to make
sure and reply to your patch. Couple clarifications in-line.
On Thu, Aug 1, 2019 at 2:51 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Jul 30, 2019 at 10:44:51AM -0700, Suren Baghdasaryan wrote:
> > On Tue, Jul 30, 2019 at 1:11 AM Peter Zijlstra <peterz@infradead.org> 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 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 !?
> >
> > We need psi poll_kworker to be an rt-priority thread so that psi
>
> There is a giant difference between 'needs to be higher than OTHER' and
> FIFO-99.
>
> > notifications are delivered to the userspace without delay even when
> > the CPUs are very congested. Otherwise it's easy to delay psi
> > notifications by running a simple CPU hogger executing "chrt -f 50 dd
> > if=/dev/zero of=/dev/null". Because these notifications are
>
> So what; at that point that's exactly what you're asking for. Using RT
> is for those who know what they're doing.
>
> > time-critical for reacting to memory shortages we can't allow for such
> > delays.
>
> Furthermore, actual RT programs will have pre-allocated and locked any
> memory they rely on. They don't give a crap about your pressure
> nonsense.
>
This signal is used not to protect other RT tasks but to monitor
overall system memory health for the sake of system responsiveness.
> > Notice that this kworker is created only if userspace creates a psi
> > trigger. So unless you are using psi triggers you will never see this
> > kthread created.
>
> By marking it FIFO-99 you're in effect saying that your stupid
> statistics gathering is more important than your life. It will preempt
> the task that's in control of the band-saw emergency break, it will
> preempt the task that's adjusting the electromagnetic field containing
> this plasma flow.
>
> That's insane.
IMHO an opt-in feature stops being "stupid" as soon as the user opted
in to use it, therefore explicitly indicating interest in it. However
I assume you are using "stupid" here to indicate that it's "less
important" rather than it's "useless".
> I'm going to queue a patch to reduce this to FIFO-1, that will preempt
> regular OTHER tasks but will not perturb (much) actual RT bits.
>
Thanks for posting the fix.
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>
^ 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