* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-11 15:05 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-11 15:05 UTC (permalink / raw)
To: ebiederm, containers
Cc: lkp, linux-kernel, zohar, tycho, serge, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey,
Stefan Berger
From: Stefan Berger <stefanb@linux.vnet.ibm.com>
This patch enables security.capability in user namespaces but also
takes a more general approach to enabling extended attributes in user
namespaces.
The following rules describe the approach using security.foo as a
'user namespace enabled' extended attribute:
Reading of extended attributes:
1a) Reading security.foo from a user namespace will read
security.foo@uid=<uid> of the parent user namespace instead with uid
being the mapping of root in that parent user namespace. An
exception is if root is mapped to uid 0 on the host, and in this case
we will read security.foo directly.
--> reading security.foo will read security.foo@uid=1000 for uid
mapping of root to 1000.
1b) If security.foo@uid=<uid> is not available, the security.foo of the
parent namespace is tried to be read. This procedure is repeated up to
the init user namespace. This step only applies for reading of extended
attributes and provides the same behavior as older system where the
host's extended attributes applied to user namespaces.
2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
can be read. The uid within the user namespace will be mapped to the
corresponding uid on the host and that uid will be used in the name of
the extended attribute.
-> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
mapping of root to 1000, size of at least 2.
All security.foo@uid=<uid> can be read (by root) on the host with values
of <uid> also being subject to checking for valid mappings.
3) No other security.foo* can be read.
The same rules for reading apply to writing and removing of user
namespace enabled extended attributes.
When listing extended attributes of a file, only those are presented
to the user namespace that have a valid mapping. Besides that, names
of the extended attributes are adjusted to represent the mapping.
This means that if root is mapped to uid 1000 on the host, the
security.foo@uid=1000 will be listed as security.foo in the user
namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Serge Hallyn <serge@hallyn.com>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
---
fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
security/commoncap.c | 36 +++-
security/selinux/hooks.c | 9 +-
3 files changed, 523 insertions(+), 31 deletions(-)
diff --git a/fs/xattr.c b/fs/xattr.c
index 464c94b..eacad9e 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
return inode_permission(inode, mask);
}
+/*
+ * A list of extended attributes that are supported in user namespaces
+ */
+static const char *const userns_xattrs[] = {
+ XATTR_NAME_CAPS,
+ NULL
+};
+
+/*
+ * xattrs_is_userns_supported - Check whether an xattr is supported in userns
+ *
+ * @name: full name of the extended attribute
+ * @prefix: do a prefix match (true) or a full match (false)
+ *
+ * This function returns < 0 if not supported, an index into userns_xattrs[]
+ * otherwise.
+ */
+static int
+xattr_is_userns_supported(const char *name, int prefix)
+{
+ int i;
+
+ if (!name)
+ return -1;
+
+ for (i = 0; userns_xattrs[i]; i++) {
+ if (prefix) {
+ if (!strncmp(userns_xattrs[i], name,
+ strlen(userns_xattrs[i])))
+ return i;
+ } else {
+ if (!strcmp(userns_xattrs[i], name))
+ return i;
+ }
+ }
+ return -1;
+}
+
+/*
+ * xattr_write_uid - print a string in the format of "%s@uid=%u", which
+ * includes a prefix string
+ *
+ * @uid: the uid
+ * @prefix: prefix string; may be NULL
+ *
+ * This function returns a buffer with the string, or a NULL pointer in
+ * case of out-of-memory error.
+ */
+static char *
+xattr_write_uid(uid_t uid, const char *prefix)
+{
+ size_t buflen;
+ char *buffer;
+
+ buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
+ if (prefix)
+ buflen += strlen(prefix);
+
+ buffer = kmalloc(buflen, GFP_KERNEL);
+ if (!buffer)
+ return NULL;
+
+ if (uid == 0)
+ *buffer = 0;
+ else
+ sprintf(buffer, "%s@uid=%u",
+ (prefix) ? prefix : "",
+ uid);
+
+ return buffer;
+}
+
+/*
+ * xattr_parse_uid_from_kuid - parse string in the format @uid=<uid>; consider
+ * user namespaces and check mappings
+ *
+ * @uidstr : string in the format "@uid=<uid>"
+ * @userns : the user namespace to consult for uid mappings
+ * @n_uidstr : returned pointer holding the rewritten @uid=<uid> string with
+ * the uid remapped
+ *
+ * This function returns an error code or 0 in case of success. In case
+ * of success, 'n_uidstr' will hold a valid string.
+ */
+static int
+xattr_parse_uid_from_kuid(const char *uidstr, struct user_namespace *userns,
+ char **n_uidstr)
+{
+ int n;
+ uid_t muid, p_uid;
+ char d;
+ kuid_t tuid;
+
+ *n_uidstr = NULL;
+
+ n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
+ if (n != 1)
+ return -EINVAL;
+
+ /* do we have a mapping of the uid? */
+ tuid = KUIDT_INIT(p_uid);
+ muid = from_kuid(userns, tuid);
+ if (muid == -1)
+ return -ENOENT;
+
+ *n_uidstr = xattr_write_uid(muid, NULL);
+ if (!*n_uidstr)
+ return -ENOMEM;
+
+ return 0;
+}
+
+/*
+ * xattr_parse_uid_make_kuid - parse string in the format @uid=<uid>; consider
+ * user namespaces and check mappings
+ *
+ * @uidstr : string in the format "@uid=<uid>"
+ * @userns : the user namespace to consult for uid mappings
+ * @N_uidstr : returned pointer holding the rewritten @uid=<uid> string with
+ * the uid remapped
+ *
+ * This function returns an error code or 0 in case of success. In case
+ * of success, 'n_uidstr' will hold a valid string.
+ */
+static int
+xattr_parse_uid_make_kuid(const char *uidstr, struct user_namespace *userns,
+ char **n_uidstr)
+{
+ int n;
+ uid_t p_uid;
+ char d;
+ kuid_t tuid;
+
+ *n_uidstr = NULL;
+
+ n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
+ if (n != 1)
+ return -EINVAL;
+
+ tuid = make_kuid(userns, p_uid);
+ if (!uid_valid(tuid))
+ return -ENOENT;
+
+ *n_uidstr = xattr_write_uid(__kuid_val(tuid), NULL);
+ if (!*n_uidstr)
+ return -ENOMEM;
+
+ return 0;
+}
+
+/*
+ * xattr_rewrite_userns_xattr - Rewrite and filter an extended attribute
+ * considering user namespace uid mappings and
+ * user namespace support extended attributes
+ *
+ * @name: full name of the extended attribute
+ *
+ * This function returns NULL if the name is to be filtered. Otherwise it can
+ * return the input buffer or a new buffer that the caller needs to free. The
+ * new buffer contains a rewritten extended attribute whose string length may
+ * exceed that of the given name.
+ */
+static char *
+xattr_rewrite_userns_xattr(char *name)
+{
+ int idx, error;
+ size_t len = 0, buflen;
+ char *buffer, *n_uidstr;
+
+ /* prefix-match name against supported attributes */
+ idx = xattr_is_userns_supported(name, true);
+ if (idx < 0) {
+ /* only rewrite those in userns_xattr[*] */
+ return name;
+ }
+
+ /* exact match ? */
+ len = strlen(userns_xattrs[idx]);
+ if (name[len] == 0)
+ return NULL;
+
+ /*
+ * We must have a name[len] == '@'.
+ */
+ error = xattr_parse_uid_from_kuid(&name[len], current_user_ns(),
+ &n_uidstr);
+ if (error)
+ return NULL;
+
+ buflen = len + strlen(n_uidstr) + 1;
+ buffer = kmalloc(buflen, GFP_KERNEL);
+ if (!buffer) {
+ kfree(n_uidstr);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ name[len] = 0;
+
+ snprintf(buffer, buflen, "%s%s", name, n_uidstr);
+
+ name[len] = '@';
+
+ kfree(n_uidstr);
+
+ return buffer;
+}
+
+/*
+ * xattr_list_contains - check whether an xattr list already contains a needle
+ *
+ * @list : 0-byte separated strings
+ * @listlen : length of the list
+ * @needle : the needle to search for
+ */
+static int
+xattr_list_contains(const char *list, size_t listlen, const char *needle)
+{
+ size_t o = 0;
+
+ while (o < listlen) {
+ if (!strcmp(&list[o], needle))
+ return true;
+ o += strlen(&list[o]) + 1;
+ }
+ return false;
+}
+
+/*
+ * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
+ * or determine needed size for attribute list
+ * in case size == 0
+ *
+ * In a user namespace we do not present all extended attributes to the
+ * user. We filter out those that are in the list of userns supported xattr.
+ * Besides that we filter out those with @uid=<uid> when there is no mapping
+ * for that uid in the current user namespace.
+ *
+ * @list: list of 0-byte separated xattr names
+ * @size: the size of the list; may be 0 to determine needed list size
+ * @list_maxlen: allocated buffer size of list
+ */
+static ssize_t
+xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
+{
+ char *nlist = NULL;
+ size_t s_off, len, nlen;
+ ssize_t d_off;
+ char *name, *newname;
+
+ if (!list || size < 0 || current_user_ns() == &init_user_ns)
+ return size;
+
+ if (size) {
+ nlist = kmalloc(list_maxlen, GFP_KERNEL);
+ if (!nlist)
+ return -ENOMEM;
+ }
+
+ s_off = d_off = 0;
+ while (s_off < size || size == 0) {
+ name = &list[s_off];
+
+ len = strlen(name);
+ if (!len)
+ break;
+
+ if (xattr_is_userns_supported(name, false) >= 0)
+ newname = name;
+ else {
+ newname = xattr_rewrite_userns_xattr(name);
+ if (IS_ERR(newname)) {
+ d_off = PTR_ERR(newname);
+ goto out_free;
+ }
+ }
+ if (newname && !xattr_list_contains(nlist, d_off, newname)) {
+ nlen = strlen(newname);
+
+ if (nlist) {
+ if (nlen + 1 > list_maxlen)
+ break;
+ strcpy(&nlist[d_off], newname);
+ }
+
+ d_off += nlen + 1;
+ if (newname != name)
+ kfree(newname);
+ }
+ s_off += len + 1;
+ }
+ if (nlist)
+ memcpy(list, nlist, d_off);
+out_free:
+ kfree(nlist);
+
+ return d_off;
+}
+
+/*
+ * xattr_userns_name - modify the name of a user namespace supported
+ * extended attribute
+ *
+ * In a user namespace we prevent read/write accesses to the host's
+ * security.foo to protect these extended attributes.
+ *
+ * Reading:
+ * 1a) Reading security.foo from a user namespace will read
+ * security.foo@uid=<uid> of the parent user namespace instead with uid
+ * being the mapping of root in that parent user namespace. An
+ * exception is if root is mapped to uid 0 on the host, and in this case
+ * we will read security.foo directly.
+ * -> reading security.foo will read security.foo@uid=1000 for a uid
+ * mapping of root to 1000.
+ *
+ * 1b) If security.foo@uid=<uid> is not available, the security.foo of the
+ * parent namespace is tried to be read. This procedure is repeated up to
+ * the init user namespace. This step only applies for reading of extended
+ * attributes and provides the same behavior as older systems where the
+ * host's extended attributes applied to user namespaces.
+ *
+ * 2) All security.foo@uid=<uid> with valid uid mappings in the user namespace
+ * an be read. The uid within the user namespace will be mapped to the
+ * corresponding uid on the host and that uid will be used in the name of
+ * the extended attribute.
+ * -> reading security.foo@uid=1 will read security.foo@uid=1001 for a uid
+ * mapping of root to 1000, size of at least 2.
+ *
+ * All security.foo@uid=<uid> can be read (by root) on the host with values
+ * of <uid> also being subject to checking for valid mappings.
+ *
+ * 3) No other security.foo* can be read.
+ *
+ * Writing and removing:
+ * The same rules for reading apply to writing and removing, except for 1b).
+ *
+ * This function returns a buffer with either the original name or the
+ * user namespace adjusted name of the extended attribute.
+ *
+ * @name: the full name of the extended attribute, e.g. security.foo
+ */
+char *
+xattr_userns_name(const char *name, struct user_namespace *userns)
+{
+ size_t buflen;
+ char *buffer, *n_uidstr;
+ kuid_t root_uid = make_kuid(userns, 0);
+ int idx, error;
+ size_t len;
+
+ /* only security.foo will be changed here - prefix match here */
+ idx = xattr_is_userns_supported(name, true);
+ if (idx < 0)
+ goto out_copy;
+
+ /* read security.foo? --> read security.foo@uid=<uid> instead */
+ len = strlen(userns_xattrs[idx]);
+ if (name[len] == 0) {
+ /*
+ * init_user_ns or userns with root mapped to uid 0
+ * may read security.foo directly
+ */
+ if (userns == &init_user_ns ||
+ __kuid_val(root_uid) == 0)
+ goto out_copy;
+
+ if (!uid_valid(root_uid))
+ return ERR_PTR(-EINVAL);
+
+ buffer = xattr_write_uid(__kuid_val(root_uid), name);
+ if (!buffer)
+ return ERR_PTR(-ENOMEM);
+
+ return buffer;
+ }
+
+ /*
+ * We must have name[len] == '@'.
+ */
+ error = xattr_parse_uid_make_kuid(&name[len],
+ userns,
+ &n_uidstr);
+ if (error)
+ return ERR_PTR(error);
+
+ /* name[len] == '@' */
+ buflen = len + strlen(n_uidstr) + 1;
+ buffer = kmalloc(buflen, GFP_KERNEL);
+ if (!buffer) {
+ kfree(n_uidstr);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ snprintf(buffer, len + 1, "%s", name);
+ snprintf(&buffer[len], buflen - len, "%s", n_uidstr);
+ kfree(n_uidstr);
+
+ return buffer;
+
+out_copy:
+ buffer = kstrdup(name, GFP_KERNEL);
+ if (!buffer)
+ return ERR_PTR(-ENOMEM);
+
+ return buffer;
+}
+
int
__vfs_setxattr(struct dentry *dentry, struct inode *inode, const char *name,
const void *value, size_t size, int flags)
{
const struct xattr_handler *handler;
+ char *newname;
+ int ret;
+ newname = xattr_userns_name(name, current_user_ns());
+ if (IS_ERR(newname))
+ return PTR_ERR(newname);
+ name = newname;
handler = xattr_resolve_name(inode, &name);
- if (IS_ERR(handler))
- return PTR_ERR(handler);
- if (!handler->set)
- return -EOPNOTSUPP;
+ if (IS_ERR(handler)) {
+ ret = PTR_ERR(handler);
+ goto out;
+ }
+ if (!handler->set) {
+ ret = -EOPNOTSUPP;
+ goto out;
+ }
if (size == 0)
value = ""; /* empty EA, do not remove */
- return handler->set(handler, dentry, inode, name, value, size, flags);
+ ret = handler->set(handler, dentry, inode, name, value, size, flags);
+
+out:
+ kfree(newname);
+ return ret;
}
EXPORT_SYMBOL(__vfs_setxattr);
@@ -301,14 +721,39 @@ ssize_t
__vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
void *value, size_t size)
{
- const struct xattr_handler *handler;
+ const struct xattr_handler *handler = NULL;
+ char *newname = NULL;
+ int ret, userns_supt_xattr;
+ struct user_namespace *userns = current_user_ns();
+
+ userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
+
+ do {
+ kfree(newname);
+
+ newname = xattr_userns_name(name, userns);
+ if (IS_ERR(newname))
+ return PTR_ERR(newname);
+
+ if (!handler) {
+ name = newname;
+ handler = xattr_resolve_name(inode, &name);
+ if (IS_ERR(handler)) {
+ ret = PTR_ERR(handler);
+ goto out;
+ }
+ if (!handler->get) {
+ ret = -EOPNOTSUPP;
+ goto out;
+ }
+ }
+ ret = handler->get(handler, dentry, inode, name, value, size);
+ userns = userns->parent;
+ } while ((ret == -ENODATA) && userns && userns_supt_xattr);
- handler = xattr_resolve_name(inode, &name);
- if (IS_ERR(handler))
- return PTR_ERR(handler);
- if (!handler->get)
- return -EOPNOTSUPP;
- return handler->get(handler, dentry, inode, name, value, size);
+out:
+ kfree(newname);
+ return ret;
}
EXPORT_SYMBOL(__vfs_getxattr);
@@ -328,8 +773,16 @@ vfs_getxattr(struct dentry *dentry, const char *name, void *value, size_t size)
if (!strncmp(name, XATTR_SECURITY_PREFIX,
XATTR_SECURITY_PREFIX_LEN)) {
- const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
- int ret = xattr_getsecurity(inode, suffix, value, size);
+ int ret;
+ const char *suffix;
+ char *newname = xattr_userns_name(name, current_user_ns());
+ if (IS_ERR(newname))
+ return PTR_ERR(newname);
+
+ suffix = newname + XATTR_SECURITY_PREFIX_LEN;
+
+ ret = xattr_getsecurity(inode, suffix, value, size);
+ kfree(newname);
/*
* Only overwrite the return value if a security module
* is actually active.
@@ -360,6 +813,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t size)
if (size && error > size)
error = -ERANGE;
}
+ if (error > 0)
+ error = xattr_list_userns_rewrite(list, error, size);
+
return error;
}
EXPORT_SYMBOL_GPL(vfs_listxattr);
@@ -369,13 +825,28 @@ __vfs_removexattr(struct dentry *dentry, const char *name)
{
struct inode *inode = d_inode(dentry);
const struct xattr_handler *handler;
+ char *newname;
+ int ret;
+ newname = xattr_userns_name(name, current_user_ns());
+ if (IS_ERR(newname))
+ return PTR_ERR(newname);
+ name = newname;
handler = xattr_resolve_name(inode, &name);
- if (IS_ERR(handler))
- return PTR_ERR(handler);
- if (!handler->set)
- return -EOPNOTSUPP;
- return handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
+ if (IS_ERR(handler)) {
+ ret = PTR_ERR(handler);
+ goto out;
+ }
+ if (!handler->set) {
+ ret = -EOPNOTSUPP;
+ goto out;
+ }
+ ret = handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
+
+out:
+ kfree(newname);
+
+ return ret;
}
EXPORT_SYMBOL(__vfs_removexattr);
diff --git a/security/commoncap.c b/security/commoncap.c
index 7abebd7..c842690 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -660,15 +660,23 @@ int cap_bprm_secureexec(struct linux_binprm *bprm)
int cap_inode_setxattr(struct dentry *dentry, const char *name,
const void *value, size_t size, int flags)
{
- if (!strcmp(name, XATTR_NAME_CAPS)) {
- if (!capable(CAP_SETFCAP))
+ if (strncmp(name, XATTR_SECURITY_PREFIX,
+ sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
+ return 0;
+
+ if (strncmp(name, XATTR_NAME_CAPS,
+ sizeof(XATTR_NAME_CAPS) - 1) == 0) {
+ struct inode *inode = d_backing_inode(dentry);
+
+ if (!inode)
+ return -EINVAL;
+ if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
return -EPERM;
+
return 0;
}
- if (!strncmp(name, XATTR_SECURITY_PREFIX,
- sizeof(XATTR_SECURITY_PREFIX) - 1) &&
- !capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN))
return -EPERM;
return 0;
}
@@ -686,15 +694,23 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name,
*/
int cap_inode_removexattr(struct dentry *dentry, const char *name)
{
- if (!strcmp(name, XATTR_NAME_CAPS)) {
- if (!capable(CAP_SETFCAP))
+ if (strncmp(name, XATTR_SECURITY_PREFIX,
+ sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
+ return 0;
+
+ if (strncmp(name, XATTR_NAME_CAPS,
+ sizeof(XATTR_NAME_CAPS) - 1) == 0) {
+ struct inode *inode = d_backing_inode(dentry);
+
+ if (!inode)
+ return -EINVAL;
+ if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
return -EPERM;
+
return 0;
}
- if (!strncmp(name, XATTR_SECURITY_PREFIX,
- sizeof(XATTR_SECURITY_PREFIX) - 1) &&
- !capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN))
return -EPERM;
return 0;
}
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 819fd68..702c225 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3091,8 +3091,13 @@ static int selinux_inode_setotherxattr(struct dentry *dentry, const char *name)
if (!strncmp(name, XATTR_SECURITY_PREFIX,
sizeof XATTR_SECURITY_PREFIX - 1)) {
- if (!strcmp(name, XATTR_NAME_CAPS)) {
- if (!capable(CAP_SETFCAP))
+ if (!strncmp(name, XATTR_NAME_CAPS,
+ sizeof(XATTR_NAME_CAPS) - 1)) {
+ struct inode *inode = d_backing_inode(dentry);
+
+ if (!inode)
+ return -EINVAL;
+ if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
return -EPERM;
} else if (!capable(CAP_SYS_ADMIN)) {
/* A different attribute in the security namespace.
--
2.7.4
^ permalink raw reply related [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-11 15:05 ` Stefan Berger
@ 2017-07-11 17:12 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-11 17:12 UTC (permalink / raw)
To: Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey, Stefan Berger
Quoting Stefan Berger (Stefan Bergerstefanb@linux.vnet.ibm.com):
> er.kernel.org>
> X-Mailing-List: linux-kernel@vger.kernel.org
> Content-Length: 19839
> Lines: 700
> X-UID: 24770
> Status: RO
>
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo@uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo@uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo@uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo@uid=1000 will be listed as security.foo in the user
> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 464c94b..eacad9e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> return inode_permission(inode, mask);
> }
>
> +/*
> + * A list of extended attributes that are supported in user namespaces
> + */
> +static const char *const userns_xattrs[] = {
> + XATTR_NAME_CAPS,
> + NULL
> +};
> +
> +/*
> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> + *
> + * @name: full name of the extended attribute
> + * @prefix: do a prefix match (true) or a full match (false)
> + *
> + * This function returns < 0 if not supported, an index into userns_xattrs[]
> + * otherwise.
> + */
> +static int
> +xattr_is_userns_supported(const char *name, int prefix)
> +{
> + int i;
> +
> + if (!name)
> + return -1;
> +
> + for (i = 0; userns_xattrs[i]; i++) {
> + if (prefix) {
> + if (!strncmp(userns_xattrs[i], name,
> + strlen(userns_xattrs[i])))
> + return i;
I think you here need to also check that the next char is either
'\0' or '.' (or maybe '@')
> + } else {
> + if (!strcmp(userns_xattrs[i], name))
> + return i;
> + }
> + }
> + return -1;
> +}
> +
> +/*
> + * xattr_write_uid - print a string in the format of "%s@uid=%u", which
> + * includes a prefix string
> + *
> + * @uid: the uid
> + * @prefix: prefix string; may be NULL
> + *
> + * This function returns a buffer with the string, or a NULL pointer in
> + * case of out-of-memory error.
> + */
> +static char *
> +xattr_write_uid(uid_t uid, const char *prefix)
> +{
> + size_t buflen;
> + char *buffer;
> +
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
> + if (prefix)
> + buflen += strlen(prefix);
> +
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer)
> + return NULL;
> +
> + if (uid == 0)
> + *buffer = 0;
Do you need to print out the prefix here?
> + else
> + sprintf(buffer, "%s@uid=%u",
> + (prefix) ? prefix : "",
> + uid);
> +
> + return buffer;
> +}
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-11 17:12 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-11 17:12 UTC (permalink / raw)
To: linux-security-module
Quoting Stefan Berger (Stefan Bergerstefanb at linux.vnet.ibm.com):
> er.kernel.org>
> X-Mailing-List: linux-kernel at vger.kernel.org
> Content-Length: 19839
> Lines: 700
> X-UID: 24770
> Status: RO
>
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo at uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo at uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo at uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo at uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo at uid=1 will read security.foo at uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo at uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo at uid=1000 will be listed as security.foo in the user
> namespace, security.foo at uid=1001 becomes security.foo at uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 464c94b..eacad9e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> return inode_permission(inode, mask);
> }
>
> +/*
> + * A list of extended attributes that are supported in user namespaces
> + */
> +static const char *const userns_xattrs[] = {
> + XATTR_NAME_CAPS,
> + NULL
> +};
> +
> +/*
> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> + *
> + * @name: full name of the extended attribute
> + * @prefix: do a prefix match (true) or a full match (false)
> + *
> + * This function returns < 0 if not supported, an index into userns_xattrs[]
> + * otherwise.
> + */
> +static int
> +xattr_is_userns_supported(const char *name, int prefix)
> +{
> + int i;
> +
> + if (!name)
> + return -1;
> +
> + for (i = 0; userns_xattrs[i]; i++) {
> + if (prefix) {
> + if (!strncmp(userns_xattrs[i], name,
> + strlen(userns_xattrs[i])))
> + return i;
I think you here need to also check that the next char is either
'\0' or '.' (or maybe '@')
> + } else {
> + if (!strcmp(userns_xattrs[i], name))
> + return i;
> + }
> + }
> + return -1;
> +}
> +
> +/*
> + * xattr_write_uid - print a string in the format of "%s at uid=%u", which
> + * includes a prefix string
> + *
> + * @uid: the uid
> + * @prefix: prefix string; may be NULL
> + *
> + * This function returns a buffer with the string, or a NULL pointer in
> + * case of out-of-memory error.
> + */
> +static char *
> +xattr_write_uid(uid_t uid, const char *prefix)
> +{
> + size_t buflen;
> + char *buffer;
> +
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
> + if (prefix)
> + buflen += strlen(prefix);
> +
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer)
> + return NULL;
> +
> + if (uid == 0)
> + *buffer = 0;
Do you need to print out the prefix here?
> + else
> + sprintf(buffer, "%s at uid=%u",
> + (prefix) ? prefix : "",
> + uid);
> +
> + return buffer;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-11 17:12 ` Serge E. Hallyn
(?)
@ 2017-07-12 0:15 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 0:15 UTC (permalink / raw)
To: Serge E. Hallyn, Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
On 07/11/2017 01:12 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb@linux.vnet.ibm.com):
>> er.kernel.org>
>> X-Mailing-List: linux-kernel@vger.kernel.org
>> Content-Length: 19839
>> Lines: 700
>> X-UID: 24770
>> Status: RO
>>
>> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo@uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo@uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo@uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo@uid=1000 will be listed as security.foo in the user
>> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
>>
>> diff --git a/fs/xattr.c b/fs/xattr.c
>> index 464c94b..eacad9e 100644
>> --- a/fs/xattr.c
>> +++ b/fs/xattr.c
>> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
>> return inode_permission(inode, mask);
>> }
>>
>> +/*
>> + * A list of extended attributes that are supported in user namespaces
>> + */
>> +static const char *const userns_xattrs[] = {
>> + XATTR_NAME_CAPS,
>> + NULL
>> +};
>> +
>> +/*
>> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
>> + *
>> + * @name: full name of the extended attribute
>> + * @prefix: do a prefix match (true) or a full match (false)
>> + *
>> + * This function returns < 0 if not supported, an index into userns_xattrs[]
>> + * otherwise.
>> + */
>> +static int
>> +xattr_is_userns_supported(const char *name, int prefix)
>> +{
>> + int i;
>> +
>> + if (!name)
>> + return -1;
>> +
>> + for (i = 0; userns_xattrs[i]; i++) {
>> + if (prefix) {
>> + if (!strncmp(userns_xattrs[i], name,
>> + strlen(userns_xattrs[i])))
>> + return i;
> I think you here need to also check that the next char is either
> '\0' or '.' (or maybe '@')
I have the checks for '@' and '\0' done by the caller. With the current
support of only security.capability I don't think we need to check for '.'.
>
>> + } else {
>> + if (!strcmp(userns_xattrs[i], name))
>> + return i;
>> + }
>> + }
>> + return -1;
>> +}
>> +
>> +/*
>> + * xattr_write_uid - print a string in the format of "%s@uid=%u", which
>> + * includes a prefix string
>> + *
>> + * @uid: the uid
>> + * @prefix: prefix string; may be NULL
>> + *
>> + * This function returns a buffer with the string, or a NULL pointer in
>> + * case of out-of-memory error.
>> + */
>> +static char *
>> +xattr_write_uid(uid_t uid, const char *prefix)
>> +{
>> + size_t buflen;
>> + char *buffer;
>> +
>> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
>> + if (prefix)
>> + buflen += strlen(prefix);
>> +
>> + buffer = kmalloc(buflen, GFP_KERNEL);
>> + if (!buffer)
>> + return NULL;
>> +
>> + if (uid == 0)
>> + *buffer = 0;
> Do you need to print out the prefix here?
Right. Fixed.
>
>> + else
>> + sprintf(buffer, "%s@uid=%u",
>> + (prefix) ? prefix : "",
>> + uid);
>> +
>> + return buffer;
>> +}
Thanks.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 0:15 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 0:15 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 5499 bytes --]
On 07/11/2017 01:12 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb(a)linux.vnet.ibm.com):
>> er.kernel.org>
>> X-Mailing-List: linux-kernel(a)vger.kernel.org
>> Content-Length: 19839
>> Lines: 700
>> X-UID: 24770
>> Status: RO
>>
>> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo(a)uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo(a)uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo(a)uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo(a)uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo(a)uid=1 will read security.foo(a)uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo(a)uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo(a)uid=1000 will be listed as security.foo in the user
>> namespace, security.foo(a)uid=1001 becomes security.foo(a)uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
>>
>> diff --git a/fs/xattr.c b/fs/xattr.c
>> index 464c94b..eacad9e 100644
>> --- a/fs/xattr.c
>> +++ b/fs/xattr.c
>> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
>> return inode_permission(inode, mask);
>> }
>>
>> +/*
>> + * A list of extended attributes that are supported in user namespaces
>> + */
>> +static const char *const userns_xattrs[] = {
>> + XATTR_NAME_CAPS,
>> + NULL
>> +};
>> +
>> +/*
>> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
>> + *
>> + * @name: full name of the extended attribute
>> + * @prefix: do a prefix match (true) or a full match (false)
>> + *
>> + * This function returns < 0 if not supported, an index into userns_xattrs[]
>> + * otherwise.
>> + */
>> +static int
>> +xattr_is_userns_supported(const char *name, int prefix)
>> +{
>> + int i;
>> +
>> + if (!name)
>> + return -1;
>> +
>> + for (i = 0; userns_xattrs[i]; i++) {
>> + if (prefix) {
>> + if (!strncmp(userns_xattrs[i], name,
>> + strlen(userns_xattrs[i])))
>> + return i;
> I think you here need to also check that the next char is either
> '\0' or '.' (or maybe '@')
I have the checks for '@' and '\0' done by the caller. With the current
support of only security.capability I don't think we need to check for '.'.
>
>> + } else {
>> + if (!strcmp(userns_xattrs[i], name))
>> + return i;
>> + }
>> + }
>> + return -1;
>> +}
>> +
>> +/*
>> + * xattr_write_uid - print a string in the format of "%s(a)uid=%u", which
>> + * includes a prefix string
>> + *
>> + * @uid: the uid
>> + * @prefix: prefix string; may be NULL
>> + *
>> + * This function returns a buffer with the string, or a NULL pointer in
>> + * case of out-of-memory error.
>> + */
>> +static char *
>> +xattr_write_uid(uid_t uid, const char *prefix)
>> +{
>> + size_t buflen;
>> + char *buffer;
>> +
>> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
>> + if (prefix)
>> + buflen += strlen(prefix);
>> +
>> + buffer = kmalloc(buflen, GFP_KERNEL);
>> + if (!buffer)
>> + return NULL;
>> +
>> + if (uid == 0)
>> + *buffer = 0;
> Do you need to print out the prefix here?
Right. Fixed.
>
>> + else
>> + sprintf(buffer, "%s(a)uid=%u",
>> + (prefix) ? prefix : "",
>> + uid);
>> +
>> + return buffer;
>> +}
Thanks.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 0:15 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 0:15 UTC (permalink / raw)
To: linux-security-module
On 07/11/2017 01:12 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb at linux.vnet.ibm.com):
>> er.kernel.org>
>> X-Mailing-List: linux-kernel at vger.kernel.org
>> Content-Length: 19839
>> Lines: 700
>> X-UID: 24770
>> Status: RO
>>
>> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo at uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo at uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo at uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo at uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo at uid=1 will read security.foo at uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo at uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo at uid=1000 will be listed as security.foo in the user
>> namespace, security.foo at uid=1001 becomes security.foo at uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
>>
>> diff --git a/fs/xattr.c b/fs/xattr.c
>> index 464c94b..eacad9e 100644
>> --- a/fs/xattr.c
>> +++ b/fs/xattr.c
>> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
>> return inode_permission(inode, mask);
>> }
>>
>> +/*
>> + * A list of extended attributes that are supported in user namespaces
>> + */
>> +static const char *const userns_xattrs[] = {
>> + XATTR_NAME_CAPS,
>> + NULL
>> +};
>> +
>> +/*
>> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
>> + *
>> + * @name: full name of the extended attribute
>> + * @prefix: do a prefix match (true) or a full match (false)
>> + *
>> + * This function returns < 0 if not supported, an index into userns_xattrs[]
>> + * otherwise.
>> + */
>> +static int
>> +xattr_is_userns_supported(const char *name, int prefix)
>> +{
>> + int i;
>> +
>> + if (!name)
>> + return -1;
>> +
>> + for (i = 0; userns_xattrs[i]; i++) {
>> + if (prefix) {
>> + if (!strncmp(userns_xattrs[i], name,
>> + strlen(userns_xattrs[i])))
>> + return i;
> I think you here need to also check that the next char is either
> '\0' or '.' (or maybe '@')
I have the checks for '@' and '\0' done by the caller. With the current
support of only security.capability I don't think we need to check for '.'.
>
>> + } else {
>> + if (!strcmp(userns_xattrs[i], name))
>> + return i;
>> + }
>> + }
>> + return -1;
>> +}
>> +
>> +/*
>> + * xattr_write_uid - print a string in the format of "%s at uid=%u", which
>> + * includes a prefix string
>> + *
>> + * @uid: the uid
>> + * @prefix: prefix string; may be NULL
>> + *
>> + * This function returns a buffer with the string, or a NULL pointer in
>> + * case of out-of-memory error.
>> + */
>> +static char *
>> +xattr_write_uid(uid_t uid, const char *prefix)
>> +{
>> + size_t buflen;
>> + char *buffer;
>> +
>> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
>> + if (prefix)
>> + buflen += strlen(prefix);
>> +
>> + buffer = kmalloc(buflen, GFP_KERNEL);
>> + if (!buffer)
>> + return NULL;
>> +
>> + if (uid == 0)
>> + *buffer = 0;
> Do you need to print out the prefix here?
Right. Fixed.
>
>> + else
>> + sprintf(buffer, "%s at uid=%u",
>> + (prefix) ? prefix : "",
>> + uid);
>> +
>> + return buffer;
>> +}
Thanks.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 0:15 ` Stefan Berger
@ 2017-07-12 0:47 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 0:47 UTC (permalink / raw)
To: Stefan Berger
Cc: Serge E. Hallyn, Stefan Berger, ebiederm, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> On 07/11/2017 01:12 PM, Serge E. Hallyn wrote:
> >>diff --git a/fs/xattr.c b/fs/xattr.c
> >>index 464c94b..eacad9e 100644
> >>--- a/fs/xattr.c
> >>+++ b/fs/xattr.c
> >>@@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> >> return inode_permission(inode, mask);
> >> }
> >>+/*
> >>+ * A list of extended attributes that are supported in user namespaces
> >>+ */
> >>+static const char *const userns_xattrs[] = {
> >>+ XATTR_NAME_CAPS,
> >>+ NULL
> >>+};
> >>+
> >>+/*
> >>+ * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> >>+ *
> >>+ * @name: full name of the extended attribute
> >>+ * @prefix: do a prefix match (true) or a full match (false)
> >>+ *
> >>+ * This function returns < 0 if not supported, an index into userns_xattrs[]
> >>+ * otherwise.
> >>+ */
> >>+static int
> >>+xattr_is_userns_supported(const char *name, int prefix)
> >>+{
> >>+ int i;
> >>+
> >>+ if (!name)
> >>+ return -1;
> >>+
> >>+ for (i = 0; userns_xattrs[i]; i++) {
> >>+ if (prefix) {
> >>+ if (!strncmp(userns_xattrs[i], name,
> >>+ strlen(userns_xattrs[i])))
> >>+ return i;
> >I think you here need to also check that the next char is either
> >'\0' or '.' (or maybe '@')
>
> I have the checks for '@' and '\0' done by the caller. With the
> current support of only security.capability I don't think we need to
> check for '.'.
Ah - ok, thanks.
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 0:47 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 0:47 UTC (permalink / raw)
To: linux-security-module
Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> On 07/11/2017 01:12 PM, Serge E. Hallyn wrote:
> >>diff --git a/fs/xattr.c b/fs/xattr.c
> >>index 464c94b..eacad9e 100644
> >>--- a/fs/xattr.c
> >>+++ b/fs/xattr.c
> >>@@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> >> return inode_permission(inode, mask);
> >> }
> >>+/*
> >>+ * A list of extended attributes that are supported in user namespaces
> >>+ */
> >>+static const char *const userns_xattrs[] = {
> >>+ XATTR_NAME_CAPS,
> >>+ NULL
> >>+};
> >>+
> >>+/*
> >>+ * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> >>+ *
> >>+ * @name: full name of the extended attribute
> >>+ * @prefix: do a prefix match (true) or a full match (false)
> >>+ *
> >>+ * This function returns < 0 if not supported, an index into userns_xattrs[]
> >>+ * otherwise.
> >>+ */
> >>+static int
> >>+xattr_is_userns_supported(const char *name, int prefix)
> >>+{
> >>+ int i;
> >>+
> >>+ if (!name)
> >>+ return -1;
> >>+
> >>+ for (i = 0; userns_xattrs[i]; i++) {
> >>+ if (prefix) {
> >>+ if (!strncmp(userns_xattrs[i], name,
> >>+ strlen(userns_xattrs[i])))
> >>+ return i;
> >I think you here need to also check that the next char is either
> >'\0' or '.' (or maybe '@')
>
> I have the checks for '@' and '\0' done by the caller. With the
> current support of only security.capability I don't think we need to
> check for '.'.
Ah - ok, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <ca6e0001-6aeb-74dc-ab91-44aed3b7d128-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <ca6e0001-6aeb-74dc-ab91-44aed3b7d128-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-12 0:47 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 0:47 UTC (permalink / raw)
Cc: zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk, Stefan Berger,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
lkp-JC7UmRfGjtg
Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> On 07/11/2017 01:12 PM, Serge E. Hallyn wrote:
> >>diff --git a/fs/xattr.c b/fs/xattr.c
> >>index 464c94b..eacad9e 100644
> >>--- a/fs/xattr.c
> >>+++ b/fs/xattr.c
> >>@@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> >> return inode_permission(inode, mask);
> >> }
> >>+/*
> >>+ * A list of extended attributes that are supported in user namespaces
> >>+ */
> >>+static const char *const userns_xattrs[] = {
> >>+ XATTR_NAME_CAPS,
> >>+ NULL
> >>+};
> >>+
> >>+/*
> >>+ * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> >>+ *
> >>+ * @name: full name of the extended attribute
> >>+ * @prefix: do a prefix match (true) or a full match (false)
> >>+ *
> >>+ * This function returns < 0 if not supported, an index into userns_xattrs[]
> >>+ * otherwise.
> >>+ */
> >>+static int
> >>+xattr_is_userns_supported(const char *name, int prefix)
> >>+{
> >>+ int i;
> >>+
> >>+ if (!name)
> >>+ return -1;
> >>+
> >>+ for (i = 0; userns_xattrs[i]; i++) {
> >>+ if (prefix) {
> >>+ if (!strncmp(userns_xattrs[i], name,
> >>+ strlen(userns_xattrs[i])))
> >>+ return i;
> >I think you here need to also check that the next char is either
> >'\0' or '.' (or maybe '@')
>
> I have the checks for '@' and '\0' done by the caller. With the
> current support of only security.capability I don't think we need to
> check for '.'.
Ah - ok, thanks.
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170711171222.GB31603-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170711171222.GB31603-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
@ 2017-07-12 0:15 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 0:15 UTC (permalink / raw)
To: Serge E. Hallyn, Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/11/2017 01:12 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
>> er.kernel.org>
>> X-Mailing-List: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Content-Length: 19839
>> Lines: 700
>> X-UID: 24770
>> Status: RO
>>
>> From: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo@uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo@uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo@uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo@uid=1000 will be listed as security.foo in the user
>> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>> Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>> Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
>>
>> diff --git a/fs/xattr.c b/fs/xattr.c
>> index 464c94b..eacad9e 100644
>> --- a/fs/xattr.c
>> +++ b/fs/xattr.c
>> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
>> return inode_permission(inode, mask);
>> }
>>
>> +/*
>> + * A list of extended attributes that are supported in user namespaces
>> + */
>> +static const char *const userns_xattrs[] = {
>> + XATTR_NAME_CAPS,
>> + NULL
>> +};
>> +
>> +/*
>> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
>> + *
>> + * @name: full name of the extended attribute
>> + * @prefix: do a prefix match (true) or a full match (false)
>> + *
>> + * This function returns < 0 if not supported, an index into userns_xattrs[]
>> + * otherwise.
>> + */
>> +static int
>> +xattr_is_userns_supported(const char *name, int prefix)
>> +{
>> + int i;
>> +
>> + if (!name)
>> + return -1;
>> +
>> + for (i = 0; userns_xattrs[i]; i++) {
>> + if (prefix) {
>> + if (!strncmp(userns_xattrs[i], name,
>> + strlen(userns_xattrs[i])))
>> + return i;
> I think you here need to also check that the next char is either
> '\0' or '.' (or maybe '@')
I have the checks for '@' and '\0' done by the caller. With the current
support of only security.capability I don't think we need to check for '.'.
>
>> + } else {
>> + if (!strcmp(userns_xattrs[i], name))
>> + return i;
>> + }
>> + }
>> + return -1;
>> +}
>> +
>> +/*
>> + * xattr_write_uid - print a string in the format of "%s@uid=%u", which
>> + * includes a prefix string
>> + *
>> + * @uid: the uid
>> + * @prefix: prefix string; may be NULL
>> + *
>> + * This function returns a buffer with the string, or a NULL pointer in
>> + * case of out-of-memory error.
>> + */
>> +static char *
>> +xattr_write_uid(uid_t uid, const char *prefix)
>> +{
>> + size_t buflen;
>> + char *buffer;
>> +
>> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
>> + if (prefix)
>> + buflen += strlen(prefix);
>> +
>> + buffer = kmalloc(buflen, GFP_KERNEL);
>> + if (!buffer)
>> + return NULL;
>> +
>> + if (uid == 0)
>> + *buffer = 0;
> Do you need to print out the prefix here?
Right. Fixed.
>
>> + else
>> + sprintf(buffer, "%s@uid=%u",
>> + (prefix) ? prefix : "",
>> + uid);
>> +
>> + return buffer;
>> +}
Thanks.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-11 15:05 ` Stefan Berger
@ 2017-07-12 3:45 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 3:45 UTC (permalink / raw)
To: Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey, Stefan Berger
Quoting Stefan Berger (Stefan Bergerstefanb@linux.vnet.ibm.com):
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = &list[s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);
Why are you doing this here? If we get here it means that
xattr_is_userns_supported() returned < 0, meaning name is
not userns-supported. So xattr_rewrite_userns_xattr() will
just return name. Am I missing something?
> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
Now here, if name was recalculated to @newname, and @newname is
found in the nlist, that should raise an error right? Something
fishy is going on?
> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)
d_off needs to be set to -ERANGE here.
> + break;
> + strcpy(&nlist[d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 3:45 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 3:45 UTC (permalink / raw)
To: linux-security-module
Quoting Stefan Berger (Stefan Bergerstefanb at linux.vnet.ibm.com):
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = &list[s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);
Why are you doing this here? If we get here it means that
xattr_is_userns_supported() returned < 0, meaning name is
not userns-supported. So xattr_rewrite_userns_xattr() will
just return name. Am I missing something?
> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
Now here, if name was recalculated to @newname, and @newname is
found in the nlist, that should raise an error right? Something
fishy is going on?
> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)
d_off needs to be set to -ERANGE here.
> + break;
> + strcpy(&nlist[d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <20170712034503.GA8270-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170712034503.GA8270-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
@ 2017-07-12 11:35 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 11:35 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/11/2017 11:45 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> + return size;
>> +
>> + if (size) {
>> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
>> + if (!nlist)
>> + return -ENOMEM;
>> + }
>> +
>> + s_off = d_off = 0;
>> + while (s_off < size || size == 0) {
>> + name = &list[s_off];
>> +
>> + len = strlen(name);
>> + if (!len)
>> + break;
>> +
>> + if (xattr_is_userns_supported(name, false) >= 0)
>> + newname = name;
>> + else {
>> + newname = xattr_rewrite_userns_xattr(name);
> Why are you doing this here? If we get here it means that
> xattr_is_userns_supported() returned < 0, meaning name is
> not userns-supported. So xattr_rewrite_userns_xattr() will
> just return name. Am I missing something?
xattr_is_userns_support(name, false) does a _full string match_ rather
than a prefix match and will only return >= 0 for security.capability.
This case handles the hosts's security.capability which 'shines
through' for read and needs to be listed. Only in this case we set
newname=name.
In the else branch we handle security.capability@uid=1000 and rewrite
that to security.capability for root mapping to uid=1000.
>
>> + if (IS_ERR(newname)) {
>> + d_off = PTR_ERR(newname);
>> + goto out_free;
>> + }
>> + }
>> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> Now here, if name was recalculated to @newname, and @newname is
> found in the nlist, that should raise an error right? Something
> fishy is going on?
If security.capability is set on a file but the container doesn't have
security.capability@uid=1000, we still need to list the former here.
However, we end up with duplicates if security.capability is there and
security.capability@uid=1000 is also there and root is mapped to
uid=1000. Both would be shown as security.capability inside the
container. In this case we need to filter.
I think the code is correct. More problematic is a memory leak in the
error case. Will fix that.
>
>> + nlen = strlen(newname);
>> +
>> + if (nlist) {
>> + if (nlen + 1 > list_maxlen)
> d_off needs to be set to -ERANGE here.
Fixed.
>
>> + break;
>> + strcpy(&nlist[d_off], newname);
>> + }
>> +
>> + d_off += nlen + 1;
>> + if (newname != name)
>> + kfree(newname);
>> + }
>> + s_off += len + 1;
>> + }
>> + if (nlist)
>> + memcpy(list, nlist, d_off);
>> +out_free:
>> + kfree(nlist);
>> +
>> + return d_off;
>> +}
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 3:45 ` Serge E. Hallyn
(?)
@ 2017-07-12 11:35 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 11:35 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
On 07/11/2017 11:45 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb@linux.vnet.ibm.com):
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> + return size;
>> +
>> + if (size) {
>> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
>> + if (!nlist)
>> + return -ENOMEM;
>> + }
>> +
>> + s_off = d_off = 0;
>> + while (s_off < size || size == 0) {
>> + name = &list[s_off];
>> +
>> + len = strlen(name);
>> + if (!len)
>> + break;
>> +
>> + if (xattr_is_userns_supported(name, false) >= 0)
>> + newname = name;
>> + else {
>> + newname = xattr_rewrite_userns_xattr(name);
> Why are you doing this here? If we get here it means that
> xattr_is_userns_supported() returned < 0, meaning name is
> not userns-supported. So xattr_rewrite_userns_xattr() will
> just return name. Am I missing something?
xattr_is_userns_support(name, false) does a _full string match_ rather
than a prefix match and will only return >= 0 for security.capability.
This case handles the hosts's security.capability which 'shines
through' for read and needs to be listed. Only in this case we set
newname=name.
In the else branch we handle security.capability@uid=1000 and rewrite
that to security.capability for root mapping to uid=1000.
>
>> + if (IS_ERR(newname)) {
>> + d_off = PTR_ERR(newname);
>> + goto out_free;
>> + }
>> + }
>> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> Now here, if name was recalculated to @newname, and @newname is
> found in the nlist, that should raise an error right? Something
> fishy is going on?
If security.capability is set on a file but the container doesn't have
security.capability@uid=1000, we still need to list the former here.
However, we end up with duplicates if security.capability is there and
security.capability@uid=1000 is also there and root is mapped to
uid=1000. Both would be shown as security.capability inside the
container. In this case we need to filter.
I think the code is correct. More problematic is a memory leak in the
error case. Will fix that.
>
>> + nlen = strlen(newname);
>> +
>> + if (nlist) {
>> + if (nlen + 1 > list_maxlen)
> d_off needs to be set to -ERANGE here.
Fixed.
>
>> + break;
>> + strcpy(&nlist[d_off], newname);
>> + }
>> +
>> + d_off += nlen + 1;
>> + if (newname != name)
>> + kfree(newname);
>> + }
>> + s_off += len + 1;
>> + }
>> + if (nlist)
>> + memcpy(list, nlist, d_off);
>> +out_free:
>> + kfree(nlist);
>> +
>> + return d_off;
>> +}
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 11:35 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 11:35 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]
On 07/11/2017 11:45 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb(a)linux.vnet.ibm.com):
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> + return size;
>> +
>> + if (size) {
>> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
>> + if (!nlist)
>> + return -ENOMEM;
>> + }
>> +
>> + s_off = d_off = 0;
>> + while (s_off < size || size == 0) {
>> + name = &list[s_off];
>> +
>> + len = strlen(name);
>> + if (!len)
>> + break;
>> +
>> + if (xattr_is_userns_supported(name, false) >= 0)
>> + newname = name;
>> + else {
>> + newname = xattr_rewrite_userns_xattr(name);
> Why are you doing this here? If we get here it means that
> xattr_is_userns_supported() returned < 0, meaning name is
> not userns-supported. So xattr_rewrite_userns_xattr() will
> just return name. Am I missing something?
xattr_is_userns_support(name, false) does a _full string match_ rather
than a prefix match and will only return >= 0 for security.capability.
This case handles the hosts's security.capability which 'shines
through' for read and needs to be listed. Only in this case we set
newname=name.
In the else branch we handle security.capability(a)uid=1000 and rewrite
that to security.capability for root mapping to uid=1000.
>
>> + if (IS_ERR(newname)) {
>> + d_off = PTR_ERR(newname);
>> + goto out_free;
>> + }
>> + }
>> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> Now here, if name was recalculated to @newname, and @newname is
> found in the nlist, that should raise an error right? Something
> fishy is going on?
If security.capability is set on a file but the container doesn't have
security.capability(a)uid=1000, we still need to list the former here.
However, we end up with duplicates if security.capability is there and
security.capability(a)uid=1000 is also there and root is mapped to
uid=1000. Both would be shown as security.capability inside the
container. In this case we need to filter.
I think the code is correct. More problematic is a memory leak in the
error case. Will fix that.
>
>> + nlen = strlen(newname);
>> +
>> + if (nlist) {
>> + if (nlen + 1 > list_maxlen)
> d_off needs to be set to -ERANGE here.
Fixed.
>
>> + break;
>> + strcpy(&nlist[d_off], newname);
>> + }
>> +
>> + d_off += nlen + 1;
>> + if (newname != name)
>> + kfree(newname);
>> + }
>> + s_off += len + 1;
>> + }
>> + if (nlist)
>> + memcpy(list, nlist, d_off);
>> +out_free:
>> + kfree(nlist);
>> +
>> + return d_off;
>> +}
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 11:35 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 11:35 UTC (permalink / raw)
To: linux-security-module
On 07/11/2017 11:45 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb at linux.vnet.ibm.com):
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> + return size;
>> +
>> + if (size) {
>> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
>> + if (!nlist)
>> + return -ENOMEM;
>> + }
>> +
>> + s_off = d_off = 0;
>> + while (s_off < size || size == 0) {
>> + name = &list[s_off];
>> +
>> + len = strlen(name);
>> + if (!len)
>> + break;
>> +
>> + if (xattr_is_userns_supported(name, false) >= 0)
>> + newname = name;
>> + else {
>> + newname = xattr_rewrite_userns_xattr(name);
> Why are you doing this here? If we get here it means that
> xattr_is_userns_supported() returned < 0, meaning name is
> not userns-supported. So xattr_rewrite_userns_xattr() will
> just return name. Am I missing something?
xattr_is_userns_support(name, false) does a _full string match_ rather
than a prefix match and will only return >= 0 for security.capability.
This case handles the hosts's security.capability which 'shines
through' for read and needs to be listed. Only in this case we set
newname=name.
In the else branch we handle security.capability at uid=1000 and rewrite
that to security.capability for root mapping to uid=1000.
>
>> + if (IS_ERR(newname)) {
>> + d_off = PTR_ERR(newname);
>> + goto out_free;
>> + }
>> + }
>> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> Now here, if name was recalculated to @newname, and @newname is
> found in the nlist, that should raise an error right? Something
> fishy is going on?
If security.capability is set on a file but the container doesn't have
security.capability at uid=1000, we still need to list the former here.
However, we end up with duplicates if security.capability is there and
security.capability at uid=1000 is also there and root is mapped to
uid=1000. Both would be shown as security.capability inside the
container. In this case we need to filter.
I think the code is correct. More problematic is a memory leak in the
error case. Will fix that.
>
>> + nlen = strlen(newname);
>> +
>> + if (nlist) {
>> + if (nlen + 1 > list_maxlen)
> d_off needs to be set to -ERANGE here.
Fixed.
>
>> + break;
>> + strcpy(&nlist[d_off], newname);
>> + }
>> +
>> + d_off += nlen + 1;
>> + if (newname != name)
>> + kfree(newname);
>> + }
>> + s_off += len + 1;
>> + }
>> + if (nlist)
>> + memcpy(list, nlist, d_off);
>> +out_free:
>> + kfree(nlist);
>> +
>> + return d_off;
>> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <8c3e8c6f-52c5-5b04-8cad-1aeae25f0ec6-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <8c3e8c6f-52c5-5b04-8cad-1aeae25f0ec6-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-12 17:32 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 17:32 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> On 07/11/2017 11:45 PM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (Stefan Bergerstefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> >>+/*
> >>+ * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> >>+ * or determine needed size for attribute list
> >>+ * in case size == 0
> >>+ *
> >>+ * In a user namespace we do not present all extended attributes to the
> >>+ * user. We filter out those that are in the list of userns supported xattr.
> >>+ * Besides that we filter out those with @uid=<uid> when there is no mapping
> >>+ * for that uid in the current user namespace.
> >>+ *
> >>+ * @list: list of 0-byte separated xattr names
> >>+ * @size: the size of the list; may be 0 to determine needed list size
> >>+ * @list_maxlen: allocated buffer size of list
> >>+ */
> >>+static ssize_t
> >>+xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> >>+{
> >>+ char *nlist = NULL;
> >>+ size_t s_off, len, nlen;
> >>+ ssize_t d_off;
> >>+ char *name, *newname;
> >>+
> >>+ if (!list || size < 0 || current_user_ns() == &init_user_ns)
> >>+ return size;
> >>+
> >>+ if (size) {
> >>+ nlist = kmalloc(list_maxlen, GFP_KERNEL);
> >>+ if (!nlist)
> >>+ return -ENOMEM;
> >>+ }
> >>+
> >>+ s_off = d_off = 0;
> >>+ while (s_off < size || size == 0) {
> >>+ name = &list[s_off];
> >>+
> >>+ len = strlen(name);
> >>+ if (!len)
> >>+ break;
> >>+
> >>+ if (xattr_is_userns_supported(name, false) >= 0)
> >>+ newname = name;
> >>+ else {
> >>+ newname = xattr_rewrite_userns_xattr(name);
> >Why are you doing this here? If we get here it means that
> >xattr_is_userns_supported() returned < 0, meaning name is
> >not userns-supported. So xattr_rewrite_userns_xattr() will
> >just return name. Am I missing something?
>
> xattr_is_userns_support(name, false) does a _full string match_
> rather than a prefix match and will only return >= 0 for
> security.capability. This case handles the hosts's
> security.capability which 'shines through' for read and needs to be
> listed. Only in this case we set newname=name.
Ah, right.
I think it would be worth #defining XATTR_PREFIX_SEARCH and
XATTR_FULLNAME_SEARCH or something. Or maybe not, maybe I was
just being dense.
> In the else branch we handle security.capability@uid=1000 and
> rewrite that to security.capability for root mapping to uid=1000.
>
> >
> >>+ if (IS_ERR(newname)) {
> >>+ d_off = PTR_ERR(newname);
> >>+ goto out_free;
> >>+ }
> >>+ }
> >>+ if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> >Now here, if name was recalculated to @newname, and @newname is
> >found in the nlist, that should raise an error right? Something
> >fishy is going on?
>
> If security.capability is set on a file but the container doesn't
> have security.capability@uid=1000, we still need to list the former
> here. However, we end up with duplicates if security.capability is
> there and security.capability@uid=1000 is also there and root is
> mapped to uid=1000. Both would be shown as security.capability
> inside the container. In this case we need to filter.
Gotcha, thanks.
> I think the code is correct. More problematic is a memory leak in
> the error case. Will fix that.
Great.
> >
> >>+ nlen = strlen(newname);
> >>+
> >>+ if (nlist) {
> >>+ if (nlen + 1 > list_maxlen)
> >d_off needs to be set to -ERANGE here.
>
> Fixed.
Great, thanks.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 11:35 ` Stefan Berger
@ 2017-07-12 17:32 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 17:32 UTC (permalink / raw)
To: Stefan Berger
Cc: Serge E. Hallyn, ebiederm, containers, lkp, linux-kernel, zohar,
tycho, James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> On 07/11/2017 11:45 PM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (Stefan Bergerstefanb@linux.vnet.ibm.com):
> >>+/*
> >>+ * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> >>+ * or determine needed size for attribute list
> >>+ * in case size == 0
> >>+ *
> >>+ * In a user namespace we do not present all extended attributes to the
> >>+ * user. We filter out those that are in the list of userns supported xattr.
> >>+ * Besides that we filter out those with @uid=<uid> when there is no mapping
> >>+ * for that uid in the current user namespace.
> >>+ *
> >>+ * @list: list of 0-byte separated xattr names
> >>+ * @size: the size of the list; may be 0 to determine needed list size
> >>+ * @list_maxlen: allocated buffer size of list
> >>+ */
> >>+static ssize_t
> >>+xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> >>+{
> >>+ char *nlist = NULL;
> >>+ size_t s_off, len, nlen;
> >>+ ssize_t d_off;
> >>+ char *name, *newname;
> >>+
> >>+ if (!list || size < 0 || current_user_ns() == &init_user_ns)
> >>+ return size;
> >>+
> >>+ if (size) {
> >>+ nlist = kmalloc(list_maxlen, GFP_KERNEL);
> >>+ if (!nlist)
> >>+ return -ENOMEM;
> >>+ }
> >>+
> >>+ s_off = d_off = 0;
> >>+ while (s_off < size || size == 0) {
> >>+ name = &list[s_off];
> >>+
> >>+ len = strlen(name);
> >>+ if (!len)
> >>+ break;
> >>+
> >>+ if (xattr_is_userns_supported(name, false) >= 0)
> >>+ newname = name;
> >>+ else {
> >>+ newname = xattr_rewrite_userns_xattr(name);
> >Why are you doing this here? If we get here it means that
> >xattr_is_userns_supported() returned < 0, meaning name is
> >not userns-supported. So xattr_rewrite_userns_xattr() will
> >just return name. Am I missing something?
>
> xattr_is_userns_support(name, false) does a _full string match_
> rather than a prefix match and will only return >= 0 for
> security.capability. This case handles the hosts's
> security.capability which 'shines through' for read and needs to be
> listed. Only in this case we set newname=name.
Ah, right.
I think it would be worth #defining XATTR_PREFIX_SEARCH and
XATTR_FULLNAME_SEARCH or something. Or maybe not, maybe I was
just being dense.
> In the else branch we handle security.capability@uid=1000 and
> rewrite that to security.capability for root mapping to uid=1000.
>
> >
> >>+ if (IS_ERR(newname)) {
> >>+ d_off = PTR_ERR(newname);
> >>+ goto out_free;
> >>+ }
> >>+ }
> >>+ if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> >Now here, if name was recalculated to @newname, and @newname is
> >found in the nlist, that should raise an error right? Something
> >fishy is going on?
>
> If security.capability is set on a file but the container doesn't
> have security.capability@uid=1000, we still need to list the former
> here. However, we end up with duplicates if security.capability is
> there and security.capability@uid=1000 is also there and root is
> mapped to uid=1000. Both would be shown as security.capability
> inside the container. In this case we need to filter.
Gotcha, thanks.
> I think the code is correct. More problematic is a memory leak in
> the error case. Will fix that.
Great.
> >
> >>+ nlen = strlen(newname);
> >>+
> >>+ if (nlist) {
> >>+ if (nlen + 1 > list_maxlen)
> >d_off needs to be set to -ERANGE here.
>
> Fixed.
Great, thanks.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 17:32 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 17:32 UTC (permalink / raw)
To: linux-security-module
Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> On 07/11/2017 11:45 PM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (Stefan Bergerstefanb at linux.vnet.ibm.com):
> >>+/*
> >>+ * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> >>+ * or determine needed size for attribute list
> >>+ * in case size == 0
> >>+ *
> >>+ * In a user namespace we do not present all extended attributes to the
> >>+ * user. We filter out those that are in the list of userns supported xattr.
> >>+ * Besides that we filter out those with @uid=<uid> when there is no mapping
> >>+ * for that uid in the current user namespace.
> >>+ *
> >>+ * @list: list of 0-byte separated xattr names
> >>+ * @size: the size of the list; may be 0 to determine needed list size
> >>+ * @list_maxlen: allocated buffer size of list
> >>+ */
> >>+static ssize_t
> >>+xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> >>+{
> >>+ char *nlist = NULL;
> >>+ size_t s_off, len, nlen;
> >>+ ssize_t d_off;
> >>+ char *name, *newname;
> >>+
> >>+ if (!list || size < 0 || current_user_ns() == &init_user_ns)
> >>+ return size;
> >>+
> >>+ if (size) {
> >>+ nlist = kmalloc(list_maxlen, GFP_KERNEL);
> >>+ if (!nlist)
> >>+ return -ENOMEM;
> >>+ }
> >>+
> >>+ s_off = d_off = 0;
> >>+ while (s_off < size || size == 0) {
> >>+ name = &list[s_off];
> >>+
> >>+ len = strlen(name);
> >>+ if (!len)
> >>+ break;
> >>+
> >>+ if (xattr_is_userns_supported(name, false) >= 0)
> >>+ newname = name;
> >>+ else {
> >>+ newname = xattr_rewrite_userns_xattr(name);
> >Why are you doing this here? If we get here it means that
> >xattr_is_userns_supported() returned < 0, meaning name is
> >not userns-supported. So xattr_rewrite_userns_xattr() will
> >just return name. Am I missing something?
>
> xattr_is_userns_support(name, false) does a _full string match_
> rather than a prefix match and will only return >= 0 for
> security.capability. This case handles the hosts's
> security.capability which 'shines through' for read and needs to be
> listed. Only in this case we set newname=name.
Ah, right.
I think it would be worth #defining XATTR_PREFIX_SEARCH and
XATTR_FULLNAME_SEARCH or something. Or maybe not, maybe I was
just being dense.
> In the else branch we handle security.capability at uid=1000 and
> rewrite that to security.capability for root mapping to uid=1000.
>
> >
> >>+ if (IS_ERR(newname)) {
> >>+ d_off = PTR_ERR(newname);
> >>+ goto out_free;
> >>+ }
> >>+ }
> >>+ if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> >Now here, if name was recalculated to @newname, and @newname is
> >found in the nlist, that should raise an error right? Something
> >fishy is going on?
>
> If security.capability is set on a file but the container doesn't
> have security.capability at uid=1000, we still need to list the former
> here. However, we end up with duplicates if security.capability is
> there and security.capability at uid=1000 is also there and root is
> mapped to uid=1000. Both would be shown as security.capability
> inside the container. In this case we need to filter.
Gotcha, thanks.
> I think the code is correct. More problematic is a memory leak in
> the error case. Will fix that.
Great.
> >
> >>+ nlen = strlen(newname);
> >>+
> >>+ if (nlist) {
> >>+ if (nlen + 1 > list_maxlen)
> >d_off needs to be set to -ERANGE here.
>
> Fixed.
Great, thanks.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-11 15:05 ` Stefan Berger
(?)
@ 2017-07-12 7:59 ` James Morris
-1 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-12 7:59 UTC (permalink / raw)
To: Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, James.Bottomley,
linux-security-module, casey, zohar
On Tue, 11 Jul 2017, Stefan Berger wrote:
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
Why not strlen() here?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-11 15:05 ` Stefan Berger
(?)
@ 2017-07-12 13:25 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-12 13:25 UTC (permalink / raw)
To: Stefan Berger
Cc: containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey, Stefan Berger
Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo@uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo@uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo@uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo@uid=1000 will be listed as security.foo in the user
> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
It doesn't look like this is coming through Serge so I don't see how
the Signed-off-by tag is legtimate.
>From the replies to this it doesn't look like Serge has reviewed this
version either.
I am disappointed that all of my concerns about technical feasibility
remain unaddressed.
I hope my reading and review of the code goes better than my reading of
it's introduction.
Eric
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 464c94b..eacad9e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> return inode_permission(inode, mask);
> }
>
> +/*
> + * A list of extended attributes that are supported in user namespaces
> + */
> +static const char *const userns_xattrs[] = {
> + XATTR_NAME_CAPS,
> + NULL
> +};
> +
> +/*
> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> + *
> + * @name: full name of the extended attribute
> + * @prefix: do a prefix match (true) or a full match (false)
> + *
> + * This function returns < 0 if not supported, an index into userns_xattrs[]
> + * otherwise.
> + */
> +static int
> +xattr_is_userns_supported(const char *name, int prefix)
> +{
> + int i;
> +
> + if (!name)
> + return -1;
> +
> + for (i = 0; userns_xattrs[i]; i++) {
> + if (prefix) {
> + if (!strncmp(userns_xattrs[i], name,
> + strlen(userns_xattrs[i])))
> + return i;
> + } else {
> + if (!strcmp(userns_xattrs[i], name))
> + return i;
> + }
> + }
> + return -1;
> +}
> +
> +/*
> + * xattr_write_uid - print a string in the format of "%s@uid=%u", which
> + * includes a prefix string
> + *
> + * @uid: the uid
> + * @prefix: prefix string; may be NULL
> + *
> + * This function returns a buffer with the string, or a NULL pointer in
> + * case of out-of-memory error.
> + */
> +static char *
> +xattr_write_uid(uid_t uid, const char *prefix)
> +{
> + size_t buflen;
> + char *buffer;
> +
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
> + if (prefix)
> + buflen += strlen(prefix);
> +
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer)
> + return NULL;
> +
> + if (uid == 0)
> + *buffer = 0;
> + else
> + sprintf(buffer, "%s@uid=%u",
> + (prefix) ? prefix : "",
> + uid);
> +
> + return buffer;
> +}
> +
> +/*
> + * xattr_parse_uid_from_kuid - parse string in the format @uid=<uid>; consider
> + * user namespaces and check mappings
> + *
> + * @uidstr : string in the format "@uid=<uid>"
> + * @userns : the user namespace to consult for uid mappings
> + * @n_uidstr : returned pointer holding the rewritten @uid=<uid> string with
> + * the uid remapped
> + *
> + * This function returns an error code or 0 in case of success. In case
> + * of success, 'n_uidstr' will hold a valid string.
> + */
> +static int
> +xattr_parse_uid_from_kuid(const char *uidstr, struct user_namespace *userns,
> + char **n_uidstr)
> +{
> + int n;
> + uid_t muid, p_uid;
> + char d;
> + kuid_t tuid;
> +
> + *n_uidstr = NULL;
> +
> + n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
> + if (n != 1)
> + return -EINVAL;
> +
> + /* do we have a mapping of the uid? */
> + tuid = KUIDT_INIT(p_uid);
> + muid = from_kuid(userns, tuid);
> + if (muid == -1)
> + return -ENOENT;
> +
> + *n_uidstr = xattr_write_uid(muid, NULL);
> + if (!*n_uidstr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +/*
> + * xattr_parse_uid_make_kuid - parse string in the format @uid=<uid>; consider
> + * user namespaces and check mappings
> + *
> + * @uidstr : string in the format "@uid=<uid>"
> + * @userns : the user namespace to consult for uid mappings
> + * @N_uidstr : returned pointer holding the rewritten @uid=<uid> string with
> + * the uid remapped
> + *
> + * This function returns an error code or 0 in case of success. In case
> + * of success, 'n_uidstr' will hold a valid string.
> + */
> +static int
> +xattr_parse_uid_make_kuid(const char *uidstr, struct user_namespace *userns,
> + char **n_uidstr)
> +{
> + int n;
> + uid_t p_uid;
> + char d;
> + kuid_t tuid;
> +
> + *n_uidstr = NULL;
> +
> + n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
> + if (n != 1)
> + return -EINVAL;
> +
> + tuid = make_kuid(userns, p_uid);
> + if (!uid_valid(tuid))
> + return -ENOENT;
> +
> + *n_uidstr = xattr_write_uid(__kuid_val(tuid), NULL);
> + if (!*n_uidstr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +/*
> + * xattr_rewrite_userns_xattr - Rewrite and filter an extended attribute
> + * considering user namespace uid mappings and
> + * user namespace support extended attributes
> + *
> + * @name: full name of the extended attribute
> + *
> + * This function returns NULL if the name is to be filtered. Otherwise it can
> + * return the input buffer or a new buffer that the caller needs to free. The
> + * new buffer contains a rewritten extended attribute whose string length may
> + * exceed that of the given name.
> + */
> +static char *
> +xattr_rewrite_userns_xattr(char *name)
> +{
> + int idx, error;
> + size_t len = 0, buflen;
> + char *buffer, *n_uidstr;
> +
> + /* prefix-match name against supported attributes */
> + idx = xattr_is_userns_supported(name, true);
> + if (idx < 0) {
> + /* only rewrite those in userns_xattr[*] */
> + return name;
> + }
> +
> + /* exact match ? */
> + len = strlen(userns_xattrs[idx]);
> + if (name[len] == 0)
> + return NULL;
> +
> + /*
> + * We must have a name[len] == '@'.
> + */
> + error = xattr_parse_uid_from_kuid(&name[len], current_user_ns(),
> + &n_uidstr);
> + if (error)
> + return NULL;
> +
> + buflen = len + strlen(n_uidstr) + 1;
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer) {
> + kfree(n_uidstr);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + name[len] = 0;
> +
> + snprintf(buffer, buflen, "%s%s", name, n_uidstr);
> +
> + name[len] = '@';
> +
> + kfree(n_uidstr);
> +
> + return buffer;
> +}
> +
> +/*
> + * xattr_list_contains - check whether an xattr list already contains a needle
> + *
> + * @list : 0-byte separated strings
> + * @listlen : length of the list
> + * @needle : the needle to search for
> + */
> +static int
> +xattr_list_contains(const char *list, size_t listlen, const char *needle)
> +{
> + size_t o = 0;
> +
> + while (o < listlen) {
> + if (!strcmp(&list[o], needle))
> + return true;
> + o += strlen(&list[o]) + 1;
> + }
> + return false;
> +}
> +
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = &list[s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);
> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)
> + break;
> + strcpy(&nlist[d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}
> +
> +/*
> + * xattr_userns_name - modify the name of a user namespace supported
> + * extended attribute
> + *
> + * In a user namespace we prevent read/write accesses to the host's
> + * security.foo to protect these extended attributes.
> + *
> + * Reading:
> + * 1a) Reading security.foo from a user namespace will read
> + * security.foo@uid=<uid> of the parent user namespace instead with uid
> + * being the mapping of root in that parent user namespace. An
> + * exception is if root is mapped to uid 0 on the host, and in this case
> + * we will read security.foo directly.
> + * -> reading security.foo will read security.foo@uid=1000 for a uid
> + * mapping of root to 1000.
> + *
> + * 1b) If security.foo@uid=<uid> is not available, the security.foo of the
> + * parent namespace is tried to be read. This procedure is repeated up to
> + * the init user namespace. This step only applies for reading of extended
> + * attributes and provides the same behavior as older systems where the
> + * host's extended attributes applied to user namespaces.
> + *
> + * 2) All security.foo@uid=<uid> with valid uid mappings in the user namespace
> + * an be read. The uid within the user namespace will be mapped to the
> + * corresponding uid on the host and that uid will be used in the name of
> + * the extended attribute.
> + * -> reading security.foo@uid=1 will read security.foo@uid=1001 for a uid
> + * mapping of root to 1000, size of at least 2.
> + *
> + * All security.foo@uid=<uid> can be read (by root) on the host with values
> + * of <uid> also being subject to checking for valid mappings.
> + *
> + * 3) No other security.foo* can be read.
> + *
> + * Writing and removing:
> + * The same rules for reading apply to writing and removing, except for 1b).
> + *
> + * This function returns a buffer with either the original name or the
> + * user namespace adjusted name of the extended attribute.
> + *
> + * @name: the full name of the extended attribute, e.g. security.foo
> + */
> +char *
> +xattr_userns_name(const char *name, struct user_namespace *userns)
> +{
> + size_t buflen;
> + char *buffer, *n_uidstr;
> + kuid_t root_uid = make_kuid(userns, 0);
> + int idx, error;
> + size_t len;
> +
> + /* only security.foo will be changed here - prefix match here */
> + idx = xattr_is_userns_supported(name, true);
> + if (idx < 0)
> + goto out_copy;
> +
> + /* read security.foo? --> read security.foo@uid=<uid> instead */
> + len = strlen(userns_xattrs[idx]);
> + if (name[len] == 0) {
> + /*
> + * init_user_ns or userns with root mapped to uid 0
> + * may read security.foo directly
> + */
> + if (userns == &init_user_ns ||
> + __kuid_val(root_uid) == 0)
> + goto out_copy;
> +
> + if (!uid_valid(root_uid))
> + return ERR_PTR(-EINVAL);
> +
> + buffer = xattr_write_uid(__kuid_val(root_uid), name);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + return buffer;
> + }
> +
> + /*
> + * We must have name[len] == '@'.
> + */
> + error = xattr_parse_uid_make_kuid(&name[len],
> + userns,
> + &n_uidstr);
> + if (error)
> + return ERR_PTR(error);
> +
> + /* name[len] == '@' */
> + buflen = len + strlen(n_uidstr) + 1;
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer) {
> + kfree(n_uidstr);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + snprintf(buffer, len + 1, "%s", name);
> + snprintf(&buffer[len], buflen - len, "%s", n_uidstr);
> + kfree(n_uidstr);
> +
> + return buffer;
> +
> +out_copy:
> + buffer = kstrdup(name, GFP_KERNEL);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + return buffer;
> +}
> +
> int
> __vfs_setxattr(struct dentry *dentry, struct inode *inode, const char *name,
> const void *value, size_t size, int flags)
> {
> const struct xattr_handler *handler;
> + char *newname;
> + int ret;
>
> + newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> + name = newname;
> handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->set)
> - return -EOPNOTSUPP;
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->set) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> if (size == 0)
> value = ""; /* empty EA, do not remove */
> - return handler->set(handler, dentry, inode, name, value, size, flags);
> + ret = handler->set(handler, dentry, inode, name, value, size, flags);
> +
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_setxattr);
>
> @@ -301,14 +721,39 @@ ssize_t
> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> void *value, size_t size)
> {
> - const struct xattr_handler *handler;
> + const struct xattr_handler *handler = NULL;
> + char *newname = NULL;
> + int ret, userns_supt_xattr;
> + struct user_namespace *userns = current_user_ns();
> +
> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
> +
> + do {
> + kfree(newname);
> +
> + newname = xattr_userns_name(name, userns);
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + if (!handler) {
> + name = newname;
> + handler = xattr_resolve_name(inode, &name);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->get) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + }
> + ret = handler->get(handler, dentry, inode, name, value, size);
> + userns = userns->parent;
> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>
> - handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->get)
> - return -EOPNOTSUPP;
> - return handler->get(handler, dentry, inode, name, value, size);
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_getxattr);
>
> @@ -328,8 +773,16 @@ vfs_getxattr(struct dentry *dentry, const char *name, void *value, size_t size)
>
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> XATTR_SECURITY_PREFIX_LEN)) {
> - const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
> - int ret = xattr_getsecurity(inode, suffix, value, size);
> + int ret;
> + const char *suffix;
> + char *newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + suffix = newname + XATTR_SECURITY_PREFIX_LEN;
> +
> + ret = xattr_getsecurity(inode, suffix, value, size);
> + kfree(newname);
> /*
> * Only overwrite the return value if a security module
> * is actually active.
> @@ -360,6 +813,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t size)
> if (size && error > size)
> error = -ERANGE;
> }
> + if (error > 0)
> + error = xattr_list_userns_rewrite(list, error, size);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_listxattr);
> @@ -369,13 +825,28 @@ __vfs_removexattr(struct dentry *dentry, const char *name)
> {
> struct inode *inode = d_inode(dentry);
> const struct xattr_handler *handler;
> + char *newname;
> + int ret;
>
> + newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> + name = newname;
> handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->set)
> - return -EOPNOTSUPP;
> - return handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->set) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + ret = handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
> +
> +out:
> + kfree(newname);
> +
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_removexattr);
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 7abebd7..c842690 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -660,15 +660,23 @@ int cap_bprm_secureexec(struct linux_binprm *bprm)
> int cap_inode_setxattr(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags)
> {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
> + return 0;
> +
> + if (strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1) == 0) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> +
> return 0;
> }
>
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> - !capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> return 0;
> }
> @@ -686,15 +694,23 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name,
> */
> int cap_inode_removexattr(struct dentry *dentry, const char *name)
> {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
> + return 0;
> +
> + if (strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1) == 0) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> +
> return 0;
> }
>
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> - !capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> return 0;
> }
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 819fd68..702c225 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3091,8 +3091,13 @@ static int selinux_inode_setotherxattr(struct dentry *dentry, const char *name)
>
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> sizeof XATTR_SECURITY_PREFIX - 1)) {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (!strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1)) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> } else if (!capable(CAP_SYS_ADMIN)) {
> /* A different attribute in the security namespace.
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 13:25 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-12 13:25 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 22421 bytes --]
Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo(a)uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo(a)uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo(a)uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo(a)uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo(a)uid=1 will read security.foo(a)uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo(a)uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo(a)uid=1000 will be listed as security.foo in the user
> namespace, security.foo(a)uid=1001 becomes security.foo(a)uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
It doesn't look like this is coming through Serge so I don't see how
the Signed-off-by tag is legtimate.
>From the replies to this it doesn't look like Serge has reviewed this
version either.
I am disappointed that all of my concerns about technical feasibility
remain unaddressed.
I hope my reading and review of the code goes better than my reading of
it's introduction.
Eric
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 464c94b..eacad9e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> return inode_permission(inode, mask);
> }
>
> +/*
> + * A list of extended attributes that are supported in user namespaces
> + */
> +static const char *const userns_xattrs[] = {
> + XATTR_NAME_CAPS,
> + NULL
> +};
> +
> +/*
> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> + *
> + * @name: full name of the extended attribute
> + * @prefix: do a prefix match (true) or a full match (false)
> + *
> + * This function returns < 0 if not supported, an index into userns_xattrs[]
> + * otherwise.
> + */
> +static int
> +xattr_is_userns_supported(const char *name, int prefix)
> +{
> + int i;
> +
> + if (!name)
> + return -1;
> +
> + for (i = 0; userns_xattrs[i]; i++) {
> + if (prefix) {
> + if (!strncmp(userns_xattrs[i], name,
> + strlen(userns_xattrs[i])))
> + return i;
> + } else {
> + if (!strcmp(userns_xattrs[i], name))
> + return i;
> + }
> + }
> + return -1;
> +}
> +
> +/*
> + * xattr_write_uid - print a string in the format of "%s(a)uid=%u", which
> + * includes a prefix string
> + *
> + * @uid: the uid
> + * @prefix: prefix string; may be NULL
> + *
> + * This function returns a buffer with the string, or a NULL pointer in
> + * case of out-of-memory error.
> + */
> +static char *
> +xattr_write_uid(uid_t uid, const char *prefix)
> +{
> + size_t buflen;
> + char *buffer;
> +
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
> + if (prefix)
> + buflen += strlen(prefix);
> +
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer)
> + return NULL;
> +
> + if (uid == 0)
> + *buffer = 0;
> + else
> + sprintf(buffer, "%s(a)uid=%u",
> + (prefix) ? prefix : "",
> + uid);
> +
> + return buffer;
> +}
> +
> +/*
> + * xattr_parse_uid_from_kuid - parse string in the format @uid=<uid>; consider
> + * user namespaces and check mappings
> + *
> + * @uidstr : string in the format "@uid=<uid>"
> + * @userns : the user namespace to consult for uid mappings
> + * @n_uidstr : returned pointer holding the rewritten @uid=<uid> string with
> + * the uid remapped
> + *
> + * This function returns an error code or 0 in case of success. In case
> + * of success, 'n_uidstr' will hold a valid string.
> + */
> +static int
> +xattr_parse_uid_from_kuid(const char *uidstr, struct user_namespace *userns,
> + char **n_uidstr)
> +{
> + int n;
> + uid_t muid, p_uid;
> + char d;
> + kuid_t tuid;
> +
> + *n_uidstr = NULL;
> +
> + n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
> + if (n != 1)
> + return -EINVAL;
> +
> + /* do we have a mapping of the uid? */
> + tuid = KUIDT_INIT(p_uid);
> + muid = from_kuid(userns, tuid);
> + if (muid == -1)
> + return -ENOENT;
> +
> + *n_uidstr = xattr_write_uid(muid, NULL);
> + if (!*n_uidstr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +/*
> + * xattr_parse_uid_make_kuid - parse string in the format @uid=<uid>; consider
> + * user namespaces and check mappings
> + *
> + * @uidstr : string in the format "@uid=<uid>"
> + * @userns : the user namespace to consult for uid mappings
> + * @N_uidstr : returned pointer holding the rewritten @uid=<uid> string with
> + * the uid remapped
> + *
> + * This function returns an error code or 0 in case of success. In case
> + * of success, 'n_uidstr' will hold a valid string.
> + */
> +static int
> +xattr_parse_uid_make_kuid(const char *uidstr, struct user_namespace *userns,
> + char **n_uidstr)
> +{
> + int n;
> + uid_t p_uid;
> + char d;
> + kuid_t tuid;
> +
> + *n_uidstr = NULL;
> +
> + n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
> + if (n != 1)
> + return -EINVAL;
> +
> + tuid = make_kuid(userns, p_uid);
> + if (!uid_valid(tuid))
> + return -ENOENT;
> +
> + *n_uidstr = xattr_write_uid(__kuid_val(tuid), NULL);
> + if (!*n_uidstr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +/*
> + * xattr_rewrite_userns_xattr - Rewrite and filter an extended attribute
> + * considering user namespace uid mappings and
> + * user namespace support extended attributes
> + *
> + * @name: full name of the extended attribute
> + *
> + * This function returns NULL if the name is to be filtered. Otherwise it can
> + * return the input buffer or a new buffer that the caller needs to free. The
> + * new buffer contains a rewritten extended attribute whose string length may
> + * exceed that of the given name.
> + */
> +static char *
> +xattr_rewrite_userns_xattr(char *name)
> +{
> + int idx, error;
> + size_t len = 0, buflen;
> + char *buffer, *n_uidstr;
> +
> + /* prefix-match name against supported attributes */
> + idx = xattr_is_userns_supported(name, true);
> + if (idx < 0) {
> + /* only rewrite those in userns_xattr[*] */
> + return name;
> + }
> +
> + /* exact match ? */
> + len = strlen(userns_xattrs[idx]);
> + if (name[len] == 0)
> + return NULL;
> +
> + /*
> + * We must have a name[len] == '@'.
> + */
> + error = xattr_parse_uid_from_kuid(&name[len], current_user_ns(),
> + &n_uidstr);
> + if (error)
> + return NULL;
> +
> + buflen = len + strlen(n_uidstr) + 1;
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer) {
> + kfree(n_uidstr);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + name[len] = 0;
> +
> + snprintf(buffer, buflen, "%s%s", name, n_uidstr);
> +
> + name[len] = '@';
> +
> + kfree(n_uidstr);
> +
> + return buffer;
> +}
> +
> +/*
> + * xattr_list_contains - check whether an xattr list already contains a needle
> + *
> + * @list : 0-byte separated strings
> + * @listlen : length of the list
> + * @needle : the needle to search for
> + */
> +static int
> +xattr_list_contains(const char *list, size_t listlen, const char *needle)
> +{
> + size_t o = 0;
> +
> + while (o < listlen) {
> + if (!strcmp(&list[o], needle))
> + return true;
> + o += strlen(&list[o]) + 1;
> + }
> + return false;
> +}
> +
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = &list[s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);
> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)
> + break;
> + strcpy(&nlist[d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}
> +
> +/*
> + * xattr_userns_name - modify the name of a user namespace supported
> + * extended attribute
> + *
> + * In a user namespace we prevent read/write accesses to the host's
> + * security.foo to protect these extended attributes.
> + *
> + * Reading:
> + * 1a) Reading security.foo from a user namespace will read
> + * security.foo(a)uid=<uid> of the parent user namespace instead with uid
> + * being the mapping of root in that parent user namespace. An
> + * exception is if root is mapped to uid 0 on the host, and in this case
> + * we will read security.foo directly.
> + * -> reading security.foo will read security.foo(a)uid=1000 for a uid
> + * mapping of root to 1000.
> + *
> + * 1b) If security.foo(a)uid=<uid> is not available, the security.foo of the
> + * parent namespace is tried to be read. This procedure is repeated up to
> + * the init user namespace. This step only applies for reading of extended
> + * attributes and provides the same behavior as older systems where the
> + * host's extended attributes applied to user namespaces.
> + *
> + * 2) All security.foo(a)uid=<uid> with valid uid mappings in the user namespace
> + * an be read. The uid within the user namespace will be mapped to the
> + * corresponding uid on the host and that uid will be used in the name of
> + * the extended attribute.
> + * -> reading security.foo(a)uid=1 will read security.foo(a)uid=1001 for a uid
> + * mapping of root to 1000, size of at least 2.
> + *
> + * All security.foo(a)uid=<uid> can be read (by root) on the host with values
> + * of <uid> also being subject to checking for valid mappings.
> + *
> + * 3) No other security.foo* can be read.
> + *
> + * Writing and removing:
> + * The same rules for reading apply to writing and removing, except for 1b).
> + *
> + * This function returns a buffer with either the original name or the
> + * user namespace adjusted name of the extended attribute.
> + *
> + * @name: the full name of the extended attribute, e.g. security.foo
> + */
> +char *
> +xattr_userns_name(const char *name, struct user_namespace *userns)
> +{
> + size_t buflen;
> + char *buffer, *n_uidstr;
> + kuid_t root_uid = make_kuid(userns, 0);
> + int idx, error;
> + size_t len;
> +
> + /* only security.foo will be changed here - prefix match here */
> + idx = xattr_is_userns_supported(name, true);
> + if (idx < 0)
> + goto out_copy;
> +
> + /* read security.foo? --> read security.foo(a)uid=<uid> instead */
> + len = strlen(userns_xattrs[idx]);
> + if (name[len] == 0) {
> + /*
> + * init_user_ns or userns with root mapped to uid 0
> + * may read security.foo directly
> + */
> + if (userns == &init_user_ns ||
> + __kuid_val(root_uid) == 0)
> + goto out_copy;
> +
> + if (!uid_valid(root_uid))
> + return ERR_PTR(-EINVAL);
> +
> + buffer = xattr_write_uid(__kuid_val(root_uid), name);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + return buffer;
> + }
> +
> + /*
> + * We must have name[len] == '@'.
> + */
> + error = xattr_parse_uid_make_kuid(&name[len],
> + userns,
> + &n_uidstr);
> + if (error)
> + return ERR_PTR(error);
> +
> + /* name[len] == '@' */
> + buflen = len + strlen(n_uidstr) + 1;
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer) {
> + kfree(n_uidstr);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + snprintf(buffer, len + 1, "%s", name);
> + snprintf(&buffer[len], buflen - len, "%s", n_uidstr);
> + kfree(n_uidstr);
> +
> + return buffer;
> +
> +out_copy:
> + buffer = kstrdup(name, GFP_KERNEL);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + return buffer;
> +}
> +
> int
> __vfs_setxattr(struct dentry *dentry, struct inode *inode, const char *name,
> const void *value, size_t size, int flags)
> {
> const struct xattr_handler *handler;
> + char *newname;
> + int ret;
>
> + newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> + name = newname;
> handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->set)
> - return -EOPNOTSUPP;
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->set) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> if (size == 0)
> value = ""; /* empty EA, do not remove */
> - return handler->set(handler, dentry, inode, name, value, size, flags);
> + ret = handler->set(handler, dentry, inode, name, value, size, flags);
> +
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_setxattr);
>
> @@ -301,14 +721,39 @@ ssize_t
> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> void *value, size_t size)
> {
> - const struct xattr_handler *handler;
> + const struct xattr_handler *handler = NULL;
> + char *newname = NULL;
> + int ret, userns_supt_xattr;
> + struct user_namespace *userns = current_user_ns();
> +
> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
> +
> + do {
> + kfree(newname);
> +
> + newname = xattr_userns_name(name, userns);
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + if (!handler) {
> + name = newname;
> + handler = xattr_resolve_name(inode, &name);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->get) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + }
> + ret = handler->get(handler, dentry, inode, name, value, size);
> + userns = userns->parent;
> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>
> - handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->get)
> - return -EOPNOTSUPP;
> - return handler->get(handler, dentry, inode, name, value, size);
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_getxattr);
>
> @@ -328,8 +773,16 @@ vfs_getxattr(struct dentry *dentry, const char *name, void *value, size_t size)
>
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> XATTR_SECURITY_PREFIX_LEN)) {
> - const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
> - int ret = xattr_getsecurity(inode, suffix, value, size);
> + int ret;
> + const char *suffix;
> + char *newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + suffix = newname + XATTR_SECURITY_PREFIX_LEN;
> +
> + ret = xattr_getsecurity(inode, suffix, value, size);
> + kfree(newname);
> /*
> * Only overwrite the return value if a security module
> * is actually active.
> @@ -360,6 +813,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t size)
> if (size && error > size)
> error = -ERANGE;
> }
> + if (error > 0)
> + error = xattr_list_userns_rewrite(list, error, size);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_listxattr);
> @@ -369,13 +825,28 @@ __vfs_removexattr(struct dentry *dentry, const char *name)
> {
> struct inode *inode = d_inode(dentry);
> const struct xattr_handler *handler;
> + char *newname;
> + int ret;
>
> + newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> + name = newname;
> handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->set)
> - return -EOPNOTSUPP;
> - return handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->set) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + ret = handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
> +
> +out:
> + kfree(newname);
> +
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_removexattr);
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 7abebd7..c842690 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -660,15 +660,23 @@ int cap_bprm_secureexec(struct linux_binprm *bprm)
> int cap_inode_setxattr(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags)
> {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
> + return 0;
> +
> + if (strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1) == 0) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> +
> return 0;
> }
>
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> - !capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> return 0;
> }
> @@ -686,15 +694,23 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name,
> */
> int cap_inode_removexattr(struct dentry *dentry, const char *name)
> {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
> + return 0;
> +
> + if (strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1) == 0) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> +
> return 0;
> }
>
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> - !capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> return 0;
> }
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 819fd68..702c225 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3091,8 +3091,13 @@ static int selinux_inode_setotherxattr(struct dentry *dentry, const char *name)
>
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> sizeof XATTR_SECURITY_PREFIX - 1)) {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (!strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1)) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> } else if (!capable(CAP_SYS_ADMIN)) {
> /* A different attribute in the security namespace.
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 13:25 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-12 13:25 UTC (permalink / raw)
To: linux-security-module
Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo at uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo at uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo at uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo at uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo at uid=1 will read security.foo at uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo at uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo at uid=1000 will be listed as security.foo in the user
> namespace, security.foo at uid=1001 becomes security.foo at uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
It doesn't look like this is coming through Serge so I don't see how
the Signed-off-by tag is legtimate.
>From the replies to this it doesn't look like Serge has reviewed this
version either.
I am disappointed that all of my concerns about technical feasibility
remain unaddressed.
I hope my reading and review of the code goes better than my reading of
it's introduction.
Eric
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 464c94b..eacad9e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> return inode_permission(inode, mask);
> }
>
> +/*
> + * A list of extended attributes that are supported in user namespaces
> + */
> +static const char *const userns_xattrs[] = {
> + XATTR_NAME_CAPS,
> + NULL
> +};
> +
> +/*
> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> + *
> + * @name: full name of the extended attribute
> + * @prefix: do a prefix match (true) or a full match (false)
> + *
> + * This function returns < 0 if not supported, an index into userns_xattrs[]
> + * otherwise.
> + */
> +static int
> +xattr_is_userns_supported(const char *name, int prefix)
> +{
> + int i;
> +
> + if (!name)
> + return -1;
> +
> + for (i = 0; userns_xattrs[i]; i++) {
> + if (prefix) {
> + if (!strncmp(userns_xattrs[i], name,
> + strlen(userns_xattrs[i])))
> + return i;
> + } else {
> + if (!strcmp(userns_xattrs[i], name))
> + return i;
> + }
> + }
> + return -1;
> +}
> +
> +/*
> + * xattr_write_uid - print a string in the format of "%s at uid=%u", which
> + * includes a prefix string
> + *
> + * @uid: the uid
> + * @prefix: prefix string; may be NULL
> + *
> + * This function returns a buffer with the string, or a NULL pointer in
> + * case of out-of-memory error.
> + */
> +static char *
> +xattr_write_uid(uid_t uid, const char *prefix)
> +{
> + size_t buflen;
> + char *buffer;
> +
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
> + if (prefix)
> + buflen += strlen(prefix);
> +
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer)
> + return NULL;
> +
> + if (uid == 0)
> + *buffer = 0;
> + else
> + sprintf(buffer, "%s at uid=%u",
> + (prefix) ? prefix : "",
> + uid);
> +
> + return buffer;
> +}
> +
> +/*
> + * xattr_parse_uid_from_kuid - parse string in the format @uid=<uid>; consider
> + * user namespaces and check mappings
> + *
> + * @uidstr : string in the format "@uid=<uid>"
> + * @userns : the user namespace to consult for uid mappings
> + * @n_uidstr : returned pointer holding the rewritten @uid=<uid> string with
> + * the uid remapped
> + *
> + * This function returns an error code or 0 in case of success. In case
> + * of success, 'n_uidstr' will hold a valid string.
> + */
> +static int
> +xattr_parse_uid_from_kuid(const char *uidstr, struct user_namespace *userns,
> + char **n_uidstr)
> +{
> + int n;
> + uid_t muid, p_uid;
> + char d;
> + kuid_t tuid;
> +
> + *n_uidstr = NULL;
> +
> + n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
> + if (n != 1)
> + return -EINVAL;
> +
> + /* do we have a mapping of the uid? */
> + tuid = KUIDT_INIT(p_uid);
> + muid = from_kuid(userns, tuid);
> + if (muid == -1)
> + return -ENOENT;
> +
> + *n_uidstr = xattr_write_uid(muid, NULL);
> + if (!*n_uidstr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +/*
> + * xattr_parse_uid_make_kuid - parse string in the format @uid=<uid>; consider
> + * user namespaces and check mappings
> + *
> + * @uidstr : string in the format "@uid=<uid>"
> + * @userns : the user namespace to consult for uid mappings
> + * @N_uidstr : returned pointer holding the rewritten @uid=<uid> string with
> + * the uid remapped
> + *
> + * This function returns an error code or 0 in case of success. In case
> + * of success, 'n_uidstr' will hold a valid string.
> + */
> +static int
> +xattr_parse_uid_make_kuid(const char *uidstr, struct user_namespace *userns,
> + char **n_uidstr)
> +{
> + int n;
> + uid_t p_uid;
> + char d;
> + kuid_t tuid;
> +
> + *n_uidstr = NULL;
> +
> + n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
> + if (n != 1)
> + return -EINVAL;
> +
> + tuid = make_kuid(userns, p_uid);
> + if (!uid_valid(tuid))
> + return -ENOENT;
> +
> + *n_uidstr = xattr_write_uid(__kuid_val(tuid), NULL);
> + if (!*n_uidstr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +/*
> + * xattr_rewrite_userns_xattr - Rewrite and filter an extended attribute
> + * considering user namespace uid mappings and
> + * user namespace support extended attributes
> + *
> + * @name: full name of the extended attribute
> + *
> + * This function returns NULL if the name is to be filtered. Otherwise it can
> + * return the input buffer or a new buffer that the caller needs to free. The
> + * new buffer contains a rewritten extended attribute whose string length may
> + * exceed that of the given name.
> + */
> +static char *
> +xattr_rewrite_userns_xattr(char *name)
> +{
> + int idx, error;
> + size_t len = 0, buflen;
> + char *buffer, *n_uidstr;
> +
> + /* prefix-match name against supported attributes */
> + idx = xattr_is_userns_supported(name, true);
> + if (idx < 0) {
> + /* only rewrite those in userns_xattr[*] */
> + return name;
> + }
> +
> + /* exact match ? */
> + len = strlen(userns_xattrs[idx]);
> + if (name[len] == 0)
> + return NULL;
> +
> + /*
> + * We must have a name[len] == '@'.
> + */
> + error = xattr_parse_uid_from_kuid(&name[len], current_user_ns(),
> + &n_uidstr);
> + if (error)
> + return NULL;
> +
> + buflen = len + strlen(n_uidstr) + 1;
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer) {
> + kfree(n_uidstr);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + name[len] = 0;
> +
> + snprintf(buffer, buflen, "%s%s", name, n_uidstr);
> +
> + name[len] = '@';
> +
> + kfree(n_uidstr);
> +
> + return buffer;
> +}
> +
> +/*
> + * xattr_list_contains - check whether an xattr list already contains a needle
> + *
> + * @list : 0-byte separated strings
> + * @listlen : length of the list
> + * @needle : the needle to search for
> + */
> +static int
> +xattr_list_contains(const char *list, size_t listlen, const char *needle)
> +{
> + size_t o = 0;
> +
> + while (o < listlen) {
> + if (!strcmp(&list[o], needle))
> + return true;
> + o += strlen(&list[o]) + 1;
> + }
> + return false;
> +}
> +
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = &list[s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);
> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)
> + break;
> + strcpy(&nlist[d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}
> +
> +/*
> + * xattr_userns_name - modify the name of a user namespace supported
> + * extended attribute
> + *
> + * In a user namespace we prevent read/write accesses to the host's
> + * security.foo to protect these extended attributes.
> + *
> + * Reading:
> + * 1a) Reading security.foo from a user namespace will read
> + * security.foo at uid=<uid> of the parent user namespace instead with uid
> + * being the mapping of root in that parent user namespace. An
> + * exception is if root is mapped to uid 0 on the host, and in this case
> + * we will read security.foo directly.
> + * -> reading security.foo will read security.foo at uid=1000 for a uid
> + * mapping of root to 1000.
> + *
> + * 1b) If security.foo at uid=<uid> is not available, the security.foo of the
> + * parent namespace is tried to be read. This procedure is repeated up to
> + * the init user namespace. This step only applies for reading of extended
> + * attributes and provides the same behavior as older systems where the
> + * host's extended attributes applied to user namespaces.
> + *
> + * 2) All security.foo at uid=<uid> with valid uid mappings in the user namespace
> + * an be read. The uid within the user namespace will be mapped to the
> + * corresponding uid on the host and that uid will be used in the name of
> + * the extended attribute.
> + * -> reading security.foo at uid=1 will read security.foo at uid=1001 for a uid
> + * mapping of root to 1000, size of at least 2.
> + *
> + * All security.foo at uid=<uid> can be read (by root) on the host with values
> + * of <uid> also being subject to checking for valid mappings.
> + *
> + * 3) No other security.foo* can be read.
> + *
> + * Writing and removing:
> + * The same rules for reading apply to writing and removing, except for 1b).
> + *
> + * This function returns a buffer with either the original name or the
> + * user namespace adjusted name of the extended attribute.
> + *
> + * @name: the full name of the extended attribute, e.g. security.foo
> + */
> +char *
> +xattr_userns_name(const char *name, struct user_namespace *userns)
> +{
> + size_t buflen;
> + char *buffer, *n_uidstr;
> + kuid_t root_uid = make_kuid(userns, 0);
> + int idx, error;
> + size_t len;
> +
> + /* only security.foo will be changed here - prefix match here */
> + idx = xattr_is_userns_supported(name, true);
> + if (idx < 0)
> + goto out_copy;
> +
> + /* read security.foo? --> read security.foo at uid=<uid> instead */
> + len = strlen(userns_xattrs[idx]);
> + if (name[len] == 0) {
> + /*
> + * init_user_ns or userns with root mapped to uid 0
> + * may read security.foo directly
> + */
> + if (userns == &init_user_ns ||
> + __kuid_val(root_uid) == 0)
> + goto out_copy;
> +
> + if (!uid_valid(root_uid))
> + return ERR_PTR(-EINVAL);
> +
> + buffer = xattr_write_uid(__kuid_val(root_uid), name);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + return buffer;
> + }
> +
> + /*
> + * We must have name[len] == '@'.
> + */
> + error = xattr_parse_uid_make_kuid(&name[len],
> + userns,
> + &n_uidstr);
> + if (error)
> + return ERR_PTR(error);
> +
> + /* name[len] == '@' */
> + buflen = len + strlen(n_uidstr) + 1;
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer) {
> + kfree(n_uidstr);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + snprintf(buffer, len + 1, "%s", name);
> + snprintf(&buffer[len], buflen - len, "%s", n_uidstr);
> + kfree(n_uidstr);
> +
> + return buffer;
> +
> +out_copy:
> + buffer = kstrdup(name, GFP_KERNEL);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + return buffer;
> +}
> +
> int
> __vfs_setxattr(struct dentry *dentry, struct inode *inode, const char *name,
> const void *value, size_t size, int flags)
> {
> const struct xattr_handler *handler;
> + char *newname;
> + int ret;
>
> + newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> + name = newname;
> handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->set)
> - return -EOPNOTSUPP;
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->set) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> if (size == 0)
> value = ""; /* empty EA, do not remove */
> - return handler->set(handler, dentry, inode, name, value, size, flags);
> + ret = handler->set(handler, dentry, inode, name, value, size, flags);
> +
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_setxattr);
>
> @@ -301,14 +721,39 @@ ssize_t
> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> void *value, size_t size)
> {
> - const struct xattr_handler *handler;
> + const struct xattr_handler *handler = NULL;
> + char *newname = NULL;
> + int ret, userns_supt_xattr;
> + struct user_namespace *userns = current_user_ns();
> +
> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
> +
> + do {
> + kfree(newname);
> +
> + newname = xattr_userns_name(name, userns);
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + if (!handler) {
> + name = newname;
> + handler = xattr_resolve_name(inode, &name);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->get) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + }
> + ret = handler->get(handler, dentry, inode, name, value, size);
> + userns = userns->parent;
> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>
> - handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->get)
> - return -EOPNOTSUPP;
> - return handler->get(handler, dentry, inode, name, value, size);
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_getxattr);
>
> @@ -328,8 +773,16 @@ vfs_getxattr(struct dentry *dentry, const char *name, void *value, size_t size)
>
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> XATTR_SECURITY_PREFIX_LEN)) {
> - const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
> - int ret = xattr_getsecurity(inode, suffix, value, size);
> + int ret;
> + const char *suffix;
> + char *newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + suffix = newname + XATTR_SECURITY_PREFIX_LEN;
> +
> + ret = xattr_getsecurity(inode, suffix, value, size);
> + kfree(newname);
> /*
> * Only overwrite the return value if a security module
> * is actually active.
> @@ -360,6 +813,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t size)
> if (size && error > size)
> error = -ERANGE;
> }
> + if (error > 0)
> + error = xattr_list_userns_rewrite(list, error, size);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_listxattr);
> @@ -369,13 +825,28 @@ __vfs_removexattr(struct dentry *dentry, const char *name)
> {
> struct inode *inode = d_inode(dentry);
> const struct xattr_handler *handler;
> + char *newname;
> + int ret;
>
> + newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> + name = newname;
> handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->set)
> - return -EOPNOTSUPP;
> - return handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->set) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + ret = handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
> +
> +out:
> + kfree(newname);
> +
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_removexattr);
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 7abebd7..c842690 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -660,15 +660,23 @@ int cap_bprm_secureexec(struct linux_binprm *bprm)
> int cap_inode_setxattr(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags)
> {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
> + return 0;
> +
> + if (strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1) == 0) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> +
> return 0;
> }
>
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> - !capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> return 0;
> }
> @@ -686,15 +694,23 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name,
> */
> int cap_inode_removexattr(struct dentry *dentry, const char *name)
> {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
> + return 0;
> +
> + if (strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1) == 0) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> +
> return 0;
> }
>
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> - !capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> return 0;
> }
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 819fd68..702c225 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3091,8 +3091,13 @@ static int selinux_inode_setotherxattr(struct dentry *dentry, const char *name)
>
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> sizeof XATTR_SECURITY_PREFIX - 1)) {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (!strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1)) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> } else if (!capable(CAP_SYS_ADMIN)) {
> /* A different attribute in the security namespace.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <87mv89iy7q.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 13:25 ` Eric W. Biederman
(?)
@ 2017-07-12 17:03 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 17:03 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> > Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> > Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> > Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>
> It doesn't look like this is coming through Serge so I don't see how
> the Signed-off-by tag is legtimate.
This is mostly explained by the fact that there have been a *lot* of
changes, many of them discussed in private emails.
> >From the replies to this it doesn't look like Serge has reviewed this
> version either.
>
> I am disappointed that all of my concerns about technical feasibility
> remain unaddressed.
Can you re-state those, or give a link to them?
I'd really like to get to a point where unprivileged containers can start
using filecaps - at this point if that means having an extra temporary
file format based on my earlier patchset while we hash this out, that
actually seems worthwhile. But it would of course be ideal if we could
do the name based caps right in the first place.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 17:03 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 17:03 UTC (permalink / raw)
To: linux-security-module
Quoting Eric W. Biederman (ebiederm at xmission.com):
> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>
> It doesn't look like this is coming through Serge so I don't see how
> the Signed-off-by tag is legtimate.
This is mostly explained by the fact that there have been a *lot* of
changes, many of them discussed in private emails.
> >From the replies to this it doesn't look like Serge has reviewed this
> version either.
>
> I am disappointed that all of my concerns about technical feasibility
> remain unaddressed.
Can you re-state those, or give a link to them?
I'd really like to get to a point where unprivileged containers can start
using filecaps - at this point if that means having an extra temporary
file format based on my earlier patchset while we hash this out, that
actually seems worthwhile. But it would of course be ideal if we could
do the name based caps right in the first place.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 17:03 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 17:03 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stefan Berger, containers, lkp, linux-kernel, zohar, tycho,
serge, James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>
> It doesn't look like this is coming through Serge so I don't see how
> the Signed-off-by tag is legtimate.
This is mostly explained by the fact that there have been a *lot* of
changes, many of them discussed in private emails.
> >From the replies to this it doesn't look like Serge has reviewed this
> version either.
>
> I am disappointed that all of my concerns about technical feasibility
> remain unaddressed.
Can you re-state those, or give a link to them?
I'd really like to get to a point where unprivileged containers can start
using filecaps - at this point if that means having an extra temporary
file format based on my earlier patchset while we hash this out, that
actually seems worthwhile. But it would of course be ideal if we could
do the name based caps right in the first place.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170712170346.GA17974-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 17:03 ` Serge E. Hallyn
(?)
(?)
@ 2017-07-12 22:20 ` James Morris
-1 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-12 22:20 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> > > Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> > > Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> > > Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> >
> > It doesn't look like this is coming through Serge so I don't see how
> > the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
Please try and keep technical discussions public or at least document them
when reposting the patches.
--
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 22:20 ` James Morris
0 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-12 22:20 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm(a)xmission.com):
> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> > > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> > > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >
> > It doesn't look like this is coming through Serge so I don't see how
> > the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
Please try and keep technical discussions public or at least document them
when reposting the patches.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 22:20 ` James Morris
0 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-12 22:20 UTC (permalink / raw)
To: linux-security-module
On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm at xmission.com):
> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> > > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> > > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >
> > It doesn't look like this is coming through Serge so I don't see how
> > the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
Please try and keep technical discussions public or at least document them
when reposting the patches.
--
James Morris
<jmorris@namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 22:20 ` James Morris
0 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-12 22:20 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Eric W. Biederman, Stefan Berger, containers, lkp, linux-kernel,
zohar, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> > > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> > > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >
> > It doesn't look like this is coming through Serge so I don't see how
> > the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
Please try and keep technical discussions public or at least document them
when reposting the patches.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <alpine.LRH.2.20.1707130820050.16810-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <alpine.LRH.2.20.1707130820050.16810-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
@ 2017-07-13 0:33 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 0:33 UTC (permalink / raw)
To: James Morris
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org> writes:
> On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
>
>> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>> > > Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>> > > Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>> > > Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>> >
>> > It doesn't look like this is coming through Serge so I don't see how
>> > the Signed-off-by tag is legtimate.
>>
>> This is mostly explained by the fact that there have been a *lot* of
>> changes, many of them discussed in private emails.
>
> Please try and keep technical discussions public or at least document them
> when reposting the patches.
Yes please.
A public discussion helps to understand what the challenges are.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 22:20 ` James Morris
(?)
@ 2017-07-13 0:33 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 0:33 UTC (permalink / raw)
To: James Morris
Cc: Serge E. Hallyn, Stefan Berger, containers, lkp, linux-kernel,
zohar, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
James Morris <jmorris@namei.org> writes:
> On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
>
>> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>> > > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> > > Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> >
>> > It doesn't look like this is coming through Serge so I don't see how
>> > the Signed-off-by tag is legtimate.
>>
>> This is mostly explained by the fact that there have been a *lot* of
>> changes, many of them discussed in private emails.
>
> Please try and keep technical discussions public or at least document them
> when reposting the patches.
Yes please.
A public discussion helps to understand what the challenges are.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 0:33 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 0:33 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
James Morris <jmorris@namei.org> writes:
> On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
>
>> Quoting Eric W. Biederman (ebiederm(a)xmission.com):
>> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>> > > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> > > Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> >
>> > It doesn't look like this is coming through Serge so I don't see how
>> > the Signed-off-by tag is legtimate.
>>
>> This is mostly explained by the fact that there have been a *lot* of
>> changes, many of them discussed in private emails.
>
> Please try and keep technical discussions public or at least document them
> when reposting the patches.
Yes please.
A public discussion helps to understand what the challenges are.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 0:33 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 0:33 UTC (permalink / raw)
To: linux-security-module
James Morris <jmorris@namei.org> writes:
> On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
>
>> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>> > > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> > > Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> >
>> > It doesn't look like this is coming through Serge so I don't see how
>> > the Signed-off-by tag is legtimate.
>>
>> This is mostly explained by the fact that there have been a *lot* of
>> changes, many of them discussed in private emails.
>
> Please try and keep technical discussions public or at least document them
> when reposting the patches.
Yes please.
A public discussion helps to understand what the challenges are.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <87o9spfa5v.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 0:33 ` Eric W. Biederman
(?)
@ 2017-07-13 1:01 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 1:01 UTC (permalink / raw)
To: Eric W. Biederman
Cc: zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org> writes:
>
> > On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
> >
> >> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> >> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> >> > > Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> >> > > Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> >> > > Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> >> >
> >> > It doesn't look like this is coming through Serge so I don't see how
> >> > the Signed-off-by tag is legtimate.
> >>
> >> This is mostly explained by the fact that there have been a *lot* of
> >> changes, many of them discussed in private emails.
I wasn't clear here. There were a lot of changes between the first
mention of the approach and the posting of v1.
My point was that I did in fact agree to Reviewed-by, and the fact that
I've found a few more things to point out only reflects my missing them
before. I don't think my name is being mis-used.
> > Please try and keep technical discussions public or at least document them
> > when reposting the patches.
>
> Yes please.
>
> A public discussion helps to understand what the challenges are.
Yes, all discussion (that I can find in my mbox) since v1 has been public.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 1:01 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 1:01 UTC (permalink / raw)
To: linux-security-module
Quoting Eric W. Biederman (ebiederm at xmission.com):
> James Morris <jmorris@namei.org> writes:
>
> > On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
> >
> >> Quoting Eric W. Biederman (ebiederm at xmission.com):
> >> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> >> > > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> >> > > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> >> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >> >
> >> > It doesn't look like this is coming through Serge so I don't see how
> >> > the Signed-off-by tag is legtimate.
> >>
> >> This is mostly explained by the fact that there have been a *lot* of
> >> changes, many of them discussed in private emails.
I wasn't clear here. There were a lot of changes between the first
mention of the approach and the posting of v1.
My point was that I did in fact agree to Reviewed-by, and the fact that
I've found a few more things to point out only reflects my missing them
before. I don't think my name is being mis-used.
> > Please try and keep technical discussions public or at least document them
> > when reposting the patches.
>
> Yes please.
>
> A public discussion helps to understand what the challenges are.
Yes, all discussion (that I can find in my mbox) since v1 has been public.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 1:01 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 1:01 UTC (permalink / raw)
To: Eric W. Biederman
Cc: James Morris, Serge E. Hallyn, Stefan Berger, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Quoting Eric W. Biederman (ebiederm@xmission.com):
> James Morris <jmorris@namei.org> writes:
>
> > On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
> >
> >> Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> >> > > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> >> > > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> >> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >> >
> >> > It doesn't look like this is coming through Serge so I don't see how
> >> > the Signed-off-by tag is legtimate.
> >>
> >> This is mostly explained by the fact that there have been a *lot* of
> >> changes, many of them discussed in private emails.
I wasn't clear here. There were a lot of changes between the first
mention of the approach and the posting of v1.
My point was that I did in fact agree to Reviewed-by, and the fact that
I've found a few more things to point out only reflects my missing them
before. I don't think my name is being mis-used.
> > Please try and keep technical discussions public or at least document them
> > when reposting the patches.
>
> Yes please.
>
> A public discussion helps to understand what the challenges are.
Yes, all discussion (that I can find in my mbox) since v1 has been public.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 17:03 ` Serge E. Hallyn
(?)
(?)
@ 2017-07-12 23:13 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-12 23:13 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>> > Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>> > Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>> > Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>>
>> It doesn't look like this is coming through Serge so I don't see how
>> the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
>
>> >From the replies to this it doesn't look like Serge has reviewed this
>> version either.
>>
>> I am disappointed that all of my concerns about technical feasibility
>> remain unaddressed.
>
> Can you re-state those, or give a link to them?
Well I only posted about one substantive comment on the last round
so it should be easy to find that said.
The big question is how does this intereact with filesystems
xattr implementations?
There is the potential that we create many more security xattrs this
way. How does that scale? With more names etc.
What happens if we have one xattr per uid for 1000+ uids?
How does this interact with filesystems optimization of xattr names?
For some filesystems they optmize the xattr names, and don't store the
entire thing.
> I'd really like to get to a point where unprivileged containers can start
> using filecaps - at this point if that means having an extra temporary
> file format based on my earlier patchset while we hash this out, that
> actually seems worthwhile. But it would of course be ideal if we could
> do the name based caps right in the first place.
This whole new version has set my review back to square one
unfortunately.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 23:13 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-12 23:13 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm(a)xmission.com):
>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>> > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>>
>> It doesn't look like this is coming through Serge so I don't see how
>> the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
>
>> >From the replies to this it doesn't look like Serge has reviewed this
>> version either.
>>
>> I am disappointed that all of my concerns about technical feasibility
>> remain unaddressed.
>
> Can you re-state those, or give a link to them?
Well I only posted about one substantive comment on the last round
so it should be easy to find that said.
The big question is how does this intereact with filesystems
xattr implementations?
There is the potential that we create many more security xattrs this
way. How does that scale? With more names etc.
What happens if we have one xattr per uid for 1000+ uids?
How does this interact with filesystems optimization of xattr names?
For some filesystems they optmize the xattr names, and don't store the
entire thing.
> I'd really like to get to a point where unprivileged containers can start
> using filecaps - at this point if that means having an extra temporary
> file format based on my earlier patchset while we hash this out, that
> actually seems worthwhile. But it would of course be ideal if we could
> do the name based caps right in the first place.
This whole new version has set my review back to square one
unfortunately.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 23:13 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-12 23:13 UTC (permalink / raw)
To: linux-security-module
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>> > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>>
>> It doesn't look like this is coming through Serge so I don't see how
>> the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
>
>> >From the replies to this it doesn't look like Serge has reviewed this
>> version either.
>>
>> I am disappointed that all of my concerns about technical feasibility
>> remain unaddressed.
>
> Can you re-state those, or give a link to them?
Well I only posted about one substantive comment on the last round
so it should be easy to find that said.
The big question is how does this intereact with filesystems
xattr implementations?
There is the potential that we create many more security xattrs this
way. How does that scale? With more names etc.
What happens if we have one xattr per uid for 1000+ uids?
How does this interact with filesystems optimization of xattr names?
For some filesystems they optmize the xattr names, and don't store the
entire thing.
> I'd really like to get to a point where unprivileged containers can start
> using filecaps - at this point if that means having an extra temporary
> file format based on my earlier patchset while we hash this out, that
> actually seems worthwhile. But it would of course be ideal if we could
> do the name based caps right in the first place.
This whole new version has set my review back to square one
unfortunately.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 23:13 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-12 23:13 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Stefan Berger, containers, lkp, linux-kernel, zohar, tycho,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>> > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>>
>> It doesn't look like this is coming through Serge so I don't see how
>> the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
>
>> >From the replies to this it doesn't look like Serge has reviewed this
>> version either.
>>
>> I am disappointed that all of my concerns about technical feasibility
>> remain unaddressed.
>
> Can you re-state those, or give a link to them?
Well I only posted about one substantive comment on the last round
so it should be easy to find that said.
The big question is how does this intereact with filesystems
xattr implementations?
There is the potential that we create many more security xattrs this
way. How does that scale? With more names etc.
What happens if we have one xattr per uid for 1000+ uids?
How does this interact with filesystems optimization of xattr names?
For some filesystems they optmize the xattr names, and don't store the
entire thing.
> I'd really like to get to a point where unprivileged containers can start
> using filecaps - at this point if that means having an extra temporary
> file format based on my earlier patchset while we hash this out, that
> actually seems worthwhile. But it would of course be ideal if we could
> do the name based caps right in the first place.
This whole new version has set my review back to square one
unfortunately.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 23:13 ` Eric W. Biederman
@ 2017-07-13 0:43 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 0:43 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge E. Hallyn, Stefan Berger, containers, lkp, linux-kernel,
zohar, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> >> > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> >> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> >> > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >>
> >> It doesn't look like this is coming through Serge so I don't see how
> >> the Signed-off-by tag is legtimate.
> >
> > This is mostly explained by the fact that there have been a *lot* of
> > changes, many of them discussed in private emails.
> >
> >> >From the replies to this it doesn't look like Serge has reviewed this
> >> version either.
> >>
> >> I am disappointed that all of my concerns about technical feasibility
> >> remain unaddressed.
> >
> > Can you re-state those, or give a link to them?
>
> Well I only posted about one substantive comment on the last round
> so it should be easy to find that said.
Ok so you are likely referring to http://lkml.org/lkml/2017/6/23/551 ,
thanks. I had actually read that differently when you sent it, and
thought it was more to do with the suggestion of putting the nsid
tags in the middle of the xattr name versus putting it on the end.
As far as that is concerned, note that no other tags besides uid=
are currently supported, and only security.capability is being
namespaced.
> The big question is how does this intereact with filesystems
> xattr implementations?
>
> There is the potential that we create many more security xattrs this
> way. How does that scale? With more names etc.
> What happens if we have one xattr per uid for 1000+ uids?
Well, that's not the intent here. The goal is *not* to make one fs image
that satisfies 200k possible uid mappings. The goal is to reconcile the
support for an unprivileged user to set uid agnostic (within the
container) file capabilities with the uid namespace's design goals -
namely root in a container is privileged over the container but
completely unprivileged wrt the host.
This is in part why in my previous version I only allowed a single
namespaced fscap. But I don't think that we have to enforce a
single fscap - I think it's fair to tell users "go ahead and shoot
yourself in the foot" performance-wise, if they insist on doing
this.
The goal of now putting the root kuid in the name is not to support
multiple containers, but to have common code supporting
security.capability and security.ima, and maybe a few more.
> How does this interact with filesystems optimization of xattr names?
> For some filesystems they optmize the xattr names, and don't store the
> entire thing.
This I have no idea on. Stefan, have you looked at this?
> > I'd really like to get to a point where unprivileged containers can start
> > using filecaps - at this point if that means having an extra temporary
> > file format based on my earlier patchset while we hash this out, that
> > actually seems worthwhile. But it would of course be ideal if we could
> > do the name based caps right in the first place.
>
> This whole new version has set my review back to square one
> unfortunately.
Well it is a whole new approach and whole new patch, so of course that's
to be expected :(
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 0:43 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 0:43 UTC (permalink / raw)
To: linux-security-module
Quoting Eric W. Biederman (ebiederm at xmission.com):
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
> > Quoting Eric W. Biederman (ebiederm at xmission.com):
> >> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> >> > Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> >> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> >> > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >>
> >> It doesn't look like this is coming through Serge so I don't see how
> >> the Signed-off-by tag is legtimate.
> >
> > This is mostly explained by the fact that there have been a *lot* of
> > changes, many of them discussed in private emails.
> >
> >> >From the replies to this it doesn't look like Serge has reviewed this
> >> version either.
> >>
> >> I am disappointed that all of my concerns about technical feasibility
> >> remain unaddressed.
> >
> > Can you re-state those, or give a link to them?
>
> Well I only posted about one substantive comment on the last round
> so it should be easy to find that said.
Ok so you are likely referring to http://lkml.org/lkml/2017/6/23/551 ,
thanks. I had actually read that differently when you sent it, and
thought it was more to do with the suggestion of putting the nsid
tags in the middle of the xattr name versus putting it on the end.
As far as that is concerned, note that no other tags besides uid=
are currently supported, and only security.capability is being
namespaced.
> The big question is how does this intereact with filesystems
> xattr implementations?
>
> There is the potential that we create many more security xattrs this
> way. How does that scale? With more names etc.
> What happens if we have one xattr per uid for 1000+ uids?
Well, that's not the intent here. The goal is *not* to make one fs image
that satisfies 200k possible uid mappings. The goal is to reconcile the
support for an unprivileged user to set uid agnostic (within the
container) file capabilities with the uid namespace's design goals -
namely root in a container is privileged over the container but
completely unprivileged wrt the host.
This is in part why in my previous version I only allowed a single
namespaced fscap. But I don't think that we have to enforce a
single fscap - I think it's fair to tell users "go ahead and shoot
yourself in the foot" performance-wise, if they insist on doing
this.
The goal of now putting the root kuid in the name is not to support
multiple containers, but to have common code supporting
security.capability and security.ima, and maybe a few more.
> How does this interact with filesystems optimization of xattr names?
> For some filesystems they optmize the xattr names, and don't store the
> entire thing.
This I have no idea on. Stefan, have you looked at this?
> > I'd really like to get to a point where unprivileged containers can start
> > using filecaps - at this point if that means having an extra temporary
> > file format based on my earlier patchset while we hash this out, that
> > actually seems worthwhile. But it would of course be ideal if we could
> > do the name based caps right in the first place.
>
> This whole new version has set my review back to square one
> unfortunately.
Well it is a whole new approach and whole new patch, so of course that's
to be expected :(
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <877ezdgsey.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <877ezdgsey.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2017-07-13 0:43 ` Serge E. Hallyn
2017-07-13 0:44 ` Stefan Berger
1 sibling, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 0:43 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
>
> > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> >> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> >> > Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> >> > Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> >> > Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> >>
> >> It doesn't look like this is coming through Serge so I don't see how
> >> the Signed-off-by tag is legtimate.
> >
> > This is mostly explained by the fact that there have been a *lot* of
> > changes, many of them discussed in private emails.
> >
> >> >From the replies to this it doesn't look like Serge has reviewed this
> >> version either.
> >>
> >> I am disappointed that all of my concerns about technical feasibility
> >> remain unaddressed.
> >
> > Can you re-state those, or give a link to them?
>
> Well I only posted about one substantive comment on the last round
> so it should be easy to find that said.
Ok so you are likely referring to http://lkml.org/lkml/2017/6/23/551 ,
thanks. I had actually read that differently when you sent it, and
thought it was more to do with the suggestion of putting the nsid
tags in the middle of the xattr name versus putting it on the end.
As far as that is concerned, note that no other tags besides uid=
are currently supported, and only security.capability is being
namespaced.
> The big question is how does this intereact with filesystems
> xattr implementations?
>
> There is the potential that we create many more security xattrs this
> way. How does that scale? With more names etc.
> What happens if we have one xattr per uid for 1000+ uids?
Well, that's not the intent here. The goal is *not* to make one fs image
that satisfies 200k possible uid mappings. The goal is to reconcile the
support for an unprivileged user to set uid agnostic (within the
container) file capabilities with the uid namespace's design goals -
namely root in a container is privileged over the container but
completely unprivileged wrt the host.
This is in part why in my previous version I only allowed a single
namespaced fscap. But I don't think that we have to enforce a
single fscap - I think it's fair to tell users "go ahead and shoot
yourself in the foot" performance-wise, if they insist on doing
this.
The goal of now putting the root kuid in the name is not to support
multiple containers, but to have common code supporting
security.capability and security.ima, and maybe a few more.
> How does this interact with filesystems optimization of xattr names?
> For some filesystems they optmize the xattr names, and don't store the
> entire thing.
This I have no idea on. Stefan, have you looked at this?
> > I'd really like to get to a point where unprivileged containers can start
> > using filecaps - at this point if that means having an extra temporary
> > file format based on my earlier patchset while we hash this out, that
> > actually seems worthwhile. But it would of course be ideal if we could
> > do the name based caps right in the first place.
>
> This whole new version has set my review back to square one
> unfortunately.
Well it is a whole new approach and whole new patch, so of course that's
to be expected :(
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 23:13 ` Eric W. Biederman
(?)
(?)
@ 2017-07-13 0:44 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 0:44 UTC (permalink / raw)
To: Eric W. Biederman, Serge E. Hallyn
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/12/2017 07:13 PM, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
>
>> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>>>> Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>>> Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>>>> Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>>> It doesn't look like this is coming through Serge so I don't see how
>>> the Signed-off-by tag is legtimate.
>> This is mostly explained by the fact that there have been a *lot* of
>> changes, many of them discussed in private emails.
>>
>>> >From the replies to this it doesn't look like Serge has reviewed this
>>> version either.
>>>
>>> I am disappointed that all of my concerns about technical feasibility
>>> remain unaddressed.
>> Can you re-state those, or give a link to them?
> Well I only posted about one substantive comment on the last round
> so it should be easy to find that said.
>
> The big question is how does this intereact with filesystems
> xattr implementations?
>
> There is the potential that we create many more security xattrs this
> way. How does that scale? With more names etc.
It doesn't scale. Shared filesystems are a problem if many containers
use them.
'man listxattr' also mentions this here as a BUG:
" As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of
the extended attribute name list returned by listxattr(7). If the
total size of attribute names attached to a file exceeds this limit,
it is no longer possible to retrieve the list of attribute names."
A simple test on ext4:
#> touch foo
#> for ((i = 0; i < 200; i++)); do setfattr -n user.foo${i} -v hello
foo; done
user.foo126 was the last one created...
Depending on the size of the data the xattrs are writing, the limit is
reached sooner. Writing 'hellohello' only goes up to 'user.foo112'.
Maybe one could try to encode the data more efficiently or as Serge did
write the uid on the xattr value side, but either way, it won't scale
due to that VFS limit.
Stefan
> What happens if we have one xattr per uid for 1000+ uids?
>
> How does this interact with filesystems optimization of xattr names?
> For some filesystems they optmize the xattr names, and don't store the
> entire thing.
>
>> I'd really like to get to a point where unprivileged containers can start
>> using filecaps - at this point if that means having an extra temporary
>> file format based on my earlier patchset while we hash this out, that
>> actually seems worthwhile. But it would of course be ideal if we could
>> do the name based caps right in the first place.
> This whole new version has set my review back to square one
> unfortunately.
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 0:44 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 0:44 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]
On 07/12/2017 07:13 PM, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
>> Quoting Eric W. Biederman (ebiederm(a)xmission.com):
>>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>>>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>>>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>>> It doesn't look like this is coming through Serge so I don't see how
>>> the Signed-off-by tag is legtimate.
>> This is mostly explained by the fact that there have been a *lot* of
>> changes, many of them discussed in private emails.
>>
>>> >From the replies to this it doesn't look like Serge has reviewed this
>>> version either.
>>>
>>> I am disappointed that all of my concerns about technical feasibility
>>> remain unaddressed.
>> Can you re-state those, or give a link to them?
> Well I only posted about one substantive comment on the last round
> so it should be easy to find that said.
>
> The big question is how does this intereact with filesystems
> xattr implementations?
>
> There is the potential that we create many more security xattrs this
> way. How does that scale? With more names etc.
It doesn't scale. Shared filesystems are a problem if many containers
use them.
'man listxattr' also mentions this here as a BUG:
" As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of
the extended attribute name list returned by listxattr(7). If the
total size of attribute names attached to a file exceeds this limit,
it is no longer possible to retrieve the list of attribute names."
A simple test on ext4:
#> touch foo
#> for ((i = 0; i < 200; i++)); do setfattr -n user.foo${i} -v hello
foo; done
user.foo126 was the last one created...
Depending on the size of the data the xattrs are writing, the limit is
reached sooner. Writing 'hellohello' only goes up to 'user.foo112'.
Maybe one could try to encode the data more efficiently or as Serge did
write the uid on the xattr value side, but either way, it won't scale
due to that VFS limit.
Stefan
> What happens if we have one xattr per uid for 1000+ uids?
>
> How does this interact with filesystems optimization of xattr names?
> For some filesystems they optmize the xattr names, and don't store the
> entire thing.
>
>> I'd really like to get to a point where unprivileged containers can start
>> using filecaps - at this point if that means having an extra temporary
>> file format based on my earlier patchset while we hash this out, that
>> actually seems worthwhile. But it would of course be ideal if we could
>> do the name based caps right in the first place.
> This whole new version has set my review back to square one
> unfortunately.
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 0:44 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 0:44 UTC (permalink / raw)
To: linux-security-module
On 07/12/2017 07:13 PM, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
>> Quoting Eric W. Biederman (ebiederm at xmission.com):
>>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>>>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>>>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>>> It doesn't look like this is coming through Serge so I don't see how
>>> the Signed-off-by tag is legtimate.
>> This is mostly explained by the fact that there have been a *lot* of
>> changes, many of them discussed in private emails.
>>
>>> >From the replies to this it doesn't look like Serge has reviewed this
>>> version either.
>>>
>>> I am disappointed that all of my concerns about technical feasibility
>>> remain unaddressed.
>> Can you re-state those, or give a link to them?
> Well I only posted about one substantive comment on the last round
> so it should be easy to find that said.
>
> The big question is how does this intereact with filesystems
> xattr implementations?
>
> There is the potential that we create many more security xattrs this
> way. How does that scale? With more names etc.
It doesn't scale. Shared filesystems are a problem if many containers
use them.
'man listxattr' also mentions this here as a BUG:
" As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of
the extended attribute name list returned by listxattr(7). If the
total size of attribute names attached to a file exceeds this limit,
it is no longer possible to retrieve the list of attribute names."
A simple test on ext4:
#> touch foo
#> for ((i = 0; i < 200; i++)); do setfattr -n user.foo${i} -v hello
foo; done
user.foo126 was the last one created...
Depending on the size of the data the xattrs are writing, the limit is
reached sooner. Writing 'hellohello' only goes up to 'user.foo112'.
Maybe one could try to encode the data more efficiently or as Serge did
write the uid on the xattr value side, but either way, it won't scale
due to that VFS limit.
Stefan
> What happens if we have one xattr per uid for 1000+ uids?
>
> How does this interact with filesystems optimization of xattr names?
> For some filesystems they optmize the xattr names, and don't store the
> entire thing.
>
>> I'd really like to get to a point where unprivileged containers can start
>> using filecaps - at this point if that means having an extra temporary
>> file format based on my earlier patchset while we hash this out, that
>> actually seems worthwhile. But it would of course be ideal if we could
>> do the name based caps right in the first place.
> This whole new version has set my review back to square one
> unfortunately.
>
> Eric
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 0:44 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 0:44 UTC (permalink / raw)
To: Eric W. Biederman, Serge E. Hallyn
Cc: containers, lkp, linux-kernel, zohar, tycho, James.Bottomley,
vgoyal, christian.brauner, amir73il, linux-security-module,
casey
On 07/12/2017 07:13 PM, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
>> Quoting Eric W. Biederman (ebiederm@xmission.com):
>>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>>>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>>>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>>> It doesn't look like this is coming through Serge so I don't see how
>>> the Signed-off-by tag is legtimate.
>> This is mostly explained by the fact that there have been a *lot* of
>> changes, many of them discussed in private emails.
>>
>>> >From the replies to this it doesn't look like Serge has reviewed this
>>> version either.
>>>
>>> I am disappointed that all of my concerns about technical feasibility
>>> remain unaddressed.
>> Can you re-state those, or give a link to them?
> Well I only posted about one substantive comment on the last round
> so it should be easy to find that said.
>
> The big question is how does this intereact with filesystems
> xattr implementations?
>
> There is the potential that we create many more security xattrs this
> way. How does that scale? With more names etc.
It doesn't scale. Shared filesystems are a problem if many containers
use them.
'man listxattr' also mentions this here as a BUG:
" As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of
the extended attribute name list returned by listxattr(7). If the
total size of attribute names attached to a file exceeds this limit,
it is no longer possible to retrieve the list of attribute names."
A simple test on ext4:
#> touch foo
#> for ((i = 0; i < 200; i++)); do setfattr -n user.foo${i} -v hello
foo; done
user.foo126 was the last one created...
Depending on the size of the data the xattrs are writing, the limit is
reached sooner. Writing 'hellohello' only goes up to 'user.foo112'.
Maybe one could try to encode the data more efficiently or as Serge did
write the uid on the xattr value side, but either way, it won't scale
due to that VFS limit.
Stefan
> What happens if we have one xattr per uid for 1000+ uids?
>
> How does this interact with filesystems optimization of xattr names?
> For some filesystems they optmize the xattr names, and don't store the
> entire thing.
>
>> I'd really like to get to a point where unprivileged containers can start
>> using filecaps - at this point if that means having an extra temporary
>> file format based on my earlier patchset while we hash this out, that
>> actually seems worthwhile. But it would of course be ideal if we could
>> do the name based caps right in the first place.
> This whole new version has set my review back to square one
> unfortunately.
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <74664cc8-bc3e-75d6-5892-f8934404349f-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 0:44 ` Stefan Berger
(?)
(?)
@ 2017-07-13 1:15 ` Theodore Ts'o
-1 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 1:15 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
I'm really confused what problem that is trying to be solved, here,
but it **feels** really, really wrong.
Why do we need to store all of this state on a per-file basis, instead
of some kind of per-file system or per-container data structure?
And how many of these security.foo@uid=bar xattrs do you expect there
to be? How many "foo", and how many "bar"?
Maybe I missed the full write up, in which case please send me a link
to the full writeup --- ideally in the form of a design doc that
explains the problem statement, gives some examples of how it's going
to be used, what were the other alternatives that were considered, and
why they were rejected, etc.
Thanks,
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 1:15 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 1:15 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
I'm really confused what problem that is trying to be solved, here,
but it **feels** really, really wrong.
Why do we need to store all of this state on a per-file basis, instead
of some kind of per-file system or per-container data structure?
And how many of these security.foo(a)uid=bar xattrs do you expect there
to be? How many "foo", and how many "bar"?
Maybe I missed the full write up, in which case please send me a link
to the full writeup --- ideally in the form of a design doc that
explains the problem statement, gives some examples of how it's going
to be used, what were the other alternatives that were considered, and
why they were rejected, etc.
Thanks,
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 1:15 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 1:15 UTC (permalink / raw)
To: linux-security-module
I'm really confused what problem that is trying to be solved, here,
but it **feels** really, really wrong.
Why do we need to store all of this state on a per-file basis, instead
of some kind of per-file system or per-container data structure?
And how many of these security.foo at uid=bar xattrs do you expect there
to be? How many "foo", and how many "bar"?
Maybe I missed the full write up, in which case please send me a link
to the full writeup --- ideally in the form of a design doc that
explains the problem statement, gives some examples of how it's going
to be used, what were the other alternatives that were considered, and
why they were rejected, etc.
Thanks,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 1:15 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 1:15 UTC (permalink / raw)
To: Stefan Berger
Cc: Eric W. Biederman, Serge E. Hallyn, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
I'm really confused what problem that is trying to be solved, here,
but it **feels** really, really wrong.
Why do we need to store all of this state on a per-file basis, instead
of some kind of per-file system or per-container data structure?
And how many of these security.foo@uid=bar xattrs do you expect there
to be? How many "foo", and how many "bar"?
Maybe I missed the full write up, in which case please send me a link
to the full writeup --- ideally in the form of a design doc that
explains the problem statement, gives some examples of how it's going
to be used, what were the other alternatives that were considered, and
why they were rejected, etc.
Thanks,
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170713011554.xwmrgkzfwnibvgcu-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 1:15 ` Theodore Ts'o
(?)
@ 2017-07-13 2:34 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 2:34 UTC (permalink / raw)
To: Theodore Ts'o, Stefan Berger, Eric W. Biederman,
Serge E. Hallyn,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lkp-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
tycho-FCduhRhOUaTQT0dZR+AlfA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA,
christian.brauner-cl+VPiYnx/1AfugRpC6u6w,
amir73il-Re5JQEeQqe8AvxtiuMwx3w,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A
Quoting Theodore Ts'o (tytso-3s7WtUTddSA@public.gmane.org):
> I'm really confused what problem that is trying to be solved, here,
> but it **feels** really, really wrong.
Hi,
The intro to my original patch might help (or maybe not), as it
has a different motivating text:
http://lkml.org/lkml/2016/11/19/158
We want file capabilities to be supported in unprivileged containers,
so that a piece of software can count on them being available rather
than having to supporting multiple ways of getting+dropping privilege
(for instance, being installed as uid 1000 with cap_net_raw=pe, versus
being installed setuid-root and being expected to do PR_SET_KEEPCAPS
and setuid).
If subuids 10000-20000 are delegated to uid 1001 on the host, and uid
1001 sets up a container with subuid 100000 mapped to container uid 0,
then the container root should be able to write file capabilities
which affect (that is, delegate container root's privilege to) all ids
over which it has privilege (all uids mapped into the container), but
should not have privilege over any uids not mapped into the container.
With regular file capabilities, this is impossible, since any filecap
he writes can then be exercised on the host by uid 1000.
The point of this set (and the ones before it) is to make it so that
the filecap written by the container root is tagged on disk as belonging
to subuid 100000.
> Why do we need to store all of this state on a per-file basis, instead
> of some kind of per-file system or per-container data structure?
This needs to be writeable by an unprivileged user, with no help from
the admin. AFAICS that rules out per-fs data structure.
Note we are not assuming a filesystem per container. The typical case
is (for instance) ~/.local/share/lxc/c1/rootfs being the root of
container c1's filesystem. Mounting a filesystem from inside a user
namespace is still mostly science fiction today.
> And how many of these security.foo@uid=bar xattrs do you expect there
> to be? How many "foo", and how many "bar"?
For now I'm expecting two foos - security and ima. The '@uid=bar' is
generic enough that it *can* be re-used for a different kind of
property if we decide to later, but I have no intention of adding
anything.
Casey has mentioned 'smack=', but i think only to keep the option open.
I don't believe he has concrete plans.
> Maybe I missed the full write up, in which case please send me a link
> to the full writeup --- ideally in the form of a design doc that
> explains the problem statement, gives some examples of how it's going
> to be used, what were the other alternatives that were considered, and
> why they were rejected, etc.
As I'd mentioned in an even older patch, http://lkml.org/lkml/2016/5/18/622 ,
I had considered using a completely separate xattr name, but that would
have required invasive userspace changes.
There's no design doc as such, mainly a progressive series of patches to
lkml. I am very seriously considering writing a paper to detail both
this design and the user ns design in general, as it has become clear
(in unrelated conversations) there is still a lot of confusiong out
there regarding uid namespaces and targeted capabilities. But it's not
written yet.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 2:34 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 2:34 UTC (permalink / raw)
To: linux-security-module
Quoting Theodore Ts'o (tytso at mit.edu):
> I'm really confused what problem that is trying to be solved, here,
> but it **feels** really, really wrong.
Hi,
The intro to my original patch might help (or maybe not), as it
has a different motivating text:
http://lkml.org/lkml/2016/11/19/158
We want file capabilities to be supported in unprivileged containers,
so that a piece of software can count on them being available rather
than having to supporting multiple ways of getting+dropping privilege
(for instance, being installed as uid 1000 with cap_net_raw=pe, versus
being installed setuid-root and being expected to do PR_SET_KEEPCAPS
and setuid).
If subuids 10000-20000 are delegated to uid 1001 on the host, and uid
1001 sets up a container with subuid 100000 mapped to container uid 0,
then the container root should be able to write file capabilities
which affect (that is, delegate container root's privilege to) all ids
over which it has privilege (all uids mapped into the container), but
should not have privilege over any uids not mapped into the container.
With regular file capabilities, this is impossible, since any filecap
he writes can then be exercised on the host by uid 1000.
The point of this set (and the ones before it) is to make it so that
the filecap written by the container root is tagged on disk as belonging
to subuid 100000.
> Why do we need to store all of this state on a per-file basis, instead
> of some kind of per-file system or per-container data structure?
This needs to be writeable by an unprivileged user, with no help from
the admin. AFAICS that rules out per-fs data structure.
Note we are not assuming a filesystem per container. The typical case
is (for instance) ~/.local/share/lxc/c1/rootfs being the root of
container c1's filesystem. Mounting a filesystem from inside a user
namespace is still mostly science fiction today.
> And how many of these security.foo at uid=bar xattrs do you expect there
> to be? How many "foo", and how many "bar"?
For now I'm expecting two foos - security and ima. The '@uid=bar' is
generic enough that it *can* be re-used for a different kind of
property if we decide to later, but I have no intention of adding
anything.
Casey has mentioned 'smack=', but i think only to keep the option open.
I don't believe he has concrete plans.
> Maybe I missed the full write up, in which case please send me a link
> to the full writeup --- ideally in the form of a design doc that
> explains the problem statement, gives some examples of how it's going
> to be used, what were the other alternatives that were considered, and
> why they were rejected, etc.
As I'd mentioned in an even older patch, http://lkml.org/lkml/2016/5/18/622 ,
I had considered using a completely separate xattr name, but that would
have required invasive userspace changes.
There's no design doc as such, mainly a progressive series of patches to
lkml. I am very seriously considering writing a paper to detail both
this design and the user ns design in general, as it has become clear
(in unrelated conversations) there is still a lot of confusiong out
there regarding uid namespaces and targeted capabilities. But it's not
written yet.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 2:34 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 2:34 UTC (permalink / raw)
To: Theodore Ts'o, Stefan Berger, Eric W. Biederman,
Serge E. Hallyn, containers, lkp, linux-kernel, zohar, tycho,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
Quoting Theodore Ts'o (tytso@mit.edu):
> I'm really confused what problem that is trying to be solved, here,
> but it **feels** really, really wrong.
Hi,
The intro to my original patch might help (or maybe not), as it
has a different motivating text:
http://lkml.org/lkml/2016/11/19/158
We want file capabilities to be supported in unprivileged containers,
so that a piece of software can count on them being available rather
than having to supporting multiple ways of getting+dropping privilege
(for instance, being installed as uid 1000 with cap_net_raw=pe, versus
being installed setuid-root and being expected to do PR_SET_KEEPCAPS
and setuid).
If subuids 10000-20000 are delegated to uid 1001 on the host, and uid
1001 sets up a container with subuid 100000 mapped to container uid 0,
then the container root should be able to write file capabilities
which affect (that is, delegate container root's privilege to) all ids
over which it has privilege (all uids mapped into the container), but
should not have privilege over any uids not mapped into the container.
With regular file capabilities, this is impossible, since any filecap
he writes can then be exercised on the host by uid 1000.
The point of this set (and the ones before it) is to make it so that
the filecap written by the container root is tagged on disk as belonging
to subuid 100000.
> Why do we need to store all of this state on a per-file basis, instead
> of some kind of per-file system or per-container data structure?
This needs to be writeable by an unprivileged user, with no help from
the admin. AFAICS that rules out per-fs data structure.
Note we are not assuming a filesystem per container. The typical case
is (for instance) ~/.local/share/lxc/c1/rootfs being the root of
container c1's filesystem. Mounting a filesystem from inside a user
namespace is still mostly science fiction today.
> And how many of these security.foo@uid=bar xattrs do you expect there
> to be? How many "foo", and how many "bar"?
For now I'm expecting two foos - security and ima. The '@uid=bar' is
generic enough that it *can* be re-used for a different kind of
property if we decide to later, but I have no intention of adding
anything.
Casey has mentioned 'smack=', but i think only to keep the option open.
I don't believe he has concrete plans.
> Maybe I missed the full write up, in which case please send me a link
> to the full writeup --- ideally in the form of a design doc that
> explains the problem statement, gives some examples of how it's going
> to be used, what were the other alternatives that were considered, and
> why they were rejected, etc.
As I'd mentioned in an even older patch, http://lkml.org/lkml/2016/5/18/622 ,
I had considered using a completely separate xattr name, but that would
have required invasive userspace changes.
There's no design doc as such, mainly a progressive series of patches to
lkml. I am very seriously considering writing a paper to detail both
this design and the user ns design in general, as it has become clear
(in unrelated conversations) there is still a lot of confusiong out
there regarding uid namespaces and targeted capabilities. But it's not
written yet.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170713011554.xwmrgkzfwnibvgcu-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-13 2:34 ` Serge E. Hallyn
@ 2017-07-13 12:11 ` Eric W. Biederman
1 sibling, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 12:11 UTC (permalink / raw)
To: Theodore Ts'o
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> writes:
> I'm really confused what problem that is trying to be solved, here,
> but it **feels** really, really wrong.
>
> Why do we need to store all of this state on a per-file basis, instead
> of some kind of per-file system or per-container data structure?
>
> And how many of these security.foo@uid=bar xattrs do you expect there
> to be? How many "foo", and how many "bar"?
>
> Maybe I missed the full write up, in which case please send me a link
> to the full writeup --- ideally in the form of a design doc that
> explains the problem statement, gives some examples of how it's going
> to be used, what were the other alternatives that were considered, and
> why they were rejected, etc.
The concise summary:
Today we have the xattr security.capable that holds a set of
capabilities that an application gains when executed. AKA setuid root exec
without actually being setuid root.
User namespaces have the concept of capabilities that are not global but
are limited to their user namespace. We do not currently have
filesystem support for this concept.
We currently have two proposals on the table. One is to bump the
revision number of security.capable and add more information in that xattr.
The other is to use a sligthly different capability name.
We are currently evaluating between the two proposals.
Given that it appears the IMA xattrs will want similar treatment coming
up with a good pattern to follow is part of the analysis here.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 1:15 ` Theodore Ts'o
(?)
@ 2017-07-13 12:11 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 12:11 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Stefan Berger, Serge E. Hallyn, containers, lkp, linux-kernel,
zohar, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
Theodore Ts'o <tytso@mit.edu> writes:
> I'm really confused what problem that is trying to be solved, here,
> but it **feels** really, really wrong.
>
> Why do we need to store all of this state on a per-file basis, instead
> of some kind of per-file system or per-container data structure?
>
> And how many of these security.foo@uid=bar xattrs do you expect there
> to be? How many "foo", and how many "bar"?
>
> Maybe I missed the full write up, in which case please send me a link
> to the full writeup --- ideally in the form of a design doc that
> explains the problem statement, gives some examples of how it's going
> to be used, what were the other alternatives that were considered, and
> why they were rejected, etc.
The concise summary:
Today we have the xattr security.capable that holds a set of
capabilities that an application gains when executed. AKA setuid root exec
without actually being setuid root.
User namespaces have the concept of capabilities that are not global but
are limited to their user namespace. We do not currently have
filesystem support for this concept.
We currently have two proposals on the table. One is to bump the
revision number of security.capable and add more information in that xattr.
The other is to use a sligthly different capability name.
We are currently evaluating between the two proposals.
Given that it appears the IMA xattrs will want similar treatment coming
up with a good pattern to follow is part of the analysis here.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 12:11 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 12:11 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]
Theodore Ts'o <tytso@mit.edu> writes:
> I'm really confused what problem that is trying to be solved, here,
> but it **feels** really, really wrong.
>
> Why do we need to store all of this state on a per-file basis, instead
> of some kind of per-file system or per-container data structure?
>
> And how many of these security.foo(a)uid=bar xattrs do you expect there
> to be? How many "foo", and how many "bar"?
>
> Maybe I missed the full write up, in which case please send me a link
> to the full writeup --- ideally in the form of a design doc that
> explains the problem statement, gives some examples of how it's going
> to be used, what were the other alternatives that were considered, and
> why they were rejected, etc.
The concise summary:
Today we have the xattr security.capable that holds a set of
capabilities that an application gains when executed. AKA setuid root exec
without actually being setuid root.
User namespaces have the concept of capabilities that are not global but
are limited to their user namespace. We do not currently have
filesystem support for this concept.
We currently have two proposals on the table. One is to bump the
revision number of security.capable and add more information in that xattr.
The other is to use a sligthly different capability name.
We are currently evaluating between the two proposals.
Given that it appears the IMA xattrs will want similar treatment coming
up with a good pattern to follow is part of the analysis here.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 12:11 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 12:11 UTC (permalink / raw)
To: linux-security-module
Theodore Ts'o <tytso@mit.edu> writes:
> I'm really confused what problem that is trying to be solved, here,
> but it **feels** really, really wrong.
>
> Why do we need to store all of this state on a per-file basis, instead
> of some kind of per-file system or per-container data structure?
>
> And how many of these security.foo at uid=bar xattrs do you expect there
> to be? How many "foo", and how many "bar"?
>
> Maybe I missed the full write up, in which case please send me a link
> to the full writeup --- ideally in the form of a design doc that
> explains the problem statement, gives some examples of how it's going
> to be used, what were the other alternatives that were considered, and
> why they were rejected, etc.
The concise summary:
Today we have the xattr security.capable that holds a set of
capabilities that an application gains when executed. AKA setuid root exec
without actually being setuid root.
User namespaces have the concept of capabilities that are not global but
are limited to their user namespace. We do not currently have
filesystem support for this concept.
We currently have two proposals on the table. One is to bump the
revision number of security.capable and add more information in that xattr.
The other is to use a sligthly different capability name.
We are currently evaluating between the two proposals.
Given that it appears the IMA xattrs will want similar treatment coming
up with a good pattern to follow is part of the analysis here.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <87y3rscz9j.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <87y3rscz9j.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2017-07-13 16:40 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 16:40 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> The concise summary:
>
> Today we have the xattr security.capable that holds a set of
> capabilities that an application gains when executed. AKA setuid root exec
> without actually being setuid root.
>
> User namespaces have the concept of capabilities that are not global but
> are limited to their user namespace. We do not currently have
> filesystem support for this concept.
So correct me if I am wrong; in general, there will only be one
variant of the form:
security.foo@uid=15000
It's not like there will be:
security.foo@uid=1000
security.foo@uid=2000
Except.... if you have an Distribution root directory which is shared
by many containers, you would need to put the xattrs in the overlay
inodes. Worse, each time you launch a new container, with a new
subuid allocation, you will have to iterate over all files with
capabilities and do a copy-up operations on the xattrs in overlayfs.
So that's actually a bit of a disaster.
So for distribution overlays, you will need to do things a different
way, which is to map the distro subdirectory so you know that the
capability with the global uid 0 should be used for the container
"root" uid, right?
So this hack of using security.foo@uid=1000 is *only* useful when the
subcontainer root wants to create the privileged executable. You
still have to do things the other way.
So can we make perhaps the assertion that *either*:
security.foo
exists, *or*
security.foo@uid=BAR
exists, but never both? And there BAR is exclusive to only one
instances?
Otherwise, I suspect that the architecture is going to turn around and
bite us in the *ss eventually, because someone will want to do
something crazy and the solution will not be scalable.
-Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 12:11 ` Eric W. Biederman
(?)
@ 2017-07-13 16:40 ` Theodore Ts'o
-1 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 16:40 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stefan Berger, Serge E. Hallyn, containers, lkp, linux-kernel,
zohar, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> The concise summary:
>
> Today we have the xattr security.capable that holds a set of
> capabilities that an application gains when executed. AKA setuid root exec
> without actually being setuid root.
>
> User namespaces have the concept of capabilities that are not global but
> are limited to their user namespace. We do not currently have
> filesystem support for this concept.
So correct me if I am wrong; in general, there will only be one
variant of the form:
security.foo@uid=15000
It's not like there will be:
security.foo@uid=1000
security.foo@uid=2000
Except.... if you have an Distribution root directory which is shared
by many containers, you would need to put the xattrs in the overlay
inodes. Worse, each time you launch a new container, with a new
subuid allocation, you will have to iterate over all files with
capabilities and do a copy-up operations on the xattrs in overlayfs.
So that's actually a bit of a disaster.
So for distribution overlays, you will need to do things a different
way, which is to map the distro subdirectory so you know that the
capability with the global uid 0 should be used for the container
"root" uid, right?
So this hack of using security.foo@uid=1000 is *only* useful when the
subcontainer root wants to create the privileged executable. You
still have to do things the other way.
So can we make perhaps the assertion that *either*:
security.foo
exists, *or*
security.foo@uid=BAR
exists, but never both? And there BAR is exclusive to only one
instances?
Otherwise, I suspect that the architecture is going to turn around and
bite us in the *ss eventually, because someone will want to do
something crazy and the solution will not be scalable.
-Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 16:40 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 16:40 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]
On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> The concise summary:
>
> Today we have the xattr security.capable that holds a set of
> capabilities that an application gains when executed. AKA setuid root exec
> without actually being setuid root.
>
> User namespaces have the concept of capabilities that are not global but
> are limited to their user namespace. We do not currently have
> filesystem support for this concept.
So correct me if I am wrong; in general, there will only be one
variant of the form:
security.foo(a)uid=15000
It's not like there will be:
security.foo(a)uid=1000
security.foo(a)uid=2000
Except.... if you have an Distribution root directory which is shared
by many containers, you would need to put the xattrs in the overlay
inodes. Worse, each time you launch a new container, with a new
subuid allocation, you will have to iterate over all files with
capabilities and do a copy-up operations on the xattrs in overlayfs.
So that's actually a bit of a disaster.
So for distribution overlays, you will need to do things a different
way, which is to map the distro subdirectory so you know that the
capability with the global uid 0 should be used for the container
"root" uid, right?
So this hack of using security.foo(a)uid=1000 is *only* useful when the
subcontainer root wants to create the privileged executable. You
still have to do things the other way.
So can we make perhaps the assertion that *either*:
security.foo
exists, *or*
security.foo(a)uid=BAR
exists, but never both? And there BAR is exclusive to only one
instances?
Otherwise, I suspect that the architecture is going to turn around and
bite us in the *ss eventually, because someone will want to do
something crazy and the solution will not be scalable.
-Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 16:40 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 16:40 UTC (permalink / raw)
To: linux-security-module
On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> The concise summary:
>
> Today we have the xattr security.capable that holds a set of
> capabilities that an application gains when executed. AKA setuid root exec
> without actually being setuid root.
>
> User namespaces have the concept of capabilities that are not global but
> are limited to their user namespace. We do not currently have
> filesystem support for this concept.
So correct me if I am wrong; in general, there will only be one
variant of the form:
security.foo at uid=15000
It's not like there will be:
security.foo at uid=1000
security.foo at uid=2000
Except.... if you have an Distribution root directory which is shared
by many containers, you would need to put the xattrs in the overlay
inodes. Worse, each time you launch a new container, with a new
subuid allocation, you will have to iterate over all files with
capabilities and do a copy-up operations on the xattrs in overlayfs.
So that's actually a bit of a disaster.
So for distribution overlays, you will need to do things a different
way, which is to map the distro subdirectory so you know that the
capability with the global uid 0 should be used for the container
"root" uid, right?
So this hack of using security.foo at uid=1000 is *only* useful when the
subcontainer root wants to create the privileged executable. You
still have to do things the other way.
So can we make perhaps the assertion that *either*:
security.foo
exists, *or*
security.foo at uid=BAR
exists, but never both? And there BAR is exclusive to only one
instances?
Otherwise, I suspect that the architecture is going to turn around and
bite us in the *ss eventually, because someone will want to do
something crazy and the solution will not be scalable.
-Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 16:40 ` Theodore Ts'o
(?)
@ 2017-07-13 17:05 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 17:05 UTC (permalink / raw)
To: Theodore Ts'o, Eric W. Biederman, Serge E. Hallyn,
containers, lkp, linux-kernel, zohar, tycho, James.Bottomley,
vgoyal, christian.brauner, amir73il, linux-security-module,
casey
On 07/13/2017 12:40 PM, Theodore Ts'o wrote:
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> The concise summary:
>>
>> Today we have the xattr security.capable that holds a set of
>> capabilities that an application gains when executed. AKA setuid root exec
>> without actually being setuid root.
>>
>> User namespaces have the concept of capabilities that are not global but
>> are limited to their user namespace. We do not currently have
>> filesystem support for this concept.
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo@uid=15000
>
> It's not like there will be:
>
> security.foo@uid=1000
> security.foo@uid=2000
A file shared by 2 containers, one mapping root to uid=1000, the other
mapping root to uid=2000, will show these two xattrs on the host
(init_user_ns) once these containers set xattrs on that file.
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes. Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
Note that we do keep compatibility to existing behavior. The
security.foo of the host is visible inside any container for as long as
the container root user doesn't set its own security.foo on that file,
which then hides it. Does that address this concern?
>
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo@uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo@uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
In the current implementation BAR is visible inside of any instance that
'covers' this uid with the mapping range. Above example of
security.foo@uid=1000 appears as security.foo inside the container with
root mapping to uid 1000 (@uid=0 is suppressed) but also appears as
security.foo@uid=100 with root uid mapping to 900 (and range of at least
101).
>
> Otherwise, I suspect that the architecture is going to turn around and
> bite us in the *ss eventually, because someone will want to do
> something crazy and the solution will not be scalable.
Can you define what 'scalable' means for you in this context?
From what I can see sharing a filesystem between multiple containers
doesn't 'scale well' for virtualizing the xattrs primarily because of
size limitations of xattrs per file.
Stefan
>
> -Ted
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:05 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 17:05 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]
On 07/13/2017 12:40 PM, Theodore Ts'o wrote:
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> The concise summary:
>>
>> Today we have the xattr security.capable that holds a set of
>> capabilities that an application gains when executed. AKA setuid root exec
>> without actually being setuid root.
>>
>> User namespaces have the concept of capabilities that are not global but
>> are limited to their user namespace. We do not currently have
>> filesystem support for this concept.
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo(a)uid=15000
>
> It's not like there will be:
>
> security.foo(a)uid=1000
> security.foo(a)uid=2000
A file shared by 2 containers, one mapping root to uid=1000, the other
mapping root to uid=2000, will show these two xattrs on the host
(init_user_ns) once these containers set xattrs on that file.
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes. Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
Note that we do keep compatibility to existing behavior. The
security.foo of the host is visible inside any container for as long as
the container root user doesn't set its own security.foo on that file,
which then hides it. Does that address this concern?
>
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo(a)uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo(a)uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
In the current implementation BAR is visible inside of any instance that
'covers' this uid with the mapping range. Above example of
security.foo(a)uid=1000 appears as security.foo inside the container with
root mapping to uid 1000 (@uid=0 is suppressed) but also appears as
security.foo(a)uid=100 with root uid mapping to 900 (and range of at least
101).
>
> Otherwise, I suspect that the architecture is going to turn around and
> bite us in the *ss eventually, because someone will want to do
> something crazy and the solution will not be scalable.
Can you define what 'scalable' means for you in this context?
From what I can see sharing a filesystem between multiple containers
doesn't 'scale well' for virtualizing the xattrs primarily because of
size limitations of xattrs per file.
Stefan
>
> -Ted
>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:05 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 17:05 UTC (permalink / raw)
To: linux-security-module
On 07/13/2017 12:40 PM, Theodore Ts'o wrote:
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> The concise summary:
>>
>> Today we have the xattr security.capable that holds a set of
>> capabilities that an application gains when executed. AKA setuid root exec
>> without actually being setuid root.
>>
>> User namespaces have the concept of capabilities that are not global but
>> are limited to their user namespace. We do not currently have
>> filesystem support for this concept.
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo at uid=15000
>
> It's not like there will be:
>
> security.foo at uid=1000
> security.foo at uid=2000
A file shared by 2 containers, one mapping root to uid=1000, the other
mapping root to uid=2000, will show these two xattrs on the host
(init_user_ns) once these containers set xattrs on that file.
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes. Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
Note that we do keep compatibility to existing behavior. The
security.foo of the host is visible inside any container for as long as
the container root user doesn't set its own security.foo on that file,
which then hides it. Does that address this concern?
>
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo at uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo at uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
In the current implementation BAR is visible inside of any instance that
'covers' this uid with the mapping range. Above example of
security.foo at uid=1000 appears as security.foo inside the container with
root mapping to uid 1000 (@uid=0 is suppressed) but also appears as
security.foo at uid=100 with root uid mapping to 900 (and range of at least
101).
>
> Otherwise, I suspect that the architecture is going to turn around and
> bite us in the *ss eventually, because someone will want to do
> something crazy and the solution will not be scalable.
Can you define what 'scalable' means for you in this context?
From what I can see sharing a filesystem between multiple containers
doesn't 'scale well' for virtualizing the xattrs primarily because of
size limitations of xattrs per file.
Stefan
>
> -Ted
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:05 ` Stefan Berger
(?)
@ 2017-07-13 17:39 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:39 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, Serge E. Hallyn, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 12:40 PM, Theodore Ts'o wrote:
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo@uid=15000
>>
>> It's not like there will be:
>>
>> security.foo@uid=1000
>> security.foo@uid=2000
>
> A file shared by 2 containers, one mapping root to uid=1000, the other
> mapping root to uid=2000, will show these two xattrs on the host
> (init_user_ns) once these containers set xattrs on that file.
There is an interesting solution for shared directory trees containing
executables.
Overlayfs is needed if you need those directory trees to be writable and
for the files to show up as owned by uid 0. An overlayfs will have to
do something with the security.capable attribute. So ignoring that case.
If you don't care about the ownership of the files, and read only is
acceptable, and you still don't want to give these executables
capabilities in the initial user namespace. What you can do is
make everything owned by some non-zero uid including the security
capability. Call this non-zero uid image-root.
When the container starts it creates two nested user namespaces first
with image-root mapped to 0. Then with the containers choice of uid
mapped to 0 image-root unmapped. This will ensure the capability
attributes work for all containers that share that root image. And it
ensures the file are read-only from the container.
So I don't think there is ever a case where we would share a filesystem
image where we would need to set multiple security attributes on a file.
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
>
> Can you define what 'scalable' means for you in this context?
> From what I can see sharing a filesystem between multiple containers
> doesn't 'scale well' for virtualizing the xattrs primarily because of
> size limitations of xattrs per file.
Worse than that I believe you will find that filesystems are built on
the assumption that there will be a small number of xattrs per file.
So even if the vfs limitations were lifted the filesystem performance
would suffer.
Even if the filesystem performed well I believe there are other issues
with stat, and simply not having so much meta-data that adminstrators
and tools get confused.
So I believe there are some very good fundamental reasons why we want to
limit the amount of meta-data per file.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:39 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:39 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3123 bytes --]
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 12:40 PM, Theodore Ts'o wrote:
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo(a)uid=15000
>>
>> It's not like there will be:
>>
>> security.foo(a)uid=1000
>> security.foo(a)uid=2000
>
> A file shared by 2 containers, one mapping root to uid=1000, the other
> mapping root to uid=2000, will show these two xattrs on the host
> (init_user_ns) once these containers set xattrs on that file.
There is an interesting solution for shared directory trees containing
executables.
Overlayfs is needed if you need those directory trees to be writable and
for the files to show up as owned by uid 0. An overlayfs will have to
do something with the security.capable attribute. So ignoring that case.
If you don't care about the ownership of the files, and read only is
acceptable, and you still don't want to give these executables
capabilities in the initial user namespace. What you can do is
make everything owned by some non-zero uid including the security
capability. Call this non-zero uid image-root.
When the container starts it creates two nested user namespaces first
with image-root mapped to 0. Then with the containers choice of uid
mapped to 0 image-root unmapped. This will ensure the capability
attributes work for all containers that share that root image. And it
ensures the file are read-only from the container.
So I don't think there is ever a case where we would share a filesystem
image where we would need to set multiple security attributes on a file.
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
>
> Can you define what 'scalable' means for you in this context?
> From what I can see sharing a filesystem between multiple containers
> doesn't 'scale well' for virtualizing the xattrs primarily because of
> size limitations of xattrs per file.
Worse than that I believe you will find that filesystems are built on
the assumption that there will be a small number of xattrs per file.
So even if the vfs limitations were lifted the filesystem performance
would suffer.
Even if the filesystem performed well I believe there are other issues
with stat, and simply not having so much meta-data that adminstrators
and tools get confused.
So I believe there are some very good fundamental reasons why we want to
limit the amount of meta-data per file.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:39 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:39 UTC (permalink / raw)
To: linux-security-module
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 12:40 PM, Theodore Ts'o wrote:
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo at uid=15000
>>
>> It's not like there will be:
>>
>> security.foo at uid=1000
>> security.foo at uid=2000
>
> A file shared by 2 containers, one mapping root to uid=1000, the other
> mapping root to uid=2000, will show these two xattrs on the host
> (init_user_ns) once these containers set xattrs on that file.
There is an interesting solution for shared directory trees containing
executables.
Overlayfs is needed if you need those directory trees to be writable and
for the files to show up as owned by uid 0. An overlayfs will have to
do something with the security.capable attribute. So ignoring that case.
If you don't care about the ownership of the files, and read only is
acceptable, and you still don't want to give these executables
capabilities in the initial user namespace. What you can do is
make everything owned by some non-zero uid including the security
capability. Call this non-zero uid image-root.
When the container starts it creates two nested user namespaces first
with image-root mapped to 0. Then with the containers choice of uid
mapped to 0 image-root unmapped. This will ensure the capability
attributes work for all containers that share that root image. And it
ensures the file are read-only from the container.
So I don't think there is ever a case where we would share a filesystem
image where we would need to set multiple security attributes on a file.
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
>
> Can you define what 'scalable' means for you in this context?
> From what I can see sharing a filesystem between multiple containers
> doesn't 'scale well' for virtualizing the xattrs primarily because of
> size limitations of xattrs per file.
Worse than that I believe you will find that filesystems are built on
the assumption that there will be a small number of xattrs per file.
So even if the vfs limitations were lifted the filesystem performance
would suffer.
Even if the filesystem performed well I believe there are other issues
with stat, and simply not having so much meta-data that adminstrators
and tools get confused.
So I believe there are some very good fundamental reasons why we want to
limit the amount of meta-data per file.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <8760ew9qyp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:39 ` Eric W. Biederman
(?)
(?)
@ 2017-07-13 19:14 ` Theodore Ts'o
-1 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 19:14 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable@uid=1000
security.capable@uid=2000
security.capable@uid=3000
security.capable@uid=4000
security.capable@uid=5000
security.capable@uid=6000
security.capable@uid=7000
security.capable@uid=8000
security.capable@uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable@guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima@uid=1000
security.ima@uid=2000
security.ima@uid=3000
security.ima@uid=4000
security.ima@uid=5000
security.ima@uid=6000
security.ima@uid=7000
security.ima@uid=8000
security.ima@uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 19:14 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 19:14 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable(a)uid=1000
security.capable(a)uid=2000
security.capable(a)uid=3000
security.capable(a)uid=4000
security.capable(a)uid=5000
security.capable(a)uid=6000
security.capable(a)uid=7000
security.capable(a)uid=8000
security.capable(a)uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable(a)guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima(a)uid=1000
security.ima(a)uid=2000
security.ima(a)uid=3000
security.ima(a)uid=4000
security.ima(a)uid=5000
security.ima(a)uid=6000
security.ima(a)uid=7000
security.ima(a)uid=8000
security.ima(a)uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 19:14 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 19:14 UTC (permalink / raw)
To: linux-security-module
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable at uid=1000
security.capable at uid=2000
security.capable at uid=3000
security.capable at uid=4000
security.capable at uid=5000
security.capable at uid=6000
security.capable at uid=7000
security.capable at uid=8000
security.capable at uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable at guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima at uid=1000
security.ima at uid=2000
security.ima at uid=3000
security.ima at uid=4000
security.ima at uid=5000
security.ima at uid=6000
security.ima at uid=7000
security.ima at uid=8000
security.ima at uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 19:14 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-13 19:14 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stefan Berger, Serge E. Hallyn, containers, lkp, linux-kernel,
zohar, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable@uid=1000
security.capable@uid=2000
security.capable@uid=3000
security.capable@uid=4000
security.capable@uid=5000
security.capable@uid=6000
security.capable@uid=7000
security.capable@uid=8000
security.capable@uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable@guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima@uid=1000
security.ima@uid=2000
security.ima@uid=3000
security.ima@uid=4000
security.ima@uid=5000
security.ima@uid=6000
security.ima@uid=7000
security.ima@uid=8000
security.ima@uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <20170713191429.vfaetqscxd7hniwq-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170713191429.vfaetqscxd7hniwq-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
@ 2017-07-13 19:41 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 19:41 UTC (permalink / raw)
To: Theodore Ts'o, Eric W. Biederman, Stefan Berger,
Serge E. Hallyn,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lkp-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
tycho-FCduhRhOUaTQT0dZR+AlfA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA,
christian.brauner-cl+VPiYnx/1AfugRpC6u6w,
amir73il-Re5JQEeQqe8AvxtiuMwx3w,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A
Quoting Theodore Ts'o (tytso-3s7WtUTddSA@public.gmane.org):
> On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > > Can you define what 'scalable' means for you in this context?
> > > From what I can see sharing a filesystem between multiple containers
> > > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > > size limitations of xattrs per file.
> >
> > Worse than that I believe you will find that filesystems are built on
> > the assumption that there will be a small number of xattrs per file.
> > So even if the vfs limitations were lifted the filesystem performance
> > would suffer.
>
> That's why I've been pushing here. If people try to do
>
> security.capable@uid=1000
> security.capable@uid=2000
> security.capable@uid=3000
> security.capable@uid=4000
> security.capable@uid=5000
> security.capable@uid=6000
> security.capable@uid=7000
> security.capable@uid=8000
> security.capable@uid=9000
> .
> .
> .
>
> ... where the values of all of these will be the same, this is going
> to be *awful* even if the file system can support it.
Typically users will be allocated a single range of ids, for instance
100000-200000. We might therefore consider putting a range in the uid=,
i.e. security.capable@uid=100000-200000. I don't think that's really
needed, but it's an option.
Consider that the executable will be owned by some kuid+kgid. If we
have all the xattrs you list above, then who would we have actually
owning the file? If we're chown'ing it anyway (to be root-owned but
not seutid-root), then this discussion is moot, because we'll have
to re-write the xattr after the chown. So for this to matter, we
would have an fs owned by either uid nobody in the container, or
by some special user (mapped to 100000 in the container perhaps)
which is always special-case-mapped into the container.
> So maybe we are better off if we define an xattr
>
> security.capable@guest-container
> ... so the property is that it is ignored by the host ("real")
> container, and in all of the subcontainers, it will be used if the
> local container root is trying to execute the file.
In the previous discussion we considered having 'security.capable@uid='
with no following integer, meaning that it would take effect in all
user namespaces which do not have kuid 0 as root.
This could be useful for cases like docker hosts, but note that writing
this has to require either global CAP_SETFCAP, or CAP_SETFCAP in a
user namespace that has every kuid except 0 mapped. If joe, uid 1000,
has subuids 100000-20000 delegated to him, then he must not be allowed
to write something that can affect someone with kuids 300000-400000.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 19:14 ` Theodore Ts'o
@ 2017-07-13 19:41 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 19:41 UTC (permalink / raw)
To: Theodore Ts'o, Eric W. Biederman, Stefan Berger,
Serge E. Hallyn, containers, lkp, linux-kernel, zohar, tycho,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
Quoting Theodore Ts'o (tytso@mit.edu):
> On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > > Can you define what 'scalable' means for you in this context?
> > > From what I can see sharing a filesystem between multiple containers
> > > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > > size limitations of xattrs per file.
> >
> > Worse than that I believe you will find that filesystems are built on
> > the assumption that there will be a small number of xattrs per file.
> > So even if the vfs limitations were lifted the filesystem performance
> > would suffer.
>
> That's why I've been pushing here. If people try to do
>
> security.capable@uid=1000
> security.capable@uid=2000
> security.capable@uid=3000
> security.capable@uid=4000
> security.capable@uid=5000
> security.capable@uid=6000
> security.capable@uid=7000
> security.capable@uid=8000
> security.capable@uid=9000
> .
> .
> .
>
> ... where the values of all of these will be the same, this is going
> to be *awful* even if the file system can support it.
Typically users will be allocated a single range of ids, for instance
100000-200000. We might therefore consider putting a range in the uid=,
i.e. security.capable@uid=100000-200000. I don't think that's really
needed, but it's an option.
Consider that the executable will be owned by some kuid+kgid. If we
have all the xattrs you list above, then who would we have actually
owning the file? If we're chown'ing it anyway (to be root-owned but
not seutid-root), then this discussion is moot, because we'll have
to re-write the xattr after the chown. So for this to matter, we
would have an fs owned by either uid nobody in the container, or
by some special user (mapped to 100000 in the container perhaps)
which is always special-case-mapped into the container.
> So maybe we are better off if we define an xattr
>
> security.capable@guest-container
> ... so the property is that it is ignored by the host ("real")
> container, and in all of the subcontainers, it will be used if the
> local container root is trying to execute the file.
In the previous discussion we considered having 'security.capable@uid='
with no following integer, meaning that it would take effect in all
user namespaces which do not have kuid 0 as root.
This could be useful for cases like docker hosts, but note that writing
this has to require either global CAP_SETFCAP, or CAP_SETFCAP in a
user namespace that has every kuid except 0 mapped. If joe, uid 1000,
has subuids 100000-20000 delegated to him, then he must not be allowed
to write something that can affect someone with kuids 300000-400000.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 19:41 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 19:41 UTC (permalink / raw)
To: linux-security-module
Quoting Theodore Ts'o (tytso at mit.edu):
> On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > > Can you define what 'scalable' means for you in this context?
> > > From what I can see sharing a filesystem between multiple containers
> > > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > > size limitations of xattrs per file.
> >
> > Worse than that I believe you will find that filesystems are built on
> > the assumption that there will be a small number of xattrs per file.
> > So even if the vfs limitations were lifted the filesystem performance
> > would suffer.
>
> That's why I've been pushing here. If people try to do
>
> security.capable at uid=1000
> security.capable at uid=2000
> security.capable at uid=3000
> security.capable at uid=4000
> security.capable at uid=5000
> security.capable at uid=6000
> security.capable at uid=7000
> security.capable at uid=8000
> security.capable at uid=9000
> .
> .
> .
>
> ... where the values of all of these will be the same, this is going
> to be *awful* even if the file system can support it.
Typically users will be allocated a single range of ids, for instance
100000-200000. We might therefore consider putting a range in the uid=,
i.e. security.capable at uid=100000-200000. I don't think that's really
needed, but it's an option.
Consider that the executable will be owned by some kuid+kgid. If we
have all the xattrs you list above, then who would we have actually
owning the file? If we're chown'ing it anyway (to be root-owned but
not seutid-root), then this discussion is moot, because we'll have
to re-write the xattr after the chown. So for this to matter, we
would have an fs owned by either uid nobody in the container, or
by some special user (mapped to 100000 in the container perhaps)
which is always special-case-mapped into the container.
> So maybe we are better off if we define an xattr
>
> security.capable at guest-container
> ... so the property is that it is ignored by the host ("real")
> container, and in all of the subcontainers, it will be used if the
> local container root is trying to execute the file.
In the previous discussion we considered having 'security.capable at uid='
with no following integer, meaning that it would take effect in all
user namespaces which do not have kuid 0 as root.
This could be useful for cases like docker hosts, but note that writing
this has to require either global CAP_SETFCAP, or CAP_SETFCAP in a
user namespace that has every kuid except 0 mapped. If joe, uid 1000,
has subuids 100000-20000 delegated to him, then he must not be allowed
to write something that can affect someone with kuids 300000-400000.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:39 ` Eric W. Biederman
(?)
@ 2017-07-13 21:17 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:17 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> If you don't care about the ownership of the files, and read only is
> acceptable, and you still don't want to give these executables
> capabilities in the initial user namespace. What you can do is
> make everything owned by some non-zero uid including the security
> capability. Call this non-zero uid image-root.
>
> When the container starts it creates two nested user namespaces first
> with image-root mapped to 0. Then with the containers choice of uid
> mapped to 0 image-root unmapped. This will ensure the capability
> attributes work for all containers that share that root image. And it
> ensures the file are read-only from the container.
>
> So I don't think there is ever a case where we would share a filesystem
> image where we would need to set multiple security attributes on a file.
Neat idea. In fact, you can take it a step further and still have the
files be owned by valid uids in the containers. The parent ns just
needs to have its *root* map to a common kuid not mapped into the child
namespaces, but the files can be owned by another kuid which *is* mapped
into the child containers.
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 21:17 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:17 UTC (permalink / raw)
To: linux-security-module
Quoting Eric W. Biederman (ebiederm at xmission.com):
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> If you don't care about the ownership of the files, and read only is
> acceptable, and you still don't want to give these executables
> capabilities in the initial user namespace. What you can do is
> make everything owned by some non-zero uid including the security
> capability. Call this non-zero uid image-root.
>
> When the container starts it creates two nested user namespaces first
> with image-root mapped to 0. Then with the containers choice of uid
> mapped to 0 image-root unmapped. This will ensure the capability
> attributes work for all containers that share that root image. And it
> ensures the file are read-only from the container.
>
> So I don't think there is ever a case where we would share a filesystem
> image where we would need to set multiple security attributes on a file.
Neat idea. In fact, you can take it a step further and still have the
files be owned by valid uids in the containers. The parent ns just
needs to have its *root* map to a common kuid not mapped into the child
namespaces, but the files can be owned by another kuid which *is* mapped
into the child containers.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 21:17 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:17 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stefan Berger, Theodore Ts'o, Serge E. Hallyn, containers,
lkp, linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> If you don't care about the ownership of the files, and read only is
> acceptable, and you still don't want to give these executables
> capabilities in the initial user namespace. What you can do is
> make everything owned by some non-zero uid including the security
> capability. Call this non-zero uid image-root.
>
> When the container starts it creates two nested user namespaces first
> with image-root mapped to 0. Then with the containers choice of uid
> mapped to 0 image-root unmapped. This will ensure the capability
> attributes work for all containers that share that root image. And it
> ensures the file are read-only from the container.
>
> So I don't think there is ever a case where we would share a filesystem
> image where we would need to set multiple security attributes on a file.
Neat idea. In fact, you can take it a step further and still have the
files be owned by valid uids in the containers. The parent ns just
needs to have its *root* map to a common kuid not mapped into the child
namespaces, but the files can be owned by another kuid which *is* mapped
into the child containers.
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <29fdda5e-ed4a-bcda-e3cc-c06ab87973ce-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <29fdda5e-ed4a-bcda-e3cc-c06ab87973ce-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-13 17:39 ` Eric W. Biederman
2017-07-18 7:01 ` James Morris
1 sibling, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:39 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> On 07/13/2017 12:40 PM, Theodore Ts'o wrote:
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo@uid=15000
>>
>> It's not like there will be:
>>
>> security.foo@uid=1000
>> security.foo@uid=2000
>
> A file shared by 2 containers, one mapping root to uid=1000, the other
> mapping root to uid=2000, will show these two xattrs on the host
> (init_user_ns) once these containers set xattrs on that file.
There is an interesting solution for shared directory trees containing
executables.
Overlayfs is needed if you need those directory trees to be writable and
for the files to show up as owned by uid 0. An overlayfs will have to
do something with the security.capable attribute. So ignoring that case.
If you don't care about the ownership of the files, and read only is
acceptable, and you still don't want to give these executables
capabilities in the initial user namespace. What you can do is
make everything owned by some non-zero uid including the security
capability. Call this non-zero uid image-root.
When the container starts it creates two nested user namespaces first
with image-root mapped to 0. Then with the containers choice of uid
mapped to 0 image-root unmapped. This will ensure the capability
attributes work for all containers that share that root image. And it
ensures the file are read-only from the container.
So I don't think there is ever a case where we would share a filesystem
image where we would need to set multiple security attributes on a file.
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
>
> Can you define what 'scalable' means for you in this context?
> From what I can see sharing a filesystem between multiple containers
> doesn't 'scale well' for virtualizing the xattrs primarily because of
> size limitations of xattrs per file.
Worse than that I believe you will find that filesystems are built on
the assumption that there will be a small number of xattrs per file.
So even if the vfs limitations were lifted the filesystem performance
would suffer.
Even if the filesystem performed well I believe there are other issues
with stat, and simply not having so much meta-data that adminstrators
and tools get confused.
So I believe there are some very good fundamental reasons why we want to
limit the amount of meta-data per file.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:05 ` Stefan Berger
(?)
(?)
@ 2017-07-18 7:01 ` James Morris
-1 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-18 7:01 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On Thu, 13 Jul 2017, Stefan Berger wrote:
> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
> these containers set xattrs on that file.
I may be missing something here, but what happens when say the uid=2000
container and associated user is deleted from the system, then another is
created with the same uid?
Won't this mean that you have unexpected capabilities turning up in the
new container?
--
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 7:01 ` James Morris
0 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-18 7:01 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
On Thu, 13 Jul 2017, Stefan Berger wrote:
> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
> these containers set xattrs on that file.
I may be missing something here, but what happens when say the uid=2000
container and associated user is deleted from the system, then another is
created with the same uid?
Won't this mean that you have unexpected capabilities turning up in the
new container?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 7:01 ` James Morris
0 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-18 7:01 UTC (permalink / raw)
To: linux-security-module
On Thu, 13 Jul 2017, Stefan Berger wrote:
> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
> these containers set xattrs on that file.
I may be missing something here, but what happens when say the uid=2000
container and associated user is deleted from the system, then another is
created with the same uid?
Won't this mean that you have unexpected capabilities turning up in the
new container?
--
James Morris
<jmorris@namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 7:01 ` James Morris
0 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-18 7:01 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, Eric W. Biederman, Serge E. Hallyn,
containers, lkp, linux-kernel, zohar, tycho, James.Bottomley,
vgoyal, christian.brauner, amir73il, linux-security-module,
casey
On Thu, 13 Jul 2017, Stefan Berger wrote:
> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
> these containers set xattrs on that file.
I may be missing something here, but what happens when say the uid=2000
container and associated user is deleted from the system, then another is
created with the same uid?
Won't this mean that you have unexpected capabilities turning up in the
new container?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <alpine.LRH.2.20.1707181659030.5209-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <alpine.LRH.2.20.1707181659030.5209-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
@ 2017-07-18 12:12 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 12:12 UTC (permalink / raw)
To: James Morris
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On 07/18/2017 03:01 AM, James Morris wrote:
> On Thu, 13 Jul 2017, Stefan Berger wrote:
>
>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
>> these containers set xattrs on that file.
> I may be missing something here, but what happens when say the uid=2000
> container and associated user is deleted from the system, then another is
> created with the same uid?
>
> Won't this mean that you have unexpected capabilities turning up in the
> new container?
>
Yes, that's right. I don't know any solution for that. We would have to
walk the filesystems and find all 'stale' xattrs with such a uid. This
is independent of whether the uid is encoded on the name side, as in
this patch, or on the value side, as in Serge's original proposal. And
uids of a mapped container root user don't necessarily have to have an
account on the host so that an account deletion could trigger that.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 7:01 ` James Morris
(?)
@ 2017-07-18 12:12 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 12:12 UTC (permalink / raw)
To: James Morris
Cc: Theodore Ts'o, Eric W. Biederman, Serge E. Hallyn,
containers, lkp, linux-kernel, zohar, tycho, James.Bottomley,
vgoyal, christian.brauner, amir73il, linux-security-module,
casey
On 07/18/2017 03:01 AM, James Morris wrote:
> On Thu, 13 Jul 2017, Stefan Berger wrote:
>
>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
>> these containers set xattrs on that file.
> I may be missing something here, but what happens when say the uid=2000
> container and associated user is deleted from the system, then another is
> created with the same uid?
>
> Won't this mean that you have unexpected capabilities turning up in the
> new container?
>
Yes, that's right. I don't know any solution for that. We would have to
walk the filesystems and find all 'stale' xattrs with such a uid. This
is independent of whether the uid is encoded on the name side, as in
this patch, or on the value side, as in Serge's original proposal. And
uids of a mapped container root user don't necessarily have to have an
account on the host so that an account deletion could trigger that.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 12:12 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 12:12 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
On 07/18/2017 03:01 AM, James Morris wrote:
> On Thu, 13 Jul 2017, Stefan Berger wrote:
>
>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
>> these containers set xattrs on that file.
> I may be missing something here, but what happens when say the uid=2000
> container and associated user is deleted from the system, then another is
> created with the same uid?
>
> Won't this mean that you have unexpected capabilities turning up in the
> new container?
>
Yes, that's right. I don't know any solution for that. We would have to
walk the filesystems and find all 'stale' xattrs with such a uid. This
is independent of whether the uid is encoded on the name side, as in
this patch, or on the value side, as in Serge's original proposal. And
uids of a mapped container root user don't necessarily have to have an
account on the host so that an account deletion could trigger that.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 12:12 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 12:12 UTC (permalink / raw)
To: linux-security-module
On 07/18/2017 03:01 AM, James Morris wrote:
> On Thu, 13 Jul 2017, Stefan Berger wrote:
>
>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
>> these containers set xattrs on that file.
> I may be missing something here, but what happens when say the uid=2000
> container and associated user is deleted from the system, then another is
> created with the same uid?
>
> Won't this mean that you have unexpected capabilities turning up in the
> new container?
>
Yes, that's right. I don't know any solution for that. We would have to
walk the filesystems and find all 'stale' xattrs with such a uid. This
is independent of whether the uid is encoded on the name side, as in
this patch, or on the value side, as in Serge's original proposal. And
uids of a mapped container root user don't necessarily have to have an
account on the host so that an account deletion could trigger that.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <aae67245-4c9c-f79e-b821-40753e732f65-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 12:12 ` Stefan Berger
(?)
(?)
@ 2017-07-18 13:26 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-18 13:26 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> On 07/18/2017 03:01 AM, James Morris wrote:
>> On Thu, 13 Jul 2017, Stefan Berger wrote:
>>
>>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
>>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
>>> these containers set xattrs on that file.
>> I may be missing something here, but what happens when say the uid=2000
>> container and associated user is deleted from the system, then another is
>> created with the same uid?
>>
>> Won't this mean that you have unexpected capabilities turning up in the
>> new container?
>>
>
> Yes, that's right. I don't know any solution for that. We would have to walk the
> filesystems and find all 'stale' xattrs with such a uid. This is independent of
> whether the uid is encoded on the name side, as in this patch, or on the value
> side, as in Serge's original proposal. And uids of a mapped container root user
> don't necessarily have to have an account on the host so that an account
> deletion could trigger that.
This problem is actually independent of this piece of code entirely.
Any lingering files owned by that uid have the same issue.
Uids are are persistent system property. It must be arranged that they
are managed carefully. If you want to reuse a uid userdel or the
equivalent must be able to go out and delete everything they have owned.
Which is to say fundamentally this is userspaces's responsibility.
I don't see this as being particularly subtle or novel. We already
track which uids and which subordinate uids go together. I will nack
anything that allows multiple capability attributes per file as we have
established they are unnecessary. So I don't see any scenarios where
this is likely to come up that it would not be a problem without these
uid tagged security capabilities.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 13:26 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-18 13:26 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/18/2017 03:01 AM, James Morris wrote:
>> On Thu, 13 Jul 2017, Stefan Berger wrote:
>>
>>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
>>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
>>> these containers set xattrs on that file.
>> I may be missing something here, but what happens when say the uid=2000
>> container and associated user is deleted from the system, then another is
>> created with the same uid?
>>
>> Won't this mean that you have unexpected capabilities turning up in the
>> new container?
>>
>
> Yes, that's right. I don't know any solution for that. We would have to walk the
> filesystems and find all 'stale' xattrs with such a uid. This is independent of
> whether the uid is encoded on the name side, as in this patch, or on the value
> side, as in Serge's original proposal. And uids of a mapped container root user
> don't necessarily have to have an account on the host so that an account
> deletion could trigger that.
This problem is actually independent of this piece of code entirely.
Any lingering files owned by that uid have the same issue.
Uids are are persistent system property. It must be arranged that they
are managed carefully. If you want to reuse a uid userdel or the
equivalent must be able to go out and delete everything they have owned.
Which is to say fundamentally this is userspaces's responsibility.
I don't see this as being particularly subtle or novel. We already
track which uids and which subordinate uids go together. I will nack
anything that allows multiple capability attributes per file as we have
established they are unnecessary. So I don't see any scenarios where
this is likely to come up that it would not be a problem without these
uid tagged security capabilities.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 13:26 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-18 13:26 UTC (permalink / raw)
To: linux-security-module
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/18/2017 03:01 AM, James Morris wrote:
>> On Thu, 13 Jul 2017, Stefan Berger wrote:
>>
>>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
>>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
>>> these containers set xattrs on that file.
>> I may be missing something here, but what happens when say the uid=2000
>> container and associated user is deleted from the system, then another is
>> created with the same uid?
>>
>> Won't this mean that you have unexpected capabilities turning up in the
>> new container?
>>
>
> Yes, that's right. I don't know any solution for that. We would have to walk the
> filesystems and find all 'stale' xattrs with such a uid. This is independent of
> whether the uid is encoded on the name side, as in this patch, or on the value
> side, as in Serge's original proposal. And uids of a mapped container root user
> don't necessarily have to have an account on the host so that an account
> deletion could trigger that.
This problem is actually independent of this piece of code entirely.
Any lingering files owned by that uid have the same issue.
Uids are are persistent system property. It must be arranged that they
are managed carefully. If you want to reuse a uid userdel or the
equivalent must be able to go out and delete everything they have owned.
Which is to say fundamentally this is userspaces's responsibility.
I don't see this as being particularly subtle or novel. We already
track which uids and which subordinate uids go together. I will nack
anything that allows multiple capability attributes per file as we have
established they are unnecessary. So I don't see any scenarios where
this is likely to come up that it would not be a problem without these
uid tagged security capabilities.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 13:26 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-18 13:26 UTC (permalink / raw)
To: Stefan Berger
Cc: James Morris, Theodore Ts'o, Serge E. Hallyn, containers,
lkp, linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/18/2017 03:01 AM, James Morris wrote:
>> On Thu, 13 Jul 2017, Stefan Berger wrote:
>>
>>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
>>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
>>> these containers set xattrs on that file.
>> I may be missing something here, but what happens when say the uid=2000
>> container and associated user is deleted from the system, then another is
>> created with the same uid?
>>
>> Won't this mean that you have unexpected capabilities turning up in the
>> new container?
>>
>
> Yes, that's right. I don't know any solution for that. We would have to walk the
> filesystems and find all 'stale' xattrs with such a uid. This is independent of
> whether the uid is encoded on the name side, as in this patch, or on the value
> side, as in Serge's original proposal. And uids of a mapped container root user
> don't necessarily have to have an account on the host so that an account
> deletion could trigger that.
This problem is actually independent of this piece of code entirely.
Any lingering files owned by that uid have the same issue.
Uids are are persistent system property. It must be arranged that they
are managed carefully. If you want to reuse a uid userdel or the
equivalent must be able to go out and delete everything they have owned.
Which is to say fundamentally this is userspaces's responsibility.
I don't see this as being particularly subtle or novel. We already
track which uids and which subordinate uids go together. I will nack
anything that allows multiple capability attributes per file as we have
established they are unnecessary. So I don't see any scenarios where
this is likely to come up that it would not be a problem without these
uid tagged security capabilities.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 13:26 ` Eric W. Biederman
@ 2017-07-18 23:13 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-18 23:13 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stefan Berger, James Morris, Theodore Ts'o, Serge E. Hallyn,
containers, lkp, linux-kernel, zohar, tycho, James.Bottomley,
vgoyal, christian.brauner, amir73il, linux-security-module,
casey
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
> > On 07/18/2017 03:01 AM, James Morris wrote:
> >> On Thu, 13 Jul 2017, Stefan Berger wrote:
> >>
> >>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
> >>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
> >>> these containers set xattrs on that file.
> >> I may be missing something here, but what happens when say the uid=2000
> >> container and associated user is deleted from the system, then another is
> >> created with the same uid?
> >>
> >> Won't this mean that you have unexpected capabilities turning up in the
> >> new container?
> >>
> >
> > Yes, that's right. I don't know any solution for that. We would have to walk the
> > filesystems and find all 'stale' xattrs with such a uid. This is independent of
> > whether the uid is encoded on the name side, as in this patch, or on the value
> > side, as in Serge's original proposal. And uids of a mapped container root user
> > don't necessarily have to have an account on the host so that an account
> > deletion could trigger that.
>
> This problem is actually independent of this piece of code entirely.
> Any lingering files owned by that uid have the same issue.
In particular, any setuid-root files in that container have the precisely
analogous issue.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 23:13 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-18 23:13 UTC (permalink / raw)
To: linux-security-module
Quoting Eric W. Biederman (ebiederm at xmission.com):
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
> > On 07/18/2017 03:01 AM, James Morris wrote:
> >> On Thu, 13 Jul 2017, Stefan Berger wrote:
> >>
> >>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
> >>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
> >>> these containers set xattrs on that file.
> >> I may be missing something here, but what happens when say the uid=2000
> >> container and associated user is deleted from the system, then another is
> >> created with the same uid?
> >>
> >> Won't this mean that you have unexpected capabilities turning up in the
> >> new container?
> >>
> >
> > Yes, that's right. I don't know any solution for that. We would have to walk the
> > filesystems and find all 'stale' xattrs with such a uid. This is independent of
> > whether the uid is encoded on the name side, as in this patch, or on the value
> > side, as in Serge's original proposal. And uids of a mapped container root user
> > don't necessarily have to have an account on the host so that an account
> > deletion could trigger that.
>
> This problem is actually independent of this piece of code entirely.
> Any lingering files owned by that uid have the same issue.
In particular, any setuid-root files in that container have the precisely
analogous issue.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <871spdj2pe.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <871spdj2pe.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2017-07-18 23:13 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-18 23:13 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>
> > On 07/18/2017 03:01 AM, James Morris wrote:
> >> On Thu, 13 Jul 2017, Stefan Berger wrote:
> >>
> >>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping
> >>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once
> >>> these containers set xattrs on that file.
> >> I may be missing something here, but what happens when say the uid=2000
> >> container and associated user is deleted from the system, then another is
> >> created with the same uid?
> >>
> >> Won't this mean that you have unexpected capabilities turning up in the
> >> new container?
> >>
> >
> > Yes, that's right. I don't know any solution for that. We would have to walk the
> > filesystems and find all 'stale' xattrs with such a uid. This is independent of
> > whether the uid is encoded on the name side, as in this patch, or on the value
> > side, as in Serge's original proposal. And uids of a mapped container root user
> > don't necessarily have to have an account on the host so that an account
> > deletion could trigger that.
>
> This problem is actually independent of this piece of code entirely.
> Any lingering files owned by that uid have the same issue.
In particular, any setuid-root files in that container have the precisely
analogous issue.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 16:40 ` Theodore Ts'o
(?)
@ 2017-07-13 17:14 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:14 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Stefan Berger, Serge E. Hallyn, containers, lkp, linux-kernel,
zohar, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
Theodore Ts'o <tytso@mit.edu> writes:
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> The concise summary:
>>
>> Today we have the xattr security.capable that holds a set of
>> capabilities that an application gains when executed. AKA setuid root exec
>> without actually being setuid root.
>>
>> User namespaces have the concept of capabilities that are not global but
>> are limited to their user namespace. We do not currently have
>> filesystem support for this concept.
>
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo@uid=15000
>
> It's not like there will be:
>
> security.foo@uid=1000
> security.foo@uid=2000
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes. Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
>
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo@uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo@uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
>
> Otherwise, I suspect that the architecture is going to turn around and
> bite us in the *ss eventually, because someone will want to do
> something crazy and the solution will not be scalable.
Yep. That is what it looks like from here.
Which is why I asked the question about scalability of the xattr
implementations. It looks like trying to accomodate the general
case just gets us in trouble, and sets unrealistic expectations.
Which strongly suggests that Serge's previous version that
just reved the format of security.capable so that a uid field could
be added is likely to be the better approach.
I want to see what Serge and Stefan have to say but the case looks
pretty clear cut at the moment.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:14 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:14 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2515 bytes --]
Theodore Ts'o <tytso@mit.edu> writes:
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> The concise summary:
>>
>> Today we have the xattr security.capable that holds a set of
>> capabilities that an application gains when executed. AKA setuid root exec
>> without actually being setuid root.
>>
>> User namespaces have the concept of capabilities that are not global but
>> are limited to their user namespace. We do not currently have
>> filesystem support for this concept.
>
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo(a)uid=15000
>
> It's not like there will be:
>
> security.foo(a)uid=1000
> security.foo(a)uid=2000
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes. Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
>
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo(a)uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo(a)uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
>
> Otherwise, I suspect that the architecture is going to turn around and
> bite us in the *ss eventually, because someone will want to do
> something crazy and the solution will not be scalable.
Yep. That is what it looks like from here.
Which is why I asked the question about scalability of the xattr
implementations. It looks like trying to accomodate the general
case just gets us in trouble, and sets unrealistic expectations.
Which strongly suggests that Serge's previous version that
just reved the format of security.capable so that a uid field could
be added is likely to be the better approach.
I want to see what Serge and Stefan have to say but the case looks
pretty clear cut at the moment.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:14 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:14 UTC (permalink / raw)
To: linux-security-module
Theodore Ts'o <tytso@mit.edu> writes:
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> The concise summary:
>>
>> Today we have the xattr security.capable that holds a set of
>> capabilities that an application gains when executed. AKA setuid root exec
>> without actually being setuid root.
>>
>> User namespaces have the concept of capabilities that are not global but
>> are limited to their user namespace. We do not currently have
>> filesystem support for this concept.
>
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo at uid=15000
>
> It's not like there will be:
>
> security.foo at uid=1000
> security.foo at uid=2000
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes. Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
>
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo at uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo at uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
>
> Otherwise, I suspect that the architecture is going to turn around and
> bite us in the *ss eventually, because someone will want to do
> something crazy and the solution will not be scalable.
Yep. That is what it looks like from here.
Which is why I asked the question about scalability of the xattr
implementations. It looks like trying to accomodate the general
case just gets us in trouble, and sets unrealistic expectations.
Which strongly suggests that Serge's previous version that
just reved the format of security.capable so that a uid field could
be added is likely to be the better approach.
I want to see what Serge and Stefan have to say but the case looks
pretty clear cut at the moment.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:14 ` Eric W. Biederman
(?)
@ 2017-07-13 17:33 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 17:33 UTC (permalink / raw)
To: Eric W. Biederman, Theodore Ts'o
Cc: Serge E. Hallyn, containers, lkp, linux-kernel, zohar, tycho,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
> Theodore Ts'o <tytso@mit.edu> writes:
>
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo@uid=15000
>>
>> It's not like there will be:
>>
>> security.foo@uid=1000
>> security.foo@uid=2000
>>
>> Except.... if you have an Distribution root directory which is shared
>> by many containers, you would need to put the xattrs in the overlay
>> inodes. Worse, each time you launch a new container, with a new
>> subuid allocation, you will have to iterate over all files with
>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> So that's actually a bit of a disaster.
>>
>> So for distribution overlays, you will need to do things a different
>> way, which is to map the distro subdirectory so you know that the
>> capability with the global uid 0 should be used for the container
>> "root" uid, right?
>>
>> So this hack of using security.foo@uid=1000 is *only* useful when the
>> subcontainer root wants to create the privileged executable. You
>> still have to do things the other way.
>>
>> So can we make perhaps the assertion that *either*:
>>
>> security.foo
>>
>> exists, *or*
>>
>> security.foo@uid=BAR
>>
>> exists, but never both? And there BAR is exclusive to only one
>> instances?
>>
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
> Yep. That is what it looks like from here.
>
> Which is why I asked the question about scalability of the xattr
> implementations. It looks like trying to accomodate the general
> case just gets us in trouble, and sets unrealistic expectations.
>
> Which strongly suggests that Serge's previous version that
> just reved the format of security.capable so that a uid field could
> be added is likely to be the better approach.
>
> I want to see what Serge and Stefan have to say but the case looks
> pretty clear cut at the moment.
The approach of virtualizing the xattrs on the name-side, which is what
this patch does, provides a more general approach than to virtualizing
it on the value side, which is what Serge does in his other patch for
security.capability alone. With the virtualizing on-the-value side
virtualizing the xattr becomes an exercise that needs to be repeated for
every xattr name that one would want to virtualize. With this patch you
would just add another xattr name to a list, a one-line patch in the
end. Xattr with prefixes like trusted.* need a bit more work but this
can be woven in as well
(https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
For virtualizing the xattrs on the 'value' side I was looking for
whether there's something like a 'wrapper' structure around the actual
value of the xattr so that that wrapper could be extended to support
different values at different uids and applied to any xattr.
Unfortunately there's no such 'wrapper'.
Stefan
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:33 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 17:33 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3678 bytes --]
On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
> Theodore Ts'o <tytso@mit.edu> writes:
>
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo(a)uid=15000
>>
>> It's not like there will be:
>>
>> security.foo(a)uid=1000
>> security.foo(a)uid=2000
>>
>> Except.... if you have an Distribution root directory which is shared
>> by many containers, you would need to put the xattrs in the overlay
>> inodes. Worse, each time you launch a new container, with a new
>> subuid allocation, you will have to iterate over all files with
>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> So that's actually a bit of a disaster.
>>
>> So for distribution overlays, you will need to do things a different
>> way, which is to map the distro subdirectory so you know that the
>> capability with the global uid 0 should be used for the container
>> "root" uid, right?
>>
>> So this hack of using security.foo(a)uid=1000 is *only* useful when the
>> subcontainer root wants to create the privileged executable. You
>> still have to do things the other way.
>>
>> So can we make perhaps the assertion that *either*:
>>
>> security.foo
>>
>> exists, *or*
>>
>> security.foo(a)uid=BAR
>>
>> exists, but never both? And there BAR is exclusive to only one
>> instances?
>>
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
> Yep. That is what it looks like from here.
>
> Which is why I asked the question about scalability of the xattr
> implementations. It looks like trying to accomodate the general
> case just gets us in trouble, and sets unrealistic expectations.
>
> Which strongly suggests that Serge's previous version that
> just reved the format of security.capable so that a uid field could
> be added is likely to be the better approach.
>
> I want to see what Serge and Stefan have to say but the case looks
> pretty clear cut at the moment.
The approach of virtualizing the xattrs on the name-side, which is what
this patch does, provides a more general approach than to virtualizing
it on the value side, which is what Serge does in his other patch for
security.capability alone. With the virtualizing on-the-value side
virtualizing the xattr becomes an exercise that needs to be repeated for
every xattr name that one would want to virtualize. With this patch you
would just add another xattr name to a list, a one-line patch in the
end. Xattr with prefixes like trusted.* need a bit more work but this
can be woven in as well
(https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
For virtualizing the xattrs on the 'value' side I was looking for
whether there's something like a 'wrapper' structure around the actual
value of the xattr so that that wrapper could be extended to support
different values at different uids and applied to any xattr.
Unfortunately there's no such 'wrapper'.
Stefan
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:33 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 17:33 UTC (permalink / raw)
To: linux-security-module
On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
> Theodore Ts'o <tytso@mit.edu> writes:
>
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo at uid=15000
>>
>> It's not like there will be:
>>
>> security.foo at uid=1000
>> security.foo at uid=2000
>>
>> Except.... if you have an Distribution root directory which is shared
>> by many containers, you would need to put the xattrs in the overlay
>> inodes. Worse, each time you launch a new container, with a new
>> subuid allocation, you will have to iterate over all files with
>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> So that's actually a bit of a disaster.
>>
>> So for distribution overlays, you will need to do things a different
>> way, which is to map the distro subdirectory so you know that the
>> capability with the global uid 0 should be used for the container
>> "root" uid, right?
>>
>> So this hack of using security.foo at uid=1000 is *only* useful when the
>> subcontainer root wants to create the privileged executable. You
>> still have to do things the other way.
>>
>> So can we make perhaps the assertion that *either*:
>>
>> security.foo
>>
>> exists, *or*
>>
>> security.foo at uid=BAR
>>
>> exists, but never both? And there BAR is exclusive to only one
>> instances?
>>
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
> Yep. That is what it looks like from here.
>
> Which is why I asked the question about scalability of the xattr
> implementations. It looks like trying to accomodate the general
> case just gets us in trouble, and sets unrealistic expectations.
>
> Which strongly suggests that Serge's previous version that
> just reved the format of security.capable so that a uid field could
> be added is likely to be the better approach.
>
> I want to see what Serge and Stefan have to say but the case looks
> pretty clear cut at the moment.
The approach of virtualizing the xattrs on the name-side, which is what
this patch does, provides a more general approach than to virtualizing
it on the value side, which is what Serge does in his other patch for
security.capability alone. With the virtualizing on-the-value side
virtualizing the xattr becomes an exercise that needs to be repeated for
every xattr name that one would want to virtualize. With this patch you
would just add another xattr name to a list, a one-line patch in the
end. Xattr with prefixes like trusted.* need a bit more work but this
can be woven in as well
(https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
For virtualizing the xattrs on the 'value' side I was looking for
whether there's something like a 'wrapper' structure around the actual
value of the xattr so that that wrapper could be extended to support
different values at different uids and applied to any xattr.
Unfortunately there's no such 'wrapper'.
Stefan
>
> Eric
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <847ccb2a-30c0-a94c-df6f-091c8901eaa0-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:33 ` Stefan Berger
(?)
(?)
@ 2017-07-13 17:49 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:49 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> writes:
>>
>>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>>> The concise summary:
>>>>
>>>> Today we have the xattr security.capable that holds a set of
>>>> capabilities that an application gains when executed. AKA setuid root exec
>>>> without actually being setuid root.
>>>>
>>>> User namespaces have the concept of capabilities that are not global but
>>>> are limited to their user namespace. We do not currently have
>>>> filesystem support for this concept.
>>> So correct me if I am wrong; in general, there will only be one
>>> variant of the form:
>>>
>>> security.foo@uid=15000
>>>
>>> It's not like there will be:
>>>
>>> security.foo@uid=1000
>>> security.foo@uid=2000
>>>
>>> Except.... if you have an Distribution root directory which is shared
>>> by many containers, you would need to put the xattrs in the overlay
>>> inodes. Worse, each time you launch a new container, with a new
>>> subuid allocation, you will have to iterate over all files with
>>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>>> So that's actually a bit of a disaster.
>>>
>>> So for distribution overlays, you will need to do things a different
>>> way, which is to map the distro subdirectory so you know that the
>>> capability with the global uid 0 should be used for the container
>>> "root" uid, right?
>>>
>>> So this hack of using security.foo@uid=1000 is *only* useful when the
>>> subcontainer root wants to create the privileged executable. You
>>> still have to do things the other way.
>>>
>>> So can we make perhaps the assertion that *either*:
>>>
>>> security.foo
>>>
>>> exists, *or*
>>>
>>> security.foo@uid=BAR
>>>
>>> exists, but never both? And there BAR is exclusive to only one
>>> instances?
>>>
>>> Otherwise, I suspect that the architecture is going to turn around and
>>> bite us in the *ss eventually, because someone will want to do
>>> something crazy and the solution will not be scalable.
>> Yep. That is what it looks like from here.
>>
>> Which is why I asked the question about scalability of the xattr
>> implementations. It looks like trying to accomodate the general
>> case just gets us in trouble, and sets unrealistic expectations.
>>
>> Which strongly suggests that Serge's previous version that
>> just reved the format of security.capable so that a uid field could
>> be added is likely to be the better approach.
>>
>> I want to see what Serge and Stefan have to say but the case looks
>> pretty clear cut at the moment.
>
> The approach of virtualizing the xattrs on the name-side, which is
> what this patch does, provides a more general approach than to
> virtualizing it on the value side, which is what Serge does in his
> other patch for security.capability alone. With the virtualizing
> on-the-value side virtualizing the xattr becomes an exercise that
> needs to be repeated for every xattr name that one would want to
> virtualize. With this patch you would just add another xattr name to a
> list, a one-line patch in the end. Xattr with prefixes like trusted.*
> need a bit more work but this can be woven in as well
> (https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
Reusable code has merit, as it reduces the maintenance burden.
My big question right now is can you implement Ted's suggested
restriction. Only one security.foo or secuirty.foo@... attribute ?
The maintenance gains are definitely worth taking if they do not
penalize the common case.
> For virtualizing the xattrs on the 'value' side I was looking for
> whether there's something like a 'wrapper' structure around the actual
> value of the xattr so that that wrapper could be extended to support
> different values at different uids and applied to any
> xattr. Unfortunately there's no such 'wrapper'.
Different values at different uids currently appear to be undesirable.
At least for security.capable it does not appear to be useful.
A wrapper structure is also a reasonable suggestion. Put it's magic
number/version code where the existing version code is away we go.
Do you know of cases where we will truly want to have different
attributes for different containers?
The case that I can think of for IMA is that the signatures want to be
conntected to a key that goes with the filesystem image (so not a system
key) but that would not be something that would need to be changed
between containers.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:49 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:49 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4710 bytes --]
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> Theodore Ts'o <tytso@mit.edu> writes:
>>
>>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>>> The concise summary:
>>>>
>>>> Today we have the xattr security.capable that holds a set of
>>>> capabilities that an application gains when executed. AKA setuid root exec
>>>> without actually being setuid root.
>>>>
>>>> User namespaces have the concept of capabilities that are not global but
>>>> are limited to their user namespace. We do not currently have
>>>> filesystem support for this concept.
>>> So correct me if I am wrong; in general, there will only be one
>>> variant of the form:
>>>
>>> security.foo(a)uid=15000
>>>
>>> It's not like there will be:
>>>
>>> security.foo(a)uid=1000
>>> security.foo(a)uid=2000
>>>
>>> Except.... if you have an Distribution root directory which is shared
>>> by many containers, you would need to put the xattrs in the overlay
>>> inodes. Worse, each time you launch a new container, with a new
>>> subuid allocation, you will have to iterate over all files with
>>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>>> So that's actually a bit of a disaster.
>>>
>>> So for distribution overlays, you will need to do things a different
>>> way, which is to map the distro subdirectory so you know that the
>>> capability with the global uid 0 should be used for the container
>>> "root" uid, right?
>>>
>>> So this hack of using security.foo(a)uid=1000 is *only* useful when the
>>> subcontainer root wants to create the privileged executable. You
>>> still have to do things the other way.
>>>
>>> So can we make perhaps the assertion that *either*:
>>>
>>> security.foo
>>>
>>> exists, *or*
>>>
>>> security.foo(a)uid=BAR
>>>
>>> exists, but never both? And there BAR is exclusive to only one
>>> instances?
>>>
>>> Otherwise, I suspect that the architecture is going to turn around and
>>> bite us in the *ss eventually, because someone will want to do
>>> something crazy and the solution will not be scalable.
>> Yep. That is what it looks like from here.
>>
>> Which is why I asked the question about scalability of the xattr
>> implementations. It looks like trying to accomodate the general
>> case just gets us in trouble, and sets unrealistic expectations.
>>
>> Which strongly suggests that Serge's previous version that
>> just reved the format of security.capable so that a uid field could
>> be added is likely to be the better approach.
>>
>> I want to see what Serge and Stefan have to say but the case looks
>> pretty clear cut at the moment.
>
> The approach of virtualizing the xattrs on the name-side, which is
> what this patch does, provides a more general approach than to
> virtualizing it on the value side, which is what Serge does in his
> other patch for security.capability alone. With the virtualizing
> on-the-value side virtualizing the xattr becomes an exercise that
> needs to be repeated for every xattr name that one would want to
> virtualize. With this patch you would just add another xattr name to a
> list, a one-line patch in the end. Xattr with prefixes like trusted.*
> need a bit more work but this can be woven in as well
> (https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
Reusable code has merit, as it reduces the maintenance burden.
My big question right now is can you implement Ted's suggested
restriction. Only one security.foo or secuirty.foo(a)... attribute ?
The maintenance gains are definitely worth taking if they do not
penalize the common case.
> For virtualizing the xattrs on the 'value' side I was looking for
> whether there's something like a 'wrapper' structure around the actual
> value of the xattr so that that wrapper could be extended to support
> different values at different uids and applied to any
> xattr. Unfortunately there's no such 'wrapper'.
Different values at different uids currently appear to be undesirable.
At least for security.capable it does not appear to be useful.
A wrapper structure is also a reasonable suggestion. Put it's magic
number/version code where the existing version code is away we go.
Do you know of cases where we will truly want to have different
attributes for different containers?
The case that I can think of for IMA is that the signatures want to be
conntected to a key that goes with the filesystem image (so not a system
key) but that would not be something that would need to be changed
between containers.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:49 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:49 UTC (permalink / raw)
To: linux-security-module
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> Theodore Ts'o <tytso@mit.edu> writes:
>>
>>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>>> The concise summary:
>>>>
>>>> Today we have the xattr security.capable that holds a set of
>>>> capabilities that an application gains when executed. AKA setuid root exec
>>>> without actually being setuid root.
>>>>
>>>> User namespaces have the concept of capabilities that are not global but
>>>> are limited to their user namespace. We do not currently have
>>>> filesystem support for this concept.
>>> So correct me if I am wrong; in general, there will only be one
>>> variant of the form:
>>>
>>> security.foo at uid=15000
>>>
>>> It's not like there will be:
>>>
>>> security.foo at uid=1000
>>> security.foo at uid=2000
>>>
>>> Except.... if you have an Distribution root directory which is shared
>>> by many containers, you would need to put the xattrs in the overlay
>>> inodes. Worse, each time you launch a new container, with a new
>>> subuid allocation, you will have to iterate over all files with
>>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>>> So that's actually a bit of a disaster.
>>>
>>> So for distribution overlays, you will need to do things a different
>>> way, which is to map the distro subdirectory so you know that the
>>> capability with the global uid 0 should be used for the container
>>> "root" uid, right?
>>>
>>> So this hack of using security.foo at uid=1000 is *only* useful when the
>>> subcontainer root wants to create the privileged executable. You
>>> still have to do things the other way.
>>>
>>> So can we make perhaps the assertion that *either*:
>>>
>>> security.foo
>>>
>>> exists, *or*
>>>
>>> security.foo at uid=BAR
>>>
>>> exists, but never both? And there BAR is exclusive to only one
>>> instances?
>>>
>>> Otherwise, I suspect that the architecture is going to turn around and
>>> bite us in the *ss eventually, because someone will want to do
>>> something crazy and the solution will not be scalable.
>> Yep. That is what it looks like from here.
>>
>> Which is why I asked the question about scalability of the xattr
>> implementations. It looks like trying to accomodate the general
>> case just gets us in trouble, and sets unrealistic expectations.
>>
>> Which strongly suggests that Serge's previous version that
>> just reved the format of security.capable so that a uid field could
>> be added is likely to be the better approach.
>>
>> I want to see what Serge and Stefan have to say but the case looks
>> pretty clear cut at the moment.
>
> The approach of virtualizing the xattrs on the name-side, which is
> what this patch does, provides a more general approach than to
> virtualizing it on the value side, which is what Serge does in his
> other patch for security.capability alone. With the virtualizing
> on-the-value side virtualizing the xattr becomes an exercise that
> needs to be repeated for every xattr name that one would want to
> virtualize. With this patch you would just add another xattr name to a
> list, a one-line patch in the end. Xattr with prefixes like trusted.*
> need a bit more work but this can be woven in as well
> (https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
Reusable code has merit, as it reduces the maintenance burden.
My big question right now is can you implement Ted's suggested
restriction. Only one security.foo or secuirty.foo at ... attribute ?
The maintenance gains are definitely worth taking if they do not
penalize the common case.
> For virtualizing the xattrs on the 'value' side I was looking for
> whether there's something like a 'wrapper' structure around the actual
> value of the xattr so that that wrapper could be extended to support
> different values at different uids and applied to any
> xattr. Unfortunately there's no such 'wrapper'.
Different values at different uids currently appear to be undesirable.
At least for security.capable it does not appear to be useful.
A wrapper structure is also a reasonable suggestion. Put it's magic
number/version code where the existing version code is away we go.
Do you know of cases where we will truly want to have different
attributes for different containers?
The case that I can think of for IMA is that the signatures want to be
conntected to a key that goes with the filesystem image (so not a system
key) but that would not be something that would need to be changed
between containers.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 17:49 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:49 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, Serge E. Hallyn, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> Theodore Ts'o <tytso@mit.edu> writes:
>>
>>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>>> The concise summary:
>>>>
>>>> Today we have the xattr security.capable that holds a set of
>>>> capabilities that an application gains when executed. AKA setuid root exec
>>>> without actually being setuid root.
>>>>
>>>> User namespaces have the concept of capabilities that are not global but
>>>> are limited to their user namespace. We do not currently have
>>>> filesystem support for this concept.
>>> So correct me if I am wrong; in general, there will only be one
>>> variant of the form:
>>>
>>> security.foo@uid=15000
>>>
>>> It's not like there will be:
>>>
>>> security.foo@uid=1000
>>> security.foo@uid=2000
>>>
>>> Except.... if you have an Distribution root directory which is shared
>>> by many containers, you would need to put the xattrs in the overlay
>>> inodes. Worse, each time you launch a new container, with a new
>>> subuid allocation, you will have to iterate over all files with
>>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>>> So that's actually a bit of a disaster.
>>>
>>> So for distribution overlays, you will need to do things a different
>>> way, which is to map the distro subdirectory so you know that the
>>> capability with the global uid 0 should be used for the container
>>> "root" uid, right?
>>>
>>> So this hack of using security.foo@uid=1000 is *only* useful when the
>>> subcontainer root wants to create the privileged executable. You
>>> still have to do things the other way.
>>>
>>> So can we make perhaps the assertion that *either*:
>>>
>>> security.foo
>>>
>>> exists, *or*
>>>
>>> security.foo@uid=BAR
>>>
>>> exists, but never both? And there BAR is exclusive to only one
>>> instances?
>>>
>>> Otherwise, I suspect that the architecture is going to turn around and
>>> bite us in the *ss eventually, because someone will want to do
>>> something crazy and the solution will not be scalable.
>> Yep. That is what it looks like from here.
>>
>> Which is why I asked the question about scalability of the xattr
>> implementations. It looks like trying to accomodate the general
>> case just gets us in trouble, and sets unrealistic expectations.
>>
>> Which strongly suggests that Serge's previous version that
>> just reved the format of security.capable so that a uid field could
>> be added is likely to be the better approach.
>>
>> I want to see what Serge and Stefan have to say but the case looks
>> pretty clear cut at the moment.
>
> The approach of virtualizing the xattrs on the name-side, which is
> what this patch does, provides a more general approach than to
> virtualizing it on the value side, which is what Serge does in his
> other patch for security.capability alone. With the virtualizing
> on-the-value side virtualizing the xattr becomes an exercise that
> needs to be repeated for every xattr name that one would want to
> virtualize. With this patch you would just add another xattr name to a
> list, a one-line patch in the end. Xattr with prefixes like trusted.*
> need a bit more work but this can be woven in as well
> (https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
Reusable code has merit, as it reduces the maintenance burden.
My big question right now is can you implement Ted's suggested
restriction. Only one security.foo or secuirty.foo@... attribute ?
The maintenance gains are definitely worth taking if they do not
penalize the common case.
> For virtualizing the xattrs on the 'value' side I was looking for
> whether there's something like a 'wrapper' structure around the actual
> value of the xattr so that that wrapper could be extended to support
> different values at different uids and applied to any
> xattr. Unfortunately there's no such 'wrapper'.
Different values at different uids currently appear to be undesirable.
At least for security.capable it does not appear to be useful.
A wrapper structure is also a reasonable suggestion. Put it's magic
number/version code where the existing version code is away we go.
Do you know of cases where we will truly want to have different
attributes for different containers?
The case that I can think of for IMA is that the signatures want to be
conntected to a key that goes with the filesystem image (so not a system
key) but that would not be something that would need to be changed
between containers.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:49 ` Eric W. Biederman
@ 2017-07-13 19:48 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 19:48 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stefan Berger, Theodore Ts'o, Serge E. Hallyn, containers,
lkp, linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
> >> Theodore Ts'o <tytso@mit.edu> writes:
> >>
> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> >>>> The concise summary:
> >>>>
> >>>> Today we have the xattr security.capable that holds a set of
> >>>> capabilities that an application gains when executed. AKA setuid root exec
> >>>> without actually being setuid root.
> >>>>
> >>>> User namespaces have the concept of capabilities that are not global but
> >>>> are limited to their user namespace. We do not currently have
> >>>> filesystem support for this concept.
> >>> So correct me if I am wrong; in general, there will only be one
> >>> variant of the form:
> >>>
> >>> security.foo@uid=15000
> >>>
> >>> It's not like there will be:
> >>>
> >>> security.foo@uid=1000
> >>> security.foo@uid=2000
> >>>
> >>> Except.... if you have an Distribution root directory which is shared
> >>> by many containers, you would need to put the xattrs in the overlay
> >>> inodes. Worse, each time you launch a new container, with a new
> >>> subuid allocation, you will have to iterate over all files with
> >>> capabilities and do a copy-up operations on the xattrs in overlayfs.
> >>> So that's actually a bit of a disaster.
> >>>
> >>> So for distribution overlays, you will need to do things a different
> >>> way, which is to map the distro subdirectory so you know that the
> >>> capability with the global uid 0 should be used for the container
> >>> "root" uid, right?
> >>>
> >>> So this hack of using security.foo@uid=1000 is *only* useful when the
> >>> subcontainer root wants to create the privileged executable. You
> >>> still have to do things the other way.
> >>>
> >>> So can we make perhaps the assertion that *either*:
> >>>
> >>> security.foo
> >>>
> >>> exists, *or*
> >>>
> >>> security.foo@uid=BAR
> >>>
> >>> exists, but never both? And there BAR is exclusive to only one
> >>> instances?
> >>>
> >>> Otherwise, I suspect that the architecture is going to turn around and
> >>> bite us in the *ss eventually, because someone will want to do
> >>> something crazy and the solution will not be scalable.
> >> Yep. That is what it looks like from here.
> >>
> >> Which is why I asked the question about scalability of the xattr
> >> implementations. It looks like trying to accomodate the general
> >> case just gets us in trouble, and sets unrealistic expectations.
> >>
> >> Which strongly suggests that Serge's previous version that
> >> just reved the format of security.capable so that a uid field could
> >> be added is likely to be the better approach.
> >>
> >> I want to see what Serge and Stefan have to say but the case looks
> >> pretty clear cut at the moment.
I'm fine with that. Now, we'll be doing the enforcement at xattr
write time, meaning someone *can* come up with an fs image with >1
such xattrs. Which is *fine*, I believe, it won't break anything
security-wise, and our goal is only to stop users from thinking it
is legitimate two write multiple such xattrs, so that they don't later
bug the fs folks like Ted saying "hey why can't I write 1000 of these,
I think that's a bug."
So at xattr write time,
1. if there is already an xattr, and it is either the global
non-namespaced xattr, or it has kuid=X where X is the kuid
mapped to root in a parent of the container, then we refuse
the write
2. if there is already an xattr, and it is for a kuid=X where
X is mapped into the container, then we overwrite the existing
xattr.
At read/use time, we use the rules we have now.
Does that seem reasonable?
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 19:48 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 19:48 UTC (permalink / raw)
To: linux-security-module
Quoting Eric W. Biederman (ebiederm at xmission.com):
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
> >> Theodore Ts'o <tytso@mit.edu> writes:
> >>
> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> >>>> The concise summary:
> >>>>
> >>>> Today we have the xattr security.capable that holds a set of
> >>>> capabilities that an application gains when executed. AKA setuid root exec
> >>>> without actually being setuid root.
> >>>>
> >>>> User namespaces have the concept of capabilities that are not global but
> >>>> are limited to their user namespace. We do not currently have
> >>>> filesystem support for this concept.
> >>> So correct me if I am wrong; in general, there will only be one
> >>> variant of the form:
> >>>
> >>> security.foo at uid=15000
> >>>
> >>> It's not like there will be:
> >>>
> >>> security.foo at uid=1000
> >>> security.foo at uid=2000
> >>>
> >>> Except.... if you have an Distribution root directory which is shared
> >>> by many containers, you would need to put the xattrs in the overlay
> >>> inodes. Worse, each time you launch a new container, with a new
> >>> subuid allocation, you will have to iterate over all files with
> >>> capabilities and do a copy-up operations on the xattrs in overlayfs.
> >>> So that's actually a bit of a disaster.
> >>>
> >>> So for distribution overlays, you will need to do things a different
> >>> way, which is to map the distro subdirectory so you know that the
> >>> capability with the global uid 0 should be used for the container
> >>> "root" uid, right?
> >>>
> >>> So this hack of using security.foo at uid=1000 is *only* useful when the
> >>> subcontainer root wants to create the privileged executable. You
> >>> still have to do things the other way.
> >>>
> >>> So can we make perhaps the assertion that *either*:
> >>>
> >>> security.foo
> >>>
> >>> exists, *or*
> >>>
> >>> security.foo at uid=BAR
> >>>
> >>> exists, but never both? And there BAR is exclusive to only one
> >>> instances?
> >>>
> >>> Otherwise, I suspect that the architecture is going to turn around and
> >>> bite us in the *ss eventually, because someone will want to do
> >>> something crazy and the solution will not be scalable.
> >> Yep. That is what it looks like from here.
> >>
> >> Which is why I asked the question about scalability of the xattr
> >> implementations. It looks like trying to accomodate the general
> >> case just gets us in trouble, and sets unrealistic expectations.
> >>
> >> Which strongly suggests that Serge's previous version that
> >> just reved the format of security.capable so that a uid field could
> >> be added is likely to be the better approach.
> >>
> >> I want to see what Serge and Stefan have to say but the case looks
> >> pretty clear cut at the moment.
I'm fine with that. Now, we'll be doing the enforcement at xattr
write time, meaning someone *can* come up with an fs image with >1
such xattrs. Which is *fine*, I believe, it won't break anything
security-wise, and our goal is only to stop users from thinking it
is legitimate two write multiple such xattrs, so that they don't later
bug the fs folks like Ted saying "hey why can't I write 1000 of these,
I think that's a bug."
So at xattr write time,
1. if there is already an xattr, and it is either the global
non-namespaced xattr, or it has kuid=X where X is the kuid
mapped to root in a parent of the container, then we refuse
the write
2. if there is already an xattr, and it is for a kuid=X where
X is mapped into the container, then we overwrite the existing
xattr.
At read/use time, we use the rules we have now.
Does that seem reasonable?
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 19:48 ` Serge E. Hallyn
(?)
@ 2017-07-13 21:12 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 21:12 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Stefan Berger, Theodore Ts'o, containers, lkp, linux-kernel,
zohar, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> >> Theodore Ts'o <tytso@mit.edu> writes:
>> >>
>> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> >>>> The concise summary:
>> >>>>
>> >>>> Today we have the xattr security.capable that holds a set of
>> >>>> capabilities that an application gains when executed. AKA setuid root exec
>> >>>> without actually being setuid root.
>> >>>>
>> >>>> User namespaces have the concept of capabilities that are not global but
>> >>>> are limited to their user namespace. We do not currently have
>> >>>> filesystem support for this concept.
>> >>> So correct me if I am wrong; in general, there will only be one
>> >>> variant of the form:
>> >>>
>> >>> security.foo@uid=15000
>> >>>
>> >>> It's not like there will be:
>> >>>
>> >>> security.foo@uid=1000
>> >>> security.foo@uid=2000
>> >>>
>> >>> Except.... if you have an Distribution root directory which is shared
>> >>> by many containers, you would need to put the xattrs in the overlay
>> >>> inodes. Worse, each time you launch a new container, with a new
>> >>> subuid allocation, you will have to iterate over all files with
>> >>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> >>> So that's actually a bit of a disaster.
>> >>>
>> >>> So for distribution overlays, you will need to do things a different
>> >>> way, which is to map the distro subdirectory so you know that the
>> >>> capability with the global uid 0 should be used for the container
>> >>> "root" uid, right?
>> >>>
>> >>> So this hack of using security.foo@uid=1000 is *only* useful when the
>> >>> subcontainer root wants to create the privileged executable. You
>> >>> still have to do things the other way.
>> >>>
>> >>> So can we make perhaps the assertion that *either*:
>> >>>
>> >>> security.foo
>> >>>
>> >>> exists, *or*
>> >>>
>> >>> security.foo@uid=BAR
>> >>>
>> >>> exists, but never both? And there BAR is exclusive to only one
>> >>> instances?
>> >>>
>> >>> Otherwise, I suspect that the architecture is going to turn around and
>> >>> bite us in the *ss eventually, because someone will want to do
>> >>> something crazy and the solution will not be scalable.
>> >> Yep. That is what it looks like from here.
>> >>
>> >> Which is why I asked the question about scalability of the xattr
>> >> implementations. It looks like trying to accomodate the general
>> >> case just gets us in trouble, and sets unrealistic expectations.
>> >>
>> >> Which strongly suggests that Serge's previous version that
>> >> just reved the format of security.capable so that a uid field could
>> >> be added is likely to be the better approach.
>> >>
>> >> I want to see what Serge and Stefan have to say but the case looks
>> >> pretty clear cut at the moment.
>
> I'm fine with that. Now, we'll be doing the enforcement at xattr
> write time, meaning someone *can* come up with an fs image with >1
> such xattrs. Which is *fine*, I believe, it won't break anything
> security-wise, and our goal is only to stop users from thinking it
> is legitimate two write multiple such xattrs, so that they don't later
> bug the fs folks like Ted saying "hey why can't I write 1000 of these,
> I think that's a bug."
>
> So at xattr write time,
>
> 1. if there is already an xattr, and it is either the global
> non-namespaced xattr, or it has kuid=X where X is the kuid
> mapped to root in a parent of the container, then we refuse
> the write
> 2. if there is already an xattr, and it is for a kuid=X where
> X is mapped into the container, then we overwrite the existing
> xattr.
>
> At read/use time, we use the rules we have now.
>
> Does that seem reasonable?
That sounds like it would keep us to one xattr of any given type so yes.
It occurs to me while I am writing this that this is also important
for ima/evm. There is an xattr that has a hash of all of the other
security relevant xattrs. Without a limit on the number of xattrs
calculating that security xattr could become time prohibitive.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 21:12 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 21:12 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4340 bytes --]
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm(a)xmission.com):
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> >> Theodore Ts'o <tytso@mit.edu> writes:
>> >>
>> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> >>>> The concise summary:
>> >>>>
>> >>>> Today we have the xattr security.capable that holds a set of
>> >>>> capabilities that an application gains when executed. AKA setuid root exec
>> >>>> without actually being setuid root.
>> >>>>
>> >>>> User namespaces have the concept of capabilities that are not global but
>> >>>> are limited to their user namespace. We do not currently have
>> >>>> filesystem support for this concept.
>> >>> So correct me if I am wrong; in general, there will only be one
>> >>> variant of the form:
>> >>>
>> >>> security.foo(a)uid=15000
>> >>>
>> >>> It's not like there will be:
>> >>>
>> >>> security.foo(a)uid=1000
>> >>> security.foo(a)uid=2000
>> >>>
>> >>> Except.... if you have an Distribution root directory which is shared
>> >>> by many containers, you would need to put the xattrs in the overlay
>> >>> inodes. Worse, each time you launch a new container, with a new
>> >>> subuid allocation, you will have to iterate over all files with
>> >>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> >>> So that's actually a bit of a disaster.
>> >>>
>> >>> So for distribution overlays, you will need to do things a different
>> >>> way, which is to map the distro subdirectory so you know that the
>> >>> capability with the global uid 0 should be used for the container
>> >>> "root" uid, right?
>> >>>
>> >>> So this hack of using security.foo(a)uid=1000 is *only* useful when the
>> >>> subcontainer root wants to create the privileged executable. You
>> >>> still have to do things the other way.
>> >>>
>> >>> So can we make perhaps the assertion that *either*:
>> >>>
>> >>> security.foo
>> >>>
>> >>> exists, *or*
>> >>>
>> >>> security.foo(a)uid=BAR
>> >>>
>> >>> exists, but never both? And there BAR is exclusive to only one
>> >>> instances?
>> >>>
>> >>> Otherwise, I suspect that the architecture is going to turn around and
>> >>> bite us in the *ss eventually, because someone will want to do
>> >>> something crazy and the solution will not be scalable.
>> >> Yep. That is what it looks like from here.
>> >>
>> >> Which is why I asked the question about scalability of the xattr
>> >> implementations. It looks like trying to accomodate the general
>> >> case just gets us in trouble, and sets unrealistic expectations.
>> >>
>> >> Which strongly suggests that Serge's previous version that
>> >> just reved the format of security.capable so that a uid field could
>> >> be added is likely to be the better approach.
>> >>
>> >> I want to see what Serge and Stefan have to say but the case looks
>> >> pretty clear cut at the moment.
>
> I'm fine with that. Now, we'll be doing the enforcement at xattr
> write time, meaning someone *can* come up with an fs image with >1
> such xattrs. Which is *fine*, I believe, it won't break anything
> security-wise, and our goal is only to stop users from thinking it
> is legitimate two write multiple such xattrs, so that they don't later
> bug the fs folks like Ted saying "hey why can't I write 1000 of these,
> I think that's a bug."
>
> So at xattr write time,
>
> 1. if there is already an xattr, and it is either the global
> non-namespaced xattr, or it has kuid=X where X is the kuid
> mapped to root in a parent of the container, then we refuse
> the write
> 2. if there is already an xattr, and it is for a kuid=X where
> X is mapped into the container, then we overwrite the existing
> xattr.
>
> At read/use time, we use the rules we have now.
>
> Does that seem reasonable?
That sounds like it would keep us to one xattr of any given type so yes.
It occurs to me while I am writing this that this is also important
for ima/evm. There is an xattr that has a hash of all of the other
security relevant xattrs. Without a limit on the number of xattrs
calculating that security xattr could become time prohibitive.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 21:12 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 21:12 UTC (permalink / raw)
To: linux-security-module
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> >> Theodore Ts'o <tytso@mit.edu> writes:
>> >>
>> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> >>>> The concise summary:
>> >>>>
>> >>>> Today we have the xattr security.capable that holds a set of
>> >>>> capabilities that an application gains when executed. AKA setuid root exec
>> >>>> without actually being setuid root.
>> >>>>
>> >>>> User namespaces have the concept of capabilities that are not global but
>> >>>> are limited to their user namespace. We do not currently have
>> >>>> filesystem support for this concept.
>> >>> So correct me if I am wrong; in general, there will only be one
>> >>> variant of the form:
>> >>>
>> >>> security.foo at uid=15000
>> >>>
>> >>> It's not like there will be:
>> >>>
>> >>> security.foo at uid=1000
>> >>> security.foo at uid=2000
>> >>>
>> >>> Except.... if you have an Distribution root directory which is shared
>> >>> by many containers, you would need to put the xattrs in the overlay
>> >>> inodes. Worse, each time you launch a new container, with a new
>> >>> subuid allocation, you will have to iterate over all files with
>> >>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> >>> So that's actually a bit of a disaster.
>> >>>
>> >>> So for distribution overlays, you will need to do things a different
>> >>> way, which is to map the distro subdirectory so you know that the
>> >>> capability with the global uid 0 should be used for the container
>> >>> "root" uid, right?
>> >>>
>> >>> So this hack of using security.foo at uid=1000 is *only* useful when the
>> >>> subcontainer root wants to create the privileged executable. You
>> >>> still have to do things the other way.
>> >>>
>> >>> So can we make perhaps the assertion that *either*:
>> >>>
>> >>> security.foo
>> >>>
>> >>> exists, *or*
>> >>>
>> >>> security.foo at uid=BAR
>> >>>
>> >>> exists, but never both? And there BAR is exclusive to only one
>> >>> instances?
>> >>>
>> >>> Otherwise, I suspect that the architecture is going to turn around and
>> >>> bite us in the *ss eventually, because someone will want to do
>> >>> something crazy and the solution will not be scalable.
>> >> Yep. That is what it looks like from here.
>> >>
>> >> Which is why I asked the question about scalability of the xattr
>> >> implementations. It looks like trying to accomodate the general
>> >> case just gets us in trouble, and sets unrealistic expectations.
>> >>
>> >> Which strongly suggests that Serge's previous version that
>> >> just reved the format of security.capable so that a uid field could
>> >> be added is likely to be the better approach.
>> >>
>> >> I want to see what Serge and Stefan have to say but the case looks
>> >> pretty clear cut at the moment.
>
> I'm fine with that. Now, we'll be doing the enforcement at xattr
> write time, meaning someone *can* come up with an fs image with >1
> such xattrs. Which is *fine*, I believe, it won't break anything
> security-wise, and our goal is only to stop users from thinking it
> is legitimate two write multiple such xattrs, so that they don't later
> bug the fs folks like Ted saying "hey why can't I write 1000 of these,
> I think that's a bug."
>
> So at xattr write time,
>
> 1. if there is already an xattr, and it is either the global
> non-namespaced xattr, or it has kuid=X where X is the kuid
> mapped to root in a parent of the container, then we refuse
> the write
> 2. if there is already an xattr, and it is for a kuid=X where
> X is mapped into the container, then we overwrite the existing
> xattr.
>
> At read/use time, we use the rules we have now.
>
> Does that seem reasonable?
That sounds like it would keep us to one xattr of any given type so yes.
It occurs to me while I am writing this that this is also important
for ima/evm. There is an xattr that has a hash of all of the other
security relevant xattrs. Without a limit on the number of xattrs
calculating that security xattr could become time prohibitive.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170713194842.GB4895-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170713194842.GB4895-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
@ 2017-07-13 21:12 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 21:12 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>>
>> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> >> Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> writes:
>> >>
>> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> >>>> The concise summary:
>> >>>>
>> >>>> Today we have the xattr security.capable that holds a set of
>> >>>> capabilities that an application gains when executed. AKA setuid root exec
>> >>>> without actually being setuid root.
>> >>>>
>> >>>> User namespaces have the concept of capabilities that are not global but
>> >>>> are limited to their user namespace. We do not currently have
>> >>>> filesystem support for this concept.
>> >>> So correct me if I am wrong; in general, there will only be one
>> >>> variant of the form:
>> >>>
>> >>> security.foo@uid=15000
>> >>>
>> >>> It's not like there will be:
>> >>>
>> >>> security.foo@uid=1000
>> >>> security.foo@uid=2000
>> >>>
>> >>> Except.... if you have an Distribution root directory which is shared
>> >>> by many containers, you would need to put the xattrs in the overlay
>> >>> inodes. Worse, each time you launch a new container, with a new
>> >>> subuid allocation, you will have to iterate over all files with
>> >>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> >>> So that's actually a bit of a disaster.
>> >>>
>> >>> So for distribution overlays, you will need to do things a different
>> >>> way, which is to map the distro subdirectory so you know that the
>> >>> capability with the global uid 0 should be used for the container
>> >>> "root" uid, right?
>> >>>
>> >>> So this hack of using security.foo@uid=1000 is *only* useful when the
>> >>> subcontainer root wants to create the privileged executable. You
>> >>> still have to do things the other way.
>> >>>
>> >>> So can we make perhaps the assertion that *either*:
>> >>>
>> >>> security.foo
>> >>>
>> >>> exists, *or*
>> >>>
>> >>> security.foo@uid=BAR
>> >>>
>> >>> exists, but never both? And there BAR is exclusive to only one
>> >>> instances?
>> >>>
>> >>> Otherwise, I suspect that the architecture is going to turn around and
>> >>> bite us in the *ss eventually, because someone will want to do
>> >>> something crazy and the solution will not be scalable.
>> >> Yep. That is what it looks like from here.
>> >>
>> >> Which is why I asked the question about scalability of the xattr
>> >> implementations. It looks like trying to accomodate the general
>> >> case just gets us in trouble, and sets unrealistic expectations.
>> >>
>> >> Which strongly suggests that Serge's previous version that
>> >> just reved the format of security.capable so that a uid field could
>> >> be added is likely to be the better approach.
>> >>
>> >> I want to see what Serge and Stefan have to say but the case looks
>> >> pretty clear cut at the moment.
>
> I'm fine with that. Now, we'll be doing the enforcement at xattr
> write time, meaning someone *can* come up with an fs image with >1
> such xattrs. Which is *fine*, I believe, it won't break anything
> security-wise, and our goal is only to stop users from thinking it
> is legitimate two write multiple such xattrs, so that they don't later
> bug the fs folks like Ted saying "hey why can't I write 1000 of these,
> I think that's a bug."
>
> So at xattr write time,
>
> 1. if there is already an xattr, and it is either the global
> non-namespaced xattr, or it has kuid=X where X is the kuid
> mapped to root in a parent of the container, then we refuse
> the write
> 2. if there is already an xattr, and it is for a kuid=X where
> X is mapped into the container, then we overwrite the existing
> xattr.
>
> At read/use time, we use the rules we have now.
>
> Does that seem reasonable?
That sounds like it would keep us to one xattr of any given type so yes.
It occurs to me while I am writing this that this is also important
for ima/evm. There is an xattr that has a hash of all of the other
security relevant xattrs. Without a limit on the number of xattrs
calculating that security xattr could become time prohibitive.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <87bmoo8bxb.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <87bmoo8bxb.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2017-07-13 19:48 ` Serge E. Hallyn
2017-07-13 21:35 ` Stefan Berger
1 sibling, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 19:48 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>
> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
> >> Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> writes:
> >>
> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> >>>> The concise summary:
> >>>>
> >>>> Today we have the xattr security.capable that holds a set of
> >>>> capabilities that an application gains when executed. AKA setuid root exec
> >>>> without actually being setuid root.
> >>>>
> >>>> User namespaces have the concept of capabilities that are not global but
> >>>> are limited to their user namespace. We do not currently have
> >>>> filesystem support for this concept.
> >>> So correct me if I am wrong; in general, there will only be one
> >>> variant of the form:
> >>>
> >>> security.foo@uid=15000
> >>>
> >>> It's not like there will be:
> >>>
> >>> security.foo@uid=1000
> >>> security.foo@uid=2000
> >>>
> >>> Except.... if you have an Distribution root directory which is shared
> >>> by many containers, you would need to put the xattrs in the overlay
> >>> inodes. Worse, each time you launch a new container, with a new
> >>> subuid allocation, you will have to iterate over all files with
> >>> capabilities and do a copy-up operations on the xattrs in overlayfs.
> >>> So that's actually a bit of a disaster.
> >>>
> >>> So for distribution overlays, you will need to do things a different
> >>> way, which is to map the distro subdirectory so you know that the
> >>> capability with the global uid 0 should be used for the container
> >>> "root" uid, right?
> >>>
> >>> So this hack of using security.foo@uid=1000 is *only* useful when the
> >>> subcontainer root wants to create the privileged executable. You
> >>> still have to do things the other way.
> >>>
> >>> So can we make perhaps the assertion that *either*:
> >>>
> >>> security.foo
> >>>
> >>> exists, *or*
> >>>
> >>> security.foo@uid=BAR
> >>>
> >>> exists, but never both? And there BAR is exclusive to only one
> >>> instances?
> >>>
> >>> Otherwise, I suspect that the architecture is going to turn around and
> >>> bite us in the *ss eventually, because someone will want to do
> >>> something crazy and the solution will not be scalable.
> >> Yep. That is what it looks like from here.
> >>
> >> Which is why I asked the question about scalability of the xattr
> >> implementations. It looks like trying to accomodate the general
> >> case just gets us in trouble, and sets unrealistic expectations.
> >>
> >> Which strongly suggests that Serge's previous version that
> >> just reved the format of security.capable so that a uid field could
> >> be added is likely to be the better approach.
> >>
> >> I want to see what Serge and Stefan have to say but the case looks
> >> pretty clear cut at the moment.
I'm fine with that. Now, we'll be doing the enforcement at xattr
write time, meaning someone *can* come up with an fs image with >1
such xattrs. Which is *fine*, I believe, it won't break anything
security-wise, and our goal is only to stop users from thinking it
is legitimate two write multiple such xattrs, so that they don't later
bug the fs folks like Ted saying "hey why can't I write 1000 of these,
I think that's a bug."
So at xattr write time,
1. if there is already an xattr, and it is either the global
non-namespaced xattr, or it has kuid=X where X is the kuid
mapped to root in a parent of the container, then we refuse
the write
2. if there is already an xattr, and it is for a kuid=X where
X is mapped into the container, then we overwrite the existing
xattr.
At read/use time, we use the rules we have now.
Does that seem reasonable?
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:49 ` Eric W. Biederman
@ 2017-07-13 21:35 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 21:35 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>
>> On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>>> Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> writes:
>>>
>>>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>>>> The concise summary:
>>>>>
>>>>> Today we have the xattr security.capable that holds a set of
>>>>> capabilities that an application gains when executed. AKA setuid root exec
>>>>> without actually being setuid root.
>>>>>
>>>>> User namespaces have the concept of capabilities that are not global but
>>>>> are limited to their user namespace. We do not currently have
>>>>> filesystem support for this concept.
>>>> So correct me if I am wrong; in general, there will only be one
>>>> variant of the form:
>>>>
>>>> security.foo@uid=15000
>>>>
>>>> It's not like there will be:
>>>>
>>>> security.foo@uid=1000
>>>> security.foo@uid=2000
>>>>
>>>> Except.... if you have an Distribution root directory which is shared
>>>> by many containers, you would need to put the xattrs in the overlay
>>>> inodes. Worse, each time you launch a new container, with a new
>>>> subuid allocation, you will have to iterate over all files with
>>>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>>>> So that's actually a bit of a disaster.
>>>>
>>>> So for distribution overlays, you will need to do things a different
>>>> way, which is to map the distro subdirectory so you know that the
>>>> capability with the global uid 0 should be used for the container
>>>> "root" uid, right?
>>>>
>>>> So this hack of using security.foo@uid=1000 is *only* useful when the
>>>> subcontainer root wants to create the privileged executable. You
>>>> still have to do things the other way.
>>>>
>>>> So can we make perhaps the assertion that *either*:
>>>>
>>>> security.foo
>>>>
>>>> exists, *or*
>>>>
>>>> security.foo@uid=BAR
>>>>
>>>> exists, but never both? And there BAR is exclusive to only one
>>>> instances?
>>>>
>>>> Otherwise, I suspect that the architecture is going to turn around and
>>>> bite us in the *ss eventually, because someone will want to do
>>>> something crazy and the solution will not be scalable.
>>> Yep. That is what it looks like from here.
>>>
>>> Which is why I asked the question about scalability of the xattr
>>> implementations. It looks like trying to accomodate the general
>>> case just gets us in trouble, and sets unrealistic expectations.
>>>
>>> Which strongly suggests that Serge's previous version that
>>> just reved the format of security.capable so that a uid field could
>>> be added is likely to be the better approach.
>>>
>>> I want to see what Serge and Stefan have to say but the case looks
>>> pretty clear cut at the moment.
>> The approach of virtualizing the xattrs on the name-side, which is
>> what this patch does, provides a more general approach than to
>> virtualizing it on the value side, which is what Serge does in his
>> other patch for security.capability alone. With the virtualizing
>> on-the-value side virtualizing the xattr becomes an exercise that
>> needs to be repeated for every xattr name that one would want to
>> virtualize. With this patch you would just add another xattr name to a
>> list, a one-line patch in the end. Xattr with prefixes like trusted.*
>> need a bit more work but this can be woven in as well
>> (https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
> Reusable code has merit, as it reduces the maintenance burden.
>
> My big question right now is can you implement Ted's suggested
> restriction. Only one security.foo or secuirty.foo@... attribute ?
We need to raw-list the xattrs and do the check before writing them. I
am fairly sure this can be done.
So now you want to allow security.foo *and one* security.foo@uid=<> or
just a single one security.foo(@[[:print:]]*)?
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 21:35 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 21:35 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4047 bytes --]
On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>>> Theodore Ts'o <tytso@mit.edu> writes:
>>>
>>>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>>>> The concise summary:
>>>>>
>>>>> Today we have the xattr security.capable that holds a set of
>>>>> capabilities that an application gains when executed. AKA setuid root exec
>>>>> without actually being setuid root.
>>>>>
>>>>> User namespaces have the concept of capabilities that are not global but
>>>>> are limited to their user namespace. We do not currently have
>>>>> filesystem support for this concept.
>>>> So correct me if I am wrong; in general, there will only be one
>>>> variant of the form:
>>>>
>>>> security.foo(a)uid=15000
>>>>
>>>> It's not like there will be:
>>>>
>>>> security.foo(a)uid=1000
>>>> security.foo(a)uid=2000
>>>>
>>>> Except.... if you have an Distribution root directory which is shared
>>>> by many containers, you would need to put the xattrs in the overlay
>>>> inodes. Worse, each time you launch a new container, with a new
>>>> subuid allocation, you will have to iterate over all files with
>>>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>>>> So that's actually a bit of a disaster.
>>>>
>>>> So for distribution overlays, you will need to do things a different
>>>> way, which is to map the distro subdirectory so you know that the
>>>> capability with the global uid 0 should be used for the container
>>>> "root" uid, right?
>>>>
>>>> So this hack of using security.foo(a)uid=1000 is *only* useful when the
>>>> subcontainer root wants to create the privileged executable. You
>>>> still have to do things the other way.
>>>>
>>>> So can we make perhaps the assertion that *either*:
>>>>
>>>> security.foo
>>>>
>>>> exists, *or*
>>>>
>>>> security.foo(a)uid=BAR
>>>>
>>>> exists, but never both? And there BAR is exclusive to only one
>>>> instances?
>>>>
>>>> Otherwise, I suspect that the architecture is going to turn around and
>>>> bite us in the *ss eventually, because someone will want to do
>>>> something crazy and the solution will not be scalable.
>>> Yep. That is what it looks like from here.
>>>
>>> Which is why I asked the question about scalability of the xattr
>>> implementations. It looks like trying to accomodate the general
>>> case just gets us in trouble, and sets unrealistic expectations.
>>>
>>> Which strongly suggests that Serge's previous version that
>>> just reved the format of security.capable so that a uid field could
>>> be added is likely to be the better approach.
>>>
>>> I want to see what Serge and Stefan have to say but the case looks
>>> pretty clear cut at the moment.
>> The approach of virtualizing the xattrs on the name-side, which is
>> what this patch does, provides a more general approach than to
>> virtualizing it on the value side, which is what Serge does in his
>> other patch for security.capability alone. With the virtualizing
>> on-the-value side virtualizing the xattr becomes an exercise that
>> needs to be repeated for every xattr name that one would want to
>> virtualize. With this patch you would just add another xattr name to a
>> list, a one-line patch in the end. Xattr with prefixes like trusted.*
>> need a bit more work but this can be woven in as well
>> (https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
> Reusable code has merit, as it reduces the maintenance burden.
>
> My big question right now is can you implement Ted's suggested
> restriction. Only one security.foo or secuirty.foo(a)... attribute ?
We need to raw-list the xattrs and do the check before writing them. I
am fairly sure this can be done.
So now you want to allow security.foo *and one* security.foo(a)uid=<> or
just a single one security.foo(@[[:print:]]*)?
Stefan
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4764 bytes --]
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-14 0:38 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 0:38 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>
> > My big question right now is can you implement Ted's suggested
> > restriction. Only one security.foo or secuirty.foo@... attribute ?
> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>
> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>
The latter.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 21:35 ` Stefan Berger
(?)
@ 2017-07-14 0:38 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 0:38 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, Serge E. Hallyn, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>
> > My big question right now is can you implement Ted's suggested
> > restriction. Only one security.foo or secuirty.foo@... attribute ?
> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>
> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>
The latter.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 0:38 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 0:38 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>
> > My big question right now is can you implement Ted's suggested
> > restriction. Only one security.foo or secuirty.foo(a)... attribute ?
> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>
> So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>
The latter.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 0:38 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 0:38 UTC (permalink / raw)
To: linux-security-module
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>
> > My big question right now is can you implement Ted's suggested
> > restriction. Only one security.foo or secuirty.foo at ... attribute ?
> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>
> So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>
The latter.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <87h8yf7szd.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <87h8yf7szd.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2017-07-14 11:32 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 11:32 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>
>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>
>>> My big question right now is can you implement Ted's suggested
>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>
>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>
> The latter.
That case would prevent a container user from overriding the xattr on
the host. Is that what we want? For limiting the number of xattrs and
getting that functionality (override IMA signature for example) the
former seems better...
For the former I now have the topmost patch here:
https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Stefan
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 0:38 ` Eric W. Biederman
(?)
@ 2017-07-14 11:32 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 11:32 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, Serge E. Hallyn, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>
>>> My big question right now is can you implement Ted's suggested
>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>
>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>
> The latter.
That case would prevent a container user from overriding the xattr on
the host. Is that what we want? For limiting the number of xattrs and
getting that functionality (override IMA signature for example) the
former seems better...
For the former I now have the topmost patch here:
https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Stefan
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 11:32 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 11:32 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>
>>> My big question right now is can you implement Ted's suggested
>>> restriction. Only one security.foo or secuirty.foo(a)... attribute ?
>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>
>> So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>>
> The latter.
That case would prevent a container user from overriding the xattr on
the host. Is that what we want? For limiting the number of xattrs and
getting that functionality (override IMA signature for example) the
former seems better...
For the former I now have the topmost patch here:
https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Stefan
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 11:32 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 11:32 UTC (permalink / raw)
To: linux-security-module
On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>
>>> My big question right now is can you implement Ted's suggested
>>> restriction. Only one security.foo or secuirty.foo at ... attribute ?
>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>
>> So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>>
> The latter.
That case would prevent a container user from overriding the xattr on
the host. Is that what we want? For limiting the number of xattrs and
getting that functionality (override IMA signature for example) the
former seems better...
For the former I now have the topmost patch here:
https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Stefan
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 11:32 ` Stefan Berger
@ 2017-07-14 13:34 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-14 13:34 UTC (permalink / raw)
To: Stefan Berger
Cc: Eric W. Biederman, Theodore Ts'o, Serge E. Hallyn,
containers, lkp, linux-kernel, zohar, tycho, James.Bottomley,
vgoyal, christian.brauner, amir73il, linux-security-module,
casey
Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >
> >>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >>
> >>>My big question right now is can you implement Ted's suggested
> >>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> >>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >>
> >>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> >>
> >The latter.
>
> That case would prevent a container user from overriding the xattr
> on the host. Is that what we want? For limiting the number of xattrs
Not really. If the file is owned by a uid mapped into the container,
then the container root can chown the file which will clear the file
capability, after which he can set a new one. If the file is not
owned by a uid mapped into the container, then container root could
not set a filecap anyway.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 13:34 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-14 13:34 UTC (permalink / raw)
To: linux-security-module
Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >
> >>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >>
> >>>My big question right now is can you implement Ted's suggested
> >>>restriction. Only one security.foo or secuirty.foo at ... attribute ?
> >>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >>
> >>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
> >>
> >The latter.
>
> That case would prevent a container user from overriding the xattr
> on the host. Is that what we want? For limiting the number of xattrs
Not really. If the file is owned by a uid mapped into the container,
then the container root can chown the file which will clear the file
capability, after which he can set a new one. If the file is not
owned by a uid mapped into the container, then container root could
not set a filecap anyway.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 13:34 ` Serge E. Hallyn
(?)
@ 2017-07-14 15:22 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 15:22 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Eric W. Biederman, Theodore Ts'o, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr
>> on the host. Is that what we want? For limiting the number of xattrs
> Not really. If the file is owned by a uid mapped into the container,
> then the container root can chown the file which will clear the file
> capability, after which he can set a new one. If the file is not
> owned by a uid mapped into the container, then container root could
> not set a filecap anyway.
Let's say I installed a container where all files are signed and thus
have security.ima. Now for some reason I want to re-sign some or all
files inside that container. How would I do that ? Would I need to get
rid of security.ima first, possibly by copying each file, deleting the
original file, and renaming the copied file to the original name, or
should I just be able to write out a new signature, thus creating
security.ima@uid=1000 besides the security.ima ?
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 15:22 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 15:22 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]
On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo(a)... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr
>> on the host. Is that what we want? For limiting the number of xattrs
> Not really. If the file is owned by a uid mapped into the container,
> then the container root can chown the file which will clear the file
> capability, after which he can set a new one. If the file is not
> owned by a uid mapped into the container, then container root could
> not set a filecap anyway.
Let's say I installed a container where all files are signed and thus
have security.ima. Now for some reason I want to re-sign some or all
files inside that container. How would I do that ? Would I need to get
rid of security.ima first, possibly by copying each file, deleting the
original file, and renaming the copied file to the original name, or
should I just be able to write out a new signature, thus creating
security.ima(a)uid=1000 besides the security.ima ?
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 15:22 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 15:22 UTC (permalink / raw)
To: linux-security-module
On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo at ... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr
>> on the host. Is that what we want? For limiting the number of xattrs
> Not really. If the file is owned by a uid mapped into the container,
> then the container root can chown the file which will clear the file
> capability, after which he can set a new one. If the file is not
> owned by a uid mapped into the container, then container root could
> not set a filecap anyway.
Let's say I installed a container where all files are signed and thus
have security.ima. Now for some reason I want to re-sign some or all
files inside that container. How would I do that ? Would I need to get
rid of security.ima first, possibly by copying each file, deleting the
original file, and renaming the copied file to the original name, or
should I just be able to write out a new signature, thus creating
security.ima at uid=1000 besides the security.ima ?
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 15:22 ` Stefan Berger
@ 2017-07-14 17:35 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-14 17:35 UTC (permalink / raw)
To: Stefan Berger, Mimi Zohar
Cc: Serge E. Hallyn, Eric W. Biederman, Theodore Ts'o,
containers, lkp, linux-kernel, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >>>
> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >>>>
> >>>>>My big question right now is can you implement Ted's suggested
> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >>>>
> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> >>>>
> >>>The latter.
> >>That case would prevent a container user from overriding the xattr
> >>on the host. Is that what we want? For limiting the number of xattrs
> >Not really. If the file is owned by a uid mapped into the container,
> >then the container root can chown the file which will clear the file
> >capability, after which he can set a new one. If the file is not
> >owned by a uid mapped into the container, then container root could
> >not set a filecap anyway.
>
> Let's say I installed a container where all files are signed and
> thus have security.ima. Now for some reason I want to re-sign some
> or all files inside that container. How would I do that ? Would I
> need to get rid of security.ima first, possibly by copying each
> file, deleting the original file, and renaming the copied file to
> the original name, or should I just be able to write out a new
> signature, thus creating security.ima@uid=1000 besides the
> security.ima ?
>
> Stefan
Hi Mimi,
what do you think makes most sense for IMA?
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 17:35 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-14 17:35 UTC (permalink / raw)
To: linux-security-module
Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >>>
> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >>>>
> >>>>>My big question right now is can you implement Ted's suggested
> >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ?
> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >>>>
> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
> >>>>
> >>>The latter.
> >>That case would prevent a container user from overriding the xattr
> >>on the host. Is that what we want? For limiting the number of xattrs
> >Not really. If the file is owned by a uid mapped into the container,
> >then the container root can chown the file which will clear the file
> >capability, after which he can set a new one. If the file is not
> >owned by a uid mapped into the container, then container root could
> >not set a filecap anyway.
>
> Let's say I installed a container where all files are signed and
> thus have security.ima. Now for some reason I want to re-sign some
> or all files inside that container. How would I do that ? Would I
> need to get rid of security.ima first, possibly by copying each
> file, deleting the original file, and renaming the copied file to
> the original name, or should I just be able to write out a new
> signature, thus creating security.ima at uid=1000 besides the
> security.ima ?
>
> Stefan
Hi Mimi,
what do you think makes most sense for IMA?
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 17:35 ` Serge E. Hallyn
(?)
@ 2017-07-14 18:17 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 18:17 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Stefan Berger, Mimi Zohar, Theodore Ts'o, containers, lkp,
linux-kernel, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>> >>>
>> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >>>>
>> >>>>>My big question right now is can you implement Ted's suggested
>> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
>> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >>>>
>> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >>>>
>> >>>The latter.
>> >>That case would prevent a container user from overriding the xattr
>> >>on the host. Is that what we want? For limiting the number of xattrs
>> >Not really. If the file is owned by a uid mapped into the container,
>> >then the container root can chown the file which will clear the file
>> >capability, after which he can set a new one. If the file is not
>> >owned by a uid mapped into the container, then container root could
>> >not set a filecap anyway.
>>
>> Let's say I installed a container where all files are signed and
>> thus have security.ima. Now for some reason I want to re-sign some
>> or all files inside that container. How would I do that ? Would I
>> need to get rid of security.ima first, possibly by copying each
>> file, deleting the original file, and renaming the copied file to
>> the original name, or should I just be able to write out a new
>> signature, thus creating security.ima@uid=1000 besides the
>> security.ima ?
>>
>> Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
I am going to give my two cents since I have been thinking about this.
First I think this entire scheme plays hobs with the security.evm
attribute as security.evm needs to know the names of the xattrs to
protect.
I forget which attributes has a hash and what has a message
athentication code.
If there is an attribute with a simple file hash I think it only make
sense for the kernel to touch it, and I don't see any sense in having
multiples.
If there is an attribute with a message authentication code (roughly a
signed hash) it makes sense to have that to be tied to the kernel key
ring that controlls the keys. (Which probably means a per user
namespace thing at some point). But again pretty untouchable otherwise.
Which brings us to the semantic question of would it be nice to have
stacked IMA/EVM on the same file.
I really don't think we do. I think allowing multiple keys for
different part of trusting files is easy enough that we should have no
need to fight over which keys do which.
Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
case I can think of for distributing a distribution image with ima/evm
xattrs will need to use asymmetric keys aka public/private keypairs so
that the originator of the content does not give away their private
keys.
Given that usefully we are talking about content that should be
connected to keys in one way or another I don't believe it even makes
sense at this point to attempt to use uids for dealing with ima and
evm content.
Further looking Serge's previous patch is 300 lines of code Setfan's
patch that provides the possibility of code resuse is 500 lines of code.
Increasingly it is looking to me that code reuse rather than concept
reuse is a false economy. The code does not get smaller. The semantic
differences make it problematic. Possibly to the problematic to the
point where significant pieces may not be reused. The format breaks
assumptions for other parts of the code like security.evm. The format
by multiple names instead of a single attribute requires more disk
access so is less efficient.
In short I am seeing more code that runs slower and is harder to
maintain. Please point out where I am wrong.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 18:17 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 18:17 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4179 bytes --]
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>> >>>
>> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >>>>
>> >>>>>My big question right now is can you implement Ted's suggested
>> >>>>>restriction. Only one security.foo or secuirty.foo(a)... attribute ?
>> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >>>>
>> >>>>So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >>>>
>> >>>The latter.
>> >>That case would prevent a container user from overriding the xattr
>> >>on the host. Is that what we want? For limiting the number of xattrs
>> >Not really. If the file is owned by a uid mapped into the container,
>> >then the container root can chown the file which will clear the file
>> >capability, after which he can set a new one. If the file is not
>> >owned by a uid mapped into the container, then container root could
>> >not set a filecap anyway.
>>
>> Let's say I installed a container where all files are signed and
>> thus have security.ima. Now for some reason I want to re-sign some
>> or all files inside that container. How would I do that ? Would I
>> need to get rid of security.ima first, possibly by copying each
>> file, deleting the original file, and renaming the copied file to
>> the original name, or should I just be able to write out a new
>> signature, thus creating security.ima(a)uid=1000 besides the
>> security.ima ?
>>
>> Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
I am going to give my two cents since I have been thinking about this.
First I think this entire scheme plays hobs with the security.evm
attribute as security.evm needs to know the names of the xattrs to
protect.
I forget which attributes has a hash and what has a message
athentication code.
If there is an attribute with a simple file hash I think it only make
sense for the kernel to touch it, and I don't see any sense in having
multiples.
If there is an attribute with a message authentication code (roughly a
signed hash) it makes sense to have that to be tied to the kernel key
ring that controlls the keys. (Which probably means a per user
namespace thing at some point). But again pretty untouchable otherwise.
Which brings us to the semantic question of would it be nice to have
stacked IMA/EVM on the same file.
I really don't think we do. I think allowing multiple keys for
different part of trusting files is easy enough that we should have no
need to fight over which keys do which.
Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
case I can think of for distributing a distribution image with ima/evm
xattrs will need to use asymmetric keys aka public/private keypairs so
that the originator of the content does not give away their private
keys.
Given that usefully we are talking about content that should be
connected to keys in one way or another I don't believe it even makes
sense at this point to attempt to use uids for dealing with ima and
evm content.
Further looking Serge's previous patch is 300 lines of code Setfan's
patch that provides the possibility of code resuse is 500 lines of code.
Increasingly it is looking to me that code reuse rather than concept
reuse is a false economy. The code does not get smaller. The semantic
differences make it problematic. Possibly to the problematic to the
point where significant pieces may not be reused. The format breaks
assumptions for other parts of the code like security.evm. The format
by multiple names instead of a single attribute requires more disk
access so is less efficient.
In short I am seeing more code that runs slower and is harder to
maintain. Please point out where I am wrong.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 18:17 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 18:17 UTC (permalink / raw)
To: linux-security-module
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
>> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>> >>>
>> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >>>>
>> >>>>>My big question right now is can you implement Ted's suggested
>> >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ?
>> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >>>>
>> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >>>>
>> >>>The latter.
>> >>That case would prevent a container user from overriding the xattr
>> >>on the host. Is that what we want? For limiting the number of xattrs
>> >Not really. If the file is owned by a uid mapped into the container,
>> >then the container root can chown the file which will clear the file
>> >capability, after which he can set a new one. If the file is not
>> >owned by a uid mapped into the container, then container root could
>> >not set a filecap anyway.
>>
>> Let's say I installed a container where all files are signed and
>> thus have security.ima. Now for some reason I want to re-sign some
>> or all files inside that container. How would I do that ? Would I
>> need to get rid of security.ima first, possibly by copying each
>> file, deleting the original file, and renaming the copied file to
>> the original name, or should I just be able to write out a new
>> signature, thus creating security.ima at uid=1000 besides the
>> security.ima ?
>>
>> Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
I am going to give my two cents since I have been thinking about this.
First I think this entire scheme plays hobs with the security.evm
attribute as security.evm needs to know the names of the xattrs to
protect.
I forget which attributes has a hash and what has a message
athentication code.
If there is an attribute with a simple file hash I think it only make
sense for the kernel to touch it, and I don't see any sense in having
multiples.
If there is an attribute with a message authentication code (roughly a
signed hash) it makes sense to have that to be tied to the kernel key
ring that controlls the keys. (Which probably means a per user
namespace thing at some point). But again pretty untouchable otherwise.
Which brings us to the semantic question of would it be nice to have
stacked IMA/EVM on the same file.
I really don't think we do. I think allowing multiple keys for
different part of trusting files is easy enough that we should have no
need to fight over which keys do which.
Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
case I can think of for distributing a distribution image with ima/evm
xattrs will need to use asymmetric keys aka public/private keypairs so
that the originator of the content does not give away their private
keys.
Given that usefully we are talking about content that should be
connected to keys in one way or another I don't believe it even makes
sense at this point to attempt to use uids for dealing with ima and
evm content.
Further looking Serge's previous patch is 300 lines of code Setfan's
patch that provides the possibility of code resuse is 500 lines of code.
Increasingly it is looking to me that code reuse rather than concept
reuse is a false economy. The code does not get smaller. The semantic
differences make it problematic. Possibly to the problematic to the
point where significant pieces may not be reused. The format breaks
assumptions for other parts of the code like security.evm. The format
by multiple names instead of a single attribute requires more disk
access so is less efficient.
In short I am seeing more code that runs slower and is harder to
maintain. Please point out where I am wrong.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170714173556.GA19669-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170714173556.GA19669-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
@ 2017-07-14 18:17 ` Eric W. Biederman
2017-07-14 18:48 ` Mimi Zohar
1 sibling, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 18:17 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Theodore Ts'o, Mimi Zohar,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
> Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
>> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >>>Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>> >>>
>> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >>>>
>> >>>>>My big question right now is can you implement Ted's suggested
>> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
>> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >>>>
>> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >>>>
>> >>>The latter.
>> >>That case would prevent a container user from overriding the xattr
>> >>on the host. Is that what we want? For limiting the number of xattrs
>> >Not really. If the file is owned by a uid mapped into the container,
>> >then the container root can chown the file which will clear the file
>> >capability, after which he can set a new one. If the file is not
>> >owned by a uid mapped into the container, then container root could
>> >not set a filecap anyway.
>>
>> Let's say I installed a container where all files are signed and
>> thus have security.ima. Now for some reason I want to re-sign some
>> or all files inside that container. How would I do that ? Would I
>> need to get rid of security.ima first, possibly by copying each
>> file, deleting the original file, and renaming the copied file to
>> the original name, or should I just be able to write out a new
>> signature, thus creating security.ima@uid=1000 besides the
>> security.ima ?
>>
>> Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
I am going to give my two cents since I have been thinking about this.
First I think this entire scheme plays hobs with the security.evm
attribute as security.evm needs to know the names of the xattrs to
protect.
I forget which attributes has a hash and what has a message
athentication code.
If there is an attribute with a simple file hash I think it only make
sense for the kernel to touch it, and I don't see any sense in having
multiples.
If there is an attribute with a message authentication code (roughly a
signed hash) it makes sense to have that to be tied to the kernel key
ring that controlls the keys. (Which probably means a per user
namespace thing at some point). But again pretty untouchable otherwise.
Which brings us to the semantic question of would it be nice to have
stacked IMA/EVM on the same file.
I really don't think we do. I think allowing multiple keys for
different part of trusting files is easy enough that we should have no
need to fight over which keys do which.
Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
case I can think of for distributing a distribution image with ima/evm
xattrs will need to use asymmetric keys aka public/private keypairs so
that the originator of the content does not give away their private
keys.
Given that usefully we are talking about content that should be
connected to keys in one way or another I don't believe it even makes
sense at this point to attempt to use uids for dealing with ima and
evm content.
Further looking Serge's previous patch is 300 lines of code Setfan's
patch that provides the possibility of code resuse is 500 lines of code.
Increasingly it is looking to me that code reuse rather than concept
reuse is a false economy. The code does not get smaller. The semantic
differences make it problematic. Possibly to the problematic to the
point where significant pieces may not be reused. The format breaks
assumptions for other parts of the code like security.evm. The format
by multiple names instead of a single attribute requires more disk
access so is less efficient.
In short I am seeing more code that runs slower and is harder to
maintain. Please point out where I am wrong.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170714173556.GA19669-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-14 18:17 ` Eric W. Biederman
@ 2017-07-14 18:48 ` Mimi Zohar
1 sibling, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 18:48 UTC (permalink / raw)
To: Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, Theodore Ts'o, lkp-JC7UmRfGjtg
On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> > >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> > >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> > >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> > >>>
> > >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> > >>>>
> > >>>>>My big question right now is can you implement Ted's suggested
> > >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> > >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> > >>>>
> > >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> > >>>>
> > >>>The latter.
> > >>That case would prevent a container user from overriding the xattr
> > >>on the host. Is that what we want? For limiting the number of xattrs
> > >Not really. If the file is owned by a uid mapped into the container,
> > >then the container root can chown the file which will clear the file
> > >capability, after which he can set a new one. If the file is not
> > >owned by a uid mapped into the container, then container root could
> > >not set a filecap anyway.
> >
> > Let's say I installed a container where all files are signed and
> > thus have security.ima. Now for some reason I want to re-sign some
> > or all files inside that container. How would I do that ? Would I
> > need to get rid of security.ima first, possibly by copying each
> > file, deleting the original file, and renaming the copied file to
> > the original name, or should I just be able to write out a new
> > signature, thus creating security.ima@uid=1000 besides the
> > security.ima ?
> >
> > Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
If I'm understanding the discussion correctly, this isn't an issue for
layered copy on write filesystems, as each fs layer could have it's
own set of xattrs. The underlying and layered xattrs should be able
to co-exist. Use the layered xattr if it exists, but fall back to
using the underlying xattr if it doesn't.
The concern is with a shared filesystems. In that case, for IMA it
would make sense to support a native and a namespace xattr. If due to
xattr space limitations we have to limit the number of xattrs, then we
should limit it to two - a native and a namespace version, with a
"uid=" tag - first namespace gets permission to write the namespace
xattr. Again, like in the layered case, if the namespace xattr
doesn't exist, fall back to using the native xattr.
This allows most files to use the underlying xattrs, but allows a few
files to be re-signed inside the namespace, as needed. For the
layered filesystem case, this would allow mutable file hashes to be
written. (Unclear as to how shared filesystems would work in this
case.)
Mimi
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 17:35 ` Serge E. Hallyn
(?)
@ 2017-07-14 18:48 ` Mimi Zohar
-1 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 18:48 UTC (permalink / raw)
To: Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: Eric W. Biederman, Theodore Ts'o, containers, lkp,
linux-kernel, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> > >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> > >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> > >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> > >>>
> > >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> > >>>>
> > >>>>>My big question right now is can you implement Ted's suggested
> > >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> > >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> > >>>>
> > >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> > >>>>
> > >>>The latter.
> > >>That case would prevent a container user from overriding the xattr
> > >>on the host. Is that what we want? For limiting the number of xattrs
> > >Not really. If the file is owned by a uid mapped into the container,
> > >then the container root can chown the file which will clear the file
> > >capability, after which he can set a new one. If the file is not
> > >owned by a uid mapped into the container, then container root could
> > >not set a filecap anyway.
> >
> > Let's say I installed a container where all files are signed and
> > thus have security.ima. Now for some reason I want to re-sign some
> > or all files inside that container. How would I do that ? Would I
> > need to get rid of security.ima first, possibly by copying each
> > file, deleting the original file, and renaming the copied file to
> > the original name, or should I just be able to write out a new
> > signature, thus creating security.ima@uid=1000 besides the
> > security.ima ?
> >
> > Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
If I'm understanding the discussion correctly, this isn't an issue for
layered copy on write filesystems, as each fs layer could have it's
own set of xattrs. The underlying and layered xattrs should be able
to co-exist. Use the layered xattr if it exists, but fall back to
using the underlying xattr if it doesn't.
The concern is with a shared filesystems. In that case, for IMA it
would make sense to support a native and a namespace xattr. If due to
xattr space limitations we have to limit the number of xattrs, then we
should limit it to two - a native and a namespace version, with a
"uid=" tag - first namespace gets permission to write the namespace
xattr. Again, like in the layered case, if the namespace xattr
doesn't exist, fall back to using the native xattr.
This allows most files to use the underlying xattrs, but allows a few
files to be re-signed inside the namespace, as needed. For the
layered filesystem case, this would allow mutable file hashes to be
written. (Unclear as to how shared filesystems would work in this
case.)
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 18:48 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 18:48 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]
On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> > >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> > >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> > >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> > >>>
> > >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> > >>>>
> > >>>>>My big question right now is can you implement Ted's suggested
> > >>>>>restriction. Only one security.foo or secuirty.foo(a)... attribute ?
> > >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> > >>>>
> > >>>>So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
> > >>>>
> > >>>The latter.
> > >>That case would prevent a container user from overriding the xattr
> > >>on the host. Is that what we want? For limiting the number of xattrs
> > >Not really. If the file is owned by a uid mapped into the container,
> > >then the container root can chown the file which will clear the file
> > >capability, after which he can set a new one. If the file is not
> > >owned by a uid mapped into the container, then container root could
> > >not set a filecap anyway.
> >
> > Let's say I installed a container where all files are signed and
> > thus have security.ima. Now for some reason I want to re-sign some
> > or all files inside that container. How would I do that ? Would I
> > need to get rid of security.ima first, possibly by copying each
> > file, deleting the original file, and renaming the copied file to
> > the original name, or should I just be able to write out a new
> > signature, thus creating security.ima(a)uid=1000 besides the
> > security.ima ?
> >
> > Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
If I'm understanding the discussion correctly, this isn't an issue for
layered copy on write filesystems, as each fs layer could have it's
own set of xattrs. The underlying and layered xattrs should be able
to co-exist. Use the layered xattr if it exists, but fall back to
using the underlying xattr if it doesn't.
The concern is with a shared filesystems. In that case, for IMA it
would make sense to support a native and a namespace xattr. If due to
xattr space limitations we have to limit the number of xattrs, then we
should limit it to two - a native and a namespace version, with a
"uid=" tag - first namespace gets permission to write the namespace
xattr. Again, like in the layered case, if the namespace xattr
doesn't exist, fall back to using the native xattr.
This allows most files to use the underlying xattrs, but allows a few
files to be re-signed inside the namespace, as needed. For the
layered filesystem case, this would allow mutable file hashes to be
written. (Unclear as to how shared filesystems would work in this
case.)
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 18:48 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 18:48 UTC (permalink / raw)
To: linux-security-module
On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> > >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> > >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> > >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> > >>>
> > >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> > >>>>
> > >>>>>My big question right now is can you implement Ted's suggested
> > >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ?
> > >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> > >>>>
> > >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
> > >>>>
> > >>>The latter.
> > >>That case would prevent a container user from overriding the xattr
> > >>on the host. Is that what we want? For limiting the number of xattrs
> > >Not really. If the file is owned by a uid mapped into the container,
> > >then the container root can chown the file which will clear the file
> > >capability, after which he can set a new one. If the file is not
> > >owned by a uid mapped into the container, then container root could
> > >not set a filecap anyway.
> >
> > Let's say I installed a container where all files are signed and
> > thus have security.ima. Now for some reason I want to re-sign some
> > or all files inside that container. How would I do that ? Would I
> > need to get rid of security.ima first, possibly by copying each
> > file, deleting the original file, and renaming the copied file to
> > the original name, or should I just be able to write out a new
> > signature, thus creating security.ima at uid=1000 besides the
> > security.ima ?
> >
> > Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
If I'm understanding the discussion correctly, this isn't an issue for
layered copy on write filesystems, as each fs layer could have it's
own set of xattrs. ?The underlying and layered xattrs should be able
to co-exist. ?Use the layered xattr if it exists, but fall back to
using the underlying xattr if it doesn't.
The concern is with a shared filesystems. ?In that case, for IMA it
would make sense to support a native and a namespace xattr. ?If due to
xattr space limitations we have to limit the number of xattrs, then we
should limit it to two - a native and a namespace version, with a
"uid=" tag - first namespace gets permission to write the namespace
xattr. ?Again, like in the layered case, if the namespace xattr
doesn't exist, fall back to using the native xattr.
This allows most files to use the underlying xattrs, but allows a few
files to be re-signed inside the namespace, as needed. ?For the
layered filesystem case, this would allow mutable file hashes to be
written. ?(Unclear as to how shared filesystems would work in this
case.)
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 18:48 ` Mimi Zohar
(?)
@ 2017-07-14 18:52 ` James Bottomley
-1 siblings, 0 replies; 288+ messages in thread
From: James Bottomley @ 2017-07-14 18:52 UTC (permalink / raw)
To: Mimi Zohar, Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: Eric W. Biederman, Theodore Ts'o, containers, lkp,
linux-kernel, tycho, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> The concern is with a shared filesystems. In that case, for IMA it
> would make sense to support a native and a namespace xattr. If due
> to xattr space limitations we have to limit the number of xattrs,
> then we should limit it to two - a native and a namespace version,
> with a "uid=" tag - first namespace gets permission to write the
> namespace xattr. Again, like in the layered case, if the namespace
> xattr doesn't exist, fall back to using the native xattr.
Just on this point: if we're really concerned about the need on shared
filesystems to have multiple IMA signatures per file, might it not make
sense simply to support multiple signatures within the security.ima
xattr? The rules for writing signature updates within user namespaces
would be somewhat complex (say only able to replace a signature for
which you demonstrate you possess the key) but it would lead to an
implementation which would work for traditional shared filesystems
(like NFS) as well as containerised bind mounts.
James
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 18:52 ` James Bottomley
0 siblings, 0 replies; 288+ messages in thread
From: James Bottomley @ 2017-07-14 18:52 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> The concern is with a shared filesystems. In that case, for IMA it
> would make sense to support a native and a namespace xattr. If due
> to xattr space limitations we have to limit the number of xattrs,
> then we should limit it to two - a native and a namespace version,
> with a "uid=" tag - first namespace gets permission to write the
> namespace xattr. Again, like in the layered case, if the namespace
> xattr doesn't exist, fall back to using the native xattr.
Just on this point: if we're really concerned about the need on shared
filesystems to have multiple IMA signatures per file, might it not make
sense simply to support multiple signatures within the security.ima
xattr? The rules for writing signature updates within user namespaces
would be somewhat complex (say only able to replace a signature for
which you demonstrate you possess the key) but it would lead to an
implementation which would work for traditional shared filesystems
(like NFS) as well as containerised bind mounts.
James
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 18:52 ` James Bottomley
0 siblings, 0 replies; 288+ messages in thread
From: James Bottomley @ 2017-07-14 18:52 UTC (permalink / raw)
To: linux-security-module
On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> The concern is with a shared filesystems. ?In that case, for IMA it
> would make sense to support a native and a namespace xattr. ?If due
> to xattr space limitations we have to limit the number of xattrs,
> then we should limit it to two - a native and a namespace version,
> with a "uid=" tag - first namespace gets permission to write the
> namespace xattr. ?Again, like in the layered case, if the namespace
> xattr doesn't exist, fall back to using the native xattr.
Just on this point: if we're really concerned about the need on shared
filesystems to have multiple IMA signatures per file, might it not make
sense simply to support multiple signatures within the security.ima
xattr? The rules for writing signature updates within user namespaces
would be somewhat complex (say only able to replace a signature for
which you demonstrate you possess the key) but it would lead to an
implementation which would work for traditional shared filesystems
(like NFS) as well as containerised bind mounts.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <1500058362.2853.28.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 18:52 ` James Bottomley
(?)
(?)
@ 2017-07-14 20:03 ` Mimi Zohar
-1 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 20:03 UTC (permalink / raw)
To: James Bottomley, Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, Theodore Ts'o, lkp-JC7UmRfGjtg
On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > The concern is with a shared filesystems. In that case, for IMA it
> > would make sense to support a native and a namespace xattr. If due
> > to xattr space limitations we have to limit the number of xattrs,
> > then we should limit it to two - a native and a namespace version,
> > with a "uid=" tag - first namespace gets permission to write the
> > namespace xattr. Again, like in the layered case, if the namespace
> > xattr doesn't exist, fall back to using the native xattr.
>
> Just on this point: if we're really concerned about the need on shared
> filesystems to have multiple IMA signatures per file, might it not make
> sense simply to support multiple signatures within the security.ima
> xattr? The rules for writing signature updates within user namespaces
> would be somewhat complex (say only able to replace a signature for
> which you demonstrate you possess the key) but it would lead to an
> implementation which would work for traditional shared filesystems
> (like NFS) as well as containerised bind mounts.
Writing security.ima requires being root with CAP_SYS_ADMIN
privileges. I wouldn't want to give root within the namespace
permission to over write or just extend the native security.ima.
Mimi
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 20:03 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 20:03 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]
On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > The concern is with a shared filesystems. In that case, for IMA it
> > would make sense to support a native and a namespace xattr. If due
> > to xattr space limitations we have to limit the number of xattrs,
> > then we should limit it to two - a native and a namespace version,
> > with a "uid=" tag - first namespace gets permission to write the
> > namespace xattr. Again, like in the layered case, if the namespace
> > xattr doesn't exist, fall back to using the native xattr.
>
> Just on this point: if we're really concerned about the need on shared
> filesystems to have multiple IMA signatures per file, might it not make
> sense simply to support multiple signatures within the security.ima
> xattr? The rules for writing signature updates within user namespaces
> would be somewhat complex (say only able to replace a signature for
> which you demonstrate you possess the key) but it would lead to an
> implementation which would work for traditional shared filesystems
> (like NFS) as well as containerised bind mounts.
Writing security.ima requires being root with CAP_SYS_ADMIN
privileges. I wouldn't want to give root within the namespace
permission to over write or just extend the native security.ima.
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 20:03 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 20:03 UTC (permalink / raw)
To: linux-security-module
On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > The concern is with a shared filesystems. ?In that case, for IMA it
> > would make sense to support a native and a namespace xattr. ?If due
> > to xattr space limitations we have to limit the number of xattrs,
> > then we should limit it to two - a native and a namespace version,
> > with a "uid=" tag - first namespace gets permission to write the
> > namespace xattr. ?Again, like in the layered case, if the namespace
> > xattr doesn't exist, fall back to using the native xattr.
>
> Just on this point: if we're really concerned about the need on shared
> filesystems to have multiple IMA signatures per file, might it not make
> sense simply to support multiple signatures within the security.ima
> xattr? The rules for writing signature updates within user namespaces
> would be somewhat complex (say only able to replace a signature for
> which you demonstrate you possess the key) but it would lead to an
> implementation which would work for traditional shared filesystems
> (like NFS) as well as containerised bind mounts.
Writing security.ima requires being root with CAP_SYS_ADMIN
privileges. ?I wouldn't want to give root within the namespace
permission to over write or just extend the native security.ima.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 20:03 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 20:03 UTC (permalink / raw)
To: James Bottomley, Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: Eric W. Biederman, Theodore Ts'o, containers, lkp,
linux-kernel, tycho, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > The concern is with a shared filesystems. In that case, for IMA it
> > would make sense to support a native and a namespace xattr. If due
> > to xattr space limitations we have to limit the number of xattrs,
> > then we should limit it to two - a native and a namespace version,
> > with a "uid=" tag - first namespace gets permission to write the
> > namespace xattr. Again, like in the layered case, if the namespace
> > xattr doesn't exist, fall back to using the native xattr.
>
> Just on this point: if we're really concerned about the need on shared
> filesystems to have multiple IMA signatures per file, might it not make
> sense simply to support multiple signatures within the security.ima
> xattr? The rules for writing signature updates within user namespaces
> would be somewhat complex (say only able to replace a signature for
> which you demonstrate you possess the key) but it would lead to an
> implementation which would work for traditional shared filesystems
> (like NFS) as well as containerised bind mounts.
Writing security.ima requires being root with CAP_SYS_ADMIN
privileges. I wouldn't want to give root within the namespace
permission to over write or just extend the native security.ima.
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <1500062619.3583.71.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1500062619.3583.71.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-14 20:39 ` James Bottomley
0 siblings, 0 replies; 288+ messages in thread
From: James Bottomley @ 2017-07-14 20:39 UTC (permalink / raw)
To: Mimi Zohar, Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: Theodore Ts'o,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> >
> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > >
> > > The concern is with a shared filesystems. In that case, for IMA
> > > it would make sense to support a native and a namespace xattr.
> > > If due to xattr space limitations we have to limit the number of
> > > xattrs, then we should limit it to two - a native and a namespace
> > > version, with a "uid=" tag - first namespace gets permission to
> > > write the namespace xattr. Again, like in the layered case, if
> > > the namespace xattr doesn't exist, fall back to using the native
> > > xattr.
> >
> > Just on this point: if we're really concerned about the need on
> > shared filesystems to have multiple IMA signatures per file, might
> > it not make sense simply to support multiple signatures within the
> > security.ima xattr? The rules for writing signature updates within
> > user namespaces would be somewhat complex (say only able to replace
> > a signature for which you demonstrate you possess the key) but it
> > would lead to an implementation which would work for traditional
> > shared filesystems (like NFS) as well as containerised bind mounts.
>
> Writing security.ima requires being root with CAP_SYS_ADMIN
> privileges. I wouldn't want to give root within the namespace
> permission to over write or just extend the native security.ima.
but why? That's partly the point of all of this: some security.
attributes can't be written by container root without some supervision
(the capability ones are the hugely problematic ones from this point of
view), but for some there's no reason they shouldn't be. What would be
the reason that root in a container shouldn't be able to write the ima
xattr the same as host root could on its filesystem?
James
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 20:03 ` Mimi Zohar
(?)
@ 2017-07-14 20:39 ` James Bottomley
-1 siblings, 0 replies; 288+ messages in thread
From: James Bottomley @ 2017-07-14 20:39 UTC (permalink / raw)
To: Mimi Zohar, Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: containers, linux-kernel, linux-security-module,
Eric W. Biederman, casey, Theodore Ts'o, lkp
On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> >
> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > >
> > > The concern is with a shared filesystems. In that case, for IMA
> > > it would make sense to support a native and a namespace xattr.
> > > If due to xattr space limitations we have to limit the number of
> > > xattrs, then we should limit it to two - a native and a namespace
> > > version, with a "uid=" tag - first namespace gets permission to
> > > write the namespace xattr. Again, like in the layered case, if
> > > the namespace xattr doesn't exist, fall back to using the native
> > > xattr.
> >
> > Just on this point: if we're really concerned about the need on
> > shared filesystems to have multiple IMA signatures per file, might
> > it not make sense simply to support multiple signatures within the
> > security.ima xattr? The rules for writing signature updates within
> > user namespaces would be somewhat complex (say only able to replace
> > a signature for which you demonstrate you possess the key) but it
> > would lead to an implementation which would work for traditional
> > shared filesystems (like NFS) as well as containerised bind mounts.
>
> Writing security.ima requires being root with CAP_SYS_ADMIN
> privileges. I wouldn't want to give root within the namespace
> permission to over write or just extend the native security.ima.
but why? That's partly the point of all of this: some security.
attributes can't be written by container root without some supervision
(the capability ones are the hugely problematic ones from this point of
view), but for some there's no reason they shouldn't be. What would be
the reason that root in a container shouldn't be able to write the ima
xattr the same as host root could on its filesystem?
James
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 20:39 ` James Bottomley
0 siblings, 0 replies; 288+ messages in thread
From: James Bottomley @ 2017-07-14 20:39 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]
On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> >
> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > >
> > > The concern is with a shared filesystems. In that case, for IMA
> > > it would make sense to support a native and a namespace xattr.
> > > If due to xattr space limitations we have to limit the number of
> > > xattrs, then we should limit it to two - a native and a namespace
> > > version, with a "uid=" tag - first namespace gets permission to
> > > write the namespace xattr. Again, like in the layered case, if
> > > the namespace xattr doesn't exist, fall back to using the native
> > > xattr.
> >
> > Just on this point: if we're really concerned about the need on
> > shared filesystems to have multiple IMA signatures per file, might
> > it not make sense simply to support multiple signatures within the
> > security.ima xattr? The rules for writing signature updates within
> > user namespaces would be somewhat complex (say only able to replace
> > a signature for which you demonstrate you possess the key) but it
> > would lead to an implementation which would work for traditional
> > shared filesystems (like NFS) as well as containerised bind mounts.
>
> Writing security.ima requires being root with CAP_SYS_ADMIN
> privileges. I wouldn't want to give root within the namespace
> permission to over write or just extend the native security.ima.
but why? That's partly the point of all of this: some security.
attributes can't be written by container root without some supervision
(the capability ones are the hugely problematic ones from this point of
view), but for some there's no reason they shouldn't be. What would be
the reason that root in a container shouldn't be able to write the ima
xattr the same as host root could on its filesystem?
James
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 20:39 ` James Bottomley
0 siblings, 0 replies; 288+ messages in thread
From: James Bottomley @ 2017-07-14 20:39 UTC (permalink / raw)
To: linux-security-module
On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> >
> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > >
> > > The concern is with a shared filesystems. ?In that case, for IMA
> > > it would make sense to support a native and a namespace xattr.
> > > ?If due to xattr space limitations we have to limit the number of
> > > xattrs, then we should limit it to two - a native and a namespace
> > > version, with a "uid=" tag - first namespace gets permission to
> > > write the namespace xattr. ?Again, like in the layered case, if
> > > the namespace xattr doesn't exist, fall back to using the native
> > > xattr.
> >
> > Just on this point: if we're really concerned about the need on
> > shared filesystems to have multiple IMA signatures per file, might
> > it not make sense simply to support multiple signatures within the
> > security.ima xattr? The rules for writing signature updates within
> > user namespaces would be somewhat complex (say only able to replace
> > a signature for which you demonstrate you possess the key) but it
> > would lead to an implementation which would work for traditional
> > shared filesystems (like NFS) as well as containerised bind mounts.
>
> Writing security.ima requires being root with CAP_SYS_ADMIN
> privileges. ?I wouldn't want to give root within the namespace
> permission to over write or just extend the native security.ima.
but why? ?That's partly the point of all of this: some security.
attributes can't be written by container root without some supervision
(the capability ones are the hugely problematic ones from this point of
view), but for some there's no reason they shouldn't be. ?What would be
the reason that root in a container shouldn't be able to write the ima
xattr the same as host root could on its filesystem?
James
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 20:39 ` James Bottomley
(?)
@ 2017-07-14 21:34 ` Theodore Ts'o
-1 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-14 21:34 UTC (permalink / raw)
To: James Bottomley
Cc: Mimi Zohar, Serge E. Hallyn, Stefan Berger, Mimi Zohar,
containers, linux-kernel, linux-security-module,
Eric W. Biederman, casey, lkp
On Fri, Jul 14, 2017 at 01:39:59PM -0700, James Bottomley wrote:
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
So I'm happy to say, "Ix-nay on nested containerization; that way lies
insanity". But my understanding is that there will be people who want
to run containers in containers in containers in containers... and
this is what scares me.
What if someone in the Nth layer of containerization wants to allow
the container root in the (N+1)th layer to set file capabilities that
will not be honored in the Nth layer of containerization?
Again I think that this is insane, and I'm happy for the answer to be,
"No, that's not supported". That the "Host container" can have
capabilities that it won't honor, but will be honored by all
subcontainers, but that same thing can't be done between a
subsubsub-container and its child subsubsubsub-container.
Are we OK with that? Because how we would encode this in the xattr
seems to be to be hopelessly not scalable.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 21:34 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-14 21:34 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]
On Fri, Jul 14, 2017 at 01:39:59PM -0700, James Bottomley wrote:
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
So I'm happy to say, "Ix-nay on nested containerization; that way lies
insanity". But my understanding is that there will be people who want
to run containers in containers in containers in containers... and
this is what scares me.
What if someone in the Nth layer of containerization wants to allow
the container root in the (N+1)th layer to set file capabilities that
will not be honored in the Nth layer of containerization?
Again I think that this is insane, and I'm happy for the answer to be,
"No, that's not supported". That the "Host container" can have
capabilities that it won't honor, but will be honored by all
subcontainers, but that same thing can't be done between a
subsubsub-container and its child subsubsubsub-container.
Are we OK with that? Because how we would encode this in the xattr
seems to be to be hopelessly not scalable.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 21:34 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-14 21:34 UTC (permalink / raw)
To: linux-security-module
On Fri, Jul 14, 2017 at 01:39:59PM -0700, James Bottomley wrote:
> but why? ?That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. ?What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
So I'm happy to say, "Ix-nay on nested containerization; that way lies
insanity". But my understanding is that there will be people who want
to run containers in containers in containers in containers... and
this is what scares me.
What if someone in the Nth layer of containerization wants to allow
the container root in the (N+1)th layer to set file capabilities that
will not be honored in the Nth layer of containerization?
Again I think that this is insane, and I'm happy for the answer to be,
"No, that's not supported". That the "Host container" can have
capabilities that it won't honor, but will be honored by all
subcontainers, but that same thing can't be done between a
subsubsub-container and its child subsubsubsub-container.
Are we OK with that? Because how we would encode this in the xattr
seems to be to be hopelessly not scalable.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 21:34 ` Theodore Ts'o
(?)
@ 2017-07-14 23:22 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:22 UTC (permalink / raw)
To: Theodore Ts'o
Cc: James Bottomley, Mimi Zohar, Serge E. Hallyn, Stefan Berger,
Mimi Zohar, containers, linux-kernel, linux-security-module,
casey, lkp
Theodore Ts'o <tytso@mit.edu> writes:
> On Fri, Jul 14, 2017 at 01:39:59PM -0700, James Bottomley wrote:
>> but why? That's partly the point of all of this: some security.
>> attributes can't be written by container root without some supervision
>> (the capability ones are the hugely problematic ones from this point of
>> view), but for some there's no reason they shouldn't be. What would be
>> the reason that root in a container shouldn't be able to write the ima
>> xattr the same as host root could on its filesystem?
>
> So I'm happy to say, "Ix-nay on nested containerization; that way lies
> insanity". But my understanding is that there will be people who want
> to run containers in containers in containers in containers... and
> this is what scares me.
I am happy to say we need to bound the space we take in an inode.
So a design that needs more space the more containers you have is
suspicious.
I am not fond of decisions that don't allow nesting of containers. That
just paints us into a corner. I am in favor of things that require
little or bounded space.
Generally I will frown at a decision that won't allow nesting, because
nesting of containers happens naturally
> What if someone in the Nth layer of containerization wants to allow
> the container root in the (N+1)th layer to set file capabilities that
> will not be honored in the Nth layer of containerization?
That works perfectly well with the design we have today. And it only
needs a single security.capability attribute. The actual design is
associated with the security.capability attribute (either in the
attribute or in the most recent iteration in the attribute name *scowl*)
is to have the uid (from the filesystems point of view) of the root user
of a user namespace. Running that executable will give you those
capabilities if the uid matches the root user in your user namespace (or
a parent user namespace).
As anyone can who can modify a file can remove a security.capable
attribute just like anyone who can modify a file can remove the setuid
bit this works fine is is sufficient. Though perhaps a little different.
> Again I think that this is insane, and I'm happy for the answer to be,
> "No, that's not supported". That the "Host container" can have
> capabilities that it won't honor, but will be honored by all
> subcontainers, but that same thing can't be done between a
> subsubsub-container and its child subsubsubsub-container.
>
> Are we OK with that? Because how we would encode this in the xattr
> seems to be to be hopelessly not scalable.
That really isn't an issue right now.
The real question right now is what to do with security.ima and
security.evm. As it was proposed that we share a common code base for
them. Right now it looks to me like the semantics are sufficiently
different that it doesn't make sense to share code between the two
implementations. At which point all reason for storing any of this in
the xattr name goes away. So we just have a single xattr.
Right now I am very much in favor of security xattrs continuing to have
well known names. That easily limits how much space in the inode you
can have, and it makes thinking about things easier. It doesn't
preclude having acls in your xattr. That is exactly how posix
acls are implemented. But I am not going to build generic support for
them, and I really don't expect they will be needed.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 23:22 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:22 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3495 bytes --]
Theodore Ts'o <tytso@mit.edu> writes:
> On Fri, Jul 14, 2017 at 01:39:59PM -0700, James Bottomley wrote:
>> but why? That's partly the point of all of this: some security.
>> attributes can't be written by container root without some supervision
>> (the capability ones are the hugely problematic ones from this point of
>> view), but for some there's no reason they shouldn't be. What would be
>> the reason that root in a container shouldn't be able to write the ima
>> xattr the same as host root could on its filesystem?
>
> So I'm happy to say, "Ix-nay on nested containerization; that way lies
> insanity". But my understanding is that there will be people who want
> to run containers in containers in containers in containers... and
> this is what scares me.
I am happy to say we need to bound the space we take in an inode.
So a design that needs more space the more containers you have is
suspicious.
I am not fond of decisions that don't allow nesting of containers. That
just paints us into a corner. I am in favor of things that require
little or bounded space.
Generally I will frown at a decision that won't allow nesting, because
nesting of containers happens naturally
> What if someone in the Nth layer of containerization wants to allow
> the container root in the (N+1)th layer to set file capabilities that
> will not be honored in the Nth layer of containerization?
That works perfectly well with the design we have today. And it only
needs a single security.capability attribute. The actual design is
associated with the security.capability attribute (either in the
attribute or in the most recent iteration in the attribute name *scowl*)
is to have the uid (from the filesystems point of view) of the root user
of a user namespace. Running that executable will give you those
capabilities if the uid matches the root user in your user namespace (or
a parent user namespace).
As anyone can who can modify a file can remove a security.capable
attribute just like anyone who can modify a file can remove the setuid
bit this works fine is is sufficient. Though perhaps a little different.
> Again I think that this is insane, and I'm happy for the answer to be,
> "No, that's not supported". That the "Host container" can have
> capabilities that it won't honor, but will be honored by all
> subcontainers, but that same thing can't be done between a
> subsubsub-container and its child subsubsubsub-container.
>
> Are we OK with that? Because how we would encode this in the xattr
> seems to be to be hopelessly not scalable.
That really isn't an issue right now.
The real question right now is what to do with security.ima and
security.evm. As it was proposed that we share a common code base for
them. Right now it looks to me like the semantics are sufficiently
different that it doesn't make sense to share code between the two
implementations. At which point all reason for storing any of this in
the xattr name goes away. So we just have a single xattr.
Right now I am very much in favor of security xattrs continuing to have
well known names. That easily limits how much space in the inode you
can have, and it makes thinking about things easier. It doesn't
preclude having acls in your xattr. That is exactly how posix
acls are implemented. But I am not going to build generic support for
them, and I really don't expect they will be needed.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 23:22 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:22 UTC (permalink / raw)
To: linux-security-module
Theodore Ts'o <tytso@mit.edu> writes:
> On Fri, Jul 14, 2017 at 01:39:59PM -0700, James Bottomley wrote:
>> but why? ?That's partly the point of all of this: some security.
>> attributes can't be written by container root without some supervision
>> (the capability ones are the hugely problematic ones from this point of
>> view), but for some there's no reason they shouldn't be. ?What would be
>> the reason that root in a container shouldn't be able to write the ima
>> xattr the same as host root could on its filesystem?
>
> So I'm happy to say, "Ix-nay on nested containerization; that way lies
> insanity". But my understanding is that there will be people who want
> to run containers in containers in containers in containers... and
> this is what scares me.
I am happy to say we need to bound the space we take in an inode.
So a design that needs more space the more containers you have is
suspicious.
I am not fond of decisions that don't allow nesting of containers. That
just paints us into a corner. I am in favor of things that require
little or bounded space.
Generally I will frown at a decision that won't allow nesting, because
nesting of containers happens naturally
> What if someone in the Nth layer of containerization wants to allow
> the container root in the (N+1)th layer to set file capabilities that
> will not be honored in the Nth layer of containerization?
That works perfectly well with the design we have today. And it only
needs a single security.capability attribute. The actual design is
associated with the security.capability attribute (either in the
attribute or in the most recent iteration in the attribute name *scowl*)
is to have the uid (from the filesystems point of view) of the root user
of a user namespace. Running that executable will give you those
capabilities if the uid matches the root user in your user namespace (or
a parent user namespace).
As anyone can who can modify a file can remove a security.capable
attribute just like anyone who can modify a file can remove the setuid
bit this works fine is is sufficient. Though perhaps a little different.
> Again I think that this is insane, and I'm happy for the answer to be,
> "No, that's not supported". That the "Host container" can have
> capabilities that it won't honor, but will be honored by all
> subcontainers, but that same thing can't be done between a
> subsubsub-container and its child subsubsubsub-container.
>
> Are we OK with that? Because how we would encode this in the xattr
> seems to be to be hopelessly not scalable.
That really isn't an issue right now.
The real question right now is what to do with security.ima and
security.evm. As it was proposed that we share a common code base for
them. Right now it looks to me like the semantics are sufficiently
different that it doesn't make sense to share code between the two
implementations. At which point all reason for storing any of this in
the xattr name goes away. So we just have a single xattr.
Right now I am very much in favor of security xattrs continuing to have
well known names. That easily limits how much space in the inode you
can have, and it makes thinking about things easier. It doesn't
preclude having acls in your xattr. That is exactly how posix
acls are implemented. But I am not going to build generic support for
them, and I really don't expect they will be needed.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170714213449.gtxtkqtxifk5j4wp-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170714213449.gtxtkqtxifk5j4wp-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
@ 2017-07-14 23:22 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:22 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Mimi Zohar, lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, James Bottomley,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, Mimi Zohar
Theodore Ts'o <tytso@mit.edu> writes:
> On Fri, Jul 14, 2017 at 01:39:59PM -0700, James Bottomley wrote:
>> but why? That's partly the point of all of this: some security.
>> attributes can't be written by container root without some supervision
>> (the capability ones are the hugely problematic ones from this point of
>> view), but for some there's no reason they shouldn't be. What would be
>> the reason that root in a container shouldn't be able to write the ima
>> xattr the same as host root could on its filesystem?
>
> So I'm happy to say, "Ix-nay on nested containerization; that way lies
> insanity". But my understanding is that there will be people who want
> to run containers in containers in containers in containers... and
> this is what scares me.
I am happy to say we need to bound the space we take in an inode.
So a design that needs more space the more containers you have is
suspicious.
I am not fond of decisions that don't allow nesting of containers. That
just paints us into a corner. I am in favor of things that require
little or bounded space.
Generally I will frown at a decision that won't allow nesting, because
nesting of containers happens naturally
> What if someone in the Nth layer of containerization wants to allow
> the container root in the (N+1)th layer to set file capabilities that
> will not be honored in the Nth layer of containerization?
That works perfectly well with the design we have today. And it only
needs a single security.capability attribute. The actual design is
associated with the security.capability attribute (either in the
attribute or in the most recent iteration in the attribute name *scowl*)
is to have the uid (from the filesystems point of view) of the root user
of a user namespace. Running that executable will give you those
capabilities if the uid matches the root user in your user namespace (or
a parent user namespace).
As anyone can who can modify a file can remove a security.capable
attribute just like anyone who can modify a file can remove the setuid
bit this works fine is is sufficient. Though perhaps a little different.
> Again I think that this is insane, and I'm happy for the answer to be,
> "No, that's not supported". That the "Host container" can have
> capabilities that it won't honor, but will be honored by all
> subcontainers, but that same thing can't be done between a
> subsubsub-container and its child subsubsubsub-container.
>
> Are we OK with that? Because how we would encode this in the xattr
> seems to be to be hopelessly not scalable.
That really isn't an issue right now.
The real question right now is what to do with security.ima and
security.evm. As it was proposed that we share a common code base for
them. Right now it looks to me like the semantics are sufficiently
different that it doesn't make sense to share code between the two
implementations. At which point all reason for storing any of this in
the xattr name goes away. So we just have a single xattr.
Right now I am very much in favor of security xattrs continuing to have
well known names. That easily limits how much space in the inode you
can have, and it makes thinking about things easier. It doesn't
preclude having acls in your xattr. That is exactly how posix
acls are implemented. But I am not going to build generic support for
them, and I really don't expect they will be needed.
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 20:39 ` James Bottomley
(?)
@ 2017-07-14 23:29 ` Mimi Zohar
-1 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 23:29 UTC (permalink / raw)
To: James Bottomley, Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: containers, linux-kernel, linux-security-module,
Eric W. Biederman, casey, Theodore Ts'o, lkp
On Fri, 2017-07-14 at 13:39 -0700, James Bottomley wrote:
> On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
> > On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> > >
> > > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > > >
> > > > The concern is with a shared filesystems. In that case, for IMA
> > > > it would make sense to support a native and a namespace xattr.
> > > > If due to xattr space limitations we have to limit the number of
> > > > xattrs, then we should limit it to two - a native and a namespace
> > > > version, with a "uid=" tag - first namespace gets permission to
> > > > write the namespace xattr. Again, like in the layered case, if
> > > > the namespace xattr doesn't exist, fall back to using the native
> > > > xattr.
> > >
> > > Just on this point: if we're really concerned about the need on
> > > shared filesystems to have multiple IMA signatures per file, might
> > > it not make sense simply to support multiple signatures within the
> > > security.ima xattr? The rules for writing signature updates within
> > > user namespaces would be somewhat complex (say only able to replace
> > > a signature for which you demonstrate you possess the key) but it
> > > would lead to an implementation which would work for traditional
> > > shared filesystems (like NFS) as well as containerised bind mounts.
> >
> > Writing security.ima requires being root with CAP_SYS_ADMIN
> > privileges. I wouldn't want to give root within the namespace
> > permission to over write or just extend the native security.ima.
>
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
Let's describe the different scenarios of a shared filesystem (not
layered).
1. The kernel updating the file hash as the file changes, written as
the security.ima xattr.
2. Root vs root in the namespace explicitly writing the security.ima
xattr.
In the first case, neither root nor root in the namespace calculates
and writes the file hash as security.ima. The kernel itself updates
the file hash. Since the file hash is the same value, it doesn't need
to be written out as two separate security.ima xattrs.
The second case is where root or root in the namespace explicitly
writes out a file signature as security.ima. Here different entities
might want to sign the file with different keys. Up to now, only root
with CAP_SYS_ADMIN can write out security.ima. That shouldn't change.
Nor should root in the namespace be allowed to change the native's
view, but should be only allowed to change its own view of the xattr.
Allowing root in the namespace to change the native's view isn't safe.
Remember writing security.ima also triggers security.evm to be
updated. Root in the namespace should never be permitted to cause the
native's security.evm to be updated, only the namespaces's version.
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 23:29 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 23:29 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3271 bytes --]
On Fri, 2017-07-14 at 13:39 -0700, James Bottomley wrote:
> On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
> > On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> > >
> > > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > > >
> > > > The concern is with a shared filesystems. In that case, for IMA
> > > > it would make sense to support a native and a namespace xattr.
> > > > If due to xattr space limitations we have to limit the number of
> > > > xattrs, then we should limit it to two - a native and a namespace
> > > > version, with a "uid=" tag - first namespace gets permission to
> > > > write the namespace xattr. Again, like in the layered case, if
> > > > the namespace xattr doesn't exist, fall back to using the native
> > > > xattr.
> > >
> > > Just on this point: if we're really concerned about the need on
> > > shared filesystems to have multiple IMA signatures per file, might
> > > it not make sense simply to support multiple signatures within the
> > > security.ima xattr? The rules for writing signature updates within
> > > user namespaces would be somewhat complex (say only able to replace
> > > a signature for which you demonstrate you possess the key) but it
> > > would lead to an implementation which would work for traditional
> > > shared filesystems (like NFS) as well as containerised bind mounts.
> >
> > Writing security.ima requires being root with CAP_SYS_ADMIN
> > privileges. I wouldn't want to give root within the namespace
> > permission to over write or just extend the native security.ima.
>
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
Let's describe the different scenarios of a shared filesystem (not
layered).
1. The kernel updating the file hash as the file changes, written as
the security.ima xattr.
2. Root vs root in the namespace explicitly writing the security.ima
xattr.
In the first case, neither root nor root in the namespace calculates
and writes the file hash as security.ima. The kernel itself updates
the file hash. Since the file hash is the same value, it doesn't need
to be written out as two separate security.ima xattrs.
The second case is where root or root in the namespace explicitly
writes out a file signature as security.ima. Here different entities
might want to sign the file with different keys. Up to now, only root
with CAP_SYS_ADMIN can write out security.ima. That shouldn't change.
Nor should root in the namespace be allowed to change the native's
view, but should be only allowed to change its own view of the xattr.
Allowing root in the namespace to change the native's view isn't safe.
Remember writing security.ima also triggers security.evm to be
updated. Root in the namespace should never be permitted to cause the
native's security.evm to be updated, only the namespaces's version.
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 23:29 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 23:29 UTC (permalink / raw)
To: linux-security-module
On Fri, 2017-07-14 at 13:39 -0700, James Bottomley wrote:
> On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
> > On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> > >
> > > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > > >
> > > > The concern is with a shared filesystems. ?In that case, for IMA
> > > > it would make sense to support a native and a namespace xattr.
> > > > ?If due to xattr space limitations we have to limit the number of
> > > > xattrs, then we should limit it to two - a native and a namespace
> > > > version, with a "uid=" tag - first namespace gets permission to
> > > > write the namespace xattr. ?Again, like in the layered case, if
> > > > the namespace xattr doesn't exist, fall back to using the native
> > > > xattr.
> > >
> > > Just on this point: if we're really concerned about the need on
> > > shared filesystems to have multiple IMA signatures per file, might
> > > it not make sense simply to support multiple signatures within the
> > > security.ima xattr? The rules for writing signature updates within
> > > user namespaces would be somewhat complex (say only able to replace
> > > a signature for which you demonstrate you possess the key) but it
> > > would lead to an implementation which would work for traditional
> > > shared filesystems (like NFS) as well as containerised bind mounts.
> >
> > Writing security.ima requires being root with CAP_SYS_ADMIN
> > privileges. ?I wouldn't want to give root within the namespace
> > permission to over write or just extend the native security.ima.
>
> but why? ?That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. ?What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
Let's describe the different scenarios of a shared filesystem (not
layered).
1. The kernel updating the file hash as the file changes, written as
the security.ima xattr.
2. Root vs root in the namespace explicitly writing the security.ima
xattr.?
?
In the first case, neither root nor root in the namespace calculates
and writes the file hash as security.ima. ?The kernel itself updates
the file hash. ?Since the file hash is the same value, it doesn't need
to be written out as two separate security.ima xattrs.
The second case is where root or root in the namespace explicitly
writes out a file signature as security.ima. ?Here different entities
might want to sign the file with different keys. ?Up to now, only root
with CAP_SYS_ADMIN can write out security.ima. ?That shouldn't change.
Nor should root in the namespace be allowed to change the native's
view, but should be only allowed to change its own view of the xattr.
Allowing root in the namespace to change the native's view isn't safe.
Remember writing security.ima also triggers security.evm to be
updated. ?Root in the namespace should never be permitted to cause the
native's security.evm to be updated, only the namespaces's version.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 20:39 ` James Bottomley
(?)
@ 2017-07-14 23:53 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:53 UTC (permalink / raw)
To: James Bottomley
Cc: Mimi Zohar, Serge E. Hallyn, Stefan Berger, Mimi Zohar,
containers, linux-kernel, linux-security-module, casey,
Theodore Ts'o, lkp
James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
>> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
>> >
>> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
>> > >
>> > > The concern is with a shared filesystems. In that case, for IMA
>> > > it would make sense to support a native and a namespace xattr.
>> > > If due to xattr space limitations we have to limit the number of
>> > > xattrs, then we should limit it to two - a native and a namespace
>> > > version, with a "uid=" tag - first namespace gets permission to
>> > > write the namespace xattr. Again, like in the layered case, if
>> > > the namespace xattr doesn't exist, fall back to using the native
>> > > xattr.
>> >
>> > Just on this point: if we're really concerned about the need on
>> > shared filesystems to have multiple IMA signatures per file, might
>> > it not make sense simply to support multiple signatures within the
>> > security.ima xattr? The rules for writing signature updates within
>> > user namespaces would be somewhat complex (say only able to replace
>> > a signature for which you demonstrate you possess the key) but it
>> > would lead to an implementation which would work for traditional
>> > shared filesystems (like NFS) as well as containerised bind mounts.
>>
>> Writing security.ima requires being root with CAP_SYS_ADMIN
>> privileges. I wouldn't want to give root within the namespace
>> permission to over write or just extend the native security.ima.
>
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
Mimi said she ``native''. It competely makes sense for the things that
the container doesn't ``own'' to not be allowed to be written/updated by
the container.
James you are making the case here for root in the container to write
to the ima and evm attributes that are for the container.
So I don't actually see any disagreement here except perhaps for
terminology.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 23:53 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:53 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]
James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
>> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
>> >
>> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
>> > >
>> > > The concern is with a shared filesystems. In that case, for IMA
>> > > it would make sense to support a native and a namespace xattr.
>> > > If due to xattr space limitations we have to limit the number of
>> > > xattrs, then we should limit it to two - a native and a namespace
>> > > version, with a "uid=" tag - first namespace gets permission to
>> > > write the namespace xattr. Again, like in the layered case, if
>> > > the namespace xattr doesn't exist, fall back to using the native
>> > > xattr.
>> >
>> > Just on this point: if we're really concerned about the need on
>> > shared filesystems to have multiple IMA signatures per file, might
>> > it not make sense simply to support multiple signatures within the
>> > security.ima xattr? The rules for writing signature updates within
>> > user namespaces would be somewhat complex (say only able to replace
>> > a signature for which you demonstrate you possess the key) but it
>> > would lead to an implementation which would work for traditional
>> > shared filesystems (like NFS) as well as containerised bind mounts.
>>
>> Writing security.ima requires being root with CAP_SYS_ADMIN
>> privileges. I wouldn't want to give root within the namespace
>> permission to over write or just extend the native security.ima.
>
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
Mimi said she ``native''. It competely makes sense for the things that
the container doesn't ``own'' to not be allowed to be written/updated by
the container.
James you are making the case here for root in the container to write
to the ima and evm attributes that are for the container.
So I don't actually see any disagreement here except perhaps for
terminology.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 23:53 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:53 UTC (permalink / raw)
To: linux-security-module
James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
>> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
>> >
>> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
>> > >
>> > > The concern is with a shared filesystems. ?In that case, for IMA
>> > > it would make sense to support a native and a namespace xattr.
>> > > ?If due to xattr space limitations we have to limit the number of
>> > > xattrs, then we should limit it to two - a native and a namespace
>> > > version, with a "uid=" tag - first namespace gets permission to
>> > > write the namespace xattr. ?Again, like in the layered case, if
>> > > the namespace xattr doesn't exist, fall back to using the native
>> > > xattr.
>> >
>> > Just on this point: if we're really concerned about the need on
>> > shared filesystems to have multiple IMA signatures per file, might
>> > it not make sense simply to support multiple signatures within the
>> > security.ima xattr? The rules for writing signature updates within
>> > user namespaces would be somewhat complex (say only able to replace
>> > a signature for which you demonstrate you possess the key) but it
>> > would lead to an implementation which would work for traditional
>> > shared filesystems (like NFS) as well as containerised bind mounts.
>>
>> Writing security.ima requires being root with CAP_SYS_ADMIN
>> privileges. ?I wouldn't want to give root within the namespace
>> permission to over write or just extend the native security.ima.
>
> but why? ?That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. ?What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
Mimi said she ``native''. It competely makes sense for the things that
the container doesn't ``own'' to not be allowed to be written/updated by
the container.
James you are making the case here for root in the container to write
to the ima and evm attributes that are for the container.
So I don't actually see any disagreement here except perhaps for
terminology.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <1500064799.2853.36.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1500064799.2853.36.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
@ 2017-07-14 21:34 ` Theodore Ts'o
2017-07-14 23:29 ` Mimi Zohar
2017-07-14 23:53 ` Eric W. Biederman
2 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-14 21:34 UTC (permalink / raw)
To: James Bottomley
Cc: Mimi Zohar, lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, Mimi Zohar
On Fri, Jul 14, 2017 at 01:39:59PM -0700, James Bottomley wrote:
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
So I'm happy to say, "Ix-nay on nested containerization; that way lies
insanity". But my understanding is that there will be people who want
to run containers in containers in containers in containers... and
this is what scares me.
What if someone in the Nth layer of containerization wants to allow
the container root in the (N+1)th layer to set file capabilities that
will not be honored in the Nth layer of containerization?
Again I think that this is insane, and I'm happy for the answer to be,
"No, that's not supported". That the "Host container" can have
capabilities that it won't honor, but will be honored by all
subcontainers, but that same thing can't be done between a
subsubsub-container and its child subsubsubsub-container.
Are we OK with that? Because how we would encode this in the xattr
seems to be to be hopelessly not scalable.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1500064799.2853.36.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-07-14 21:34 ` Theodore Ts'o
@ 2017-07-14 23:29 ` Mimi Zohar
2017-07-14 23:53 ` Eric W. Biederman
2 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 23:29 UTC (permalink / raw)
To: James Bottomley, Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: Theodore Ts'o,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On Fri, 2017-07-14 at 13:39 -0700, James Bottomley wrote:
> On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
> > On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
> > >
> > > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> > > >
> > > > The concern is with a shared filesystems. In that case, for IMA
> > > > it would make sense to support a native and a namespace xattr.
> > > > If due to xattr space limitations we have to limit the number of
> > > > xattrs, then we should limit it to two - a native and a namespace
> > > > version, with a "uid=" tag - first namespace gets permission to
> > > > write the namespace xattr. Again, like in the layered case, if
> > > > the namespace xattr doesn't exist, fall back to using the native
> > > > xattr.
> > >
> > > Just on this point: if we're really concerned about the need on
> > > shared filesystems to have multiple IMA signatures per file, might
> > > it not make sense simply to support multiple signatures within the
> > > security.ima xattr? The rules for writing signature updates within
> > > user namespaces would be somewhat complex (say only able to replace
> > > a signature for which you demonstrate you possess the key) but it
> > > would lead to an implementation which would work for traditional
> > > shared filesystems (like NFS) as well as containerised bind mounts.
> >
> > Writing security.ima requires being root with CAP_SYS_ADMIN
> > privileges. I wouldn't want to give root within the namespace
> > permission to over write or just extend the native security.ima.
>
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
Let's describe the different scenarios of a shared filesystem (not
layered).
1. The kernel updating the file hash as the file changes, written as
the security.ima xattr.
2. Root vs root in the namespace explicitly writing the security.ima
xattr.
In the first case, neither root nor root in the namespace calculates
and writes the file hash as security.ima. The kernel itself updates
the file hash. Since the file hash is the same value, it doesn't need
to be written out as two separate security.ima xattrs.
The second case is where root or root in the namespace explicitly
writes out a file signature as security.ima. Here different entities
might want to sign the file with different keys. Up to now, only root
with CAP_SYS_ADMIN can write out security.ima. That shouldn't change.
Nor should root in the namespace be allowed to change the native's
view, but should be only allowed to change its own view of the xattr.
Allowing root in the namespace to change the native's view isn't safe.
Remember writing security.ima also triggers security.evm to be
updated. Root in the namespace should never be permitted to cause the
native's security.evm to be updated, only the namespaces's version.
Mimi
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1500064799.2853.36.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-07-14 21:34 ` Theodore Ts'o
2017-07-14 23:29 ` Mimi Zohar
@ 2017-07-14 23:53 ` Eric W. Biederman
2 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:53 UTC (permalink / raw)
To: James Bottomley
Cc: Theodore Ts'o, Mimi Zohar, lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, Mimi Zohar
James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:
>> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:
>> >
>> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
>> > >
>> > > The concern is with a shared filesystems. In that case, for IMA
>> > > it would make sense to support a native and a namespace xattr.
>> > > If due to xattr space limitations we have to limit the number of
>> > > xattrs, then we should limit it to two - a native and a namespace
>> > > version, with a "uid=" tag - first namespace gets permission to
>> > > write the namespace xattr. Again, like in the layered case, if
>> > > the namespace xattr doesn't exist, fall back to using the native
>> > > xattr.
>> >
>> > Just on this point: if we're really concerned about the need on
>> > shared filesystems to have multiple IMA signatures per file, might
>> > it not make sense simply to support multiple signatures within the
>> > security.ima xattr? The rules for writing signature updates within
>> > user namespaces would be somewhat complex (say only able to replace
>> > a signature for which you demonstrate you possess the key) but it
>> > would lead to an implementation which would work for traditional
>> > shared filesystems (like NFS) as well as containerised bind mounts.
>>
>> Writing security.ima requires being root with CAP_SYS_ADMIN
>> privileges. I wouldn't want to give root within the namespace
>> permission to over write or just extend the native security.ima.
>
> but why? That's partly the point of all of this: some security.
> attributes can't be written by container root without some supervision
> (the capability ones are the hugely problematic ones from this point of
> view), but for some there's no reason they shouldn't be. What would be
> the reason that root in a container shouldn't be able to write the ima
> xattr the same as host root could on its filesystem?
Mimi said she ``native''. It competely makes sense for the things that
the container doesn't ``own'' to not be allowed to be written/updated by
the container.
James you are making the case here for root in the container to write
to the ima and evm attributes that are for the container.
So I don't actually see any disagreement here except perhaps for
terminology.
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <1500058090.3583.28.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1500058090.3583.28.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-14 18:52 ` James Bottomley
2017-07-14 19:29 ` Theodore Ts'o
1 sibling, 0 replies; 288+ messages in thread
From: James Bottomley @ 2017-07-14 18:52 UTC (permalink / raw)
To: Mimi Zohar, Serge E. Hallyn, Stefan Berger, Mimi Zohar
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, Theodore Ts'o, lkp-JC7UmRfGjtg
On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:
> The concern is with a shared filesystems. In that case, for IMA it
> would make sense to support a native and a namespace xattr. If due
> to xattr space limitations we have to limit the number of xattrs,
> then we should limit it to two - a native and a namespace version,
> with a "uid=" tag - first namespace gets permission to write the
> namespace xattr. Again, like in the layered case, if the namespace
> xattr doesn't exist, fall back to using the native xattr.
Just on this point: if we're really concerned about the need on shared
filesystems to have multiple IMA signatures per file, might it not make
sense simply to support multiple signatures within the security.ima
xattr? The rules for writing signature updates within user namespaces
would be somewhat complex (say only able to replace a signature for
which you demonstrate you possess the key) but it would lead to an
implementation which would work for traditional shared filesystems
(like NFS) as well as containerised bind mounts.
James
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 18:48 ` Mimi Zohar
(?)
(?)
@ 2017-07-14 19:29 ` Theodore Ts'o
-1 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-14 19:29 UTC (permalink / raw)
To: Mimi Zohar
Cc: Mimi Zohar,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
>
> If I'm understanding the discussion correctly, this isn't an issue for
> layered copy on write filesystems, as each fs layer could have it's
> own set of xattrs. The underlying and layered xattrs should be able
> to co-exist. Use the layered xattr if it exists, but fall back to
> using the underlying xattr if it doesn't.
Note that this assumes that it is possible to "copy up" the xattrs
without necessarily "copying up" all of the data blocks. This might
be true for some layers, but I don't believe it is currently true for
overlayfs, for example.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:29 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-14 19:29 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
>
> If I'm understanding the discussion correctly, this isn't an issue for
> layered copy on write filesystems, as each fs layer could have it's
> own set of xattrs. The underlying and layered xattrs should be able
> to co-exist. Use the layered xattr if it exists, but fall back to
> using the underlying xattr if it doesn't.
Note that this assumes that it is possible to "copy up" the xattrs
without necessarily "copying up" all of the data blocks. This might
be true for some layers, but I don't believe it is currently true for
overlayfs, for example.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:29 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-14 19:29 UTC (permalink / raw)
To: linux-security-module
On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
>
> If I'm understanding the discussion correctly, this isn't an issue for
> layered copy on write filesystems, as each fs layer could have it's
> own set of xattrs. ?The underlying and layered xattrs should be able
> to co-exist. ?Use the layered xattr if it exists, but fall back to
> using the underlying xattr if it doesn't.
Note that this assumes that it is possible to "copy up" the xattrs
without necessarily "copying up" all of the data blocks. This might
be true for some layers, but I don't believe it is currently true for
overlayfs, for example.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:29 ` Theodore Ts'o
0 siblings, 0 replies; 288+ messages in thread
From: Theodore Ts'o @ 2017-07-14 19:29 UTC (permalink / raw)
To: Mimi Zohar
Cc: Serge E. Hallyn, Stefan Berger, Mimi Zohar, Eric W. Biederman,
containers, lkp, linux-kernel, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
>
> If I'm understanding the discussion correctly, this isn't an issue for
> layered copy on write filesystems, as each fs layer could have it's
> own set of xattrs. The underlying and layered xattrs should be able
> to co-exist. Use the layered xattr if it exists, but fall back to
> using the underlying xattr if it doesn't.
Note that this assumes that it is possible to "copy up" the xattrs
without necessarily "copying up" all of the data blocks. This might
be true for some layers, but I don't believe it is currently true for
overlayfs, for example.
- Ted
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170714192909.zoxnlm32nrxguqao-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 19:29 ` Theodore Ts'o
(?)
(?)
@ 2017-07-14 19:43 ` Mimi Zohar
-1 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 19:43 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Mimi Zohar,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
> On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
> >
> > If I'm understanding the discussion correctly, this isn't an issue for
> > layered copy on write filesystems, as each fs layer could have it's
> > own set of xattrs. The underlying and layered xattrs should be able
> > to co-exist. Use the layered xattr if it exists, but fall back to
> > using the underlying xattr if it doesn't.
>
> Note that this assumes that it is possible to "copy up" the xattrs
> without necessarily "copying up" all of the data blocks. This might
> be true for some layers, but I don't believe it is currently true for
> overlayfs, for example.
Ok, so for the use case scneario where the container owner is willing
to use the public key distributed with the files, then only those
files that are new or modified in the overlay would need to be signed
with a key local to the overlay. In the worst case scenario, where
the container owner is only willing to trust their own public key, I
guess we can live with having to copy up the files.
Mimi
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:43 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 19:43 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
> On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
> >
> > If I'm understanding the discussion correctly, this isn't an issue for
> > layered copy on write filesystems, as each fs layer could have it's
> > own set of xattrs. The underlying and layered xattrs should be able
> > to co-exist. Use the layered xattr if it exists, but fall back to
> > using the underlying xattr if it doesn't.
>
> Note that this assumes that it is possible to "copy up" the xattrs
> without necessarily "copying up" all of the data blocks. This might
> be true for some layers, but I don't believe it is currently true for
> overlayfs, for example.
Ok, so for the use case scneario where the container owner is willing
to use the public key distributed with the files, then only those
files that are new or modified in the overlay would need to be signed
with a key local to the overlay. In the worst case scenario, where
the container owner is only willing to trust their own public key, I
guess we can live with having to copy up the files.
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:43 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 19:43 UTC (permalink / raw)
To: linux-security-module
On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
> On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
> >
> > If I'm understanding the discussion correctly, this isn't an issue for
> > layered copy on write filesystems, as each fs layer could have it's
> > own set of xattrs. ?The underlying and layered xattrs should be able
> > to co-exist. ?Use the layered xattr if it exists, but fall back to
> > using the underlying xattr if it doesn't.
>
> Note that this assumes that it is possible to "copy up" the xattrs
> without necessarily "copying up" all of the data blocks. This might
> be true for some layers, but I don't believe it is currently true for
> overlayfs, for example.
Ok, so for the use case scneario where the container owner is willing
to use the public key distributed with the files, then only those
files that are new or modified in the overlay would need to be signed
with a key local to the overlay. ?In the worst case scenario, where
the container owner is only willing to trust their own public key, I
guess we can live with having to copy up the files.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:43 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 19:43 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Serge E. Hallyn, Stefan Berger, Mimi Zohar, Eric W. Biederman,
containers, lkp, linux-kernel, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
> On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
> >
> > If I'm understanding the discussion correctly, this isn't an issue for
> > layered copy on write filesystems, as each fs layer could have it's
> > own set of xattrs. The underlying and layered xattrs should be able
> > to co-exist. Use the layered xattr if it exists, but fall back to
> > using the underlying xattr if it doesn't.
>
> Note that this assumes that it is possible to "copy up" the xattrs
> without necessarily "copying up" all of the data blocks. This might
> be true for some layers, but I don't believe it is currently true for
> overlayfs, for example.
Ok, so for the use case scneario where the container owner is willing
to use the public key distributed with the files, then only those
files that are new or modified in the overlay would need to be signed
with a key local to the overlay. In the worst case scenario, where
the container owner is only willing to trust their own public key, I
guess we can live with having to copy up the files.
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com>]
[parent not found: <xagsmtp2.20170714182525.6604-SsZeXQfhYdoOFdY8m0e24VaTQe2KTcn/@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <xagsmtp2.20170714182525.6604-SsZeXQfhYdoOFdY8m0e24VaTQe2KTcn/@public.gmane.org>
@ 2017-07-14 19:26 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 19:26 UTC (permalink / raw)
To: Eric W. Biederman, Serge E. Hallyn
Cc: Theodore Ts'o, Mimi Zohar,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
> > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >> >>>
> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >> >>>>
> >> >>>>>My big question right now is can you implement Ted's suggested
> >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >> >>>>
> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> >> >>>>
> >> >>>The latter.
> >> >>That case would prevent a container user from overriding the xattr
> >> >>on the host. Is that what we want? For limiting the number of xattrs
> >> >Not really. If the file is owned by a uid mapped into the container,
> >> >then the container root can chown the file which will clear the file
> >> >capability, after which he can set a new one. If the file is not
> >> >owned by a uid mapped into the container, then container root could
> >> >not set a filecap anyway.
> >>
> >> Let's say I installed a container where all files are signed and
> >> thus have security.ima. Now for some reason I want to re-sign some
> >> or all files inside that container. How would I do that ? Would I
> >> need to get rid of security.ima first, possibly by copying each
> >> file, deleting the original file, and renaming the copied file to
> >> the original name, or should I just be able to write out a new
> >> signature, thus creating security.ima@uid=1000 besides the
> >> security.ima ?
> >>
> >> Stefan
> >
> > Hi Mimi,
> >
> > what do you think makes most sense for IMA?
>
> I am going to give my two cents since I have been thinking about this.
>
> First I think this entire scheme plays hobs with the security.evm
> attribute as security.evm needs to know the names of the xattrs to
> protect.
>
> I forget which attributes has a hash and what has a message
> athentication code.
security.ima contains either a file hash or a signature. (file data)
security.evm contains either a signature or an hmac of the security
xattrs and other file metadata. (file meta-data)
The same rules would apply to security.evm, as described in my
response. Based on it's view of the security xattrs, either the
native or namespace security.evm would be updated.
> If there is an attribute with a simple file hash I think it only make
> sense for the kernel to touch it, and I don't see any sense in having
> multiples.
Only files that are in the IMA-appraisal policy is the file hash
calculated and written out as security.ima. Depending this policy,
does the security.ima exist. So if the file is in policy for both the
native and namespace policies, agreed the same hash doesn't need to be
written as two different xattrs.
> If there is an attribute with a message authentication code (roughly a
> signed hash) it makes sense to have that to be tied to the kernel key
> ring that controlls the keys. (Which probably means a per user
> namespace thing at some point). But again pretty untouchable otherwise.
Right, the namespace would require it's own EVM key.
> Which brings us to the semantic question of would it be nice to have
> stacked IMA/EVM on the same file.
>
> I really don't think we do. I think allowing multiple keys for
> different part of trusting files is easy enough that we should have no
> need to fight over which keys do which.
We definitely want to support different policies on the native and in
the namespace with different keys and keyrings.
Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
of IMA namespacing - kernsec.org/pipermail/linux-security-module-
archive/2017-July/002286.html.
> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
> case I can think of for distributing a distribution image with ima/evm
> xattrs will need to use asymmetric keys aka public/private keypairs so
> that the originator of the content does not give away their private
> keys.
Agreed.
> Given that usefully we are talking about content that should be
> connected to keys in one way or another I don't believe it even makes
> sense at this point to attempt to use uids for dealing with ima and
> evm content.
We need to resolve the xattr issue in order to namespace IMA-
appraisal.
Mimi
> Further looking Serge's previous patch is 300 lines of code Setfan's
> patch that provides the possibility of code resuse is 500 lines of code.
>
> Increasingly it is looking to me that code reuse rather than concept
> reuse is a false economy. The code does not get smaller. The semantic
> differences make it problematic. Possibly to the problematic to the
> point where significant pieces may not be reused. The format breaks
> assumptions for other parts of the code like security.evm. The format
> by multiple names instead of a single attribute requires more disk
> access so is less efficient.
>
> In short I am seeing more code that runs slower and is harder to
> maintain. Please point out where I am wrong.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com>
[not found] ` <xagsmtp2.20170714182525.6604-SsZeXQfhYdoOFdY8m0e24VaTQe2KTcn/@public.gmane.org>
@ 2017-07-14 19:26 ` Mimi Zohar
1 sibling, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 19:26 UTC (permalink / raw)
To: Eric W. Biederman, Serge E. Hallyn
Cc: Stefan Berger, Mimi Zohar, Theodore Ts'o, containers, lkp,
linux-kernel, tycho, James.Bottomley, vgoyal, christian.brauner,
amir73il, linux-security-module, casey
On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
> > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >> >>>
> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >> >>>>
> >> >>>>>My big question right now is can you implement Ted's suggested
> >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >> >>>>
> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> >> >>>>
> >> >>>The latter.
> >> >>That case would prevent a container user from overriding the xattr
> >> >>on the host. Is that what we want? For limiting the number of xattrs
> >> >Not really. If the file is owned by a uid mapped into the container,
> >> >then the container root can chown the file which will clear the file
> >> >capability, after which he can set a new one. If the file is not
> >> >owned by a uid mapped into the container, then container root could
> >> >not set a filecap anyway.
> >>
> >> Let's say I installed a container where all files are signed and
> >> thus have security.ima. Now for some reason I want to re-sign some
> >> or all files inside that container. How would I do that ? Would I
> >> need to get rid of security.ima first, possibly by copying each
> >> file, deleting the original file, and renaming the copied file to
> >> the original name, or should I just be able to write out a new
> >> signature, thus creating security.ima@uid=1000 besides the
> >> security.ima ?
> >>
> >> Stefan
> >
> > Hi Mimi,
> >
> > what do you think makes most sense for IMA?
>
> I am going to give my two cents since I have been thinking about this.
>
> First I think this entire scheme plays hobs with the security.evm
> attribute as security.evm needs to know the names of the xattrs to
> protect.
>
> I forget which attributes has a hash and what has a message
> athentication code.
security.ima contains either a file hash or a signature. (file data)
security.evm contains either a signature or an hmac of the security
xattrs and other file metadata. (file meta-data)
The same rules would apply to security.evm, as described in my
response. Based on it's view of the security xattrs, either the
native or namespace security.evm would be updated.
> If there is an attribute with a simple file hash I think it only make
> sense for the kernel to touch it, and I don't see any sense in having
> multiples.
Only files that are in the IMA-appraisal policy is the file hash
calculated and written out as security.ima. Depending this policy,
does the security.ima exist. So if the file is in policy for both the
native and namespace policies, agreed the same hash doesn't need to be
written as two different xattrs.
> If there is an attribute with a message authentication code (roughly a
> signed hash) it makes sense to have that to be tied to the kernel key
> ring that controlls the keys. (Which probably means a per user
> namespace thing at some point). But again pretty untouchable otherwise.
Right, the namespace would require it's own EVM key.
> Which brings us to the semantic question of would it be nice to have
> stacked IMA/EVM on the same file.
>
> I really don't think we do. I think allowing multiple keys for
> different part of trusting files is easy enough that we should have no
> need to fight over which keys do which.
We definitely want to support different policies on the native and in
the namespace with different keys and keyrings.
Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
of IMA namespacing - kernsec.org/pipermail/linux-security-module-
archive/2017-July/002286.html.
> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
> case I can think of for distributing a distribution image with ima/evm
> xattrs will need to use asymmetric keys aka public/private keypairs so
> that the originator of the content does not give away their private
> keys.
Agreed.
> Given that usefully we are talking about content that should be
> connected to keys in one way or another I don't believe it even makes
> sense at this point to attempt to use uids for dealing with ima and
> evm content.
We need to resolve the xattr issue in order to namespace IMA-
appraisal.
Mimi
> Further looking Serge's previous patch is 300 lines of code Setfan's
> patch that provides the possibility of code resuse is 500 lines of code.
>
> Increasingly it is looking to me that code reuse rather than concept
> reuse is a false economy. The code does not get smaller. The semantic
> differences make it problematic. Possibly to the problematic to the
> point where significant pieces may not be reused. The format breaks
> assumptions for other parts of the code like security.evm. The format
> by multiple names instead of a single attribute requires more disk
> access so is less efficient.
>
> In short I am seeing more code that runs slower and is harder to
> maintain. Please point out where I am wrong.
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:26 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 19:26 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 5526 bytes --]
On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
> > Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >> >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >> >>>
> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >> >>>>
> >> >>>>>My big question right now is can you implement Ted's suggested
> >> >>>>>restriction. Only one security.foo or secuirty.foo(a)... attribute ?
> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >> >>>>
> >> >>>>So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
> >> >>>>
> >> >>>The latter.
> >> >>That case would prevent a container user from overriding the xattr
> >> >>on the host. Is that what we want? For limiting the number of xattrs
> >> >Not really. If the file is owned by a uid mapped into the container,
> >> >then the container root can chown the file which will clear the file
> >> >capability, after which he can set a new one. If the file is not
> >> >owned by a uid mapped into the container, then container root could
> >> >not set a filecap anyway.
> >>
> >> Let's say I installed a container where all files are signed and
> >> thus have security.ima. Now for some reason I want to re-sign some
> >> or all files inside that container. How would I do that ? Would I
> >> need to get rid of security.ima first, possibly by copying each
> >> file, deleting the original file, and renaming the copied file to
> >> the original name, or should I just be able to write out a new
> >> signature, thus creating security.ima(a)uid=1000 besides the
> >> security.ima ?
> >>
> >> Stefan
> >
> > Hi Mimi,
> >
> > what do you think makes most sense for IMA?
>
> I am going to give my two cents since I have been thinking about this.
>
> First I think this entire scheme plays hobs with the security.evm
> attribute as security.evm needs to know the names of the xattrs to
> protect.
>
> I forget which attributes has a hash and what has a message
> athentication code.
security.ima contains either a file hash or a signature. (file data)
security.evm contains either a signature or an hmac of the security
xattrs and other file metadata. (file meta-data)
The same rules would apply to security.evm, as described in my
response. Based on it's view of the security xattrs, either the
native or namespace security.evm would be updated.
> If there is an attribute with a simple file hash I think it only make
> sense for the kernel to touch it, and I don't see any sense in having
> multiples.
Only files that are in the IMA-appraisal policy is the file hash
calculated and written out as security.ima. Depending this policy,
does the security.ima exist. So if the file is in policy for both the
native and namespace policies, agreed the same hash doesn't need to be
written as two different xattrs.
> If there is an attribute with a message authentication code (roughly a
> signed hash) it makes sense to have that to be tied to the kernel key
> ring that controlls the keys. (Which probably means a per user
> namespace thing at some point). But again pretty untouchable otherwise.
Right, the namespace would require it's own EVM key.
> Which brings us to the semantic question of would it be nice to have
> stacked IMA/EVM on the same file.
>
> I really don't think we do. I think allowing multiple keys for
> different part of trusting files is easy enough that we should have no
> need to fight over which keys do which.
We definitely want to support different policies on the native and in
the namespace with different keys and keyrings.
Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
of IMA namespacing - kernsec.org/pipermail/linux-security-module-
archive/2017-July/002286.html.
> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
> case I can think of for distributing a distribution image with ima/evm
> xattrs will need to use asymmetric keys aka public/private keypairs so
> that the originator of the content does not give away their private
> keys.
Agreed.
> Given that usefully we are talking about content that should be
> connected to keys in one way or another I don't believe it even makes
> sense at this point to attempt to use uids for dealing with ima and
> evm content.
We need to resolve the xattr issue in order to namespace IMA-
appraisal.
Mimi
> Further looking Serge's previous patch is 300 lines of code Setfan's
> patch that provides the possibility of code resuse is 500 lines of code.
>
> Increasingly it is looking to me that code reuse rather than concept
> reuse is a false economy. The code does not get smaller. The semantic
> differences make it problematic. Possibly to the problematic to the
> point where significant pieces may not be reused. The format breaks
> assumptions for other parts of the code like security.evm. The format
> by multiple names instead of a single attribute requires more disk
> access so is less efficient.
>
> In short I am seeing more code that runs slower and is harder to
> maintain. Please point out where I am wrong.
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:26 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-14 19:26 UTC (permalink / raw)
To: linux-security-module
On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@hallyn.com> writes:
>
> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >> >>>
> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >> >>>>
> >> >>>>>My big question right now is can you implement Ted's suggested
> >> >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ?
> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >> >>>>
> >> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
> >> >>>>
> >> >>>The latter.
> >> >>That case would prevent a container user from overriding the xattr
> >> >>on the host. Is that what we want? For limiting the number of xattrs
> >> >Not really. If the file is owned by a uid mapped into the container,
> >> >then the container root can chown the file which will clear the file
> >> >capability, after which he can set a new one. If the file is not
> >> >owned by a uid mapped into the container, then container root could
> >> >not set a filecap anyway.
> >>
> >> Let's say I installed a container where all files are signed and
> >> thus have security.ima. Now for some reason I want to re-sign some
> >> or all files inside that container. How would I do that ? Would I
> >> need to get rid of security.ima first, possibly by copying each
> >> file, deleting the original file, and renaming the copied file to
> >> the original name, or should I just be able to write out a new
> >> signature, thus creating security.ima at uid=1000 besides the
> >> security.ima ?
> >>
> >> Stefan
> >
> > Hi Mimi,
> >
> > what do you think makes most sense for IMA?
>
> I am going to give my two cents since I have been thinking about this.
>
> First I think this entire scheme plays hobs with the security.evm
> attribute as security.evm needs to know the names of the xattrs to
> protect.
>
> I forget which attributes has a hash and what has a message
> athentication code.
security.ima contains either a file hash or a signature. (file data)
security.evm contains either a signature or an hmac of the security
xattrs and other file metadata. (file meta-data)
The same rules would apply to security.evm, as described in my
response. ?Based on it's view of the security xattrs, either the
native or namespace security.evm would be updated.
> If there is an attribute with a simple file hash I think it only make
> sense for the kernel to touch it, and I don't see any sense in having
> multiples.
Only files that are in the IMA-appraisal policy is the file hash
calculated and written out as security.ima. ?Depending this policy,
does the security.ima exist. ?So if the file is in policy for both the
native and namespace policies, agreed the same hash doesn't need to be
written as two different xattrs.
> If there is an attribute with a message authentication code (roughly a
> signed hash) it makes sense to have that to be tied to the kernel key
> ring that controlls the keys. (Which probably means a per user
> namespace thing at some point). But again pretty untouchable otherwise.
Right, the namespace would require it's own EVM key.
> Which brings us to the semantic question of would it be nice to have
> stacked IMA/EVM on the same file.
>
> I really don't think we do. I think allowing multiple keys for
> different part of trusting files is easy enough that we should have no
> need to fight over which keys do which.
We definitely want to support different policies on the native and in
the namespace with different keys and keyrings.
Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
of IMA namespacing - kernsec.org/pipermail/linux-security-module-
archive/2017-July/002286.html.
> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
> case I can think of for distributing a distribution image with ima/evm
> xattrs will need to use asymmetric keys aka public/private keypairs so
> that the originator of the content does not give away their private
> keys.
Agreed.
> Given that usefully we are talking about content that should be
> connected to keys in one way or another I don't believe it even makes
> sense at this point to attempt to use uids for dealing with ima and
> evm content.
We need to resolve the xattr issue in order to namespace IMA-
appraisal.?
Mimi
> Further looking Serge's previous patch is 300 lines of code Setfan's
> patch that provides the possibility of code resuse is 500 lines of code.
>
> Increasingly it is looking to me that code reuse rather than concept
> reuse is a false economy. The code does not get smaller. The semantic
> differences make it problematic. Possibly to the problematic to the
> point where significant pieces may not be reused. The format breaks
> assumptions for other parts of the code like security.evm. The format
> by multiple names instead of a single attribute requires more disk
> access so is less efficient.
>
> In short I am seeing more code that runs slower and is harder to
> maintain. Please point out where I am wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 19:26 ` Mimi Zohar
(?)
@ 2017-07-15 0:02 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-15 0:02 UTC (permalink / raw)
To: Mimi Zohar
Cc: Serge E. Hallyn, Stefan Berger, Mimi Zohar, Theodore Ts'o,
containers, lkp, linux-kernel, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
>> "Serge E. Hallyn" <serge@hallyn.com> writes:
>>
>> > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>> >> >>>
>> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >> >>>>
>> >> >>>>>My big question right now is can you implement Ted's suggested
>> >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
>> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >> >>>>
>> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >> >>>>
>> >> >>>The latter.
>> >> >>That case would prevent a container user from overriding the xattr
>> >> >>on the host. Is that what we want? For limiting the number of xattrs
>> >> >Not really. If the file is owned by a uid mapped into the container,
>> >> >then the container root can chown the file which will clear the file
>> >> >capability, after which he can set a new one. If the file is not
>> >> >owned by a uid mapped into the container, then container root could
>> >> >not set a filecap anyway.
>> >>
>> >> Let's say I installed a container where all files are signed and
>> >> thus have security.ima. Now for some reason I want to re-sign some
>> >> or all files inside that container. How would I do that ? Would I
>> >> need to get rid of security.ima first, possibly by copying each
>> >> file, deleting the original file, and renaming the copied file to
>> >> the original name, or should I just be able to write out a new
>> >> signature, thus creating security.ima@uid=1000 besides the
>> >> security.ima ?
>> >>
>> >> Stefan
>> >
>> > Hi Mimi,
>> >
>> > what do you think makes most sense for IMA?
>>
>> I am going to give my two cents since I have been thinking about this.
>>
>> First I think this entire scheme plays hobs with the security.evm
>> attribute as security.evm needs to know the names of the xattrs to
>> protect.
>>
>> I forget which attributes has a hash and what has a message
>> athentication code.
>
> security.ima contains either a file hash or a signature. (file data)
> security.evm contains either a signature or an hmac of the security
> xattrs and other file metadata. (file meta-data)
>
> The same rules would apply to security.evm, as described in my
> response. Based on it's view of the security xattrs, either the
> native or namespace security.evm would be updated.
>
>> If there is an attribute with a simple file hash I think it only make
>> sense for the kernel to touch it, and I don't see any sense in having
>> multiples.
>
> Only files that are in the IMA-appraisal policy is the file hash
> calculated and written out as security.ima. Depending this policy,
> does the security.ima exist. So if the file is in policy for both the
> native and namespace policies, agreed the same hash doesn't need to be
> written as two different xattrs.
>
>> If there is an attribute with a message authentication code (roughly a
>> signed hash) it makes sense to have that to be tied to the kernel key
>> ring that controlls the keys. (Which probably means a per user
>> namespace thing at some point). But again pretty untouchable otherwise.
>
> Right, the namespace would require it's own EVM key.
>
>> Which brings us to the semantic question of would it be nice to have
>> stacked IMA/EVM on the same file.
>>
>> I really don't think we do. I think allowing multiple keys for
>> different part of trusting files is easy enough that we should have no
>> need to fight over which keys do which.
>
> We definitely want to support different policies on the native and in
> the namespace with different keys and keyrings.
>
> Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
> of IMA namespacing - kernsec.org/pipermail/linux-security-module-
> archive/2017-July/002286.html.
>
>> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
>> case I can think of for distributing a distribution image with ima/evm
>> xattrs will need to use asymmetric keys aka public/private keypairs so
>> that the originator of the content does not give away their private
>> keys.
>
> Agreed.
>
>> Given that usefully we are talking about content that should be
>> connected to keys in one way or another I don't believe it even makes
>> sense at this point to attempt to use uids for dealing with ima and
>> evm content.
>
> We need to resolve the xattr issue in order to namespace IMA-
> appraisal.
Mimi I have two questions:
a) Is the keyid enough to distinguish the security.ima and security.evm
xattrs of one container from another container and from native? Or
do we have some important security xattrs that are associated with
keys that don't have a keyid?
b) Can we reasonably live with a limitation that the native and the
namespace'd policies don't intersect? Or in the case of an
interesection the native policy is the only one that is executed?
I submit that if the answer is keyids are always present, and we can
live with the native policy taking precedence over the container policy
then we have a solution to the IMA xattrs.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-15 0:02 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-15 0:02 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 5634 bytes --]
Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
>> "Serge E. Hallyn" <serge@hallyn.com> writes:
>>
>> > Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >> >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>> >> >>>
>> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >> >>>>
>> >> >>>>>My big question right now is can you implement Ted's suggested
>> >> >>>>>restriction. Only one security.foo or secuirty.foo(a)... attribute ?
>> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >> >>>>
>> >> >>>>So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >> >>>>
>> >> >>>The latter.
>> >> >>That case would prevent a container user from overriding the xattr
>> >> >>on the host. Is that what we want? For limiting the number of xattrs
>> >> >Not really. If the file is owned by a uid mapped into the container,
>> >> >then the container root can chown the file which will clear the file
>> >> >capability, after which he can set a new one. If the file is not
>> >> >owned by a uid mapped into the container, then container root could
>> >> >not set a filecap anyway.
>> >>
>> >> Let's say I installed a container where all files are signed and
>> >> thus have security.ima. Now for some reason I want to re-sign some
>> >> or all files inside that container. How would I do that ? Would I
>> >> need to get rid of security.ima first, possibly by copying each
>> >> file, deleting the original file, and renaming the copied file to
>> >> the original name, or should I just be able to write out a new
>> >> signature, thus creating security.ima(a)uid=1000 besides the
>> >> security.ima ?
>> >>
>> >> Stefan
>> >
>> > Hi Mimi,
>> >
>> > what do you think makes most sense for IMA?
>>
>> I am going to give my two cents since I have been thinking about this.
>>
>> First I think this entire scheme plays hobs with the security.evm
>> attribute as security.evm needs to know the names of the xattrs to
>> protect.
>>
>> I forget which attributes has a hash and what has a message
>> athentication code.
>
> security.ima contains either a file hash or a signature. (file data)
> security.evm contains either a signature or an hmac of the security
> xattrs and other file metadata. (file meta-data)
>
> The same rules would apply to security.evm, as described in my
> response. Based on it's view of the security xattrs, either the
> native or namespace security.evm would be updated.
>
>> If there is an attribute with a simple file hash I think it only make
>> sense for the kernel to touch it, and I don't see any sense in having
>> multiples.
>
> Only files that are in the IMA-appraisal policy is the file hash
> calculated and written out as security.ima. Depending this policy,
> does the security.ima exist. So if the file is in policy for both the
> native and namespace policies, agreed the same hash doesn't need to be
> written as two different xattrs.
>
>> If there is an attribute with a message authentication code (roughly a
>> signed hash) it makes sense to have that to be tied to the kernel key
>> ring that controlls the keys. (Which probably means a per user
>> namespace thing at some point). But again pretty untouchable otherwise.
>
> Right, the namespace would require it's own EVM key.
>
>> Which brings us to the semantic question of would it be nice to have
>> stacked IMA/EVM on the same file.
>>
>> I really don't think we do. I think allowing multiple keys for
>> different part of trusting files is easy enough that we should have no
>> need to fight over which keys do which.
>
> We definitely want to support different policies on the native and in
> the namespace with different keys and keyrings.
>
> Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
> of IMA namespacing - kernsec.org/pipermail/linux-security-module-
> archive/2017-July/002286.html.
>
>> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
>> case I can think of for distributing a distribution image with ima/evm
>> xattrs will need to use asymmetric keys aka public/private keypairs so
>> that the originator of the content does not give away their private
>> keys.
>
> Agreed.
>
>> Given that usefully we are talking about content that should be
>> connected to keys in one way or another I don't believe it even makes
>> sense at this point to attempt to use uids for dealing with ima and
>> evm content.
>
> We need to resolve the xattr issue in order to namespace IMA-
> appraisal.
Mimi I have two questions:
a) Is the keyid enough to distinguish the security.ima and security.evm
xattrs of one container from another container and from native? Or
do we have some important security xattrs that are associated with
keys that don't have a keyid?
b) Can we reasonably live with a limitation that the native and the
namespace'd policies don't intersect? Or in the case of an
interesection the native policy is the only one that is executed?
I submit that if the answer is keyids are always present, and we can
live with the native policy taking precedence over the container policy
then we have a solution to the IMA xattrs.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-15 0:02 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-15 0:02 UTC (permalink / raw)
To: linux-security-module
Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
>> "Serge E. Hallyn" <serge@hallyn.com> writes:
>>
>> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
>> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
>> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>> >> >>>
>> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >> >>>>
>> >> >>>>>My big question right now is can you implement Ted's suggested
>> >> >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ?
>> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >> >>>>
>> >> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >> >>>>
>> >> >>>The latter.
>> >> >>That case would prevent a container user from overriding the xattr
>> >> >>on the host. Is that what we want? For limiting the number of xattrs
>> >> >Not really. If the file is owned by a uid mapped into the container,
>> >> >then the container root can chown the file which will clear the file
>> >> >capability, after which he can set a new one. If the file is not
>> >> >owned by a uid mapped into the container, then container root could
>> >> >not set a filecap anyway.
>> >>
>> >> Let's say I installed a container where all files are signed and
>> >> thus have security.ima. Now for some reason I want to re-sign some
>> >> or all files inside that container. How would I do that ? Would I
>> >> need to get rid of security.ima first, possibly by copying each
>> >> file, deleting the original file, and renaming the copied file to
>> >> the original name, or should I just be able to write out a new
>> >> signature, thus creating security.ima at uid=1000 besides the
>> >> security.ima ?
>> >>
>> >> Stefan
>> >
>> > Hi Mimi,
>> >
>> > what do you think makes most sense for IMA?
>>
>> I am going to give my two cents since I have been thinking about this.
>>
>> First I think this entire scheme plays hobs with the security.evm
>> attribute as security.evm needs to know the names of the xattrs to
>> protect.
>>
>> I forget which attributes has a hash and what has a message
>> athentication code.
>
> security.ima contains either a file hash or a signature. (file data)
> security.evm contains either a signature or an hmac of the security
> xattrs and other file metadata. (file meta-data)
>
> The same rules would apply to security.evm, as described in my
> response. ?Based on it's view of the security xattrs, either the
> native or namespace security.evm would be updated.
>
>> If there is an attribute with a simple file hash I think it only make
>> sense for the kernel to touch it, and I don't see any sense in having
>> multiples.
>
> Only files that are in the IMA-appraisal policy is the file hash
> calculated and written out as security.ima. ?Depending this policy,
> does the security.ima exist. ?So if the file is in policy for both the
> native and namespace policies, agreed the same hash doesn't need to be
> written as two different xattrs.
>
>> If there is an attribute with a message authentication code (roughly a
>> signed hash) it makes sense to have that to be tied to the kernel key
>> ring that controlls the keys. (Which probably means a per user
>> namespace thing at some point). But again pretty untouchable otherwise.
>
> Right, the namespace would require it's own EVM key.
>
>> Which brings us to the semantic question of would it be nice to have
>> stacked IMA/EVM on the same file.
>>
>> I really don't think we do. I think allowing multiple keys for
>> different part of trusting files is easy enough that we should have no
>> need to fight over which keys do which.
>
> We definitely want to support different policies on the native and in
> the namespace with different keys and keyrings.
>
> Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
> of IMA namespacing - kernsec.org/pipermail/linux-security-module-
> archive/2017-July/002286.html.
>
>> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
>> case I can think of for distributing a distribution image with ima/evm
>> xattrs will need to use asymmetric keys aka public/private keypairs so
>> that the originator of the content does not give away their private
>> keys.
>
> Agreed.
>
>> Given that usefully we are talking about content that should be
>> connected to keys in one way or another I don't believe it even makes
>> sense at this point to attempt to use uids for dealing with ima and
>> evm content.
>
> We need to resolve the xattr issue in order to namespace IMA-
> appraisal.?
Mimi I have two questions:
a) Is the keyid enough to distinguish the security.ima and security.evm
xattrs of one container from another container and from native? Or
do we have some important security xattrs that are associated with
keys that don't have a keyid?
b) Can we reasonably live with a limitation that the native and the
namespace'd policies don't intersect? Or in the case of an
interesection the native policy is the only one that is executed?
I submit that if the answer is keyids are always present, and we can
live with the native policy taking precedence over the container policy
then we have a solution to the IMA xattrs.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <1500060374.3583.57.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1500060374.3583.57.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-15 0:02 ` Eric W. Biederman
2017-07-26 3:00 ` Serge E. Hallyn
1 sibling, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-15 0:02 UTC (permalink / raw)
To: Mimi Zohar
Cc: Theodore Ts'o, Mimi Zohar,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
>> "Serge E. Hallyn" <serge@hallyn.com> writes:
>>
>> > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>> >> >>>
>> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >> >>>>
>> >> >>>>>My big question right now is can you implement Ted's suggested
>> >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
>> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >> >>>>
>> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >> >>>>
>> >> >>>The latter.
>> >> >>That case would prevent a container user from overriding the xattr
>> >> >>on the host. Is that what we want? For limiting the number of xattrs
>> >> >Not really. If the file is owned by a uid mapped into the container,
>> >> >then the container root can chown the file which will clear the file
>> >> >capability, after which he can set a new one. If the file is not
>> >> >owned by a uid mapped into the container, then container root could
>> >> >not set a filecap anyway.
>> >>
>> >> Let's say I installed a container where all files are signed and
>> >> thus have security.ima. Now for some reason I want to re-sign some
>> >> or all files inside that container. How would I do that ? Would I
>> >> need to get rid of security.ima first, possibly by copying each
>> >> file, deleting the original file, and renaming the copied file to
>> >> the original name, or should I just be able to write out a new
>> >> signature, thus creating security.ima@uid=1000 besides the
>> >> security.ima ?
>> >>
>> >> Stefan
>> >
>> > Hi Mimi,
>> >
>> > what do you think makes most sense for IMA?
>>
>> I am going to give my two cents since I have been thinking about this.
>>
>> First I think this entire scheme plays hobs with the security.evm
>> attribute as security.evm needs to know the names of the xattrs to
>> protect.
>>
>> I forget which attributes has a hash and what has a message
>> athentication code.
>
> security.ima contains either a file hash or a signature. (file data)
> security.evm contains either a signature or an hmac of the security
> xattrs and other file metadata. (file meta-data)
>
> The same rules would apply to security.evm, as described in my
> response. Based on it's view of the security xattrs, either the
> native or namespace security.evm would be updated.
>
>> If there is an attribute with a simple file hash I think it only make
>> sense for the kernel to touch it, and I don't see any sense in having
>> multiples.
>
> Only files that are in the IMA-appraisal policy is the file hash
> calculated and written out as security.ima. Depending this policy,
> does the security.ima exist. So if the file is in policy for both the
> native and namespace policies, agreed the same hash doesn't need to be
> written as two different xattrs.
>
>> If there is an attribute with a message authentication code (roughly a
>> signed hash) it makes sense to have that to be tied to the kernel key
>> ring that controlls the keys. (Which probably means a per user
>> namespace thing at some point). But again pretty untouchable otherwise.
>
> Right, the namespace would require it's own EVM key.
>
>> Which brings us to the semantic question of would it be nice to have
>> stacked IMA/EVM on the same file.
>>
>> I really don't think we do. I think allowing multiple keys for
>> different part of trusting files is easy enough that we should have no
>> need to fight over which keys do which.
>
> We definitely want to support different policies on the native and in
> the namespace with different keys and keyrings.
>
> Refer to Mehmet Kaaylap's recent post, which refers to a PoC version
> of IMA namespacing - kernsec.org/pipermail/linux-security-module-
> archive/2017-July/002286.html.
>
>> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
>> case I can think of for distributing a distribution image with ima/evm
>> xattrs will need to use asymmetric keys aka public/private keypairs so
>> that the originator of the content does not give away their private
>> keys.
>
> Agreed.
>
>> Given that usefully we are talking about content that should be
>> connected to keys in one way or another I don't believe it even makes
>> sense at this point to attempt to use uids for dealing with ima and
>> evm content.
>
> We need to resolve the xattr issue in order to namespace IMA-
> appraisal.
Mimi I have two questions:
a) Is the keyid enough to distinguish the security.ima and security.evm
xattrs of one container from another container and from native? Or
do we have some important security xattrs that are associated with
keys that don't have a keyid?
b) Can we reasonably live with a limitation that the native and the
namespace'd policies don't intersect? Or in the case of an
interesection the native policy is the only one that is executed?
I submit that if the answer is keyids are always present, and we can
live with the native policy taking precedence over the container policy
then we have a solution to the IMA xattrs.
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 19:26 ` Mimi Zohar
(?)
@ 2017-07-26 3:00 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-26 3:00 UTC (permalink / raw)
To: Mimi Zohar
Cc: Theodore Ts'o, Mimi Zohar,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On Fri, Jul 14, 2017 at 03:26:14PM -0400, Mimi Zohar wrote:
> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> > Which brings us to the semantic question of would it be nice to have
> > stacked IMA/EVM on the same file.
> >
> > I really don't think we do. I think allowing multiple keys for
> > different part of trusting files is easy enough that we should have no
> > need to fight over which keys do which.
>
> We definitely want to support different policies on the native and in
> the namespace with different keys and keyrings.
Ok, so Stefan's code to support userspace in a container reading
security.ima and getting back the value for security.ima@uid=1000
(if 1000 is the kuid of the container's root user) is in fact
useful to IMA?
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-26 3:00 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-26 3:00 UTC (permalink / raw)
To: linux-security-module
On Fri, Jul 14, 2017 at 03:26:14PM -0400, Mimi Zohar wrote:
> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> > Which brings us to the semantic question of would it be nice to have
> > stacked IMA/EVM on the same file.
> >
> > I really don't think we do. I think allowing multiple keys for
> > different part of trusting files is easy enough that we should have no
> > need to fight over which keys do which.
>
> We definitely want to support different policies on the native and in
> the namespace with different keys and keyrings.
Ok, so Stefan's code to support userspace in a container reading
security.ima and getting back the value for security.ima at uid=1000
(if 1000 is the kuid of the container's root user) is in fact
useful to IMA?
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-26 3:00 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-26 3:00 UTC (permalink / raw)
To: Mimi Zohar
Cc: Eric W. Biederman, Serge E. Hallyn, Stefan Berger, Mimi Zohar,
Theodore Ts'o, containers, lkp, linux-kernel, tycho,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
On Fri, Jul 14, 2017 at 03:26:14PM -0400, Mimi Zohar wrote:
> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> > Which brings us to the semantic question of would it be nice to have
> > stacked IMA/EVM on the same file.
> >
> > I really don't think we do. I think allowing multiple keys for
> > different part of trusting files is easy enough that we should have no
> > need to fight over which keys do which.
>
> We definitely want to support different policies on the native and in
> the namespace with different keys and keyrings.
Ok, so Stefan's code to support userspace in a container reading
security.ima and getting back the value for security.ima@uid=1000
(if 1000 is the kuid of the container's root user) is in fact
useful to IMA?
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-26 3:00 ` Serge E. Hallyn
(?)
@ 2017-07-26 13:57 ` Mimi Zohar
-1 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-26 13:57 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Eric W. Biederman, Stefan Berger, Mimi Zohar, Theodore Ts'o,
containers, lkp, linux-kernel, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
On Tue, 2017-07-25 at 22:00 -0500, Serge E. Hallyn wrote:
> On Fri, Jul 14, 2017 at 03:26:14PM -0400, Mimi Zohar wrote:
> > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> > > Which brings us to the semantic question of would it be nice to have
> > > stacked IMA/EVM on the same file.
> > >
> > > I really don't think we do. I think allowing multiple keys for
> > > different part of trusting files is easy enough that we should have no
> > > need to fight over which keys do which.
> >
> > We definitely want to support different policies on the native and in
> > the namespace with different keys and keyrings.
>
> Ok, so Stefan's code to support userspace in a container reading
> security.ima and getting back the value for security.ima@uid=1000
> (if 1000 is the kuid of the container's root user) is in fact
> useful to IMA?
Definitely! Root within the namespace needs to be able to read and
write security.ima in order to (re)sign files, with a specific key
known to that container. Stefan's code provides different views of
the security xattrs.
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-26 13:57 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-26 13:57 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
On Tue, 2017-07-25 at 22:00 -0500, Serge E. Hallyn wrote:
> On Fri, Jul 14, 2017 at 03:26:14PM -0400, Mimi Zohar wrote:
> > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> > > Which brings us to the semantic question of would it be nice to have
> > > stacked IMA/EVM on the same file.
> > >
> > > I really don't think we do. I think allowing multiple keys for
> > > different part of trusting files is easy enough that we should have no
> > > need to fight over which keys do which.
> >
> > We definitely want to support different policies on the native and in
> > the namespace with different keys and keyrings.
>
> Ok, so Stefan's code to support userspace in a container reading
> security.ima and getting back the value for security.ima(a)uid=1000
> (if 1000 is the kuid of the container's root user) is in fact
> useful to IMA?
Definitely! Root within the namespace needs to be able to read and
write security.ima in order to (re)sign files, with a specific key
known to that container. Stefan's code provides different views of
the security xattrs.
Mimi
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-26 13:57 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-26 13:57 UTC (permalink / raw)
To: linux-security-module
On Tue, 2017-07-25 at 22:00 -0500, Serge E. Hallyn wrote:
> On Fri, Jul 14, 2017 at 03:26:14PM -0400, Mimi Zohar wrote:
> > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> > > Which brings us to the semantic question of would it be nice to have
> > > stacked IMA/EVM on the same file.
> > >
> > > I really don't think we do. I think allowing multiple keys for
> > > different part of trusting files is easy enough that we should have no
> > > need to fight over which keys do which.
> >
> > We definitely want to support different policies on the native and in
> > the namespace with different keys and keyrings.
>
> Ok, so Stefan's code to support userspace in a container reading
> security.ima and getting back the value for security.ima at uid=1000
> (if 1000 is the kuid of the container's root user) is in fact
> useful to IMA?
Definitely! ?Root within the namespace needs to be able to read and
write security.ima in order to (re)sign files, with a specific key
known to that container. ?Stefan's code provides different views of
the security xattrs.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170726030007.GA10087-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170726030007.GA10087-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
@ 2017-07-26 13:57 ` Mimi Zohar
0 siblings, 0 replies; 288+ messages in thread
From: Mimi Zohar @ 2017-07-26 13:57 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Theodore Ts'o, Mimi Zohar,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On Tue, 2017-07-25 at 22:00 -0500, Serge E. Hallyn wrote:
> On Fri, Jul 14, 2017 at 03:26:14PM -0400, Mimi Zohar wrote:
> > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> > > Which brings us to the semantic question of would it be nice to have
> > > stacked IMA/EVM on the same file.
> > >
> > > I really don't think we do. I think allowing multiple keys for
> > > different part of trusting files is easy enough that we should have no
> > > need to fight over which keys do which.
> >
> > We definitely want to support different policies on the native and in
> > the namespace with different keys and keyrings.
>
> Ok, so Stefan's code to support userspace in a container reading
> security.ima and getting back the value for security.ima@uid=1000
> (if 1000 is the kuid of the container's root user) is in fact
> useful to IMA?
Definitely! Root within the namespace needs to be able to read and
write security.ima in order to (re)sign files, with a specific key
known to that container. Stefan's code provides different views of
the security xattrs.
Mimi
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <xagsmtp3.20170715001054.9173@uk1vsc.vnet.ibm.com>]
[parent not found: <596f808b-e21d-8296-5fef-23c1ce7ab778-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <596f808b-e21d-8296-5fef-23c1ce7ab778-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-14 17:35 ` Serge E. Hallyn
2017-07-14 17:36 ` Eric W. Biederman
1 sibling, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-14 17:35 UTC (permalink / raw)
To: Stefan Berger, Mimi Zohar
Cc: Theodore Ts'o,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >>>Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> >>>
> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >>>>
> >>>>>My big question right now is can you implement Ted's suggested
> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >>>>
> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> >>>>
> >>>The latter.
> >>That case would prevent a container user from overriding the xattr
> >>on the host. Is that what we want? For limiting the number of xattrs
> >Not really. If the file is owned by a uid mapped into the container,
> >then the container root can chown the file which will clear the file
> >capability, after which he can set a new one. If the file is not
> >owned by a uid mapped into the container, then container root could
> >not set a filecap anyway.
>
> Let's say I installed a container where all files are signed and
> thus have security.ima. Now for some reason I want to re-sign some
> or all files inside that container. How would I do that ? Would I
> need to get rid of security.ima first, possibly by copying each
> file, deleting the original file, and renaming the copied file to
> the original name, or should I just be able to write out a new
> signature, thus creating security.ima@uid=1000 besides the
> security.ima ?
>
> Stefan
Hi Mimi,
what do you think makes most sense for IMA?
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 15:22 ` Stefan Berger
(?)
(?)
@ 2017-07-14 17:36 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 17:36 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
>>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>>> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>>>>
>>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>>
>>>>>> My big question right now is can you implement Ted's suggested
>>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>>
>>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>>
>>>> The latter.
>>> That case would prevent a container user from overriding the xattr
>>> on the host. Is that what we want? For limiting the number of xattrs
>> Not really. If the file is owned by a uid mapped into the container,
>> then the container root can chown the file which will clear the file
>> capability, after which he can set a new one. If the file is not
>> owned by a uid mapped into the container, then container root could
>> not set a filecap anyway.
>
> Let's say I installed a container where all files are signed and thus have
> security.ima. Now for some reason I want to re-sign some or all files inside
> that container. How would I do that ? Would I need to get rid of security.ima
> first, possibly by copying each file, deleting the original file, and renaming
> the copied file to the original name, or should I just be able to write out a
> new signature, thus creating security.ima@uid=1000 besides the security.ima ?
This gets us into some interesting territory, where the semantics of
these attributes matters.
The implementation of security.capable implements the security killpriv
hooks. Anyone merely by changing the file can cause the security
capability to go away. So it makes sense from the security.capable side
that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be
able to clear and set security.capable.
The integrity xattrs do not. Which results in very big semantic
difference between these two kinds of attributes. I am insufficiently
familiar with the rules for security.ima and security.evm to understand
what those rules should be.
That may be enough that we can not share code between these two cases.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 17:36 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 17:36 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>
>>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>>
>>>>>> My big question right now is can you implement Ted's suggested
>>>>>> restriction. Only one security.foo or secuirty.foo(a)... attribute ?
>>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>>
>>>>> So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>>
>>>> The latter.
>>> That case would prevent a container user from overriding the xattr
>>> on the host. Is that what we want? For limiting the number of xattrs
>> Not really. If the file is owned by a uid mapped into the container,
>> then the container root can chown the file which will clear the file
>> capability, after which he can set a new one. If the file is not
>> owned by a uid mapped into the container, then container root could
>> not set a filecap anyway.
>
> Let's say I installed a container where all files are signed and thus have
> security.ima. Now for some reason I want to re-sign some or all files inside
> that container. How would I do that ? Would I need to get rid of security.ima
> first, possibly by copying each file, deleting the original file, and renaming
> the copied file to the original name, or should I just be able to write out a
> new signature, thus creating security.ima(a)uid=1000 besides the security.ima ?
This gets us into some interesting territory, where the semantics of
these attributes matters.
The implementation of security.capable implements the security killpriv
hooks. Anyone merely by changing the file can cause the security
capability to go away. So it makes sense from the security.capable side
that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be
able to clear and set security.capable.
The integrity xattrs do not. Which results in very big semantic
difference between these two kinds of attributes. I am insufficiently
familiar with the rules for security.ima and security.evm to understand
what those rules should be.
That may be enough that we can not share code between these two cases.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 17:36 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 17:36 UTC (permalink / raw)
To: linux-security-module
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
>>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>
>>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>>
>>>>>> My big question right now is can you implement Ted's suggested
>>>>>> restriction. Only one security.foo or secuirty.foo at ... attribute ?
>>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>>
>>>>> So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>>
>>>> The latter.
>>> That case would prevent a container user from overriding the xattr
>>> on the host. Is that what we want? For limiting the number of xattrs
>> Not really. If the file is owned by a uid mapped into the container,
>> then the container root can chown the file which will clear the file
>> capability, after which he can set a new one. If the file is not
>> owned by a uid mapped into the container, then container root could
>> not set a filecap anyway.
>
> Let's say I installed a container where all files are signed and thus have
> security.ima. Now for some reason I want to re-sign some or all files inside
> that container. How would I do that ? Would I need to get rid of security.ima
> first, possibly by copying each file, deleting the original file, and renaming
> the copied file to the original name, or should I just be able to write out a
> new signature, thus creating security.ima at uid=1000 besides the security.ima ?
This gets us into some interesting territory, where the semantics of
these attributes matters.
The implementation of security.capable implements the security killpriv
hooks. Anyone merely by changing the file can cause the security
capability to go away. So it makes sense from the security.capable side
that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be
able to clear and set security.capable.
The integrity xattrs do not. Which results in very big semantic
difference between these two kinds of attributes. I am insufficiently
familiar with the rules for security.ima and security.evm to understand
what those rules should be.
That may be enough that we can not share code between these two cases.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 17:36 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 17:36 UTC (permalink / raw)
To: Stefan Berger
Cc: Serge E. Hallyn, Theodore Ts'o, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>
>>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>>
>>>>>> My big question right now is can you implement Ted's suggested
>>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>>
>>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>>
>>>> The latter.
>>> That case would prevent a container user from overriding the xattr
>>> on the host. Is that what we want? For limiting the number of xattrs
>> Not really. If the file is owned by a uid mapped into the container,
>> then the container root can chown the file which will clear the file
>> capability, after which he can set a new one. If the file is not
>> owned by a uid mapped into the container, then container root could
>> not set a filecap anyway.
>
> Let's say I installed a container where all files are signed and thus have
> security.ima. Now for some reason I want to re-sign some or all files inside
> that container. How would I do that ? Would I need to get rid of security.ima
> first, possibly by copying each file, deleting the original file, and renaming
> the copied file to the original name, or should I just be able to write out a
> new signature, thus creating security.ima@uid=1000 besides the security.ima ?
This gets us into some interesting territory, where the semantics of
these attributes matters.
The implementation of security.capable implements the security killpriv
hooks. Anyone merely by changing the file can cause the security
capability to go away. So it makes sense from the security.capable side
that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be
able to clear and set security.capable.
The integrity xattrs do not. Which results in very big semantic
difference between these two kinds of attributes. I am insufficiently
familiar with the rules for security.ima and security.evm to understand
what those rules should be.
That may be enough that we can not share code between these two cases.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <87pod22a4x.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <87pod22a4x.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2017-07-14 19:22 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 19:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On 07/14/2017 01:36 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>>> Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
>>>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>>>> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>>>>>
>>>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>>>
>>>>>>> My big question right now is can you implement Ted's suggested
>>>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>>>
>>>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>>>
>>>>> The latter.
>>>> That case would prevent a container user from overriding the xattr
>>>> on the host. Is that what we want? For limiting the number of xattrs
>>> Not really. If the file is owned by a uid mapped into the container,
>>> then the container root can chown the file which will clear the file
>>> capability, after which he can set a new one. If the file is not
>>> owned by a uid mapped into the container, then container root could
>>> not set a filecap anyway.
>> Let's say I installed a container where all files are signed and thus have
>> security.ima. Now for some reason I want to re-sign some or all files inside
>> that container. How would I do that ? Would I need to get rid of security.ima
>> first, possibly by copying each file, deleting the original file, and renaming
>> the copied file to the original name, or should I just be able to write out a
>> new signature, thus creating security.ima@uid=1000 besides the security.ima ?
> This gets us into some interesting territory, where the semantics of
> these attributes matters.
>
> The implementation of security.capable implements the security killpriv
> hooks. Anyone merely by changing the file can cause the security
> capability to go away. So it makes sense from the security.capable side
> that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be
> able to clear and set security.capable.
>
> The integrity xattrs do not. Which results in very big semantic
> difference between these two kinds of attributes. I am insufficiently
> familiar with the rules for security.ima and security.evm to understand
> what those rules should be.
>
> That may be enough that we can not share code between these two cases.
On the host I can simply overwrite capabilities. I think the same model
should apply to the virtualized world. The difference still is that
removing an xattr, if written on the host, may only be possible by copy
+ file move to original filename.
On IMA, when appending a letter to an executable, the executable doesn't
run anymore when appraisal is used, but the signature is still there and
needs to be re-written. Though I think this aspect on how they disappear
doesn't matter as much if they can simply be overwritten.
Some things could certainly be solved with flags indicating behaviors of
xattrs for as long as these flags only affect the reading, listing, and
re-writing of the virtualized xattrs, which is what the patch does. For
example a flag for security.capability could say that only a single
'security.capability(@uid=<uid>)?' may exist while security.ima could
have two.
Stefan
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 17:36 ` Eric W. Biederman
(?)
@ 2017-07-14 19:22 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 19:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge E. Hallyn, Theodore Ts'o, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
On 07/14/2017 01:36 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>>> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>>>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>>
>>>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>>>
>>>>>>> My big question right now is can you implement Ted's suggested
>>>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>>>
>>>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>>>
>>>>> The latter.
>>>> That case would prevent a container user from overriding the xattr
>>>> on the host. Is that what we want? For limiting the number of xattrs
>>> Not really. If the file is owned by a uid mapped into the container,
>>> then the container root can chown the file which will clear the file
>>> capability, after which he can set a new one. If the file is not
>>> owned by a uid mapped into the container, then container root could
>>> not set a filecap anyway.
>> Let's say I installed a container where all files are signed and thus have
>> security.ima. Now for some reason I want to re-sign some or all files inside
>> that container. How would I do that ? Would I need to get rid of security.ima
>> first, possibly by copying each file, deleting the original file, and renaming
>> the copied file to the original name, or should I just be able to write out a
>> new signature, thus creating security.ima@uid=1000 besides the security.ima ?
> This gets us into some interesting territory, where the semantics of
> these attributes matters.
>
> The implementation of security.capable implements the security killpriv
> hooks. Anyone merely by changing the file can cause the security
> capability to go away. So it makes sense from the security.capable side
> that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be
> able to clear and set security.capable.
>
> The integrity xattrs do not. Which results in very big semantic
> difference between these two kinds of attributes. I am insufficiently
> familiar with the rules for security.ima and security.evm to understand
> what those rules should be.
>
> That may be enough that we can not share code between these two cases.
On the host I can simply overwrite capabilities. I think the same model
should apply to the virtualized world. The difference still is that
removing an xattr, if written on the host, may only be possible by copy
+ file move to original filename.
On IMA, when appending a letter to an executable, the executable doesn't
run anymore when appraisal is used, but the signature is still there and
needs to be re-written. Though I think this aspect on how they disappear
doesn't matter as much if they can simply be overwritten.
Some things could certainly be solved with flags indicating behaviors of
xattrs for as long as these flags only affect the reading, listing, and
re-writing of the virtualized xattrs, which is what the patch does. For
example a flag for security.capability could say that only a single
'security.capability(@uid=<uid>)?' may exist while security.ima could
have two.
Stefan
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:22 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 19:22 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]
On 07/14/2017 01:36 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>>> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>>>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>>
>>>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>>>
>>>>>>> My big question right now is can you implement Ted's suggested
>>>>>>> restriction. Only one security.foo or secuirty.foo(a)... attribute ?
>>>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>>>
>>>>>> So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>>>
>>>>> The latter.
>>>> That case would prevent a container user from overriding the xattr
>>>> on the host. Is that what we want? For limiting the number of xattrs
>>> Not really. If the file is owned by a uid mapped into the container,
>>> then the container root can chown the file which will clear the file
>>> capability, after which he can set a new one. If the file is not
>>> owned by a uid mapped into the container, then container root could
>>> not set a filecap anyway.
>> Let's say I installed a container where all files are signed and thus have
>> security.ima. Now for some reason I want to re-sign some or all files inside
>> that container. How would I do that ? Would I need to get rid of security.ima
>> first, possibly by copying each file, deleting the original file, and renaming
>> the copied file to the original name, or should I just be able to write out a
>> new signature, thus creating security.ima(a)uid=1000 besides the security.ima ?
> This gets us into some interesting territory, where the semantics of
> these attributes matters.
>
> The implementation of security.capable implements the security killpriv
> hooks. Anyone merely by changing the file can cause the security
> capability to go away. So it makes sense from the security.capable side
> that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be
> able to clear and set security.capable.
>
> The integrity xattrs do not. Which results in very big semantic
> difference between these two kinds of attributes. I am insufficiently
> familiar with the rules for security.ima and security.evm to understand
> what those rules should be.
>
> That may be enough that we can not share code between these two cases.
On the host I can simply overwrite capabilities. I think the same model
should apply to the virtualized world. The difference still is that
removing an xattr, if written on the host, may only be possible by copy
+ file move to original filename.
On IMA, when appending a letter to an executable, the executable doesn't
run anymore when appraisal is used, but the signature is still there and
needs to be re-written. Though I think this aspect on how they disappear
doesn't matter as much if they can simply be overwritten.
Some things could certainly be solved with flags indicating behaviors of
xattrs for as long as these flags only affect the reading, listing, and
re-writing of the virtualized xattrs, which is what the patch does. For
example a flag for security.capability could say that only a single
'security.capability(@uid=<uid>)?' may exist while security.ima could
have two.
Stefan
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 19:22 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 19:22 UTC (permalink / raw)
To: linux-security-module
On 07/14/2017 01:36 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>>> Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
>>>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>>>
>>>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>>>
>>>>>>> My big question right now is can you implement Ted's suggested
>>>>>>> restriction. Only one security.foo or secuirty.foo at ... attribute ?
>>>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>>>
>>>>>> So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>>>
>>>>> The latter.
>>>> That case would prevent a container user from overriding the xattr
>>>> on the host. Is that what we want? For limiting the number of xattrs
>>> Not really. If the file is owned by a uid mapped into the container,
>>> then the container root can chown the file which will clear the file
>>> capability, after which he can set a new one. If the file is not
>>> owned by a uid mapped into the container, then container root could
>>> not set a filecap anyway.
>> Let's say I installed a container where all files are signed and thus have
>> security.ima. Now for some reason I want to re-sign some or all files inside
>> that container. How would I do that ? Would I need to get rid of security.ima
>> first, possibly by copying each file, deleting the original file, and renaming
>> the copied file to the original name, or should I just be able to write out a
>> new signature, thus creating security.ima at uid=1000 besides the security.ima ?
> This gets us into some interesting territory, where the semantics of
> these attributes matters.
>
> The implementation of security.capable implements the security killpriv
> hooks. Anyone merely by changing the file can cause the security
> capability to go away. So it makes sense from the security.capable side
> that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be
> able to clear and set security.capable.
>
> The integrity xattrs do not. Which results in very big semantic
> difference between these two kinds of attributes. I am insufficiently
> familiar with the rules for security.ima and security.evm to understand
> what those rules should be.
>
> That may be enough that we can not share code between these two cases.
On the host I can simply overwrite capabilities. I think the same model
should apply to the virtualized world. The difference still is that
removing an xattr, if written on the host, may only be possible by copy
+ file move to original filename.
On IMA, when appending a letter to an executable, the executable doesn't
run anymore when appraisal is used, but the signature is still there and
needs to be re-written. Though I think this aspect on how they disappear
doesn't matter as much if they can simply be overwritten.
Some things could certainly be solved with flags indicating behaviors of
xattrs for as long as these flags only affect the reading, listing, and
re-writing of the virtualized xattrs, which is what the patch does. For
example a flag for security.capability could say that only a single
'security.capability(@uid=<uid>)?' may exist while security.ima could
have two.
Stefan
>
> Eric
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170714133437.GA16737-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170714133437.GA16737-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
@ 2017-07-14 15:22 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 15:22 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr
>> on the host. Is that what we want? For limiting the number of xattrs
> Not really. If the file is owned by a uid mapped into the container,
> then the container root can chown the file which will clear the file
> capability, after which he can set a new one. If the file is not
> owned by a uid mapped into the container, then container root could
> not set a filecap anyway.
Let's say I installed a container where all files are signed and thus
have security.ima. Now for some reason I want to re-sign some or all
files inside that container. How would I do that ? Would I need to get
rid of security.ima first, possibly by copying each file, deleting the
original file, and renaming the copied file to the original name, or
should I just be able to write out a new signature, thus creating
security.ima@uid=1000 besides the security.ima ?
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <65dbe654-0d99-03fa-c838-5a726b462826-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 11:32 ` Stefan Berger
(?)
(?)
@ 2017-07-14 12:04 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 12:04 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>>
>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>
>>>> My big question right now is can you implement Ted's suggested
>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>
>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>
>> The latter.
>
> That case would prevent a container user from overriding the xattr on
> the host. Is that what we want?
Most definitely. If a more privileged use has set secure.capable that
is better.
> For limiting the number of xattrs and
> getting that functionality (override IMA signature for example) the
> former seems better...
I don't know about IMA. But my feeling is that we will only be dealing
with a single signing key, so I don't see how having multiple IMA xattrs
make sense. Could you explain that to me?
> For the former I now have the topmost patch here:
> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Thank you.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 12:04 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 12:04 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>
>>>> My big question right now is can you implement Ted's suggested
>>>> restriction. Only one security.foo or secuirty.foo(a)... attribute ?
>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>
>>> So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>
>> The latter.
>
> That case would prevent a container user from overriding the xattr on
> the host. Is that what we want?
Most definitely. If a more privileged use has set secure.capable that
is better.
> For limiting the number of xattrs and
> getting that functionality (override IMA signature for example) the
> former seems better...
I don't know about IMA. But my feeling is that we will only be dealing
with a single signing key, so I don't see how having multiple IMA xattrs
make sense. Could you explain that to me?
> For the former I now have the topmost patch here:
> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Thank you.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 12:04 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 12:04 UTC (permalink / raw)
To: linux-security-module
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>
>>>> My big question right now is can you implement Ted's suggested
>>>> restriction. Only one security.foo or secuirty.foo at ... attribute ?
>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>
>>> So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>
>> The latter.
>
> That case would prevent a container user from overriding the xattr on
> the host. Is that what we want?
Most definitely. If a more privileged use has set secure.capable that
is better.
> For limiting the number of xattrs and
> getting that functionality (override IMA signature for example) the
> former seems better...
I don't know about IMA. But my feeling is that we will only be dealing
with a single signing key, so I don't see how having multiple IMA xattrs
make sense. Could you explain that to me?
> For the former I now have the topmost patch here:
> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Thank you.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 12:04 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 12:04 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, Serge E. Hallyn, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>
>>>> My big question right now is can you implement Ted's suggested
>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>
>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>
>> The latter.
>
> That case would prevent a container user from overriding the xattr on
> the host. Is that what we want?
Most definitely. If a more privileged use has set secure.capable that
is better.
> For limiting the number of xattrs and
> getting that functionality (override IMA signature for example) the
> former seems better...
I don't know about IMA. But my feeling is that we will only be dealing
with a single signing key, so I don't see how having multiple IMA xattrs
make sense. Could you explain that to me?
> For the former I now have the topmost patch here:
> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Thank you.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <87vamv2pj0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 12:04 ` Eric W. Biederman
(?)
(?)
@ 2017-07-14 12:39 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 12:39 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
On 07/14/2017 08:04 AM, Eric W. Biederman wrote:
> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr on
>> the host. Is that what we want?
> Most definitely. If a more privileged use has set secure.capable that
> is better.
>
>> For limiting the number of xattrs and
>> getting that functionality (override IMA signature for example) the
>> former seems better...
> I don't know about IMA. But my feeling is that we will only be dealing
> with a single signing key, so I don't see how having multiple IMA xattrs
> make sense. Could you explain that to me?
Admittedly I would need to construct and example where the user inside
the container doesn't want to share the public key with the host on a
file mounted from the host for some reason.
An example related to security.capability could be a Fedora Docker
container where the container is distributed with the ping tool
installed. The ping tool is installed with cap_net_admin,cap_net_raw+ep.
On a normal Fedora container I cannot use this tool due to my
capabilities bounding set not including cap_net_admin. So, I overwrite
this and set only cap_net_raw+ep and I can use for pinging. I may loose
some functionality on the way due to the lost cap_net_admin but I can
now use the tool. I guess the point is one can override the capabilities
set of a distributed container if the container is started with less
capabilities.
Stefan
>
>> For the former I now have the topmost patch here:
>> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
> Thank you.
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 12:39 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 12:39 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]
On 07/14/2017 08:04 AM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo(a)... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr on
>> the host. Is that what we want?
> Most definitely. If a more privileged use has set secure.capable that
> is better.
>
>> For limiting the number of xattrs and
>> getting that functionality (override IMA signature for example) the
>> former seems better...
> I don't know about IMA. But my feeling is that we will only be dealing
> with a single signing key, so I don't see how having multiple IMA xattrs
> make sense. Could you explain that to me?
Admittedly I would need to construct and example where the user inside
the container doesn't want to share the public key with the host on a
file mounted from the host for some reason.
An example related to security.capability could be a Fedora Docker
container where the container is distributed with the ping tool
installed. The ping tool is installed with cap_net_admin,cap_net_raw+ep.
On a normal Fedora container I cannot use this tool due to my
capabilities bounding set not including cap_net_admin. So, I overwrite
this and set only cap_net_raw+ep and I can use for pinging. I may loose
some functionality on the way due to the lost cap_net_admin but I can
now use the tool. I guess the point is one can override the capabilities
set of a distributed container if the container is started with less
capabilities.
Stefan
>
>> For the former I now have the topmost patch here:
>> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
> Thank you.
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 12:39 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 12:39 UTC (permalink / raw)
To: linux-security-module
On 07/14/2017 08:04 AM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo at ... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr on
>> the host. Is that what we want?
> Most definitely. If a more privileged use has set secure.capable that
> is better.
>
>> For limiting the number of xattrs and
>> getting that functionality (override IMA signature for example) the
>> former seems better...
> I don't know about IMA. But my feeling is that we will only be dealing
> with a single signing key, so I don't see how having multiple IMA xattrs
> make sense. Could you explain that to me?
Admittedly I would need to construct and example where the user inside
the container doesn't want to share the public key with the host on a
file mounted from the host for some reason.
An example related to security.capability could be a Fedora Docker
container where the container is distributed with the ping tool
installed. The ping tool is installed with cap_net_admin,cap_net_raw+ep.
On a normal Fedora container I cannot use this tool due to my
capabilities bounding set not including cap_net_admin. So, I overwrite
this and set only cap_net_raw+ep and I can use for pinging. I may loose
some functionality on the way due to the lost cap_net_admin but I can
now use the tool. I guess the point is one can override the capabilities
set of a distributed container if the container is started with less
capabilities.
Stefan
>
>> For the former I now have the topmost patch here:
>> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
> Thank you.
>
> Eric
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 12:39 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-14 12:39 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, Serge E. Hallyn, containers, lkp,
linux-kernel, zohar, tycho, James.Bottomley, vgoyal,
christian.brauner, amir73il, linux-security-module, casey
On 07/14/2017 08:04 AM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr on
>> the host. Is that what we want?
> Most definitely. If a more privileged use has set secure.capable that
> is better.
>
>> For limiting the number of xattrs and
>> getting that functionality (override IMA signature for example) the
>> former seems better...
> I don't know about IMA. But my feeling is that we will only be dealing
> with a single signing key, so I don't see how having multiple IMA xattrs
> make sense. Could you explain that to me?
Admittedly I would need to construct and example where the user inside
the container doesn't want to share the public key with the host on a
file mounted from the host for some reason.
An example related to security.capability could be a Fedora Docker
container where the container is distributed with the ping tool
installed. The ping tool is installed with cap_net_admin,cap_net_raw+ep.
On a normal Fedora container I cannot use this tool due to my
capabilities bounding set not including cap_net_admin. So, I overwrite
this and set only cap_net_raw+ep and I can use for pinging. I may loose
some functionality on the way due to the lost cap_net_admin but I can
now use the tool. I guess the point is one can override the capabilities
set of a distributed container if the container is started with less
capabilities.
Stefan
>
>> For the former I now have the topmost patch here:
>> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
> Thank you.
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <65dbe654-0d99-03fa-c838-5a726b462826-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-14 12:04 ` Eric W. Biederman
@ 2017-07-14 13:34 ` Serge E. Hallyn
1 sibling, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-14 13:34 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> >Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> >
> >>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> >>
> >>>My big question right now is can you implement Ted's suggested
> >>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> >>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> >>
> >>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> >>
> >The latter.
>
> That case would prevent a container user from overriding the xattr
> on the host. Is that what we want? For limiting the number of xattrs
Not really. If the file is owned by a uid mapped into the container,
then the container root can chown the file which will clear the file
capability, after which he can set a new one. If the file is not
owned by a uid mapped into the container, then container root could
not set a filecap anyway.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <847ccb2a-30c0-a94c-df6f-091c8901eaa0-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-13 17:49 ` Eric W. Biederman
@ 2017-07-13 21:21 ` Serge E. Hallyn
1 sibling, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:21 UTC (permalink / raw)
To: Stefan Berger
Cc: Theodore Ts'o, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
casey-iSGtlc1asvQWG2LlvL+J4A, lkp-JC7UmRfGjtg
Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> For virtualizing the xattrs on the 'value' side I was looking for
> whether there's something like a 'wrapper' structure around the
> actual value of the xattr so that that wrapper could be extended to
> support different values at different uids and applied to any xattr.
> Unfortunately there's no such 'wrapper'.
I believe my very first implementation did essentially this - it used
the not uncommon structure of (mostly making this up):
struct ns_vfs_cap {
int magic;
int ncaps;
struct ns_vfs_cap_data data[0];
};
with (ncaps * sizeof(ns_vfs_cap_data)) following that.
I didn't like it.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 17:33 ` Stefan Berger
@ 2017-07-13 21:21 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:21 UTC (permalink / raw)
To: Stefan Berger
Cc: Eric W. Biederman, Theodore Ts'o, Serge E. Hallyn,
containers, lkp, linux-kernel, zohar, tycho, James.Bottomley,
vgoyal, christian.brauner, amir73il, linux-security-module,
casey
Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> For virtualizing the xattrs on the 'value' side I was looking for
> whether there's something like a 'wrapper' structure around the
> actual value of the xattr so that that wrapper could be extended to
> support different values at different uids and applied to any xattr.
> Unfortunately there's no such 'wrapper'.
I believe my very first implementation did essentially this - it used
the not uncommon structure of (mostly making this up):
struct ns_vfs_cap {
int magic;
int ncaps;
struct ns_vfs_cap_data data[0];
};
with (ncaps * sizeof(ns_vfs_cap_data)) following that.
I didn't like it.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 21:21 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:21 UTC (permalink / raw)
To: linux-security-module
Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
> For virtualizing the xattrs on the 'value' side I was looking for
> whether there's something like a 'wrapper' structure around the
> actual value of the xattr so that that wrapper could be extended to
> support different values at different uids and applied to any xattr.
> Unfortunately there's no such 'wrapper'.
I believe my very first implementation did essentially this - it used
the not uncommon structure of (mostly making this up):
struct ns_vfs_cap {
int magic;
int ncaps;
struct ns_vfs_cap_data data[0];
};
with (ncaps * sizeof(ns_vfs_cap_data)) following that.
I didn't like it.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <87k23cb6os.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <87k23cb6os.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2017-07-13 17:33 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 17:33 UTC (permalink / raw)
To: Eric W. Biederman, Theodore Ts'o
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
> Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> writes:
>
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo@uid=15000
>>
>> It's not like there will be:
>>
>> security.foo@uid=1000
>> security.foo@uid=2000
>>
>> Except.... if you have an Distribution root directory which is shared
>> by many containers, you would need to put the xattrs in the overlay
>> inodes. Worse, each time you launch a new container, with a new
>> subuid allocation, you will have to iterate over all files with
>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> So that's actually a bit of a disaster.
>>
>> So for distribution overlays, you will need to do things a different
>> way, which is to map the distro subdirectory so you know that the
>> capability with the global uid 0 should be used for the container
>> "root" uid, right?
>>
>> So this hack of using security.foo@uid=1000 is *only* useful when the
>> subcontainer root wants to create the privileged executable. You
>> still have to do things the other way.
>>
>> So can we make perhaps the assertion that *either*:
>>
>> security.foo
>>
>> exists, *or*
>>
>> security.foo@uid=BAR
>>
>> exists, but never both? And there BAR is exclusive to only one
>> instances?
>>
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
> Yep. That is what it looks like from here.
>
> Which is why I asked the question about scalability of the xattr
> implementations. It looks like trying to accomodate the general
> case just gets us in trouble, and sets unrealistic expectations.
>
> Which strongly suggests that Serge's previous version that
> just reved the format of security.capable so that a uid field could
> be added is likely to be the better approach.
>
> I want to see what Serge and Stefan have to say but the case looks
> pretty clear cut at the moment.
The approach of virtualizing the xattrs on the name-side, which is what
this patch does, provides a more general approach than to virtualizing
it on the value side, which is what Serge does in his other patch for
security.capability alone. With the virtualizing on-the-value side
virtualizing the xattr becomes an exercise that needs to be repeated for
every xattr name that one would want to virtualize. With this patch you
would just add another xattr name to a list, a one-line patch in the
end. Xattr with prefixes like trusted.* need a bit more work but this
can be woven in as well
(https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
For virtualizing the xattrs on the 'value' side I was looking for
whether there's something like a 'wrapper' structure around the actual
value of the xattr so that that wrapper could be extended to support
different values at different uids and applied to any xattr.
Unfortunately there's no such 'wrapper'.
Stefan
>
> Eric
>
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170713164012.brj2flnkaaks2oci-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170713164012.brj2flnkaaks2oci-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
@ 2017-07-13 17:05 ` Stefan Berger
2017-07-13 17:14 ` Eric W. Biederman
2017-07-13 21:13 ` Serge E. Hallyn
2 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-13 17:05 UTC (permalink / raw)
To: Theodore Ts'o, Eric W. Biederman, Serge E. Hallyn,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lkp-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
tycho-FCduhRhOUaTQT0dZR+AlfA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA,
christian.brauner-cl+VPiYnx/1AfugRpC6u6w,
amir73il-Re5JQEeQqe8AvxtiuMwx3w,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A
On 07/13/2017 12:40 PM, Theodore Ts'o wrote:
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> The concise summary:
>>
>> Today we have the xattr security.capable that holds a set of
>> capabilities that an application gains when executed. AKA setuid root exec
>> without actually being setuid root.
>>
>> User namespaces have the concept of capabilities that are not global but
>> are limited to their user namespace. We do not currently have
>> filesystem support for this concept.
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo@uid=15000
>
> It's not like there will be:
>
> security.foo@uid=1000
> security.foo@uid=2000
A file shared by 2 containers, one mapping root to uid=1000, the other
mapping root to uid=2000, will show these two xattrs on the host
(init_user_ns) once these containers set xattrs on that file.
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes. Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
Note that we do keep compatibility to existing behavior. The
security.foo of the host is visible inside any container for as long as
the container root user doesn't set its own security.foo on that file,
which then hides it. Does that address this concern?
>
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo@uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo@uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
In the current implementation BAR is visible inside of any instance that
'covers' this uid with the mapping range. Above example of
security.foo@uid=1000 appears as security.foo inside the container with
root mapping to uid 1000 (@uid=0 is suppressed) but also appears as
security.foo@uid=100 with root uid mapping to 900 (and range of at least
101).
>
> Otherwise, I suspect that the architecture is going to turn around and
> bite us in the *ss eventually, because someone will want to do
> something crazy and the solution will not be scalable.
Can you define what 'scalable' means for you in this context?
From what I can see sharing a filesystem between multiple containers
doesn't 'scale well' for virtualizing the xattrs primarily because of
size limitations of xattrs per file.
Stefan
>
> -Ted
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170713164012.brj2flnkaaks2oci-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-13 17:05 ` Stefan Berger
@ 2017-07-13 17:14 ` Eric W. Biederman
2017-07-13 21:13 ` Serge E. Hallyn
2 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-13 17:14 UTC (permalink / raw)
To: Theodore Ts'o
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> writes:
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> The concise summary:
>>
>> Today we have the xattr security.capable that holds a set of
>> capabilities that an application gains when executed. AKA setuid root exec
>> without actually being setuid root.
>>
>> User namespaces have the concept of capabilities that are not global but
>> are limited to their user namespace. We do not currently have
>> filesystem support for this concept.
>
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo@uid=15000
>
> It's not like there will be:
>
> security.foo@uid=1000
> security.foo@uid=2000
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes. Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
>
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo@uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo@uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
>
> Otherwise, I suspect that the architecture is going to turn around and
> bite us in the *ss eventually, because someone will want to do
> something crazy and the solution will not be scalable.
Yep. That is what it looks like from here.
Which is why I asked the question about scalability of the xattr
implementations. It looks like trying to accomodate the general
case just gets us in trouble, and sets unrealistic expectations.
Which strongly suggests that Serge's previous version that
just reved the format of security.capable so that a uid field could
be added is likely to be the better approach.
I want to see what Serge and Stefan have to say but the case looks
pretty clear cut at the moment.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170713164012.brj2flnkaaks2oci-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-13 17:05 ` Stefan Berger
2017-07-13 17:14 ` Eric W. Biederman
@ 2017-07-13 21:13 ` Serge E. Hallyn
2 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:13 UTC (permalink / raw)
To: Theodore Ts'o, Eric W. Biederman, Stefan Berger,
Serge E. Hallyn,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lkp-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
tycho-FCduhRhOUaTQT0dZR+AlfA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA,
christian.brauner-cl+VPiYnx/1AfugRpC6u6w,
amir73il-Re5JQEeQqe8AvxtiuMwx3w,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A
Quoting Theodore Ts'o (tytso-3s7WtUTddSA@public.gmane.org):
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> > The concise summary:
> >
> > Today we have the xattr security.capable that holds a set of
> > capabilities that an application gains when executed. AKA setuid root exec
> > without actually being setuid root.
> >
> > User namespaces have the concept of capabilities that are not global but
> > are limited to their user namespace. We do not currently have
> > filesystem support for this concept.
>
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo@uid=15000
>
> It's not like there will be:
>
> security.foo@uid=1000
> security.foo@uid=2000
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes.
Is that a problem? Essentially people who would try to do the
above also want to use 'shiftfs' stackable filesystem, which would
presumably eventually do this for you.
> Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
Only if you create the container rootfs as a copy.
Note that generally they would want to walk the fs in that case anyway, to chown
the files into the container. And said chown would clear out any existing file
capabilities (and suid/sgid bits).
On the other hand, unprivileged lxc containers are created by
untarring the distro image straight into the mapped user namespace.
So no chowning is needed, and - once we we have this properly supported -
the filecaps should be automatically written correctly for the container.
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo@uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo@uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
I think that's fine.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-13 16:40 ` Theodore Ts'o
@ 2017-07-13 21:13 ` Serge E. Hallyn
-1 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:13 UTC (permalink / raw)
To: Theodore Ts'o, Eric W. Biederman, Stefan Berger,
Serge E. Hallyn, containers, lkp, linux-kernel, zohar, tycho,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
Quoting Theodore Ts'o (tytso@mit.edu):
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> > The concise summary:
> >
> > Today we have the xattr security.capable that holds a set of
> > capabilities that an application gains when executed. AKA setuid root exec
> > without actually being setuid root.
> >
> > User namespaces have the concept of capabilities that are not global but
> > are limited to their user namespace. We do not currently have
> > filesystem support for this concept.
>
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo@uid=15000
>
> It's not like there will be:
>
> security.foo@uid=1000
> security.foo@uid=2000
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes.
Is that a problem? Essentially people who would try to do the
above also want to use 'shiftfs' stackable filesystem, which would
presumably eventually do this for you.
> Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
Only if you create the container rootfs as a copy.
Note that generally they would want to walk the fs in that case anyway, to chown
the files into the container. And said chown would clear out any existing file
capabilities (and suid/sgid bits).
On the other hand, unprivileged lxc containers are created by
untarring the distro image straight into the mapped user namespace.
So no chowning is needed, and - once we we have this properly supported -
the filecaps should be automatically written correctly for the container.
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo@uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo@uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
I think that's fine.
-serge
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-13 21:13 ` Serge E. Hallyn
0 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-13 21:13 UTC (permalink / raw)
To: linux-security-module
Quoting Theodore Ts'o (tytso at mit.edu):
> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
> > The concise summary:
> >
> > Today we have the xattr security.capable that holds a set of
> > capabilities that an application gains when executed. AKA setuid root exec
> > without actually being setuid root.
> >
> > User namespaces have the concept of capabilities that are not global but
> > are limited to their user namespace. We do not currently have
> > filesystem support for this concept.
>
> So correct me if I am wrong; in general, there will only be one
> variant of the form:
>
> security.foo at uid=15000
>
> It's not like there will be:
>
> security.foo at uid=1000
> security.foo at uid=2000
>
> Except.... if you have an Distribution root directory which is shared
> by many containers, you would need to put the xattrs in the overlay
> inodes.
Is that a problem? Essentially people who would try to do the
above also want to use 'shiftfs' stackable filesystem, which would
presumably eventually do this for you.
> Worse, each time you launch a new container, with a new
> subuid allocation, you will have to iterate over all files with
> capabilities and do a copy-up operations on the xattrs in overlayfs.
> So that's actually a bit of a disaster.
Only if you create the container rootfs as a copy.
Note that generally they would want to walk the fs in that case anyway, to chown
the files into the container. And said chown would clear out any existing file
capabilities (and suid/sgid bits).
On the other hand, unprivileged lxc containers are created by
untarring the distro image straight into the mapped user namespace.
So no chowning is needed, and - once we we have this properly supported -
the filecaps should be automatically written correctly for the container.
> So for distribution overlays, you will need to do things a different
> way, which is to map the distro subdirectory so you know that the
> capability with the global uid 0 should be used for the container
> "root" uid, right?
>
> So this hack of using security.foo at uid=1000 is *only* useful when the
> subcontainer root wants to create the privileged executable. You
> still have to do things the other way.
>
> So can we make perhaps the assertion that *either*:
>
> security.foo
>
> exists, *or*
>
> security.foo at uid=BAR
>
> exists, but never both? And there BAR is exclusive to only one
> instances?
I think that's fine.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <1499785511-17192-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1499785511-17192-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-11 17:12 ` Serge E. Hallyn
2017-07-12 3:45 ` Serge E. Hallyn
` (6 subsequent siblings)
7 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-11 17:12 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Quoting Stefan Berger (Stefan Bergerstefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> er.kernel.org>
> X-Mailing-List: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Content-Length: 19839
> Lines: 700
> X-UID: 24770
> Status: RO
>
> From: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo@uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo@uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo@uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo@uid=1000 will be listed as security.foo in the user
> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 464c94b..eacad9e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> return inode_permission(inode, mask);
> }
>
> +/*
> + * A list of extended attributes that are supported in user namespaces
> + */
> +static const char *const userns_xattrs[] = {
> + XATTR_NAME_CAPS,
> + NULL
> +};
> +
> +/*
> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> + *
> + * @name: full name of the extended attribute
> + * @prefix: do a prefix match (true) or a full match (false)
> + *
> + * This function returns < 0 if not supported, an index into userns_xattrs[]
> + * otherwise.
> + */
> +static int
> +xattr_is_userns_supported(const char *name, int prefix)
> +{
> + int i;
> +
> + if (!name)
> + return -1;
> +
> + for (i = 0; userns_xattrs[i]; i++) {
> + if (prefix) {
> + if (!strncmp(userns_xattrs[i], name,
> + strlen(userns_xattrs[i])))
> + return i;
I think you here need to also check that the next char is either
'\0' or '.' (or maybe '@')
> + } else {
> + if (!strcmp(userns_xattrs[i], name))
> + return i;
> + }
> + }
> + return -1;
> +}
> +
> +/*
> + * xattr_write_uid - print a string in the format of "%s@uid=%u", which
> + * includes a prefix string
> + *
> + * @uid: the uid
> + * @prefix: prefix string; may be NULL
> + *
> + * This function returns a buffer with the string, or a NULL pointer in
> + * case of out-of-memory error.
> + */
> +static char *
> +xattr_write_uid(uid_t uid, const char *prefix)
> +{
> + size_t buflen;
> + char *buffer;
> +
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
> + if (prefix)
> + buflen += strlen(prefix);
> +
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer)
> + return NULL;
> +
> + if (uid == 0)
> + *buffer = 0;
Do you need to print out the prefix here?
> + else
> + sprintf(buffer, "%s@uid=%u",
> + (prefix) ? prefix : "",
> + uid);
> +
> + return buffer;
> +}
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1499785511-17192-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-11 17:12 ` Serge E. Hallyn
@ 2017-07-12 3:45 ` Serge E. Hallyn
2017-07-12 7:59 ` James Morris
` (5 subsequent siblings)
7 siblings, 0 replies; 288+ messages in thread
From: Serge E. Hallyn @ 2017-07-12 3:45 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Quoting Stefan Berger (Stefan Bergerstefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = &list[s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);
Why are you doing this here? If we get here it means that
xattr_is_userns_supported() returned < 0, meaning name is
not userns-supported. So xattr_rewrite_userns_xattr() will
just return name. Am I missing something?
> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
Now here, if name was recalculated to @newname, and @newname is
found in the nlist, that should raise an error right? Something
fishy is going on?
> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)
d_off needs to be set to -ERANGE here.
> + break;
> + strcpy(&nlist[d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1499785511-17192-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-11 17:12 ` Serge E. Hallyn
2017-07-12 3:45 ` Serge E. Hallyn
@ 2017-07-12 7:59 ` James Morris
2017-07-12 13:25 ` Eric W. Biederman
` (4 subsequent siblings)
7 siblings, 0 replies; 288+ messages in thread
From: James Morris @ 2017-07-12 7:59 UTC (permalink / raw)
To: Stefan Berger
Cc: zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
lkp-JC7UmRfGjtg
On Tue, 11 Jul 2017, Stefan Berger wrote:
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
Why not strlen() here?
--
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1499785511-17192-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
` (2 preceding siblings ...)
2017-07-12 7:59 ` James Morris
@ 2017-07-12 13:25 ` Eric W. Biederman
2017-07-12 17:53 ` Vivek Goyal
` (3 subsequent siblings)
7 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-12 13:25 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> From: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo@uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo@uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo@uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo@uid=1000 will be listed as security.foo in the user
> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
It doesn't look like this is coming through Serge so I don't see how
the Signed-off-by tag is legtimate.
From the replies to this it doesn't look like Serge has reviewed this
version either.
I am disappointed that all of my concerns about technical feasibility
remain unaddressed.
I hope my reading and review of the code goes better than my reading of
it's introduction.
Eric
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 464c94b..eacad9e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
> return inode_permission(inode, mask);
> }
>
> +/*
> + * A list of extended attributes that are supported in user namespaces
> + */
> +static const char *const userns_xattrs[] = {
> + XATTR_NAME_CAPS,
> + NULL
> +};
> +
> +/*
> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> + *
> + * @name: full name of the extended attribute
> + * @prefix: do a prefix match (true) or a full match (false)
> + *
> + * This function returns < 0 if not supported, an index into userns_xattrs[]
> + * otherwise.
> + */
> +static int
> +xattr_is_userns_supported(const char *name, int prefix)
> +{
> + int i;
> +
> + if (!name)
> + return -1;
> +
> + for (i = 0; userns_xattrs[i]; i++) {
> + if (prefix) {
> + if (!strncmp(userns_xattrs[i], name,
> + strlen(userns_xattrs[i])))
> + return i;
> + } else {
> + if (!strcmp(userns_xattrs[i], name))
> + return i;
> + }
> + }
> + return -1;
> +}
> +
> +/*
> + * xattr_write_uid - print a string in the format of "%s@uid=%u", which
> + * includes a prefix string
> + *
> + * @uid: the uid
> + * @prefix: prefix string; may be NULL
> + *
> + * This function returns a buffer with the string, or a NULL pointer in
> + * case of out-of-memory error.
> + */
> +static char *
> +xattr_write_uid(uid_t uid, const char *prefix)
> +{
> + size_t buflen;
> + char *buffer;
> +
> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
> + if (prefix)
> + buflen += strlen(prefix);
> +
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer)
> + return NULL;
> +
> + if (uid == 0)
> + *buffer = 0;
> + else
> + sprintf(buffer, "%s@uid=%u",
> + (prefix) ? prefix : "",
> + uid);
> +
> + return buffer;
> +}
> +
> +/*
> + * xattr_parse_uid_from_kuid - parse string in the format @uid=<uid>; consider
> + * user namespaces and check mappings
> + *
> + * @uidstr : string in the format "@uid=<uid>"
> + * @userns : the user namespace to consult for uid mappings
> + * @n_uidstr : returned pointer holding the rewritten @uid=<uid> string with
> + * the uid remapped
> + *
> + * This function returns an error code or 0 in case of success. In case
> + * of success, 'n_uidstr' will hold a valid string.
> + */
> +static int
> +xattr_parse_uid_from_kuid(const char *uidstr, struct user_namespace *userns,
> + char **n_uidstr)
> +{
> + int n;
> + uid_t muid, p_uid;
> + char d;
> + kuid_t tuid;
> +
> + *n_uidstr = NULL;
> +
> + n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
> + if (n != 1)
> + return -EINVAL;
> +
> + /* do we have a mapping of the uid? */
> + tuid = KUIDT_INIT(p_uid);
> + muid = from_kuid(userns, tuid);
> + if (muid == -1)
> + return -ENOENT;
> +
> + *n_uidstr = xattr_write_uid(muid, NULL);
> + if (!*n_uidstr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +/*
> + * xattr_parse_uid_make_kuid - parse string in the format @uid=<uid>; consider
> + * user namespaces and check mappings
> + *
> + * @uidstr : string in the format "@uid=<uid>"
> + * @userns : the user namespace to consult for uid mappings
> + * @N_uidstr : returned pointer holding the rewritten @uid=<uid> string with
> + * the uid remapped
> + *
> + * This function returns an error code or 0 in case of success. In case
> + * of success, 'n_uidstr' will hold a valid string.
> + */
> +static int
> +xattr_parse_uid_make_kuid(const char *uidstr, struct user_namespace *userns,
> + char **n_uidstr)
> +{
> + int n;
> + uid_t p_uid;
> + char d;
> + kuid_t tuid;
> +
> + *n_uidstr = NULL;
> +
> + n = sscanf(uidstr, "@uid=%u%c", &p_uid, &d);
> + if (n != 1)
> + return -EINVAL;
> +
> + tuid = make_kuid(userns, p_uid);
> + if (!uid_valid(tuid))
> + return -ENOENT;
> +
> + *n_uidstr = xattr_write_uid(__kuid_val(tuid), NULL);
> + if (!*n_uidstr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +/*
> + * xattr_rewrite_userns_xattr - Rewrite and filter an extended attribute
> + * considering user namespace uid mappings and
> + * user namespace support extended attributes
> + *
> + * @name: full name of the extended attribute
> + *
> + * This function returns NULL if the name is to be filtered. Otherwise it can
> + * return the input buffer or a new buffer that the caller needs to free. The
> + * new buffer contains a rewritten extended attribute whose string length may
> + * exceed that of the given name.
> + */
> +static char *
> +xattr_rewrite_userns_xattr(char *name)
> +{
> + int idx, error;
> + size_t len = 0, buflen;
> + char *buffer, *n_uidstr;
> +
> + /* prefix-match name against supported attributes */
> + idx = xattr_is_userns_supported(name, true);
> + if (idx < 0) {
> + /* only rewrite those in userns_xattr[*] */
> + return name;
> + }
> +
> + /* exact match ? */
> + len = strlen(userns_xattrs[idx]);
> + if (name[len] == 0)
> + return NULL;
> +
> + /*
> + * We must have a name[len] == '@'.
> + */
> + error = xattr_parse_uid_from_kuid(&name[len], current_user_ns(),
> + &n_uidstr);
> + if (error)
> + return NULL;
> +
> + buflen = len + strlen(n_uidstr) + 1;
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer) {
> + kfree(n_uidstr);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + name[len] = 0;
> +
> + snprintf(buffer, buflen, "%s%s", name, n_uidstr);
> +
> + name[len] = '@';
> +
> + kfree(n_uidstr);
> +
> + return buffer;
> +}
> +
> +/*
> + * xattr_list_contains - check whether an xattr list already contains a needle
> + *
> + * @list : 0-byte separated strings
> + * @listlen : length of the list
> + * @needle : the needle to search for
> + */
> +static int
> +xattr_list_contains(const char *list, size_t listlen, const char *needle)
> +{
> + size_t o = 0;
> +
> + while (o < listlen) {
> + if (!strcmp(&list[o], needle))
> + return true;
> + o += strlen(&list[o]) + 1;
> + }
> + return false;
> +}
> +
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = &list[s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);
> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)
> + break;
> + strcpy(&nlist[d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}
> +
> +/*
> + * xattr_userns_name - modify the name of a user namespace supported
> + * extended attribute
> + *
> + * In a user namespace we prevent read/write accesses to the host's
> + * security.foo to protect these extended attributes.
> + *
> + * Reading:
> + * 1a) Reading security.foo from a user namespace will read
> + * security.foo@uid=<uid> of the parent user namespace instead with uid
> + * being the mapping of root in that parent user namespace. An
> + * exception is if root is mapped to uid 0 on the host, and in this case
> + * we will read security.foo directly.
> + * -> reading security.foo will read security.foo@uid=1000 for a uid
> + * mapping of root to 1000.
> + *
> + * 1b) If security.foo@uid=<uid> is not available, the security.foo of the
> + * parent namespace is tried to be read. This procedure is repeated up to
> + * the init user namespace. This step only applies for reading of extended
> + * attributes and provides the same behavior as older systems where the
> + * host's extended attributes applied to user namespaces.
> + *
> + * 2) All security.foo@uid=<uid> with valid uid mappings in the user namespace
> + * an be read. The uid within the user namespace will be mapped to the
> + * corresponding uid on the host and that uid will be used in the name of
> + * the extended attribute.
> + * -> reading security.foo@uid=1 will read security.foo@uid=1001 for a uid
> + * mapping of root to 1000, size of at least 2.
> + *
> + * All security.foo@uid=<uid> can be read (by root) on the host with values
> + * of <uid> also being subject to checking for valid mappings.
> + *
> + * 3) No other security.foo* can be read.
> + *
> + * Writing and removing:
> + * The same rules for reading apply to writing and removing, except for 1b).
> + *
> + * This function returns a buffer with either the original name or the
> + * user namespace adjusted name of the extended attribute.
> + *
> + * @name: the full name of the extended attribute, e.g. security.foo
> + */
> +char *
> +xattr_userns_name(const char *name, struct user_namespace *userns)
> +{
> + size_t buflen;
> + char *buffer, *n_uidstr;
> + kuid_t root_uid = make_kuid(userns, 0);
> + int idx, error;
> + size_t len;
> +
> + /* only security.foo will be changed here - prefix match here */
> + idx = xattr_is_userns_supported(name, true);
> + if (idx < 0)
> + goto out_copy;
> +
> + /* read security.foo? --> read security.foo@uid=<uid> instead */
> + len = strlen(userns_xattrs[idx]);
> + if (name[len] == 0) {
> + /*
> + * init_user_ns or userns with root mapped to uid 0
> + * may read security.foo directly
> + */
> + if (userns == &init_user_ns ||
> + __kuid_val(root_uid) == 0)
> + goto out_copy;
> +
> + if (!uid_valid(root_uid))
> + return ERR_PTR(-EINVAL);
> +
> + buffer = xattr_write_uid(__kuid_val(root_uid), name);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + return buffer;
> + }
> +
> + /*
> + * We must have name[len] == '@'.
> + */
> + error = xattr_parse_uid_make_kuid(&name[len],
> + userns,
> + &n_uidstr);
> + if (error)
> + return ERR_PTR(error);
> +
> + /* name[len] == '@' */
> + buflen = len + strlen(n_uidstr) + 1;
> + buffer = kmalloc(buflen, GFP_KERNEL);
> + if (!buffer) {
> + kfree(n_uidstr);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + snprintf(buffer, len + 1, "%s", name);
> + snprintf(&buffer[len], buflen - len, "%s", n_uidstr);
> + kfree(n_uidstr);
> +
> + return buffer;
> +
> +out_copy:
> + buffer = kstrdup(name, GFP_KERNEL);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + return buffer;
> +}
> +
> int
> __vfs_setxattr(struct dentry *dentry, struct inode *inode, const char *name,
> const void *value, size_t size, int flags)
> {
> const struct xattr_handler *handler;
> + char *newname;
> + int ret;
>
> + newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> + name = newname;
> handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->set)
> - return -EOPNOTSUPP;
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->set) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> if (size == 0)
> value = ""; /* empty EA, do not remove */
> - return handler->set(handler, dentry, inode, name, value, size, flags);
> + ret = handler->set(handler, dentry, inode, name, value, size, flags);
> +
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_setxattr);
>
> @@ -301,14 +721,39 @@ ssize_t
> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> void *value, size_t size)
> {
> - const struct xattr_handler *handler;
> + const struct xattr_handler *handler = NULL;
> + char *newname = NULL;
> + int ret, userns_supt_xattr;
> + struct user_namespace *userns = current_user_ns();
> +
> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
> +
> + do {
> + kfree(newname);
> +
> + newname = xattr_userns_name(name, userns);
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + if (!handler) {
> + name = newname;
> + handler = xattr_resolve_name(inode, &name);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->get) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + }
> + ret = handler->get(handler, dentry, inode, name, value, size);
> + userns = userns->parent;
> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>
> - handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->get)
> - return -EOPNOTSUPP;
> - return handler->get(handler, dentry, inode, name, value, size);
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_getxattr);
>
> @@ -328,8 +773,16 @@ vfs_getxattr(struct dentry *dentry, const char *name, void *value, size_t size)
>
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> XATTR_SECURITY_PREFIX_LEN)) {
> - const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
> - int ret = xattr_getsecurity(inode, suffix, value, size);
> + int ret;
> + const char *suffix;
> + char *newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + suffix = newname + XATTR_SECURITY_PREFIX_LEN;
> +
> + ret = xattr_getsecurity(inode, suffix, value, size);
> + kfree(newname);
> /*
> * Only overwrite the return value if a security module
> * is actually active.
> @@ -360,6 +813,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t size)
> if (size && error > size)
> error = -ERANGE;
> }
> + if (error > 0)
> + error = xattr_list_userns_rewrite(list, error, size);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_listxattr);
> @@ -369,13 +825,28 @@ __vfs_removexattr(struct dentry *dentry, const char *name)
> {
> struct inode *inode = d_inode(dentry);
> const struct xattr_handler *handler;
> + char *newname;
> + int ret;
>
> + newname = xattr_userns_name(name, current_user_ns());
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> + name = newname;
> handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->set)
> - return -EOPNOTSUPP;
> - return handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->set) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + ret = handler->set(handler, dentry, inode, name, NULL, 0, XATTR_REPLACE);
> +
> +out:
> + kfree(newname);
> +
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_removexattr);
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 7abebd7..c842690 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -660,15 +660,23 @@ int cap_bprm_secureexec(struct linux_binprm *bprm)
> int cap_inode_setxattr(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags)
> {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
> + return 0;
> +
> + if (strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1) == 0) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> +
> return 0;
> }
>
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> - !capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> return 0;
> }
> @@ -686,15 +694,23 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name,
> */
> int cap_inode_removexattr(struct dentry *dentry, const char *name)
> {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
> + return 0;
> +
> + if (strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1) == 0) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> +
> return 0;
> }
>
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> - !capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> return 0;
> }
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 819fd68..702c225 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3091,8 +3091,13 @@ static int selinux_inode_setotherxattr(struct dentry *dentry, const char *name)
>
> if (!strncmp(name, XATTR_SECURITY_PREFIX,
> sizeof XATTR_SECURITY_PREFIX - 1)) {
> - if (!strcmp(name, XATTR_NAME_CAPS)) {
> - if (!capable(CAP_SETFCAP))
> + if (!strncmp(name, XATTR_NAME_CAPS,
> + sizeof(XATTR_NAME_CAPS) - 1)) {
> + struct inode *inode = d_backing_inode(dentry);
> +
> + if (!inode)
> + return -EINVAL;
> + if (!capable_wrt_inode_uidgid(inode, CAP_SETFCAP))
> return -EPERM;
> } else if (!capable(CAP_SYS_ADMIN)) {
> /* A different attribute in the security namespace.
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-11 15:05 ` Stefan Berger
(?)
(?)
@ 2017-07-12 17:53 ` Vivek Goyal
-1 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-12 17:53 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
[..]
> @@ -301,14 +721,39 @@ ssize_t
> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> void *value, size_t size)
> {
> - const struct xattr_handler *handler;
> + const struct xattr_handler *handler = NULL;
> + char *newname = NULL;
> + int ret, userns_supt_xattr;
> + struct user_namespace *userns = current_user_ns();
> +
> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
> +
Hi Stephan,
> + do {
> + kfree(newname);
> +
> + newname = xattr_userns_name(name, userns);
^^^
Will name be pointing to a freed string in second iteration of loop.
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + if (!handler) {
> + name = newname;
Here we assign name and at the beginning of second iteration we free
newname.
Also I am not sure why do we do this assignment only if handler is NULL.
BTW, I set cap_sys_admin on a file outside usernamespace and then launched
user namespace (mapping 1000 to 0). And then tried to do getcap on file
and I am not seeing security.capability set by host. Not sure what am I
doing wrong. getxattr() seems to return -ENODATA. Still debugging it.
Also, have we resovled the question of stacked filesystem like overlayfs.
There we are switching creds to mounter's creds when doing operations on
underlying filesystem. I am concenrned does that mean, we will get and
return security.capability to caller in usernamespace instead of
security.capability@uid=1000.
Vivek
> + handler = xattr_resolve_name(inode, &name);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->get) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + }
> + ret = handler->get(handler, dentry, inode, name, value, size);
> + userns = userns->parent;
> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>
> - handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->get)
> - return -EOPNOTSUPP;
> - return handler->get(handler, dentry, inode, name, value, size);
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_getxattr);
>
Thanks
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 17:53 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-12 17:53 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
[..]
> @@ -301,14 +721,39 @@ ssize_t
> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> void *value, size_t size)
> {
> - const struct xattr_handler *handler;
> + const struct xattr_handler *handler = NULL;
> + char *newname = NULL;
> + int ret, userns_supt_xattr;
> + struct user_namespace *userns = current_user_ns();
> +
> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
> +
Hi Stephan,
> + do {
> + kfree(newname);
> +
> + newname = xattr_userns_name(name, userns);
^^^
Will name be pointing to a freed string in second iteration of loop.
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + if (!handler) {
> + name = newname;
Here we assign name and at the beginning of second iteration we free
newname.
Also I am not sure why do we do this assignment only if handler is NULL.
BTW, I set cap_sys_admin on a file outside usernamespace and then launched
user namespace (mapping 1000 to 0). And then tried to do getcap on file
and I am not seeing security.capability set by host. Not sure what am I
doing wrong. getxattr() seems to return -ENODATA. Still debugging it.
Also, have we resovled the question of stacked filesystem like overlayfs.
There we are switching creds to mounter's creds when doing operations on
underlying filesystem. I am concenrned does that mean, we will get and
return security.capability to caller in usernamespace instead of
security.capability(a)uid=1000.
Vivek
> + handler = xattr_resolve_name(inode, &name);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->get) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + }
> + ret = handler->get(handler, dentry, inode, name, value, size);
> + userns = userns->parent;
> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>
> - handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->get)
> - return -EOPNOTSUPP;
> - return handler->get(handler, dentry, inode, name, value, size);
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_getxattr);
>
Thanks
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 17:53 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-12 17:53 UTC (permalink / raw)
To: linux-security-module
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
[..]
> @@ -301,14 +721,39 @@ ssize_t
> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> void *value, size_t size)
> {
> - const struct xattr_handler *handler;
> + const struct xattr_handler *handler = NULL;
> + char *newname = NULL;
> + int ret, userns_supt_xattr;
> + struct user_namespace *userns = current_user_ns();
> +
> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
> +
Hi Stephan,
> + do {
> + kfree(newname);
> +
> + newname = xattr_userns_name(name, userns);
^^^
Will name be pointing to a freed string in second iteration of loop.
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + if (!handler) {
> + name = newname;
Here we assign name and at the beginning of second iteration we free
newname.
Also I am not sure why do we do this assignment only if handler is NULL.
BTW, I set cap_sys_admin on a file outside usernamespace and then launched
user namespace (mapping 1000 to 0). And then tried to do getcap on file
and I am not seeing security.capability set by host. Not sure what am I
doing wrong. getxattr() seems to return -ENODATA. Still debugging it.
Also, have we resovled the question of stacked filesystem like overlayfs.
There we are switching creds to mounter's creds when doing operations on
underlying filesystem. I am concenrned does that mean, we will get and
return security.capability to caller in usernamespace instead of
security.capability at uid=1000.
Vivek
> + handler = xattr_resolve_name(inode, &name);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->get) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + }
> + ret = handler->get(handler, dentry, inode, name, value, size);
> + userns = userns->parent;
> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>
> - handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->get)
> - return -EOPNOTSUPP;
> - return handler->get(handler, dentry, inode, name, value, size);
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_getxattr);
>
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 17:53 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-12 17:53 UTC (permalink / raw)
To: Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey, Stefan Berger
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
[..]
> @@ -301,14 +721,39 @@ ssize_t
> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> void *value, size_t size)
> {
> - const struct xattr_handler *handler;
> + const struct xattr_handler *handler = NULL;
> + char *newname = NULL;
> + int ret, userns_supt_xattr;
> + struct user_namespace *userns = current_user_ns();
> +
> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
> +
Hi Stephan,
> + do {
> + kfree(newname);
> +
> + newname = xattr_userns_name(name, userns);
^^^
Will name be pointing to a freed string in second iteration of loop.
> + if (IS_ERR(newname))
> + return PTR_ERR(newname);
> +
> + if (!handler) {
> + name = newname;
Here we assign name and at the beginning of second iteration we free
newname.
Also I am not sure why do we do this assignment only if handler is NULL.
BTW, I set cap_sys_admin on a file outside usernamespace and then launched
user namespace (mapping 1000 to 0). And then tried to do getcap on file
and I am not seeing security.capability set by host. Not sure what am I
doing wrong. getxattr() seems to return -ENODATA. Still debugging it.
Also, have we resovled the question of stacked filesystem like overlayfs.
There we are switching creds to mounter's creds when doing operations on
underlying filesystem. I am concenrned does that mean, we will get and
return security.capability to caller in usernamespace instead of
security.capability@uid=1000.
Vivek
> + handler = xattr_resolve_name(inode, &name);
> + if (IS_ERR(handler)) {
> + ret = PTR_ERR(handler);
> + goto out;
> + }
> + if (!handler->get) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
> + }
> + ret = handler->get(handler, dentry, inode, name, value, size);
> + userns = userns->parent;
> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>
> - handler = xattr_resolve_name(inode, &name);
> - if (IS_ERR(handler))
> - return PTR_ERR(handler);
> - if (!handler->get)
> - return -EOPNOTSUPP;
> - return handler->get(handler, dentry, inode, name, value, size);
> +out:
> + kfree(newname);
> + return ret;
> }
> EXPORT_SYMBOL(__vfs_getxattr);
>
Thanks
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-12 17:53 ` Vivek Goyal
(?)
@ 2017-07-12 19:19 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 19:19 UTC (permalink / raw)
To: Vivek Goyal, Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On 07/12/2017 01:53 PM, Vivek Goyal wrote:
> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>
> [..]
>> @@ -301,14 +721,39 @@ ssize_t
>> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
>> void *value, size_t size)
>> {
>> - const struct xattr_handler *handler;
>> + const struct xattr_handler *handler = NULL;
>> + char *newname = NULL;
>> + int ret, userns_supt_xattr;
>> + struct user_namespace *userns = current_user_ns();
>> +
>> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
>> +
> Hi Stephan,
>
>> + do {
>> + kfree(newname);
>> +
>> + newname = xattr_userns_name(name, userns);
> ^^^
> Will name be pointing to a freed string in second iteration of loop.
Fixing for v3.
>
>> + if (IS_ERR(newname))
>> + return PTR_ERR(newname);
>> +
>> + if (!handler) {
>> + name = newname;
> Here we assign name and at the beginning of second iteration we free
> newname.
>
> Also I am not sure why do we do this assignment only if handler is NULL.
The handler shouldn't change but this optimization isn't helpful. Fixed
through this patch:
https://github.com/stefanberger/linux/commit/10828401b29a13f8c56f8fad0c0fb2690e4af878
>
> BTW, I set cap_sys_admin on a file outside usernamespace and then launched
> user namespace (mapping 1000 to 0). And then tried to do getcap on file
> and I am not seeing security.capability set by host. Not sure what am I
> doing wrong. getxattr() seems to return -ENODATA. Still debugging it.
This was a regression due to the bug in the loop. I didn't have a test
case (with runc) for it, now I do.
>
> Also, have we resovled the question of stacked filesystem like overlayfs.
> There we are switching creds to mounter's creds when doing operations on
> underlying filesystem. I am concenrned does that mean, we will get and
> return security.capability to caller in usernamespace instead of
> security.capability@uid=1000.
I would have to test this, otherwise I don't know. I'll try it out with
Docker.
Stefan
>
> Vivek
>
>> + handler = xattr_resolve_name(inode, &name);
>> + if (IS_ERR(handler)) {
>> + ret = PTR_ERR(handler);
>> + goto out;
>> + }
>> + if (!handler->get) {
>> + ret = -EOPNOTSUPP;
>> + goto out;
>> + }
>> + }
>> + ret = handler->get(handler, dentry, inode, name, value, size);
>> + userns = userns->parent;
>> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>>
>> - handler = xattr_resolve_name(inode, &name);
>> - if (IS_ERR(handler))
>> - return PTR_ERR(handler);
>> - if (!handler->get)
>> - return -EOPNOTSUPP;
>> - return handler->get(handler, dentry, inode, name, value, size);
>> +out:
>> + kfree(newname);
>> + return ret;
>> }
>> EXPORT_SYMBOL(__vfs_getxattr);
>>
> Thanks
> Vivek
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 19:19 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 19:19 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]
On 07/12/2017 01:53 PM, Vivek Goyal wrote:
> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>
> [..]
>> @@ -301,14 +721,39 @@ ssize_t
>> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
>> void *value, size_t size)
>> {
>> - const struct xattr_handler *handler;
>> + const struct xattr_handler *handler = NULL;
>> + char *newname = NULL;
>> + int ret, userns_supt_xattr;
>> + struct user_namespace *userns = current_user_ns();
>> +
>> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
>> +
> Hi Stephan,
>
>> + do {
>> + kfree(newname);
>> +
>> + newname = xattr_userns_name(name, userns);
> ^^^
> Will name be pointing to a freed string in second iteration of loop.
Fixing for v3.
>
>> + if (IS_ERR(newname))
>> + return PTR_ERR(newname);
>> +
>> + if (!handler) {
>> + name = newname;
> Here we assign name and at the beginning of second iteration we free
> newname.
>
> Also I am not sure why do we do this assignment only if handler is NULL.
The handler shouldn't change but this optimization isn't helpful. Fixed
through this patch:
https://github.com/stefanberger/linux/commit/10828401b29a13f8c56f8fad0c0fb2690e4af878
>
> BTW, I set cap_sys_admin on a file outside usernamespace and then launched
> user namespace (mapping 1000 to 0). And then tried to do getcap on file
> and I am not seeing security.capability set by host. Not sure what am I
> doing wrong. getxattr() seems to return -ENODATA. Still debugging it.
This was a regression due to the bug in the loop. I didn't have a test
case (with runc) for it, now I do.
>
> Also, have we resovled the question of stacked filesystem like overlayfs.
> There we are switching creds to mounter's creds when doing operations on
> underlying filesystem. I am concenrned does that mean, we will get and
> return security.capability to caller in usernamespace instead of
> security.capability(a)uid=1000.
I would have to test this, otherwise I don't know. I'll try it out with
Docker.
Stefan
>
> Vivek
>
>> + handler = xattr_resolve_name(inode, &name);
>> + if (IS_ERR(handler)) {
>> + ret = PTR_ERR(handler);
>> + goto out;
>> + }
>> + if (!handler->get) {
>> + ret = -EOPNOTSUPP;
>> + goto out;
>> + }
>> + }
>> + ret = handler->get(handler, dentry, inode, name, value, size);
>> + userns = userns->parent;
>> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>>
>> - handler = xattr_resolve_name(inode, &name);
>> - if (IS_ERR(handler))
>> - return PTR_ERR(handler);
>> - if (!handler->get)
>> - return -EOPNOTSUPP;
>> - return handler->get(handler, dentry, inode, name, value, size);
>> +out:
>> + kfree(newname);
>> + return ret;
>> }
>> EXPORT_SYMBOL(__vfs_getxattr);
>>
> Thanks
> Vivek
>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-12 19:19 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 19:19 UTC (permalink / raw)
To: linux-security-module
On 07/12/2017 01:53 PM, Vivek Goyal wrote:
> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>
> [..]
>> @@ -301,14 +721,39 @@ ssize_t
>> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
>> void *value, size_t size)
>> {
>> - const struct xattr_handler *handler;
>> + const struct xattr_handler *handler = NULL;
>> + char *newname = NULL;
>> + int ret, userns_supt_xattr;
>> + struct user_namespace *userns = current_user_ns();
>> +
>> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
>> +
> Hi Stephan,
>
>> + do {
>> + kfree(newname);
>> +
>> + newname = xattr_userns_name(name, userns);
> ^^^
> Will name be pointing to a freed string in second iteration of loop.
Fixing for v3.
>
>> + if (IS_ERR(newname))
>> + return PTR_ERR(newname);
>> +
>> + if (!handler) {
>> + name = newname;
> Here we assign name and at the beginning of second iteration we free
> newname.
>
> Also I am not sure why do we do this assignment only if handler is NULL.
The handler shouldn't change but this optimization isn't helpful. Fixed
through this patch:
https://github.com/stefanberger/linux/commit/10828401b29a13f8c56f8fad0c0fb2690e4af878
>
> BTW, I set cap_sys_admin on a file outside usernamespace and then launched
> user namespace (mapping 1000 to 0). And then tried to do getcap on file
> and I am not seeing security.capability set by host. Not sure what am I
> doing wrong. getxattr() seems to return -ENODATA. Still debugging it.
This was a regression due to the bug in the loop. I didn't have a test
case (with runc) for it, now I do.
>
> Also, have we resovled the question of stacked filesystem like overlayfs.
> There we are switching creds to mounter's creds when doing operations on
> underlying filesystem. I am concenrned does that mean, we will get and
> return security.capability to caller in usernamespace instead of
> security.capability at uid=1000.
I would have to test this, otherwise I don't know. I'll try it out with
Docker.
Stefan
>
> Vivek
>
>> + handler = xattr_resolve_name(inode, &name);
>> + if (IS_ERR(handler)) {
>> + ret = PTR_ERR(handler);
>> + goto out;
>> + }
>> + if (!handler->get) {
>> + ret = -EOPNOTSUPP;
>> + goto out;
>> + }
>> + }
>> + ret = handler->get(handler, dentry, inode, name, value, size);
>> + userns = userns->parent;
>> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>>
>> - handler = xattr_resolve_name(inode, &name);
>> - if (IS_ERR(handler))
>> - return PTR_ERR(handler);
>> - if (!handler->get)
>> - return -EOPNOTSUPP;
>> - return handler->get(handler, dentry, inode, name, value, size);
>> +out:
>> + kfree(newname);
>> + return ret;
>> }
>> EXPORT_SYMBOL(__vfs_getxattr);
>>
> Thanks
> Vivek
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170712175357.GA32609-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170712175357.GA32609-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-12 19:19 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-12 19:19 UTC (permalink / raw)
To: Vivek Goyal, Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/12/2017 01:53 PM, Vivek Goyal wrote:
> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>
> [..]
>> @@ -301,14 +721,39 @@ ssize_t
>> __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
>> void *value, size_t size)
>> {
>> - const struct xattr_handler *handler;
>> + const struct xattr_handler *handler = NULL;
>> + char *newname = NULL;
>> + int ret, userns_supt_xattr;
>> + struct user_namespace *userns = current_user_ns();
>> +
>> + userns_supt_xattr = (xattr_is_userns_supported(name, false) >= 0);
>> +
> Hi Stephan,
>
>> + do {
>> + kfree(newname);
>> +
>> + newname = xattr_userns_name(name, userns);
> ^^^
> Will name be pointing to a freed string in second iteration of loop.
Fixing for v3.
>
>> + if (IS_ERR(newname))
>> + return PTR_ERR(newname);
>> +
>> + if (!handler) {
>> + name = newname;
> Here we assign name and at the beginning of second iteration we free
> newname.
>
> Also I am not sure why do we do this assignment only if handler is NULL.
The handler shouldn't change but this optimization isn't helpful. Fixed
through this patch:
https://github.com/stefanberger/linux/commit/10828401b29a13f8c56f8fad0c0fb2690e4af878
>
> BTW, I set cap_sys_admin on a file outside usernamespace and then launched
> user namespace (mapping 1000 to 0). And then tried to do getcap on file
> and I am not seeing security.capability set by host. Not sure what am I
> doing wrong. getxattr() seems to return -ENODATA. Still debugging it.
This was a regression due to the bug in the loop. I didn't have a test
case (with runc) for it, now I do.
>
> Also, have we resovled the question of stacked filesystem like overlayfs.
> There we are switching creds to mounter's creds when doing operations on
> underlying filesystem. I am concenrned does that mean, we will get and
> return security.capability to caller in usernamespace instead of
> security.capability@uid=1000.
I would have to test this, otherwise I don't know. I'll try it out with
Docker.
Stefan
>
> Vivek
>
>> + handler = xattr_resolve_name(inode, &name);
>> + if (IS_ERR(handler)) {
>> + ret = PTR_ERR(handler);
>> + goto out;
>> + }
>> + if (!handler->get) {
>> + ret = -EOPNOTSUPP;
>> + goto out;
>> + }
>> + }
>> + ret = handler->get(handler, dentry, inode, name, value, size);
>> + userns = userns->parent;
>> + } while ((ret == -ENODATA) && userns && userns_supt_xattr);
>>
>> - handler = xattr_resolve_name(inode, &name);
>> - if (IS_ERR(handler))
>> - return PTR_ERR(handler);
>> - if (!handler->get)
>> - return -EOPNOTSUPP;
>> - return handler->get(handler, dentry, inode, name, value, size);
>> +out:
>> + kfree(newname);
>> + return ret;
>> }
>> EXPORT_SYMBOL(__vfs_getxattr);
>>
> Thanks
> Vivek
>
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <1499785511-17192-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
` (4 preceding siblings ...)
2017-07-12 17:53 ` Vivek Goyal
@ 2017-07-14 23:41 ` Eric W. Biederman
2017-07-17 18:58 ` Vivek Goyal
2017-07-20 1:05 ` [LTP] " kernel test robot
7 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:41 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> From: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo@uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo@uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo@uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo@uid=1000 will be listed as security.foo in the user
> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
I am just going to quickly and publicly point out that as designed this
patch breaks evm inode metadata signing. As evm_config_xattrnames is not
updated.
While not completely insurmountable that seems like a strong limitation of
this design.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-11 15:05 ` Stefan Berger
(?)
(?)
@ 2017-07-17 18:58 ` Vivek Goyal
-1 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-17 18:58 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
[..]
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
size will never be less than 0 here. Only caller calls this function only
if size is >0. So can we remove this?
What about case of "!list". So if user space called listxattr(foo, NULL,
0), we want to return the size of buffer as if all the xattrs will be
returned to user space. But in practice we probably will filter out some
xattrs so actually returned string will be smaller than size reported
previously.
Looks like that's the intent of "!list" condition here. Just wanted to
make sure, hence asking.
BTW, I am testing this with overlayfs and trying to figure out if
switching of creds will create issues. Simple operations like listxattr
and getxattr and setxattr so far worked for me. And reason seems to be
that name transformation we are doing in top layer based on creds of
caller (and not based on creds of mounter).
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-17 18:58 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-17 18:58 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
[..]
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
size will never be less than 0 here. Only caller calls this function only
if size is >0. So can we remove this?
What about case of "!list". So if user space called listxattr(foo, NULL,
0), we want to return the size of buffer as if all the xattrs will be
returned to user space. But in practice we probably will filter out some
xattrs so actually returned string will be smaller than size reported
previously.
Looks like that's the intent of "!list" condition here. Just wanted to
make sure, hence asking.
BTW, I am testing this with overlayfs and trying to figure out if
switching of creds will create issues. Simple operations like listxattr
and getxattr and setxattr so far worked for me. And reason seems to be
that name transformation we are doing in top layer based on creds of
caller (and not based on creds of mounter).
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-17 18:58 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-17 18:58 UTC (permalink / raw)
To: linux-security-module
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
[..]
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
size will never be less than 0 here. Only caller calls this function only
if size is >0. So can we remove this?
What about case of "!list". So if user space called listxattr(foo, NULL,
0), we want to return the size of buffer as if all the xattrs will be
returned to user space. But in practice we probably will filter out some
xattrs so actually returned string will be smaller than size reported
previously.
Looks like that's the intent of "!list" condition here. Just wanted to
make sure, hence asking.
BTW, I am testing this with overlayfs and trying to figure out if
switching of creds will create issues. Simple operations like listxattr
and getxattr and setxattr so far worked for me. And reason seems to be
that name transformation we are doing in top layer based on creds of
caller (and not based on creds of mounter).
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-17 18:58 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-17 18:58 UTC (permalink / raw)
To: Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey, Stefan Berger
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
[..]
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid=<uid> when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list: list of 0-byte separated xattr names
> + * @size: the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
size will never be less than 0 here. Only caller calls this function only
if size is >0. So can we remove this?
What about case of "!list". So if user space called listxattr(foo, NULL,
0), we want to return the size of buffer as if all the xattrs will be
returned to user space. But in practice we probably will filter out some
xattrs so actually returned string will be smaller than size reported
previously.
Looks like that's the intent of "!list" condition here. Just wanted to
make sure, hence asking.
BTW, I am testing this with overlayfs and trying to figure out if
switching of creds will create issues. Simple operations like listxattr
and getxattr and setxattr so far worked for me. And reason seems to be
that name transformation we are doing in top layer based on creds of
caller (and not based on creds of mounter).
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <20170717185811.GC15794-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-17 18:58 ` Vivek Goyal
(?)
(?)
@ 2017-07-17 20:50 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-17 20:50 UTC (permalink / raw)
To: Vivek Goyal, Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>
> [..]
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> size will never be less than 0 here. Only caller calls this function only
> if size is >0. So can we remove this?
Correct.
>
> What about case of "!list". So if user space called listxattr(foo, NULL,
> 0), we want to return the size of buffer as if all the xattrs will be
> returned to user space. But in practice we probably will filter out some
> xattrs so actually returned string will be smaller than size reported
> previously.
This case of size=0 is a problem in userns. Depending on the mapping of
the userid's the list can expand. A security.foo@uid=100 can become
security.foo@uid=100000, if the mapping is set up so that uid 100 on the
host becomes uid 100000 inside the container. So for now we only have
security.capability and the way I solved this is by allocating a 65k
buffer when calling from a userns. In this buffer where we gather the
xattr names and then walk them to determine the size that's needed for
the buffer by simulating the rewriting. It's not nice but I don't know
of any other solution.
>
> Looks like that's the intent of "!list" condition here. Just wanted to
> make sure, hence asking.
Thanks for asking. I thought I had this case covered, but obviously I
did not.
>
> BTW, I am testing this with overlayfs and trying to figure out if
> switching of creds will create issues. Simple operations like listxattr
> and getxattr and setxattr so far worked for me. And reason seems to be
> that name transformation we are doing in top layer based on creds of
> caller (and not based on creds of mounter).
>
> Vivek
>
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-17 20:50 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-17 20:50 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>
> [..]
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> size will never be less than 0 here. Only caller calls this function only
> if size is >0. So can we remove this?
Correct.
>
> What about case of "!list". So if user space called listxattr(foo, NULL,
> 0), we want to return the size of buffer as if all the xattrs will be
> returned to user space. But in practice we probably will filter out some
> xattrs so actually returned string will be smaller than size reported
> previously.
This case of size=0 is a problem in userns. Depending on the mapping of
the userid's the list can expand. A security.foo(a)uid=100 can become
security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
host becomes uid 100000 inside the container. So for now we only have
security.capability and the way I solved this is by allocating a 65k
buffer when calling from a userns. In this buffer where we gather the
xattr names and then walk them to determine the size that's needed for
the buffer by simulating the rewriting. It's not nice but I don't know
of any other solution.
>
> Looks like that's the intent of "!list" condition here. Just wanted to
> make sure, hence asking.
Thanks for asking. I thought I had this case covered, but obviously I
did not.
>
> BTW, I am testing this with overlayfs and trying to figure out if
> switching of creds will create issues. Simple operations like listxattr
> and getxattr and setxattr so far worked for me. And reason seems to be
> that name transformation we are doing in top layer based on creds of
> caller (and not based on creds of mounter).
>
> Vivek
>
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-17 20:50 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-17 20:50 UTC (permalink / raw)
To: linux-security-module
On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>
> [..]
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> size will never be less than 0 here. Only caller calls this function only
> if size is >0. So can we remove this?
Correct.
>
> What about case of "!list". So if user space called listxattr(foo, NULL,
> 0), we want to return the size of buffer as if all the xattrs will be
> returned to user space. But in practice we probably will filter out some
> xattrs so actually returned string will be smaller than size reported
> previously.
This case of size=0 is a problem in userns. Depending on the mapping of
the userid's the list can expand. A security.foo at uid=100 can become
security.foo at uid=100000, if the mapping is set up so that uid 100 on the
host becomes uid 100000 inside the container. So for now we only have
security.capability and the way I solved this is by allocating a 65k
buffer when calling from a userns. In this buffer where we gather the
xattr names and then walk them to determine the size that's needed for
the buffer by simulating the rewriting. It's not nice but I don't know
of any other solution.
>
> Looks like that's the intent of "!list" condition here. Just wanted to
> make sure, hence asking.
Thanks for asking. I thought I had this case covered, but obviously I
did not.
>
> BTW, I am testing this with overlayfs and trying to figure out if
> switching of creds will create issues. Simple operations like listxattr
> and getxattr and setxattr so far worked for me. And reason seems to be
> that name transformation we are doing in top layer based on creds of
> caller (and not based on creds of mounter).
>
> Vivek
>
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-17 20:50 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-17 20:50 UTC (permalink / raw)
To: Vivek Goyal, Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>
> [..]
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> size will never be less than 0 here. Only caller calls this function only
> if size is >0. So can we remove this?
Correct.
>
> What about case of "!list". So if user space called listxattr(foo, NULL,
> 0), we want to return the size of buffer as if all the xattrs will be
> returned to user space. But in practice we probably will filter out some
> xattrs so actually returned string will be smaller than size reported
> previously.
This case of size=0 is a problem in userns. Depending on the mapping of
the userid's the list can expand. A security.foo@uid=100 can become
security.foo@uid=100000, if the mapping is set up so that uid 100 on the
host becomes uid 100000 inside the container. So for now we only have
security.capability and the way I solved this is by allocating a 65k
buffer when calling from a userns. In this buffer where we gather the
xattr names and then walk them to determine the size that's needed for
the buffer by simulating the rewriting. It's not nice but I don't know
of any other solution.
>
> Looks like that's the intent of "!list" condition here. Just wanted to
> make sure, hence asking.
Thanks for asking. I thought I had this case covered, but obviously I
did not.
>
> BTW, I am testing this with overlayfs and trying to figure out if
> switching of creds will create issues. Simple operations like listxattr
> and getxattr and setxattr so far worked for me. And reason seems to be
> that name transformation we are doing in top layer based on creds of
> caller (and not based on creds of mounter).
>
> Vivek
>
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <7a39e8a6-a33b-f6a8-3fd5-6211c075ab91-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <7a39e8a6-a33b-f6a8-3fd5-6211c075ab91-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-18 11:48 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 11:48 UTC (permalink / raw)
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk, Stefan Berger,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> >
> > [..]
> > > +/*
> > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > + * or determine needed size for attribute list
> > > + * in case size == 0
> > > + *
> > > + * In a user namespace we do not present all extended attributes to the
> > > + * user. We filter out those that are in the list of userns supported xattr.
> > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > + * for that uid in the current user namespace.
> > > + *
> > > + * @list: list of 0-byte separated xattr names
> > > + * @size: the size of the list; may be 0 to determine needed list size
> > > + * @list_maxlen: allocated buffer size of list
> > > + */
> > > +static ssize_t
> > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > +{
> > > + char *nlist = NULL;
> > > + size_t s_off, len, nlen;
> > > + ssize_t d_off;
> > > + char *name, *newname;
> > > +
> > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > size will never be less than 0 here. Only caller calls this function only
> > if size is >0. So can we remove this?
>
> Correct.
>
> >
> > What about case of "!list". So if user space called listxattr(foo, NULL,
> > 0), we want to return the size of buffer as if all the xattrs will be
> > returned to user space. But in practice we probably will filter out some
> > xattrs so actually returned string will be smaller than size reported
> > previously.
>
> This case of size=0 is a problem in userns. Depending on the mapping of the
> userid's the list can expand. A security.foo@uid=100 can become
> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> host becomes uid 100000 inside the container. So for now we only have
> security.capability and the way I solved this is by allocating a 65k buffer
> when calling from a userns. In this buffer where we gather the xattr names
> and then walk them to determine the size that's needed for the buffer by
> simulating the rewriting. It's not nice but I don't know of any other
> solution.
Hi Stefan,
For the case of size==0, why don't we iterate through all the xattr,
filter them, remap them and then return the size to process in user
namespace. That should fix this? I thought that's what
xattr_list_userns_rewrite() was doing. But looks like this logic will not
kick in for the case of size==0 due to "!list" condition.
Also we could probably replace "!list" with "!size" wheverever required.
Its little easy to read and understand.
For the other case where some xattrs can get filtered out and we report
a buffer size bigger than actually needed, I am hoping that its acceptable
and none of the existing users are broken.
Thanks
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-17 20:50 ` Stefan Berger
(?)
@ 2017-07-18 11:48 ` Vivek Goyal
-1 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 11:48 UTC (permalink / raw)
To: Stefan Berger
Cc: Stefan Berger, ebiederm, containers, lkp, linux-kernel, zohar,
tycho, serge, James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> >
> > [..]
> > > +/*
> > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > + * or determine needed size for attribute list
> > > + * in case size == 0
> > > + *
> > > + * In a user namespace we do not present all extended attributes to the
> > > + * user. We filter out those that are in the list of userns supported xattr.
> > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > + * for that uid in the current user namespace.
> > > + *
> > > + * @list: list of 0-byte separated xattr names
> > > + * @size: the size of the list; may be 0 to determine needed list size
> > > + * @list_maxlen: allocated buffer size of list
> > > + */
> > > +static ssize_t
> > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > +{
> > > + char *nlist = NULL;
> > > + size_t s_off, len, nlen;
> > > + ssize_t d_off;
> > > + char *name, *newname;
> > > +
> > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > size will never be less than 0 here. Only caller calls this function only
> > if size is >0. So can we remove this?
>
> Correct.
>
> >
> > What about case of "!list". So if user space called listxattr(foo, NULL,
> > 0), we want to return the size of buffer as if all the xattrs will be
> > returned to user space. But in practice we probably will filter out some
> > xattrs so actually returned string will be smaller than size reported
> > previously.
>
> This case of size=0 is a problem in userns. Depending on the mapping of the
> userid's the list can expand. A security.foo@uid=100 can become
> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> host becomes uid 100000 inside the container. So for now we only have
> security.capability and the way I solved this is by allocating a 65k buffer
> when calling from a userns. In this buffer where we gather the xattr names
> and then walk them to determine the size that's needed for the buffer by
> simulating the rewriting. It's not nice but I don't know of any other
> solution.
Hi Stefan,
For the case of size==0, why don't we iterate through all the xattr,
filter them, remap them and then return the size to process in user
namespace. That should fix this? I thought that's what
xattr_list_userns_rewrite() was doing. But looks like this logic will not
kick in for the case of size==0 due to "!list" condition.
Also we could probably replace "!list" with "!size" wheverever required.
Its little easy to read and understand.
For the other case where some xattrs can get filtered out and we report
a buffer size bigger than actually needed, I am hoping that its acceptable
and none of the existing users are broken.
Thanks
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 11:48 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 11:48 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> >
> > [..]
> > > +/*
> > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > + * or determine needed size for attribute list
> > > + * in case size == 0
> > > + *
> > > + * In a user namespace we do not present all extended attributes to the
> > > + * user. We filter out those that are in the list of userns supported xattr.
> > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > + * for that uid in the current user namespace.
> > > + *
> > > + * @list: list of 0-byte separated xattr names
> > > + * @size: the size of the list; may be 0 to determine needed list size
> > > + * @list_maxlen: allocated buffer size of list
> > > + */
> > > +static ssize_t
> > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > +{
> > > + char *nlist = NULL;
> > > + size_t s_off, len, nlen;
> > > + ssize_t d_off;
> > > + char *name, *newname;
> > > +
> > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > size will never be less than 0 here. Only caller calls this function only
> > if size is >0. So can we remove this?
>
> Correct.
>
> >
> > What about case of "!list". So if user space called listxattr(foo, NULL,
> > 0), we want to return the size of buffer as if all the xattrs will be
> > returned to user space. But in practice we probably will filter out some
> > xattrs so actually returned string will be smaller than size reported
> > previously.
>
> This case of size=0 is a problem in userns. Depending on the mapping of the
> userid's the list can expand. A security.foo(a)uid=100 can become
> security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
> host becomes uid 100000 inside the container. So for now we only have
> security.capability and the way I solved this is by allocating a 65k buffer
> when calling from a userns. In this buffer where we gather the xattr names
> and then walk them to determine the size that's needed for the buffer by
> simulating the rewriting. It's not nice but I don't know of any other
> solution.
Hi Stefan,
For the case of size==0, why don't we iterate through all the xattr,
filter them, remap them and then return the size to process in user
namespace. That should fix this? I thought that's what
xattr_list_userns_rewrite() was doing. But looks like this logic will not
kick in for the case of size==0 due to "!list" condition.
Also we could probably replace "!list" with "!size" wheverever required.
Its little easy to read and understand.
For the other case where some xattrs can get filtered out and we report
a buffer size bigger than actually needed, I am hoping that its acceptable
and none of the existing users are broken.
Thanks
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 11:48 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 11:48 UTC (permalink / raw)
To: linux-security-module
On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> >
> > [..]
> > > +/*
> > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > + * or determine needed size for attribute list
> > > + * in case size == 0
> > > + *
> > > + * In a user namespace we do not present all extended attributes to the
> > > + * user. We filter out those that are in the list of userns supported xattr.
> > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > + * for that uid in the current user namespace.
> > > + *
> > > + * @list: list of 0-byte separated xattr names
> > > + * @size: the size of the list; may be 0 to determine needed list size
> > > + * @list_maxlen: allocated buffer size of list
> > > + */
> > > +static ssize_t
> > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > +{
> > > + char *nlist = NULL;
> > > + size_t s_off, len, nlen;
> > > + ssize_t d_off;
> > > + char *name, *newname;
> > > +
> > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > size will never be less than 0 here. Only caller calls this function only
> > if size is >0. So can we remove this?
>
> Correct.
>
> >
> > What about case of "!list". So if user space called listxattr(foo, NULL,
> > 0), we want to return the size of buffer as if all the xattrs will be
> > returned to user space. But in practice we probably will filter out some
> > xattrs so actually returned string will be smaller than size reported
> > previously.
>
> This case of size=0 is a problem in userns. Depending on the mapping of the
> userid's the list can expand. A security.foo at uid=100 can become
> security.foo at uid=100000, if the mapping is set up so that uid 100 on the
> host becomes uid 100000 inside the container. So for now we only have
> security.capability and the way I solved this is by allocating a 65k buffer
> when calling from a userns. In this buffer where we gather the xattr names
> and then walk them to determine the size that's needed for the buffer by
> simulating the rewriting. It's not nice but I don't know of any other
> solution.
Hi Stefan,
For the case of size==0, why don't we iterate through all the xattr,
filter them, remap them and then return the size to process in user
namespace. That should fix this? I thought that's what
xattr_list_userns_rewrite() was doing. But looks like this logic will not
kick in for the case of size==0 due to "!list" condition.
Also we could probably replace "!list" with "!size" wheverever required.
Its little easy to read and understand.
For the other case where some xattrs can get filtered out and we report
a buffer size bigger than actually needed, I am hoping that its acceptable
and none of the existing users are broken.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 11:48 ` Vivek Goyal
(?)
@ 2017-07-18 12:05 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 12:05 UTC (permalink / raw)
To: Vivek Goyal
Cc: Stefan Berger, ebiederm, containers, lkp, linux-kernel, zohar,
tycho, serge, James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>
>>> [..]
>>>> +/*
>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>> + * or determine needed size for attribute list
>>>> + * in case size == 0
>>>> + *
>>>> + * In a user namespace we do not present all extended attributes to the
>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>> + * for that uid in the current user namespace.
>>>> + *
>>>> + * @list: list of 0-byte separated xattr names
>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>> + * @list_maxlen: allocated buffer size of list
>>>> + */
>>>> +static ssize_t
>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>> +{
>>>> + char *nlist = NULL;
>>>> + size_t s_off, len, nlen;
>>>> + ssize_t d_off;
>>>> + char *name, *newname;
>>>> +
>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>> size will never be less than 0 here. Only caller calls this function only
>>> if size is >0. So can we remove this?
>> Correct.
>>
>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>> 0), we want to return the size of buffer as if all the xattrs will be
>>> returned to user space. But in practice we probably will filter out some
>>> xattrs so actually returned string will be smaller than size reported
>>> previously.
>> This case of size=0 is a problem in userns. Depending on the mapping of the
>> userid's the list can expand. A security.foo@uid=100 can become
>> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
>> host becomes uid 100000 inside the container. So for now we only have
>> security.capability and the way I solved this is by allocating a 65k buffer
>> when calling from a userns. In this buffer where we gather the xattr names
>> and then walk them to determine the size that's needed for the buffer by
>> simulating the rewriting. It's not nice but I don't know of any other
>> solution.
> Hi Stefan,
>
> For the case of size==0, why don't we iterate through all the xattr,
> filter them, remap them and then return the size to process in user
> namespace. That should fix this? I thought that's what
For the size==0 we need a temp. buffer where the raw xattr names are
written to so that the xattr_list_userns_rewrite() can actually rewrite
what the filesystem drivers returned. Not knowing exactly how big that
buffer should be, I allocate 65k for it. From what I read there is a 64k
limit on the vfs layer for xattrs, probably including xattr values. So
65k would for sure be enough also if each one of the xattr names becomes
bigger.
@@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
size_t size, bool rewrite)
{
struct inode *inode = d_inode(dentry);
ssize_t error;
+ bool getsize = false;
error = security_inode_listxattr(dentry);
if (error)
return error;
+
+ if (!size) {
+ if (current_user_ns() != &init_user_ns) {
+ size = 65 * 1024;
+ list = kmalloc(size, GFP_KERNEL);
+ }
+ getsize = true;
+ }
+
if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
error = -EOPNOTSUPP;
error = inode->i_op->listxattr(dentry, list, size);
@@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list,
size_t size, bool rewrite)
if (error > 0 && rewrite)
error = xattr_list_userns_rewrite(list, error, size);
+ if (getsize)
+ kfree(list);
+
return error;
}
EXPORT_SYMBOL_GPL(vfs_listxattr);
Stefan
> xattr_list_userns_rewrite() was doing. But looks like this logic will not
> kick in for the case of size==0 due to "!list" condition.
>
> Also we could probably replace "!list" with "!size" wheverever required.
> Its little easy to read and understand.
>
> For the other case where some xattrs can get filtered out and we report
> a buffer size bigger than actually needed, I am hoping that its acceptable
> and none of the existing users are broken.
>
> Thanks
> Vivek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 12:05 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 12:05 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4769 bytes --]
On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>
>>> [..]
>>>> +/*
>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>> + * or determine needed size for attribute list
>>>> + * in case size == 0
>>>> + *
>>>> + * In a user namespace we do not present all extended attributes to the
>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>> + * for that uid in the current user namespace.
>>>> + *
>>>> + * @list: list of 0-byte separated xattr names
>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>> + * @list_maxlen: allocated buffer size of list
>>>> + */
>>>> +static ssize_t
>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>> +{
>>>> + char *nlist = NULL;
>>>> + size_t s_off, len, nlen;
>>>> + ssize_t d_off;
>>>> + char *name, *newname;
>>>> +
>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>> size will never be less than 0 here. Only caller calls this function only
>>> if size is >0. So can we remove this?
>> Correct.
>>
>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>> 0), we want to return the size of buffer as if all the xattrs will be
>>> returned to user space. But in practice we probably will filter out some
>>> xattrs so actually returned string will be smaller than size reported
>>> previously.
>> This case of size=0 is a problem in userns. Depending on the mapping of the
>> userid's the list can expand. A security.foo(a)uid=100 can become
>> security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
>> host becomes uid 100000 inside the container. So for now we only have
>> security.capability and the way I solved this is by allocating a 65k buffer
>> when calling from a userns. In this buffer where we gather the xattr names
>> and then walk them to determine the size that's needed for the buffer by
>> simulating the rewriting. It's not nice but I don't know of any other
>> solution.
> Hi Stefan,
>
> For the case of size==0, why don't we iterate through all the xattr,
> filter them, remap them and then return the size to process in user
> namespace. That should fix this? I thought that's what
For the size==0 we need a temp. buffer where the raw xattr names are
written to so that the xattr_list_userns_rewrite() can actually rewrite
what the filesystem drivers returned. Not knowing exactly how big that
buffer should be, I allocate 65k for it. From what I read there is a 64k
limit on the vfs layer for xattrs, probably including xattr values. So
65k would for sure be enough also if each one of the xattr names becomes
bigger.
@@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
size_t size, bool rewrite)
{
struct inode *inode = d_inode(dentry);
ssize_t error;
+ bool getsize = false;
error = security_inode_listxattr(dentry);
if (error)
return error;
+
+ if (!size) {
+ if (current_user_ns() != &init_user_ns) {
+ size = 65 * 1024;
+ list = kmalloc(size, GFP_KERNEL);
+ }
+ getsize = true;
+ }
+
if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
error = -EOPNOTSUPP;
error = inode->i_op->listxattr(dentry, list, size);
@@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list,
size_t size, bool rewrite)
if (error > 0 && rewrite)
error = xattr_list_userns_rewrite(list, error, size);
+ if (getsize)
+ kfree(list);
+
return error;
}
EXPORT_SYMBOL_GPL(vfs_listxattr);
Stefan
> xattr_list_userns_rewrite() was doing. But looks like this logic will not
> kick in for the case of size==0 due to "!list" condition.
>
> Also we could probably replace "!list" with "!size" wheverever required.
> Its little easy to read and understand.
>
> For the other case where some xattrs can get filtered out and we report
> a buffer size bigger than actually needed, I am hoping that its acceptable
> and none of the existing users are broken.
>
> Thanks
> Vivek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 12:05 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 12:05 UTC (permalink / raw)
To: linux-security-module
On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>
>>> [..]
>>>> +/*
>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>> + * or determine needed size for attribute list
>>>> + * in case size == 0
>>>> + *
>>>> + * In a user namespace we do not present all extended attributes to the
>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>> + * for that uid in the current user namespace.
>>>> + *
>>>> + * @list: list of 0-byte separated xattr names
>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>> + * @list_maxlen: allocated buffer size of list
>>>> + */
>>>> +static ssize_t
>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>> +{
>>>> + char *nlist = NULL;
>>>> + size_t s_off, len, nlen;
>>>> + ssize_t d_off;
>>>> + char *name, *newname;
>>>> +
>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>> size will never be less than 0 here. Only caller calls this function only
>>> if size is >0. So can we remove this?
>> Correct.
>>
>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>> 0), we want to return the size of buffer as if all the xattrs will be
>>> returned to user space. But in practice we probably will filter out some
>>> xattrs so actually returned string will be smaller than size reported
>>> previously.
>> This case of size=0 is a problem in userns. Depending on the mapping of the
>> userid's the list can expand. A security.foo at uid=100 can become
>> security.foo at uid=100000, if the mapping is set up so that uid 100 on the
>> host becomes uid 100000 inside the container. So for now we only have
>> security.capability and the way I solved this is by allocating a 65k buffer
>> when calling from a userns. In this buffer where we gather the xattr names
>> and then walk them to determine the size that's needed for the buffer by
>> simulating the rewriting. It's not nice but I don't know of any other
>> solution.
> Hi Stefan,
>
> For the case of size==0, why don't we iterate through all the xattr,
> filter them, remap them and then return the size to process in user
> namespace. That should fix this? I thought that's what
For the size==0 we need a temp. buffer where the raw xattr names are
written to so that the xattr_list_userns_rewrite() can actually rewrite
what the filesystem drivers returned. Not knowing exactly how big that
buffer should be, I allocate 65k for it. From what I read there is a 64k
limit on the vfs layer for xattrs, probably including xattr values. So
65k would for sure be enough also if each one of the xattr names becomes
bigger.
@@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
size_t size, bool rewrite)
{
struct inode *inode = d_inode(dentry);
ssize_t error;
+ bool getsize = false;
error = security_inode_listxattr(dentry);
if (error)
return error;
+
+ if (!size) {
+ if (current_user_ns() != &init_user_ns) {
+ size = 65 * 1024;
+ list = kmalloc(size, GFP_KERNEL);
+ }
+ getsize = true;
+ }
+
if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
error = -EOPNOTSUPP;
error = inode->i_op->listxattr(dentry, list, size);
@@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list,
size_t size, bool rewrite)
if (error > 0 && rewrite)
error = xattr_list_userns_rewrite(list, error, size);
+ if (getsize)
+ kfree(list);
+
return error;
}
EXPORT_SYMBOL_GPL(vfs_listxattr);
Stefan
> xattr_list_userns_rewrite() was doing. But looks like this logic will not
> kick in for the case of size==0 due to "!list" condition.
>
> Also we could probably replace "!list" with "!size" wheverever required.
> Its little easy to read and understand.
>
> For the other case where some xattrs can get filtered out and we report
> a buffer size bigger than actually needed, I am hoping that its acceptable
> and none of the existing users are broken.
>
> Thanks
> Vivek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 12:05 ` Stefan Berger
(?)
@ 2017-07-18 12:30 ` Vivek Goyal
-1 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 12:30 UTC (permalink / raw)
To: Stefan Berger
Cc: Stefan Berger, ebiederm, containers, lkp, linux-kernel, zohar,
tycho, serge, James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > >
> > > > [..]
> > > > > +/*
> > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > + * or determine needed size for attribute list
> > > > > + * in case size == 0
> > > > > + *
> > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > + * for that uid in the current user namespace.
> > > > > + *
> > > > > + * @list: list of 0-byte separated xattr names
> > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > + * @list_maxlen: allocated buffer size of list
> > > > > + */
> > > > > +static ssize_t
> > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > +{
> > > > > + char *nlist = NULL;
> > > > > + size_t s_off, len, nlen;
> > > > > + ssize_t d_off;
> > > > > + char *name, *newname;
> > > > > +
> > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > size will never be less than 0 here. Only caller calls this function only
> > > > if size is >0. So can we remove this?
> > > Correct.
> > >
> > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > returned to user space. But in practice we probably will filter out some
> > > > xattrs so actually returned string will be smaller than size reported
> > > > previously.
> > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > userid's the list can expand. A security.foo@uid=100 can become
> > > security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> > > host becomes uid 100000 inside the container. So for now we only have
> > > security.capability and the way I solved this is by allocating a 65k buffer
> > > when calling from a userns. In this buffer where we gather the xattr names
> > > and then walk them to determine the size that's needed for the buffer by
> > > simulating the rewriting. It's not nice but I don't know of any other
> > > solution.
> > Hi Stefan,
> >
> > For the case of size==0, why don't we iterate through all the xattr,
> > filter them, remap them and then return the size to process in user
> > namespace. That should fix this? I thought that's what
>
>
> For the size==0 we need a temp. buffer where the raw xattr names are written
> to so that the xattr_list_userns_rewrite() can actually rewrite what the
> filesystem drivers returned.
I am probably missing something, but for the case of size==0, we don't
have to copy all xattrs. We just need to determine size. So we can walk
through each xattr, remap it and add to the size. I mean there should not
be a need to allocate this 65K buffer. Just enough space needed to be
able to store remapped xattr.
You are already doing it in xattr_parse_uid_from_kuid(). It returns the
buffer containing remapped xattr. So we should be able to just determine
the size and free the buffer. And do it for all the xattrs returned by
filesystem.
What am I missing?
Vivek
> Not knowing exactly how big that buffer should
> be, I allocate 65k for it. From what I read there is a 64k limit on the vfs
> layer for xattrs, probably including xattr values. So 65k would for sure be
> enough also if each one of the xattr names becomes bigger.
>
> @@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
> size_t size, bool rewrite)
> {
> struct inode *inode = d_inode(dentry);
> ssize_t error;
> + bool getsize = false;
>
> error = security_inode_listxattr(dentry);
> if (error)
> return error;
> +
> + if (!size) {
> + if (current_user_ns() != &init_user_ns) {
> + size = 65 * 1024;
> + list = kmalloc(size, GFP_KERNEL);
> + }
> + getsize = true;
> + }
> +
> if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
> error = -EOPNOTSUPP;
> error = inode->i_op->listxattr(dentry, list, size);
> @@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t
> size, bool rewrite)
> if (error > 0 && rewrite)
> error = xattr_list_userns_rewrite(list, error, size);
>
> + if (getsize)
> + kfree(list);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_listxattr);
>
>
> Stefan
>
> > xattr_list_userns_rewrite() was doing. But looks like this logic will not
> > kick in for the case of size==0 due to "!list" condition.
> >
> > Also we could probably replace "!list" with "!size" wheverever required.
> > Its little easy to read and understand.
> >
> > For the other case where some xattrs can get filtered out and we report
> > a buffer size bigger than actually needed, I am hoping that its acceptable
> > and none of the existing users are broken.
> >
> > Thanks
> > Vivek
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 12:30 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 12:30 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 5739 bytes --]
On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > >
> > > > [..]
> > > > > +/*
> > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > + * or determine needed size for attribute list
> > > > > + * in case size == 0
> > > > > + *
> > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > + * for that uid in the current user namespace.
> > > > > + *
> > > > > + * @list: list of 0-byte separated xattr names
> > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > + * @list_maxlen: allocated buffer size of list
> > > > > + */
> > > > > +static ssize_t
> > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > +{
> > > > > + char *nlist = NULL;
> > > > > + size_t s_off, len, nlen;
> > > > > + ssize_t d_off;
> > > > > + char *name, *newname;
> > > > > +
> > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > size will never be less than 0 here. Only caller calls this function only
> > > > if size is >0. So can we remove this?
> > > Correct.
> > >
> > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > returned to user space. But in practice we probably will filter out some
> > > > xattrs so actually returned string will be smaller than size reported
> > > > previously.
> > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > userid's the list can expand. A security.foo(a)uid=100 can become
> > > security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
> > > host becomes uid 100000 inside the container. So for now we only have
> > > security.capability and the way I solved this is by allocating a 65k buffer
> > > when calling from a userns. In this buffer where we gather the xattr names
> > > and then walk them to determine the size that's needed for the buffer by
> > > simulating the rewriting. It's not nice but I don't know of any other
> > > solution.
> > Hi Stefan,
> >
> > For the case of size==0, why don't we iterate through all the xattr,
> > filter them, remap them and then return the size to process in user
> > namespace. That should fix this? I thought that's what
>
>
> For the size==0 we need a temp. buffer where the raw xattr names are written
> to so that the xattr_list_userns_rewrite() can actually rewrite what the
> filesystem drivers returned.
I am probably missing something, but for the case of size==0, we don't
have to copy all xattrs. We just need to determine size. So we can walk
through each xattr, remap it and add to the size. I mean there should not
be a need to allocate this 65K buffer. Just enough space needed to be
able to store remapped xattr.
You are already doing it in xattr_parse_uid_from_kuid(). It returns the
buffer containing remapped xattr. So we should be able to just determine
the size and free the buffer. And do it for all the xattrs returned by
filesystem.
What am I missing?
Vivek
> Not knowing exactly how big that buffer should
> be, I allocate 65k for it. From what I read there is a 64k limit on the vfs
> layer for xattrs, probably including xattr values. So 65k would for sure be
> enough also if each one of the xattr names becomes bigger.
>
> @@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
> size_t size, bool rewrite)
> {
> struct inode *inode = d_inode(dentry);
> ssize_t error;
> + bool getsize = false;
>
> error = security_inode_listxattr(dentry);
> if (error)
> return error;
> +
> + if (!size) {
> + if (current_user_ns() != &init_user_ns) {
> + size = 65 * 1024;
> + list = kmalloc(size, GFP_KERNEL);
> + }
> + getsize = true;
> + }
> +
> if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
> error = -EOPNOTSUPP;
> error = inode->i_op->listxattr(dentry, list, size);
> @@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t
> size, bool rewrite)
> if (error > 0 && rewrite)
> error = xattr_list_userns_rewrite(list, error, size);
>
> + if (getsize)
> + kfree(list);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_listxattr);
>
>
> Stefan
>
> > xattr_list_userns_rewrite() was doing. But looks like this logic will not
> > kick in for the case of size==0 due to "!list" condition.
> >
> > Also we could probably replace "!list" with "!size" wheverever required.
> > Its little easy to read and understand.
> >
> > For the other case where some xattrs can get filtered out and we report
> > a buffer size bigger than actually needed, I am hoping that its acceptable
> > and none of the existing users are broken.
> >
> > Thanks
> > Vivek
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> > the body of a message to majordomo(a)vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 12:30 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 12:30 UTC (permalink / raw)
To: linux-security-module
On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > >
> > > > [..]
> > > > > +/*
> > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > + * or determine needed size for attribute list
> > > > > + * in case size == 0
> > > > > + *
> > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > + * for that uid in the current user namespace.
> > > > > + *
> > > > > + * @list: list of 0-byte separated xattr names
> > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > + * @list_maxlen: allocated buffer size of list
> > > > > + */
> > > > > +static ssize_t
> > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > +{
> > > > > + char *nlist = NULL;
> > > > > + size_t s_off, len, nlen;
> > > > > + ssize_t d_off;
> > > > > + char *name, *newname;
> > > > > +
> > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > size will never be less than 0 here. Only caller calls this function only
> > > > if size is >0. So can we remove this?
> > > Correct.
> > >
> > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > returned to user space. But in practice we probably will filter out some
> > > > xattrs so actually returned string will be smaller than size reported
> > > > previously.
> > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > userid's the list can expand. A security.foo at uid=100 can become
> > > security.foo at uid=100000, if the mapping is set up so that uid 100 on the
> > > host becomes uid 100000 inside the container. So for now we only have
> > > security.capability and the way I solved this is by allocating a 65k buffer
> > > when calling from a userns. In this buffer where we gather the xattr names
> > > and then walk them to determine the size that's needed for the buffer by
> > > simulating the rewriting. It's not nice but I don't know of any other
> > > solution.
> > Hi Stefan,
> >
> > For the case of size==0, why don't we iterate through all the xattr,
> > filter them, remap them and then return the size to process in user
> > namespace. That should fix this? I thought that's what
>
>
> For the size==0 we need a temp. buffer where the raw xattr names are written
> to so that the xattr_list_userns_rewrite() can actually rewrite what the
> filesystem drivers returned.
I am probably missing something, but for the case of size==0, we don't
have to copy all xattrs. We just need to determine size. So we can walk
through each xattr, remap it and add to the size. I mean there should not
be a need to allocate this 65K buffer. Just enough space needed to be
able to store remapped xattr.
You are already doing it in xattr_parse_uid_from_kuid(). It returns the
buffer containing remapped xattr. So we should be able to just determine
the size and free the buffer. And do it for all the xattrs returned by
filesystem.
What am I missing?
Vivek
> Not knowing exactly how big that buffer should
> be, I allocate 65k for it. From what I read there is a 64k limit on the vfs
> layer for xattrs, probably including xattr values. So 65k would for sure be
> enough also if each one of the xattr names becomes bigger.
>
> @@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
> size_t size, bool rewrite)
> {
> struct inode *inode = d_inode(dentry);
> ssize_t error;
> + bool getsize = false;
>
> error = security_inode_listxattr(dentry);
> if (error)
> return error;
> +
> + if (!size) {
> + if (current_user_ns() != &init_user_ns) {
> + size = 65 * 1024;
> + list = kmalloc(size, GFP_KERNEL);
> + }
> + getsize = true;
> + }
> +
> if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
> error = -EOPNOTSUPP;
> error = inode->i_op->listxattr(dentry, list, size);
> @@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t
> size, bool rewrite)
> if (error > 0 && rewrite)
> error = xattr_list_userns_rewrite(list, error, size);
>
> + if (getsize)
> + kfree(list);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_listxattr);
>
>
> Stefan
>
> > xattr_list_userns_rewrite() was doing. But looks like this logic will not
> > kick in for the case of size==0 due to "!list" condition.
> >
> > Also we could probably replace "!list" with "!size" wheverever required.
> > Its little easy to read and understand.
> >
> > For the other case where some xattrs can get filtered out and we report
> > a buffer size bigger than actually needed, I am hoping that its acceptable
> > and none of the existing users are broken.
> >
> > Thanks
> > Vivek
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 12:30 ` Vivek Goyal
(?)
@ 2017-07-18 12:36 ` Vivek Goyal
-1 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 12:36 UTC (permalink / raw)
To: Stefan Berger
Cc: Stefan Berger, ebiederm, containers, lkp, linux-kernel, zohar,
tycho, serge, James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > > >
> > > > > [..]
> > > > > > +/*
> > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > > + * or determine needed size for attribute list
> > > > > > + * in case size == 0
> > > > > > + *
> > > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > > + * for that uid in the current user namespace.
> > > > > > + *
> > > > > > + * @list: list of 0-byte separated xattr names
> > > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > > + * @list_maxlen: allocated buffer size of list
> > > > > > + */
> > > > > > +static ssize_t
> > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > > +{
> > > > > > + char *nlist = NULL;
> > > > > > + size_t s_off, len, nlen;
> > > > > > + ssize_t d_off;
> > > > > > + char *name, *newname;
> > > > > > +
> > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > > size will never be less than 0 here. Only caller calls this function only
> > > > > if size is >0. So can we remove this?
> > > > Correct.
> > > >
> > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > > returned to user space. But in practice we probably will filter out some
> > > > > xattrs so actually returned string will be smaller than size reported
> > > > > previously.
> > > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > > userid's the list can expand. A security.foo@uid=100 can become
> > > > security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> > > > host becomes uid 100000 inside the container. So for now we only have
> > > > security.capability and the way I solved this is by allocating a 65k buffer
> > > > when calling from a userns. In this buffer where we gather the xattr names
> > > > and then walk them to determine the size that's needed for the buffer by
> > > > simulating the rewriting. It's not nice but I don't know of any other
> > > > solution.
> > > Hi Stefan,
> > >
> > > For the case of size==0, why don't we iterate through all the xattr,
> > > filter them, remap them and then return the size to process in user
> > > namespace. That should fix this? I thought that's what
> >
> >
> > For the size==0 we need a temp. buffer where the raw xattr names are written
> > to so that the xattr_list_userns_rewrite() can actually rewrite what the
> > filesystem drivers returned.
>
> I am probably missing something, but for the case of size==0, we don't
> have to copy all xattrs. We just need to determine size. So we can walk
> through each xattr, remap it and add to the size. I mean there should not
> be a need to allocate this 65K buffer. Just enough space needed to be
> able to store remapped xattr.
>
> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> buffer containing remapped xattr. So we should be able to just determine
> the size and free the buffer. And do it for all the xattrs returned by
> filesystem.
>
> What am I missing?
Oh, I think I get it. If I don't pass a buffer to underlying driver, then
it will just return the size (and not actual list). So that's why you are
allocating that big buffer and getting the whole list internally, doing
mapping and returning size to user space. Hmm...
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 12:36 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 12:36 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4150 bytes --]
On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > > >
> > > > > [..]
> > > > > > +/*
> > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > > + * or determine needed size for attribute list
> > > > > > + * in case size == 0
> > > > > > + *
> > > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > > + * for that uid in the current user namespace.
> > > > > > + *
> > > > > > + * @list: list of 0-byte separated xattr names
> > > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > > + * @list_maxlen: allocated buffer size of list
> > > > > > + */
> > > > > > +static ssize_t
> > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > > +{
> > > > > > + char *nlist = NULL;
> > > > > > + size_t s_off, len, nlen;
> > > > > > + ssize_t d_off;
> > > > > > + char *name, *newname;
> > > > > > +
> > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > > size will never be less than 0 here. Only caller calls this function only
> > > > > if size is >0. So can we remove this?
> > > > Correct.
> > > >
> > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > > returned to user space. But in practice we probably will filter out some
> > > > > xattrs so actually returned string will be smaller than size reported
> > > > > previously.
> > > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > > userid's the list can expand. A security.foo(a)uid=100 can become
> > > > security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
> > > > host becomes uid 100000 inside the container. So for now we only have
> > > > security.capability and the way I solved this is by allocating a 65k buffer
> > > > when calling from a userns. In this buffer where we gather the xattr names
> > > > and then walk them to determine the size that's needed for the buffer by
> > > > simulating the rewriting. It's not nice but I don't know of any other
> > > > solution.
> > > Hi Stefan,
> > >
> > > For the case of size==0, why don't we iterate through all the xattr,
> > > filter them, remap them and then return the size to process in user
> > > namespace. That should fix this? I thought that's what
> >
> >
> > For the size==0 we need a temp. buffer where the raw xattr names are written
> > to so that the xattr_list_userns_rewrite() can actually rewrite what the
> > filesystem drivers returned.
>
> I am probably missing something, but for the case of size==0, we don't
> have to copy all xattrs. We just need to determine size. So we can walk
> through each xattr, remap it and add to the size. I mean there should not
> be a need to allocate this 65K buffer. Just enough space needed to be
> able to store remapped xattr.
>
> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> buffer containing remapped xattr. So we should be able to just determine
> the size and free the buffer. And do it for all the xattrs returned by
> filesystem.
>
> What am I missing?
Oh, I think I get it. If I don't pass a buffer to underlying driver, then
it will just return the size (and not actual list). So that's why you are
allocating that big buffer and getting the whole list internally, doing
mapping and returning size to user space. Hmm...
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 12:36 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 12:36 UTC (permalink / raw)
To: linux-security-module
On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > > >
> > > > > [..]
> > > > > > +/*
> > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > > + * or determine needed size for attribute list
> > > > > > + * in case size == 0
> > > > > > + *
> > > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > > + * for that uid in the current user namespace.
> > > > > > + *
> > > > > > + * @list: list of 0-byte separated xattr names
> > > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > > + * @list_maxlen: allocated buffer size of list
> > > > > > + */
> > > > > > +static ssize_t
> > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > > +{
> > > > > > + char *nlist = NULL;
> > > > > > + size_t s_off, len, nlen;
> > > > > > + ssize_t d_off;
> > > > > > + char *name, *newname;
> > > > > > +
> > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > > size will never be less than 0 here. Only caller calls this function only
> > > > > if size is >0. So can we remove this?
> > > > Correct.
> > > >
> > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > > returned to user space. But in practice we probably will filter out some
> > > > > xattrs so actually returned string will be smaller than size reported
> > > > > previously.
> > > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > > userid's the list can expand. A security.foo at uid=100 can become
> > > > security.foo at uid=100000, if the mapping is set up so that uid 100 on the
> > > > host becomes uid 100000 inside the container. So for now we only have
> > > > security.capability and the way I solved this is by allocating a 65k buffer
> > > > when calling from a userns. In this buffer where we gather the xattr names
> > > > and then walk them to determine the size that's needed for the buffer by
> > > > simulating the rewriting. It's not nice but I don't know of any other
> > > > solution.
> > > Hi Stefan,
> > >
> > > For the case of size==0, why don't we iterate through all the xattr,
> > > filter them, remap them and then return the size to process in user
> > > namespace. That should fix this? I thought that's what
> >
> >
> > For the size==0 we need a temp. buffer where the raw xattr names are written
> > to so that the xattr_list_userns_rewrite() can actually rewrite what the
> > filesystem drivers returned.
>
> I am probably missing something, but for the case of size==0, we don't
> have to copy all xattrs. We just need to determine size. So we can walk
> through each xattr, remap it and add to the size. I mean there should not
> be a need to allocate this 65K buffer. Just enough space needed to be
> able to store remapped xattr.
>
> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> buffer containing remapped xattr. So we should be able to just determine
> the size and free the buffer. And do it for all the xattrs returned by
> filesystem.
>
> What am I missing?
Oh, I think I get it. If I don't pass a buffer to underlying driver, then
it will just return the size (and not actual list). So that's why you are
allocating that big buffer and getting the whole list internally, doing
mapping and returning size to user space. Hmm...
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <20170718123603.GC8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170718123603.GC8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-18 13:29 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-18 13:29 UTC (permalink / raw)
To: Vivek Goyal
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk, Stefan Berger,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote:
>> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>> > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>> > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>> > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>> > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>> > > > >
>> > > > > [..]
>> > > > > > +/*
>> > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> > > > > > + * or determine needed size for attribute list
>> > > > > > + * in case size == 0
>> > > > > > + *
>> > > > > > + * In a user namespace we do not present all extended attributes to the
>> > > > > > + * user. We filter out those that are in the list of userns supported xattr.
>> > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> > > > > > + * for that uid in the current user namespace.
>> > > > > > + *
>> > > > > > + * @list: list of 0-byte separated xattr names
>> > > > > > + * @size: the size of the list; may be 0 to determine needed list size
>> > > > > > + * @list_maxlen: allocated buffer size of list
>> > > > > > + */
>> > > > > > +static ssize_t
>> > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> > > > > > +{
>> > > > > > + char *nlist = NULL;
>> > > > > > + size_t s_off, len, nlen;
>> > > > > > + ssize_t d_off;
>> > > > > > + char *name, *newname;
>> > > > > > +
>> > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> > > > > size will never be less than 0 here. Only caller calls this function only
>> > > > > if size is >0. So can we remove this?
>> > > > Correct.
>> > > >
>> > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
>> > > > > 0), we want to return the size of buffer as if all the xattrs will be
>> > > > > returned to user space. But in practice we probably will filter out some
>> > > > > xattrs so actually returned string will be smaller than size reported
>> > > > > previously.
>> > > > This case of size=0 is a problem in userns. Depending on the mapping of the
>> > > > userid's the list can expand. A security.foo@uid=100 can become
>> > > > security.foo@uid=100000, if the mapping is set up so that uid 100 on the
>> > > > host becomes uid 100000 inside the container. So for now we only have
>> > > > security.capability and the way I solved this is by allocating a 65k buffer
>> > > > when calling from a userns. In this buffer where we gather the xattr names
>> > > > and then walk them to determine the size that's needed for the buffer by
>> > > > simulating the rewriting. It's not nice but I don't know of any other
>> > > > solution.
>> > > Hi Stefan,
>> > >
>> > > For the case of size==0, why don't we iterate through all the xattr,
>> > > filter them, remap them and then return the size to process in user
>> > > namespace. That should fix this? I thought that's what
>> >
>> >
>> > For the size==0 we need a temp. buffer where the raw xattr names are written
>> > to so that the xattr_list_userns_rewrite() can actually rewrite what the
>> > filesystem drivers returned.
>>
>> I am probably missing something, but for the case of size==0, we don't
>> have to copy all xattrs. We just need to determine size. So we can walk
>> through each xattr, remap it and add to the size. I mean there should not
>> be a need to allocate this 65K buffer. Just enough space needed to be
>> able to store remapped xattr.
>>
>> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
>> buffer containing remapped xattr. So we should be able to just determine
>> the size and free the buffer. And do it for all the xattrs returned by
>> filesystem.
>>
>> What am I missing?
>
> Oh, I think I get it. If I don't pass a buffer to underlying driver, then
> it will just return the size (and not actual list). So that's why you are
> allocating that big buffer and getting the whole list internally, doing
> mapping and returning size to user space. Hmm...
A valid reason to be leary of storing attributs in the xattrs.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 12:36 ` Vivek Goyal
(?)
@ 2017-07-18 13:29 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-18 13:29 UTC (permalink / raw)
To: Vivek Goyal
Cc: Stefan Berger, Stefan Berger, containers, lkp, linux-kernel,
zohar, tycho, serge, James.Bottomley, christian.brauner,
amir73il, linux-security-module, casey
Vivek Goyal <vgoyal@redhat.com> writes:
> On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote:
>> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>> > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>> > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>> > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>> > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>> > > > >
>> > > > > [..]
>> > > > > > +/*
>> > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> > > > > > + * or determine needed size for attribute list
>> > > > > > + * in case size == 0
>> > > > > > + *
>> > > > > > + * In a user namespace we do not present all extended attributes to the
>> > > > > > + * user. We filter out those that are in the list of userns supported xattr.
>> > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> > > > > > + * for that uid in the current user namespace.
>> > > > > > + *
>> > > > > > + * @list: list of 0-byte separated xattr names
>> > > > > > + * @size: the size of the list; may be 0 to determine needed list size
>> > > > > > + * @list_maxlen: allocated buffer size of list
>> > > > > > + */
>> > > > > > +static ssize_t
>> > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> > > > > > +{
>> > > > > > + char *nlist = NULL;
>> > > > > > + size_t s_off, len, nlen;
>> > > > > > + ssize_t d_off;
>> > > > > > + char *name, *newname;
>> > > > > > +
>> > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> > > > > size will never be less than 0 here. Only caller calls this function only
>> > > > > if size is >0. So can we remove this?
>> > > > Correct.
>> > > >
>> > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
>> > > > > 0), we want to return the size of buffer as if all the xattrs will be
>> > > > > returned to user space. But in practice we probably will filter out some
>> > > > > xattrs so actually returned string will be smaller than size reported
>> > > > > previously.
>> > > > This case of size=0 is a problem in userns. Depending on the mapping of the
>> > > > userid's the list can expand. A security.foo@uid=100 can become
>> > > > security.foo@uid=100000, if the mapping is set up so that uid 100 on the
>> > > > host becomes uid 100000 inside the container. So for now we only have
>> > > > security.capability and the way I solved this is by allocating a 65k buffer
>> > > > when calling from a userns. In this buffer where we gather the xattr names
>> > > > and then walk them to determine the size that's needed for the buffer by
>> > > > simulating the rewriting. It's not nice but I don't know of any other
>> > > > solution.
>> > > Hi Stefan,
>> > >
>> > > For the case of size==0, why don't we iterate through all the xattr,
>> > > filter them, remap them and then return the size to process in user
>> > > namespace. That should fix this? I thought that's what
>> >
>> >
>> > For the size==0 we need a temp. buffer where the raw xattr names are written
>> > to so that the xattr_list_userns_rewrite() can actually rewrite what the
>> > filesystem drivers returned.
>>
>> I am probably missing something, but for the case of size==0, we don't
>> have to copy all xattrs. We just need to determine size. So we can walk
>> through each xattr, remap it and add to the size. I mean there should not
>> be a need to allocate this 65K buffer. Just enough space needed to be
>> able to store remapped xattr.
>>
>> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
>> buffer containing remapped xattr. So we should be able to just determine
>> the size and free the buffer. And do it for all the xattrs returned by
>> filesystem.
>>
>> What am I missing?
>
> Oh, I think I get it. If I don't pass a buffer to underlying driver, then
> it will just return the size (and not actual list). So that's why you are
> allocating that big buffer and getting the whole list internally, doing
> mapping and returning size to user space. Hmm...
A valid reason to be leary of storing attributs in the xattrs.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 13:29 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-18 13:29 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4342 bytes --]
Vivek Goyal <vgoyal@redhat.com> writes:
> On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote:
>> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>> > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>> > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>> > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>> > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>> > > > >
>> > > > > [..]
>> > > > > > +/*
>> > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> > > > > > + * or determine needed size for attribute list
>> > > > > > + * in case size == 0
>> > > > > > + *
>> > > > > > + * In a user namespace we do not present all extended attributes to the
>> > > > > > + * user. We filter out those that are in the list of userns supported xattr.
>> > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> > > > > > + * for that uid in the current user namespace.
>> > > > > > + *
>> > > > > > + * @list: list of 0-byte separated xattr names
>> > > > > > + * @size: the size of the list; may be 0 to determine needed list size
>> > > > > > + * @list_maxlen: allocated buffer size of list
>> > > > > > + */
>> > > > > > +static ssize_t
>> > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> > > > > > +{
>> > > > > > + char *nlist = NULL;
>> > > > > > + size_t s_off, len, nlen;
>> > > > > > + ssize_t d_off;
>> > > > > > + char *name, *newname;
>> > > > > > +
>> > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> > > > > size will never be less than 0 here. Only caller calls this function only
>> > > > > if size is >0. So can we remove this?
>> > > > Correct.
>> > > >
>> > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
>> > > > > 0), we want to return the size of buffer as if all the xattrs will be
>> > > > > returned to user space. But in practice we probably will filter out some
>> > > > > xattrs so actually returned string will be smaller than size reported
>> > > > > previously.
>> > > > This case of size=0 is a problem in userns. Depending on the mapping of the
>> > > > userid's the list can expand. A security.foo(a)uid=100 can become
>> > > > security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
>> > > > host becomes uid 100000 inside the container. So for now we only have
>> > > > security.capability and the way I solved this is by allocating a 65k buffer
>> > > > when calling from a userns. In this buffer where we gather the xattr names
>> > > > and then walk them to determine the size that's needed for the buffer by
>> > > > simulating the rewriting. It's not nice but I don't know of any other
>> > > > solution.
>> > > Hi Stefan,
>> > >
>> > > For the case of size==0, why don't we iterate through all the xattr,
>> > > filter them, remap them and then return the size to process in user
>> > > namespace. That should fix this? I thought that's what
>> >
>> >
>> > For the size==0 we need a temp. buffer where the raw xattr names are written
>> > to so that the xattr_list_userns_rewrite() can actually rewrite what the
>> > filesystem drivers returned.
>>
>> I am probably missing something, but for the case of size==0, we don't
>> have to copy all xattrs. We just need to determine size. So we can walk
>> through each xattr, remap it and add to the size. I mean there should not
>> be a need to allocate this 65K buffer. Just enough space needed to be
>> able to store remapped xattr.
>>
>> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
>> buffer containing remapped xattr. So we should be able to just determine
>> the size and free the buffer. And do it for all the xattrs returned by
>> filesystem.
>>
>> What am I missing?
>
> Oh, I think I get it. If I don't pass a buffer to underlying driver, then
> it will just return the size (and not actual list). So that's why you are
> allocating that big buffer and getting the whole list internally, doing
> mapping and returning size to user space. Hmm...
A valid reason to be leary of storing attributs in the xattrs.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 13:29 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-18 13:29 UTC (permalink / raw)
To: linux-security-module
Vivek Goyal <vgoyal@redhat.com> writes:
> On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote:
>> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>> > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>> > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>> > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>> > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>> > > > >
>> > > > > [..]
>> > > > > > +/*
>> > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> > > > > > + * or determine needed size for attribute list
>> > > > > > + * in case size == 0
>> > > > > > + *
>> > > > > > + * In a user namespace we do not present all extended attributes to the
>> > > > > > + * user. We filter out those that are in the list of userns supported xattr.
>> > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> > > > > > + * for that uid in the current user namespace.
>> > > > > > + *
>> > > > > > + * @list: list of 0-byte separated xattr names
>> > > > > > + * @size: the size of the list; may be 0 to determine needed list size
>> > > > > > + * @list_maxlen: allocated buffer size of list
>> > > > > > + */
>> > > > > > +static ssize_t
>> > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> > > > > > +{
>> > > > > > + char *nlist = NULL;
>> > > > > > + size_t s_off, len, nlen;
>> > > > > > + ssize_t d_off;
>> > > > > > + char *name, *newname;
>> > > > > > +
>> > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> > > > > size will never be less than 0 here. Only caller calls this function only
>> > > > > if size is >0. So can we remove this?
>> > > > Correct.
>> > > >
>> > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
>> > > > > 0), we want to return the size of buffer as if all the xattrs will be
>> > > > > returned to user space. But in practice we probably will filter out some
>> > > > > xattrs so actually returned string will be smaller than size reported
>> > > > > previously.
>> > > > This case of size=0 is a problem in userns. Depending on the mapping of the
>> > > > userid's the list can expand. A security.foo at uid=100 can become
>> > > > security.foo at uid=100000, if the mapping is set up so that uid 100 on the
>> > > > host becomes uid 100000 inside the container. So for now we only have
>> > > > security.capability and the way I solved this is by allocating a 65k buffer
>> > > > when calling from a userns. In this buffer where we gather the xattr names
>> > > > and then walk them to determine the size that's needed for the buffer by
>> > > > simulating the rewriting. It's not nice but I don't know of any other
>> > > > solution.
>> > > Hi Stefan,
>> > >
>> > > For the case of size==0, why don't we iterate through all the xattr,
>> > > filter them, remap them and then return the size to process in user
>> > > namespace. That should fix this? I thought that's what
>> >
>> >
>> > For the size==0 we need a temp. buffer where the raw xattr names are written
>> > to so that the xattr_list_userns_rewrite() can actually rewrite what the
>> > filesystem drivers returned.
>>
>> I am probably missing something, but for the case of size==0, we don't
>> have to copy all xattrs. We just need to determine size. So we can walk
>> through each xattr, remap it and add to the size. I mean there should not
>> be a need to allocate this 65K buffer. Just enough space needed to be
>> able to store remapped xattr.
>>
>> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
>> buffer containing remapped xattr. So we should be able to just determine
>> the size and free the buffer. And do it for all the xattrs returned by
>> filesystem.
>>
>> What am I missing?
>
> Oh, I think I get it. If I don't pass a buffer to underlying driver, then
> it will just return the size (and not actual list). So that's why you are
> allocating that big buffer and getting the whole list internally, doing
> mapping and returning size to user space. Hmm...
A valid reason to be leary of storing attributs in the xattrs.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 12:30 ` Vivek Goyal
(?)
@ 2017-07-18 13:21 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 13:21 UTC (permalink / raw)
To: Vivek Goyal
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On 07/18/2017 08:30 AM, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>>> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>>>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>>>
>>>>> [..]
>>>>>> +/*
>>>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>>>> + * or determine needed size for attribute list
>>>>>> + * in case size == 0
>>>>>> + *
>>>>>> + * In a user namespace we do not present all extended attributes to the
>>>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>>>> + * for that uid in the current user namespace.
>>>>>> + *
>>>>>> + * @list: list of 0-byte separated xattr names
>>>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>>>> + * @list_maxlen: allocated buffer size of list
>>>>>> + */
>>>>>> +static ssize_t
>>>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>>>> +{
>>>>>> + char *nlist = NULL;
>>>>>> + size_t s_off, len, nlen;
>>>>>> + ssize_t d_off;
>>>>>> + char *name, *newname;
>>>>>> +
>>>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>>>> size will never be less than 0 here. Only caller calls this function only
>>>>> if size is >0. So can we remove this?
>>>> Correct.
>>>>
>>>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>>>> 0), we want to return the size of buffer as if all the xattrs will be
>>>>> returned to user space. But in practice we probably will filter out some
>>>>> xattrs so actually returned string will be smaller than size reported
>>>>> previously.
>>>> This case of size=0 is a problem in userns. Depending on the mapping of the
>>>> userid's the list can expand. A security.foo@uid=100 can become
>>>> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
>>>> host becomes uid 100000 inside the container. So for now we only have
>>>> security.capability and the way I solved this is by allocating a 65k buffer
>>>> when calling from a userns. In this buffer where we gather the xattr names
>>>> and then walk them to determine the size that's needed for the buffer by
>>>> simulating the rewriting. It's not nice but I don't know of any other
>>>> solution.
>>> Hi Stefan,
>>>
>>> For the case of size==0, why don't we iterate through all the xattr,
>>> filter them, remap them and then return the size to process in user
>>> namespace. That should fix this? I thought that's what
>>
>> For the size==0 we need a temp. buffer where the raw xattr names are written
>> to so that the xattr_list_userns_rewrite() can actually rewrite what the
>> filesystem drivers returned.
> I am probably missing something, but for the case of size==0, we don't
> have to copy all xattrs. We just need to determine size. So we can walk
> through each xattr, remap it and add to the size. I mean there should not
> be a need to allocate this 65K buffer. Just enough space needed to be
> able to store remapped xattr.
>
> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> buffer containing remapped xattr. So we should be able to just determine
> the size and free the buffer. And do it for all the xattrs returned by
> filesystem.
>
> What am I missing?
The problem is that each filesystem has a function that collects the
xattr names. These functions only return the needed size if size==0 and
don't write anything into a buffer. If the buffer is empty or there is
no buffer, I have nothing to remap and calculate size for. So I pass a
buffer large enough to hold the xattr names to the filesystem functions
so I can then subsequently walk the xattrs and remap them. The remapping
only needs to be done in non-init_user_ns since there the uid parts
(@uid=1000) may need to be rewritten and most importantly, the size of
the needed buffer can increase, depending on how the uid mappings are.
I don't want to extend every filesystem's xattr name gathering function...
Stefan
>
> Vivek
>
>> Not knowing exactly how big that buffer should
>> be, I allocate 65k for it. From what I read there is a 64k limit on the vfs
>> layer for xattrs, probably including xattr values. So 65k would for sure be
>> enough also if each one of the xattr names becomes bigger.
>>
>> @@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
>> size_t size, bool rewrite)
>> {
>> struct inode *inode = d_inode(dentry);
>> ssize_t error;
>> + bool getsize = false;
>>
>> error = security_inode_listxattr(dentry);
>> if (error)
>> return error;
>> +
>> + if (!size) {
>> + if (current_user_ns() != &init_user_ns) {
>> + size = 65 * 1024;
>> + list = kmalloc(size, GFP_KERNEL);
>> + }
>> + getsize = true;
>> + }
>> +
>> if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
>> error = -EOPNOTSUPP;
>> error = inode->i_op->listxattr(dentry, list, size);
>> @@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t
>> size, bool rewrite)
>> if (error > 0 && rewrite)
>> error = xattr_list_userns_rewrite(list, error, size);
>>
>> + if (getsize)
>> + kfree(list);
>> +
>> return error;
>> }
>> EXPORT_SYMBOL_GPL(vfs_listxattr);
>>
>>
>> Stefan
>>
>>> xattr_list_userns_rewrite() was doing. But looks like this logic will not
>>> kick in for the case of size==0 due to "!list" condition.
>>>
>>> Also we could probably replace "!list" with "!size" wheverever required.
>>> Its little easy to read and understand.
>>>
>>> For the other case where some xattrs can get filtered out and we report
>>> a buffer size bigger than actually needed, I am hoping that its acceptable
>>> and none of the existing users are broken.
>>>
>>> Thanks
>>> Vivek
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 13:21 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 13:21 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 6511 bytes --]
On 07/18/2017 08:30 AM, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>>> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>>>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>>>
>>>>> [..]
>>>>>> +/*
>>>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>>>> + * or determine needed size for attribute list
>>>>>> + * in case size == 0
>>>>>> + *
>>>>>> + * In a user namespace we do not present all extended attributes to the
>>>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>>>> + * for that uid in the current user namespace.
>>>>>> + *
>>>>>> + * @list: list of 0-byte separated xattr names
>>>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>>>> + * @list_maxlen: allocated buffer size of list
>>>>>> + */
>>>>>> +static ssize_t
>>>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>>>> +{
>>>>>> + char *nlist = NULL;
>>>>>> + size_t s_off, len, nlen;
>>>>>> + ssize_t d_off;
>>>>>> + char *name, *newname;
>>>>>> +
>>>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>>>> size will never be less than 0 here. Only caller calls this function only
>>>>> if size is >0. So can we remove this?
>>>> Correct.
>>>>
>>>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>>>> 0), we want to return the size of buffer as if all the xattrs will be
>>>>> returned to user space. But in practice we probably will filter out some
>>>>> xattrs so actually returned string will be smaller than size reported
>>>>> previously.
>>>> This case of size=0 is a problem in userns. Depending on the mapping of the
>>>> userid's the list can expand. A security.foo(a)uid=100 can become
>>>> security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
>>>> host becomes uid 100000 inside the container. So for now we only have
>>>> security.capability and the way I solved this is by allocating a 65k buffer
>>>> when calling from a userns. In this buffer where we gather the xattr names
>>>> and then walk them to determine the size that's needed for the buffer by
>>>> simulating the rewriting. It's not nice but I don't know of any other
>>>> solution.
>>> Hi Stefan,
>>>
>>> For the case of size==0, why don't we iterate through all the xattr,
>>> filter them, remap them and then return the size to process in user
>>> namespace. That should fix this? I thought that's what
>>
>> For the size==0 we need a temp. buffer where the raw xattr names are written
>> to so that the xattr_list_userns_rewrite() can actually rewrite what the
>> filesystem drivers returned.
> I am probably missing something, but for the case of size==0, we don't
> have to copy all xattrs. We just need to determine size. So we can walk
> through each xattr, remap it and add to the size. I mean there should not
> be a need to allocate this 65K buffer. Just enough space needed to be
> able to store remapped xattr.
>
> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> buffer containing remapped xattr. So we should be able to just determine
> the size and free the buffer. And do it for all the xattrs returned by
> filesystem.
>
> What am I missing?
The problem is that each filesystem has a function that collects the
xattr names. These functions only return the needed size if size==0 and
don't write anything into a buffer. If the buffer is empty or there is
no buffer, I have nothing to remap and calculate size for. So I pass a
buffer large enough to hold the xattr names to the filesystem functions
so I can then subsequently walk the xattrs and remap them. The remapping
only needs to be done in non-init_user_ns since there the uid parts
(@uid=1000) may need to be rewritten and most importantly, the size of
the needed buffer can increase, depending on how the uid mappings are.
I don't want to extend every filesystem's xattr name gathering function...
Stefan
>
> Vivek
>
>> Not knowing exactly how big that buffer should
>> be, I allocate 65k for it. From what I read there is a 64k limit on the vfs
>> layer for xattrs, probably including xattr values. So 65k would for sure be
>> enough also if each one of the xattr names becomes bigger.
>>
>> @@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
>> size_t size, bool rewrite)
>> {
>> struct inode *inode = d_inode(dentry);
>> ssize_t error;
>> + bool getsize = false;
>>
>> error = security_inode_listxattr(dentry);
>> if (error)
>> return error;
>> +
>> + if (!size) {
>> + if (current_user_ns() != &init_user_ns) {
>> + size = 65 * 1024;
>> + list = kmalloc(size, GFP_KERNEL);
>> + }
>> + getsize = true;
>> + }
>> +
>> if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
>> error = -EOPNOTSUPP;
>> error = inode->i_op->listxattr(dentry, list, size);
>> @@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t
>> size, bool rewrite)
>> if (error > 0 && rewrite)
>> error = xattr_list_userns_rewrite(list, error, size);
>>
>> + if (getsize)
>> + kfree(list);
>> +
>> return error;
>> }
>> EXPORT_SYMBOL_GPL(vfs_listxattr);
>>
>>
>> Stefan
>>
>>> xattr_list_userns_rewrite() was doing. But looks like this logic will not
>>> kick in for the case of size==0 due to "!list" condition.
>>>
>>> Also we could probably replace "!list" with "!size" wheverever required.
>>> Its little easy to read and understand.
>>>
>>> For the other case where some xattrs can get filtered out and we report
>>> a buffer size bigger than actually needed, I am hoping that its acceptable
>>> and none of the existing users are broken.
>>>
>>> Thanks
>>> Vivek
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>>> the body of a message to majordomo(a)vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 13:21 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 13:21 UTC (permalink / raw)
To: linux-security-module
On 07/18/2017 08:30 AM, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>>> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>>>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>>>
>>>>> [..]
>>>>>> +/*
>>>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>>>> + * or determine needed size for attribute list
>>>>>> + * in case size == 0
>>>>>> + *
>>>>>> + * In a user namespace we do not present all extended attributes to the
>>>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>>>> + * for that uid in the current user namespace.
>>>>>> + *
>>>>>> + * @list: list of 0-byte separated xattr names
>>>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>>>> + * @list_maxlen: allocated buffer size of list
>>>>>> + */
>>>>>> +static ssize_t
>>>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>>>> +{
>>>>>> + char *nlist = NULL;
>>>>>> + size_t s_off, len, nlen;
>>>>>> + ssize_t d_off;
>>>>>> + char *name, *newname;
>>>>>> +
>>>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>>>> size will never be less than 0 here. Only caller calls this function only
>>>>> if size is >0. So can we remove this?
>>>> Correct.
>>>>
>>>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>>>> 0), we want to return the size of buffer as if all the xattrs will be
>>>>> returned to user space. But in practice we probably will filter out some
>>>>> xattrs so actually returned string will be smaller than size reported
>>>>> previously.
>>>> This case of size=0 is a problem in userns. Depending on the mapping of the
>>>> userid's the list can expand. A security.foo at uid=100 can become
>>>> security.foo at uid=100000, if the mapping is set up so that uid 100 on the
>>>> host becomes uid 100000 inside the container. So for now we only have
>>>> security.capability and the way I solved this is by allocating a 65k buffer
>>>> when calling from a userns. In this buffer where we gather the xattr names
>>>> and then walk them to determine the size that's needed for the buffer by
>>>> simulating the rewriting. It's not nice but I don't know of any other
>>>> solution.
>>> Hi Stefan,
>>>
>>> For the case of size==0, why don't we iterate through all the xattr,
>>> filter them, remap them and then return the size to process in user
>>> namespace. That should fix this? I thought that's what
>>
>> For the size==0 we need a temp. buffer where the raw xattr names are written
>> to so that the xattr_list_userns_rewrite() can actually rewrite what the
>> filesystem drivers returned.
> I am probably missing something, but for the case of size==0, we don't
> have to copy all xattrs. We just need to determine size. So we can walk
> through each xattr, remap it and add to the size. I mean there should not
> be a need to allocate this 65K buffer. Just enough space needed to be
> able to store remapped xattr.
>
> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> buffer containing remapped xattr. So we should be able to just determine
> the size and free the buffer. And do it for all the xattrs returned by
> filesystem.
>
> What am I missing?
The problem is that each filesystem has a function that collects the
xattr names. These functions only return the needed size if size==0 and
don't write anything into a buffer. If the buffer is empty or there is
no buffer, I have nothing to remap and calculate size for. So I pass a
buffer large enough to hold the xattr names to the filesystem functions
so I can then subsequently walk the xattrs and remap them. The remapping
only needs to be done in non-init_user_ns since there the uid parts
(@uid=1000) may need to be rewritten and most importantly, the size of
the needed buffer can increase, depending on how the uid mappings are.
I don't want to extend every filesystem's xattr name gathering function...
Stefan
>
> Vivek
>
>> Not knowing exactly how big that buffer should
>> be, I allocate 65k for it. From what I read there is a 64k limit on the vfs
>> layer for xattrs, probably including xattr values. So 65k would for sure be
>> enough also if each one of the xattr names becomes bigger.
>>
>> @@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
>> size_t size, bool rewrite)
>> {
>> struct inode *inode = d_inode(dentry);
>> ssize_t error;
>> + bool getsize = false;
>>
>> error = security_inode_listxattr(dentry);
>> if (error)
>> return error;
>> +
>> + if (!size) {
>> + if (current_user_ns() != &init_user_ns) {
>> + size = 65 * 1024;
>> + list = kmalloc(size, GFP_KERNEL);
>> + }
>> + getsize = true;
>> + }
>> +
>> if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
>> error = -EOPNOTSUPP;
>> error = inode->i_op->listxattr(dentry, list, size);
>> @@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t
>> size, bool rewrite)
>> if (error > 0 && rewrite)
>> error = xattr_list_userns_rewrite(list, error, size);
>>
>> + if (getsize)
>> + kfree(list);
>> +
>> return error;
>> }
>> EXPORT_SYMBOL_GPL(vfs_listxattr);
>>
>>
>> Stefan
>>
>>> xattr_list_userns_rewrite() was doing. But looks like this logic will not
>>> kick in for the case of size==0 due to "!list" condition.
>>>
>>> Also we could probably replace "!list" with "!size" wheverever required.
>>> Its little easy to read and understand.
>>>
>>> For the other case where some xattrs can get filtered out and we report
>>> a buffer size bigger than actually needed, I am hoping that its acceptable
>>> and none of the existing users are broken.
>>>
>>> Thanks
>>> Vivek
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <cc515ca0-c5fa-412f-3f57-a41178b060a9-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <cc515ca0-c5fa-412f-3f57-a41178b060a9-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-18 14:57 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 14:57 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote:
> On 07/18/2017 08:30 AM, Vivek Goyal wrote:
> > On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> > > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > > > >
> > > > > > [..]
> > > > > > > +/*
> > > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > > > + * or determine needed size for attribute list
> > > > > > > + * in case size == 0
> > > > > > > + *
> > > > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > > > + * for that uid in the current user namespace.
> > > > > > > + *
> > > > > > > + * @list: list of 0-byte separated xattr names
> > > > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > > > + * @list_maxlen: allocated buffer size of list
> > > > > > > + */
> > > > > > > +static ssize_t
> > > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > > > +{
> > > > > > > + char *nlist = NULL;
> > > > > > > + size_t s_off, len, nlen;
> > > > > > > + ssize_t d_off;
> > > > > > > + char *name, *newname;
> > > > > > > +
> > > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > > > size will never be less than 0 here. Only caller calls this function only
> > > > > > if size is >0. So can we remove this?
> > > > > Correct.
> > > > >
> > > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > > > returned to user space. But in practice we probably will filter out some
> > > > > > xattrs so actually returned string will be smaller than size reported
> > > > > > previously.
> > > > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > > > userid's the list can expand. A security.foo@uid=100 can become
> > > > > security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> > > > > host becomes uid 100000 inside the container. So for now we only have
> > > > > security.capability and the way I solved this is by allocating a 65k buffer
> > > > > when calling from a userns. In this buffer where we gather the xattr names
> > > > > and then walk them to determine the size that's needed for the buffer by
> > > > > simulating the rewriting. It's not nice but I don't know of any other
> > > > > solution.
> > > > Hi Stefan,
> > > >
> > > > For the case of size==0, why don't we iterate through all the xattr,
> > > > filter them, remap them and then return the size to process in user
> > > > namespace. That should fix this? I thought that's what
> > >
> > > For the size==0 we need a temp. buffer where the raw xattr names are written
> > > to so that the xattr_list_userns_rewrite() can actually rewrite what the
> > > filesystem drivers returned.
> > I am probably missing something, but for the case of size==0, we don't
> > have to copy all xattrs. We just need to determine size. So we can walk
> > through each xattr, remap it and add to the size. I mean there should not
> > be a need to allocate this 65K buffer. Just enough space needed to be
> > able to store remapped xattr.
> >
> > You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> > buffer containing remapped xattr. So we should be able to just determine
> > the size and free the buffer. And do it for all the xattrs returned by
> > filesystem.
> >
> > What am I missing?
>
> The problem is that each filesystem has a function that collects the xattr
> names. These functions only return the needed size if size==0 and don't
> write anything into a buffer. If the buffer is empty or there is no buffer,
> I have nothing to remap and calculate size for.
How about calling listxattr() twice. In the first call you will get the
size of buffer to allocate. Allocate that buffer and call ->listxattr()
again, this time passing that buffer? That way you will not have to
hardcode the size of buffer.
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 13:21 ` Stefan Berger
(?)
@ 2017-07-18 14:57 ` Vivek Goyal
-1 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 14:57 UTC (permalink / raw)
To: Stefan Berger
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote:
> On 07/18/2017 08:30 AM, Vivek Goyal wrote:
> > On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> > > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > > > >
> > > > > > [..]
> > > > > > > +/*
> > > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > > > + * or determine needed size for attribute list
> > > > > > > + * in case size == 0
> > > > > > > + *
> > > > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > > > + * for that uid in the current user namespace.
> > > > > > > + *
> > > > > > > + * @list: list of 0-byte separated xattr names
> > > > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > > > + * @list_maxlen: allocated buffer size of list
> > > > > > > + */
> > > > > > > +static ssize_t
> > > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > > > +{
> > > > > > > + char *nlist = NULL;
> > > > > > > + size_t s_off, len, nlen;
> > > > > > > + ssize_t d_off;
> > > > > > > + char *name, *newname;
> > > > > > > +
> > > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > > > size will never be less than 0 here. Only caller calls this function only
> > > > > > if size is >0. So can we remove this?
> > > > > Correct.
> > > > >
> > > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > > > returned to user space. But in practice we probably will filter out some
> > > > > > xattrs so actually returned string will be smaller than size reported
> > > > > > previously.
> > > > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > > > userid's the list can expand. A security.foo@uid=100 can become
> > > > > security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> > > > > host becomes uid 100000 inside the container. So for now we only have
> > > > > security.capability and the way I solved this is by allocating a 65k buffer
> > > > > when calling from a userns. In this buffer where we gather the xattr names
> > > > > and then walk them to determine the size that's needed for the buffer by
> > > > > simulating the rewriting. It's not nice but I don't know of any other
> > > > > solution.
> > > > Hi Stefan,
> > > >
> > > > For the case of size==0, why don't we iterate through all the xattr,
> > > > filter them, remap them and then return the size to process in user
> > > > namespace. That should fix this? I thought that's what
> > >
> > > For the size==0 we need a temp. buffer where the raw xattr names are written
> > > to so that the xattr_list_userns_rewrite() can actually rewrite what the
> > > filesystem drivers returned.
> > I am probably missing something, but for the case of size==0, we don't
> > have to copy all xattrs. We just need to determine size. So we can walk
> > through each xattr, remap it and add to the size. I mean there should not
> > be a need to allocate this 65K buffer. Just enough space needed to be
> > able to store remapped xattr.
> >
> > You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> > buffer containing remapped xattr. So we should be able to just determine
> > the size and free the buffer. And do it for all the xattrs returned by
> > filesystem.
> >
> > What am I missing?
>
> The problem is that each filesystem has a function that collects the xattr
> names. These functions only return the needed size if size==0 and don't
> write anything into a buffer. If the buffer is empty or there is no buffer,
> I have nothing to remap and calculate size for.
How about calling listxattr() twice. In the first call you will get the
size of buffer to allocate. Allocate that buffer and call ->listxattr()
again, this time passing that buffer? That way you will not have to
hardcode the size of buffer.
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 14:57 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 14:57 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4585 bytes --]
On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote:
> On 07/18/2017 08:30 AM, Vivek Goyal wrote:
> > On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> > > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > > > >
> > > > > > [..]
> > > > > > > +/*
> > > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > > > + * or determine needed size for attribute list
> > > > > > > + * in case size == 0
> > > > > > > + *
> > > > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > > > + * for that uid in the current user namespace.
> > > > > > > + *
> > > > > > > + * @list: list of 0-byte separated xattr names
> > > > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > > > + * @list_maxlen: allocated buffer size of list
> > > > > > > + */
> > > > > > > +static ssize_t
> > > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > > > +{
> > > > > > > + char *nlist = NULL;
> > > > > > > + size_t s_off, len, nlen;
> > > > > > > + ssize_t d_off;
> > > > > > > + char *name, *newname;
> > > > > > > +
> > > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > > > size will never be less than 0 here. Only caller calls this function only
> > > > > > if size is >0. So can we remove this?
> > > > > Correct.
> > > > >
> > > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > > > returned to user space. But in practice we probably will filter out some
> > > > > > xattrs so actually returned string will be smaller than size reported
> > > > > > previously.
> > > > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > > > userid's the list can expand. A security.foo(a)uid=100 can become
> > > > > security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
> > > > > host becomes uid 100000 inside the container. So for now we only have
> > > > > security.capability and the way I solved this is by allocating a 65k buffer
> > > > > when calling from a userns. In this buffer where we gather the xattr names
> > > > > and then walk them to determine the size that's needed for the buffer by
> > > > > simulating the rewriting. It's not nice but I don't know of any other
> > > > > solution.
> > > > Hi Stefan,
> > > >
> > > > For the case of size==0, why don't we iterate through all the xattr,
> > > > filter them, remap them and then return the size to process in user
> > > > namespace. That should fix this? I thought that's what
> > >
> > > For the size==0 we need a temp. buffer where the raw xattr names are written
> > > to so that the xattr_list_userns_rewrite() can actually rewrite what the
> > > filesystem drivers returned.
> > I am probably missing something, but for the case of size==0, we don't
> > have to copy all xattrs. We just need to determine size. So we can walk
> > through each xattr, remap it and add to the size. I mean there should not
> > be a need to allocate this 65K buffer. Just enough space needed to be
> > able to store remapped xattr.
> >
> > You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> > buffer containing remapped xattr. So we should be able to just determine
> > the size and free the buffer. And do it for all the xattrs returned by
> > filesystem.
> >
> > What am I missing?
>
> The problem is that each filesystem has a function that collects the xattr
> names. These functions only return the needed size if size==0 and don't
> write anything into a buffer. If the buffer is empty or there is no buffer,
> I have nothing to remap and calculate size for.
How about calling listxattr() twice. In the first call you will get the
size of buffer to allocate. Allocate that buffer and call ->listxattr()
again, this time passing that buffer? That way you will not have to
hardcode the size of buffer.
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 14:57 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 14:57 UTC (permalink / raw)
To: linux-security-module
On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote:
> On 07/18/2017 08:30 AM, Vivek Goyal wrote:
> > On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> > > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > > > >
> > > > > > [..]
> > > > > > > +/*
> > > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > > > + * or determine needed size for attribute list
> > > > > > > + * in case size == 0
> > > > > > > + *
> > > > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > > > + * for that uid in the current user namespace.
> > > > > > > + *
> > > > > > > + * @list: list of 0-byte separated xattr names
> > > > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > > > + * @list_maxlen: allocated buffer size of list
> > > > > > > + */
> > > > > > > +static ssize_t
> > > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > > > +{
> > > > > > > + char *nlist = NULL;
> > > > > > > + size_t s_off, len, nlen;
> > > > > > > + ssize_t d_off;
> > > > > > > + char *name, *newname;
> > > > > > > +
> > > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > > > size will never be less than 0 here. Only caller calls this function only
> > > > > > if size is >0. So can we remove this?
> > > > > Correct.
> > > > >
> > > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > > > returned to user space. But in practice we probably will filter out some
> > > > > > xattrs so actually returned string will be smaller than size reported
> > > > > > previously.
> > > > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > > > userid's the list can expand. A security.foo at uid=100 can become
> > > > > security.foo at uid=100000, if the mapping is set up so that uid 100 on the
> > > > > host becomes uid 100000 inside the container. So for now we only have
> > > > > security.capability and the way I solved this is by allocating a 65k buffer
> > > > > when calling from a userns. In this buffer where we gather the xattr names
> > > > > and then walk them to determine the size that's needed for the buffer by
> > > > > simulating the rewriting. It's not nice but I don't know of any other
> > > > > solution.
> > > > Hi Stefan,
> > > >
> > > > For the case of size==0, why don't we iterate through all the xattr,
> > > > filter them, remap them and then return the size to process in user
> > > > namespace. That should fix this? I thought that's what
> > >
> > > For the size==0 we need a temp. buffer where the raw xattr names are written
> > > to so that the xattr_list_userns_rewrite() can actually rewrite what the
> > > filesystem drivers returned.
> > I am probably missing something, but for the case of size==0, we don't
> > have to copy all xattrs. We just need to determine size. So we can walk
> > through each xattr, remap it and add to the size. I mean there should not
> > be a need to allocate this 65K buffer. Just enough space needed to be
> > able to store remapped xattr.
> >
> > You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> > buffer containing remapped xattr. So we should be able to just determine
> > the size and free the buffer. And do it for all the xattrs returned by
> > filesystem.
> >
> > What am I missing?
>
> The problem is that each filesystem has a function that collects the xattr
> names. These functions only return the needed size if size==0 and don't
> write anything into a buffer. If the buffer is empty or there is no buffer,
> I have nothing to remap and calculate size for.
How about calling listxattr() twice. In the first call you will get the
size of buffer to allocate. Allocate that buffer and call ->listxattr()
again, this time passing that buffer? That way you will not have to
hardcode the size of buffer.
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread[parent not found: <20170718145716.GA25494-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170718145716.GA25494-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-18 16:11 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 16:11 UTC (permalink / raw)
To: Vivek Goyal
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/18/2017 10:57 AM, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote:
>> On 07/18/2017 08:30 AM, Vivek Goyal wrote:
>>> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>>>> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>>>>> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>>>>>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>>>>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>>>>>
>>>>>>> [..]
>>>>>>>> +/*
>>>>>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>>>>>> + * or determine needed size for attribute list
>>>>>>>> + * in case size == 0
>>>>>>>> + *
>>>>>>>> + * In a user namespace we do not present all extended attributes to the
>>>>>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>>>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>>>>>> + * for that uid in the current user namespace.
>>>>>>>> + *
>>>>>>>> + * @list: list of 0-byte separated xattr names
>>>>>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>>>>>> + * @list_maxlen: allocated buffer size of list
>>>>>>>> + */
>>>>>>>> +static ssize_t
>>>>>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>>>>>> +{
>>>>>>>> + char *nlist = NULL;
>>>>>>>> + size_t s_off, len, nlen;
>>>>>>>> + ssize_t d_off;
>>>>>>>> + char *name, *newname;
>>>>>>>> +
>>>>>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>>>>>> size will never be less than 0 here. Only caller calls this function only
>>>>>>> if size is >0. So can we remove this?
>>>>>> Correct.
>>>>>>
>>>>>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>>>>>> 0), we want to return the size of buffer as if all the xattrs will be
>>>>>>> returned to user space. But in practice we probably will filter out some
>>>>>>> xattrs so actually returned string will be smaller than size reported
>>>>>>> previously.
>>>>>> This case of size=0 is a problem in userns. Depending on the mapping of the
>>>>>> userid's the list can expand. A security.foo@uid=100 can become
>>>>>> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
>>>>>> host becomes uid 100000 inside the container. So for now we only have
>>>>>> security.capability and the way I solved this is by allocating a 65k buffer
>>>>>> when calling from a userns. In this buffer where we gather the xattr names
>>>>>> and then walk them to determine the size that's needed for the buffer by
>>>>>> simulating the rewriting. It's not nice but I don't know of any other
>>>>>> solution.
>>>>> Hi Stefan,
>>>>>
>>>>> For the case of size==0, why don't we iterate through all the xattr,
>>>>> filter them, remap them and then return the size to process in user
>>>>> namespace. That should fix this? I thought that's what
>>>> For the size==0 we need a temp. buffer where the raw xattr names are written
>>>> to so that the xattr_list_userns_rewrite() can actually rewrite what the
>>>> filesystem drivers returned.
>>> I am probably missing something, but for the case of size==0, we don't
>>> have to copy all xattrs. We just need to determine size. So we can walk
>>> through each xattr, remap it and add to the size. I mean there should not
>>> be a need to allocate this 65K buffer. Just enough space needed to be
>>> able to store remapped xattr.
>>>
>>> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
>>> buffer containing remapped xattr. So we should be able to just determine
>>> the size and free the buffer. And do it for all the xattrs returned by
>>> filesystem.
>>>
>>> What am I missing?
>> The problem is that each filesystem has a function that collects the xattr
>> names. These functions only return the needed size if size==0 and don't
>> write anything into a buffer. If the buffer is empty or there is no buffer,
>> I have nothing to remap and calculate size for.
> How about calling listxattr() twice. In the first call you will get the
> size of buffer to allocate. Allocate that buffer and call ->listxattr()
> again, this time passing that buffer? That way you will not have to
> hardcode the size of buffer.
Good idea. I modified the code to do this now. Thanks.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-18 14:57 ` Vivek Goyal
(?)
@ 2017-07-18 16:11 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 16:11 UTC (permalink / raw)
To: Vivek Goyal
Cc: ebiederm, containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, christian.brauner, amir73il,
linux-security-module, casey
On 07/18/2017 10:57 AM, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote:
>> On 07/18/2017 08:30 AM, Vivek Goyal wrote:
>>> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>>>> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>>>>> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>>>>>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>>>>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>>>>>
>>>>>>> [..]
>>>>>>>> +/*
>>>>>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>>>>>> + * or determine needed size for attribute list
>>>>>>>> + * in case size == 0
>>>>>>>> + *
>>>>>>>> + * In a user namespace we do not present all extended attributes to the
>>>>>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>>>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>>>>>> + * for that uid in the current user namespace.
>>>>>>>> + *
>>>>>>>> + * @list: list of 0-byte separated xattr names
>>>>>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>>>>>> + * @list_maxlen: allocated buffer size of list
>>>>>>>> + */
>>>>>>>> +static ssize_t
>>>>>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>>>>>> +{
>>>>>>>> + char *nlist = NULL;
>>>>>>>> + size_t s_off, len, nlen;
>>>>>>>> + ssize_t d_off;
>>>>>>>> + char *name, *newname;
>>>>>>>> +
>>>>>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>>>>>> size will never be less than 0 here. Only caller calls this function only
>>>>>>> if size is >0. So can we remove this?
>>>>>> Correct.
>>>>>>
>>>>>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>>>>>> 0), we want to return the size of buffer as if all the xattrs will be
>>>>>>> returned to user space. But in practice we probably will filter out some
>>>>>>> xattrs so actually returned string will be smaller than size reported
>>>>>>> previously.
>>>>>> This case of size=0 is a problem in userns. Depending on the mapping of the
>>>>>> userid's the list can expand. A security.foo@uid=100 can become
>>>>>> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
>>>>>> host becomes uid 100000 inside the container. So for now we only have
>>>>>> security.capability and the way I solved this is by allocating a 65k buffer
>>>>>> when calling from a userns. In this buffer where we gather the xattr names
>>>>>> and then walk them to determine the size that's needed for the buffer by
>>>>>> simulating the rewriting. It's not nice but I don't know of any other
>>>>>> solution.
>>>>> Hi Stefan,
>>>>>
>>>>> For the case of size==0, why don't we iterate through all the xattr,
>>>>> filter them, remap them and then return the size to process in user
>>>>> namespace. That should fix this? I thought that's what
>>>> For the size==0 we need a temp. buffer where the raw xattr names are written
>>>> to so that the xattr_list_userns_rewrite() can actually rewrite what the
>>>> filesystem drivers returned.
>>> I am probably missing something, but for the case of size==0, we don't
>>> have to copy all xattrs. We just need to determine size. So we can walk
>>> through each xattr, remap it and add to the size. I mean there should not
>>> be a need to allocate this 65K buffer. Just enough space needed to be
>>> able to store remapped xattr.
>>>
>>> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
>>> buffer containing remapped xattr. So we should be able to just determine
>>> the size and free the buffer. And do it for all the xattrs returned by
>>> filesystem.
>>>
>>> What am I missing?
>> The problem is that each filesystem has a function that collects the xattr
>> names. These functions only return the needed size if size==0 and don't
>> write anything into a buffer. If the buffer is empty or there is no buffer,
>> I have nothing to remap and calculate size for.
> How about calling listxattr() twice. In the first call you will get the
> size of buffer to allocate. Allocate that buffer and call ->listxattr()
> again, this time passing that buffer? That way you will not have to
> hardcode the size of buffer.
Good idea. I modified the code to do this now. Thanks.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 16:11 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 16:11 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 4483 bytes --]
On 07/18/2017 10:57 AM, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote:
>> On 07/18/2017 08:30 AM, Vivek Goyal wrote:
>>> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>>>> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>>>>> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>>>>>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>>>>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>>>>>
>>>>>>> [..]
>>>>>>>> +/*
>>>>>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>>>>>> + * or determine needed size for attribute list
>>>>>>>> + * in case size == 0
>>>>>>>> + *
>>>>>>>> + * In a user namespace we do not present all extended attributes to the
>>>>>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>>>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>>>>>> + * for that uid in the current user namespace.
>>>>>>>> + *
>>>>>>>> + * @list: list of 0-byte separated xattr names
>>>>>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>>>>>> + * @list_maxlen: allocated buffer size of list
>>>>>>>> + */
>>>>>>>> +static ssize_t
>>>>>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>>>>>> +{
>>>>>>>> + char *nlist = NULL;
>>>>>>>> + size_t s_off, len, nlen;
>>>>>>>> + ssize_t d_off;
>>>>>>>> + char *name, *newname;
>>>>>>>> +
>>>>>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>>>>>> size will never be less than 0 here. Only caller calls this function only
>>>>>>> if size is >0. So can we remove this?
>>>>>> Correct.
>>>>>>
>>>>>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>>>>>> 0), we want to return the size of buffer as if all the xattrs will be
>>>>>>> returned to user space. But in practice we probably will filter out some
>>>>>>> xattrs so actually returned string will be smaller than size reported
>>>>>>> previously.
>>>>>> This case of size=0 is a problem in userns. Depending on the mapping of the
>>>>>> userid's the list can expand. A security.foo(a)uid=100 can become
>>>>>> security.foo(a)uid=100000, if the mapping is set up so that uid 100 on the
>>>>>> host becomes uid 100000 inside the container. So for now we only have
>>>>>> security.capability and the way I solved this is by allocating a 65k buffer
>>>>>> when calling from a userns. In this buffer where we gather the xattr names
>>>>>> and then walk them to determine the size that's needed for the buffer by
>>>>>> simulating the rewriting. It's not nice but I don't know of any other
>>>>>> solution.
>>>>> Hi Stefan,
>>>>>
>>>>> For the case of size==0, why don't we iterate through all the xattr,
>>>>> filter them, remap them and then return the size to process in user
>>>>> namespace. That should fix this? I thought that's what
>>>> For the size==0 we need a temp. buffer where the raw xattr names are written
>>>> to so that the xattr_list_userns_rewrite() can actually rewrite what the
>>>> filesystem drivers returned.
>>> I am probably missing something, but for the case of size==0, we don't
>>> have to copy all xattrs. We just need to determine size. So we can walk
>>> through each xattr, remap it and add to the size. I mean there should not
>>> be a need to allocate this 65K buffer. Just enough space needed to be
>>> able to store remapped xattr.
>>>
>>> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
>>> buffer containing remapped xattr. So we should be able to just determine
>>> the size and free the buffer. And do it for all the xattrs returned by
>>> filesystem.
>>>
>>> What am I missing?
>> The problem is that each filesystem has a function that collects the xattr
>> names. These functions only return the needed size if size==0 and don't
>> write anything into a buffer. If the buffer is empty or there is no buffer,
>> I have nothing to remap and calculate size for.
> How about calling listxattr() twice. In the first call you will get the
> size of buffer to allocate. Allocate that buffer and call ->listxattr()
> again, this time passing that buffer? That way you will not have to
> hardcode the size of buffer.
Good idea. I modified the code to do this now. Thanks.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-18 16:11 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 16:11 UTC (permalink / raw)
To: linux-security-module
On 07/18/2017 10:57 AM, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote:
>> On 07/18/2017 08:30 AM, Vivek Goyal wrote:
>>> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>>>> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>>>>> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>>>>>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>>>>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>>>>>
>>>>>>> [..]
>>>>>>>> +/*
>>>>>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>>>>>> + * or determine needed size for attribute list
>>>>>>>> + * in case size == 0
>>>>>>>> + *
>>>>>>>> + * In a user namespace we do not present all extended attributes to the
>>>>>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>>>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>>>>>> + * for that uid in the current user namespace.
>>>>>>>> + *
>>>>>>>> + * @list: list of 0-byte separated xattr names
>>>>>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>>>>>> + * @list_maxlen: allocated buffer size of list
>>>>>>>> + */
>>>>>>>> +static ssize_t
>>>>>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>>>>>> +{
>>>>>>>> + char *nlist = NULL;
>>>>>>>> + size_t s_off, len, nlen;
>>>>>>>> + ssize_t d_off;
>>>>>>>> + char *name, *newname;
>>>>>>>> +
>>>>>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>>>>>> size will never be less than 0 here. Only caller calls this function only
>>>>>>> if size is >0. So can we remove this?
>>>>>> Correct.
>>>>>>
>>>>>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>>>>>> 0), we want to return the size of buffer as if all the xattrs will be
>>>>>>> returned to user space. But in practice we probably will filter out some
>>>>>>> xattrs so actually returned string will be smaller than size reported
>>>>>>> previously.
>>>>>> This case of size=0 is a problem in userns. Depending on the mapping of the
>>>>>> userid's the list can expand. A security.foo at uid=100 can become
>>>>>> security.foo at uid=100000, if the mapping is set up so that uid 100 on the
>>>>>> host becomes uid 100000 inside the container. So for now we only have
>>>>>> security.capability and the way I solved this is by allocating a 65k buffer
>>>>>> when calling from a userns. In this buffer where we gather the xattr names
>>>>>> and then walk them to determine the size that's needed for the buffer by
>>>>>> simulating the rewriting. It's not nice but I don't know of any other
>>>>>> solution.
>>>>> Hi Stefan,
>>>>>
>>>>> For the case of size==0, why don't we iterate through all the xattr,
>>>>> filter them, remap them and then return the size to process in user
>>>>> namespace. That should fix this? I thought that's what
>>>> For the size==0 we need a temp. buffer where the raw xattr names are written
>>>> to so that the xattr_list_userns_rewrite() can actually rewrite what the
>>>> filesystem drivers returned.
>>> I am probably missing something, but for the case of size==0, we don't
>>> have to copy all xattrs. We just need to determine size. So we can walk
>>> through each xattr, remap it and add to the size. I mean there should not
>>> be a need to allocate this 65K buffer. Just enough space needed to be
>>> able to store remapped xattr.
>>>
>>> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
>>> buffer containing remapped xattr. So we should be able to just determine
>>> the size and free the buffer. And do it for all the xattrs returned by
>>> filesystem.
>>>
>>> What am I missing?
>> The problem is that each filesystem has a function that collects the xattr
>> names. These functions only return the needed size if size==0 and don't
>> write anything into a buffer. If the buffer is empty or there is no buffer,
>> I have nothing to remap and calculate size for.
> How about calling listxattr() twice. In the first call you will get the
> size of buffer to allocate. Allocate that buffer and call ->listxattr()
> again, this time passing that buffer? That way you will not have to
> hardcode the size of buffer.
Good idea. I modified the code to do this now. Thanks.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170718123009.GB8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170718123009.GB8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-18 12:36 ` Vivek Goyal
2017-07-18 13:21 ` Stefan Berger
1 sibling, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 12:36 UTC (permalink / raw)
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk, Stefan Berger,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> > On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > > >
> > > > > [..]
> > > > > > +/*
> > > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > > + * or determine needed size for attribute list
> > > > > > + * in case size == 0
> > > > > > + *
> > > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > > + * for that uid in the current user namespace.
> > > > > > + *
> > > > > > + * @list: list of 0-byte separated xattr names
> > > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > > + * @list_maxlen: allocated buffer size of list
> > > > > > + */
> > > > > > +static ssize_t
> > > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > > +{
> > > > > > + char *nlist = NULL;
> > > > > > + size_t s_off, len, nlen;
> > > > > > + ssize_t d_off;
> > > > > > + char *name, *newname;
> > > > > > +
> > > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > > size will never be less than 0 here. Only caller calls this function only
> > > > > if size is >0. So can we remove this?
> > > > Correct.
> > > >
> > > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > > returned to user space. But in practice we probably will filter out some
> > > > > xattrs so actually returned string will be smaller than size reported
> > > > > previously.
> > > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > > userid's the list can expand. A security.foo@uid=100 can become
> > > > security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> > > > host becomes uid 100000 inside the container. So for now we only have
> > > > security.capability and the way I solved this is by allocating a 65k buffer
> > > > when calling from a userns. In this buffer where we gather the xattr names
> > > > and then walk them to determine the size that's needed for the buffer by
> > > > simulating the rewriting. It's not nice but I don't know of any other
> > > > solution.
> > > Hi Stefan,
> > >
> > > For the case of size==0, why don't we iterate through all the xattr,
> > > filter them, remap them and then return the size to process in user
> > > namespace. That should fix this? I thought that's what
> >
> >
> > For the size==0 we need a temp. buffer where the raw xattr names are written
> > to so that the xattr_list_userns_rewrite() can actually rewrite what the
> > filesystem drivers returned.
>
> I am probably missing something, but for the case of size==0, we don't
> have to copy all xattrs. We just need to determine size. So we can walk
> through each xattr, remap it and add to the size. I mean there should not
> be a need to allocate this 65K buffer. Just enough space needed to be
> able to store remapped xattr.
>
> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> buffer containing remapped xattr. So we should be able to just determine
> the size and free the buffer. And do it for all the xattrs returned by
> filesystem.
>
> What am I missing?
Oh, I think I get it. If I don't pass a buffer to underlying driver, then
it will just return the size (and not actual list). So that's why you are
allocating that big buffer and getting the whole list internally, doing
mapping and returning size to user space. Hmm...
Vivek
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170718123009.GB8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-18 12:36 ` Vivek Goyal
@ 2017-07-18 13:21 ` Stefan Berger
1 sibling, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 13:21 UTC (permalink / raw)
To: Vivek Goyal
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/18/2017 08:30 AM, Vivek Goyal wrote:
> On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
>> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
>>> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>>>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>>>
>>>>> [..]
>>>>>> +/*
>>>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>>>> + * or determine needed size for attribute list
>>>>>> + * in case size == 0
>>>>>> + *
>>>>>> + * In a user namespace we do not present all extended attributes to the
>>>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>>>> + * for that uid in the current user namespace.
>>>>>> + *
>>>>>> + * @list: list of 0-byte separated xattr names
>>>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>>>> + * @list_maxlen: allocated buffer size of list
>>>>>> + */
>>>>>> +static ssize_t
>>>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>>>> +{
>>>>>> + char *nlist = NULL;
>>>>>> + size_t s_off, len, nlen;
>>>>>> + ssize_t d_off;
>>>>>> + char *name, *newname;
>>>>>> +
>>>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>>>> size will never be less than 0 here. Only caller calls this function only
>>>>> if size is >0. So can we remove this?
>>>> Correct.
>>>>
>>>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>>>> 0), we want to return the size of buffer as if all the xattrs will be
>>>>> returned to user space. But in practice we probably will filter out some
>>>>> xattrs so actually returned string will be smaller than size reported
>>>>> previously.
>>>> This case of size=0 is a problem in userns. Depending on the mapping of the
>>>> userid's the list can expand. A security.foo@uid=100 can become
>>>> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
>>>> host becomes uid 100000 inside the container. So for now we only have
>>>> security.capability and the way I solved this is by allocating a 65k buffer
>>>> when calling from a userns. In this buffer where we gather the xattr names
>>>> and then walk them to determine the size that's needed for the buffer by
>>>> simulating the rewriting. It's not nice but I don't know of any other
>>>> solution.
>>> Hi Stefan,
>>>
>>> For the case of size==0, why don't we iterate through all the xattr,
>>> filter them, remap them and then return the size to process in user
>>> namespace. That should fix this? I thought that's what
>>
>> For the size==0 we need a temp. buffer where the raw xattr names are written
>> to so that the xattr_list_userns_rewrite() can actually rewrite what the
>> filesystem drivers returned.
> I am probably missing something, but for the case of size==0, we don't
> have to copy all xattrs. We just need to determine size. So we can walk
> through each xattr, remap it and add to the size. I mean there should not
> be a need to allocate this 65K buffer. Just enough space needed to be
> able to store remapped xattr.
>
> You are already doing it in xattr_parse_uid_from_kuid(). It returns the
> buffer containing remapped xattr. So we should be able to just determine
> the size and free the buffer. And do it for all the xattrs returned by
> filesystem.
>
> What am I missing?
The problem is that each filesystem has a function that collects the
xattr names. These functions only return the needed size if size==0 and
don't write anything into a buffer. If the buffer is empty or there is
no buffer, I have nothing to remap and calculate size for. So I pass a
buffer large enough to hold the xattr names to the filesystem functions
so I can then subsequently walk the xattrs and remap them. The remapping
only needs to be done in non-init_user_ns since there the uid parts
(@uid=1000) may need to be rewritten and most importantly, the size of
the needed buffer can increase, depending on how the uid mappings are.
I don't want to extend every filesystem's xattr name gathering function...
Stefan
>
> Vivek
>
>> Not knowing exactly how big that buffer should
>> be, I allocate 65k for it. From what I read there is a 64k limit on the vfs
>> layer for xattrs, probably including xattr values. So 65k would for sure be
>> enough also if each one of the xattr names becomes bigger.
>>
>> @@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
>> size_t size, bool rewrite)
>> {
>> struct inode *inode = d_inode(dentry);
>> ssize_t error;
>> + bool getsize = false;
>>
>> error = security_inode_listxattr(dentry);
>> if (error)
>> return error;
>> +
>> + if (!size) {
>> + if (current_user_ns() != &init_user_ns) {
>> + size = 65 * 1024;
>> + list = kmalloc(size, GFP_KERNEL);
>> + }
>> + getsize = true;
>> + }
>> +
>> if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
>> error = -EOPNOTSUPP;
>> error = inode->i_op->listxattr(dentry, list, size);
>> @@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t
>> size, bool rewrite)
>> if (error > 0 && rewrite)
>> error = xattr_list_userns_rewrite(list, error, size);
>>
>> + if (getsize)
>> + kfree(list);
>> +
>> return error;
>> }
>> EXPORT_SYMBOL_GPL(vfs_listxattr);
>>
>>
>> Stefan
>>
>>> xattr_list_userns_rewrite() was doing. But looks like this logic will not
>>> kick in for the case of size==0 due to "!list" condition.
>>>
>>> Also we could probably replace "!list" with "!size" wheverever required.
>>> Its little easy to read and understand.
>>>
>>> For the other case where some xattrs can get filtered out and we report
>>> a buffer size bigger than actually needed, I am hoping that its acceptable
>>> and none of the existing users are broken.
>>>
>>> Thanks
>>> Vivek
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <55971eea-fde2-439a-2fe5-d0ae5e80bc22-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <55971eea-fde2-439a-2fe5-d0ae5e80bc22-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
@ 2017-07-18 12:30 ` Vivek Goyal
0 siblings, 0 replies; 288+ messages in thread
From: Vivek Goyal @ 2017-07-18 12:30 UTC (permalink / raw)
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk, Stefan Berger,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote:
> On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> > > On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > > >
> > > > [..]
> > > > > +/*
> > > > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > > > + * or determine needed size for attribute list
> > > > > + * in case size == 0
> > > > > + *
> > > > > + * In a user namespace we do not present all extended attributes to the
> > > > > + * user. We filter out those that are in the list of userns supported xattr.
> > > > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > > > + * for that uid in the current user namespace.
> > > > > + *
> > > > > + * @list: list of 0-byte separated xattr names
> > > > > + * @size: the size of the list; may be 0 to determine needed list size
> > > > > + * @list_maxlen: allocated buffer size of list
> > > > > + */
> > > > > +static ssize_t
> > > > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > > > +{
> > > > > + char *nlist = NULL;
> > > > > + size_t s_off, len, nlen;
> > > > > + ssize_t d_off;
> > > > > + char *name, *newname;
> > > > > +
> > > > > + if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > > > size will never be less than 0 here. Only caller calls this function only
> > > > if size is >0. So can we remove this?
> > > Correct.
> > >
> > > > What about case of "!list". So if user space called listxattr(foo, NULL,
> > > > 0), we want to return the size of buffer as if all the xattrs will be
> > > > returned to user space. But in practice we probably will filter out some
> > > > xattrs so actually returned string will be smaller than size reported
> > > > previously.
> > > This case of size=0 is a problem in userns. Depending on the mapping of the
> > > userid's the list can expand. A security.foo@uid=100 can become
> > > security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> > > host becomes uid 100000 inside the container. So for now we only have
> > > security.capability and the way I solved this is by allocating a 65k buffer
> > > when calling from a userns. In this buffer where we gather the xattr names
> > > and then walk them to determine the size that's needed for the buffer by
> > > simulating the rewriting. It's not nice but I don't know of any other
> > > solution.
> > Hi Stefan,
> >
> > For the case of size==0, why don't we iterate through all the xattr,
> > filter them, remap them and then return the size to process in user
> > namespace. That should fix this? I thought that's what
>
>
> For the size==0 we need a temp. buffer where the raw xattr names are written
> to so that the xattr_list_userns_rewrite() can actually rewrite what the
> filesystem drivers returned.
I am probably missing something, but for the case of size==0, we don't
have to copy all xattrs. We just need to determine size. So we can walk
through each xattr, remap it and add to the size. I mean there should not
be a need to allocate this 65K buffer. Just enough space needed to be
able to store remapped xattr.
You are already doing it in xattr_parse_uid_from_kuid(). It returns the
buffer containing remapped xattr. So we should be able to just determine
the size and free the buffer. And do it for all the xattrs returned by
filesystem.
What am I missing?
Vivek
> Not knowing exactly how big that buffer should
> be, I allocate 65k for it. From what I read there is a 64k limit on the vfs
> layer for xattrs, probably including xattr values. So 65k would for sure be
> enough also if each one of the xattr names becomes bigger.
>
> @@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
> size_t size, bool rewrite)
> {
> struct inode *inode = d_inode(dentry);
> ssize_t error;
> + bool getsize = false;
>
> error = security_inode_listxattr(dentry);
> if (error)
> return error;
> +
> + if (!size) {
> + if (current_user_ns() != &init_user_ns) {
> + size = 65 * 1024;
> + list = kmalloc(size, GFP_KERNEL);
> + }
> + getsize = true;
> + }
> +
> if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
> error = -EOPNOTSUPP;
> error = inode->i_op->listxattr(dentry, list, size);
> @@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t
> size, bool rewrite)
> if (error > 0 && rewrite)
> error = xattr_list_userns_rewrite(list, error, size);
>
> + if (getsize)
> + kfree(list);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_listxattr);
>
>
> Stefan
>
> > xattr_list_userns_rewrite() was doing. But looks like this logic will not
> > kick in for the case of size==0 due to "!list" condition.
> >
> > Also we could probably replace "!list" with "!size" wheverever required.
> > Its little easy to read and understand.
> >
> > For the other case where some xattrs can get filtered out and we report
> > a buffer size bigger than actually needed, I am hoping that its acceptable
> > and none of the existing users are broken.
> >
> > Thanks
> > Vivek
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <20170718114849.GA8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <20170718114849.GA8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2017-07-18 12:05 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-18 12:05 UTC (permalink / raw)
To: Vivek Goyal
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk, Stefan Berger,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/18/2017 07:48 AM, Vivek Goyal wrote:
> On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
>> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
>>> On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
>>>
>>> [..]
>>>> +/*
>>>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>>>> + * or determine needed size for attribute list
>>>> + * in case size == 0
>>>> + *
>>>> + * In a user namespace we do not present all extended attributes to the
>>>> + * user. We filter out those that are in the list of userns supported xattr.
>>>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>>>> + * for that uid in the current user namespace.
>>>> + *
>>>> + * @list: list of 0-byte separated xattr names
>>>> + * @size: the size of the list; may be 0 to determine needed list size
>>>> + * @list_maxlen: allocated buffer size of list
>>>> + */
>>>> +static ssize_t
>>>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>>>> +{
>>>> + char *nlist = NULL;
>>>> + size_t s_off, len, nlen;
>>>> + ssize_t d_off;
>>>> + char *name, *newname;
>>>> +
>>>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>>> size will never be less than 0 here. Only caller calls this function only
>>> if size is >0. So can we remove this?
>> Correct.
>>
>>> What about case of "!list". So if user space called listxattr(foo, NULL,
>>> 0), we want to return the size of buffer as if all the xattrs will be
>>> returned to user space. But in practice we probably will filter out some
>>> xattrs so actually returned string will be smaller than size reported
>>> previously.
>> This case of size=0 is a problem in userns. Depending on the mapping of the
>> userid's the list can expand. A security.foo@uid=100 can become
>> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
>> host becomes uid 100000 inside the container. So for now we only have
>> security.capability and the way I solved this is by allocating a 65k buffer
>> when calling from a userns. In this buffer where we gather the xattr names
>> and then walk them to determine the size that's needed for the buffer by
>> simulating the rewriting. It's not nice but I don't know of any other
>> solution.
> Hi Stefan,
>
> For the case of size==0, why don't we iterate through all the xattr,
> filter them, remap them and then return the size to process in user
> namespace. That should fix this? I thought that's what
For the size==0 we need a temp. buffer where the raw xattr names are
written to so that the xattr_list_userns_rewrite() can actually rewrite
what the filesystem drivers returned. Not knowing exactly how big that
buffer should be, I allocate 65k for it. From what I read there is a 64k
limit on the vfs layer for xattrs, probably including xattr values. So
65k would for sure be enough also if each one of the xattr names becomes
bigger.
@@ -922,10 +947,20 @@ vfs_listxattr(struct dentry *dentry, char *list,
size_t size, bool rewrite)
{
struct inode *inode = d_inode(dentry);
ssize_t error;
+ bool getsize = false;
error = security_inode_listxattr(dentry);
if (error)
return error;
+
+ if (!size) {
+ if (current_user_ns() != &init_user_ns) {
+ size = 65 * 1024;
+ list = kmalloc(size, GFP_KERNEL);
+ }
+ getsize = true;
+ }
+
if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
error = -EOPNOTSUPP;
error = inode->i_op->listxattr(dentry, list, size);
@@ -937,6 +972,9 @@ vfs_listxattr(struct dentry *dentry, char *list,
size_t size, bool rewrite)
if (error > 0 && rewrite)
error = xattr_list_userns_rewrite(list, error, size);
+ if (getsize)
+ kfree(list);
+
return error;
}
EXPORT_SYMBOL_GPL(vfs_listxattr);
Stefan
> xattr_list_userns_rewrite() was doing. But looks like this logic will not
> kick in for the case of size==0 due to "!list" condition.
>
> Also we could probably replace "!list" with "!size" wheverever required.
> Its little easy to read and understand.
>
> For the other case where some xattrs can get filtered out and we report
> a buffer size bigger than actually needed, I am hoping that its acceptable
> and none of the existing users are broken.
>
> Thanks
> Vivek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 288+ messages in thread
* [lkp-robot] [xattr] 3f3bf5920d: ltp.userns06.fail
2017-07-11 15:05 ` Stefan Berger
(?)
@ 2017-07-20 1:05 ` kernel test robot
-1 siblings, 0 replies; 288+ messages in thread
From: kernel test robot @ 2017-07-20 1:05 UTC (permalink / raw)
To: Stefan Berger
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
ltp-cunTk1MwBs91InPhgRC9rw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
FYI, we noticed the following commit:
commit: 3f3bf5920d2df8b0b3df8ec90e21e67316688e95 ("xattr: Enable security.capability in user namespaces")
url: https://github.com/0day-ci/linux/commits/Stefan-Berger/xattr-Enable-security-capability-in-user-namespaces/20170712-035657
in testcase: ltp
with following parameters:
test: containers
test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
test-url: http://linux-test-project.github.io/
on test machine: 8 threads Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz with 4G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
[ 60.440119] <<<test_start>>>
[ 60.440120]
[ 60.441256] tag=userns06 stime=1500298556
[ 60.441258]
[ 60.442244] cmdline="userns06"
[ 60.442246]
[ 60.442943] contacts=""
[ 60.442945]
[ 60.443774] analysis=exit
[ 60.443776]
[ 60.444626] <<<test_output>>>
[ 60.444628]
[ 60.446472] user_namespace6 0 TINFO : Child process returned TPASS
[ 60.446474]
[ 60.448555] user_namespace6 0 TINFO : Child process returned TFAIL
[ 60.448557]
[ 60.449643] <<<execution_status>>>
[ 60.449645]
[ 60.450596] initiation_status="ok"
[ 60.450598]
[ 60.452640] duration=0 termination_type=exited termination_id=1 corefile=no
[ 60.452641]
[ 60.453663] cutime=0 cstime=0
[ 60.453665]
[ 60.454431] <<<test_end>>>
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Xiaolong
[-- Attachment #2: config-4.12.0-10318-g3f3bf59 --]
[-- Type: text/plain, Size: 160355 bytes --]
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.12.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
# CONFIG_NO_HZ_FULL_ALL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_RCU_NOCB_CPU=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_BPF is not set
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_POSIX_TIMERS=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_BPF_SYSCALL=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_USERFAULTFD=y
CONFIG_PCI_QUIRKS=y
CONFIG_MEMBARRIER=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
# CONFIG_PC104 is not set
#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLUB_MEMCG_SYSFS_ON is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLAB_MERGE_DEFAULT=y
# CONFIG_SLAB_FREELIST_RANDOM is not set
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SYSTEM_DATA_VERIFICATION is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
# CONFIG_STATIC_KEYS_SELFTEST is not set
CONFIG_OPTPROBES=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_UPROBES=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_NMI=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_ARCH_HAS_SET_MEMORY=y
CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_GCC_PLUGINS=y
# CONFIG_GCC_PLUGINS is not set
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_THIN_ARCHIVES=y
CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_HAVE_ARCH_HUGE_VMAP=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
CONFIG_HAVE_EXIT_THREAD=y
CONFIG_ARCH_MMAP_RND_BITS=28
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES=y
CONFIG_HAVE_COPY_THREAD_TLS=y
CONFIG_HAVE_STACK_VALIDATION=y
# CONFIG_HAVE_ARCH_HASH is not set
# CONFIG_ISA_BUS_API is not set
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_COMPAT_OLD_SIGACTION=y
# CONFIG_CPU_NO_EFFICIENT_FFS is not set
CONFIG_HAVE_ARCH_VMAP_STACK=y
CONFIG_VMAP_STACK=y
# CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set
# CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set
CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
CONFIG_STRICT_MODULE_RWX=y
# CONFIG_REFCOUNT_FULL is not set
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
# CONFIG_MODULE_COMPRESS is not set
# CONFIG_TRIM_UNUSED_KSYMS is not set
CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_BLOCK=y
CONFIG_BLK_SCSI_REQUEST=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y
# CONFIG_BLK_DEV_ZONED is not set
CONFIG_BLK_DEV_THROTTLING=y
# CONFIG_BLK_DEV_THROTTLING_LOW is not set
# CONFIG_BLK_CMDLINE_PARSER is not set
# CONFIG_BLK_WBT is not set
CONFIG_BLK_DEBUG_FS=y
# CONFIG_BLK_SED_OPAL is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_BLOCK_COMPAT=y
CONFIG_BLK_MQ_PCI=y
CONFIG_BLK_MQ_VIRTIO=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_MQ_IOSCHED_DEADLINE=y
CONFIG_MQ_IOSCHED_KYBER=y
# CONFIG_IOSCHED_BFQ is not set
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PADATA=y
CONFIG_ASN1=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_LOCK_SPIN_ON_OWNER=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
CONFIG_QUEUED_SPINLOCKS=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
CONFIG_QUEUED_RWLOCKS=y
CONFIG_FREEZER=y
#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_FAST_FEATURE_TESTS=y
CONFIG_X86_X2APIC=y
CONFIG_X86_MPPARSE=y
# CONFIG_GOLDFISH is not set
CONFIG_INTEL_RDT_A=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_NUMACHIP is not set
# CONFIG_X86_VSMP is not set
CONFIG_X86_UV=y
# CONFIG_X86_GOLDFISH is not set
# CONFIG_X86_INTEL_MID is not set
CONFIG_X86_INTEL_LPSS=y
# CONFIG_X86_AMD_PLATFORM_DEVICE is not set
CONFIG_IOSF_MBI=y
# CONFIG_IOSF_MBI_DEBUG is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
CONFIG_HYPERVISOR_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_PARAVIRT_SPINLOCKS=y
# CONFIG_QUEUED_LOCK_STAT is not set
CONFIG_XEN=y
CONFIG_XEN_PV=y
CONFIG_XEN_PV_SMP=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_PVHVM_SMP=y
CONFIG_XEN_512GB=y
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_XEN_PVH is not set
CONFIG_KVM_GUEST=y
# CONFIG_KVM_DEBUG_FS is not set
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_NO_BOOTMEM=y
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
# CONFIG_PROCESSOR_SELECT is not set
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_MAXSMP=y
CONFIG_NR_CPUS=8192
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_SCHED_MC_PRIO=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCELOG_LEGACY=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=m
CONFIG_X86_THERMAL_VECTOR=y
#
# Performance monitoring
#
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_PERF_EVENTS_INTEL_RAPL=y
CONFIG_PERF_EVENTS_INTEL_CSTATE=y
# CONFIG_PERF_EVENTS_AMD_POWER is not set
# CONFIG_VM86 is not set
CONFIG_X86_16BIT=y
CONFIG_X86_ESPFIX64=y
CONFIG_X86_VSYSCALL_EMULATION=y
CONFIG_I8K=m
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_X86_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=10
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_MEMORY_PROBE=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_HAVE_GENERIC_GUP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
CONFIG_HAVE_BOOTMEM_INFO_NODE=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
# CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is not set
CONFIG_MEMORY_HOTREMOVE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
CONFIG_MEMORY_BALLOON=y
CONFIG_BALLOON_COMPACTION=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
CONFIG_HWPOISON_INJECT=m
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_ARCH_WANTS_THP_SWAP=y
CONFIG_THP_SWAP=y
CONFIG_TRANSPARENT_HUGE_PAGECACHE=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set
# CONFIG_CMA_DEBUGFS is not set
CONFIG_CMA_AREAS=7
# CONFIG_MEM_SOFT_DIRTY is not set
CONFIG_ZSWAP=y
CONFIG_ZPOOL=y
CONFIG_ZBUD=y
# CONFIG_Z3FOLD is not set
CONFIG_ZSMALLOC=y
# CONFIG_PGTABLE_MAPPING is not set
# CONFIG_ZSMALLOC_STAT is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT=y
# CONFIG_DEFERRED_STRUCT_PAGE_INIT is not set
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_ARCH_HAS_ZONE_DEVICE=y
CONFIG_ZONE_DEVICE=y
CONFIG_FRAME_VECTOR=y
CONFIG_ARCH_USES_HIGH_VMA_FLAGS=y
CONFIG_ARCH_HAS_PKEYS=y
# CONFIG_PERCPU_STATS is not set
CONFIG_X86_PMEM_LEGACY_DEVICE=y
CONFIG_X86_PMEM_LEGACY=m
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
# CONFIG_X86_INTEL_MPX is not set
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
# CONFIG_EFI_MIXED is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
# CONFIG_KEXEC_FILE is not set
CONFIG_CRASH_DUMP=y
CONFIG_KEXEC_JUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
# CONFIG_RANDOMIZE_BASE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
CONFIG_BOOTPARAM_HOTPLUG_CPU0=y
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
# CONFIG_LEGACY_VSYSCALL_NATIVE is not set
CONFIG_LEGACY_VSYSCALL_EMULATE=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_MODIFY_LDT_SYSCALL=y
CONFIG_HAVE_LIVEPATCH=y
# CONFIG_LIVEPATCH is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y
#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_SUSPEND_SKIP_SYNC is not set
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_PM_ADVANCED_DEBUG=y
CONFIG_PM_TEST_SUSPEND=y
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_DPM_WATCHDOG is not set
# CONFIG_PM_TRACE_RTC is not set
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
# CONFIG_ACPI_DEBUGGER is not set
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
CONFIG_ACPI_EC_DEBUGFS=m
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_CPU_FREQ_PSS=y
CONFIG_ACPI_PROCESSOR_CSTATE=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_ACPI_CPPC_LIB=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_IPMI=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_ACPI_HOTPLUG_IOAPIC=y
CONFIG_ACPI_SBS=m
CONFIG_ACPI_HED=y
CONFIG_ACPI_CUSTOM_METHOD=m
CONFIG_ACPI_BGRT=y
# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
CONFIG_ACPI_NFIT=m
CONFIG_HAVE_ACPI_APEI=y
CONFIG_HAVE_ACPI_APEI_NMI=y
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_ACPI_APEI_MEMORY_FAILURE=y
CONFIG_ACPI_APEI_EINJ=m
CONFIG_ACPI_APEI_ERST_DEBUG=y
# CONFIG_DPTF_POWER is not set
CONFIG_ACPI_EXTLOG=m
# CONFIG_PMIC_OPREGION is not set
# CONFIG_ACPI_CONFIGFS is not set
CONFIG_SFI=y
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
#
# CPU frequency scaling drivers
#
CONFIG_X86_INTEL_PSTATE=y
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ_CPB=y
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_AMD_FREQ_SENSITIVITY=m
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=m
#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
#
# CPU Idle
#
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_GOV_LADDER is not set
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
CONFIG_INTEL_IDLE=y
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
CONFIG_PCIEAER_INJECT=m
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_POWER_SUPERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_PCIE_PME=y
# CONFIG_PCIE_DPC is not set
# CONFIG_PCIE_PTM is not set
CONFIG_PCI_BUS_ADDR_T_64BIT=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MSI_IRQ_DOMAIN=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
CONFIG_PCI_STUB=y
# CONFIG_XEN_PCIDEV_FRONTEND is not set
CONFIG_HT_IRQ=y
CONFIG_PCI_ATS=y
CONFIG_PCI_LOCKLESS_CONFIG=y
CONFIG_PCI_IOV=y
CONFIG_PCI_PRI=y
CONFIG_PCI_PASID=y
CONFIG_PCI_LABEL=y
# CONFIG_PCI_HYPERV is not set
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m
#
# DesignWare PCI Core Support
#
# CONFIG_PCIE_DW_PLAT is not set
#
# PCI host controller drivers
#
# CONFIG_VMD is not set
#
# PCI Endpoint
#
# CONFIG_PCI_ENDPOINT is not set
#
# PCI switch controller drivers
#
# CONFIG_PCI_SW_SWITCHTEC is not set
# CONFIG_ISA_BUS is not set
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA is not set
CONFIG_CARDBUS=y
#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_RAPIDIO is not set
# CONFIG_X86_SYSFB is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ELFCORE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
# CONFIG_X86_X32 is not set
CONFIG_COMPAT_32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y
CONFIG_NET_INGRESS=y
CONFIG_NET_EGRESS=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=m
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=m
# CONFIG_TLS is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_FIB_TRIE_STATS=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_CLASSID=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE_DEMUX=m
CONFIG_NET_IP_TUNNEL=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_SYN_COOKIES=y
CONFIG_NET_IPVTI=m
CONFIG_NET_UDP_TUNNEL=m
# CONFIG_NET_FOU is not set
# CONFIG_NET_FOU_IP_TUNNELS is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
# CONFIG_INET_ESP_OFFLOAD is not set
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_INET_UDP_DIAG=m
# CONFIG_INET_RAW_DIAG is not set
# CONFIG_INET_DIAG_DESTROY is not set
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
# CONFIG_TCP_CONG_NV is not set
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_TCP_CONG_DCTCP is not set
# CONFIG_TCP_CONG_CDG is not set
# CONFIG_TCP_CONG_BBR is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
# CONFIG_INET6_ESP_OFFLOAD is not set
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
# CONFIG_IPV6_ILA is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
# CONFIG_IPV6_VTI is not set
CONFIG_IPV6_SIT=m
CONFIG_IPV6_SIT_6RD=y
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_FOU is not set
# CONFIG_IPV6_FOU_TUNNEL is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
CONFIG_IPV6_PIMSM_V2=y
# CONFIG_IPV6_SEG6_LWTUNNEL is not set
# CONFIG_IPV6_SEG6_HMAC is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NET_PTP_CLASSIFY=y
CONFIG_NETWORK_PHY_TIMESTAMPING=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=m
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_INGRESS=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_ACCT=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_LOG_COMMON=m
# CONFIG_NF_LOG_NETDEV is not set
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_ZONES=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_EVENTS=y
# CONFIG_NF_CONNTRACK_TIMEOUT is not set
CONFIG_NF_CONNTRACK_TIMESTAMP=y
CONFIG_NF_CONNTRACK_LABELS=y
CONFIG_NF_CT_PROTO_DCCP=y
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=y
CONFIG_NF_CT_PROTO_UDPLITE=y
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_BROADCAST=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_SNMP=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
# CONFIG_NF_CT_NETLINK_TIMEOUT is not set
# CONFIG_NETFILTER_NETLINK_GLUE_CT is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_NF_NAT_PROTO_DCCP=y
CONFIG_NF_NAT_PROTO_UDPLITE=y
CONFIG_NF_NAT_PROTO_SCTP=y
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_SIP=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_REDIRECT=m
CONFIG_NETFILTER_SYNPROXY=m
CONFIG_NF_TABLES=m
# CONFIG_NF_TABLES_INET is not set
# CONFIG_NF_TABLES_NETDEV is not set
CONFIG_NFT_EXTHDR=m
CONFIG_NFT_META=m
# CONFIG_NFT_RT is not set
# CONFIG_NFT_NUMGEN is not set
CONFIG_NFT_CT=m
# CONFIG_NFT_SET_RBTREE is not set
# CONFIG_NFT_SET_HASH is not set
# CONFIG_NFT_SET_BITMAP is not set
CONFIG_NFT_COUNTER=m
CONFIG_NFT_LOG=m
CONFIG_NFT_LIMIT=m
# CONFIG_NFT_MASQ is not set
# CONFIG_NFT_REDIR is not set
CONFIG_NFT_NAT=m
# CONFIG_NFT_OBJREF is not set
# CONFIG_NFT_QUEUE is not set
# CONFIG_NFT_QUOTA is not set
# CONFIG_NFT_REJECT is not set
CONFIG_NFT_COMPAT=m
CONFIG_NFT_HASH=m
CONFIG_NETFILTER_XTABLES=y
#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=m
CONFIG_NETFILTER_XT_CONNMARK=m
CONFIG_NETFILTER_XT_SET=m
#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_AUDIT=m
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_HMARK=m
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_LED=m
CONFIG_NETFILTER_XT_TARGET_LOG=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_NAT=m
CONFIG_NETFILTER_XT_TARGET_NETMAP=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_REDIRECT=m
CONFIG_NETFILTER_XT_TARGET_TEE=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
CONFIG_NETFILTER_XT_MATCH_BPF=m
# CONFIG_NETFILTER_XT_MATCH_CGROUP is not set
CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLABEL=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_CPU=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ECN=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
# CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_IPVS=m
CONFIG_NETFILTER_XT_MATCH_L2TP=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_NFACCT=m
CONFIG_NETFILTER_XT_MATCH_OSF=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_RECENT=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_IP_SET=m
CONFIG_IP_SET_MAX=256
CONFIG_IP_SET_BITMAP_IP=m
CONFIG_IP_SET_BITMAP_IPMAC=m
CONFIG_IP_SET_BITMAP_PORT=m
CONFIG_IP_SET_HASH_IP=m
# CONFIG_IP_SET_HASH_IPMARK is not set
CONFIG_IP_SET_HASH_IPPORT=m
CONFIG_IP_SET_HASH_IPPORTIP=m
CONFIG_IP_SET_HASH_IPPORTNET=m
# CONFIG_IP_SET_HASH_IPMAC is not set
# CONFIG_IP_SET_HASH_MAC is not set
# CONFIG_IP_SET_HASH_NETPORTNET is not set
CONFIG_IP_SET_HASH_NET=m
# CONFIG_IP_SET_HASH_NETNET is not set
CONFIG_IP_SET_HASH_NETPORT=m
CONFIG_IP_SET_HASH_NETIFACE=m
CONFIG_IP_SET_LIST_SET=m
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
# CONFIG_IP_VS_FO is not set
# CONFIG_IP_VS_OVF is not set
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#
# IPVS SH scheduler
#
CONFIG_IP_VS_SH_TAB_BITS=8
#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m
#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
# CONFIG_NF_SOCKET_IPV4 is not set
CONFIG_NF_TABLES_IPV4=m
CONFIG_NFT_CHAIN_ROUTE_IPV4=m
# CONFIG_NFT_REJECT_IPV4 is not set
# CONFIG_NFT_DUP_IPV4 is not set
# CONFIG_NFT_FIB_IPV4 is not set
# CONFIG_NF_TABLES_ARP is not set
CONFIG_NF_DUP_IPV4=m
# CONFIG_NF_LOG_ARP is not set
CONFIG_NF_LOG_IPV4=m
CONFIG_NF_REJECT_IPV4=m
CONFIG_NF_NAT_IPV4=m
CONFIG_NFT_CHAIN_NAT_IPV4=m
CONFIG_NF_NAT_MASQUERADE_IPV4=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_RPFILTER=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_SYNPROXY=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_SECURITY=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
#
# IPv6: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV6=m
CONFIG_NF_CONNTRACK_IPV6=m
# CONFIG_NF_SOCKET_IPV6 is not set
CONFIG_NF_TABLES_IPV6=m
CONFIG_NFT_CHAIN_ROUTE_IPV6=m
# CONFIG_NFT_REJECT_IPV6 is not set
# CONFIG_NFT_DUP_IPV6 is not set
# CONFIG_NFT_FIB_IPV6 is not set
CONFIG_NF_DUP_IPV6=m
CONFIG_NF_REJECT_IPV6=m
CONFIG_NF_LOG_IPV6=m
CONFIG_NF_NAT_IPV6=m
CONFIG_NFT_CHAIN_NAT_IPV6=m
# CONFIG_NF_NAT_MASQUERADE_IPV6 is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RPFILTER=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_TARGET_SYNPROXY=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_RAW=m
CONFIG_IP6_NF_SECURITY=m
# CONFIG_IP6_NF_NAT is not set
CONFIG_NF_TABLES_BRIDGE=m
# CONFIG_NFT_BRIDGE_META is not set
# CONFIG_NF_LOG_BRIDGE is not set
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_IP6=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
#
# DCCP CCIDs Configuration
#
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=y
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_TFRC_LIB=y
#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_NET_DCCPPROBE is not set
CONFIG_IP_SCTP=m
CONFIG_NET_SCTPPROBE=m
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set
CONFIG_SCTP_COOKIE_HMAC_MD5=y
CONFIG_SCTP_COOKIE_HMAC_SHA1=y
CONFIG_INET_SCTP_DIAG=m
# CONFIG_RDS is not set
CONFIG_TIPC=m
CONFIG_TIPC_MEDIA_UDP=y
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_L2TP=m
CONFIG_L2TP_DEBUGFS=m
CONFIG_L2TP_V3=y
CONFIG_L2TP_IP=m
CONFIG_L2TP_ETH=m
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_MRP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_HAVE_NET_DSA=y
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_VLAN_8021Q_MVRP=y
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_6LOWPAN is not set
CONFIG_IEEE802154=m
# CONFIG_IEEE802154_NL802154_EXPERIMENTAL is not set
CONFIG_IEEE802154_SOCKET=m
CONFIG_MAC802154=m
CONFIG_NET_SCHED=y
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_MULTIQ=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFB=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_DRR=m
CONFIG_NET_SCH_MQPRIO=m
CONFIG_NET_SCH_CHOKE=m
CONFIG_NET_SCH_QFQ=m
CONFIG_NET_SCH_CODEL=m
CONFIG_NET_SCH_FQ_CODEL=m
# CONFIG_NET_SCH_FQ is not set
# CONFIG_NET_SCH_HHF is not set
# CONFIG_NET_SCH_PIE is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_PLUG=m
# CONFIG_NET_SCH_DEFAULT is not set
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=m
CONFIG_NET_CLS_CGROUP=y
CONFIG_NET_CLS_BPF=m
# CONFIG_NET_CLS_FLOWER is not set
# CONFIG_NET_CLS_MATCHALL is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_EMATCH_IPSET=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
# CONFIG_NET_ACT_SAMPLE is not set
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_ACT_CSUM=m
# CONFIG_NET_ACT_VLAN is not set
# CONFIG_NET_ACT_BPF is not set
# CONFIG_NET_ACT_CONNMARK is not set
# CONFIG_NET_ACT_SKBMOD is not set
# CONFIG_NET_ACT_IFE is not set
# CONFIG_NET_ACT_TUNNEL_KEY is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
CONFIG_DCB=y
CONFIG_DNS_RESOLVER=m
# CONFIG_BATMAN_ADV is not set
CONFIG_OPENVSWITCH=m
CONFIG_OPENVSWITCH_GRE=m
CONFIG_OPENVSWITCH_VXLAN=m
CONFIG_VSOCKETS=m
CONFIG_VMWARE_VMCI_VSOCKETS=m
# CONFIG_VIRTIO_VSOCKETS is not set
CONFIG_NETLINK_DIAG=m
CONFIG_MPLS=y
CONFIG_NET_MPLS_GSO=m
# CONFIG_MPLS_ROUTING is not set
# CONFIG_HSR is not set
# CONFIG_NET_SWITCHDEV is not set
# CONFIG_NET_L3_MASTER_DEV is not set
# CONFIG_NET_NCSI is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
# CONFIG_CGROUP_NET_PRIO is not set
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
CONFIG_BPF_JIT=y
CONFIG_NET_FLOW_LIMIT=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
CONFIG_NET_DROP_MONITOR=y
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_AF_KCM is not set
# CONFIG_STREAM_PARSER is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211=m
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
CONFIG_CFG80211_CRDA_SUPPORT=y
CONFIG_CFG80211_WEXT=y
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
# CONFIG_MAC80211_RC_MINSTREL_VHT is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
CONFIG_MAC80211_STA_HASH_MAX_SIZE=0
# CONFIG_WIMAX is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_RFKILL_GPIO is not set
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
# CONFIG_NET_9P_XEN is not set
# CONFIG_NET_9P_DEBUG is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
# CONFIG_PSAMPLE is not set
# CONFIG_NET_IFE is not set
# CONFIG_LWTUNNEL is not set
CONFIG_DST_CACHE=y
CONFIG_GRO_CELLS=y
# CONFIG_NET_DEVLINK is not set
CONFIG_MAY_USE_DEVLINK=y
CONFIG_HAVE_EBPF_JIT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_ALLOW_DEV_COREDUMP=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set
# CONFIG_TEST_ASYNC_DRIVER_PROBE is not set
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_DMA_SHARED_BUFFER=y
# CONFIG_DMA_FENCE_TRACE is not set
CONFIG_DMA_CMA=y
#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=200
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=m
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_BLOCK=m
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set
# CONFIG_MTD_PARTITIONED_MASTER is not set
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set
#
# LPDDR & LPDDR2 PCM memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_SPI_NOR is not set
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
# CONFIG_MTD_UBI_BLOCK is not set
# CONFIG_OF is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_NULL_BLK=m
CONFIG_BLK_DEV_FD=m
# CONFIG_PARIDE is not set
CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m
# CONFIG_ZRAM is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=0
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SKD is not set
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_RAM_DAX is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=m
# CONFIG_XEN_BLKDEV_BACKEND is not set
CONFIG_VIRTIO_BLK=y
# CONFIG_VIRTIO_BLK_SCSI is not set
# CONFIG_BLK_DEV_RBD is not set
CONFIG_BLK_DEV_RSXX=m
CONFIG_NVME_CORE=m
CONFIG_BLK_DEV_NVME=m
# CONFIG_NVME_FC is not set
# CONFIG_NVME_TARGET is not set
#
# Misc devices
#
CONFIG_SENSORS_LIS3LV02D=m
# CONFIG_AD525X_DPOT is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_ICS932S401 is not set
CONFIG_ENCLOSURE_SERVICES=m
CONFIG_SGI_XP=m
CONFIG_HP_ILO=m
CONFIG_SGI_GRU=m
# CONFIG_SGI_GRU_DEBUG is not set
CONFIG_APDS9802ALS=m
CONFIG_ISL29003=m
CONFIG_ISL29020=m
CONFIG_SENSORS_TSL2550=m
CONFIG_SENSORS_BH1770=m
CONFIG_SENSORS_APDS990X=m
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
CONFIG_VMWARE_BALLOON=m
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_PCI_ENDPOINT_TEST is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
# CONFIG_EEPROM_AT25 is not set
CONFIG_EEPROM_LEGACY=m
CONFIG_EEPROM_MAX6875=m
CONFIG_EEPROM_93CX6=m
# CONFIG_EEPROM_93XX46 is not set
# CONFIG_EEPROM_IDT_89HPESX is not set
CONFIG_CB710_CORE=m
# CONFIG_CB710_DEBUG is not set
CONFIG_CB710_DEBUG_ASSUMPTIONS=y
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
CONFIG_SENSORS_LIS3_I2C=m
#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=m
CONFIG_INTEL_MEI=y
CONFIG_INTEL_MEI_ME=y
# CONFIG_INTEL_MEI_TXE is not set
CONFIG_VMWARE_VMCI=m
#
# Intel MIC Bus Driver
#
# CONFIG_INTEL_MIC_BUS is not set
#
# SCIF Bus Driver
#
# CONFIG_SCIF_BUS is not set
#
# VOP Bus Driver
#
# CONFIG_VOP_BUS is not set
#
# Intel MIC Host Driver
#
#
# Intel MIC Card Driver
#
#
# SCIF Driver
#
#
# Intel MIC Coprocessor State Management (COSM) Drivers
#
#
# VOP Driver
#
# CONFIG_GENWQE is not set
# CONFIG_ECHO is not set
# CONFIG_CXL_BASE is not set
# CONFIG_CXL_AFU_DRIVER_OPS is not set
# CONFIG_CXL_LIB is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_ENCLOSURE=m
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
CONFIG_ISCSI_BOOT_SYSFS=m
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_SCSI_BNX2X_FCOE=m
CONFIG_BE2ISCSI=m
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_HPSA=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_3W_SAS=m
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=m
# CONFIG_SCSI_AIC7XXX is not set
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC94XX is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
CONFIG_SCSI_MVSAS_TASKLET=y
CONFIG_SCSI_MVUMI=m
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_ARCMSR=m
# CONFIG_SCSI_ESAS2R is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_MPT3SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT3SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS=m
# CONFIG_SCSI_SMARTPQI is not set
CONFIG_SCSI_UFSHCD=m
CONFIG_SCSI_UFSHCD_PCI=m
# CONFIG_SCSI_UFS_DWC_TC_PCI is not set
# CONFIG_SCSI_UFSHCD_PLATFORM is not set
CONFIG_SCSI_HPTIOP=m
# CONFIG_SCSI_BUSLOGIC is not set
CONFIG_VMWARE_PVSCSI=m
# CONFIG_XEN_SCSI_FRONTEND is not set
CONFIG_HYPERV_STORAGE=m
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
CONFIG_FCOE=m
CONFIG_FCOE_FNIC=m
# CONFIG_SCSI_SNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_ISCI=m
# CONFIG_SCSI_IPS is not set
CONFIG_SCSI_INITIO=m
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
CONFIG_SCSI_STEX=m
# CONFIG_SCSI_SYM53C8XX_2 is not set
CONFIG_SCSI_IPR=m
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA_FC=m
# CONFIG_TCM_QLA2XXX is not set
CONFIG_SCSI_QLA_ISCSI=m
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_WD719X is not set
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_PMCRAID=m
CONFIG_SCSI_PM8001=m
# CONFIG_SCSI_BFA_FC is not set
CONFIG_SCSI_VIRTIO=m
CONFIG_SCSI_CHELSIO_FCOE=m
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=y
CONFIG_SCSI_DH_HP_SW=y
CONFIG_SCSI_DH_EMC=y
CONFIG_SCSI_DH_ALUA=y
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
# CONFIG_SATA_ZPODD is not set
CONFIG_SATA_PMP=y
#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
CONFIG_SATA_AHCI_PLATFORM=m
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_ACARD_AHCI=m
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y
#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_SX4=m
CONFIG_ATA_BMDMA=y
#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=m
# CONFIG_SATA_DWC is not set
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_SVW=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m
#
# PATA SFF controllers with BMDMA
#
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=m
CONFIG_PATA_ARTOP=m
CONFIG_PATA_ATIIXP=m
CONFIG_PATA_ATP867X=m
CONFIG_PATA_CMD64X=m
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_PATA_HPT366=m
CONFIG_PATA_HPT37X=m
CONFIG_PATA_HPT3X2N=m
CONFIG_PATA_HPT3X3=m
# CONFIG_PATA_HPT3X3_DMA is not set
CONFIG_PATA_IT8213=m
CONFIG_PATA_IT821X=m
CONFIG_PATA_JMICRON=m
CONFIG_PATA_MARVELL=m
CONFIG_PATA_NETCELL=m
CONFIG_PATA_NINJA32=m
# CONFIG_PATA_NS87415 is not set
CONFIG_PATA_OLDPIIX=m
# CONFIG_PATA_OPTIDMA is not set
CONFIG_PATA_PDC2027X=m
CONFIG_PATA_PDC_OLD=m
# CONFIG_PATA_RADISYS is not set
CONFIG_PATA_RDC=m
CONFIG_PATA_SCH=m
CONFIG_PATA_SERVERWORKS=m
CONFIG_PATA_SIL680=m
CONFIG_PATA_SIS=m
CONFIG_PATA_TOSHIBA=m
# CONFIG_PATA_TRIFLEX is not set
CONFIG_PATA_VIA=m
# CONFIG_PATA_WINBOND is not set
#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_PATA_RZ1000 is not set
#
# Generic fallback / legacy drivers
#
CONFIG_PATA_ACPI=m
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_LEGACY is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
# CONFIG_MD_CLUSTER is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_MQ_DEFAULT is not set
CONFIG_DM_DEBUG=y
CONFIG_DM_BUFIO=m
# CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING is not set
CONFIG_DM_BIO_PRISON=m
CONFIG_DM_PERSISTENT_DATA=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_THIN_PROVISIONING=m
CONFIG_DM_CACHE=m
CONFIG_DM_CACHE_SMQ=m
# CONFIG_DM_ERA is not set
CONFIG_DM_MIRROR=m
CONFIG_DM_LOG_USERSPACE=m
CONFIG_DM_RAID=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_QL=m
CONFIG_DM_MULTIPATH_ST=m
CONFIG_DM_DELAY=m
CONFIG_DM_UEVENT=y
CONFIG_DM_FLAKEY=m
CONFIG_DM_VERITY=m
# CONFIG_DM_VERITY_FEC is not set
CONFIG_DM_SWITCH=m
# CONFIG_DM_LOG_WRITES is not set
# CONFIG_DM_INTEGRITY is not set
CONFIG_TARGET_CORE=m
CONFIG_TCM_IBLOCK=m
CONFIG_TCM_FILEIO=m
CONFIG_TCM_PSCSI=m
# CONFIG_TCM_USER2 is not set
CONFIG_LOOPBACK_TARGET=m
CONFIG_TCM_FC=m
CONFIG_ISCSI_TARGET=m
# CONFIG_ISCSI_TARGET_CXGB4 is not set
# CONFIG_SBP_TARGET is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LOGGING=y
#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
CONFIG_FIREWIRE_NET=m
# CONFIG_FIREWIRE_NOSY is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_MII=y
CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
# CONFIG_EQUALIZER is not set
CONFIG_NET_FC=y
CONFIG_IFB=m
CONFIG_NET_TEAM=m
CONFIG_NET_TEAM_MODE_BROADCAST=m
CONFIG_NET_TEAM_MODE_ROUNDROBIN=m
CONFIG_NET_TEAM_MODE_RANDOM=m
CONFIG_NET_TEAM_MODE_ACTIVEBACKUP=m
CONFIG_NET_TEAM_MODE_LOADBALANCE=m
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_VXLAN=m
# CONFIG_GENEVE is not set
# CONFIG_GTP is not set
# CONFIG_MACSEC is not set
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
CONFIG_TAP=m
# CONFIG_TUN_VNET_CROSS_LE is not set
CONFIG_VETH=m
CONFIG_VIRTIO_NET=y
CONFIG_NLMON=m
# CONFIG_ARCNET is not set
# CONFIG_ATM_DRIVERS is not set
#
# CAIF transport drivers
#
#
# Distributed Switch Architecture drivers
#
CONFIG_ETHERNET=y
CONFIG_MDIO=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
CONFIG_NET_VENDOR_AGERE=y
# CONFIG_ET131X is not set
CONFIG_NET_VENDOR_ALACRITECH=y
# CONFIG_SLICOSS is not set
# CONFIG_NET_VENDOR_ALTEON is not set
# CONFIG_ALTERA_TSE is not set
CONFIG_NET_VENDOR_AMAZON=y
# CONFIG_ENA_ETHERNET is not set
# CONFIG_NET_VENDOR_AMD is not set
CONFIG_NET_VENDOR_AQUANTIA=y
# CONFIG_AQTION is not set
CONFIG_NET_VENDOR_ARC=y
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATL2=m
CONFIG_ATL1=m
CONFIG_ATL1E=m
CONFIG_ATL1C=m
CONFIG_ALX=m
# CONFIG_NET_VENDOR_AURORA is not set
CONFIG_NET_CADENCE=y
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
# CONFIG_BCMGENET is not set
CONFIG_BNX2=m
CONFIG_CNIC=m
CONFIG_TIGON3=y
CONFIG_TIGON3_HWMON=y
# CONFIG_BNX2X is not set
# CONFIG_BNXT is not set
CONFIG_NET_VENDOR_BROCADE=y
CONFIG_BNA=m
CONFIG_NET_VENDOR_CAVIUM=y
# CONFIG_THUNDER_NIC_PF is not set
# CONFIG_THUNDER_NIC_VF is not set
# CONFIG_THUNDER_NIC_BGX is not set
# CONFIG_THUNDER_NIC_RGX is not set
# CONFIG_LIQUIDIO is not set
# CONFIG_LIQUIDIO_VF is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3=m
CONFIG_CHELSIO_T4=m
# CONFIG_CHELSIO_T4_DCB is not set
CONFIG_CHELSIO_T4VF=m
CONFIG_CHELSIO_LIB=m
CONFIG_NET_VENDOR_CISCO=y
CONFIG_ENIC=m
# CONFIG_CX_ECAT is not set
CONFIG_DNET=m
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_DE2104X_DSL=0
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
# CONFIG_NET_VENDOR_DLINK is not set
CONFIG_NET_VENDOR_EMULEX=y
CONFIG_BE2NET=m
CONFIG_BE2NET_HWMON=y
CONFIG_NET_VENDOR_EZCHIP=y
# CONFIG_NET_VENDOR_EXAR is not set
# CONFIG_NET_VENDOR_HP is not set
CONFIG_NET_VENDOR_INTEL=y
# CONFIG_E100 is not set
CONFIG_E1000=y
CONFIG_E1000E=y
CONFIG_E1000E_HWTS=y
CONFIG_IGB=y
CONFIG_IGB_HWMON=y
CONFIG_IGBVF=m
CONFIG_IXGB=m
CONFIG_IXGBE=y
CONFIG_IXGBE_HWMON=y
CONFIG_IXGBE_DCB=y
CONFIG_IXGBEVF=m
CONFIG_I40E=m
# CONFIG_I40E_DCB is not set
# CONFIG_I40EVF is not set
# CONFIG_FM10K is not set
# CONFIG_NET_VENDOR_I825XX is not set
CONFIG_JME=m
CONFIG_NET_VENDOR_MARVELL=y
CONFIG_MVMDIO=m
CONFIG_SKGE=m
CONFIG_SKGE_DEBUG=y
CONFIG_SKGE_GENESIS=y
CONFIG_SKY2=m
CONFIG_SKY2_DEBUG=y
CONFIG_NET_VENDOR_MELLANOX=y
CONFIG_MLX4_EN=m
CONFIG_MLX4_EN_DCB=y
CONFIG_MLX4_CORE=m
CONFIG_MLX4_DEBUG=y
# CONFIG_MLX5_CORE is not set
# CONFIG_MLXSW_CORE is not set
# CONFIG_MLXFW is not set
# CONFIG_NET_VENDOR_MICREL is not set
CONFIG_NET_VENDOR_MICROCHIP=y
# CONFIG_ENC28J60 is not set
# CONFIG_ENCX24J600 is not set
CONFIG_NET_VENDOR_MYRI=y
CONFIG_MYRI10GE=m
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
CONFIG_NET_VENDOR_NETRONOME=y
# CONFIG_NFP is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
CONFIG_NET_VENDOR_OKI=y
CONFIG_ETHOC=m
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
CONFIG_YELLOWFIN=m
CONFIG_NET_VENDOR_QLOGIC=y
CONFIG_QLA3XXX=m
CONFIG_QLCNIC=m
CONFIG_QLCNIC_SRIOV=y
CONFIG_QLCNIC_DCB=y
CONFIG_QLCNIC_HWMON=y
CONFIG_QLGE=m
CONFIG_NETXEN_NIC=m
# CONFIG_QED is not set
CONFIG_NET_VENDOR_QUALCOMM=y
# CONFIG_QCOM_EMAC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_ATP is not set
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R8169=y
CONFIG_NET_VENDOR_RENESAS=y
# CONFIG_NET_VENDOR_RDC is not set
CONFIG_NET_VENDOR_ROCKER=y
CONFIG_NET_VENDOR_SAMSUNG=y
# CONFIG_SXGBE_ETH is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
# CONFIG_NET_VENDOR_SIS is not set
CONFIG_NET_VENDOR_SOLARFLARE=y
CONFIG_SFC=m
CONFIG_SFC_MTD=y
CONFIG_SFC_MCDI_MON=y
CONFIG_SFC_SRIOV=y
CONFIG_SFC_MCDI_LOGGING=y
# CONFIG_SFC_FALCON is not set
CONFIG_NET_VENDOR_SMSC=y
CONFIG_EPIC100=m
# CONFIG_SMSC911X is not set
CONFIG_SMSC9420=m
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_NET_VENDOR_SYNOPSYS=y
# CONFIG_DWC_XLGMAC is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_MDIO_DEVICE=y
CONFIG_MDIO_BITBANG=m
# CONFIG_MDIO_GPIO is not set
# CONFIG_MDIO_THUNDER is not set
CONFIG_PHYLIB=y
CONFIG_SWPHY=y
# CONFIG_LED_TRIGGER_PHY is not set
#
# MII PHY device drivers
#
CONFIG_AMD_PHY=m
# CONFIG_AQUANTIA_PHY is not set
CONFIG_AT803X_PHY=m
# CONFIG_BCM7XXX_PHY is not set
CONFIG_BCM87XX_PHY=m
CONFIG_BCM_NET_PHYLIB=m
CONFIG_BROADCOM_PHY=m
CONFIG_CICADA_PHY=m
# CONFIG_CORTINA_PHY is not set
CONFIG_DAVICOM_PHY=m
# CONFIG_DP83848_PHY is not set
# CONFIG_DP83867_PHY is not set
CONFIG_FIXED_PHY=y
CONFIG_ICPLUS_PHY=m
# CONFIG_INTEL_XWAY_PHY is not set
CONFIG_LSI_ET1011C_PHY=m
CONFIG_LXT_PHY=m
CONFIG_MARVELL_PHY=m
# CONFIG_MARVELL_10G_PHY is not set
CONFIG_MICREL_PHY=m
# CONFIG_MICROCHIP_PHY is not set
# CONFIG_MICROSEMI_PHY is not set
CONFIG_NATIONAL_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_REALTEK_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_STE10XP=m
# CONFIG_TERANETICS_PHY is not set
CONFIG_VITESSE_PHY=m
# CONFIG_XILINX_GMII2RGMII is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_MPPE=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPPOATM=m
CONFIG_PPPOE=m
CONFIG_PPTP=m
CONFIG_PPPOL2TP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_SLIP=m
CONFIG_SLHC=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_USB_NET_DRIVERS=y
CONFIG_USB_CATC=y
CONFIG_USB_KAWETH=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8150=y
CONFIG_USB_RTL8152=m
# CONFIG_USB_LAN78XX is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_AX88179_178A=m
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=m
# CONFIG_USB_NET_HUAWEI_CDC_NCM is not set
CONFIG_USB_NET_CDC_MBIM=m
CONFIG_USB_NET_DM9601=y
# CONFIG_USB_NET_SR9700 is not set
# CONFIG_USB_NET_SR9800 is not set
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_USB_NET_GL620A=y
CONFIG_USB_NET_NET1080=y
CONFIG_USB_NET_PLUSB=y
CONFIG_USB_NET_MCS7830=y
CONFIG_USB_NET_RNDIS_HOST=y
CONFIG_USB_NET_CDC_SUBSET_ENABLE=y
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
CONFIG_USB_NET_CX82310_ETH=m
CONFIG_USB_NET_KALMIA=m
CONFIG_USB_NET_QMI_WWAN=m
CONFIG_USB_HSO=m
CONFIG_USB_NET_INT51X1=y
CONFIG_USB_IPHETH=y
CONFIG_USB_SIERRA_NET=y
CONFIG_USB_VL600=m
# CONFIG_USB_NET_CH9200 is not set
CONFIG_WLAN=y
# CONFIG_WIRELESS_WDS is not set
CONFIG_WLAN_VENDOR_ADMTEK=y
# CONFIG_ADM8211 is not set
CONFIG_WLAN_VENDOR_ATH=y
# CONFIG_ATH_DEBUG is not set
# CONFIG_ATH5K is not set
# CONFIG_ATH5K_PCI is not set
# CONFIG_ATH9K is not set
# CONFIG_ATH9K_HTC is not set
# CONFIG_CARL9170 is not set
# CONFIG_ATH6KL is not set
# CONFIG_AR5523 is not set
# CONFIG_WIL6210 is not set
# CONFIG_ATH10K is not set
# CONFIG_WCN36XX is not set
CONFIG_WLAN_VENDOR_ATMEL=y
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
CONFIG_WLAN_VENDOR_BROADCOM=y
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMSMAC is not set
# CONFIG_BRCMFMAC is not set
CONFIG_WLAN_VENDOR_CISCO=y
# CONFIG_AIRO is not set
CONFIG_WLAN_VENDOR_INTEL=y
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_IWL4965 is not set
# CONFIG_IWL3945 is not set
# CONFIG_IWLWIFI is not set
CONFIG_WLAN_VENDOR_INTERSIL=y
# CONFIG_HOSTAP is not set
# CONFIG_HERMES is not set
# CONFIG_P54_COMMON is not set
# CONFIG_PRISM54 is not set
CONFIG_WLAN_VENDOR_MARVELL=y
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_MWIFIEX is not set
# CONFIG_MWL8K is not set
CONFIG_WLAN_VENDOR_MEDIATEK=y
# CONFIG_MT7601U is not set
CONFIG_WLAN_VENDOR_RALINK=y
# CONFIG_RT2X00 is not set
CONFIG_WLAN_VENDOR_REALTEK=y
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
CONFIG_RTL_CARDS=m
# CONFIG_RTL8192CE is not set
# CONFIG_RTL8192SE is not set
# CONFIG_RTL8192DE is not set
# CONFIG_RTL8723AE is not set
# CONFIG_RTL8723BE is not set
# CONFIG_RTL8188EE is not set
# CONFIG_RTL8192EE is not set
# CONFIG_RTL8821AE is not set
# CONFIG_RTL8192CU is not set
# CONFIG_RTL8XXXU is not set
CONFIG_WLAN_VENDOR_RSI=y
# CONFIG_RSI_91X is not set
CONFIG_WLAN_VENDOR_ST=y
# CONFIG_CW1200 is not set
CONFIG_WLAN_VENDOR_TI=y
# CONFIG_WL1251 is not set
# CONFIG_WL12XX is not set
# CONFIG_WL18XX is not set
# CONFIG_WLCORE is not set
CONFIG_WLAN_VENDOR_ZYDAS=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_ZD1211RW is not set
CONFIG_WLAN_VENDOR_QUANTENNA=y
# CONFIG_QTNFMAC_PEARL_PCIE is not set
CONFIG_MAC80211_HWSIM=m
# CONFIG_USB_NET_RNDIS_WLAN is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
CONFIG_WAN=y
# CONFIG_LANMEDIA is not set
CONFIG_HDLC=m
CONFIG_HDLC_RAW=m
# CONFIG_HDLC_RAW_ETH is not set
CONFIG_HDLC_CISCO=m
CONFIG_HDLC_FR=m
CONFIG_HDLC_PPP=m
#
# X.25/LAPB support is disabled
#
# CONFIG_PCI200SYN is not set
# CONFIG_WANXL is not set
# CONFIG_PC300TOO is not set
# CONFIG_FARSYNC is not set
# CONFIG_DSCC4 is not set
CONFIG_DLCI=m
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
CONFIG_IEEE802154_DRIVERS=m
CONFIG_IEEE802154_FAKELB=m
# CONFIG_IEEE802154_AT86RF230 is not set
# CONFIG_IEEE802154_MRF24J40 is not set
# CONFIG_IEEE802154_CC2520 is not set
# CONFIG_IEEE802154_ATUSB is not set
# CONFIG_IEEE802154_ADF7242 is not set
# CONFIG_IEEE802154_CA8210 is not set
CONFIG_XEN_NETDEV_FRONTEND=m
# CONFIG_XEN_NETDEV_BACKEND is not set
CONFIG_VMXNET3=m
# CONFIG_FUJITSU_ES is not set
CONFIG_HYPERV_NET=m
CONFIG_ISDN=y
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y
#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m
#
# ISDN4Linux hardware drivers
#
#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set
CONFIG_ISDN_CAPI=m
# CONFIG_CAPI_TRACE is not set
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPIDRV=m
# CONFIG_ISDN_CAPI_CAPIDRV_VERBOSE is not set
#
# CAPI hardware drivers
#
CONFIG_CAPI_AVM=y
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
# CONFIG_CAPI_EICON is not set
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_CAPI=y
# CONFIG_GIGASET_I4L is not set
# CONFIG_GIGASET_DUMMYLL is not set
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
CONFIG_GIGASET_M101=m
# CONFIG_GIGASET_DEBUG is not set
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
CONFIG_MISDN=m
CONFIG_MISDN_DSP=m
CONFIG_MISDN_L1OIP=m
#
# mISDN hardware drivers
#
CONFIG_MISDN_HFCPCI=m
CONFIG_MISDN_HFCMULTI=m
CONFIG_MISDN_HFCUSB=m
CONFIG_MISDN_AVMFRITZ=m
CONFIG_MISDN_SPEEDFAX=m
CONFIG_MISDN_INFINEON=m
CONFIG_MISDN_W6692=m
CONFIG_MISDN_NETJET=m
CONFIG_MISDN_IPAC=m
CONFIG_MISDN_ISAR=m
CONFIG_ISDN_HDLC=m
# CONFIG_NVM is not set
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_LEDS=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
CONFIG_INPUT_SPARSEKMAP=m
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_DLINK_DIR685 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_TM2_TOUCHKEY is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_BYD=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_PS2_SENTELIC=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_PS2_FOCALTECH=y
# CONFIG_MOUSE_PS2_VMMOUSE is not set
CONFIG_MOUSE_PS2_SMBUS=y
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_APPLETOUCH=m
CONFIG_MOUSE_BCM5974=m
CONFIG_MOUSE_CYAPA=m
# CONFIG_MOUSE_ELAN_I2C is not set
CONFIG_MOUSE_VSXXXAA=m
# CONFIG_MOUSE_GPIO is not set
CONFIG_MOUSE_SYNAPTICS_I2C=m
CONFIG_MOUSE_SYNAPTICS_USB=m
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
CONFIG_TABLET_USB_ACECAD=m
CONFIG_TABLET_USB_AIPTEK=m
CONFIG_TABLET_USB_GTCO=m
# CONFIG_TABLET_USB_HANWANG is not set
CONFIG_TABLET_USB_KBTAB=m
# CONFIG_TABLET_USB_PEGASUS is not set
# CONFIG_TABLET_SERIAL_WACOM4 is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_PROPERTIES=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX_SERIAL is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GOODIX is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_EKTF2127 is not set
# CONFIG_TOUCHSCREEN_ELAN is not set
# CONFIG_TOUCHSCREEN_ELO is not set
CONFIG_TOUCHSCREEN_WACOM_W8001=m
CONFIG_TOUCHSCREEN_WACOM_I2C=m
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MELFAS_MIP4 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_WDT87XX_I2C is not set
# CONFIG_TOUCHSCREEN_WM97XX is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2004 is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_RM_TS is not set
# CONFIG_TOUCHSCREEN_SILEAD is not set
# CONFIG_TOUCHSCREEN_SIS_I2C is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_STMFTS is not set
# CONFIG_TOUCHSCREEN_SUR40 is not set
# CONFIG_TOUCHSCREEN_SURFACE3_SPI is not set
# CONFIG_TOUCHSCREEN_SX8654 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_TOUCHSCREEN_ZET6223 is not set
# CONFIG_TOUCHSCREEN_ZFORCE is not set
# CONFIG_TOUCHSCREEN_ROHM_BU21023 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_E3X0_BUTTON is not set
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_MMA8450 is not set
CONFIG_INPUT_APANEL=m
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_BEEPER is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_GPIO_DECODER is not set
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
# CONFIG_INPUT_KXTJ9 is not set
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_YEALINK=m
CONFIG_INPUT_CM109=m
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_PWM_BEEPER is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_IMS_PCU is not set
# CONFIG_INPUT_CMA3000 is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
# CONFIG_INPUT_IDEAPAD_SLIDEBAR is not set
# CONFIG_INPUT_DRV260X_HAPTICS is not set
# CONFIG_INPUT_DRV2665_HAPTICS is not set
# CONFIG_INPUT_DRV2667_HAPTICS is not set
# CONFIG_RMI4_CORE is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
# CONFIG_SERIO_PS2MULT is not set
CONFIG_SERIO_ARC_PS2=m
CONFIG_HYPERV_KEYBOARD=m
# CONFIG_USERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_NOZOMI=m
# CONFIG_ISI is not set
CONFIG_N_HDLC=m
CONFIG_N_GSM=m
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
# CONFIG_DEVKMEM is not set
#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_EXAR=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_FSL is not set
CONFIG_SERIAL_8250_DW=y
# CONFIG_SERIAL_8250_RT288X is not set
CONFIG_SERIAL_8250_LPSS=y
CONFIG_SERIAL_8250_MID=y
# CONFIG_SERIAL_8250_MOXA is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
CONFIG_SERIAL_ARC=m
CONFIG_SERIAL_ARC_NR_PORTS=1
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_DEV_BUS is not set
# CONFIG_TTY_PRINTK is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
# CONFIG_IPMI_SSIF is not set
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_HW_RANDOM_TPM=m
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
# CONFIG_HPET_MMAP_DEFAULT is not set
CONFIG_HANGCHECK_TIMER=m
CONFIG_UV_MMTIMER=m
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS=y
# CONFIG_TCG_TIS_SPI is not set
# CONFIG_TCG_TIS_I2C_ATMEL is not set
# CONFIG_TCG_TIS_I2C_INFINEON is not set
# CONFIG_TCG_TIS_I2C_NUVOTON is not set
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
# CONFIG_TCG_XEN is not set
# CONFIG_TCG_CRB is not set
# CONFIG_TCG_VTPM_PROXY is not set
# CONFIG_TCG_TIS_ST33ZP24_I2C is not set
# CONFIG_TCG_TIS_ST33ZP24_SPI is not set
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_ACPI_I2C_OPREGION=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_MUX=m
#
# Multiplexer I2C Chip support
#
# CONFIG_I2C_MUX_GPIO is not set
# CONFIG_I2C_MUX_LTC4306 is not set
# CONFIG_I2C_MUX_PCA9541 is not set
# CONFIG_I2C_MUX_PCA954x is not set
# CONFIG_I2C_MUX_PINCTRL is not set
# CONFIG_I2C_MUX_REG is not set
# CONFIG_I2C_MUX_MLXCPLD is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=y
CONFIG_I2C_ISCH=m
CONFIG_I2C_ISMT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
#
# ACPI drivers
#
CONFIG_I2C_SCMI=m
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DESIGNWARE_CORE=m
CONFIG_I2C_DESIGNWARE_PLATFORM=m
CONFIG_I2C_DESIGNWARE_PCI=m
# CONFIG_I2C_DESIGNWARE_BAYTRAIL is not set
# CONFIG_I2C_EMEV2 is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PCA_PLATFORM=m
# CONFIG_I2C_PXA_PCI is not set
CONFIG_I2C_SIMTEC=m
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_DIOLAN_U2C=m
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_ROBOTFUZZ_OSIF is not set
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m
CONFIG_I2C_VIPERBOARD=m
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_MLXCPLD is not set
CONFIG_I2C_STUB=m
# CONFIG_I2C_SLAVE is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_AXI_SPI_ENGINE is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_BUTTERFLY is not set
# CONFIG_SPI_CADENCE is not set
CONFIG_SPI_DESIGNWARE=m
# CONFIG_SPI_DW_PCI is not set
# CONFIG_SPI_DW_MMIO is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_LM70_LLP is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_PXA2XX=m
CONFIG_SPI_PXA2XX_PCI=m
# CONFIG_SPI_ROCKCHIP is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_ZYNQMP_GQSPI is not set
#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_LOOPBACK_TEST is not set
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_SPI_SLAVE is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
CONFIG_PPS_CLIENT_PARPORT=m
CONFIG_PPS_CLIENT_GPIO=m
#
# PPS generators support
#
#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y
CONFIG_DP83640_PHY=m
CONFIG_PTP_1588_CLOCK_KVM=y
CONFIG_PINCTRL=y
#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
# CONFIG_PINCTRL_AMD is not set
# CONFIG_PINCTRL_MCP23S08 is not set
# CONFIG_PINCTRL_SX150X is not set
CONFIG_PINCTRL_BAYTRAIL=y
# CONFIG_PINCTRL_CHERRYVIEW is not set
# CONFIG_PINCTRL_BROXTON is not set
# CONFIG_PINCTRL_CANNONLAKE is not set
# CONFIG_PINCTRL_GEMINILAKE is not set
# CONFIG_PINCTRL_SUNRISEPOINT is not set
CONFIG_GPIOLIB=y
CONFIG_GPIO_ACPI=y
CONFIG_GPIOLIB_IRQCHIP=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y
#
# Memory mapped GPIO drivers
#
# CONFIG_GPIO_AMDPT is not set
# CONFIG_GPIO_DWAPB is not set
# CONFIG_GPIO_EXAR is not set
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_ICH is not set
CONFIG_GPIO_LYNXPOINT=m
CONFIG_GPIO_MOCKUP=y
# CONFIG_GPIO_VX855 is not set
#
# Port-mapped I/O GPIO drivers
#
# CONFIG_GPIO_F7188X is not set
# CONFIG_GPIO_IT87 is not set
# CONFIG_GPIO_SCH is not set
# CONFIG_GPIO_SCH311X is not set
#
# I2C GPIO expanders
#
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_TPIC2810 is not set
#
# MFD GPIO expanders
#
#
# PCI GPIO expanders
#
# CONFIG_GPIO_AMD8111 is not set
# CONFIG_GPIO_ML_IOH is not set
# CONFIG_GPIO_PCI_IDIO_16 is not set
# CONFIG_GPIO_RDC321X is not set
#
# SPI GPIO expanders
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_PISOSR is not set
# CONFIG_GPIO_XRA1403 is not set
#
# USB GPIO expanders
#
# CONFIG_GPIO_VIPERBOARD is not set
# CONFIG_W1 is not set
# CONFIG_POWER_AVS is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_CHARGER_SBS is not set
# CONFIG_BATTERY_BQ27XXX is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_ISP1704 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_LTC3651 is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_BQ24190 is not set
# CONFIG_CHARGER_BQ24257 is not set
# CONFIG_CHARGER_BQ24735 is not set
# CONFIG_CHARGER_BQ25890 is not set
CONFIG_CHARGER_SMB347=m
# CONFIG_BATTERY_GAUGE_LTC2941 is not set
# CONFIG_CHARGER_RT9455 is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Native drivers
#
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
# CONFIG_SENSORS_AD7314 is not set
CONFIG_SENSORS_AD7414=m
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7X10=m
# CONFIG_SENSORS_ADT7310 is not set
CONFIG_SENSORS_ADT7410=m
CONFIG_SENSORS_ADT7411=m
CONFIG_SENSORS_ADT7462=m
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_ADT7475=m
CONFIG_SENSORS_ASC7621=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_K10TEMP=m
CONFIG_SENSORS_FAM15H_POWER=m
CONFIG_SENSORS_APPLESMC=m
CONFIG_SENSORS_ASB100=m
# CONFIG_SENSORS_ASPEED is not set
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS620=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_DELL_SMM=m
CONFIG_SENSORS_I5K_AMB=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
CONFIG_SENSORS_FSCHMD=m
# CONFIG_SENSORS_FTSTEUTATES is not set
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_G760A=m
# CONFIG_SENSORS_G762 is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_HIH6130 is not set
CONFIG_SENSORS_IBMAEM=m
CONFIG_SENSORS_IBMPEX=m
# CONFIG_SENSORS_I5500 is not set
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_POWR1220 is not set
CONFIG_SENSORS_LINEAGE=m
# CONFIG_SENSORS_LTC2945 is not set
# CONFIG_SENSORS_LTC2990 is not set
CONFIG_SENSORS_LTC4151=m
CONFIG_SENSORS_LTC4215=m
# CONFIG_SENSORS_LTC4222 is not set
CONFIG_SENSORS_LTC4245=m
# CONFIG_SENSORS_LTC4260 is not set
CONFIG_SENSORS_LTC4261=m
# CONFIG_SENSORS_MAX1111 is not set
CONFIG_SENSORS_MAX16065=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_MAX1668=m
CONFIG_SENSORS_MAX197=m
# CONFIG_SENSORS_MAX31722 is not set
CONFIG_SENSORS_MAX6639=m
CONFIG_SENSORS_MAX6642=m
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_MAX6697=m
# CONFIG_SENSORS_MAX31790 is not set
CONFIG_SENSORS_MCP3021=m
# CONFIG_SENSORS_TC654 is not set
# CONFIG_SENSORS_ADCXX is not set
CONFIG_SENSORS_LM63=m
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_LM93=m
CONFIG_SENSORS_LM95234=m
CONFIG_SENSORS_LM95241=m
CONFIG_SENSORS_LM95245=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_NTC_THERMISTOR=m
# CONFIG_SENSORS_NCT6683 is not set
CONFIG_SENSORS_NCT6775=m
# CONFIG_SENSORS_NCT7802 is not set
# CONFIG_SENSORS_NCT7904 is not set
CONFIG_SENSORS_PCF8591=m
CONFIG_PMBUS=m
CONFIG_SENSORS_PMBUS=m
CONFIG_SENSORS_ADM1275=m
# CONFIG_SENSORS_IR35221 is not set
CONFIG_SENSORS_LM25066=m
CONFIG_SENSORS_LTC2978=m
# CONFIG_SENSORS_LTC3815 is not set
CONFIG_SENSORS_MAX16064=m
# CONFIG_SENSORS_MAX20751 is not set
CONFIG_SENSORS_MAX34440=m
CONFIG_SENSORS_MAX8688=m
# CONFIG_SENSORS_TPS40422 is not set
CONFIG_SENSORS_UCD9000=m
CONFIG_SENSORS_UCD9200=m
CONFIG_SENSORS_ZL6100=m
# CONFIG_SENSORS_SHT15 is not set
CONFIG_SENSORS_SHT21=m
# CONFIG_SENSORS_SHT3x is not set
# CONFIG_SENSORS_SHTC1 is not set
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_DME1737=m
CONFIG_SENSORS_EMC1403=m
# CONFIG_SENSORS_EMC2103 is not set
CONFIG_SENSORS_EMC6W201=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_SCH56XX_COMMON=m
CONFIG_SENSORS_SCH5627=m
CONFIG_SENSORS_SCH5636=m
# CONFIG_SENSORS_STTS751 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_ADC128D818 is not set
CONFIG_SENSORS_ADS1015=m
CONFIG_SENSORS_ADS7828=m
# CONFIG_SENSORS_ADS7871 is not set
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA209=m
CONFIG_SENSORS_INA2XX=m
# CONFIG_SENSORS_INA3221 is not set
# CONFIG_SENSORS_TC74 is not set
CONFIG_SENSORS_THMC50=m
CONFIG_SENSORS_TMP102=m
# CONFIG_SENSORS_TMP103 is not set
# CONFIG_SENSORS_TMP108 is not set
CONFIG_SENSORS_TMP401=m
CONFIG_SENSORS_TMP421=m
CONFIG_SENSORS_VIA_CPUTEMP=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83795=m
# CONFIG_SENSORS_W83795_FANCTRL is not set
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83L786NG=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
# CONFIG_SENSORS_XGENE is not set
#
# ACPI drivers
#
CONFIG_SENSORS_ACPI_POWER=m
CONFIG_SENSORS_ATK0110=m
CONFIG_THERMAL=y
CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_WRITABLE_TRIPS=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set
CONFIG_THERMAL_GOV_FAIR_SHARE=y
CONFIG_THERMAL_GOV_STEP_WISE=y
CONFIG_THERMAL_GOV_BANG_BANG=y
CONFIG_THERMAL_GOV_USER_SPACE=y
# CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_EMULATION is not set
CONFIG_INTEL_POWERCLAMP=m
CONFIG_X86_PKG_TEMP_THERMAL=m
# CONFIG_INTEL_SOC_DTS_THERMAL is not set
#
# ACPI INT340X thermal drivers
#
# CONFIG_INT340X_THERMAL is not set
CONFIG_INTEL_PCH_THERMAL=m
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
# CONFIG_WATCHDOG_SYSFS is not set
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_WDAT_WDT is not set
# CONFIG_XILINX_WATCHDOG is not set
# CONFIG_ZIIRAVE_WATCHDOG is not set
# CONFIG_CADENCE_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_F71808E_WDT=m
CONFIG_SP5100_TCO=m
CONFIG_SBC_FITPC2_WATCHDOG=m
# CONFIG_EUROTECH_WDT is not set
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=y
CONFIG_IE6XX_WDT=m
CONFIG_ITCO_WDT=y
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_IT8712F_WDT=m
CONFIG_IT87_WDT=m
CONFIG_HP_WATCHDOG=m
CONFIG_HPWDT_NMI_DECODING=y
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
CONFIG_NV_TCO=m
# CONFIG_60XX_WDT is not set
# CONFIG_CPU5_WDT is not set
CONFIG_SMSC_SCH311X_WDT=m
# CONFIG_SMSC37B787_WDT is not set
CONFIG_VIA_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
# CONFIG_INTEL_MEI_WDT is not set
# CONFIG_NI903X_WDT is not set
# CONFIG_NIC7018_WDT is not set
# CONFIG_MEN_A21_WDT is not set
CONFIG_XEN_WDT=m
#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
#
# Watchdog Pretimeout Governors
#
# CONFIG_WATCHDOG_PRETIMEOUT_GOV is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
CONFIG_SSB_SDIOHOST_POSSIBLE=y
CONFIG_SSB_SDIOHOST=y
# CONFIG_SSB_SILENT is not set
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y
# CONFIG_SSB_DRIVER_GPIO is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
CONFIG_BCMA=m
CONFIG_BCMA_HOST_PCI_POSSIBLE=y
CONFIG_BCMA_HOST_PCI=y
# CONFIG_BCMA_HOST_SOC is not set
CONFIG_BCMA_DRIVER_PCI=y
CONFIG_BCMA_DRIVER_GMAC_CMN=y
# CONFIG_BCMA_DRIVER_GPIO is not set
# CONFIG_BCMA_DEBUG is not set
#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_BCM590XX is not set
# CONFIG_MFD_AXP20X_I2C is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9062 is not set
# CONFIG_MFD_DA9063 is not set
# CONFIG_MFD_DA9150 is not set
# CONFIG_MFD_DLN2 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_INTEL_QUARK_I2C_GPIO is not set
CONFIG_LPC_ICH=y
CONFIG_LPC_SCH=m
# CONFIG_INTEL_SOC_PMIC is not set
# CONFIG_INTEL_SOC_PMIC_CHTWC is not set
# CONFIG_MFD_INTEL_LPSS_ACPI is not set
# CONFIG_MFD_INTEL_LPSS_PCI is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX14577 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX77843 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_MENF21BMC is not set
# CONFIG_EZX_PCAP is not set
CONFIG_MFD_VIPERBOARD=m
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_UCB1400_CORE is not set
# CONFIG_MFD_RDC321X is not set
CONFIG_MFD_RTSX_PCI=m
# CONFIG_MFD_RT5033 is not set
# CONFIG_MFD_RTSX_USB is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
CONFIG_MFD_SM501=m
# CONFIG_MFD_SM501_GPIO is not set
# CONFIG_MFD_SKY81452 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP3943 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_TI_LMU is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65086 is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TI_LP873X is not set
# CONFIG_MFD_TPS65218 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TMIO is not set
CONFIG_MFD_VX855=m
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_REGULATOR is not set
CONFIG_MEDIA_SUPPORT=m
#
# Multimedia core support
#
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_RADIO_SUPPORT=y
# CONFIG_MEDIA_SDR_SUPPORT is not set
CONFIG_MEDIA_RC_SUPPORT=y
# CONFIG_MEDIA_CEC_SUPPORT is not set
# CONFIG_MEDIA_CONTROLLER is not set
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2=m
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEOBUF_VMALLOC=m
CONFIG_VIDEOBUF_DVB=m
CONFIG_VIDEOBUF2_CORE=m
CONFIG_VIDEOBUF2_MEMOPS=m
CONFIG_VIDEOBUF2_VMALLOC=m
CONFIG_VIDEOBUF2_DMA_SG=m
CONFIG_VIDEOBUF2_DVB=m
CONFIG_DVB_CORE=m
CONFIG_DVB_NET=y
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_MAX_ADAPTERS=8
CONFIG_DVB_DYNAMIC_MINORS=y
# CONFIG_DVB_DEMUX_SECTION_LOSS_LOG is not set
#
# Media drivers
#
CONFIG_RC_CORE=m
CONFIG_RC_MAP=m
CONFIG_RC_DECODERS=y
CONFIG_LIRC=m
CONFIG_IR_LIRC_CODEC=m
CONFIG_IR_NEC_DECODER=m
CONFIG_IR_RC5_DECODER=m
CONFIG_IR_RC6_DECODER=m
CONFIG_IR_JVC_DECODER=m
CONFIG_IR_SONY_DECODER=m
CONFIG_IR_SANYO_DECODER=m
CONFIG_IR_SHARP_DECODER=m
CONFIG_IR_MCE_KBD_DECODER=m
CONFIG_IR_XMP_DECODER=m
CONFIG_RC_DEVICES=y
CONFIG_RC_ATI_REMOTE=m
CONFIG_IR_ENE=m
# CONFIG_IR_HIX5HD2 is not set
CONFIG_IR_IMON=m
CONFIG_IR_MCEUSB=m
CONFIG_IR_ITE_CIR=m
CONFIG_IR_FINTEK=m
CONFIG_IR_NUVOTON=m
CONFIG_IR_REDRAT3=m
# CONFIG_IR_SPI is not set
CONFIG_IR_STREAMZAP=m
CONFIG_IR_WINBOND_CIR=m
# CONFIG_IR_IGORPLUGUSB is not set
CONFIG_IR_IGUANA=m
CONFIG_IR_TTUSBIR=m
# CONFIG_RC_LOOPBACK is not set
CONFIG_IR_GPIO_CIR=m
# CONFIG_IR_SERIAL is not set
# CONFIG_IR_SIR is not set
CONFIG_MEDIA_USB_SUPPORT=y
#
# Webcam devices
#
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_GSPCA=m
CONFIG_USB_M5602=m
CONFIG_USB_STV06XX=m
CONFIG_USB_GL860=m
CONFIG_USB_GSPCA_BENQ=m
CONFIG_USB_GSPCA_CONEX=m
CONFIG_USB_GSPCA_CPIA1=m
# CONFIG_USB_GSPCA_DTCS033 is not set
CONFIG_USB_GSPCA_ETOMS=m
CONFIG_USB_GSPCA_FINEPIX=m
CONFIG_USB_GSPCA_JEILINJ=m
CONFIG_USB_GSPCA_JL2005BCD=m
# CONFIG_USB_GSPCA_KINECT is not set
CONFIG_USB_GSPCA_KONICA=m
CONFIG_USB_GSPCA_MARS=m
CONFIG_USB_GSPCA_MR97310A=m
CONFIG_USB_GSPCA_NW80X=m
CONFIG_USB_GSPCA_OV519=m
CONFIG_USB_GSPCA_OV534=m
CONFIG_USB_GSPCA_OV534_9=m
CONFIG_USB_GSPCA_PAC207=m
CONFIG_USB_GSPCA_PAC7302=m
CONFIG_USB_GSPCA_PAC7311=m
CONFIG_USB_GSPCA_SE401=m
CONFIG_USB_GSPCA_SN9C2028=m
CONFIG_USB_GSPCA_SN9C20X=m
CONFIG_USB_GSPCA_SONIXB=m
CONFIG_USB_GSPCA_SONIXJ=m
CONFIG_USB_GSPCA_SPCA500=m
CONFIG_USB_GSPCA_SPCA501=m
CONFIG_USB_GSPCA_SPCA505=m
CONFIG_USB_GSPCA_SPCA506=m
CONFIG_USB_GSPCA_SPCA508=m
CONFIG_USB_GSPCA_SPCA561=m
CONFIG_USB_GSPCA_SPCA1528=m
CONFIG_USB_GSPCA_SQ905=m
CONFIG_USB_GSPCA_SQ905C=m
CONFIG_USB_GSPCA_SQ930X=m
CONFIG_USB_GSPCA_STK014=m
# CONFIG_USB_GSPCA_STK1135 is not set
CONFIG_USB_GSPCA_STV0680=m
CONFIG_USB_GSPCA_SUNPLUS=m
CONFIG_USB_GSPCA_T613=m
CONFIG_USB_GSPCA_TOPRO=m
# CONFIG_USB_GSPCA_TOUPTEK is not set
CONFIG_USB_GSPCA_TV8532=m
CONFIG_USB_GSPCA_VC032X=m
CONFIG_USB_GSPCA_VICAM=m
CONFIG_USB_GSPCA_XIRLINK_CIT=m
CONFIG_USB_GSPCA_ZC3XX=m
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set
CONFIG_USB_PWC_INPUT_EVDEV=y
# CONFIG_VIDEO_CPIA2 is not set
CONFIG_USB_ZR364XX=m
CONFIG_USB_STKWEBCAM=m
CONFIG_USB_S2255=m
# CONFIG_VIDEO_USBTV is not set
#
# Analog TV USB devices
#
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_SYSFS=y
CONFIG_VIDEO_PVRUSB2_DVB=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_HDPVR=m
CONFIG_VIDEO_USBVISION=m
# CONFIG_VIDEO_STK1160_COMMON is not set
# CONFIG_VIDEO_GO7007 is not set
#
# Analog/digital TV USB devices
#
CONFIG_VIDEO_AU0828=m
CONFIG_VIDEO_AU0828_V4L2=y
# CONFIG_VIDEO_AU0828_RC is not set
CONFIG_VIDEO_CX231XX=m
CONFIG_VIDEO_CX231XX_RC=y
CONFIG_VIDEO_CX231XX_ALSA=m
CONFIG_VIDEO_CX231XX_DVB=m
CONFIG_VIDEO_TM6000=m
CONFIG_VIDEO_TM6000_ALSA=m
CONFIG_VIDEO_TM6000_DVB=m
#
# Digital TV USB devices
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_DIB3000MC=m
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
CONFIG_DVB_USB_M920X=m
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_TTUSB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_USB_OPERA1=m
CONFIG_DVB_USB_AF9005=m
CONFIG_DVB_USB_AF9005_REMOTE=m
CONFIG_DVB_USB_PCTV452E=m
CONFIG_DVB_USB_DW2102=m
CONFIG_DVB_USB_CINERGY_T2=m
CONFIG_DVB_USB_DTV5100=m
CONFIG_DVB_USB_FRIIO=m
CONFIG_DVB_USB_AZ6027=m
CONFIG_DVB_USB_TECHNISAT_USB2=m
CONFIG_DVB_USB_V2=m
CONFIG_DVB_USB_AF9015=m
CONFIG_DVB_USB_AF9035=m
CONFIG_DVB_USB_ANYSEE=m
CONFIG_DVB_USB_AU6610=m
CONFIG_DVB_USB_AZ6007=m
CONFIG_DVB_USB_CE6230=m
CONFIG_DVB_USB_EC168=m
CONFIG_DVB_USB_GL861=m
CONFIG_DVB_USB_LME2510=m
CONFIG_DVB_USB_MXL111SF=m
CONFIG_DVB_USB_RTL28XXU=m
# CONFIG_DVB_USB_DVBSKY is not set
# CONFIG_DVB_USB_ZD1301 is not set
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_SMS_USB_DRV=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_USB_DEBUG is not set
# CONFIG_DVB_AS102 is not set
#
# Webcam, TV (analog/digital) USB devices
#
CONFIG_VIDEO_EM28XX=m
# CONFIG_VIDEO_EM28XX_V4L2 is not set
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_DVB=m
CONFIG_VIDEO_EM28XX_RC=m
CONFIG_MEDIA_PCI_SUPPORT=y
#
# Media capture support
#
# CONFIG_VIDEO_MEYE is not set
# CONFIG_VIDEO_SOLO6X10 is not set
# CONFIG_VIDEO_TW5864 is not set
# CONFIG_VIDEO_TW68 is not set
# CONFIG_VIDEO_TW686X is not set
# CONFIG_VIDEO_ZORAN is not set
#
# Media capture/analog TV support
#
CONFIG_VIDEO_IVTV=m
# CONFIG_VIDEO_IVTV_DEPRECATED_IOCTLS is not set
# CONFIG_VIDEO_IVTV_ALSA is not set
CONFIG_VIDEO_FB_IVTV=m
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DT3155 is not set
#
# Media capture/analog/hybrid TV support
#
CONFIG_VIDEO_CX18=m
CONFIG_VIDEO_CX18_ALSA=m
CONFIG_VIDEO_CX23885=m
CONFIG_MEDIA_ALTERA_CI=m
# CONFIG_VIDEO_CX25821 is not set
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_ENABLE_VP3054=y
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CX88_MPEG=m
CONFIG_VIDEO_BT848=m
CONFIG_DVB_BT8XX=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_RC=y
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_SAA7164=m
#
# Media digital TV PCI Adapters
#
CONFIG_DVB_AV7110_IR=y
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET_CORE=m
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
# CONFIG_DVB_B2C2_FLEXCOP_PCI_DEBUG is not set
CONFIG_DVB_PLUTO2=m
CONFIG_DVB_DM1105=m
CONFIG_DVB_PT1=m
# CONFIG_DVB_PT3 is not set
CONFIG_MANTIS_CORE=m
CONFIG_DVB_MANTIS=m
CONFIG_DVB_HOPPER=m
CONFIG_DVB_NGENE=m
CONFIG_DVB_DDBRIDGE=m
# CONFIG_DVB_SMIPCIE is not set
# CONFIG_DVB_NETUP_UNIDVB is not set
# CONFIG_V4L_PLATFORM_DRIVERS is not set
# CONFIG_V4L_MEM2MEM_DRIVERS is not set
# CONFIG_V4L_TEST_DRIVERS is not set
# CONFIG_DVB_PLATFORM_DRIVERS is not set
#
# Supported MMC/SDIO adapters
#
CONFIG_SMS_SDIO_DRV=m
CONFIG_RADIO_ADAPTERS=y
CONFIG_RADIO_TEA575X=m
# CONFIG_RADIO_SI470X is not set
# CONFIG_RADIO_SI4713 is not set
# CONFIG_USB_MR800 is not set
# CONFIG_USB_DSBR is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_SHARK is not set
# CONFIG_RADIO_SHARK2 is not set
# CONFIG_USB_KEENE is not set
# CONFIG_USB_RAREMONO is not set
# CONFIG_USB_MA901 is not set
# CONFIG_RADIO_TEA5764 is not set
# CONFIG_RADIO_SAA7706H is not set
# CONFIG_RADIO_TEF6862 is not set
# CONFIG_RADIO_WL1273 is not set
#
# Texas Instruments WL128x FM driver (ST based)
#
#
# Supported FireWire (IEEE 1394) Adapters
#
CONFIG_DVB_FIREDTV=m
CONFIG_DVB_FIREDTV_INPUT=y
CONFIG_MEDIA_COMMON_OPTIONS=y
#
# common driver options
#
CONFIG_VIDEO_CX2341X=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_CYPRESS_FIRMWARE=m
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_SMS_SIANO_MDTV=m
CONFIG_SMS_SIANO_RC=y
# CONFIG_SMS_SIANO_DEBUGFS is not set
#
# Media ancillary drivers (tuners, sensors, i2c, spi, frontends)
#
CONFIG_MEDIA_SUBDRV_AUTOSELECT=y
CONFIG_MEDIA_ATTACH=y
CONFIG_VIDEO_IR_I2C=m
#
# Audio decoders, processors and mixers
#
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_CS3308=m
CONFIG_VIDEO_CS5345=m
CONFIG_VIDEO_CS53L32A=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_WM8739=m
CONFIG_VIDEO_VP27SMPX=m
#
# RDS decoders
#
CONFIG_VIDEO_SAA6588=m
#
# Video decoders
#
CONFIG_VIDEO_SAA711X=m
#
# Video and audio decoders
#
CONFIG_VIDEO_SAA717X=m
CONFIG_VIDEO_CX25840=m
#
# Video encoders
#
CONFIG_VIDEO_SAA7127=m
#
# Camera sensor devices
#
#
# Flash devices
#
#
# Video improvement chips
#
CONFIG_VIDEO_UPD64031A=m
CONFIG_VIDEO_UPD64083=m
#
# Audio/Video compression chips
#
CONFIG_VIDEO_SAA6752HS=m
#
# SDR tuner chips
#
#
# Miscellaneous helper chips
#
CONFIG_VIDEO_M52790=m
#
# Sensors used on soc_camera driver
#
CONFIG_MEDIA_TUNER=m
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA827X=m
CONFIG_MEDIA_TUNER_TDA18271=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_MT2060=m
CONFIG_MEDIA_TUNER_MT2063=m
CONFIG_MEDIA_TUNER_MT2266=m
CONFIG_MEDIA_TUNER_MT2131=m
CONFIG_MEDIA_TUNER_QT1010=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_XC4000=m
CONFIG_MEDIA_TUNER_MXL5005S=m
CONFIG_MEDIA_TUNER_MXL5007T=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_MEDIA_TUNER_MAX2165=m
CONFIG_MEDIA_TUNER_TDA18218=m
CONFIG_MEDIA_TUNER_FC0011=m
CONFIG_MEDIA_TUNER_FC0012=m
CONFIG_MEDIA_TUNER_FC0013=m
CONFIG_MEDIA_TUNER_TDA18212=m
CONFIG_MEDIA_TUNER_E4000=m
CONFIG_MEDIA_TUNER_FC2580=m
CONFIG_MEDIA_TUNER_M88RS6000T=m
CONFIG_MEDIA_TUNER_TUA9001=m
CONFIG_MEDIA_TUNER_SI2157=m
CONFIG_MEDIA_TUNER_IT913X=m
CONFIG_MEDIA_TUNER_R820T=m
CONFIG_MEDIA_TUNER_QM1D1C0042=m
#
# Multistandard (satellite) frontends
#
CONFIG_DVB_STB0899=m
CONFIG_DVB_STB6100=m
CONFIG_DVB_STV090x=m
CONFIG_DVB_STV6110x=m
CONFIG_DVB_M88DS3103=m
#
# Multistandard (cable + terrestrial) frontends
#
CONFIG_DVB_DRXK=m
CONFIG_DVB_TDA18271C2DD=m
CONFIG_DVB_SI2165=m
CONFIG_DVB_MN88472=m
CONFIG_DVB_MN88473=m
#
# DVB-S (satellite) frontends
#
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_MT312=m
CONFIG_DVB_ZL10036=m
CONFIG_DVB_ZL10039=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_STV0288=m
CONFIG_DVB_STB6000=m
CONFIG_DVB_STV0299=m
CONFIG_DVB_STV6110=m
CONFIG_DVB_STV0900=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA10086=m
CONFIG_DVB_TDA8261=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_TUNER_ITD1000=m
CONFIG_DVB_TUNER_CX24113=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUA6100=m
CONFIG_DVB_CX24116=m
CONFIG_DVB_CX24117=m
CONFIG_DVB_CX24120=m
CONFIG_DVB_SI21XX=m
CONFIG_DVB_TS2020=m
CONFIG_DVB_DS3000=m
CONFIG_DVB_MB86A16=m
CONFIG_DVB_TDA10071=m
#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_DRXD=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m
CONFIG_DVB_TDA10048=m
CONFIG_DVB_AF9013=m
CONFIG_DVB_EC100=m
CONFIG_DVB_STV0367=m
CONFIG_DVB_CXD2820R=m
CONFIG_DVB_CXD2841ER=m
CONFIG_DVB_RTL2830=m
CONFIG_DVB_RTL2832=m
CONFIG_DVB_SI2168=m
# CONFIG_DVB_AS102_FE is not set
CONFIG_DVB_GP8PSK_FE=m
#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_TDA10023=m
CONFIG_DVB_STV0297=m
#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m
CONFIG_DVB_LGDT3305=m
CONFIG_DVB_LGDT3306A=m
CONFIG_DVB_LG2160=m
CONFIG_DVB_S5H1409=m
CONFIG_DVB_AU8522=m
CONFIG_DVB_AU8522_DTV=m
CONFIG_DVB_AU8522_V4L=m
CONFIG_DVB_S5H1411=m
#
# ISDB-T (terrestrial) frontends
#
CONFIG_DVB_S921=m
CONFIG_DVB_DIB8000=m
CONFIG_DVB_MB86A20S=m
#
# ISDB-S (satellite) & ISDB-T (terrestrial) frontends
#
CONFIG_DVB_TC90522=m
#
# Digital terrestrial only tuners/PLL
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TUNER_DIB0070=m
CONFIG_DVB_TUNER_DIB0090=m
#
# SEC control devices for DVB-S
#
CONFIG_DVB_DRX39XYJ=m
CONFIG_DVB_LNBP21=m
CONFIG_DVB_LNBP22=m
CONFIG_DVB_ISL6405=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_ISL6423=m
CONFIG_DVB_A8293=m
CONFIG_DVB_LGS8GXX=m
CONFIG_DVB_ATBM8830=m
CONFIG_DVB_TDA665x=m
CONFIG_DVB_IX2505V=m
CONFIG_DVB_M88RS2000=m
CONFIG_DVB_AF9033=m
#
# Tools to develop new frontends
#
# CONFIG_DVB_DUMMY_FE is not set
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_INTEL_GTT=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=64
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=m
CONFIG_DRM_MIPI_DSI=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
CONFIG_DRM_TTM=m
#
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
CONFIG_DRM_I2C_NXP_TDA998X=m
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_AMDGPU is not set
#
# ACP (Audio CoProcessor) Configuration
#
# CONFIG_DRM_NOUVEAU is not set
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_ALPHA_SUPPORT is not set
CONFIG_DRM_I915_CAPTURE_ERROR=y
CONFIG_DRM_I915_COMPRESS_ERROR=y
CONFIG_DRM_I915_USERPTR=y
# CONFIG_DRM_I915_GVT is not set
#
# drm/i915 Debugging
#
# CONFIG_DRM_I915_WERROR is not set
# CONFIG_DRM_I915_DEBUG is not set
# CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set
# CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set
# CONFIG_DRM_I915_SELFTEST is not set
# CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS is not set
# CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set
# CONFIG_DRM_VGEM is not set
CONFIG_DRM_VMWGFX=m
CONFIG_DRM_VMWGFX_FBCON=y
CONFIG_DRM_GMA500=m
CONFIG_DRM_GMA600=y
CONFIG_DRM_GMA3600=y
CONFIG_DRM_UDL=m
CONFIG_DRM_AST=m
CONFIG_DRM_MGAG200=m
CONFIG_DRM_CIRRUS_QEMU=m
CONFIG_DRM_QXL=m
# CONFIG_DRM_BOCHS is not set
# CONFIG_DRM_VIRTIO_GPU is not set
CONFIG_DRM_PANEL=y
#
# Display Panels
#
CONFIG_DRM_BRIDGE=y
CONFIG_DRM_PANEL_BRIDGE=y
#
# Display Interface Bridges
#
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
# CONFIG_DRM_HISI_HIBMC is not set
# CONFIG_DRM_TINYDRM is not set
# CONFIG_DRM_LEGACY is not set
# CONFIG_DRM_LIB_RANDOM is not set
#
# Frame buffer Devices
#
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_SM501 is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_XEN_FBDEV_FRONTEND is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
CONFIG_FB_HYPERV=m
# CONFIG_FB_SIMPLE is not set
# CONFIG_FB_SM712 is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_L4F00242T03 is not set
# CONFIG_LCD_LMS283GF05 is not set
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_ILI922X is not set
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
CONFIG_LCD_PLATFORM=m
# CONFIG_LCD_S6E63M0 is not set
# CONFIG_LCD_LD9040 is not set
# CONFIG_LCD_AMS369FG06 is not set
# CONFIG_LCD_LMS501KF03 is not set
# CONFIG_LCD_HX8357 is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_PWM is not set
CONFIG_BACKLIGHT_APPLE=m
# CONFIG_BACKLIGHT_PM8941_WLED is not set
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630A is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_GPIO is not set
# CONFIG_BACKLIGHT_LV5207LP is not set
# CONFIG_BACKLIGHT_BD6107 is not set
# CONFIG_BACKLIGHT_ARCXCNN is not set
# CONFIG_VGASTATE is not set
CONFIG_HDMI=y
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
# CONFIG_VGACON_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_SEQ_DEVICE=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_JACK=y
CONFIG_SND_JACK_INPUT_DEV=y
CONFIG_SND_OSSEMUL=y
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
CONFIG_SND_PCM_TIMER=y
CONFIG_SND_HRTIMER=m
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_MAX_CARDS=32
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_PROC_FS=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_SEQUENCER_OSS=m
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_SND_SEQ_MIDI_EVENT=m
CONFIG_SND_SEQ_MIDI_EMUL=m
CONFIG_SND_SEQ_VIRMIDI=m
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_OPL3_LIB_SEQ=m
# CONFIG_SND_OPL4_LIB_SEQ is not set
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCSP=m
CONFIG_SND_DUMMY=m
CONFIG_SND_ALOOP=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=5
CONFIG_SND_PCI=y
CONFIG_SND_AD1889=m
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
CONFIG_SND_ALI5451=m
CONFIG_SND_ASIHPI=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_OXYGEN_LIB=m
CONFIG_SND_OXYGEN=m
# CONFIG_SND_CS4281 is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CTXFI=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_INDIGOIOX=m
CONFIG_SND_INDIGODJX=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1_SEQ=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
CONFIG_SND_ES1968=m
CONFIG_SND_ES1968_INPUT=y
CONFIG_SND_ES1968_RADIO=y
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_LOLA=m
CONFIG_SND_LX6464ES=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MAESTRO3_INPUT=y
CONFIG_SND_MIXART=m
# CONFIG_SND_NM256 is not set
CONFIG_SND_PCXHR=m
# CONFIG_SND_RIPTIDE is not set
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
# CONFIG_SND_SONICVIBES is not set
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
# CONFIG_SND_YMFPCI is not set
#
# HD-Audio
#
CONFIG_SND_HDA=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=0
# CONFIG_SND_HDA_PATCH_LOADER is not set
CONFIG_SND_HDA_CODEC_REALTEK=m
CONFIG_SND_HDA_CODEC_ANALOG=m
CONFIG_SND_HDA_CODEC_SIGMATEL=m
CONFIG_SND_HDA_CODEC_VIA=m
CONFIG_SND_HDA_CODEC_HDMI=m
CONFIG_SND_HDA_CODEC_CIRRUS=m
CONFIG_SND_HDA_CODEC_CONEXANT=m
CONFIG_SND_HDA_CODEC_CA0110=m
CONFIG_SND_HDA_CODEC_CA0132=m
CONFIG_SND_HDA_CODEC_CA0132_DSP=y
CONFIG_SND_HDA_CODEC_CMEDIA=m
CONFIG_SND_HDA_CODEC_SI3054=m
CONFIG_SND_HDA_GENERIC=m
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDA_CORE=m
CONFIG_SND_HDA_DSP_LOADER=y
CONFIG_SND_HDA_I915=y
CONFIG_SND_HDA_PREALLOC_SIZE=512
CONFIG_SND_SPI=y
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_UA101=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
CONFIG_SND_USB_US122L=m
CONFIG_SND_USB_6FIRE=m
# CONFIG_SND_USB_HIFACE is not set
# CONFIG_SND_BCD2000 is not set
# CONFIG_SND_USB_POD is not set
# CONFIG_SND_USB_PODHD is not set
# CONFIG_SND_USB_TONEPORT is not set
# CONFIG_SND_USB_VARIAX is not set
CONFIG_SND_FIREWIRE=y
CONFIG_SND_FIREWIRE_LIB=m
# CONFIG_SND_DICE is not set
# CONFIG_SND_OXFW is not set
CONFIG_SND_ISIGHT=m
# CONFIG_SND_FIREWORKS is not set
# CONFIG_SND_BEBOB is not set
# CONFIG_SND_FIREWIRE_DIGI00X is not set
# CONFIG_SND_FIREWIRE_TASCAM is not set
# CONFIG_SND_FIREWIRE_MOTU is not set
# CONFIG_SND_FIREFACE is not set
# CONFIG_SND_SOC is not set
CONFIG_SND_X86=y
# CONFIG_HDMI_LPE_AUDIO is not set
CONFIG_SND_SYNTH_EMUX=m
CONFIG_AC97_BUS=m
#
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=m
CONFIG_HID_GENERIC=y
#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACCUTOUCH is not set
CONFIG_HID_ACRUX=m
# CONFIG_HID_ACRUX_FF is not set
CONFIG_HID_APPLE=y
CONFIG_HID_APPLEIR=m
# CONFIG_HID_ASUS is not set
CONFIG_HID_AUREAL=m
CONFIG_HID_BELKIN=y
# CONFIG_HID_BETOP_FF is not set
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
# CONFIG_HID_CORSAIR is not set
CONFIG_HID_PRODIKEYS=m
# CONFIG_HID_CMEDIA is not set
# CONFIG_HID_CP2112 is not set
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=m
# CONFIG_DRAGONRISE_FF is not set
# CONFIG_HID_EMS_FF is not set
CONFIG_HID_ELECOM=m
# CONFIG_HID_ELO is not set
CONFIG_HID_EZKEY=y
# CONFIG_HID_GEMBIRD is not set
# CONFIG_HID_GFRM is not set
CONFIG_HID_HOLTEK=m
# CONFIG_HOLTEK_FF is not set
# CONFIG_HID_GT683R is not set
CONFIG_HID_KEYTOUCH=m
CONFIG_HID_KYE=m
CONFIG_HID_UCLOGIC=m
CONFIG_HID_WALTOP=m
CONFIG_HID_GYRATION=m
CONFIG_HID_ICADE=m
CONFIG_HID_TWINHAN=m
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LCPOWER=m
CONFIG_HID_LED=m
# CONFIG_HID_LENOVO is not set
CONFIG_HID_LOGITECH=y
CONFIG_HID_LOGITECH_DJ=m
CONFIG_HID_LOGITECH_HIDPP=m
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set
CONFIG_HID_MAGICMOUSE=y
# CONFIG_HID_MAYFLASH is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_MULTITOUCH=m
# CONFIG_HID_NTI is not set
CONFIG_HID_NTRIG=y
CONFIG_HID_ORTEK=m
CONFIG_HID_PANTHERLORD=m
# CONFIG_PANTHERLORD_FF is not set
# CONFIG_HID_PENMOUNT is not set
CONFIG_HID_PETALYNX=m
CONFIG_HID_PICOLCD=m
CONFIG_HID_PICOLCD_FB=y
CONFIG_HID_PICOLCD_BACKLIGHT=y
CONFIG_HID_PICOLCD_LCD=y
CONFIG_HID_PICOLCD_LEDS=y
CONFIG_HID_PICOLCD_CIR=y
CONFIG_HID_PLANTRONICS=y
CONFIG_HID_PRIMAX=m
CONFIG_HID_ROCCAT=m
CONFIG_HID_SAITEK=m
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
# CONFIG_SONY_FF is not set
CONFIG_HID_SPEEDLINK=m
CONFIG_HID_STEELSERIES=m
CONFIG_HID_SUNPLUS=m
# CONFIG_HID_RMI is not set
CONFIG_HID_GREENASIA=m
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_HYPERV_MOUSE=m
CONFIG_HID_SMARTJOYPLUS=m
# CONFIG_SMARTJOYPLUS_FF is not set
CONFIG_HID_TIVO=m
CONFIG_HID_TOPSEED=m
CONFIG_HID_THINGM=m
CONFIG_HID_THRUSTMASTER=m
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_HID_UDRAW_PS3 is not set
CONFIG_HID_WACOM=m
CONFIG_HID_WIIMOTE=m
# CONFIG_HID_XINMO is not set
CONFIG_HID_ZEROPLUS=m
# CONFIG_ZEROPLUS_FF is not set
CONFIG_HID_ZYDACRON=m
# CONFIG_HID_SENSOR_HUB is not set
# CONFIG_HID_ALPS is not set
#
# USB HID support
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y
#
# I2C HID support
#
CONFIG_I2C_HID=m
#
# Intel ISH HID support
#
# CONFIG_INTEL_ISH_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_PCI=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_LEDS_TRIGGER_USBPORT is not set
CONFIG_USB_MON=y
CONFIG_USB_WUSB=m
CONFIG_USB_WUSB_CBAF=m
# CONFIG_USB_WUSB_CBAF_DEBUG is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
# CONFIG_USB_MAX3421_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PCI=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_U132_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
CONFIG_USB_HWA_HCD=m
# CONFIG_USB_HCD_BCMA is not set
# CONFIG_USB_HCD_SSB is not set
# CONFIG_USB_HCD_TEST_MODE is not set
#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_WDM=m
CONFIG_USB_TMC=m
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_REALTEK=m
CONFIG_REALTEK_AUTOPM=y
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m
CONFIG_USB_UAS=m
#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m
# CONFIG_USBIP_CORE is not set
# CONFIG_USB_MUSB_HDRC is not set
CONFIG_USB_DWC3=y
# CONFIG_USB_DWC3_HOST is not set
CONFIG_USB_DWC3_GADGET=y
# CONFIG_USB_DWC3_DUAL_ROLE is not set
#
# Platform Glue Driver Support
#
CONFIG_USB_DWC3_PCI=y
# CONFIG_USB_DWC2 is not set
# CONFIG_USB_CHIPIDEA is not set
# CONFIG_USB_ISP1760 is not set
#
# USB port drivers
#
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_SIMPLE is not set
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP210X=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
# CONFIG_USB_SERIAL_F81232 is not set
# CONFIG_USB_SERIAL_F8153X is not set
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
# CONFIG_USB_SERIAL_METRO is not set
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7715_PARPORT=y
CONFIG_USB_SERIAL_MOS7840=m
# CONFIG_USB_SERIAL_MXUPORT is not set
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_OTI6858=m
CONFIG_USB_SERIAL_QCAUX=m
CONFIG_USB_SERIAL_QUALCOMM=m
CONFIG_USB_SERIAL_SPCP8X5=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_SYMBOL=m
# CONFIG_USB_SERIAL_TI is not set
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_WWAN=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_SERIAL_OPTICON=m
CONFIG_USB_SERIAL_XSENS_MT=m
# CONFIG_USB_SERIAL_WISHBONE is not set
CONFIG_USB_SERIAL_SSU100=m
CONFIG_USB_SERIAL_QT2=m
# CONFIG_USB_SERIAL_UPD78F0730 is not set
CONFIG_USB_SERIAL_DEBUG=m
#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_SEVSEG=m
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
# CONFIG_USB_TRANCEVIBRATOR is not set
CONFIG_USB_IOWARRIOR=m
# CONFIG_USB_TEST is not set
# CONFIG_USB_EHSET_TEST_FIXTURE is not set
CONFIG_USB_ISIGHTFW=m
# CONFIG_USB_YUREX is not set
CONFIG_USB_EZUSB_FX2=m
# CONFIG_USB_HUB_USB251XB is not set
CONFIG_USB_HSIC_USB3503=m
# CONFIG_USB_HSIC_USB4604 is not set
# CONFIG_USB_LINK_LAYER_TEST is not set
# CONFIG_USB_CHAOSKEY is not set
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m
#
# USB Physical Layer drivers
#
CONFIG_USB_PHY=y
CONFIG_NOP_USB_XCEIV=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
#
# USB Peripheral Controller
#
# CONFIG_USB_FOTG210_UDC is not set
# CONFIG_USB_GR_UDC is not set
# CONFIG_USB_R8A66597 is not set
# CONFIG_USB_PXA27X is not set
# CONFIG_USB_MV_UDC is not set
# CONFIG_USB_MV_U3D is not set
# CONFIG_USB_M66592 is not set
# CONFIG_USB_BDC_UDC is not set
# CONFIG_USB_AMD5536UDC is not set
# CONFIG_USB_NET2272 is not set
# CONFIG_USB_NET2280 is not set
# CONFIG_USB_GOKU is not set
# CONFIG_USB_EG20T is not set
# CONFIG_USB_DUMMY_HCD is not set
CONFIG_USB_LIBCOMPOSITE=m
CONFIG_USB_F_MASS_STORAGE=m
# CONFIG_USB_CONFIGFS is not set
# CONFIG_USB_ZERO is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_G_NCM is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FUNCTIONFS is not set
CONFIG_USB_MASS_STORAGE=m
# CONFIG_USB_GADGET_TARGET is not set
# CONFIG_USB_G_SERIAL is not set
# CONFIG_USB_MIDI_GADGET is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
# CONFIG_USB_G_ACM_MS is not set
# CONFIG_USB_G_MULTI is not set
# CONFIG_USB_G_HID is not set
# CONFIG_USB_G_DBGP is not set
# CONFIG_USB_G_WEBCAM is not set
#
# USB Power Delivery and Type-C drivers
#
# CONFIG_TYPEC_UCSI is not set
# CONFIG_USB_LED_TRIG is not set
# CONFIG_USB_ULPI_BUS is not set
CONFIG_UWB=m
CONFIG_UWB_HWA=m
CONFIG_UWB_WHCI=m
CONFIG_UWB_I1480U=m
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_SDIO_UART=m
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=y
CONFIG_MMC_SDHCI_ACPI=m
CONFIG_MMC_SDHCI_PLTFM=m
# CONFIG_MMC_WBSD is not set
CONFIG_MMC_TIFM_SD=m
# CONFIG_MMC_SPI is not set
CONFIG_MMC_CB710=m
CONFIG_MMC_VIA_SDMMC=m
CONFIG_MMC_VUB300=m
CONFIG_MMC_USHC=m
# CONFIG_MMC_USDHI6ROL0 is not set
CONFIG_MMC_REALTEK_PCI=m
# CONFIG_MMC_TOSHIBA_PCI is not set
# CONFIG_MMC_MTK is not set
# CONFIG_MMC_SDHCI_XENON is not set
CONFIG_MEMSTICK=m
# CONFIG_MEMSTICK_DEBUG is not set
#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m
# CONFIG_MS_BLOCK is not set
#
# MemoryStick Host Controller Drivers
#
CONFIG_MEMSTICK_TIFM_MS=m
CONFIG_MEMSTICK_JMICRON_38X=m
CONFIG_MEMSTICK_R592=m
CONFIG_MEMSTICK_REALTEK_PCI=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
# CONFIG_LEDS_CLASS_FLASH is not set
# CONFIG_LEDS_BRIGHTNESS_HW_CHANGED is not set
#
# LED drivers
#
CONFIG_LEDS_LM3530=m
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
CONFIG_LEDS_LP3944=m
# CONFIG_LEDS_LP3952 is not set
CONFIG_LEDS_LP55XX_COMMON=m
CONFIG_LEDS_LP5521=m
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_LP5562=m
# CONFIG_LEDS_LP8501 is not set
# CONFIG_LEDS_LP8860 is not set
CONFIG_LEDS_CLEVO_MAIL=m
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA963X is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_PWM is not set
# CONFIG_LEDS_BD2802 is not set
CONFIG_LEDS_INTEL_SS4200=m
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_TLC591XX is not set
# CONFIG_LEDS_LM355x is not set
#
# LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)
#
CONFIG_LEDS_BLINKM=m
# CONFIG_LEDS_MLXCPLD is not set
# CONFIG_LEDS_USER is not set
# CONFIG_LEDS_NIC78BX is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
# CONFIG_LEDS_TRIGGER_DISK is not set
# CONFIG_LEDS_TRIGGER_MTD is not set
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
# CONFIG_LEDS_TRIGGER_CPU is not set
# CONFIG_LEDS_TRIGGER_GPIO is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_LEDS_TRIGGER_TRANSIENT=m
CONFIG_LEDS_TRIGGER_CAMERA=m
# CONFIG_LEDS_TRIGGER_PANIC is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=m
# CONFIG_EDAC_GHES is not set
CONFIG_EDAC_AMD64=m
# CONFIG_EDAC_AMD64_ERROR_INJECTION is not set
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82975X=m
CONFIG_EDAC_I3000=m
CONFIG_EDAC_I3200=m
# CONFIG_EDAC_IE31200 is not set
CONFIG_EDAC_X38=m
CONFIG_EDAC_I5400=m
CONFIG_EDAC_I7CORE=m
CONFIG_EDAC_I5000=m
CONFIG_EDAC_I5100=m
CONFIG_EDAC_I7300=m
CONFIG_EDAC_SBRIDGE=m
# CONFIG_EDAC_SKX is not set
# CONFIG_EDAC_PND2 is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_SYSTOHC is not set
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_ABB5ZES3 is not set
# CONFIG_RTC_DRV_ABX80X is not set
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1307_HWMON=y
# CONFIG_RTC_DRV_DS1307_CENTURY is not set
CONFIG_RTC_DRV_DS1374=m
# CONFIG_RTC_DRV_DS1374_WDT is not set
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_ISL12022=m
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8523=m
# CONFIG_RTC_DRV_PCF85063 is not set
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
CONFIG_RTC_DRV_M41T80_WDT=y
CONFIG_RTC_DRV_BQ32K=m
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=m
# CONFIG_RTC_DRV_RX8010 is not set
CONFIG_RTC_DRV_RX8581=m
CONFIG_RTC_DRV_RX8025=m
CONFIG_RTC_DRV_EM3027=m
# CONFIG_RTC_DRV_RV8803 is not set
#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1302 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1343 is not set
# CONFIG_RTC_DRV_DS1347 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6916 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RX4581 is not set
# CONFIG_RTC_DRV_RX6110 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_MCP795 is not set
CONFIG_RTC_I2C_AND_SPI=y
#
# SPI and I2C RTC drivers
#
CONFIG_RTC_DRV_DS3232=m
# CONFIG_RTC_DRV_PCF2127 is not set
CONFIG_RTC_DRV_RV3029C2=m
CONFIG_RTC_DRV_RV3029_HWMON=y
#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1286=m
CONFIG_RTC_DRV_DS1511=m
CONFIG_RTC_DRV_DS1553=m
# CONFIG_RTC_DRV_DS1685_FAMILY is not set
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_DS2404=m
CONFIG_RTC_DRV_STK17TA8=m
# CONFIG_RTC_DRV_M48T86 is not set
CONFIG_RTC_DRV_M48T35=m
CONFIG_RTC_DRV_M48T59=m
CONFIG_RTC_DRV_MSM6242=m
CONFIG_RTC_DRV_BQ4802=m
CONFIG_RTC_DRV_RP5C01=m
CONFIG_RTC_DRV_V3020=m
#
# on-CPU RTC drivers
#
#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set
#
# DMA Devices
#
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_ACPI=y
# CONFIG_INTEL_IDMA64 is not set
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_QCOM_HIDMA_MGMT is not set
# CONFIG_QCOM_HIDMA is not set
CONFIG_DW_DMAC_CORE=y
CONFIG_DW_DMAC=m
CONFIG_DW_DMAC_PCI=y
CONFIG_HSU_DMA=y
#
# DMA Clients
#
CONFIG_ASYNC_TX_DMA=y
CONFIG_DMATEST=m
CONFIG_DMA_ENGINE_RAID=y
#
# DMABUF options
#
CONFIG_SYNC_FILE=y
CONFIG_SW_SYNC=y
CONFIG_AUXDISPLAY=y
# CONFIG_HD44780 is not set
CONFIG_KS0108=m
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
CONFIG_CFAG12864B=m
CONFIG_CFAG12864B_RATE=20
# CONFIG_IMG_ASCII_LCD is not set
# CONFIG_PANEL is not set
CONFIG_UIO=m
CONFIG_UIO_CIF=m
CONFIG_UIO_PDRV_GENIRQ=m
# CONFIG_UIO_DMEM_GENIRQ is not set
CONFIG_UIO_AEC=m
CONFIG_UIO_SERCOS3=m
CONFIG_UIO_PCI_GENERIC=m
# CONFIG_UIO_NETX is not set
# CONFIG_UIO_PRUSS is not set
# CONFIG_UIO_MF624 is not set
# CONFIG_UIO_HV_GENERIC is not set
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_VFIO_PCI=m
# CONFIG_VFIO_PCI_VGA is not set
CONFIG_VFIO_PCI_MMAP=y
CONFIG_VFIO_PCI_INTX=y
CONFIG_VFIO_PCI_IGD=y
# CONFIG_VFIO_MDEV is not set
CONFIG_IRQ_BYPASS_MANAGER=m
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y
#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_VIRTIO_BALLOON=y
# CONFIG_VIRTIO_INPUT is not set
# CONFIG_VIRTIO_MMIO is not set
#
# Microsoft Hyper-V guest support
#
CONFIG_HYPERV=m
CONFIG_HYPERV_TSCPAGE=y
CONFIG_HYPERV_UTILS=m
CONFIG_HYPERV_BALLOON=m
#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
# CONFIG_XEN_SELFBALLOONING is not set
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=m
CONFIG_XEN_PCIDEV_BACKEND=m
# CONFIG_XEN_SCSI_BACKEND is not set
CONFIG_XEN_PRIVCMD=m
CONFIG_XEN_ACPI_PROCESSOR=m
# CONFIG_XEN_MCE_LOG is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y
CONFIG_XEN_ACPI=y
CONFIG_XEN_SYMS=y
CONFIG_XEN_HAVE_VPMU=y
CONFIG_STAGING=y
# CONFIG_PRISM2_USB is not set
# CONFIG_COMEDI is not set
# CONFIG_RTL8192U is not set
CONFIG_RTLLIB=m
CONFIG_RTLLIB_CRYPTO_CCMP=m
CONFIG_RTLLIB_CRYPTO_TKIP=m
CONFIG_RTLLIB_CRYPTO_WEP=m
CONFIG_RTL8192E=m
# CONFIG_RTL8723BS is not set
CONFIG_R8712U=m
# CONFIG_R8188EU is not set
# CONFIG_RTS5208 is not set
# CONFIG_VT6655 is not set
# CONFIG_VT6656 is not set
# CONFIG_FB_SM750 is not set
# CONFIG_FB_XGI is not set
#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_STAGING_MEDIA is not set
#
# Android
#
# CONFIG_LTE_GDM724X is not set
CONFIG_FIREWIRE_SERIAL=m
CONFIG_FWTTY_MAX_TOTAL_PORTS=64
CONFIG_FWTTY_MAX_CARD_PORTS=32
# CONFIG_LNET is not set
# CONFIG_DGNC is not set
# CONFIG_GS_FPGABOOT is not set
# CONFIG_CRYPTO_SKEIN is not set
# CONFIG_UNISYSSPAR is not set
# CONFIG_FB_TFT is not set
# CONFIG_WILC1000_SDIO is not set
# CONFIG_WILC1000_SPI is not set
# CONFIG_MOST is not set
# CONFIG_KS7010 is not set
# CONFIG_GREYBUS is not set
#
# USB Power Delivery and Type-C drivers
#
# CONFIG_TYPEC_TCPM is not set
CONFIG_X86_PLATFORM_DEVICES=y
CONFIG_ACER_WMI=m
CONFIG_ACERHDF=m
# CONFIG_ALIENWARE_WMI is not set
CONFIG_ASUS_LAPTOP=m
# CONFIG_DELL_LAPTOP is not set
# CONFIG_DELL_WMI is not set
CONFIG_DELL_WMI_AIO=m
# CONFIG_DELL_WMI_LED is not set
# CONFIG_DELL_SMO8800 is not set
# CONFIG_DELL_RBTN is not set
CONFIG_FUJITSU_LAPTOP=m
CONFIG_FUJITSU_TABLET=m
CONFIG_AMILO_RFKILL=m
CONFIG_HP_ACCEL=m
# CONFIG_HP_WIRELESS is not set
CONFIG_HP_WMI=m
CONFIG_MSI_LAPTOP=m
CONFIG_PANASONIC_LAPTOP=m
CONFIG_COMPAL_LAPTOP=m
CONFIG_SONY_LAPTOP=m
CONFIG_SONYPI_COMPAT=y
CONFIG_IDEAPAD_LAPTOP=m
# CONFIG_SURFACE3_WMI is not set
CONFIG_THINKPAD_ACPI=m
CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
CONFIG_THINKPAD_ACPI_VIDEO=y
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
CONFIG_SENSORS_HDAPS=m
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=m
CONFIG_ASUS_WMI=m
CONFIG_ASUS_NB_WMI=m
CONFIG_EEEPC_WMI=m
# CONFIG_ASUS_WIRELESS is not set
CONFIG_ACPI_WMI=m
CONFIG_WMI_BMOF=m
CONFIG_MSI_WMI=m
# CONFIG_PEAQ_WMI is not set
CONFIG_TOPSTAR_LAPTOP=m
CONFIG_TOSHIBA_BT_RFKILL=m
# CONFIG_TOSHIBA_HAPS is not set
# CONFIG_TOSHIBA_WMI is not set
CONFIG_ACPI_CMPC=m
# CONFIG_INTEL_CHT_INT33FE is not set
# CONFIG_INTEL_INT0002_VGPIO is not set
# CONFIG_INTEL_HID_EVENT is not set
# CONFIG_INTEL_VBTN is not set
CONFIG_INTEL_IPS=m
# CONFIG_INTEL_PMC_CORE is not set
# CONFIG_IBM_RTL is not set
CONFIG_SAMSUNG_LAPTOP=m
CONFIG_MXM_WMI=m
CONFIG_INTEL_OAKTRAIL=m
CONFIG_SAMSUNG_Q10=m
CONFIG_APPLE_GMUX=m
# CONFIG_INTEL_RST is not set
# CONFIG_INTEL_SMARTCONNECT is not set
CONFIG_PVPANIC=y
# CONFIG_INTEL_PMC_IPC is not set
# CONFIG_SURFACE_PRO3_BUTTON is not set
# CONFIG_INTEL_PUNIT_IPC is not set
# CONFIG_MLX_PLATFORM is not set
# CONFIG_MLX_CPLD_PLATFORM is not set
# CONFIG_INTEL_TURBO_MAX_3 is not set
CONFIG_PMC_ATOM=y
# CONFIG_CHROME_PLATFORMS is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y
#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_CDCE706 is not set
# CONFIG_COMMON_CLK_CS2000_CP is not set
# CONFIG_COMMON_CLK_NXP is not set
# CONFIG_COMMON_CLK_PWM is not set
# CONFIG_COMMON_CLK_PXA is not set
# CONFIG_COMMON_CLK_PIC32 is not set
# CONFIG_HWSPINLOCK is not set
#
# Clock Source drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_ATMEL_PIT is not set
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
CONFIG_MAILBOX=y
CONFIG_PCC=y
# CONFIG_ALTERA_MBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
#
# Generic IOMMU Pagetable Support
#
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_V2=m
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_SVM is not set
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
CONFIG_IRQ_REMAP=y
#
# Remoteproc drivers
#
# CONFIG_REMOTEPROC is not set
#
# Rpmsg drivers
#
# CONFIG_RPMSG_QCOM_GLINK_RPM is not set
#
# SOC (System On Chip) specific Drivers
#
#
# Broadcom SoC drivers
#
#
# i.MX SoC drivers
#
# CONFIG_SUNXI_SRAM is not set
# CONFIG_SOC_TI is not set
# CONFIG_SOC_ZTE is not set
CONFIG_PM_DEVFREQ=y
#
# DEVFREQ Governors
#
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=m
# CONFIG_DEVFREQ_GOV_PERFORMANCE is not set
# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
# CONFIG_DEVFREQ_GOV_USERSPACE is not set
# CONFIG_DEVFREQ_GOV_PASSIVE is not set
#
# DEVFREQ Drivers
#
# CONFIG_PM_DEVFREQ_EVENT is not set
CONFIG_EXTCON=y
#
# Extcon Device Drivers
#
# CONFIG_EXTCON_GPIO is not set
# CONFIG_EXTCON_INTEL_INT3496 is not set
# CONFIG_EXTCON_MAX3355 is not set
# CONFIG_EXTCON_RT8973A is not set
# CONFIG_EXTCON_SM5502 is not set
# CONFIG_EXTCON_USB_GPIO is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
CONFIG_NTB=m
# CONFIG_NTB_AMD is not set
# CONFIG_NTB_INTEL is not set
# CONFIG_NTB_PINGPONG is not set
# CONFIG_NTB_TOOL is not set
# CONFIG_NTB_PERF is not set
# CONFIG_NTB_TRANSPORT is not set
# CONFIG_VME_BUS is not set
CONFIG_PWM=y
CONFIG_PWM_SYSFS=y
# CONFIG_PWM_LPSS_PCI is not set
# CONFIG_PWM_LPSS_PLATFORM is not set
# CONFIG_PWM_PCA9685 is not set
CONFIG_ARM_GIC_MAX_NR=1
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set
#
# PHY Subsystem
#
CONFIG_GENERIC_PHY=y
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
CONFIG_POWERCAP=y
CONFIG_INTEL_RAPL=m
# CONFIG_MCB is not set
#
# Performance monitor support
#
CONFIG_RAS=y
# CONFIG_RAS_CEC is not set
# CONFIG_THUNDERBOLT is not set
#
# Android
#
# CONFIG_ANDROID is not set
CONFIG_LIBNVDIMM=m
CONFIG_BLK_DEV_PMEM=m
CONFIG_ND_BLK=m
CONFIG_ND_CLAIM=y
CONFIG_ND_BTT=m
CONFIG_BTT=y
CONFIG_ND_PFN=m
CONFIG_NVDIMM_PFN=y
CONFIG_NVDIMM_DAX=y
CONFIG_DAX=y
CONFIG_DEV_DAX=m
CONFIG_DEV_DAX_PMEM=m
CONFIG_NVMEM=m
# CONFIG_STM is not set
# CONFIG_INTEL_TH is not set
#
# FPGA Configuration Support
#
# CONFIG_FPGA is not set
#
# FSI support
#
# CONFIG_FSI is not set
# CONFIG_MULTIPLEXER is not set
#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
CONFIG_DMI_SYSFS=y
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m
# CONFIG_FW_CFG_SYSFS is not set
# CONFIG_GOOGLE_FIRMWARE is not set
#
# EFI (Extensible Firmware Interface) Support
#
CONFIG_EFI_VARS=y
CONFIG_EFI_ESRT=y
CONFIG_EFI_VARS_PSTORE=y
CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y
CONFIG_EFI_RUNTIME_MAP=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_RUNTIME_WRAPPERS=y
# CONFIG_EFI_BOOTLOADER_CONTROL is not set
# CONFIG_EFI_CAPSULE_LOADER is not set
# CONFIG_EFI_TEST is not set
# CONFIG_APPLE_PROPERTIES is not set
CONFIG_UEFI_CPER=y
# CONFIG_EFI_DEV_PATH_PARSER is not set
#
# Tegra firmware driver
#
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_FS_IOMAP=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_DLM=y
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_FS_O2CB=m
CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m
CONFIG_OCFS2_FS_STATS=y
CONFIG_OCFS2_DEBUG_MASKLOG=y
# CONFIG_OCFS2_DEBUG_FS is not set
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
# CONFIG_NILFS2_FS is not set
CONFIG_F2FS_FS=m
CONFIG_F2FS_STAT_FS=y
CONFIG_F2FS_FS_XATTR=y
CONFIG_F2FS_FS_POSIX_ACL=y
# CONFIG_F2FS_FS_SECURITY is not set
# CONFIG_F2FS_CHECK_FS is not set
# CONFIG_F2FS_FS_ENCRYPTION is not set
# CONFIG_F2FS_IO_TRACE is not set
# CONFIG_F2FS_FAULT_INJECTION is not set
CONFIG_FS_DAX=y
CONFIG_FS_DAX_PMD=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
# CONFIG_EXPORTFS_BLOCK_OPS is not set
CONFIG_FILE_LOCKING=y
CONFIG_MANDATORY_FILE_LOCKING=y
# CONFIG_FS_ENCRYPTION is not set
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_OVERLAY_FS=m
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_CHILDREN=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ORANGEFS_FS is not set
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_UBIFS_FS is not set
CONFIG_CRAMFS=m
CONFIG_SQUASHFS=m
CONFIG_SQUASHFS_FILE_CACHE=y
# CONFIG_SQUASHFS_FILE_DIRECT is not set
CONFIG_SQUASHFS_DECOMP_SINGLE=y
# CONFIG_SQUASHFS_DECOMP_MULTI is not set
# CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
# CONFIG_SQUASHFS_LZ4 is not set
CONFIG_SQUASHFS_LZO=y
CONFIG_SQUASHFS_XZ=y
# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
# CONFIG_SQUASHFS_EMBEDDED is not set
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
CONFIG_PSTORE_ZLIB_COMPRESS=y
# CONFIG_PSTORE_LZO_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
# CONFIG_PSTORE_FTRACE is not set
CONFIG_PSTORE_RAM=m
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_EXOFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
# CONFIG_NFS_V2 is not set
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=m
# CONFIG_NFS_SWAP is not set
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_PNFS_FILE_LAYOUT=m
CONFIG_PNFS_BLOCK=m
CONFIG_PNFS_FLEXFILE_LAYOUT=m
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
# CONFIG_NFS_V4_1_MIGRATION is not set
CONFIG_NFS_V4_SECURITY_LABEL=y
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFS_DEBUG=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
# CONFIG_NFSD_BLOCKLAYOUT is not set
# CONFIG_NFSD_SCSILAYOUT is not set
# CONFIG_NFSD_FLEXFILELAYOUT is not set
CONFIG_NFSD_V4_SECURITY_LABEL=y
# CONFIG_NFSD_FAULT_INJECTION is not set
CONFIG_GRACE_PERIOD=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_BACKCHANNEL=y
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_SUNRPC_DEBUG=y
# CONFIG_CEPH_FS is not set
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_CIFS_ACL=y
CONFIG_CIFS_DEBUG=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_DEBUG_DUMP_KEYS is not set
CONFIG_CIFS_DFS_UPCALL=y
CONFIG_CIFS_SMB2=y
# CONFIG_CIFS_SMB311 is not set
# CONFIG_CIFS_FSCACHE is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=y
CONFIG_9P_FS_POSIX_ACL=y
# CONFIG_9P_FS_SECURITY is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_MAC_ROMAN=m
CONFIG_NLS_MAC_CELTIC=m
CONFIG_NLS_MAC_CENTEURO=m
CONFIG_NLS_MAC_CROATIAN=m
CONFIG_NLS_MAC_CYRILLIC=m
CONFIG_NLS_MAC_GAELIC=m
CONFIG_NLS_MAC_GREEK=m
CONFIG_NLS_MAC_ICELAND=m
CONFIG_NLS_MAC_INUIT=m
CONFIG_NLS_MAC_ROMANIAN=m
CONFIG_NLS_MAC_TURKISH=m
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_DYNAMIC_DEBUG=y
#
# Compile-time checks and compiler options
#
# CONFIG_DEBUG_INFO is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_STACK_VALIDATION is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_MAGIC_SYSRQ_SERIAL=y
CONFIG_DEBUG_KERNEL=y
#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_PAGE_POISONING is not set
# CONFIG_DEBUG_PAGE_REF is not set
CONFIG_DEBUG_RODATA_TEST=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_MEMORY_NOTIFIER_ERROR_INJECT=m
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_HAVE_ARCH_KASAN=y
# CONFIG_KASAN is not set
CONFIG_ARCH_HAS_KCOV=y
# CONFIG_KCOV is not set
CONFIG_DEBUG_SHIRQ=y
#
# Debug Lockups and Hangs
#
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_WQ_WATCHDOG is not set
CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_ON_OOPS_VALUE=1
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHED_INFO=y
CONFIG_SCHEDSTATS=y
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_TIMEKEEPING is not set
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_LOCK_TORTURE_TEST=m
# CONFIG_WW_MUTEX_SELFTEST is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_PI_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
CONFIG_TORTURE_TEST=m
# CONFIG_RCU_PERF_TEST is not set
CONFIG_RCU_TORTURE_TEST=m
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set
CONFIG_NOTIFIER_ERROR_INJECTION=m
CONFIG_PM_NOTIFIER_ERROR_INJECT=m
# CONFIG_NETDEV_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
CONFIG_SCHED_TRACER=y
# CONFIG_HWLAT_TRACER is not set
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENTS=y
CONFIG_UPROBE_EVENTS=y
CONFIG_BPF_EVENTS=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
CONFIG_TRACING_MAP=y
CONFIG_HIST_TRIGGERS=y
# CONFIG_TRACEPOINT_BENCHMARK is not set
CONFIG_RING_BUFFER_BENCHMARK=m
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_TRACE_EVAL_MAP_FILE is not set
CONFIG_TRACING_EVENTS_GPIO=y
#
# Runtime Testing
#
CONFIG_LKDTM=m
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_TEST_SORT is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_RBTREE_TEST=m
CONFIG_INTERVAL_TREE_TEST=m
CONFIG_PERCPU_TEST=m
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_ASYNC_RAID6_TEST=m
# CONFIG_TEST_HEXDUMP is not set
# CONFIG_TEST_STRING_HELPERS is not set
CONFIG_TEST_KSTRTOX=m
CONFIG_TEST_PRINTF=m
CONFIG_TEST_BITMAP=m
# CONFIG_TEST_UUID is not set
# CONFIG_TEST_RHASHTABLE is not set
# CONFIG_TEST_HASH is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_TEST_LKM=m
CONFIG_TEST_USER_COPY=m
CONFIG_TEST_BPF=m
CONFIG_TEST_FIRMWARE=m
CONFIG_TEST_UDELAY=m
# CONFIG_MEMTEST is not set
CONFIG_TEST_STATIC_KEYS=m
# CONFIG_BUG_ON_DATA_CORRUPTION is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
# CONFIG_ARCH_WANTS_UBSAN_NO_NULL is not set
# CONFIG_UBSAN is not set
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
CONFIG_STRICT_DEVMEM=y
# CONFIG_IO_STRICT_DEVMEM is not set
CONFIG_EARLY_PRINTK_USB=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
# CONFIG_EARLY_PRINTK_EFI is not set
# CONFIG_EARLY_PRINTK_USB_XDBC is not set
# CONFIG_X86_PTDUMP_CORE is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_EFI_PGT_DUMP is not set
# CONFIG_DEBUG_WX is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_TLBFLUSH is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_X86_DECODER_SELFTEST=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_ENTRY is not set
# CONFIG_DEBUG_NMI_SELFTEST is not set
CONFIG_X86_DEBUG_FPU=y
# CONFIG_PUNIT_ATOM_DEBUG is not set
#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_COMPAT=y
CONFIG_PERSISTENT_KEYRINGS=y
CONFIG_BIG_KEYS=y
CONFIG_TRUSTED_KEYS=y
CONFIG_ENCRYPTED_KEYS=y
# CONFIG_KEY_DH_OPERATIONS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_WRITABLE_HOOKS=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_INTEL_TXT=y
CONFIG_LSM_MMAP_MIN_ADDR=65535
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
# CONFIG_HARDENED_USERCOPY is not set
# CONFIG_STATIC_USERMODEHELPER is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_LOADPIN is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
CONFIG_INTEGRITY_TRUSTED_KEYRING=y
CONFIG_INTEGRITY_AUDIT=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_LSM_RULES=y
# CONFIG_IMA_TEMPLATE is not set
CONFIG_IMA_NG_TEMPLATE=y
# CONFIG_IMA_SIG_TEMPLATE is not set
CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
CONFIG_IMA_DEFAULT_HASH_SHA1=y
# CONFIG_IMA_DEFAULT_HASH_SHA256 is not set
CONFIG_IMA_DEFAULT_HASH="sha1"
# CONFIG_IMA_WRITE_POLICY is not set
# CONFIG_IMA_READ_POLICY is not set
CONFIG_IMA_APPRAISE=y
CONFIG_IMA_APPRAISE_BOOTPARAM=y
CONFIG_IMA_TRUSTED_KEYRING=y
# CONFIG_IMA_BLACKLIST_KEYRING is not set
# CONFIG_IMA_LOAD_X509 is not set
CONFIG_EVM=y
CONFIG_EVM_ATTR_FSUUID=y
# CONFIG_EVM_LOAD_X509 is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_KPP2=y
CONFIG_CRYPTO_ACOMP2=y
CONFIG_CRYPTO_RSA=y
# CONFIG_CRYPTO_DH is not set
# CONFIG_CRYPTO_ECDH is not set
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
# CONFIG_CRYPTO_MCRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=m
CONFIG_CRYPTO_SIMD=m
CONFIG_CRYPTO_GLUE_HELPER_X86=m
CONFIG_CRYPTO_ENGINE=m
#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
CONFIG_CRYPTO_SEQIV=y
CONFIG_CRYPTO_ECHAINIV=m
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
# CONFIG_CRYPTO_KEYWRAP is not set
#
# Hash modes
#
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRYPTO_GHASH=m
# CONFIG_CRYPTO_POLY1305 is not set
# CONFIG_CRYPTO_POLY1305_X86_64 is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=m
CONFIG_CRYPTO_SHA256_SSSE3=m
CONFIG_CRYPTO_SHA512_SSSE3=m
# CONFIG_CRYPTO_SHA1_MB is not set
# CONFIG_CRYPTO_SHA256_MB is not set
# CONFIG_CRYPTO_SHA512_MB is not set
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_SHA3 is not set
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_TI is not set
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_BLOWFISH_X86_64=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_CAST6_AVX_X86_64=m
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_DES3_EDE_X86_64 is not set
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
# CONFIG_CRYPTO_CHACHA20 is not set
# CONFIG_CRYPTO_CHACHA20_X86_64 is not set
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_842 is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set
#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_DRBG_HMAC=y
# CONFIG_CRYPTO_DRBG_HASH is not set
# CONFIG_CRYPTO_DRBG_CTR is not set
CONFIG_CRYPTO_DRBG=y
CONFIG_CRYPTO_JITTERENTROPY=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
# CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC is not set
# CONFIG_CRYPTO_DEV_CCP is not set
# CONFIG_CRYPTO_DEV_QAT_DH895xCC is not set
# CONFIG_CRYPTO_DEV_QAT_C3XXX is not set
# CONFIG_CRYPTO_DEV_QAT_C62X is not set
# CONFIG_CRYPTO_DEV_QAT_DH895xCCVF is not set
# CONFIG_CRYPTO_DEV_QAT_C3XXXVF is not set
# CONFIG_CRYPTO_DEV_QAT_C62XVF is not set
# CONFIG_CRYPTO_DEV_NITROX_CNN55XX is not set
# CONFIG_CRYPTO_DEV_CHELSIO is not set
CONFIG_CRYPTO_DEV_VIRTIO=m
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
CONFIG_X509_CERTIFICATE_PARSER=y
# CONFIG_PKCS7_MESSAGE_PARSER is not set
#
# Certificates for signature checking
#
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set
# CONFIG_SYSTEM_BLACKLIST_KEYRING is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_IRQFD=y
CONFIG_HAVE_KVM_IRQ_ROUTING=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_KVM_VFIO=y
CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
CONFIG_KVM_COMPAT=y
CONFIG_HAVE_KVM_IRQ_BYPASS=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_MMU_AUDIT=y
CONFIG_VHOST_NET=m
# CONFIG_VHOST_SCSI is not set
# CONFIG_VHOST_VSOCK is not set
CONFIG_VHOST=m
# CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
# CONFIG_HAVE_ARCH_BITREVERSE is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_CRC8=m
# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_BTREE=y
CONFIG_INTERVAL_TREE=y
CONFIG_RADIX_TREE_MULTIORDER=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
# CONFIG_DMA_NOOP_OPS is not set
# CONFIG_DMA_VIRT_OPS is not set
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_GLOB=y
# CONFIG_GLOB_SELFTEST is not set
CONFIG_NLATTR=y
CONFIG_CLZ_TAB=y
CONFIG_CORDIC=m
# CONFIG_DDR is not set
CONFIG_IRQ_POLL=y
CONFIG_MPILIB=y
CONFIG_SIGNATURE=y
CONFIG_OID_REGISTRY=y
CONFIG_UCS2_STRING=y
CONFIG_FONT_SUPPORT=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_SG_SPLIT is not set
CONFIG_SG_POOL=y
CONFIG_ARCH_HAS_SG_CHAIN=y
CONFIG_ARCH_HAS_PMEM_API=y
CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
CONFIG_ARCH_HAS_MMIO_FLUSH=y
CONFIG_SBITMAP=y
[-- Attachment #3: job-script --]
[-- Type: text/plain, Size: 4349 bytes --]
#!/bin/sh
export_top_env()
{
export suite='ltp'
export testcase='ltp'
export category='functional'
export job_origin='/lkp/lkp/.src-20170713-182338/allot/cyclic:linux-devel:devel-hourly/nhm-white2/ltp.yaml'
export queue='bisect'
export testbox='nhm-white2'
export tbox_group='nhm-white2'
export submit_id='596cbccc0b9a93d8998bd5fd'
export job_file='/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml'
export id='bcf686732c701d15cf5dadb19fcea28e34ef0504'
export model='Nehalem'
export memory='4G'
export nr_cpu=8
export hdd_partitions=
export swap_partitions=
export rootfs_partition=
export netconsole_port=6671
export brand='Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz'
export need_kconfig='CONFIG_BLK_DEV_LOOP'
export commit='3f3bf5920d2df8b0b3df8ec90e21e67316688e95'
export kconfig='x86_64-rhel-7.2'
export compiler='gcc-6'
export rootfs='debian-x86_64-2016-08-31.cgz'
export enqueue_time='2017-07-17 21:34:04 +0800'
export _id='596cbccc0b9a93d8998bd5fd'
export _rt='/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95'
export user='lkp'
export head_commit='e457614996880c0ba13ddf22980b39b56030a491'
export base_commit='6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c'
export branch='linux-devel/devel-hourly-2017071420'
export result_root='/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0'
export LKP_SERVER='inn'
export max_uptime=3600
export initrd='/osimage/debian/debian-x86_64-2016-08-31.cgz'
export bootloader_append='root=/dev/ram0
user=lkp
job=/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml
ARCH=x86_64
kconfig=x86_64-rhel-7.2
branch=linux-devel/devel-hourly-2017071420
commit=3f3bf5920d2df8b0b3df8ec90e21e67316688e95
BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59
max_uptime=3600
RESULT_ROOT=/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0
LKP_SERVER=inn
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
earlyprintk=ttyS0,115200
console=ttyS0,115200
console=tty0
vga=normal
rw'
export lkp_initrd='/lkp/lkp/lkp-x86_64.cgz'
export modules_initrd='/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/modules.cgz'
export bm_initrd='/osimage/deps/debian-x86_64-2016-08-31.cgz/lkp_2017-05-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/rsync-rootfs_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/ltp_2017-07-01.cgz,/osimage/pkg/debian-x86_64-2016-08-31.cgz/ltp-x86_64-10f4a5476_2017-07-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/hw_2016-11-15.cgz'
export site='inn'
export LKP_CGI_PORT=80
export LKP_CIFS_PORT=139
export kernel='/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59'
export dequeue_time='2017-07-17 21:34:38 +0800'
export job_initrd='/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.cgz'
[ -n "$LKP_SRC" ] ||
export LKP_SRC=/lkp/${user:-lkp}/src
}
run_job()
{
echo $$ > $TMP/run-job.pid
. $LKP_SRC/lib/http.sh
. $LKP_SRC/lib/job.sh
. $LKP_SRC/lib/env.sh
export_top_env
run_monitor $LKP_SRC/monitors/wrapper kmsg
run_monitor $LKP_SRC/monitors/wrapper heartbeat
run_monitor $LKP_SRC/monitors/wrapper oom-killer
run_monitor $LKP_SRC/monitors/plain/watchdog
run_monitor $LKP_SRC/monitors/wrapper nfs-hang
run_test test='containers' $LKP_SRC/tests/wrapper ltp
}
extract_stats()
{
$LKP_SRC/stats/wrapper ltp
$LKP_SRC/stats/wrapper kmsg
$LKP_SRC/stats/wrapper time ltp.time
$LKP_SRC/stats/wrapper time
$LKP_SRC/stats/wrapper dmesg
$LKP_SRC/stats/wrapper kmsg
$LKP_SRC/stats/wrapper stderr
$LKP_SRC/stats/wrapper last_state
}
"$@"
[-- Attachment #4: dmesg.xz --]
[-- Type: application/octet-stream, Size: 29584 bytes --]
[-- Attachment #5: ltp --]
[-- Type: text/plain, Size: 47755 bytes --]
2017-07-17 21:35:16 ./runltp -f containers
INFO: creating /lkp/benchmarks/ltp/output directory
INFO: creating /lkp/benchmarks/ltp/results directory
Checking for required user/group ids
'nobody' user id and group found.
'bin' user id and group found.
'daemon' user id and group found.
Users group found.
Sys group found.
Required users/groups exist.
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
PRETTY_NAME="Debian GNU/Linux stretch/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Linux nhm-white2 4.12.0-10318-g3f3bf59 #1 SMP Sat Jul 15 01:43:38 CST 2017 x86_64 GNU/Linux
Gnu C
util-linux linux 2.28.1
mount mountinfo, assert, debug)
modutils 23
e2fsprogs 1.43.1
Linux C Library > libc.2.23
Dynamic linker (ldd) 2.23
Procps 3.3.12
Net-tools 2.10-alpha
iproute2 iproute2-ss161212
Kbd 69:
Sh-utils 8.25
Modules Loaded rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver netconsole sr_mod cdrom sd_mod sg snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi intel_powerclamp coretemp ata_generic pata_acpi snd_hda_intel kvm_intel snd_hda_codec dcdbas dell_smm_hwmon firewire_ohci snd_hda_core snd_hwdep firewire_core crc_itu_t ata_piix uas snd_pcm serio_raw pcspkr kvm snd_timer irqbypass i7core_edac usb_storage snd libata crc32c_intel soundcore shpchp ip_tables broadcom bcm_phy_lib
free reports:
total used free shared buff/cache available
Mem: 4033168 165708 2948392 9032 919068 3656908
Swap: 0 0 0
/proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5852.25
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
no big block device was specified on commandline.
Tests which require a big block device are disabled.
You can specify it with option -z
COMMAND: /lkp/benchmarks/ltp/bin/ltp-pan -e -S -a 4180 -n 4180 -p -f /tmp/ltp-QKIduxmJCG/alltests -l /lkp/benchmarks/ltp/results/LTP_RUN_ON-2017_07_17-21h_35m_16s.log -C /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.failed -T /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.tconf
LOG File: /lkp/benchmarks/ltp/results/LTP_RUN_ON-2017_07_17-21h_35m_16s.log
FAILED COMMAND File: /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.failed
TCONF COMMAND File: /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.tconf
Running tests.......
<<<test_start>>>
tag=pidns01 stime=1500298516
cmdline="pidns01"
contacts=""
analysis=exit
<<<test_output>>>
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns02 stime=1500298516
cmdline="pidns02"
contacts=""
analysis=exit
<<<test_output>>>
Checking session id & group id inside container
Success: Got Group ID = 1 & Session ID = 1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns03 stime=1500298516
cmdline="pidns03"
contacts=""
analysis=exit
<<<test_output>>>
pidns03 1 TPASS : mounting procfs in a new namespace
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns04 stime=1500298516
cmdline="pidns04"
contacts=""
analysis=exit
<<<test_output>>>
PIDNS test is running inside container
pidns04 1 TPASS : Container init : I was not killed !
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns05 stime=1500298516
cmdline="pidns05"
contacts=""
analysis=exit
<<<test_output>>>
pidns05 0 TINFO : 5 Nested Containers are created
pidns05 1 TPASS : The number of containers killed are 2
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns06 stime=1500298517
cmdline="pidns06"
contacts=""
analysis=exit
<<<test_output>>>
pidns06 0 TINFO : Parent: Passing the pid of the process 4326
Container: killing parent pid=4326 failed as expected with ESRCH
Container: killing non-existent pid failed as expected with ESRCH
pidns06 0 TINFO : Parent: Passing the pid of the process 4326
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns10 stime=1500298517
cmdline="pidns10"
contacts=""
analysis=exit
<<<test_output>>>
cinit: kill(-1, sig) failed with -1 / ESRCH as expected
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns12 stime=1500298518
cmdline="pidns12"
contacts=""
analysis=exit
<<<test_output>>>
pidns12 0 TINFO : parent: PID is 4332
pidns12 1 TPASS : cinit: signalling PID (from other namespace) is 0 as expected
pidns12 0 TINFO : parent: PID is 4332
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns13 stime=1500298518
cmdline="pidns13"
contacts=""
analysis=exit
<<<test_output>>>
pidns13 0 TINFO : cinit2: writing some data in pipe
pidns13 0 TINFO : cinit1: setup handler for async I/O on pipe
pidns13 1 TPASS : cinit1: si_fd is 7, si_code is 1
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns16 stime=1500298520
cmdline="pidns16"
contacts=""
analysis=exit
<<<test_output>>>
pidns16 1 TPASS : container init continued successfuly, after handling signal -USR1
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns17 stime=1500298522
cmdline="pidns17"
contacts=""
analysis=exit
<<<test_output>>>
cinit: all children have terminated.
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns20 stime=1500298523
cmdline="pidns20"
contacts=""
analysis=exit
<<<test_output>>>
pidns20 0 TINFO : cinit: blocked SIGUSR1
pidns20 0 TINFO : cinit: unblocking SIGUSR1
pidns20 1 TPASS : cinit: user function is called as expected
pidns20 0 TINFO : parent: signalled SIGUSR1 to container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns30 stime=1500298523
cmdline="pidns30"
contacts=""
analysis=exit
<<<test_output>>>
mq_open succeeded
successfully registered for notification
successfully registered handler for SIGUSR1
signal originator PID = 0
parent is done - cleaning up
pidns30 0 TINFO : successfully created posix mqueue
pidns30 0 TINFO : mq_send succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns31 stime=1500298523
cmdline="pidns31"
contacts=""
analysis=exit
<<<test_output>>>
pidns31 0 TINFO : parent: successfully created posix mqueue
pidns31 0 TINFO : cinit: my father is ready to receive a message
pidns31 0 TINFO : cinit: mq_open succeeded
pidns31 0 TINFO : cinit: mq_send() succeeded
pidns31 0 TINFO : parent: successfully created posix mqueue
pidns31 0 TINFO : parent: successfully created child (pid = 4364)
pidns31 0 TINFO : parent: successfully registered for notification
pidns31 0 TINFO : parent: successfully registered handler for SIGUSR1
pidns31 1 TPASS : father: signal originator PID = 4364
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns32 stime=1500298523
cmdline="pidns32"
contacts=""
analysis=exit
<<<test_output>>>
pidns32 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=mqns_01 stime=1500298523
cmdline="mqns_01"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 1 TPASS : child process didn't find mqueue
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_01_clone stime=1500298523
cmdline="mqns_01 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 1 TPASS : child process didn't find mqueue
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_02 stime=1500298523
cmdline="mqns_02"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_02 0 TINFO : Checking namespaces isolation (child to parent)
posixmq_namespace_02 1 TPASS : Parent process can't see the mqueue
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through unshare(2).
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_02_clone stime=1500298523
cmdline="mqns_02 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_02 0 TINFO : Checking namespaces isolation (child to parent)
posixmq_namespace_02 1 TPASS : Parent process can't see the mqueue
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_03 stime=1500298523
cmdline="mqns_03"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through unshare(2)
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through unshare(2)
posixmq_namespace_03 0 TINFO : Checking correct umount+remount of mqueuefs
posixmq_namespace_03 1 TPASS : umount+remount of mqueuefs remounted the right fs
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_03_clone stime=1500298523
cmdline="mqns_03 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through clone(2)
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through clone(2)
posixmq_namespace_03 0 TINFO : Checking correct umount+remount of mqueuefs
posixmq_namespace_03 1 TPASS : umount+remount of mqueuefs remounted the right fs
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_04 stime=1500298523
cmdline="mqns_04"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 1 TPASS : Child mqueue fs still visible for parent
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_04_clone stime=1500298523
cmdline="mqns_04 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 1 TPASS : Child mqueue fs still visible for parent
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=netns_netlink stime=1500298524
cmdline="netns_netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_netlink 1 TPASS : netlink interface pass
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv4_netlink stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv4_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_breakns_ns_exec_ipv4_netlink 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv4_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv6_netlink stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv6_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_breakns_ns_exec_ipv6_netlink 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv6_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv4_ioctl stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv4_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_breakns_ns_exec_ipv4_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv4_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=2
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv6_ioctl stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv6_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_breakns_ns_exec_ipv6_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv6_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv4_netlink stime=1500298524
cmdline="netns_breakns.sh ip ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv4_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_breakns_ip_ipv4_netlink 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv4_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv6_netlink stime=1500298524
cmdline="netns_breakns.sh ip ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv6_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_breakns_ip_ipv6_netlink 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv6_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv4_ioctl stime=1500298525
cmdline="netns_breakns.sh ip ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv4_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_breakns_ip_ipv4_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv4_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv6_ioctl stime=1500298525
cmdline="netns_breakns.sh ip ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv6_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_breakns_ip_ipv6_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv6_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv4_netlink stime=1500298525
cmdline="netns_comm.sh ns_exec ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv4_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_comm_ns_exec_ipv4_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv4_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv4_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv6_netlink stime=1500298528
cmdline="netns_comm.sh ns_exec ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv6_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_comm_ns_exec_ipv6_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv6_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv6_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=2
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv4_ioctl stime=1500298532
cmdline="netns_comm.sh ns_exec ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv4_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_comm_ns_exec_ipv4_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv4_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv4_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv6_ioctl stime=1500298535
cmdline="netns_comm.sh ns_exec ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv6_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_comm_ns_exec_ipv6_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv6_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv6_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv4_netlink stime=1500298538
cmdline="netns_comm.sh ip ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv4_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_comm_ip_ipv4_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv4_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv4_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=3 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv6_netlink stime=1500298542
cmdline="netns_comm.sh ip ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv6_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_comm_ip_ipv6_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv6_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv6_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv4_ioctl stime=1500298546
cmdline="netns_comm.sh ip ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv4_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_comm_ip_ipv4_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv4_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv4_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv6_ioctl stime=1500298549
cmdline="netns_comm.sh ip ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv6_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_comm_ip_ipv6_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv6_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv6_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_sysfs stime=1500298553
cmdline="netns_sysfs.sh"
contacts=""
analysis=exit
<<<test_output>>>
netns_sysfs 1 TPASS: sysfs in new namespace has dummy_test1 interface
netns_sysfs 2 TPASS: sysfs in new namespace does not have dummy_test0 interface
netns_sysfs 3 TPASS: sysfs not affected by a separate namespace
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_none stime=1500298553
cmdline="shmnstest none"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : none
sysvipc_namespace 0 TINFO : shmid namespaces test : none
sysvipc_namespace 1 TPASS : plain cloned process found shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_clone stime=1500298553
cmdline="shmnstest clone"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : clone
sysvipc_namespace 0 TINFO : shmid namespaces test : clone
sysvipc_namespace 1 TPASS : clone: child process didn't find shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_unshare stime=1500298553
cmdline="shmnstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : unshare
sysvipc_namespace 0 TINFO : shmid namespaces test : unshare
sysvipc_namespace 1 TPASS : unshare: child process didn't find shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_none stime=1500298553
cmdline="shmem_2nstest none"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 1 TPASS : Plain cloned process able to access shmem segment created
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_clone stime=1500298553
cmdline="shmem_2nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 0 TINFO : Cont2: Able to allocate shmem seg with the same key
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 1 TPASS : clone : In namespace2 unable to access the shmem seg created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_unshare stime=1500298553
cmdline="shmem_2nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 0 TINFO : Cont2: Able to allocate shmem seg with the same key
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 1 TPASS : unshare : In namespace2 unable to access the shmem seg created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shm_comm stime=1500298553
cmdline="shm_comm"
contacts=""
analysis=exit
<<<test_output>>>
shm_comm 1 TPASS : SysV shm: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_none stime=1500298553
cmdline="mesgq_nstest none"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : none
mesgq_nstest 0 TINFO : Mesg read of 18 bytes; Type 5: Msg: Message of type 5!
mesgq_nstest 0 TINFO : mesgq namespaces test : none
mesgq_nstest 1 TPASS : Plain cloned process found mesgq inside container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_clone stime=1500298553
cmdline="mesgq_nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : clone
mesgq_nstest 0 TINFO : mesgq namespaces test : clone
mesgq_nstest 1 TPASS : clone: Container didn't find mesgq
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_unshare stime=1500298553
cmdline="mesgq_nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : unshare
mesgq_nstest 0 TINFO : mesgq namespaces test : unshare
mesgq_nstest 1 TPASS : unshare: Container didn't find mesgq
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=msg_comm stime=1500298553
cmdline="msg_comm"
contacts=""
analysis=exit
<<<test_output>>>
msg_comm 1 TPASS : SysV msg: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_none stime=1500298553
cmdline="sem_nstest none"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : none
sem_nstest 0 TINFO : PID 5072: Fetched existing semaphore..id = 32769
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : none
sem_nstest 1 TPASS : Plain cloned process found semaphore inside container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_clone stime=1500298553
cmdline="sem_nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : clone
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : clone
sem_nstest 1 TPASS : clone: Container didn't find semaphore
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_unshare stime=1500298553
cmdline="sem_nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : unshare
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : unshare
sem_nstest 1 TPASS : unshare: Container didn't find semaphore
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_none stime=1500298553
cmdline="semtest_2ns none"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 0 TINFO : Sem1: File locked, Critical section is updated...
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 1 TPASS : Plain cloned process able to access the semaphore created
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_clone stime=1500298555
cmdline="semtest_2ns clone"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 0 TINFO : Cont2: Able to create semaphore with sameKey
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 1 TPASS : clone : In namespace2 unable to access the semaphore created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_unshare stime=1500298555
cmdline="semtest_2ns unshare"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 0 TINFO : Cont2: Able to create semaphore with sameKey
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 1 TPASS : unshare : In namespace2 unable to access the semaphore created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_comm stime=1500298556
cmdline="sem_comm"
contacts=""
analysis=exit
<<<test_output>>>
sem_comm 1 TPASS : SysV sem: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_1 stime=1500298556
cmdline="utstest unshare 1"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 1 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_2 stime=1500298556
cmdline="utstest unshare 2"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 2 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_3 stime=1500298556
cmdline="utstest unshare 3"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 3 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_4 stime=1500298556
cmdline="utstest unshare 4"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 4 (unshare): successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_5 stime=1500298556
cmdline="utstest unshare 5"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : P2: P1 claims error
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_1 stime=1500298556
cmdline="utstest clone 1"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 1 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_2 stime=1500298556
cmdline="utstest clone 2"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 2 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_3 stime=1500298556
cmdline="utstest clone 3"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 3 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_4 stime=1500298556
cmdline="utstest clone 4"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 4 (clone): successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_5 stime=1500298556
cmdline="utstest clone 5"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : P2: P1 claims error
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns01 stime=1500298556
cmdline="mountns01"
contacts=""
analysis=exit
<<<test_output>>>
mountns01 1 TPASS : shared mount in child passed
mountns01 2 TPASS : shared mount in parent passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns02 stime=1500298556
cmdline="mountns02"
contacts=""
analysis=exit
<<<test_output>>>
mountns02 1 TPASS : private mount in child passed
mountns02 2 TPASS : private mount in parent passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns03 stime=1500298556
cmdline="mountns03"
contacts=""
analysis=exit
<<<test_output>>>
mountns03 1 TPASS : propagation from slave mount passed
mountns03 2 TPASS : propagation to slave mount passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns04 stime=1500298556
cmdline="mountns04"
contacts=""
analysis=exit
<<<test_output>>>
mountns04 1 TPASS : unbindable mount passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns01 stime=1500298556
cmdline="userns01"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace1 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns02 stime=1500298556
cmdline="userns02"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace2 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns03 stime=1500298556
cmdline="userns03"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace3 1 TPASS : setgroups can't be re-enabled
user_namespace3 0 TINFO : Child process returned TPASS
user_namespace3 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns04 stime=1500298556
cmdline="userns04"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace4 0 TINFO : Child process returned TPASS
user_namespace4 0 TINFO : Child process returned TPASS
user_namespace4 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns05 stime=1500298556
cmdline="userns05"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace5 0 TINFO : Child process returned TPASS
user_namespace5 0 TINFO : Child process returned TPASS
user_namespace5 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns06 stime=1500298556
cmdline="userns06"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace6 0 TINFO : Child process returned TPASS
user_namespace6 0 TINFO : Child process returned TFAIL
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns07 stime=1500298556
cmdline="userns07"
contacts=""
analysis=exit
<<<test_output>>>
userns07 0 TINFO : Child process returned TPASS
incrementing stop
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
INFO: ltp-pan reported some tests FAIL
LTP Version: 20170516-93-g10f4a5476
###############################################################
Done executing testcases.
LTP Version: 20170516-93-g10f4a5476
###############################################################
[-- Attachment #6: job.yaml --]
[-- Type: text/plain, Size: 3600 bytes --]
---
#! jobs/ltp.yaml
suite: ltp
testcase: ltp
category: functional
ltp:
test: containers
job_origin: "/lkp/lkp/.src-20170713-182338/allot/cyclic:linux-devel:devel-hourly/nhm-white2/ltp.yaml"
#! queue options
queue: bisect
testbox: nhm-white2
tbox_group: nhm-white2
submit_id: 596cbccc0b9a93d8998bd5fd
job_file: "/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml"
id: bcf686732c701d15cf5dadb19fcea28e34ef0504
#! hosts/nhm-white2
model: Nehalem
memory: 4G
nr_cpu: 8
hdd_partitions:
swap_partitions:
rootfs_partition:
netconsole_port: 6671
brand: Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
#! include/category/functional
kmsg:
heartbeat:
#! include/ltp
need_kconfig: CONFIG_BLK_DEV_LOOP
#! include/queue/cyclic
commit: 3f3bf5920d2df8b0b3df8ec90e21e67316688e95
#! include/testbox/nhm-white2
cpufreq_governor:
#! default params
kconfig: x86_64-rhel-7.2
compiler: gcc-6
rootfs: debian-x86_64-2016-08-31.cgz
enqueue_time: 2017-07-17 21:34:04.819483840 +08:00
_id: 596cbccc0b9a93d8998bd5fd
_rt: "/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95"
#! schedule options
user: lkp
head_commit: e457614996880c0ba13ddf22980b39b56030a491
base_commit: 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
branch: linux-devel/devel-hourly-2017071420
result_root: "/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0"
LKP_SERVER: inn
max_uptime: 3600
initrd: "/osimage/debian/debian-x86_64-2016-08-31.cgz"
bootloader_append:
- root=/dev/ram0
- user=lkp
- job=/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml
- ARCH=x86_64
- kconfig=x86_64-rhel-7.2
- branch=linux-devel/devel-hourly-2017071420
- commit=3f3bf5920d2df8b0b3df8ec90e21e67316688e95
- BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59
- max_uptime=3600
- RESULT_ROOT=/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0
- LKP_SERVER=inn
- debug
- apic=debug
- sysrq_always_enabled
- rcupdate.rcu_cpu_stall_timeout=100
- net.ifnames=0
- printk.devkmsg=on
- panic=-1
- softlockup_panic=1
- nmi_watchdog=panic
- oops=panic
- load_ramdisk=2
- prompt_ramdisk=0
- drbd.minor_count=8
- systemd.log_level=err
- ignore_loglevel
- earlyprintk=ttyS0,115200
- console=ttyS0,115200
- console=tty0
- vga=normal
- rw
lkp_initrd: "/lkp/lkp/lkp-x86_64.cgz"
modules_initrd: "/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/modules.cgz"
bm_initrd: "/osimage/deps/debian-x86_64-2016-08-31.cgz/lkp_2017-05-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/rsync-rootfs_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/ltp_2017-07-01.cgz,/osimage/pkg/debian-x86_64-2016-08-31.cgz/ltp-x86_64-10f4a5476_2017-07-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/hw_2016-11-15.cgz"
site: inn
#! /lkp/lkp/.src-20170717-111651/include/site/inn
LKP_CGI_PORT: 80
LKP_CIFS_PORT: 139
oom-killer:
watchdog:
nfs-hang:
#! runtime status
#! user overrides
kernel: "/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59"
dequeue_time: 2017-07-17 21:34:38.045538335 +08:00
#! /lkp/lkp/.src-20170717-211357/include/site/inn
job_state: failed
loadavg: '0.62'
[-- Attachment #7: reproduce --]
[-- Type: text/plain, Size: 23 bytes --]
./runltp -f containers
[-- Attachment #8: Type: text/plain, Size: 205 bytes --]
_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply [flat|nested] 288+ messages in thread* [lkp-robot] [xattr] 3f3bf5920d: ltp.userns06.fail
@ 2017-07-20 1:05 ` kernel test robot
0 siblings, 0 replies; 288+ messages in thread
From: kernel test robot @ 2017-07-20 1:05 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
FYI, we noticed the following commit:
commit: 3f3bf5920d2df8b0b3df8ec90e21e67316688e95 ("xattr: Enable security.capability in user namespaces")
url: https://github.com/0day-ci/linux/commits/Stefan-Berger/xattr-Enable-security-capability-in-user-namespaces/20170712-035657
in testcase: ltp
with following parameters:
test: containers
test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
test-url: http://linux-test-project.github.io/
on test machine: 8 threads Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz with 4G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
[ 60.440119] <<<test_start>>>
[ 60.440120]
[ 60.441256] tag=userns06 stime=1500298556
[ 60.441258]
[ 60.442244] cmdline="userns06"
[ 60.442246]
[ 60.442943] contacts=""
[ 60.442945]
[ 60.443774] analysis=exit
[ 60.443776]
[ 60.444626] <<<test_output>>>
[ 60.444628]
[ 60.446472] user_namespace6 0 TINFO : Child process returned TPASS
[ 60.446474]
[ 60.448555] user_namespace6 0 TINFO : Child process returned TFAIL
[ 60.448557]
[ 60.449643] <<<execution_status>>>
[ 60.449645]
[ 60.450596] initiation_status="ok"
[ 60.450598]
[ 60.452640] duration=0 termination_type=exited termination_id=1 corefile=no
[ 60.452641]
[ 60.453663] cutime=0 cstime=0
[ 60.453665]
[ 60.454431] <<<test_end>>>
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Xiaolong
[-- Attachment #2: config-4.12.0-10318-g3f3bf59 --]
[-- Type: text/plain, Size: 160355 bytes --]
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.12.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
# CONFIG_NO_HZ_FULL_ALL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_RCU_NOCB_CPU=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_BPF is not set
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_POSIX_TIMERS=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_BPF_SYSCALL=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_USERFAULTFD=y
CONFIG_PCI_QUIRKS=y
CONFIG_MEMBARRIER=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
# CONFIG_PC104 is not set
#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLUB_MEMCG_SYSFS_ON is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLAB_MERGE_DEFAULT=y
# CONFIG_SLAB_FREELIST_RANDOM is not set
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SYSTEM_DATA_VERIFICATION is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
# CONFIG_STATIC_KEYS_SELFTEST is not set
CONFIG_OPTPROBES=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_UPROBES=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_NMI=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_ARCH_HAS_SET_MEMORY=y
CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_GCC_PLUGINS=y
# CONFIG_GCC_PLUGINS is not set
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_THIN_ARCHIVES=y
CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_HAVE_ARCH_HUGE_VMAP=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
CONFIG_HAVE_EXIT_THREAD=y
CONFIG_ARCH_MMAP_RND_BITS=28
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES=y
CONFIG_HAVE_COPY_THREAD_TLS=y
CONFIG_HAVE_STACK_VALIDATION=y
# CONFIG_HAVE_ARCH_HASH is not set
# CONFIG_ISA_BUS_API is not set
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_COMPAT_OLD_SIGACTION=y
# CONFIG_CPU_NO_EFFICIENT_FFS is not set
CONFIG_HAVE_ARCH_VMAP_STACK=y
CONFIG_VMAP_STACK=y
# CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set
# CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set
CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
CONFIG_STRICT_MODULE_RWX=y
# CONFIG_REFCOUNT_FULL is not set
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
# CONFIG_MODULE_COMPRESS is not set
# CONFIG_TRIM_UNUSED_KSYMS is not set
CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_BLOCK=y
CONFIG_BLK_SCSI_REQUEST=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y
# CONFIG_BLK_DEV_ZONED is not set
CONFIG_BLK_DEV_THROTTLING=y
# CONFIG_BLK_DEV_THROTTLING_LOW is not set
# CONFIG_BLK_CMDLINE_PARSER is not set
# CONFIG_BLK_WBT is not set
CONFIG_BLK_DEBUG_FS=y
# CONFIG_BLK_SED_OPAL is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_BLOCK_COMPAT=y
CONFIG_BLK_MQ_PCI=y
CONFIG_BLK_MQ_VIRTIO=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_MQ_IOSCHED_DEADLINE=y
CONFIG_MQ_IOSCHED_KYBER=y
# CONFIG_IOSCHED_BFQ is not set
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PADATA=y
CONFIG_ASN1=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_LOCK_SPIN_ON_OWNER=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
CONFIG_QUEUED_SPINLOCKS=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
CONFIG_QUEUED_RWLOCKS=y
CONFIG_FREEZER=y
#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_FAST_FEATURE_TESTS=y
CONFIG_X86_X2APIC=y
CONFIG_X86_MPPARSE=y
# CONFIG_GOLDFISH is not set
CONFIG_INTEL_RDT_A=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_NUMACHIP is not set
# CONFIG_X86_VSMP is not set
CONFIG_X86_UV=y
# CONFIG_X86_GOLDFISH is not set
# CONFIG_X86_INTEL_MID is not set
CONFIG_X86_INTEL_LPSS=y
# CONFIG_X86_AMD_PLATFORM_DEVICE is not set
CONFIG_IOSF_MBI=y
# CONFIG_IOSF_MBI_DEBUG is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
CONFIG_HYPERVISOR_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_PARAVIRT_SPINLOCKS=y
# CONFIG_QUEUED_LOCK_STAT is not set
CONFIG_XEN=y
CONFIG_XEN_PV=y
CONFIG_XEN_PV_SMP=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_PVHVM_SMP=y
CONFIG_XEN_512GB=y
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_XEN_PVH is not set
CONFIG_KVM_GUEST=y
# CONFIG_KVM_DEBUG_FS is not set
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_NO_BOOTMEM=y
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
# CONFIG_PROCESSOR_SELECT is not set
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_MAXSMP=y
CONFIG_NR_CPUS=8192
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_SCHED_MC_PRIO=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCELOG_LEGACY=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=m
CONFIG_X86_THERMAL_VECTOR=y
#
# Performance monitoring
#
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_PERF_EVENTS_INTEL_RAPL=y
CONFIG_PERF_EVENTS_INTEL_CSTATE=y
# CONFIG_PERF_EVENTS_AMD_POWER is not set
# CONFIG_VM86 is not set
CONFIG_X86_16BIT=y
CONFIG_X86_ESPFIX64=y
CONFIG_X86_VSYSCALL_EMULATION=y
CONFIG_I8K=m
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_X86_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=10
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_MEMORY_PROBE=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_HAVE_GENERIC_GUP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
CONFIG_HAVE_BOOTMEM_INFO_NODE=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
# CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is not set
CONFIG_MEMORY_HOTREMOVE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
CONFIG_MEMORY_BALLOON=y
CONFIG_BALLOON_COMPACTION=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
CONFIG_HWPOISON_INJECT=m
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_ARCH_WANTS_THP_SWAP=y
CONFIG_THP_SWAP=y
CONFIG_TRANSPARENT_HUGE_PAGECACHE=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set
# CONFIG_CMA_DEBUGFS is not set
CONFIG_CMA_AREAS=7
# CONFIG_MEM_SOFT_DIRTY is not set
CONFIG_ZSWAP=y
CONFIG_ZPOOL=y
CONFIG_ZBUD=y
# CONFIG_Z3FOLD is not set
CONFIG_ZSMALLOC=y
# CONFIG_PGTABLE_MAPPING is not set
# CONFIG_ZSMALLOC_STAT is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT=y
# CONFIG_DEFERRED_STRUCT_PAGE_INIT is not set
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_ARCH_HAS_ZONE_DEVICE=y
CONFIG_ZONE_DEVICE=y
CONFIG_FRAME_VECTOR=y
CONFIG_ARCH_USES_HIGH_VMA_FLAGS=y
CONFIG_ARCH_HAS_PKEYS=y
# CONFIG_PERCPU_STATS is not set
CONFIG_X86_PMEM_LEGACY_DEVICE=y
CONFIG_X86_PMEM_LEGACY=m
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
# CONFIG_X86_INTEL_MPX is not set
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
# CONFIG_EFI_MIXED is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
# CONFIG_KEXEC_FILE is not set
CONFIG_CRASH_DUMP=y
CONFIG_KEXEC_JUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
# CONFIG_RANDOMIZE_BASE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
CONFIG_BOOTPARAM_HOTPLUG_CPU0=y
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
# CONFIG_LEGACY_VSYSCALL_NATIVE is not set
CONFIG_LEGACY_VSYSCALL_EMULATE=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_MODIFY_LDT_SYSCALL=y
CONFIG_HAVE_LIVEPATCH=y
# CONFIG_LIVEPATCH is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y
#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_SUSPEND_SKIP_SYNC is not set
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_PM_ADVANCED_DEBUG=y
CONFIG_PM_TEST_SUSPEND=y
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_DPM_WATCHDOG is not set
# CONFIG_PM_TRACE_RTC is not set
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
# CONFIG_ACPI_DEBUGGER is not set
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
CONFIG_ACPI_EC_DEBUGFS=m
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_CPU_FREQ_PSS=y
CONFIG_ACPI_PROCESSOR_CSTATE=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_ACPI_CPPC_LIB=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_IPMI=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_ACPI_HOTPLUG_IOAPIC=y
CONFIG_ACPI_SBS=m
CONFIG_ACPI_HED=y
CONFIG_ACPI_CUSTOM_METHOD=m
CONFIG_ACPI_BGRT=y
# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
CONFIG_ACPI_NFIT=m
CONFIG_HAVE_ACPI_APEI=y
CONFIG_HAVE_ACPI_APEI_NMI=y
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_ACPI_APEI_MEMORY_FAILURE=y
CONFIG_ACPI_APEI_EINJ=m
CONFIG_ACPI_APEI_ERST_DEBUG=y
# CONFIG_DPTF_POWER is not set
CONFIG_ACPI_EXTLOG=m
# CONFIG_PMIC_OPREGION is not set
# CONFIG_ACPI_CONFIGFS is not set
CONFIG_SFI=y
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
#
# CPU frequency scaling drivers
#
CONFIG_X86_INTEL_PSTATE=y
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ_CPB=y
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_AMD_FREQ_SENSITIVITY=m
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=m
#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
#
# CPU Idle
#
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_GOV_LADDER is not set
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
CONFIG_INTEL_IDLE=y
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
CONFIG_PCIEAER_INJECT=m
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_POWER_SUPERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_PCIE_PME=y
# CONFIG_PCIE_DPC is not set
# CONFIG_PCIE_PTM is not set
CONFIG_PCI_BUS_ADDR_T_64BIT=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MSI_IRQ_DOMAIN=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
CONFIG_PCI_STUB=y
# CONFIG_XEN_PCIDEV_FRONTEND is not set
CONFIG_HT_IRQ=y
CONFIG_PCI_ATS=y
CONFIG_PCI_LOCKLESS_CONFIG=y
CONFIG_PCI_IOV=y
CONFIG_PCI_PRI=y
CONFIG_PCI_PASID=y
CONFIG_PCI_LABEL=y
# CONFIG_PCI_HYPERV is not set
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m
#
# DesignWare PCI Core Support
#
# CONFIG_PCIE_DW_PLAT is not set
#
# PCI host controller drivers
#
# CONFIG_VMD is not set
#
# PCI Endpoint
#
# CONFIG_PCI_ENDPOINT is not set
#
# PCI switch controller drivers
#
# CONFIG_PCI_SW_SWITCHTEC is not set
# CONFIG_ISA_BUS is not set
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA is not set
CONFIG_CARDBUS=y
#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_RAPIDIO is not set
# CONFIG_X86_SYSFB is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ELFCORE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
# CONFIG_X86_X32 is not set
CONFIG_COMPAT_32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y
CONFIG_NET_INGRESS=y
CONFIG_NET_EGRESS=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=m
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=m
# CONFIG_TLS is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_FIB_TRIE_STATS=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_CLASSID=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE_DEMUX=m
CONFIG_NET_IP_TUNNEL=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_SYN_COOKIES=y
CONFIG_NET_IPVTI=m
CONFIG_NET_UDP_TUNNEL=m
# CONFIG_NET_FOU is not set
# CONFIG_NET_FOU_IP_TUNNELS is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
# CONFIG_INET_ESP_OFFLOAD is not set
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_INET_UDP_DIAG=m
# CONFIG_INET_RAW_DIAG is not set
# CONFIG_INET_DIAG_DESTROY is not set
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
# CONFIG_TCP_CONG_NV is not set
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_TCP_CONG_DCTCP is not set
# CONFIG_TCP_CONG_CDG is not set
# CONFIG_TCP_CONG_BBR is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
# CONFIG_INET6_ESP_OFFLOAD is not set
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
# CONFIG_IPV6_ILA is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
# CONFIG_IPV6_VTI is not set
CONFIG_IPV6_SIT=m
CONFIG_IPV6_SIT_6RD=y
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_FOU is not set
# CONFIG_IPV6_FOU_TUNNEL is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
CONFIG_IPV6_PIMSM_V2=y
# CONFIG_IPV6_SEG6_LWTUNNEL is not set
# CONFIG_IPV6_SEG6_HMAC is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NET_PTP_CLASSIFY=y
CONFIG_NETWORK_PHY_TIMESTAMPING=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=m
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_INGRESS=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_ACCT=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_LOG_COMMON=m
# CONFIG_NF_LOG_NETDEV is not set
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_ZONES=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_EVENTS=y
# CONFIG_NF_CONNTRACK_TIMEOUT is not set
CONFIG_NF_CONNTRACK_TIMESTAMP=y
CONFIG_NF_CONNTRACK_LABELS=y
CONFIG_NF_CT_PROTO_DCCP=y
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=y
CONFIG_NF_CT_PROTO_UDPLITE=y
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_BROADCAST=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_SNMP=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
# CONFIG_NF_CT_NETLINK_TIMEOUT is not set
# CONFIG_NETFILTER_NETLINK_GLUE_CT is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_NF_NAT_PROTO_DCCP=y
CONFIG_NF_NAT_PROTO_UDPLITE=y
CONFIG_NF_NAT_PROTO_SCTP=y
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_SIP=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_REDIRECT=m
CONFIG_NETFILTER_SYNPROXY=m
CONFIG_NF_TABLES=m
# CONFIG_NF_TABLES_INET is not set
# CONFIG_NF_TABLES_NETDEV is not set
CONFIG_NFT_EXTHDR=m
CONFIG_NFT_META=m
# CONFIG_NFT_RT is not set
# CONFIG_NFT_NUMGEN is not set
CONFIG_NFT_CT=m
# CONFIG_NFT_SET_RBTREE is not set
# CONFIG_NFT_SET_HASH is not set
# CONFIG_NFT_SET_BITMAP is not set
CONFIG_NFT_COUNTER=m
CONFIG_NFT_LOG=m
CONFIG_NFT_LIMIT=m
# CONFIG_NFT_MASQ is not set
# CONFIG_NFT_REDIR is not set
CONFIG_NFT_NAT=m
# CONFIG_NFT_OBJREF is not set
# CONFIG_NFT_QUEUE is not set
# CONFIG_NFT_QUOTA is not set
# CONFIG_NFT_REJECT is not set
CONFIG_NFT_COMPAT=m
CONFIG_NFT_HASH=m
CONFIG_NETFILTER_XTABLES=y
#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=m
CONFIG_NETFILTER_XT_CONNMARK=m
CONFIG_NETFILTER_XT_SET=m
#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_AUDIT=m
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_HMARK=m
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_LED=m
CONFIG_NETFILTER_XT_TARGET_LOG=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_NAT=m
CONFIG_NETFILTER_XT_TARGET_NETMAP=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_REDIRECT=m
CONFIG_NETFILTER_XT_TARGET_TEE=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
CONFIG_NETFILTER_XT_MATCH_BPF=m
# CONFIG_NETFILTER_XT_MATCH_CGROUP is not set
CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLABEL=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_CPU=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ECN=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
# CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_IPVS=m
CONFIG_NETFILTER_XT_MATCH_L2TP=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_NFACCT=m
CONFIG_NETFILTER_XT_MATCH_OSF=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_RECENT=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_IP_SET=m
CONFIG_IP_SET_MAX=256
CONFIG_IP_SET_BITMAP_IP=m
CONFIG_IP_SET_BITMAP_IPMAC=m
CONFIG_IP_SET_BITMAP_PORT=m
CONFIG_IP_SET_HASH_IP=m
# CONFIG_IP_SET_HASH_IPMARK is not set
CONFIG_IP_SET_HASH_IPPORT=m
CONFIG_IP_SET_HASH_IPPORTIP=m
CONFIG_IP_SET_HASH_IPPORTNET=m
# CONFIG_IP_SET_HASH_IPMAC is not set
# CONFIG_IP_SET_HASH_MAC is not set
# CONFIG_IP_SET_HASH_NETPORTNET is not set
CONFIG_IP_SET_HASH_NET=m
# CONFIG_IP_SET_HASH_NETNET is not set
CONFIG_IP_SET_HASH_NETPORT=m
CONFIG_IP_SET_HASH_NETIFACE=m
CONFIG_IP_SET_LIST_SET=m
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
# CONFIG_IP_VS_FO is not set
# CONFIG_IP_VS_OVF is not set
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#
# IPVS SH scheduler
#
CONFIG_IP_VS_SH_TAB_BITS=8
#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m
#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
# CONFIG_NF_SOCKET_IPV4 is not set
CONFIG_NF_TABLES_IPV4=m
CONFIG_NFT_CHAIN_ROUTE_IPV4=m
# CONFIG_NFT_REJECT_IPV4 is not set
# CONFIG_NFT_DUP_IPV4 is not set
# CONFIG_NFT_FIB_IPV4 is not set
# CONFIG_NF_TABLES_ARP is not set
CONFIG_NF_DUP_IPV4=m
# CONFIG_NF_LOG_ARP is not set
CONFIG_NF_LOG_IPV4=m
CONFIG_NF_REJECT_IPV4=m
CONFIG_NF_NAT_IPV4=m
CONFIG_NFT_CHAIN_NAT_IPV4=m
CONFIG_NF_NAT_MASQUERADE_IPV4=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_RPFILTER=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_SYNPROXY=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_SECURITY=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
#
# IPv6: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV6=m
CONFIG_NF_CONNTRACK_IPV6=m
# CONFIG_NF_SOCKET_IPV6 is not set
CONFIG_NF_TABLES_IPV6=m
CONFIG_NFT_CHAIN_ROUTE_IPV6=m
# CONFIG_NFT_REJECT_IPV6 is not set
# CONFIG_NFT_DUP_IPV6 is not set
# CONFIG_NFT_FIB_IPV6 is not set
CONFIG_NF_DUP_IPV6=m
CONFIG_NF_REJECT_IPV6=m
CONFIG_NF_LOG_IPV6=m
CONFIG_NF_NAT_IPV6=m
CONFIG_NFT_CHAIN_NAT_IPV6=m
# CONFIG_NF_NAT_MASQUERADE_IPV6 is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RPFILTER=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_TARGET_SYNPROXY=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_RAW=m
CONFIG_IP6_NF_SECURITY=m
# CONFIG_IP6_NF_NAT is not set
CONFIG_NF_TABLES_BRIDGE=m
# CONFIG_NFT_BRIDGE_META is not set
# CONFIG_NF_LOG_BRIDGE is not set
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_IP6=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
#
# DCCP CCIDs Configuration
#
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=y
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_TFRC_LIB=y
#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_NET_DCCPPROBE is not set
CONFIG_IP_SCTP=m
CONFIG_NET_SCTPPROBE=m
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set
CONFIG_SCTP_COOKIE_HMAC_MD5=y
CONFIG_SCTP_COOKIE_HMAC_SHA1=y
CONFIG_INET_SCTP_DIAG=m
# CONFIG_RDS is not set
CONFIG_TIPC=m
CONFIG_TIPC_MEDIA_UDP=y
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_L2TP=m
CONFIG_L2TP_DEBUGFS=m
CONFIG_L2TP_V3=y
CONFIG_L2TP_IP=m
CONFIG_L2TP_ETH=m
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_MRP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_HAVE_NET_DSA=y
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_VLAN_8021Q_MVRP=y
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_6LOWPAN is not set
CONFIG_IEEE802154=m
# CONFIG_IEEE802154_NL802154_EXPERIMENTAL is not set
CONFIG_IEEE802154_SOCKET=m
CONFIG_MAC802154=m
CONFIG_NET_SCHED=y
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_MULTIQ=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFB=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_DRR=m
CONFIG_NET_SCH_MQPRIO=m
CONFIG_NET_SCH_CHOKE=m
CONFIG_NET_SCH_QFQ=m
CONFIG_NET_SCH_CODEL=m
CONFIG_NET_SCH_FQ_CODEL=m
# CONFIG_NET_SCH_FQ is not set
# CONFIG_NET_SCH_HHF is not set
# CONFIG_NET_SCH_PIE is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_PLUG=m
# CONFIG_NET_SCH_DEFAULT is not set
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=m
CONFIG_NET_CLS_CGROUP=y
CONFIG_NET_CLS_BPF=m
# CONFIG_NET_CLS_FLOWER is not set
# CONFIG_NET_CLS_MATCHALL is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_EMATCH_IPSET=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
# CONFIG_NET_ACT_SAMPLE is not set
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_ACT_CSUM=m
# CONFIG_NET_ACT_VLAN is not set
# CONFIG_NET_ACT_BPF is not set
# CONFIG_NET_ACT_CONNMARK is not set
# CONFIG_NET_ACT_SKBMOD is not set
# CONFIG_NET_ACT_IFE is not set
# CONFIG_NET_ACT_TUNNEL_KEY is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
CONFIG_DCB=y
CONFIG_DNS_RESOLVER=m
# CONFIG_BATMAN_ADV is not set
CONFIG_OPENVSWITCH=m
CONFIG_OPENVSWITCH_GRE=m
CONFIG_OPENVSWITCH_VXLAN=m
CONFIG_VSOCKETS=m
CONFIG_VMWARE_VMCI_VSOCKETS=m
# CONFIG_VIRTIO_VSOCKETS is not set
CONFIG_NETLINK_DIAG=m
CONFIG_MPLS=y
CONFIG_NET_MPLS_GSO=m
# CONFIG_MPLS_ROUTING is not set
# CONFIG_HSR is not set
# CONFIG_NET_SWITCHDEV is not set
# CONFIG_NET_L3_MASTER_DEV is not set
# CONFIG_NET_NCSI is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
# CONFIG_CGROUP_NET_PRIO is not set
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
CONFIG_BPF_JIT=y
CONFIG_NET_FLOW_LIMIT=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
CONFIG_NET_DROP_MONITOR=y
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_AF_KCM is not set
# CONFIG_STREAM_PARSER is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211=m
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
CONFIG_CFG80211_CRDA_SUPPORT=y
CONFIG_CFG80211_WEXT=y
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
# CONFIG_MAC80211_RC_MINSTREL_VHT is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
CONFIG_MAC80211_STA_HASH_MAX_SIZE=0
# CONFIG_WIMAX is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_RFKILL_GPIO is not set
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
# CONFIG_NET_9P_XEN is not set
# CONFIG_NET_9P_DEBUG is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
# CONFIG_PSAMPLE is not set
# CONFIG_NET_IFE is not set
# CONFIG_LWTUNNEL is not set
CONFIG_DST_CACHE=y
CONFIG_GRO_CELLS=y
# CONFIG_NET_DEVLINK is not set
CONFIG_MAY_USE_DEVLINK=y
CONFIG_HAVE_EBPF_JIT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_ALLOW_DEV_COREDUMP=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set
# CONFIG_TEST_ASYNC_DRIVER_PROBE is not set
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_DMA_SHARED_BUFFER=y
# CONFIG_DMA_FENCE_TRACE is not set
CONFIG_DMA_CMA=y
#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=200
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=m
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_BLOCK=m
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set
# CONFIG_MTD_PARTITIONED_MASTER is not set
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set
#
# LPDDR & LPDDR2 PCM memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_SPI_NOR is not set
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
# CONFIG_MTD_UBI_BLOCK is not set
# CONFIG_OF is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_NULL_BLK=m
CONFIG_BLK_DEV_FD=m
# CONFIG_PARIDE is not set
CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m
# CONFIG_ZRAM is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=0
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SKD is not set
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_RAM_DAX is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=m
# CONFIG_XEN_BLKDEV_BACKEND is not set
CONFIG_VIRTIO_BLK=y
# CONFIG_VIRTIO_BLK_SCSI is not set
# CONFIG_BLK_DEV_RBD is not set
CONFIG_BLK_DEV_RSXX=m
CONFIG_NVME_CORE=m
CONFIG_BLK_DEV_NVME=m
# CONFIG_NVME_FC is not set
# CONFIG_NVME_TARGET is not set
#
# Misc devices
#
CONFIG_SENSORS_LIS3LV02D=m
# CONFIG_AD525X_DPOT is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_ICS932S401 is not set
CONFIG_ENCLOSURE_SERVICES=m
CONFIG_SGI_XP=m
CONFIG_HP_ILO=m
CONFIG_SGI_GRU=m
# CONFIG_SGI_GRU_DEBUG is not set
CONFIG_APDS9802ALS=m
CONFIG_ISL29003=m
CONFIG_ISL29020=m
CONFIG_SENSORS_TSL2550=m
CONFIG_SENSORS_BH1770=m
CONFIG_SENSORS_APDS990X=m
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
CONFIG_VMWARE_BALLOON=m
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_PCI_ENDPOINT_TEST is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
# CONFIG_EEPROM_AT25 is not set
CONFIG_EEPROM_LEGACY=m
CONFIG_EEPROM_MAX6875=m
CONFIG_EEPROM_93CX6=m
# CONFIG_EEPROM_93XX46 is not set
# CONFIG_EEPROM_IDT_89HPESX is not set
CONFIG_CB710_CORE=m
# CONFIG_CB710_DEBUG is not set
CONFIG_CB710_DEBUG_ASSUMPTIONS=y
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
CONFIG_SENSORS_LIS3_I2C=m
#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=m
CONFIG_INTEL_MEI=y
CONFIG_INTEL_MEI_ME=y
# CONFIG_INTEL_MEI_TXE is not set
CONFIG_VMWARE_VMCI=m
#
# Intel MIC Bus Driver
#
# CONFIG_INTEL_MIC_BUS is not set
#
# SCIF Bus Driver
#
# CONFIG_SCIF_BUS is not set
#
# VOP Bus Driver
#
# CONFIG_VOP_BUS is not set
#
# Intel MIC Host Driver
#
#
# Intel MIC Card Driver
#
#
# SCIF Driver
#
#
# Intel MIC Coprocessor State Management (COSM) Drivers
#
#
# VOP Driver
#
# CONFIG_GENWQE is not set
# CONFIG_ECHO is not set
# CONFIG_CXL_BASE is not set
# CONFIG_CXL_AFU_DRIVER_OPS is not set
# CONFIG_CXL_LIB is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_ENCLOSURE=m
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
CONFIG_ISCSI_BOOT_SYSFS=m
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_SCSI_BNX2X_FCOE=m
CONFIG_BE2ISCSI=m
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_HPSA=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_3W_SAS=m
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=m
# CONFIG_SCSI_AIC7XXX is not set
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC94XX is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
CONFIG_SCSI_MVSAS_TASKLET=y
CONFIG_SCSI_MVUMI=m
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_ARCMSR=m
# CONFIG_SCSI_ESAS2R is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_MPT3SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT3SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS=m
# CONFIG_SCSI_SMARTPQI is not set
CONFIG_SCSI_UFSHCD=m
CONFIG_SCSI_UFSHCD_PCI=m
# CONFIG_SCSI_UFS_DWC_TC_PCI is not set
# CONFIG_SCSI_UFSHCD_PLATFORM is not set
CONFIG_SCSI_HPTIOP=m
# CONFIG_SCSI_BUSLOGIC is not set
CONFIG_VMWARE_PVSCSI=m
# CONFIG_XEN_SCSI_FRONTEND is not set
CONFIG_HYPERV_STORAGE=m
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
CONFIG_FCOE=m
CONFIG_FCOE_FNIC=m
# CONFIG_SCSI_SNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_ISCI=m
# CONFIG_SCSI_IPS is not set
CONFIG_SCSI_INITIO=m
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
CONFIG_SCSI_STEX=m
# CONFIG_SCSI_SYM53C8XX_2 is not set
CONFIG_SCSI_IPR=m
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA_FC=m
# CONFIG_TCM_QLA2XXX is not set
CONFIG_SCSI_QLA_ISCSI=m
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_WD719X is not set
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_PMCRAID=m
CONFIG_SCSI_PM8001=m
# CONFIG_SCSI_BFA_FC is not set
CONFIG_SCSI_VIRTIO=m
CONFIG_SCSI_CHELSIO_FCOE=m
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=y
CONFIG_SCSI_DH_HP_SW=y
CONFIG_SCSI_DH_EMC=y
CONFIG_SCSI_DH_ALUA=y
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
# CONFIG_SATA_ZPODD is not set
CONFIG_SATA_PMP=y
#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
CONFIG_SATA_AHCI_PLATFORM=m
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_ACARD_AHCI=m
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y
#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_SX4=m
CONFIG_ATA_BMDMA=y
#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=m
# CONFIG_SATA_DWC is not set
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_SVW=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m
#
# PATA SFF controllers with BMDMA
#
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=m
CONFIG_PATA_ARTOP=m
CONFIG_PATA_ATIIXP=m
CONFIG_PATA_ATP867X=m
CONFIG_PATA_CMD64X=m
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_PATA_HPT366=m
CONFIG_PATA_HPT37X=m
CONFIG_PATA_HPT3X2N=m
CONFIG_PATA_HPT3X3=m
# CONFIG_PATA_HPT3X3_DMA is not set
CONFIG_PATA_IT8213=m
CONFIG_PATA_IT821X=m
CONFIG_PATA_JMICRON=m
CONFIG_PATA_MARVELL=m
CONFIG_PATA_NETCELL=m
CONFIG_PATA_NINJA32=m
# CONFIG_PATA_NS87415 is not set
CONFIG_PATA_OLDPIIX=m
# CONFIG_PATA_OPTIDMA is not set
CONFIG_PATA_PDC2027X=m
CONFIG_PATA_PDC_OLD=m
# CONFIG_PATA_RADISYS is not set
CONFIG_PATA_RDC=m
CONFIG_PATA_SCH=m
CONFIG_PATA_SERVERWORKS=m
CONFIG_PATA_SIL680=m
CONFIG_PATA_SIS=m
CONFIG_PATA_TOSHIBA=m
# CONFIG_PATA_TRIFLEX is not set
CONFIG_PATA_VIA=m
# CONFIG_PATA_WINBOND is not set
#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_PATA_RZ1000 is not set
#
# Generic fallback / legacy drivers
#
CONFIG_PATA_ACPI=m
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_LEGACY is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
# CONFIG_MD_CLUSTER is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_MQ_DEFAULT is not set
CONFIG_DM_DEBUG=y
CONFIG_DM_BUFIO=m
# CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING is not set
CONFIG_DM_BIO_PRISON=m
CONFIG_DM_PERSISTENT_DATA=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_THIN_PROVISIONING=m
CONFIG_DM_CACHE=m
CONFIG_DM_CACHE_SMQ=m
# CONFIG_DM_ERA is not set
CONFIG_DM_MIRROR=m
CONFIG_DM_LOG_USERSPACE=m
CONFIG_DM_RAID=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_QL=m
CONFIG_DM_MULTIPATH_ST=m
CONFIG_DM_DELAY=m
CONFIG_DM_UEVENT=y
CONFIG_DM_FLAKEY=m
CONFIG_DM_VERITY=m
# CONFIG_DM_VERITY_FEC is not set
CONFIG_DM_SWITCH=m
# CONFIG_DM_LOG_WRITES is not set
# CONFIG_DM_INTEGRITY is not set
CONFIG_TARGET_CORE=m
CONFIG_TCM_IBLOCK=m
CONFIG_TCM_FILEIO=m
CONFIG_TCM_PSCSI=m
# CONFIG_TCM_USER2 is not set
CONFIG_LOOPBACK_TARGET=m
CONFIG_TCM_FC=m
CONFIG_ISCSI_TARGET=m
# CONFIG_ISCSI_TARGET_CXGB4 is not set
# CONFIG_SBP_TARGET is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LOGGING=y
#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
CONFIG_FIREWIRE_NET=m
# CONFIG_FIREWIRE_NOSY is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_MII=y
CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
# CONFIG_EQUALIZER is not set
CONFIG_NET_FC=y
CONFIG_IFB=m
CONFIG_NET_TEAM=m
CONFIG_NET_TEAM_MODE_BROADCAST=m
CONFIG_NET_TEAM_MODE_ROUNDROBIN=m
CONFIG_NET_TEAM_MODE_RANDOM=m
CONFIG_NET_TEAM_MODE_ACTIVEBACKUP=m
CONFIG_NET_TEAM_MODE_LOADBALANCE=m
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_VXLAN=m
# CONFIG_GENEVE is not set
# CONFIG_GTP is not set
# CONFIG_MACSEC is not set
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
CONFIG_TAP=m
# CONFIG_TUN_VNET_CROSS_LE is not set
CONFIG_VETH=m
CONFIG_VIRTIO_NET=y
CONFIG_NLMON=m
# CONFIG_ARCNET is not set
# CONFIG_ATM_DRIVERS is not set
#
# CAIF transport drivers
#
#
# Distributed Switch Architecture drivers
#
CONFIG_ETHERNET=y
CONFIG_MDIO=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
CONFIG_NET_VENDOR_AGERE=y
# CONFIG_ET131X is not set
CONFIG_NET_VENDOR_ALACRITECH=y
# CONFIG_SLICOSS is not set
# CONFIG_NET_VENDOR_ALTEON is not set
# CONFIG_ALTERA_TSE is not set
CONFIG_NET_VENDOR_AMAZON=y
# CONFIG_ENA_ETHERNET is not set
# CONFIG_NET_VENDOR_AMD is not set
CONFIG_NET_VENDOR_AQUANTIA=y
# CONFIG_AQTION is not set
CONFIG_NET_VENDOR_ARC=y
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATL2=m
CONFIG_ATL1=m
CONFIG_ATL1E=m
CONFIG_ATL1C=m
CONFIG_ALX=m
# CONFIG_NET_VENDOR_AURORA is not set
CONFIG_NET_CADENCE=y
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
# CONFIG_BCMGENET is not set
CONFIG_BNX2=m
CONFIG_CNIC=m
CONFIG_TIGON3=y
CONFIG_TIGON3_HWMON=y
# CONFIG_BNX2X is not set
# CONFIG_BNXT is not set
CONFIG_NET_VENDOR_BROCADE=y
CONFIG_BNA=m
CONFIG_NET_VENDOR_CAVIUM=y
# CONFIG_THUNDER_NIC_PF is not set
# CONFIG_THUNDER_NIC_VF is not set
# CONFIG_THUNDER_NIC_BGX is not set
# CONFIG_THUNDER_NIC_RGX is not set
# CONFIG_LIQUIDIO is not set
# CONFIG_LIQUIDIO_VF is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3=m
CONFIG_CHELSIO_T4=m
# CONFIG_CHELSIO_T4_DCB is not set
CONFIG_CHELSIO_T4VF=m
CONFIG_CHELSIO_LIB=m
CONFIG_NET_VENDOR_CISCO=y
CONFIG_ENIC=m
# CONFIG_CX_ECAT is not set
CONFIG_DNET=m
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_DE2104X_DSL=0
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
# CONFIG_NET_VENDOR_DLINK is not set
CONFIG_NET_VENDOR_EMULEX=y
CONFIG_BE2NET=m
CONFIG_BE2NET_HWMON=y
CONFIG_NET_VENDOR_EZCHIP=y
# CONFIG_NET_VENDOR_EXAR is not set
# CONFIG_NET_VENDOR_HP is not set
CONFIG_NET_VENDOR_INTEL=y
# CONFIG_E100 is not set
CONFIG_E1000=y
CONFIG_E1000E=y
CONFIG_E1000E_HWTS=y
CONFIG_IGB=y
CONFIG_IGB_HWMON=y
CONFIG_IGBVF=m
CONFIG_IXGB=m
CONFIG_IXGBE=y
CONFIG_IXGBE_HWMON=y
CONFIG_IXGBE_DCB=y
CONFIG_IXGBEVF=m
CONFIG_I40E=m
# CONFIG_I40E_DCB is not set
# CONFIG_I40EVF is not set
# CONFIG_FM10K is not set
# CONFIG_NET_VENDOR_I825XX is not set
CONFIG_JME=m
CONFIG_NET_VENDOR_MARVELL=y
CONFIG_MVMDIO=m
CONFIG_SKGE=m
CONFIG_SKGE_DEBUG=y
CONFIG_SKGE_GENESIS=y
CONFIG_SKY2=m
CONFIG_SKY2_DEBUG=y
CONFIG_NET_VENDOR_MELLANOX=y
CONFIG_MLX4_EN=m
CONFIG_MLX4_EN_DCB=y
CONFIG_MLX4_CORE=m
CONFIG_MLX4_DEBUG=y
# CONFIG_MLX5_CORE is not set
# CONFIG_MLXSW_CORE is not set
# CONFIG_MLXFW is not set
# CONFIG_NET_VENDOR_MICREL is not set
CONFIG_NET_VENDOR_MICROCHIP=y
# CONFIG_ENC28J60 is not set
# CONFIG_ENCX24J600 is not set
CONFIG_NET_VENDOR_MYRI=y
CONFIG_MYRI10GE=m
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
CONFIG_NET_VENDOR_NETRONOME=y
# CONFIG_NFP is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
CONFIG_NET_VENDOR_OKI=y
CONFIG_ETHOC=m
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
CONFIG_YELLOWFIN=m
CONFIG_NET_VENDOR_QLOGIC=y
CONFIG_QLA3XXX=m
CONFIG_QLCNIC=m
CONFIG_QLCNIC_SRIOV=y
CONFIG_QLCNIC_DCB=y
CONFIG_QLCNIC_HWMON=y
CONFIG_QLGE=m
CONFIG_NETXEN_NIC=m
# CONFIG_QED is not set
CONFIG_NET_VENDOR_QUALCOMM=y
# CONFIG_QCOM_EMAC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_ATP is not set
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R8169=y
CONFIG_NET_VENDOR_RENESAS=y
# CONFIG_NET_VENDOR_RDC is not set
CONFIG_NET_VENDOR_ROCKER=y
CONFIG_NET_VENDOR_SAMSUNG=y
# CONFIG_SXGBE_ETH is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
# CONFIG_NET_VENDOR_SIS is not set
CONFIG_NET_VENDOR_SOLARFLARE=y
CONFIG_SFC=m
CONFIG_SFC_MTD=y
CONFIG_SFC_MCDI_MON=y
CONFIG_SFC_SRIOV=y
CONFIG_SFC_MCDI_LOGGING=y
# CONFIG_SFC_FALCON is not set
CONFIG_NET_VENDOR_SMSC=y
CONFIG_EPIC100=m
# CONFIG_SMSC911X is not set
CONFIG_SMSC9420=m
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_NET_VENDOR_SYNOPSYS=y
# CONFIG_DWC_XLGMAC is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_MDIO_DEVICE=y
CONFIG_MDIO_BITBANG=m
# CONFIG_MDIO_GPIO is not set
# CONFIG_MDIO_THUNDER is not set
CONFIG_PHYLIB=y
CONFIG_SWPHY=y
# CONFIG_LED_TRIGGER_PHY is not set
#
# MII PHY device drivers
#
CONFIG_AMD_PHY=m
# CONFIG_AQUANTIA_PHY is not set
CONFIG_AT803X_PHY=m
# CONFIG_BCM7XXX_PHY is not set
CONFIG_BCM87XX_PHY=m
CONFIG_BCM_NET_PHYLIB=m
CONFIG_BROADCOM_PHY=m
CONFIG_CICADA_PHY=m
# CONFIG_CORTINA_PHY is not set
CONFIG_DAVICOM_PHY=m
# CONFIG_DP83848_PHY is not set
# CONFIG_DP83867_PHY is not set
CONFIG_FIXED_PHY=y
CONFIG_ICPLUS_PHY=m
# CONFIG_INTEL_XWAY_PHY is not set
CONFIG_LSI_ET1011C_PHY=m
CONFIG_LXT_PHY=m
CONFIG_MARVELL_PHY=m
# CONFIG_MARVELL_10G_PHY is not set
CONFIG_MICREL_PHY=m
# CONFIG_MICROCHIP_PHY is not set
# CONFIG_MICROSEMI_PHY is not set
CONFIG_NATIONAL_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_REALTEK_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_STE10XP=m
# CONFIG_TERANETICS_PHY is not set
CONFIG_VITESSE_PHY=m
# CONFIG_XILINX_GMII2RGMII is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_MPPE=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPPOATM=m
CONFIG_PPPOE=m
CONFIG_PPTP=m
CONFIG_PPPOL2TP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_SLIP=m
CONFIG_SLHC=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_USB_NET_DRIVERS=y
CONFIG_USB_CATC=y
CONFIG_USB_KAWETH=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8150=y
CONFIG_USB_RTL8152=m
# CONFIG_USB_LAN78XX is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_AX88179_178A=m
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=m
# CONFIG_USB_NET_HUAWEI_CDC_NCM is not set
CONFIG_USB_NET_CDC_MBIM=m
CONFIG_USB_NET_DM9601=y
# CONFIG_USB_NET_SR9700 is not set
# CONFIG_USB_NET_SR9800 is not set
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_USB_NET_GL620A=y
CONFIG_USB_NET_NET1080=y
CONFIG_USB_NET_PLUSB=y
CONFIG_USB_NET_MCS7830=y
CONFIG_USB_NET_RNDIS_HOST=y
CONFIG_USB_NET_CDC_SUBSET_ENABLE=y
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
CONFIG_USB_NET_CX82310_ETH=m
CONFIG_USB_NET_KALMIA=m
CONFIG_USB_NET_QMI_WWAN=m
CONFIG_USB_HSO=m
CONFIG_USB_NET_INT51X1=y
CONFIG_USB_IPHETH=y
CONFIG_USB_SIERRA_NET=y
CONFIG_USB_VL600=m
# CONFIG_USB_NET_CH9200 is not set
CONFIG_WLAN=y
# CONFIG_WIRELESS_WDS is not set
CONFIG_WLAN_VENDOR_ADMTEK=y
# CONFIG_ADM8211 is not set
CONFIG_WLAN_VENDOR_ATH=y
# CONFIG_ATH_DEBUG is not set
# CONFIG_ATH5K is not set
# CONFIG_ATH5K_PCI is not set
# CONFIG_ATH9K is not set
# CONFIG_ATH9K_HTC is not set
# CONFIG_CARL9170 is not set
# CONFIG_ATH6KL is not set
# CONFIG_AR5523 is not set
# CONFIG_WIL6210 is not set
# CONFIG_ATH10K is not set
# CONFIG_WCN36XX is not set
CONFIG_WLAN_VENDOR_ATMEL=y
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
CONFIG_WLAN_VENDOR_BROADCOM=y
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMSMAC is not set
# CONFIG_BRCMFMAC is not set
CONFIG_WLAN_VENDOR_CISCO=y
# CONFIG_AIRO is not set
CONFIG_WLAN_VENDOR_INTEL=y
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_IWL4965 is not set
# CONFIG_IWL3945 is not set
# CONFIG_IWLWIFI is not set
CONFIG_WLAN_VENDOR_INTERSIL=y
# CONFIG_HOSTAP is not set
# CONFIG_HERMES is not set
# CONFIG_P54_COMMON is not set
# CONFIG_PRISM54 is not set
CONFIG_WLAN_VENDOR_MARVELL=y
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_MWIFIEX is not set
# CONFIG_MWL8K is not set
CONFIG_WLAN_VENDOR_MEDIATEK=y
# CONFIG_MT7601U is not set
CONFIG_WLAN_VENDOR_RALINK=y
# CONFIG_RT2X00 is not set
CONFIG_WLAN_VENDOR_REALTEK=y
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
CONFIG_RTL_CARDS=m
# CONFIG_RTL8192CE is not set
# CONFIG_RTL8192SE is not set
# CONFIG_RTL8192DE is not set
# CONFIG_RTL8723AE is not set
# CONFIG_RTL8723BE is not set
# CONFIG_RTL8188EE is not set
# CONFIG_RTL8192EE is not set
# CONFIG_RTL8821AE is not set
# CONFIG_RTL8192CU is not set
# CONFIG_RTL8XXXU is not set
CONFIG_WLAN_VENDOR_RSI=y
# CONFIG_RSI_91X is not set
CONFIG_WLAN_VENDOR_ST=y
# CONFIG_CW1200 is not set
CONFIG_WLAN_VENDOR_TI=y
# CONFIG_WL1251 is not set
# CONFIG_WL12XX is not set
# CONFIG_WL18XX is not set
# CONFIG_WLCORE is not set
CONFIG_WLAN_VENDOR_ZYDAS=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_ZD1211RW is not set
CONFIG_WLAN_VENDOR_QUANTENNA=y
# CONFIG_QTNFMAC_PEARL_PCIE is not set
CONFIG_MAC80211_HWSIM=m
# CONFIG_USB_NET_RNDIS_WLAN is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
CONFIG_WAN=y
# CONFIG_LANMEDIA is not set
CONFIG_HDLC=m
CONFIG_HDLC_RAW=m
# CONFIG_HDLC_RAW_ETH is not set
CONFIG_HDLC_CISCO=m
CONFIG_HDLC_FR=m
CONFIG_HDLC_PPP=m
#
# X.25/LAPB support is disabled
#
# CONFIG_PCI200SYN is not set
# CONFIG_WANXL is not set
# CONFIG_PC300TOO is not set
# CONFIG_FARSYNC is not set
# CONFIG_DSCC4 is not set
CONFIG_DLCI=m
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
CONFIG_IEEE802154_DRIVERS=m
CONFIG_IEEE802154_FAKELB=m
# CONFIG_IEEE802154_AT86RF230 is not set
# CONFIG_IEEE802154_MRF24J40 is not set
# CONFIG_IEEE802154_CC2520 is not set
# CONFIG_IEEE802154_ATUSB is not set
# CONFIG_IEEE802154_ADF7242 is not set
# CONFIG_IEEE802154_CA8210 is not set
CONFIG_XEN_NETDEV_FRONTEND=m
# CONFIG_XEN_NETDEV_BACKEND is not set
CONFIG_VMXNET3=m
# CONFIG_FUJITSU_ES is not set
CONFIG_HYPERV_NET=m
CONFIG_ISDN=y
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y
#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m
#
# ISDN4Linux hardware drivers
#
#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set
CONFIG_ISDN_CAPI=m
# CONFIG_CAPI_TRACE is not set
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPIDRV=m
# CONFIG_ISDN_CAPI_CAPIDRV_VERBOSE is not set
#
# CAPI hardware drivers
#
CONFIG_CAPI_AVM=y
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
# CONFIG_CAPI_EICON is not set
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_CAPI=y
# CONFIG_GIGASET_I4L is not set
# CONFIG_GIGASET_DUMMYLL is not set
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
CONFIG_GIGASET_M101=m
# CONFIG_GIGASET_DEBUG is not set
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
CONFIG_MISDN=m
CONFIG_MISDN_DSP=m
CONFIG_MISDN_L1OIP=m
#
# mISDN hardware drivers
#
CONFIG_MISDN_HFCPCI=m
CONFIG_MISDN_HFCMULTI=m
CONFIG_MISDN_HFCUSB=m
CONFIG_MISDN_AVMFRITZ=m
CONFIG_MISDN_SPEEDFAX=m
CONFIG_MISDN_INFINEON=m
CONFIG_MISDN_W6692=m
CONFIG_MISDN_NETJET=m
CONFIG_MISDN_IPAC=m
CONFIG_MISDN_ISAR=m
CONFIG_ISDN_HDLC=m
# CONFIG_NVM is not set
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_LEDS=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
CONFIG_INPUT_SPARSEKMAP=m
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_DLINK_DIR685 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_TM2_TOUCHKEY is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_BYD=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_PS2_SENTELIC=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_PS2_FOCALTECH=y
# CONFIG_MOUSE_PS2_VMMOUSE is not set
CONFIG_MOUSE_PS2_SMBUS=y
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_APPLETOUCH=m
CONFIG_MOUSE_BCM5974=m
CONFIG_MOUSE_CYAPA=m
# CONFIG_MOUSE_ELAN_I2C is not set
CONFIG_MOUSE_VSXXXAA=m
# CONFIG_MOUSE_GPIO is not set
CONFIG_MOUSE_SYNAPTICS_I2C=m
CONFIG_MOUSE_SYNAPTICS_USB=m
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
CONFIG_TABLET_USB_ACECAD=m
CONFIG_TABLET_USB_AIPTEK=m
CONFIG_TABLET_USB_GTCO=m
# CONFIG_TABLET_USB_HANWANG is not set
CONFIG_TABLET_USB_KBTAB=m
# CONFIG_TABLET_USB_PEGASUS is not set
# CONFIG_TABLET_SERIAL_WACOM4 is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_PROPERTIES=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX_SERIAL is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GOODIX is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_EKTF2127 is not set
# CONFIG_TOUCHSCREEN_ELAN is not set
# CONFIG_TOUCHSCREEN_ELO is not set
CONFIG_TOUCHSCREEN_WACOM_W8001=m
CONFIG_TOUCHSCREEN_WACOM_I2C=m
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MELFAS_MIP4 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_WDT87XX_I2C is not set
# CONFIG_TOUCHSCREEN_WM97XX is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2004 is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_RM_TS is not set
# CONFIG_TOUCHSCREEN_SILEAD is not set
# CONFIG_TOUCHSCREEN_SIS_I2C is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_STMFTS is not set
# CONFIG_TOUCHSCREEN_SUR40 is not set
# CONFIG_TOUCHSCREEN_SURFACE3_SPI is not set
# CONFIG_TOUCHSCREEN_SX8654 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_TOUCHSCREEN_ZET6223 is not set
# CONFIG_TOUCHSCREEN_ZFORCE is not set
# CONFIG_TOUCHSCREEN_ROHM_BU21023 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_E3X0_BUTTON is not set
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_MMA8450 is not set
CONFIG_INPUT_APANEL=m
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_BEEPER is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_GPIO_DECODER is not set
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
# CONFIG_INPUT_KXTJ9 is not set
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_YEALINK=m
CONFIG_INPUT_CM109=m
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_PWM_BEEPER is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_IMS_PCU is not set
# CONFIG_INPUT_CMA3000 is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
# CONFIG_INPUT_IDEAPAD_SLIDEBAR is not set
# CONFIG_INPUT_DRV260X_HAPTICS is not set
# CONFIG_INPUT_DRV2665_HAPTICS is not set
# CONFIG_INPUT_DRV2667_HAPTICS is not set
# CONFIG_RMI4_CORE is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
# CONFIG_SERIO_PS2MULT is not set
CONFIG_SERIO_ARC_PS2=m
CONFIG_HYPERV_KEYBOARD=m
# CONFIG_USERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_NOZOMI=m
# CONFIG_ISI is not set
CONFIG_N_HDLC=m
CONFIG_N_GSM=m
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
# CONFIG_DEVKMEM is not set
#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_EXAR=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_FSL is not set
CONFIG_SERIAL_8250_DW=y
# CONFIG_SERIAL_8250_RT288X is not set
CONFIG_SERIAL_8250_LPSS=y
CONFIG_SERIAL_8250_MID=y
# CONFIG_SERIAL_8250_MOXA is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
CONFIG_SERIAL_ARC=m
CONFIG_SERIAL_ARC_NR_PORTS=1
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_DEV_BUS is not set
# CONFIG_TTY_PRINTK is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
# CONFIG_IPMI_SSIF is not set
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_HW_RANDOM_TPM=m
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
# CONFIG_HPET_MMAP_DEFAULT is not set
CONFIG_HANGCHECK_TIMER=m
CONFIG_UV_MMTIMER=m
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS=y
# CONFIG_TCG_TIS_SPI is not set
# CONFIG_TCG_TIS_I2C_ATMEL is not set
# CONFIG_TCG_TIS_I2C_INFINEON is not set
# CONFIG_TCG_TIS_I2C_NUVOTON is not set
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
# CONFIG_TCG_XEN is not set
# CONFIG_TCG_CRB is not set
# CONFIG_TCG_VTPM_PROXY is not set
# CONFIG_TCG_TIS_ST33ZP24_I2C is not set
# CONFIG_TCG_TIS_ST33ZP24_SPI is not set
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_ACPI_I2C_OPREGION=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_MUX=m
#
# Multiplexer I2C Chip support
#
# CONFIG_I2C_MUX_GPIO is not set
# CONFIG_I2C_MUX_LTC4306 is not set
# CONFIG_I2C_MUX_PCA9541 is not set
# CONFIG_I2C_MUX_PCA954x is not set
# CONFIG_I2C_MUX_PINCTRL is not set
# CONFIG_I2C_MUX_REG is not set
# CONFIG_I2C_MUX_MLXCPLD is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=y
CONFIG_I2C_ISCH=m
CONFIG_I2C_ISMT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
#
# ACPI drivers
#
CONFIG_I2C_SCMI=m
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DESIGNWARE_CORE=m
CONFIG_I2C_DESIGNWARE_PLATFORM=m
CONFIG_I2C_DESIGNWARE_PCI=m
# CONFIG_I2C_DESIGNWARE_BAYTRAIL is not set
# CONFIG_I2C_EMEV2 is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PCA_PLATFORM=m
# CONFIG_I2C_PXA_PCI is not set
CONFIG_I2C_SIMTEC=m
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_DIOLAN_U2C=m
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_ROBOTFUZZ_OSIF is not set
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m
CONFIG_I2C_VIPERBOARD=m
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_MLXCPLD is not set
CONFIG_I2C_STUB=m
# CONFIG_I2C_SLAVE is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_AXI_SPI_ENGINE is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_BUTTERFLY is not set
# CONFIG_SPI_CADENCE is not set
CONFIG_SPI_DESIGNWARE=m
# CONFIG_SPI_DW_PCI is not set
# CONFIG_SPI_DW_MMIO is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_LM70_LLP is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_PXA2XX=m
CONFIG_SPI_PXA2XX_PCI=m
# CONFIG_SPI_ROCKCHIP is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_ZYNQMP_GQSPI is not set
#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_LOOPBACK_TEST is not set
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_SPI_SLAVE is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
CONFIG_PPS_CLIENT_PARPORT=m
CONFIG_PPS_CLIENT_GPIO=m
#
# PPS generators support
#
#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y
CONFIG_DP83640_PHY=m
CONFIG_PTP_1588_CLOCK_KVM=y
CONFIG_PINCTRL=y
#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
# CONFIG_PINCTRL_AMD is not set
# CONFIG_PINCTRL_MCP23S08 is not set
# CONFIG_PINCTRL_SX150X is not set
CONFIG_PINCTRL_BAYTRAIL=y
# CONFIG_PINCTRL_CHERRYVIEW is not set
# CONFIG_PINCTRL_BROXTON is not set
# CONFIG_PINCTRL_CANNONLAKE is not set
# CONFIG_PINCTRL_GEMINILAKE is not set
# CONFIG_PINCTRL_SUNRISEPOINT is not set
CONFIG_GPIOLIB=y
CONFIG_GPIO_ACPI=y
CONFIG_GPIOLIB_IRQCHIP=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y
#
# Memory mapped GPIO drivers
#
# CONFIG_GPIO_AMDPT is not set
# CONFIG_GPIO_DWAPB is not set
# CONFIG_GPIO_EXAR is not set
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_ICH is not set
CONFIG_GPIO_LYNXPOINT=m
CONFIG_GPIO_MOCKUP=y
# CONFIG_GPIO_VX855 is not set
#
# Port-mapped I/O GPIO drivers
#
# CONFIG_GPIO_F7188X is not set
# CONFIG_GPIO_IT87 is not set
# CONFIG_GPIO_SCH is not set
# CONFIG_GPIO_SCH311X is not set
#
# I2C GPIO expanders
#
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_TPIC2810 is not set
#
# MFD GPIO expanders
#
#
# PCI GPIO expanders
#
# CONFIG_GPIO_AMD8111 is not set
# CONFIG_GPIO_ML_IOH is not set
# CONFIG_GPIO_PCI_IDIO_16 is not set
# CONFIG_GPIO_RDC321X is not set
#
# SPI GPIO expanders
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_PISOSR is not set
# CONFIG_GPIO_XRA1403 is not set
#
# USB GPIO expanders
#
# CONFIG_GPIO_VIPERBOARD is not set
# CONFIG_W1 is not set
# CONFIG_POWER_AVS is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_CHARGER_SBS is not set
# CONFIG_BATTERY_BQ27XXX is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_ISP1704 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_LTC3651 is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_BQ24190 is not set
# CONFIG_CHARGER_BQ24257 is not set
# CONFIG_CHARGER_BQ24735 is not set
# CONFIG_CHARGER_BQ25890 is not set
CONFIG_CHARGER_SMB347=m
# CONFIG_BATTERY_GAUGE_LTC2941 is not set
# CONFIG_CHARGER_RT9455 is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Native drivers
#
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
# CONFIG_SENSORS_AD7314 is not set
CONFIG_SENSORS_AD7414=m
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7X10=m
# CONFIG_SENSORS_ADT7310 is not set
CONFIG_SENSORS_ADT7410=m
CONFIG_SENSORS_ADT7411=m
CONFIG_SENSORS_ADT7462=m
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_ADT7475=m
CONFIG_SENSORS_ASC7621=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_K10TEMP=m
CONFIG_SENSORS_FAM15H_POWER=m
CONFIG_SENSORS_APPLESMC=m
CONFIG_SENSORS_ASB100=m
# CONFIG_SENSORS_ASPEED is not set
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS620=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_DELL_SMM=m
CONFIG_SENSORS_I5K_AMB=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
CONFIG_SENSORS_FSCHMD=m
# CONFIG_SENSORS_FTSTEUTATES is not set
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_G760A=m
# CONFIG_SENSORS_G762 is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_HIH6130 is not set
CONFIG_SENSORS_IBMAEM=m
CONFIG_SENSORS_IBMPEX=m
# CONFIG_SENSORS_I5500 is not set
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_POWR1220 is not set
CONFIG_SENSORS_LINEAGE=m
# CONFIG_SENSORS_LTC2945 is not set
# CONFIG_SENSORS_LTC2990 is not set
CONFIG_SENSORS_LTC4151=m
CONFIG_SENSORS_LTC4215=m
# CONFIG_SENSORS_LTC4222 is not set
CONFIG_SENSORS_LTC4245=m
# CONFIG_SENSORS_LTC4260 is not set
CONFIG_SENSORS_LTC4261=m
# CONFIG_SENSORS_MAX1111 is not set
CONFIG_SENSORS_MAX16065=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_MAX1668=m
CONFIG_SENSORS_MAX197=m
# CONFIG_SENSORS_MAX31722 is not set
CONFIG_SENSORS_MAX6639=m
CONFIG_SENSORS_MAX6642=m
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_MAX6697=m
# CONFIG_SENSORS_MAX31790 is not set
CONFIG_SENSORS_MCP3021=m
# CONFIG_SENSORS_TC654 is not set
# CONFIG_SENSORS_ADCXX is not set
CONFIG_SENSORS_LM63=m
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_LM93=m
CONFIG_SENSORS_LM95234=m
CONFIG_SENSORS_LM95241=m
CONFIG_SENSORS_LM95245=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_NTC_THERMISTOR=m
# CONFIG_SENSORS_NCT6683 is not set
CONFIG_SENSORS_NCT6775=m
# CONFIG_SENSORS_NCT7802 is not set
# CONFIG_SENSORS_NCT7904 is not set
CONFIG_SENSORS_PCF8591=m
CONFIG_PMBUS=m
CONFIG_SENSORS_PMBUS=m
CONFIG_SENSORS_ADM1275=m
# CONFIG_SENSORS_IR35221 is not set
CONFIG_SENSORS_LM25066=m
CONFIG_SENSORS_LTC2978=m
# CONFIG_SENSORS_LTC3815 is not set
CONFIG_SENSORS_MAX16064=m
# CONFIG_SENSORS_MAX20751 is not set
CONFIG_SENSORS_MAX34440=m
CONFIG_SENSORS_MAX8688=m
# CONFIG_SENSORS_TPS40422 is not set
CONFIG_SENSORS_UCD9000=m
CONFIG_SENSORS_UCD9200=m
CONFIG_SENSORS_ZL6100=m
# CONFIG_SENSORS_SHT15 is not set
CONFIG_SENSORS_SHT21=m
# CONFIG_SENSORS_SHT3x is not set
# CONFIG_SENSORS_SHTC1 is not set
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_DME1737=m
CONFIG_SENSORS_EMC1403=m
# CONFIG_SENSORS_EMC2103 is not set
CONFIG_SENSORS_EMC6W201=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_SCH56XX_COMMON=m
CONFIG_SENSORS_SCH5627=m
CONFIG_SENSORS_SCH5636=m
# CONFIG_SENSORS_STTS751 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_ADC128D818 is not set
CONFIG_SENSORS_ADS1015=m
CONFIG_SENSORS_ADS7828=m
# CONFIG_SENSORS_ADS7871 is not set
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA209=m
CONFIG_SENSORS_INA2XX=m
# CONFIG_SENSORS_INA3221 is not set
# CONFIG_SENSORS_TC74 is not set
CONFIG_SENSORS_THMC50=m
CONFIG_SENSORS_TMP102=m
# CONFIG_SENSORS_TMP103 is not set
# CONFIG_SENSORS_TMP108 is not set
CONFIG_SENSORS_TMP401=m
CONFIG_SENSORS_TMP421=m
CONFIG_SENSORS_VIA_CPUTEMP=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83795=m
# CONFIG_SENSORS_W83795_FANCTRL is not set
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83L786NG=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
# CONFIG_SENSORS_XGENE is not set
#
# ACPI drivers
#
CONFIG_SENSORS_ACPI_POWER=m
CONFIG_SENSORS_ATK0110=m
CONFIG_THERMAL=y
CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_WRITABLE_TRIPS=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set
CONFIG_THERMAL_GOV_FAIR_SHARE=y
CONFIG_THERMAL_GOV_STEP_WISE=y
CONFIG_THERMAL_GOV_BANG_BANG=y
CONFIG_THERMAL_GOV_USER_SPACE=y
# CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_EMULATION is not set
CONFIG_INTEL_POWERCLAMP=m
CONFIG_X86_PKG_TEMP_THERMAL=m
# CONFIG_INTEL_SOC_DTS_THERMAL is not set
#
# ACPI INT340X thermal drivers
#
# CONFIG_INT340X_THERMAL is not set
CONFIG_INTEL_PCH_THERMAL=m
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
# CONFIG_WATCHDOG_SYSFS is not set
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_WDAT_WDT is not set
# CONFIG_XILINX_WATCHDOG is not set
# CONFIG_ZIIRAVE_WATCHDOG is not set
# CONFIG_CADENCE_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_F71808E_WDT=m
CONFIG_SP5100_TCO=m
CONFIG_SBC_FITPC2_WATCHDOG=m
# CONFIG_EUROTECH_WDT is not set
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=y
CONFIG_IE6XX_WDT=m
CONFIG_ITCO_WDT=y
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_IT8712F_WDT=m
CONFIG_IT87_WDT=m
CONFIG_HP_WATCHDOG=m
CONFIG_HPWDT_NMI_DECODING=y
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
CONFIG_NV_TCO=m
# CONFIG_60XX_WDT is not set
# CONFIG_CPU5_WDT is not set
CONFIG_SMSC_SCH311X_WDT=m
# CONFIG_SMSC37B787_WDT is not set
CONFIG_VIA_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
# CONFIG_INTEL_MEI_WDT is not set
# CONFIG_NI903X_WDT is not set
# CONFIG_NIC7018_WDT is not set
# CONFIG_MEN_A21_WDT is not set
CONFIG_XEN_WDT=m
#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
#
# Watchdog Pretimeout Governors
#
# CONFIG_WATCHDOG_PRETIMEOUT_GOV is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
CONFIG_SSB_SDIOHOST_POSSIBLE=y
CONFIG_SSB_SDIOHOST=y
# CONFIG_SSB_SILENT is not set
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y
# CONFIG_SSB_DRIVER_GPIO is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
CONFIG_BCMA=m
CONFIG_BCMA_HOST_PCI_POSSIBLE=y
CONFIG_BCMA_HOST_PCI=y
# CONFIG_BCMA_HOST_SOC is not set
CONFIG_BCMA_DRIVER_PCI=y
CONFIG_BCMA_DRIVER_GMAC_CMN=y
# CONFIG_BCMA_DRIVER_GPIO is not set
# CONFIG_BCMA_DEBUG is not set
#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_BCM590XX is not set
# CONFIG_MFD_AXP20X_I2C is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9062 is not set
# CONFIG_MFD_DA9063 is not set
# CONFIG_MFD_DA9150 is not set
# CONFIG_MFD_DLN2 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_INTEL_QUARK_I2C_GPIO is not set
CONFIG_LPC_ICH=y
CONFIG_LPC_SCH=m
# CONFIG_INTEL_SOC_PMIC is not set
# CONFIG_INTEL_SOC_PMIC_CHTWC is not set
# CONFIG_MFD_INTEL_LPSS_ACPI is not set
# CONFIG_MFD_INTEL_LPSS_PCI is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX14577 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX77843 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_MENF21BMC is not set
# CONFIG_EZX_PCAP is not set
CONFIG_MFD_VIPERBOARD=m
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_UCB1400_CORE is not set
# CONFIG_MFD_RDC321X is not set
CONFIG_MFD_RTSX_PCI=m
# CONFIG_MFD_RT5033 is not set
# CONFIG_MFD_RTSX_USB is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
CONFIG_MFD_SM501=m
# CONFIG_MFD_SM501_GPIO is not set
# CONFIG_MFD_SKY81452 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP3943 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_TI_LMU is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65086 is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TI_LP873X is not set
# CONFIG_MFD_TPS65218 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TMIO is not set
CONFIG_MFD_VX855=m
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_REGULATOR is not set
CONFIG_MEDIA_SUPPORT=m
#
# Multimedia core support
#
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_RADIO_SUPPORT=y
# CONFIG_MEDIA_SDR_SUPPORT is not set
CONFIG_MEDIA_RC_SUPPORT=y
# CONFIG_MEDIA_CEC_SUPPORT is not set
# CONFIG_MEDIA_CONTROLLER is not set
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2=m
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEOBUF_VMALLOC=m
CONFIG_VIDEOBUF_DVB=m
CONFIG_VIDEOBUF2_CORE=m
CONFIG_VIDEOBUF2_MEMOPS=m
CONFIG_VIDEOBUF2_VMALLOC=m
CONFIG_VIDEOBUF2_DMA_SG=m
CONFIG_VIDEOBUF2_DVB=m
CONFIG_DVB_CORE=m
CONFIG_DVB_NET=y
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_MAX_ADAPTERS=8
CONFIG_DVB_DYNAMIC_MINORS=y
# CONFIG_DVB_DEMUX_SECTION_LOSS_LOG is not set
#
# Media drivers
#
CONFIG_RC_CORE=m
CONFIG_RC_MAP=m
CONFIG_RC_DECODERS=y
CONFIG_LIRC=m
CONFIG_IR_LIRC_CODEC=m
CONFIG_IR_NEC_DECODER=m
CONFIG_IR_RC5_DECODER=m
CONFIG_IR_RC6_DECODER=m
CONFIG_IR_JVC_DECODER=m
CONFIG_IR_SONY_DECODER=m
CONFIG_IR_SANYO_DECODER=m
CONFIG_IR_SHARP_DECODER=m
CONFIG_IR_MCE_KBD_DECODER=m
CONFIG_IR_XMP_DECODER=m
CONFIG_RC_DEVICES=y
CONFIG_RC_ATI_REMOTE=m
CONFIG_IR_ENE=m
# CONFIG_IR_HIX5HD2 is not set
CONFIG_IR_IMON=m
CONFIG_IR_MCEUSB=m
CONFIG_IR_ITE_CIR=m
CONFIG_IR_FINTEK=m
CONFIG_IR_NUVOTON=m
CONFIG_IR_REDRAT3=m
# CONFIG_IR_SPI is not set
CONFIG_IR_STREAMZAP=m
CONFIG_IR_WINBOND_CIR=m
# CONFIG_IR_IGORPLUGUSB is not set
CONFIG_IR_IGUANA=m
CONFIG_IR_TTUSBIR=m
# CONFIG_RC_LOOPBACK is not set
CONFIG_IR_GPIO_CIR=m
# CONFIG_IR_SERIAL is not set
# CONFIG_IR_SIR is not set
CONFIG_MEDIA_USB_SUPPORT=y
#
# Webcam devices
#
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_GSPCA=m
CONFIG_USB_M5602=m
CONFIG_USB_STV06XX=m
CONFIG_USB_GL860=m
CONFIG_USB_GSPCA_BENQ=m
CONFIG_USB_GSPCA_CONEX=m
CONFIG_USB_GSPCA_CPIA1=m
# CONFIG_USB_GSPCA_DTCS033 is not set
CONFIG_USB_GSPCA_ETOMS=m
CONFIG_USB_GSPCA_FINEPIX=m
CONFIG_USB_GSPCA_JEILINJ=m
CONFIG_USB_GSPCA_JL2005BCD=m
# CONFIG_USB_GSPCA_KINECT is not set
CONFIG_USB_GSPCA_KONICA=m
CONFIG_USB_GSPCA_MARS=m
CONFIG_USB_GSPCA_MR97310A=m
CONFIG_USB_GSPCA_NW80X=m
CONFIG_USB_GSPCA_OV519=m
CONFIG_USB_GSPCA_OV534=m
CONFIG_USB_GSPCA_OV534_9=m
CONFIG_USB_GSPCA_PAC207=m
CONFIG_USB_GSPCA_PAC7302=m
CONFIG_USB_GSPCA_PAC7311=m
CONFIG_USB_GSPCA_SE401=m
CONFIG_USB_GSPCA_SN9C2028=m
CONFIG_USB_GSPCA_SN9C20X=m
CONFIG_USB_GSPCA_SONIXB=m
CONFIG_USB_GSPCA_SONIXJ=m
CONFIG_USB_GSPCA_SPCA500=m
CONFIG_USB_GSPCA_SPCA501=m
CONFIG_USB_GSPCA_SPCA505=m
CONFIG_USB_GSPCA_SPCA506=m
CONFIG_USB_GSPCA_SPCA508=m
CONFIG_USB_GSPCA_SPCA561=m
CONFIG_USB_GSPCA_SPCA1528=m
CONFIG_USB_GSPCA_SQ905=m
CONFIG_USB_GSPCA_SQ905C=m
CONFIG_USB_GSPCA_SQ930X=m
CONFIG_USB_GSPCA_STK014=m
# CONFIG_USB_GSPCA_STK1135 is not set
CONFIG_USB_GSPCA_STV0680=m
CONFIG_USB_GSPCA_SUNPLUS=m
CONFIG_USB_GSPCA_T613=m
CONFIG_USB_GSPCA_TOPRO=m
# CONFIG_USB_GSPCA_TOUPTEK is not set
CONFIG_USB_GSPCA_TV8532=m
CONFIG_USB_GSPCA_VC032X=m
CONFIG_USB_GSPCA_VICAM=m
CONFIG_USB_GSPCA_XIRLINK_CIT=m
CONFIG_USB_GSPCA_ZC3XX=m
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set
CONFIG_USB_PWC_INPUT_EVDEV=y
# CONFIG_VIDEO_CPIA2 is not set
CONFIG_USB_ZR364XX=m
CONFIG_USB_STKWEBCAM=m
CONFIG_USB_S2255=m
# CONFIG_VIDEO_USBTV is not set
#
# Analog TV USB devices
#
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_SYSFS=y
CONFIG_VIDEO_PVRUSB2_DVB=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_HDPVR=m
CONFIG_VIDEO_USBVISION=m
# CONFIG_VIDEO_STK1160_COMMON is not set
# CONFIG_VIDEO_GO7007 is not set
#
# Analog/digital TV USB devices
#
CONFIG_VIDEO_AU0828=m
CONFIG_VIDEO_AU0828_V4L2=y
# CONFIG_VIDEO_AU0828_RC is not set
CONFIG_VIDEO_CX231XX=m
CONFIG_VIDEO_CX231XX_RC=y
CONFIG_VIDEO_CX231XX_ALSA=m
CONFIG_VIDEO_CX231XX_DVB=m
CONFIG_VIDEO_TM6000=m
CONFIG_VIDEO_TM6000_ALSA=m
CONFIG_VIDEO_TM6000_DVB=m
#
# Digital TV USB devices
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_DIB3000MC=m
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
CONFIG_DVB_USB_M920X=m
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_TTUSB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_USB_OPERA1=m
CONFIG_DVB_USB_AF9005=m
CONFIG_DVB_USB_AF9005_REMOTE=m
CONFIG_DVB_USB_PCTV452E=m
CONFIG_DVB_USB_DW2102=m
CONFIG_DVB_USB_CINERGY_T2=m
CONFIG_DVB_USB_DTV5100=m
CONFIG_DVB_USB_FRIIO=m
CONFIG_DVB_USB_AZ6027=m
CONFIG_DVB_USB_TECHNISAT_USB2=m
CONFIG_DVB_USB_V2=m
CONFIG_DVB_USB_AF9015=m
CONFIG_DVB_USB_AF9035=m
CONFIG_DVB_USB_ANYSEE=m
CONFIG_DVB_USB_AU6610=m
CONFIG_DVB_USB_AZ6007=m
CONFIG_DVB_USB_CE6230=m
CONFIG_DVB_USB_EC168=m
CONFIG_DVB_USB_GL861=m
CONFIG_DVB_USB_LME2510=m
CONFIG_DVB_USB_MXL111SF=m
CONFIG_DVB_USB_RTL28XXU=m
# CONFIG_DVB_USB_DVBSKY is not set
# CONFIG_DVB_USB_ZD1301 is not set
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_SMS_USB_DRV=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_USB_DEBUG is not set
# CONFIG_DVB_AS102 is not set
#
# Webcam, TV (analog/digital) USB devices
#
CONFIG_VIDEO_EM28XX=m
# CONFIG_VIDEO_EM28XX_V4L2 is not set
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_DVB=m
CONFIG_VIDEO_EM28XX_RC=m
CONFIG_MEDIA_PCI_SUPPORT=y
#
# Media capture support
#
# CONFIG_VIDEO_MEYE is not set
# CONFIG_VIDEO_SOLO6X10 is not set
# CONFIG_VIDEO_TW5864 is not set
# CONFIG_VIDEO_TW68 is not set
# CONFIG_VIDEO_TW686X is not set
# CONFIG_VIDEO_ZORAN is not set
#
# Media capture/analog TV support
#
CONFIG_VIDEO_IVTV=m
# CONFIG_VIDEO_IVTV_DEPRECATED_IOCTLS is not set
# CONFIG_VIDEO_IVTV_ALSA is not set
CONFIG_VIDEO_FB_IVTV=m
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DT3155 is not set
#
# Media capture/analog/hybrid TV support
#
CONFIG_VIDEO_CX18=m
CONFIG_VIDEO_CX18_ALSA=m
CONFIG_VIDEO_CX23885=m
CONFIG_MEDIA_ALTERA_CI=m
# CONFIG_VIDEO_CX25821 is not set
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_ENABLE_VP3054=y
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CX88_MPEG=m
CONFIG_VIDEO_BT848=m
CONFIG_DVB_BT8XX=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_RC=y
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_SAA7164=m
#
# Media digital TV PCI Adapters
#
CONFIG_DVB_AV7110_IR=y
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET_CORE=m
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
# CONFIG_DVB_B2C2_FLEXCOP_PCI_DEBUG is not set
CONFIG_DVB_PLUTO2=m
CONFIG_DVB_DM1105=m
CONFIG_DVB_PT1=m
# CONFIG_DVB_PT3 is not set
CONFIG_MANTIS_CORE=m
CONFIG_DVB_MANTIS=m
CONFIG_DVB_HOPPER=m
CONFIG_DVB_NGENE=m
CONFIG_DVB_DDBRIDGE=m
# CONFIG_DVB_SMIPCIE is not set
# CONFIG_DVB_NETUP_UNIDVB is not set
# CONFIG_V4L_PLATFORM_DRIVERS is not set
# CONFIG_V4L_MEM2MEM_DRIVERS is not set
# CONFIG_V4L_TEST_DRIVERS is not set
# CONFIG_DVB_PLATFORM_DRIVERS is not set
#
# Supported MMC/SDIO adapters
#
CONFIG_SMS_SDIO_DRV=m
CONFIG_RADIO_ADAPTERS=y
CONFIG_RADIO_TEA575X=m
# CONFIG_RADIO_SI470X is not set
# CONFIG_RADIO_SI4713 is not set
# CONFIG_USB_MR800 is not set
# CONFIG_USB_DSBR is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_SHARK is not set
# CONFIG_RADIO_SHARK2 is not set
# CONFIG_USB_KEENE is not set
# CONFIG_USB_RAREMONO is not set
# CONFIG_USB_MA901 is not set
# CONFIG_RADIO_TEA5764 is not set
# CONFIG_RADIO_SAA7706H is not set
# CONFIG_RADIO_TEF6862 is not set
# CONFIG_RADIO_WL1273 is not set
#
# Texas Instruments WL128x FM driver (ST based)
#
#
# Supported FireWire (IEEE 1394) Adapters
#
CONFIG_DVB_FIREDTV=m
CONFIG_DVB_FIREDTV_INPUT=y
CONFIG_MEDIA_COMMON_OPTIONS=y
#
# common driver options
#
CONFIG_VIDEO_CX2341X=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_CYPRESS_FIRMWARE=m
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_SMS_SIANO_MDTV=m
CONFIG_SMS_SIANO_RC=y
# CONFIG_SMS_SIANO_DEBUGFS is not set
#
# Media ancillary drivers (tuners, sensors, i2c, spi, frontends)
#
CONFIG_MEDIA_SUBDRV_AUTOSELECT=y
CONFIG_MEDIA_ATTACH=y
CONFIG_VIDEO_IR_I2C=m
#
# Audio decoders, processors and mixers
#
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_CS3308=m
CONFIG_VIDEO_CS5345=m
CONFIG_VIDEO_CS53L32A=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_WM8739=m
CONFIG_VIDEO_VP27SMPX=m
#
# RDS decoders
#
CONFIG_VIDEO_SAA6588=m
#
# Video decoders
#
CONFIG_VIDEO_SAA711X=m
#
# Video and audio decoders
#
CONFIG_VIDEO_SAA717X=m
CONFIG_VIDEO_CX25840=m
#
# Video encoders
#
CONFIG_VIDEO_SAA7127=m
#
# Camera sensor devices
#
#
# Flash devices
#
#
# Video improvement chips
#
CONFIG_VIDEO_UPD64031A=m
CONFIG_VIDEO_UPD64083=m
#
# Audio/Video compression chips
#
CONFIG_VIDEO_SAA6752HS=m
#
# SDR tuner chips
#
#
# Miscellaneous helper chips
#
CONFIG_VIDEO_M52790=m
#
# Sensors used on soc_camera driver
#
CONFIG_MEDIA_TUNER=m
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA827X=m
CONFIG_MEDIA_TUNER_TDA18271=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_MT2060=m
CONFIG_MEDIA_TUNER_MT2063=m
CONFIG_MEDIA_TUNER_MT2266=m
CONFIG_MEDIA_TUNER_MT2131=m
CONFIG_MEDIA_TUNER_QT1010=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_XC4000=m
CONFIG_MEDIA_TUNER_MXL5005S=m
CONFIG_MEDIA_TUNER_MXL5007T=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_MEDIA_TUNER_MAX2165=m
CONFIG_MEDIA_TUNER_TDA18218=m
CONFIG_MEDIA_TUNER_FC0011=m
CONFIG_MEDIA_TUNER_FC0012=m
CONFIG_MEDIA_TUNER_FC0013=m
CONFIG_MEDIA_TUNER_TDA18212=m
CONFIG_MEDIA_TUNER_E4000=m
CONFIG_MEDIA_TUNER_FC2580=m
CONFIG_MEDIA_TUNER_M88RS6000T=m
CONFIG_MEDIA_TUNER_TUA9001=m
CONFIG_MEDIA_TUNER_SI2157=m
CONFIG_MEDIA_TUNER_IT913X=m
CONFIG_MEDIA_TUNER_R820T=m
CONFIG_MEDIA_TUNER_QM1D1C0042=m
#
# Multistandard (satellite) frontends
#
CONFIG_DVB_STB0899=m
CONFIG_DVB_STB6100=m
CONFIG_DVB_STV090x=m
CONFIG_DVB_STV6110x=m
CONFIG_DVB_M88DS3103=m
#
# Multistandard (cable + terrestrial) frontends
#
CONFIG_DVB_DRXK=m
CONFIG_DVB_TDA18271C2DD=m
CONFIG_DVB_SI2165=m
CONFIG_DVB_MN88472=m
CONFIG_DVB_MN88473=m
#
# DVB-S (satellite) frontends
#
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_MT312=m
CONFIG_DVB_ZL10036=m
CONFIG_DVB_ZL10039=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_STV0288=m
CONFIG_DVB_STB6000=m
CONFIG_DVB_STV0299=m
CONFIG_DVB_STV6110=m
CONFIG_DVB_STV0900=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA10086=m
CONFIG_DVB_TDA8261=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_TUNER_ITD1000=m
CONFIG_DVB_TUNER_CX24113=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUA6100=m
CONFIG_DVB_CX24116=m
CONFIG_DVB_CX24117=m
CONFIG_DVB_CX24120=m
CONFIG_DVB_SI21XX=m
CONFIG_DVB_TS2020=m
CONFIG_DVB_DS3000=m
CONFIG_DVB_MB86A16=m
CONFIG_DVB_TDA10071=m
#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_DRXD=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m
CONFIG_DVB_TDA10048=m
CONFIG_DVB_AF9013=m
CONFIG_DVB_EC100=m
CONFIG_DVB_STV0367=m
CONFIG_DVB_CXD2820R=m
CONFIG_DVB_CXD2841ER=m
CONFIG_DVB_RTL2830=m
CONFIG_DVB_RTL2832=m
CONFIG_DVB_SI2168=m
# CONFIG_DVB_AS102_FE is not set
CONFIG_DVB_GP8PSK_FE=m
#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_TDA10023=m
CONFIG_DVB_STV0297=m
#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m
CONFIG_DVB_LGDT3305=m
CONFIG_DVB_LGDT3306A=m
CONFIG_DVB_LG2160=m
CONFIG_DVB_S5H1409=m
CONFIG_DVB_AU8522=m
CONFIG_DVB_AU8522_DTV=m
CONFIG_DVB_AU8522_V4L=m
CONFIG_DVB_S5H1411=m
#
# ISDB-T (terrestrial) frontends
#
CONFIG_DVB_S921=m
CONFIG_DVB_DIB8000=m
CONFIG_DVB_MB86A20S=m
#
# ISDB-S (satellite) & ISDB-T (terrestrial) frontends
#
CONFIG_DVB_TC90522=m
#
# Digital terrestrial only tuners/PLL
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TUNER_DIB0070=m
CONFIG_DVB_TUNER_DIB0090=m
#
# SEC control devices for DVB-S
#
CONFIG_DVB_DRX39XYJ=m
CONFIG_DVB_LNBP21=m
CONFIG_DVB_LNBP22=m
CONFIG_DVB_ISL6405=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_ISL6423=m
CONFIG_DVB_A8293=m
CONFIG_DVB_LGS8GXX=m
CONFIG_DVB_ATBM8830=m
CONFIG_DVB_TDA665x=m
CONFIG_DVB_IX2505V=m
CONFIG_DVB_M88RS2000=m
CONFIG_DVB_AF9033=m
#
# Tools to develop new frontends
#
# CONFIG_DVB_DUMMY_FE is not set
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_INTEL_GTT=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=64
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=m
CONFIG_DRM_MIPI_DSI=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
CONFIG_DRM_TTM=m
#
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
CONFIG_DRM_I2C_NXP_TDA998X=m
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_AMDGPU is not set
#
# ACP (Audio CoProcessor) Configuration
#
# CONFIG_DRM_NOUVEAU is not set
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_ALPHA_SUPPORT is not set
CONFIG_DRM_I915_CAPTURE_ERROR=y
CONFIG_DRM_I915_COMPRESS_ERROR=y
CONFIG_DRM_I915_USERPTR=y
# CONFIG_DRM_I915_GVT is not set
#
# drm/i915 Debugging
#
# CONFIG_DRM_I915_WERROR is not set
# CONFIG_DRM_I915_DEBUG is not set
# CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set
# CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set
# CONFIG_DRM_I915_SELFTEST is not set
# CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS is not set
# CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set
# CONFIG_DRM_VGEM is not set
CONFIG_DRM_VMWGFX=m
CONFIG_DRM_VMWGFX_FBCON=y
CONFIG_DRM_GMA500=m
CONFIG_DRM_GMA600=y
CONFIG_DRM_GMA3600=y
CONFIG_DRM_UDL=m
CONFIG_DRM_AST=m
CONFIG_DRM_MGAG200=m
CONFIG_DRM_CIRRUS_QEMU=m
CONFIG_DRM_QXL=m
# CONFIG_DRM_BOCHS is not set
# CONFIG_DRM_VIRTIO_GPU is not set
CONFIG_DRM_PANEL=y
#
# Display Panels
#
CONFIG_DRM_BRIDGE=y
CONFIG_DRM_PANEL_BRIDGE=y
#
# Display Interface Bridges
#
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
# CONFIG_DRM_HISI_HIBMC is not set
# CONFIG_DRM_TINYDRM is not set
# CONFIG_DRM_LEGACY is not set
# CONFIG_DRM_LIB_RANDOM is not set
#
# Frame buffer Devices
#
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_SM501 is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_XEN_FBDEV_FRONTEND is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
CONFIG_FB_HYPERV=m
# CONFIG_FB_SIMPLE is not set
# CONFIG_FB_SM712 is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_L4F00242T03 is not set
# CONFIG_LCD_LMS283GF05 is not set
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_ILI922X is not set
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
CONFIG_LCD_PLATFORM=m
# CONFIG_LCD_S6E63M0 is not set
# CONFIG_LCD_LD9040 is not set
# CONFIG_LCD_AMS369FG06 is not set
# CONFIG_LCD_LMS501KF03 is not set
# CONFIG_LCD_HX8357 is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_PWM is not set
CONFIG_BACKLIGHT_APPLE=m
# CONFIG_BACKLIGHT_PM8941_WLED is not set
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630A is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_GPIO is not set
# CONFIG_BACKLIGHT_LV5207LP is not set
# CONFIG_BACKLIGHT_BD6107 is not set
# CONFIG_BACKLIGHT_ARCXCNN is not set
# CONFIG_VGASTATE is not set
CONFIG_HDMI=y
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
# CONFIG_VGACON_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_SEQ_DEVICE=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_JACK=y
CONFIG_SND_JACK_INPUT_DEV=y
CONFIG_SND_OSSEMUL=y
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
CONFIG_SND_PCM_TIMER=y
CONFIG_SND_HRTIMER=m
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_MAX_CARDS=32
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_PROC_FS=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_SEQUENCER_OSS=m
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_SND_SEQ_MIDI_EVENT=m
CONFIG_SND_SEQ_MIDI_EMUL=m
CONFIG_SND_SEQ_VIRMIDI=m
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_OPL3_LIB_SEQ=m
# CONFIG_SND_OPL4_LIB_SEQ is not set
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCSP=m
CONFIG_SND_DUMMY=m
CONFIG_SND_ALOOP=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=5
CONFIG_SND_PCI=y
CONFIG_SND_AD1889=m
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
CONFIG_SND_ALI5451=m
CONFIG_SND_ASIHPI=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_OXYGEN_LIB=m
CONFIG_SND_OXYGEN=m
# CONFIG_SND_CS4281 is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CTXFI=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_INDIGOIOX=m
CONFIG_SND_INDIGODJX=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1_SEQ=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
CONFIG_SND_ES1968=m
CONFIG_SND_ES1968_INPUT=y
CONFIG_SND_ES1968_RADIO=y
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_LOLA=m
CONFIG_SND_LX6464ES=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MAESTRO3_INPUT=y
CONFIG_SND_MIXART=m
# CONFIG_SND_NM256 is not set
CONFIG_SND_PCXHR=m
# CONFIG_SND_RIPTIDE is not set
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
# CONFIG_SND_SONICVIBES is not set
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
# CONFIG_SND_YMFPCI is not set
#
# HD-Audio
#
CONFIG_SND_HDA=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=0
# CONFIG_SND_HDA_PATCH_LOADER is not set
CONFIG_SND_HDA_CODEC_REALTEK=m
CONFIG_SND_HDA_CODEC_ANALOG=m
CONFIG_SND_HDA_CODEC_SIGMATEL=m
CONFIG_SND_HDA_CODEC_VIA=m
CONFIG_SND_HDA_CODEC_HDMI=m
CONFIG_SND_HDA_CODEC_CIRRUS=m
CONFIG_SND_HDA_CODEC_CONEXANT=m
CONFIG_SND_HDA_CODEC_CA0110=m
CONFIG_SND_HDA_CODEC_CA0132=m
CONFIG_SND_HDA_CODEC_CA0132_DSP=y
CONFIG_SND_HDA_CODEC_CMEDIA=m
CONFIG_SND_HDA_CODEC_SI3054=m
CONFIG_SND_HDA_GENERIC=m
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDA_CORE=m
CONFIG_SND_HDA_DSP_LOADER=y
CONFIG_SND_HDA_I915=y
CONFIG_SND_HDA_PREALLOC_SIZE=512
CONFIG_SND_SPI=y
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_UA101=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
CONFIG_SND_USB_US122L=m
CONFIG_SND_USB_6FIRE=m
# CONFIG_SND_USB_HIFACE is not set
# CONFIG_SND_BCD2000 is not set
# CONFIG_SND_USB_POD is not set
# CONFIG_SND_USB_PODHD is not set
# CONFIG_SND_USB_TONEPORT is not set
# CONFIG_SND_USB_VARIAX is not set
CONFIG_SND_FIREWIRE=y
CONFIG_SND_FIREWIRE_LIB=m
# CONFIG_SND_DICE is not set
# CONFIG_SND_OXFW is not set
CONFIG_SND_ISIGHT=m
# CONFIG_SND_FIREWORKS is not set
# CONFIG_SND_BEBOB is not set
# CONFIG_SND_FIREWIRE_DIGI00X is not set
# CONFIG_SND_FIREWIRE_TASCAM is not set
# CONFIG_SND_FIREWIRE_MOTU is not set
# CONFIG_SND_FIREFACE is not set
# CONFIG_SND_SOC is not set
CONFIG_SND_X86=y
# CONFIG_HDMI_LPE_AUDIO is not set
CONFIG_SND_SYNTH_EMUX=m
CONFIG_AC97_BUS=m
#
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=m
CONFIG_HID_GENERIC=y
#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACCUTOUCH is not set
CONFIG_HID_ACRUX=m
# CONFIG_HID_ACRUX_FF is not set
CONFIG_HID_APPLE=y
CONFIG_HID_APPLEIR=m
# CONFIG_HID_ASUS is not set
CONFIG_HID_AUREAL=m
CONFIG_HID_BELKIN=y
# CONFIG_HID_BETOP_FF is not set
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
# CONFIG_HID_CORSAIR is not set
CONFIG_HID_PRODIKEYS=m
# CONFIG_HID_CMEDIA is not set
# CONFIG_HID_CP2112 is not set
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=m
# CONFIG_DRAGONRISE_FF is not set
# CONFIG_HID_EMS_FF is not set
CONFIG_HID_ELECOM=m
# CONFIG_HID_ELO is not set
CONFIG_HID_EZKEY=y
# CONFIG_HID_GEMBIRD is not set
# CONFIG_HID_GFRM is not set
CONFIG_HID_HOLTEK=m
# CONFIG_HOLTEK_FF is not set
# CONFIG_HID_GT683R is not set
CONFIG_HID_KEYTOUCH=m
CONFIG_HID_KYE=m
CONFIG_HID_UCLOGIC=m
CONFIG_HID_WALTOP=m
CONFIG_HID_GYRATION=m
CONFIG_HID_ICADE=m
CONFIG_HID_TWINHAN=m
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LCPOWER=m
CONFIG_HID_LED=m
# CONFIG_HID_LENOVO is not set
CONFIG_HID_LOGITECH=y
CONFIG_HID_LOGITECH_DJ=m
CONFIG_HID_LOGITECH_HIDPP=m
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set
CONFIG_HID_MAGICMOUSE=y
# CONFIG_HID_MAYFLASH is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_MULTITOUCH=m
# CONFIG_HID_NTI is not set
CONFIG_HID_NTRIG=y
CONFIG_HID_ORTEK=m
CONFIG_HID_PANTHERLORD=m
# CONFIG_PANTHERLORD_FF is not set
# CONFIG_HID_PENMOUNT is not set
CONFIG_HID_PETALYNX=m
CONFIG_HID_PICOLCD=m
CONFIG_HID_PICOLCD_FB=y
CONFIG_HID_PICOLCD_BACKLIGHT=y
CONFIG_HID_PICOLCD_LCD=y
CONFIG_HID_PICOLCD_LEDS=y
CONFIG_HID_PICOLCD_CIR=y
CONFIG_HID_PLANTRONICS=y
CONFIG_HID_PRIMAX=m
CONFIG_HID_ROCCAT=m
CONFIG_HID_SAITEK=m
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
# CONFIG_SONY_FF is not set
CONFIG_HID_SPEEDLINK=m
CONFIG_HID_STEELSERIES=m
CONFIG_HID_SUNPLUS=m
# CONFIG_HID_RMI is not set
CONFIG_HID_GREENASIA=m
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_HYPERV_MOUSE=m
CONFIG_HID_SMARTJOYPLUS=m
# CONFIG_SMARTJOYPLUS_FF is not set
CONFIG_HID_TIVO=m
CONFIG_HID_TOPSEED=m
CONFIG_HID_THINGM=m
CONFIG_HID_THRUSTMASTER=m
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_HID_UDRAW_PS3 is not set
CONFIG_HID_WACOM=m
CONFIG_HID_WIIMOTE=m
# CONFIG_HID_XINMO is not set
CONFIG_HID_ZEROPLUS=m
# CONFIG_ZEROPLUS_FF is not set
CONFIG_HID_ZYDACRON=m
# CONFIG_HID_SENSOR_HUB is not set
# CONFIG_HID_ALPS is not set
#
# USB HID support
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y
#
# I2C HID support
#
CONFIG_I2C_HID=m
#
# Intel ISH HID support
#
# CONFIG_INTEL_ISH_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_PCI=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_LEDS_TRIGGER_USBPORT is not set
CONFIG_USB_MON=y
CONFIG_USB_WUSB=m
CONFIG_USB_WUSB_CBAF=m
# CONFIG_USB_WUSB_CBAF_DEBUG is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
# CONFIG_USB_MAX3421_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PCI=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_U132_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
CONFIG_USB_HWA_HCD=m
# CONFIG_USB_HCD_BCMA is not set
# CONFIG_USB_HCD_SSB is not set
# CONFIG_USB_HCD_TEST_MODE is not set
#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_WDM=m
CONFIG_USB_TMC=m
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_REALTEK=m
CONFIG_REALTEK_AUTOPM=y
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m
CONFIG_USB_UAS=m
#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m
# CONFIG_USBIP_CORE is not set
# CONFIG_USB_MUSB_HDRC is not set
CONFIG_USB_DWC3=y
# CONFIG_USB_DWC3_HOST is not set
CONFIG_USB_DWC3_GADGET=y
# CONFIG_USB_DWC3_DUAL_ROLE is not set
#
# Platform Glue Driver Support
#
CONFIG_USB_DWC3_PCI=y
# CONFIG_USB_DWC2 is not set
# CONFIG_USB_CHIPIDEA is not set
# CONFIG_USB_ISP1760 is not set
#
# USB port drivers
#
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_SIMPLE is not set
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP210X=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
# CONFIG_USB_SERIAL_F81232 is not set
# CONFIG_USB_SERIAL_F8153X is not set
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
# CONFIG_USB_SERIAL_METRO is not set
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7715_PARPORT=y
CONFIG_USB_SERIAL_MOS7840=m
# CONFIG_USB_SERIAL_MXUPORT is not set
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_OTI6858=m
CONFIG_USB_SERIAL_QCAUX=m
CONFIG_USB_SERIAL_QUALCOMM=m
CONFIG_USB_SERIAL_SPCP8X5=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_SYMBOL=m
# CONFIG_USB_SERIAL_TI is not set
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_WWAN=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_SERIAL_OPTICON=m
CONFIG_USB_SERIAL_XSENS_MT=m
# CONFIG_USB_SERIAL_WISHBONE is not set
CONFIG_USB_SERIAL_SSU100=m
CONFIG_USB_SERIAL_QT2=m
# CONFIG_USB_SERIAL_UPD78F0730 is not set
CONFIG_USB_SERIAL_DEBUG=m
#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_SEVSEG=m
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
# CONFIG_USB_TRANCEVIBRATOR is not set
CONFIG_USB_IOWARRIOR=m
# CONFIG_USB_TEST is not set
# CONFIG_USB_EHSET_TEST_FIXTURE is not set
CONFIG_USB_ISIGHTFW=m
# CONFIG_USB_YUREX is not set
CONFIG_USB_EZUSB_FX2=m
# CONFIG_USB_HUB_USB251XB is not set
CONFIG_USB_HSIC_USB3503=m
# CONFIG_USB_HSIC_USB4604 is not set
# CONFIG_USB_LINK_LAYER_TEST is not set
# CONFIG_USB_CHAOSKEY is not set
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m
#
# USB Physical Layer drivers
#
CONFIG_USB_PHY=y
CONFIG_NOP_USB_XCEIV=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
#
# USB Peripheral Controller
#
# CONFIG_USB_FOTG210_UDC is not set
# CONFIG_USB_GR_UDC is not set
# CONFIG_USB_R8A66597 is not set
# CONFIG_USB_PXA27X is not set
# CONFIG_USB_MV_UDC is not set
# CONFIG_USB_MV_U3D is not set
# CONFIG_USB_M66592 is not set
# CONFIG_USB_BDC_UDC is not set
# CONFIG_USB_AMD5536UDC is not set
# CONFIG_USB_NET2272 is not set
# CONFIG_USB_NET2280 is not set
# CONFIG_USB_GOKU is not set
# CONFIG_USB_EG20T is not set
# CONFIG_USB_DUMMY_HCD is not set
CONFIG_USB_LIBCOMPOSITE=m
CONFIG_USB_F_MASS_STORAGE=m
# CONFIG_USB_CONFIGFS is not set
# CONFIG_USB_ZERO is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_G_NCM is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FUNCTIONFS is not set
CONFIG_USB_MASS_STORAGE=m
# CONFIG_USB_GADGET_TARGET is not set
# CONFIG_USB_G_SERIAL is not set
# CONFIG_USB_MIDI_GADGET is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
# CONFIG_USB_G_ACM_MS is not set
# CONFIG_USB_G_MULTI is not set
# CONFIG_USB_G_HID is not set
# CONFIG_USB_G_DBGP is not set
# CONFIG_USB_G_WEBCAM is not set
#
# USB Power Delivery and Type-C drivers
#
# CONFIG_TYPEC_UCSI is not set
# CONFIG_USB_LED_TRIG is not set
# CONFIG_USB_ULPI_BUS is not set
CONFIG_UWB=m
CONFIG_UWB_HWA=m
CONFIG_UWB_WHCI=m
CONFIG_UWB_I1480U=m
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_SDIO_UART=m
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=y
CONFIG_MMC_SDHCI_ACPI=m
CONFIG_MMC_SDHCI_PLTFM=m
# CONFIG_MMC_WBSD is not set
CONFIG_MMC_TIFM_SD=m
# CONFIG_MMC_SPI is not set
CONFIG_MMC_CB710=m
CONFIG_MMC_VIA_SDMMC=m
CONFIG_MMC_VUB300=m
CONFIG_MMC_USHC=m
# CONFIG_MMC_USDHI6ROL0 is not set
CONFIG_MMC_REALTEK_PCI=m
# CONFIG_MMC_TOSHIBA_PCI is not set
# CONFIG_MMC_MTK is not set
# CONFIG_MMC_SDHCI_XENON is not set
CONFIG_MEMSTICK=m
# CONFIG_MEMSTICK_DEBUG is not set
#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m
# CONFIG_MS_BLOCK is not set
#
# MemoryStick Host Controller Drivers
#
CONFIG_MEMSTICK_TIFM_MS=m
CONFIG_MEMSTICK_JMICRON_38X=m
CONFIG_MEMSTICK_R592=m
CONFIG_MEMSTICK_REALTEK_PCI=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
# CONFIG_LEDS_CLASS_FLASH is not set
# CONFIG_LEDS_BRIGHTNESS_HW_CHANGED is not set
#
# LED drivers
#
CONFIG_LEDS_LM3530=m
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
CONFIG_LEDS_LP3944=m
# CONFIG_LEDS_LP3952 is not set
CONFIG_LEDS_LP55XX_COMMON=m
CONFIG_LEDS_LP5521=m
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_LP5562=m
# CONFIG_LEDS_LP8501 is not set
# CONFIG_LEDS_LP8860 is not set
CONFIG_LEDS_CLEVO_MAIL=m
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA963X is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_PWM is not set
# CONFIG_LEDS_BD2802 is not set
CONFIG_LEDS_INTEL_SS4200=m
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_TLC591XX is not set
# CONFIG_LEDS_LM355x is not set
#
# LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)
#
CONFIG_LEDS_BLINKM=m
# CONFIG_LEDS_MLXCPLD is not set
# CONFIG_LEDS_USER is not set
# CONFIG_LEDS_NIC78BX is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
# CONFIG_LEDS_TRIGGER_DISK is not set
# CONFIG_LEDS_TRIGGER_MTD is not set
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
# CONFIG_LEDS_TRIGGER_CPU is not set
# CONFIG_LEDS_TRIGGER_GPIO is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_LEDS_TRIGGER_TRANSIENT=m
CONFIG_LEDS_TRIGGER_CAMERA=m
# CONFIG_LEDS_TRIGGER_PANIC is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=m
# CONFIG_EDAC_GHES is not set
CONFIG_EDAC_AMD64=m
# CONFIG_EDAC_AMD64_ERROR_INJECTION is not set
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82975X=m
CONFIG_EDAC_I3000=m
CONFIG_EDAC_I3200=m
# CONFIG_EDAC_IE31200 is not set
CONFIG_EDAC_X38=m
CONFIG_EDAC_I5400=m
CONFIG_EDAC_I7CORE=m
CONFIG_EDAC_I5000=m
CONFIG_EDAC_I5100=m
CONFIG_EDAC_I7300=m
CONFIG_EDAC_SBRIDGE=m
# CONFIG_EDAC_SKX is not set
# CONFIG_EDAC_PND2 is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_SYSTOHC is not set
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_ABB5ZES3 is not set
# CONFIG_RTC_DRV_ABX80X is not set
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1307_HWMON=y
# CONFIG_RTC_DRV_DS1307_CENTURY is not set
CONFIG_RTC_DRV_DS1374=m
# CONFIG_RTC_DRV_DS1374_WDT is not set
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_ISL12022=m
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8523=m
# CONFIG_RTC_DRV_PCF85063 is not set
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
CONFIG_RTC_DRV_M41T80_WDT=y
CONFIG_RTC_DRV_BQ32K=m
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=m
# CONFIG_RTC_DRV_RX8010 is not set
CONFIG_RTC_DRV_RX8581=m
CONFIG_RTC_DRV_RX8025=m
CONFIG_RTC_DRV_EM3027=m
# CONFIG_RTC_DRV_RV8803 is not set
#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1302 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1343 is not set
# CONFIG_RTC_DRV_DS1347 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6916 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RX4581 is not set
# CONFIG_RTC_DRV_RX6110 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_MCP795 is not set
CONFIG_RTC_I2C_AND_SPI=y
#
# SPI and I2C RTC drivers
#
CONFIG_RTC_DRV_DS3232=m
# CONFIG_RTC_DRV_PCF2127 is not set
CONFIG_RTC_DRV_RV3029C2=m
CONFIG_RTC_DRV_RV3029_HWMON=y
#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1286=m
CONFIG_RTC_DRV_DS1511=m
CONFIG_RTC_DRV_DS1553=m
# CONFIG_RTC_DRV_DS1685_FAMILY is not set
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_DS2404=m
CONFIG_RTC_DRV_STK17TA8=m
# CONFIG_RTC_DRV_M48T86 is not set
CONFIG_RTC_DRV_M48T35=m
CONFIG_RTC_DRV_M48T59=m
CONFIG_RTC_DRV_MSM6242=m
CONFIG_RTC_DRV_BQ4802=m
CONFIG_RTC_DRV_RP5C01=m
CONFIG_RTC_DRV_V3020=m
#
# on-CPU RTC drivers
#
#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set
#
# DMA Devices
#
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_ACPI=y
# CONFIG_INTEL_IDMA64 is not set
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_QCOM_HIDMA_MGMT is not set
# CONFIG_QCOM_HIDMA is not set
CONFIG_DW_DMAC_CORE=y
CONFIG_DW_DMAC=m
CONFIG_DW_DMAC_PCI=y
CONFIG_HSU_DMA=y
#
# DMA Clients
#
CONFIG_ASYNC_TX_DMA=y
CONFIG_DMATEST=m
CONFIG_DMA_ENGINE_RAID=y
#
# DMABUF options
#
CONFIG_SYNC_FILE=y
CONFIG_SW_SYNC=y
CONFIG_AUXDISPLAY=y
# CONFIG_HD44780 is not set
CONFIG_KS0108=m
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
CONFIG_CFAG12864B=m
CONFIG_CFAG12864B_RATE=20
# CONFIG_IMG_ASCII_LCD is not set
# CONFIG_PANEL is not set
CONFIG_UIO=m
CONFIG_UIO_CIF=m
CONFIG_UIO_PDRV_GENIRQ=m
# CONFIG_UIO_DMEM_GENIRQ is not set
CONFIG_UIO_AEC=m
CONFIG_UIO_SERCOS3=m
CONFIG_UIO_PCI_GENERIC=m
# CONFIG_UIO_NETX is not set
# CONFIG_UIO_PRUSS is not set
# CONFIG_UIO_MF624 is not set
# CONFIG_UIO_HV_GENERIC is not set
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_VFIO_PCI=m
# CONFIG_VFIO_PCI_VGA is not set
CONFIG_VFIO_PCI_MMAP=y
CONFIG_VFIO_PCI_INTX=y
CONFIG_VFIO_PCI_IGD=y
# CONFIG_VFIO_MDEV is not set
CONFIG_IRQ_BYPASS_MANAGER=m
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y
#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_VIRTIO_BALLOON=y
# CONFIG_VIRTIO_INPUT is not set
# CONFIG_VIRTIO_MMIO is not set
#
# Microsoft Hyper-V guest support
#
CONFIG_HYPERV=m
CONFIG_HYPERV_TSCPAGE=y
CONFIG_HYPERV_UTILS=m
CONFIG_HYPERV_BALLOON=m
#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
# CONFIG_XEN_SELFBALLOONING is not set
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=m
CONFIG_XEN_PCIDEV_BACKEND=m
# CONFIG_XEN_SCSI_BACKEND is not set
CONFIG_XEN_PRIVCMD=m
CONFIG_XEN_ACPI_PROCESSOR=m
# CONFIG_XEN_MCE_LOG is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y
CONFIG_XEN_ACPI=y
CONFIG_XEN_SYMS=y
CONFIG_XEN_HAVE_VPMU=y
CONFIG_STAGING=y
# CONFIG_PRISM2_USB is not set
# CONFIG_COMEDI is not set
# CONFIG_RTL8192U is not set
CONFIG_RTLLIB=m
CONFIG_RTLLIB_CRYPTO_CCMP=m
CONFIG_RTLLIB_CRYPTO_TKIP=m
CONFIG_RTLLIB_CRYPTO_WEP=m
CONFIG_RTL8192E=m
# CONFIG_RTL8723BS is not set
CONFIG_R8712U=m
# CONFIG_R8188EU is not set
# CONFIG_RTS5208 is not set
# CONFIG_VT6655 is not set
# CONFIG_VT6656 is not set
# CONFIG_FB_SM750 is not set
# CONFIG_FB_XGI is not set
#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_STAGING_MEDIA is not set
#
# Android
#
# CONFIG_LTE_GDM724X is not set
CONFIG_FIREWIRE_SERIAL=m
CONFIG_FWTTY_MAX_TOTAL_PORTS=64
CONFIG_FWTTY_MAX_CARD_PORTS=32
# CONFIG_LNET is not set
# CONFIG_DGNC is not set
# CONFIG_GS_FPGABOOT is not set
# CONFIG_CRYPTO_SKEIN is not set
# CONFIG_UNISYSSPAR is not set
# CONFIG_FB_TFT is not set
# CONFIG_WILC1000_SDIO is not set
# CONFIG_WILC1000_SPI is not set
# CONFIG_MOST is not set
# CONFIG_KS7010 is not set
# CONFIG_GREYBUS is not set
#
# USB Power Delivery and Type-C drivers
#
# CONFIG_TYPEC_TCPM is not set
CONFIG_X86_PLATFORM_DEVICES=y
CONFIG_ACER_WMI=m
CONFIG_ACERHDF=m
# CONFIG_ALIENWARE_WMI is not set
CONFIG_ASUS_LAPTOP=m
# CONFIG_DELL_LAPTOP is not set
# CONFIG_DELL_WMI is not set
CONFIG_DELL_WMI_AIO=m
# CONFIG_DELL_WMI_LED is not set
# CONFIG_DELL_SMO8800 is not set
# CONFIG_DELL_RBTN is not set
CONFIG_FUJITSU_LAPTOP=m
CONFIG_FUJITSU_TABLET=m
CONFIG_AMILO_RFKILL=m
CONFIG_HP_ACCEL=m
# CONFIG_HP_WIRELESS is not set
CONFIG_HP_WMI=m
CONFIG_MSI_LAPTOP=m
CONFIG_PANASONIC_LAPTOP=m
CONFIG_COMPAL_LAPTOP=m
CONFIG_SONY_LAPTOP=m
CONFIG_SONYPI_COMPAT=y
CONFIG_IDEAPAD_LAPTOP=m
# CONFIG_SURFACE3_WMI is not set
CONFIG_THINKPAD_ACPI=m
CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
CONFIG_THINKPAD_ACPI_VIDEO=y
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
CONFIG_SENSORS_HDAPS=m
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=m
CONFIG_ASUS_WMI=m
CONFIG_ASUS_NB_WMI=m
CONFIG_EEEPC_WMI=m
# CONFIG_ASUS_WIRELESS is not set
CONFIG_ACPI_WMI=m
CONFIG_WMI_BMOF=m
CONFIG_MSI_WMI=m
# CONFIG_PEAQ_WMI is not set
CONFIG_TOPSTAR_LAPTOP=m
CONFIG_TOSHIBA_BT_RFKILL=m
# CONFIG_TOSHIBA_HAPS is not set
# CONFIG_TOSHIBA_WMI is not set
CONFIG_ACPI_CMPC=m
# CONFIG_INTEL_CHT_INT33FE is not set
# CONFIG_INTEL_INT0002_VGPIO is not set
# CONFIG_INTEL_HID_EVENT is not set
# CONFIG_INTEL_VBTN is not set
CONFIG_INTEL_IPS=m
# CONFIG_INTEL_PMC_CORE is not set
# CONFIG_IBM_RTL is not set
CONFIG_SAMSUNG_LAPTOP=m
CONFIG_MXM_WMI=m
CONFIG_INTEL_OAKTRAIL=m
CONFIG_SAMSUNG_Q10=m
CONFIG_APPLE_GMUX=m
# CONFIG_INTEL_RST is not set
# CONFIG_INTEL_SMARTCONNECT is not set
CONFIG_PVPANIC=y
# CONFIG_INTEL_PMC_IPC is not set
# CONFIG_SURFACE_PRO3_BUTTON is not set
# CONFIG_INTEL_PUNIT_IPC is not set
# CONFIG_MLX_PLATFORM is not set
# CONFIG_MLX_CPLD_PLATFORM is not set
# CONFIG_INTEL_TURBO_MAX_3 is not set
CONFIG_PMC_ATOM=y
# CONFIG_CHROME_PLATFORMS is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y
#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_CDCE706 is not set
# CONFIG_COMMON_CLK_CS2000_CP is not set
# CONFIG_COMMON_CLK_NXP is not set
# CONFIG_COMMON_CLK_PWM is not set
# CONFIG_COMMON_CLK_PXA is not set
# CONFIG_COMMON_CLK_PIC32 is not set
# CONFIG_HWSPINLOCK is not set
#
# Clock Source drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_ATMEL_PIT is not set
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
CONFIG_MAILBOX=y
CONFIG_PCC=y
# CONFIG_ALTERA_MBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
#
# Generic IOMMU Pagetable Support
#
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_V2=m
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_SVM is not set
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
CONFIG_IRQ_REMAP=y
#
# Remoteproc drivers
#
# CONFIG_REMOTEPROC is not set
#
# Rpmsg drivers
#
# CONFIG_RPMSG_QCOM_GLINK_RPM is not set
#
# SOC (System On Chip) specific Drivers
#
#
# Broadcom SoC drivers
#
#
# i.MX SoC drivers
#
# CONFIG_SUNXI_SRAM is not set
# CONFIG_SOC_TI is not set
# CONFIG_SOC_ZTE is not set
CONFIG_PM_DEVFREQ=y
#
# DEVFREQ Governors
#
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=m
# CONFIG_DEVFREQ_GOV_PERFORMANCE is not set
# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
# CONFIG_DEVFREQ_GOV_USERSPACE is not set
# CONFIG_DEVFREQ_GOV_PASSIVE is not set
#
# DEVFREQ Drivers
#
# CONFIG_PM_DEVFREQ_EVENT is not set
CONFIG_EXTCON=y
#
# Extcon Device Drivers
#
# CONFIG_EXTCON_GPIO is not set
# CONFIG_EXTCON_INTEL_INT3496 is not set
# CONFIG_EXTCON_MAX3355 is not set
# CONFIG_EXTCON_RT8973A is not set
# CONFIG_EXTCON_SM5502 is not set
# CONFIG_EXTCON_USB_GPIO is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
CONFIG_NTB=m
# CONFIG_NTB_AMD is not set
# CONFIG_NTB_INTEL is not set
# CONFIG_NTB_PINGPONG is not set
# CONFIG_NTB_TOOL is not set
# CONFIG_NTB_PERF is not set
# CONFIG_NTB_TRANSPORT is not set
# CONFIG_VME_BUS is not set
CONFIG_PWM=y
CONFIG_PWM_SYSFS=y
# CONFIG_PWM_LPSS_PCI is not set
# CONFIG_PWM_LPSS_PLATFORM is not set
# CONFIG_PWM_PCA9685 is not set
CONFIG_ARM_GIC_MAX_NR=1
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set
#
# PHY Subsystem
#
CONFIG_GENERIC_PHY=y
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
CONFIG_POWERCAP=y
CONFIG_INTEL_RAPL=m
# CONFIG_MCB is not set
#
# Performance monitor support
#
CONFIG_RAS=y
# CONFIG_RAS_CEC is not set
# CONFIG_THUNDERBOLT is not set
#
# Android
#
# CONFIG_ANDROID is not set
CONFIG_LIBNVDIMM=m
CONFIG_BLK_DEV_PMEM=m
CONFIG_ND_BLK=m
CONFIG_ND_CLAIM=y
CONFIG_ND_BTT=m
CONFIG_BTT=y
CONFIG_ND_PFN=m
CONFIG_NVDIMM_PFN=y
CONFIG_NVDIMM_DAX=y
CONFIG_DAX=y
CONFIG_DEV_DAX=m
CONFIG_DEV_DAX_PMEM=m
CONFIG_NVMEM=m
# CONFIG_STM is not set
# CONFIG_INTEL_TH is not set
#
# FPGA Configuration Support
#
# CONFIG_FPGA is not set
#
# FSI support
#
# CONFIG_FSI is not set
# CONFIG_MULTIPLEXER is not set
#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
CONFIG_DMI_SYSFS=y
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m
# CONFIG_FW_CFG_SYSFS is not set
# CONFIG_GOOGLE_FIRMWARE is not set
#
# EFI (Extensible Firmware Interface) Support
#
CONFIG_EFI_VARS=y
CONFIG_EFI_ESRT=y
CONFIG_EFI_VARS_PSTORE=y
CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y
CONFIG_EFI_RUNTIME_MAP=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_RUNTIME_WRAPPERS=y
# CONFIG_EFI_BOOTLOADER_CONTROL is not set
# CONFIG_EFI_CAPSULE_LOADER is not set
# CONFIG_EFI_TEST is not set
# CONFIG_APPLE_PROPERTIES is not set
CONFIG_UEFI_CPER=y
# CONFIG_EFI_DEV_PATH_PARSER is not set
#
# Tegra firmware driver
#
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_FS_IOMAP=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_DLM=y
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_FS_O2CB=m
CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m
CONFIG_OCFS2_FS_STATS=y
CONFIG_OCFS2_DEBUG_MASKLOG=y
# CONFIG_OCFS2_DEBUG_FS is not set
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
# CONFIG_NILFS2_FS is not set
CONFIG_F2FS_FS=m
CONFIG_F2FS_STAT_FS=y
CONFIG_F2FS_FS_XATTR=y
CONFIG_F2FS_FS_POSIX_ACL=y
# CONFIG_F2FS_FS_SECURITY is not set
# CONFIG_F2FS_CHECK_FS is not set
# CONFIG_F2FS_FS_ENCRYPTION is not set
# CONFIG_F2FS_IO_TRACE is not set
# CONFIG_F2FS_FAULT_INJECTION is not set
CONFIG_FS_DAX=y
CONFIG_FS_DAX_PMD=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
# CONFIG_EXPORTFS_BLOCK_OPS is not set
CONFIG_FILE_LOCKING=y
CONFIG_MANDATORY_FILE_LOCKING=y
# CONFIG_FS_ENCRYPTION is not set
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_OVERLAY_FS=m
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_CHILDREN=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ORANGEFS_FS is not set
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_UBIFS_FS is not set
CONFIG_CRAMFS=m
CONFIG_SQUASHFS=m
CONFIG_SQUASHFS_FILE_CACHE=y
# CONFIG_SQUASHFS_FILE_DIRECT is not set
CONFIG_SQUASHFS_DECOMP_SINGLE=y
# CONFIG_SQUASHFS_DECOMP_MULTI is not set
# CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
# CONFIG_SQUASHFS_LZ4 is not set
CONFIG_SQUASHFS_LZO=y
CONFIG_SQUASHFS_XZ=y
# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
# CONFIG_SQUASHFS_EMBEDDED is not set
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
CONFIG_PSTORE_ZLIB_COMPRESS=y
# CONFIG_PSTORE_LZO_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
# CONFIG_PSTORE_FTRACE is not set
CONFIG_PSTORE_RAM=m
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_EXOFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
# CONFIG_NFS_V2 is not set
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=m
# CONFIG_NFS_SWAP is not set
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_PNFS_FILE_LAYOUT=m
CONFIG_PNFS_BLOCK=m
CONFIG_PNFS_FLEXFILE_LAYOUT=m
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
# CONFIG_NFS_V4_1_MIGRATION is not set
CONFIG_NFS_V4_SECURITY_LABEL=y
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFS_DEBUG=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
# CONFIG_NFSD_BLOCKLAYOUT is not set
# CONFIG_NFSD_SCSILAYOUT is not set
# CONFIG_NFSD_FLEXFILELAYOUT is not set
CONFIG_NFSD_V4_SECURITY_LABEL=y
# CONFIG_NFSD_FAULT_INJECTION is not set
CONFIG_GRACE_PERIOD=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_BACKCHANNEL=y
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_SUNRPC_DEBUG=y
# CONFIG_CEPH_FS is not set
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_CIFS_ACL=y
CONFIG_CIFS_DEBUG=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_DEBUG_DUMP_KEYS is not set
CONFIG_CIFS_DFS_UPCALL=y
CONFIG_CIFS_SMB2=y
# CONFIG_CIFS_SMB311 is not set
# CONFIG_CIFS_FSCACHE is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=y
CONFIG_9P_FS_POSIX_ACL=y
# CONFIG_9P_FS_SECURITY is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_MAC_ROMAN=m
CONFIG_NLS_MAC_CELTIC=m
CONFIG_NLS_MAC_CENTEURO=m
CONFIG_NLS_MAC_CROATIAN=m
CONFIG_NLS_MAC_CYRILLIC=m
CONFIG_NLS_MAC_GAELIC=m
CONFIG_NLS_MAC_GREEK=m
CONFIG_NLS_MAC_ICELAND=m
CONFIG_NLS_MAC_INUIT=m
CONFIG_NLS_MAC_ROMANIAN=m
CONFIG_NLS_MAC_TURKISH=m
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_DYNAMIC_DEBUG=y
#
# Compile-time checks and compiler options
#
# CONFIG_DEBUG_INFO is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_STACK_VALIDATION is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_MAGIC_SYSRQ_SERIAL=y
CONFIG_DEBUG_KERNEL=y
#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_PAGE_POISONING is not set
# CONFIG_DEBUG_PAGE_REF is not set
CONFIG_DEBUG_RODATA_TEST=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_MEMORY_NOTIFIER_ERROR_INJECT=m
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_HAVE_ARCH_KASAN=y
# CONFIG_KASAN is not set
CONFIG_ARCH_HAS_KCOV=y
# CONFIG_KCOV is not set
CONFIG_DEBUG_SHIRQ=y
#
# Debug Lockups and Hangs
#
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_WQ_WATCHDOG is not set
CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_ON_OOPS_VALUE=1
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHED_INFO=y
CONFIG_SCHEDSTATS=y
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_TIMEKEEPING is not set
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_LOCK_TORTURE_TEST=m
# CONFIG_WW_MUTEX_SELFTEST is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_PI_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
CONFIG_TORTURE_TEST=m
# CONFIG_RCU_PERF_TEST is not set
CONFIG_RCU_TORTURE_TEST=m
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set
CONFIG_NOTIFIER_ERROR_INJECTION=m
CONFIG_PM_NOTIFIER_ERROR_INJECT=m
# CONFIG_NETDEV_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
CONFIG_SCHED_TRACER=y
# CONFIG_HWLAT_TRACER is not set
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENTS=y
CONFIG_UPROBE_EVENTS=y
CONFIG_BPF_EVENTS=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
CONFIG_TRACING_MAP=y
CONFIG_HIST_TRIGGERS=y
# CONFIG_TRACEPOINT_BENCHMARK is not set
CONFIG_RING_BUFFER_BENCHMARK=m
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_TRACE_EVAL_MAP_FILE is not set
CONFIG_TRACING_EVENTS_GPIO=y
#
# Runtime Testing
#
CONFIG_LKDTM=m
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_TEST_SORT is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_RBTREE_TEST=m
CONFIG_INTERVAL_TREE_TEST=m
CONFIG_PERCPU_TEST=m
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_ASYNC_RAID6_TEST=m
# CONFIG_TEST_HEXDUMP is not set
# CONFIG_TEST_STRING_HELPERS is not set
CONFIG_TEST_KSTRTOX=m
CONFIG_TEST_PRINTF=m
CONFIG_TEST_BITMAP=m
# CONFIG_TEST_UUID is not set
# CONFIG_TEST_RHASHTABLE is not set
# CONFIG_TEST_HASH is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_TEST_LKM=m
CONFIG_TEST_USER_COPY=m
CONFIG_TEST_BPF=m
CONFIG_TEST_FIRMWARE=m
CONFIG_TEST_UDELAY=m
# CONFIG_MEMTEST is not set
CONFIG_TEST_STATIC_KEYS=m
# CONFIG_BUG_ON_DATA_CORRUPTION is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
# CONFIG_ARCH_WANTS_UBSAN_NO_NULL is not set
# CONFIG_UBSAN is not set
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
CONFIG_STRICT_DEVMEM=y
# CONFIG_IO_STRICT_DEVMEM is not set
CONFIG_EARLY_PRINTK_USB=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
# CONFIG_EARLY_PRINTK_EFI is not set
# CONFIG_EARLY_PRINTK_USB_XDBC is not set
# CONFIG_X86_PTDUMP_CORE is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_EFI_PGT_DUMP is not set
# CONFIG_DEBUG_WX is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_TLBFLUSH is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_X86_DECODER_SELFTEST=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_ENTRY is not set
# CONFIG_DEBUG_NMI_SELFTEST is not set
CONFIG_X86_DEBUG_FPU=y
# CONFIG_PUNIT_ATOM_DEBUG is not set
#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_COMPAT=y
CONFIG_PERSISTENT_KEYRINGS=y
CONFIG_BIG_KEYS=y
CONFIG_TRUSTED_KEYS=y
CONFIG_ENCRYPTED_KEYS=y
# CONFIG_KEY_DH_OPERATIONS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_WRITABLE_HOOKS=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_INTEL_TXT=y
CONFIG_LSM_MMAP_MIN_ADDR=65535
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
# CONFIG_HARDENED_USERCOPY is not set
# CONFIG_STATIC_USERMODEHELPER is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_LOADPIN is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
CONFIG_INTEGRITY_TRUSTED_KEYRING=y
CONFIG_INTEGRITY_AUDIT=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_LSM_RULES=y
# CONFIG_IMA_TEMPLATE is not set
CONFIG_IMA_NG_TEMPLATE=y
# CONFIG_IMA_SIG_TEMPLATE is not set
CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
CONFIG_IMA_DEFAULT_HASH_SHA1=y
# CONFIG_IMA_DEFAULT_HASH_SHA256 is not set
CONFIG_IMA_DEFAULT_HASH="sha1"
# CONFIG_IMA_WRITE_POLICY is not set
# CONFIG_IMA_READ_POLICY is not set
CONFIG_IMA_APPRAISE=y
CONFIG_IMA_APPRAISE_BOOTPARAM=y
CONFIG_IMA_TRUSTED_KEYRING=y
# CONFIG_IMA_BLACKLIST_KEYRING is not set
# CONFIG_IMA_LOAD_X509 is not set
CONFIG_EVM=y
CONFIG_EVM_ATTR_FSUUID=y
# CONFIG_EVM_LOAD_X509 is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_KPP2=y
CONFIG_CRYPTO_ACOMP2=y
CONFIG_CRYPTO_RSA=y
# CONFIG_CRYPTO_DH is not set
# CONFIG_CRYPTO_ECDH is not set
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
# CONFIG_CRYPTO_MCRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=m
CONFIG_CRYPTO_SIMD=m
CONFIG_CRYPTO_GLUE_HELPER_X86=m
CONFIG_CRYPTO_ENGINE=m
#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
CONFIG_CRYPTO_SEQIV=y
CONFIG_CRYPTO_ECHAINIV=m
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
# CONFIG_CRYPTO_KEYWRAP is not set
#
# Hash modes
#
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRYPTO_GHASH=m
# CONFIG_CRYPTO_POLY1305 is not set
# CONFIG_CRYPTO_POLY1305_X86_64 is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=m
CONFIG_CRYPTO_SHA256_SSSE3=m
CONFIG_CRYPTO_SHA512_SSSE3=m
# CONFIG_CRYPTO_SHA1_MB is not set
# CONFIG_CRYPTO_SHA256_MB is not set
# CONFIG_CRYPTO_SHA512_MB is not set
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_SHA3 is not set
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_TI is not set
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_BLOWFISH_X86_64=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_CAST6_AVX_X86_64=m
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_DES3_EDE_X86_64 is not set
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
# CONFIG_CRYPTO_CHACHA20 is not set
# CONFIG_CRYPTO_CHACHA20_X86_64 is not set
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_842 is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set
#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_DRBG_HMAC=y
# CONFIG_CRYPTO_DRBG_HASH is not set
# CONFIG_CRYPTO_DRBG_CTR is not set
CONFIG_CRYPTO_DRBG=y
CONFIG_CRYPTO_JITTERENTROPY=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
# CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC is not set
# CONFIG_CRYPTO_DEV_CCP is not set
# CONFIG_CRYPTO_DEV_QAT_DH895xCC is not set
# CONFIG_CRYPTO_DEV_QAT_C3XXX is not set
# CONFIG_CRYPTO_DEV_QAT_C62X is not set
# CONFIG_CRYPTO_DEV_QAT_DH895xCCVF is not set
# CONFIG_CRYPTO_DEV_QAT_C3XXXVF is not set
# CONFIG_CRYPTO_DEV_QAT_C62XVF is not set
# CONFIG_CRYPTO_DEV_NITROX_CNN55XX is not set
# CONFIG_CRYPTO_DEV_CHELSIO is not set
CONFIG_CRYPTO_DEV_VIRTIO=m
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
CONFIG_X509_CERTIFICATE_PARSER=y
# CONFIG_PKCS7_MESSAGE_PARSER is not set
#
# Certificates for signature checking
#
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set
# CONFIG_SYSTEM_BLACKLIST_KEYRING is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_IRQFD=y
CONFIG_HAVE_KVM_IRQ_ROUTING=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_KVM_VFIO=y
CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
CONFIG_KVM_COMPAT=y
CONFIG_HAVE_KVM_IRQ_BYPASS=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_MMU_AUDIT=y
CONFIG_VHOST_NET=m
# CONFIG_VHOST_SCSI is not set
# CONFIG_VHOST_VSOCK is not set
CONFIG_VHOST=m
# CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
# CONFIG_HAVE_ARCH_BITREVERSE is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_CRC8=m
# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_BTREE=y
CONFIG_INTERVAL_TREE=y
CONFIG_RADIX_TREE_MULTIORDER=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
# CONFIG_DMA_NOOP_OPS is not set
# CONFIG_DMA_VIRT_OPS is not set
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_GLOB=y
# CONFIG_GLOB_SELFTEST is not set
CONFIG_NLATTR=y
CONFIG_CLZ_TAB=y
CONFIG_CORDIC=m
# CONFIG_DDR is not set
CONFIG_IRQ_POLL=y
CONFIG_MPILIB=y
CONFIG_SIGNATURE=y
CONFIG_OID_REGISTRY=y
CONFIG_UCS2_STRING=y
CONFIG_FONT_SUPPORT=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_SG_SPLIT is not set
CONFIG_SG_POOL=y
CONFIG_ARCH_HAS_SG_CHAIN=y
CONFIG_ARCH_HAS_PMEM_API=y
CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
CONFIG_ARCH_HAS_MMIO_FLUSH=y
CONFIG_SBITMAP=y
[-- Attachment #3: job-script.ksh --]
[-- Type: text/plain, Size: 4349 bytes --]
#!/bin/sh
export_top_env()
{
export suite='ltp'
export testcase='ltp'
export category='functional'
export job_origin='/lkp/lkp/.src-20170713-182338/allot/cyclic:linux-devel:devel-hourly/nhm-white2/ltp.yaml'
export queue='bisect'
export testbox='nhm-white2'
export tbox_group='nhm-white2'
export submit_id='596cbccc0b9a93d8998bd5fd'
export job_file='/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml'
export id='bcf686732c701d15cf5dadb19fcea28e34ef0504'
export model='Nehalem'
export memory='4G'
export nr_cpu=8
export hdd_partitions=
export swap_partitions=
export rootfs_partition=
export netconsole_port=6671
export brand='Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz'
export need_kconfig='CONFIG_BLK_DEV_LOOP'
export commit='3f3bf5920d2df8b0b3df8ec90e21e67316688e95'
export kconfig='x86_64-rhel-7.2'
export compiler='gcc-6'
export rootfs='debian-x86_64-2016-08-31.cgz'
export enqueue_time='2017-07-17 21:34:04 +0800'
export _id='596cbccc0b9a93d8998bd5fd'
export _rt='/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95'
export user='lkp'
export head_commit='e457614996880c0ba13ddf22980b39b56030a491'
export base_commit='6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c'
export branch='linux-devel/devel-hourly-2017071420'
export result_root='/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0'
export LKP_SERVER='inn'
export max_uptime=3600
export initrd='/osimage/debian/debian-x86_64-2016-08-31.cgz'
export bootloader_append='root=/dev/ram0
user=lkp
job=/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml
ARCH=x86_64
kconfig=x86_64-rhel-7.2
branch=linux-devel/devel-hourly-2017071420
commit=3f3bf5920d2df8b0b3df8ec90e21e67316688e95
BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59
max_uptime=3600
RESULT_ROOT=/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0
LKP_SERVER=inn
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
earlyprintk=ttyS0,115200
console=ttyS0,115200
console=tty0
vga=normal
rw'
export lkp_initrd='/lkp/lkp/lkp-x86_64.cgz'
export modules_initrd='/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/modules.cgz'
export bm_initrd='/osimage/deps/debian-x86_64-2016-08-31.cgz/lkp_2017-05-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/rsync-rootfs_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/ltp_2017-07-01.cgz,/osimage/pkg/debian-x86_64-2016-08-31.cgz/ltp-x86_64-10f4a5476_2017-07-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/hw_2016-11-15.cgz'
export site='inn'
export LKP_CGI_PORT=80
export LKP_CIFS_PORT=139
export kernel='/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59'
export dequeue_time='2017-07-17 21:34:38 +0800'
export job_initrd='/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.cgz'
[ -n "$LKP_SRC" ] ||
export LKP_SRC=/lkp/${user:-lkp}/src
}
run_job()
{
echo $$ > $TMP/run-job.pid
. $LKP_SRC/lib/http.sh
. $LKP_SRC/lib/job.sh
. $LKP_SRC/lib/env.sh
export_top_env
run_monitor $LKP_SRC/monitors/wrapper kmsg
run_monitor $LKP_SRC/monitors/wrapper heartbeat
run_monitor $LKP_SRC/monitors/wrapper oom-killer
run_monitor $LKP_SRC/monitors/plain/watchdog
run_monitor $LKP_SRC/monitors/wrapper nfs-hang
run_test test='containers' $LKP_SRC/tests/wrapper ltp
}
extract_stats()
{
$LKP_SRC/stats/wrapper ltp
$LKP_SRC/stats/wrapper kmsg
$LKP_SRC/stats/wrapper time ltp.time
$LKP_SRC/stats/wrapper time
$LKP_SRC/stats/wrapper dmesg
$LKP_SRC/stats/wrapper kmsg
$LKP_SRC/stats/wrapper stderr
$LKP_SRC/stats/wrapper last_state
}
"$@"
[-- Attachment #4: dmesg.xz --]
[-- Type: application/octet-stream, Size: 29584 bytes --]
[-- Attachment #5: ltp.ksh --]
[-- Type: text/plain, Size: 47755 bytes --]
2017-07-17 21:35:16 ./runltp -f containers
INFO: creating /lkp/benchmarks/ltp/output directory
INFO: creating /lkp/benchmarks/ltp/results directory
Checking for required user/group ids
'nobody' user id and group found.
'bin' user id and group found.
'daemon' user id and group found.
Users group found.
Sys group found.
Required users/groups exist.
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
PRETTY_NAME="Debian GNU/Linux stretch/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Linux nhm-white2 4.12.0-10318-g3f3bf59 #1 SMP Sat Jul 15 01:43:38 CST 2017 x86_64 GNU/Linux
Gnu C
util-linux linux 2.28.1
mount mountinfo, assert, debug)
modutils 23
e2fsprogs 1.43.1
Linux C Library > libc.2.23
Dynamic linker (ldd) 2.23
Procps 3.3.12
Net-tools 2.10-alpha
iproute2 iproute2-ss161212
Kbd 69:
Sh-utils 8.25
Modules Loaded rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver netconsole sr_mod cdrom sd_mod sg snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi intel_powerclamp coretemp ata_generic pata_acpi snd_hda_intel kvm_intel snd_hda_codec dcdbas dell_smm_hwmon firewire_ohci snd_hda_core snd_hwdep firewire_core crc_itu_t ata_piix uas snd_pcm serio_raw pcspkr kvm snd_timer irqbypass i7core_edac usb_storage snd libata crc32c_intel soundcore shpchp ip_tables broadcom bcm_phy_lib
free reports:
total used free shared buff/cache available
Mem: 4033168 165708 2948392 9032 919068 3656908
Swap: 0 0 0
/proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5852.25
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
no big block device was specified on commandline.
Tests which require a big block device are disabled.
You can specify it with option -z
COMMAND: /lkp/benchmarks/ltp/bin/ltp-pan -e -S -a 4180 -n 4180 -p -f /tmp/ltp-QKIduxmJCG/alltests -l /lkp/benchmarks/ltp/results/LTP_RUN_ON-2017_07_17-21h_35m_16s.log -C /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.failed -T /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.tconf
LOG File: /lkp/benchmarks/ltp/results/LTP_RUN_ON-2017_07_17-21h_35m_16s.log
FAILED COMMAND File: /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.failed
TCONF COMMAND File: /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.tconf
Running tests.......
<<<test_start>>>
tag=pidns01 stime=1500298516
cmdline="pidns01"
contacts=""
analysis=exit
<<<test_output>>>
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns02 stime=1500298516
cmdline="pidns02"
contacts=""
analysis=exit
<<<test_output>>>
Checking session id & group id inside container
Success: Got Group ID = 1 & Session ID = 1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns03 stime=1500298516
cmdline="pidns03"
contacts=""
analysis=exit
<<<test_output>>>
pidns03 1 TPASS : mounting procfs in a new namespace
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns04 stime=1500298516
cmdline="pidns04"
contacts=""
analysis=exit
<<<test_output>>>
PIDNS test is running inside container
pidns04 1 TPASS : Container init : I was not killed !
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns05 stime=1500298516
cmdline="pidns05"
contacts=""
analysis=exit
<<<test_output>>>
pidns05 0 TINFO : 5 Nested Containers are created
pidns05 1 TPASS : The number of containers killed are 2
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns06 stime=1500298517
cmdline="pidns06"
contacts=""
analysis=exit
<<<test_output>>>
pidns06 0 TINFO : Parent: Passing the pid of the process 4326
Container: killing parent pid=4326 failed as expected with ESRCH
Container: killing non-existent pid failed as expected with ESRCH
pidns06 0 TINFO : Parent: Passing the pid of the process 4326
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns10 stime=1500298517
cmdline="pidns10"
contacts=""
analysis=exit
<<<test_output>>>
cinit: kill(-1, sig) failed with -1 / ESRCH as expected
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns12 stime=1500298518
cmdline="pidns12"
contacts=""
analysis=exit
<<<test_output>>>
pidns12 0 TINFO : parent: PID is 4332
pidns12 1 TPASS : cinit: signalling PID (from other namespace) is 0 as expected
pidns12 0 TINFO : parent: PID is 4332
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns13 stime=1500298518
cmdline="pidns13"
contacts=""
analysis=exit
<<<test_output>>>
pidns13 0 TINFO : cinit2: writing some data in pipe
pidns13 0 TINFO : cinit1: setup handler for async I/O on pipe
pidns13 1 TPASS : cinit1: si_fd is 7, si_code is 1
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns16 stime=1500298520
cmdline="pidns16"
contacts=""
analysis=exit
<<<test_output>>>
pidns16 1 TPASS : container init continued successfuly, after handling signal -USR1
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns17 stime=1500298522
cmdline="pidns17"
contacts=""
analysis=exit
<<<test_output>>>
cinit: all children have terminated.
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns20 stime=1500298523
cmdline="pidns20"
contacts=""
analysis=exit
<<<test_output>>>
pidns20 0 TINFO : cinit: blocked SIGUSR1
pidns20 0 TINFO : cinit: unblocking SIGUSR1
pidns20 1 TPASS : cinit: user function is called as expected
pidns20 0 TINFO : parent: signalled SIGUSR1 to container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns30 stime=1500298523
cmdline="pidns30"
contacts=""
analysis=exit
<<<test_output>>>
mq_open succeeded
successfully registered for notification
successfully registered handler for SIGUSR1
signal originator PID = 0
parent is done - cleaning up
pidns30 0 TINFO : successfully created posix mqueue
pidns30 0 TINFO : mq_send succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns31 stime=1500298523
cmdline="pidns31"
contacts=""
analysis=exit
<<<test_output>>>
pidns31 0 TINFO : parent: successfully created posix mqueue
pidns31 0 TINFO : cinit: my father is ready to receive a message
pidns31 0 TINFO : cinit: mq_open succeeded
pidns31 0 TINFO : cinit: mq_send() succeeded
pidns31 0 TINFO : parent: successfully created posix mqueue
pidns31 0 TINFO : parent: successfully created child (pid = 4364)
pidns31 0 TINFO : parent: successfully registered for notification
pidns31 0 TINFO : parent: successfully registered handler for SIGUSR1
pidns31 1 TPASS : father: signal originator PID = 4364
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns32 stime=1500298523
cmdline="pidns32"
contacts=""
analysis=exit
<<<test_output>>>
pidns32 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=mqns_01 stime=1500298523
cmdline="mqns_01"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 1 TPASS : child process didn't find mqueue
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_01_clone stime=1500298523
cmdline="mqns_01 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 1 TPASS : child process didn't find mqueue
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_02 stime=1500298523
cmdline="mqns_02"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_02 0 TINFO : Checking namespaces isolation (child to parent)
posixmq_namespace_02 1 TPASS : Parent process can't see the mqueue
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through unshare(2).
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_02_clone stime=1500298523
cmdline="mqns_02 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_02 0 TINFO : Checking namespaces isolation (child to parent)
posixmq_namespace_02 1 TPASS : Parent process can't see the mqueue
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_03 stime=1500298523
cmdline="mqns_03"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through unshare(2)
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through unshare(2)
posixmq_namespace_03 0 TINFO : Checking correct umount+remount of mqueuefs
posixmq_namespace_03 1 TPASS : umount+remount of mqueuefs remounted the right fs
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_03_clone stime=1500298523
cmdline="mqns_03 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through clone(2)
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through clone(2)
posixmq_namespace_03 0 TINFO : Checking correct umount+remount of mqueuefs
posixmq_namespace_03 1 TPASS : umount+remount of mqueuefs remounted the right fs
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_04 stime=1500298523
cmdline="mqns_04"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 1 TPASS : Child mqueue fs still visible for parent
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_04_clone stime=1500298523
cmdline="mqns_04 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 1 TPASS : Child mqueue fs still visible for parent
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=netns_netlink stime=1500298524
cmdline="netns_netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_netlink 1 TPASS : netlink interface pass
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv4_netlink stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv4_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_breakns_ns_exec_ipv4_netlink 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv4_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv6_netlink stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv6_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_breakns_ns_exec_ipv6_netlink 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv6_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv4_ioctl stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv4_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_breakns_ns_exec_ipv4_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv4_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=2
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv6_ioctl stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv6_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_breakns_ns_exec_ipv6_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv6_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv4_netlink stime=1500298524
cmdline="netns_breakns.sh ip ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv4_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_breakns_ip_ipv4_netlink 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv4_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv6_netlink stime=1500298524
cmdline="netns_breakns.sh ip ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv6_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_breakns_ip_ipv6_netlink 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv6_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv4_ioctl stime=1500298525
cmdline="netns_breakns.sh ip ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv4_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_breakns_ip_ipv4_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv4_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv6_ioctl stime=1500298525
cmdline="netns_breakns.sh ip ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv6_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_breakns_ip_ipv6_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv6_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv4_netlink stime=1500298525
cmdline="netns_comm.sh ns_exec ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv4_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_comm_ns_exec_ipv4_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv4_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv4_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv6_netlink stime=1500298528
cmdline="netns_comm.sh ns_exec ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv6_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_comm_ns_exec_ipv6_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv6_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv6_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=2
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv4_ioctl stime=1500298532
cmdline="netns_comm.sh ns_exec ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv4_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_comm_ns_exec_ipv4_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv4_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv4_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv6_ioctl stime=1500298535
cmdline="netns_comm.sh ns_exec ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv6_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_comm_ns_exec_ipv6_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv6_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv6_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv4_netlink stime=1500298538
cmdline="netns_comm.sh ip ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv4_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_comm_ip_ipv4_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv4_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv4_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=3 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv6_netlink stime=1500298542
cmdline="netns_comm.sh ip ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv6_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_comm_ip_ipv6_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv6_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv6_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv4_ioctl stime=1500298546
cmdline="netns_comm.sh ip ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv4_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_comm_ip_ipv4_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv4_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv4_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv6_ioctl stime=1500298549
cmdline="netns_comm.sh ip ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv6_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_comm_ip_ipv6_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv6_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv6_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_sysfs stime=1500298553
cmdline="netns_sysfs.sh"
contacts=""
analysis=exit
<<<test_output>>>
netns_sysfs 1 TPASS: sysfs in new namespace has dummy_test1 interface
netns_sysfs 2 TPASS: sysfs in new namespace does not have dummy_test0 interface
netns_sysfs 3 TPASS: sysfs not affected by a separate namespace
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_none stime=1500298553
cmdline="shmnstest none"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : none
sysvipc_namespace 0 TINFO : shmid namespaces test : none
sysvipc_namespace 1 TPASS : plain cloned process found shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_clone stime=1500298553
cmdline="shmnstest clone"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : clone
sysvipc_namespace 0 TINFO : shmid namespaces test : clone
sysvipc_namespace 1 TPASS : clone: child process didn't find shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_unshare stime=1500298553
cmdline="shmnstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : unshare
sysvipc_namespace 0 TINFO : shmid namespaces test : unshare
sysvipc_namespace 1 TPASS : unshare: child process didn't find shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_none stime=1500298553
cmdline="shmem_2nstest none"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 1 TPASS : Plain cloned process able to access shmem segment created
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_clone stime=1500298553
cmdline="shmem_2nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 0 TINFO : Cont2: Able to allocate shmem seg with the same key
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 1 TPASS : clone : In namespace2 unable to access the shmem seg created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_unshare stime=1500298553
cmdline="shmem_2nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 0 TINFO : Cont2: Able to allocate shmem seg with the same key
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 1 TPASS : unshare : In namespace2 unable to access the shmem seg created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shm_comm stime=1500298553
cmdline="shm_comm"
contacts=""
analysis=exit
<<<test_output>>>
shm_comm 1 TPASS : SysV shm: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_none stime=1500298553
cmdline="mesgq_nstest none"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : none
mesgq_nstest 0 TINFO : Mesg read of 18 bytes; Type 5: Msg: Message of type 5!
mesgq_nstest 0 TINFO : mesgq namespaces test : none
mesgq_nstest 1 TPASS : Plain cloned process found mesgq inside container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_clone stime=1500298553
cmdline="mesgq_nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : clone
mesgq_nstest 0 TINFO : mesgq namespaces test : clone
mesgq_nstest 1 TPASS : clone: Container didn't find mesgq
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_unshare stime=1500298553
cmdline="mesgq_nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : unshare
mesgq_nstest 0 TINFO : mesgq namespaces test : unshare
mesgq_nstest 1 TPASS : unshare: Container didn't find mesgq
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=msg_comm stime=1500298553
cmdline="msg_comm"
contacts=""
analysis=exit
<<<test_output>>>
msg_comm 1 TPASS : SysV msg: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_none stime=1500298553
cmdline="sem_nstest none"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : none
sem_nstest 0 TINFO : PID 5072: Fetched existing semaphore..id = 32769
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : none
sem_nstest 1 TPASS : Plain cloned process found semaphore inside container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_clone stime=1500298553
cmdline="sem_nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : clone
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : clone
sem_nstest 1 TPASS : clone: Container didn't find semaphore
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_unshare stime=1500298553
cmdline="sem_nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : unshare
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : unshare
sem_nstest 1 TPASS : unshare: Container didn't find semaphore
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_none stime=1500298553
cmdline="semtest_2ns none"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 0 TINFO : Sem1: File locked, Critical section is updated...
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 1 TPASS : Plain cloned process able to access the semaphore created
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_clone stime=1500298555
cmdline="semtest_2ns clone"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 0 TINFO : Cont2: Able to create semaphore with sameKey
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 1 TPASS : clone : In namespace2 unable to access the semaphore created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_unshare stime=1500298555
cmdline="semtest_2ns unshare"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 0 TINFO : Cont2: Able to create semaphore with sameKey
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 1 TPASS : unshare : In namespace2 unable to access the semaphore created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_comm stime=1500298556
cmdline="sem_comm"
contacts=""
analysis=exit
<<<test_output>>>
sem_comm 1 TPASS : SysV sem: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_1 stime=1500298556
cmdline="utstest unshare 1"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 1 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_2 stime=1500298556
cmdline="utstest unshare 2"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 2 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_3 stime=1500298556
cmdline="utstest unshare 3"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 3 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_4 stime=1500298556
cmdline="utstest unshare 4"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 4 (unshare): successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_5 stime=1500298556
cmdline="utstest unshare 5"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : P2: P1 claims error
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_1 stime=1500298556
cmdline="utstest clone 1"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 1 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_2 stime=1500298556
cmdline="utstest clone 2"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 2 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_3 stime=1500298556
cmdline="utstest clone 3"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 3 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_4 stime=1500298556
cmdline="utstest clone 4"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 4 (clone): successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_5 stime=1500298556
cmdline="utstest clone 5"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : P2: P1 claims error
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns01 stime=1500298556
cmdline="mountns01"
contacts=""
analysis=exit
<<<test_output>>>
mountns01 1 TPASS : shared mount in child passed
mountns01 2 TPASS : shared mount in parent passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns02 stime=1500298556
cmdline="mountns02"
contacts=""
analysis=exit
<<<test_output>>>
mountns02 1 TPASS : private mount in child passed
mountns02 2 TPASS : private mount in parent passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns03 stime=1500298556
cmdline="mountns03"
contacts=""
analysis=exit
<<<test_output>>>
mountns03 1 TPASS : propagation from slave mount passed
mountns03 2 TPASS : propagation to slave mount passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns04 stime=1500298556
cmdline="mountns04"
contacts=""
analysis=exit
<<<test_output>>>
mountns04 1 TPASS : unbindable mount passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns01 stime=1500298556
cmdline="userns01"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace1 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns02 stime=1500298556
cmdline="userns02"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace2 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns03 stime=1500298556
cmdline="userns03"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace3 1 TPASS : setgroups can't be re-enabled
user_namespace3 0 TINFO : Child process returned TPASS
user_namespace3 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns04 stime=1500298556
cmdline="userns04"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace4 0 TINFO : Child process returned TPASS
user_namespace4 0 TINFO : Child process returned TPASS
user_namespace4 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns05 stime=1500298556
cmdline="userns05"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace5 0 TINFO : Child process returned TPASS
user_namespace5 0 TINFO : Child process returned TPASS
user_namespace5 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns06 stime=1500298556
cmdline="userns06"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace6 0 TINFO : Child process returned TPASS
user_namespace6 0 TINFO : Child process returned TFAIL
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns07 stime=1500298556
cmdline="userns07"
contacts=""
analysis=exit
<<<test_output>>>
userns07 0 TINFO : Child process returned TPASS
incrementing stop
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
INFO: ltp-pan reported some tests FAIL
LTP Version: 20170516-93-g10f4a5476
###############################################################
Done executing testcases.
LTP Version: 20170516-93-g10f4a5476
###############################################################
[-- Attachment #6: job.yaml --]
[-- Type: text/plain, Size: 3600 bytes --]
---
#! jobs/ltp.yaml
suite: ltp
testcase: ltp
category: functional
ltp:
test: containers
job_origin: "/lkp/lkp/.src-20170713-182338/allot/cyclic:linux-devel:devel-hourly/nhm-white2/ltp.yaml"
#! queue options
queue: bisect
testbox: nhm-white2
tbox_group: nhm-white2
submit_id: 596cbccc0b9a93d8998bd5fd
job_file: "/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml"
id: bcf686732c701d15cf5dadb19fcea28e34ef0504
#! hosts/nhm-white2
model: Nehalem
memory: 4G
nr_cpu: 8
hdd_partitions:
swap_partitions:
rootfs_partition:
netconsole_port: 6671
brand: Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
#! include/category/functional
kmsg:
heartbeat:
#! include/ltp
need_kconfig: CONFIG_BLK_DEV_LOOP
#! include/queue/cyclic
commit: 3f3bf5920d2df8b0b3df8ec90e21e67316688e95
#! include/testbox/nhm-white2
cpufreq_governor:
#! default params
kconfig: x86_64-rhel-7.2
compiler: gcc-6
rootfs: debian-x86_64-2016-08-31.cgz
enqueue_time: 2017-07-17 21:34:04.819483840 +08:00
_id: 596cbccc0b9a93d8998bd5fd
_rt: "/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95"
#! schedule options
user: lkp
head_commit: e457614996880c0ba13ddf22980b39b56030a491
base_commit: 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
branch: linux-devel/devel-hourly-2017071420
result_root: "/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0"
LKP_SERVER: inn
max_uptime: 3600
initrd: "/osimage/debian/debian-x86_64-2016-08-31.cgz"
bootloader_append:
- root=/dev/ram0
- user=lkp
- job=/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml
- ARCH=x86_64
- kconfig=x86_64-rhel-7.2
- branch=linux-devel/devel-hourly-2017071420
- commit=3f3bf5920d2df8b0b3df8ec90e21e67316688e95
- BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59
- max_uptime=3600
- RESULT_ROOT=/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0
- LKP_SERVER=inn
- debug
- apic=debug
- sysrq_always_enabled
- rcupdate.rcu_cpu_stall_timeout=100
- net.ifnames=0
- printk.devkmsg=on
- panic=-1
- softlockup_panic=1
- nmi_watchdog=panic
- oops=panic
- load_ramdisk=2
- prompt_ramdisk=0
- drbd.minor_count=8
- systemd.log_level=err
- ignore_loglevel
- earlyprintk=ttyS0,115200
- console=ttyS0,115200
- console=tty0
- vga=normal
- rw
lkp_initrd: "/lkp/lkp/lkp-x86_64.cgz"
modules_initrd: "/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/modules.cgz"
bm_initrd: "/osimage/deps/debian-x86_64-2016-08-31.cgz/lkp_2017-05-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/rsync-rootfs_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/ltp_2017-07-01.cgz,/osimage/pkg/debian-x86_64-2016-08-31.cgz/ltp-x86_64-10f4a5476_2017-07-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/hw_2016-11-15.cgz"
site: inn
#! /lkp/lkp/.src-20170717-111651/include/site/inn
LKP_CGI_PORT: 80
LKP_CIFS_PORT: 139
oom-killer:
watchdog:
nfs-hang:
#! runtime status
#! user overrides
kernel: "/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59"
dequeue_time: 2017-07-17 21:34:38.045538335 +08:00
#! /lkp/lkp/.src-20170717-211357/include/site/inn
job_state: failed
loadavg: '0.62'
[-- Attachment #7: reproduce.ksh --]
[-- Type: text/plain, Size: 23 bytes --]
./runltp -f containers
^ permalink raw reply [flat|nested] 288+ messages in thread* [LTP] [lkp-robot] [xattr] 3f3bf5920d: ltp.userns06.fail
@ 2017-07-20 1:05 ` kernel test robot
0 siblings, 0 replies; 288+ messages in thread
From: kernel test robot @ 2017-07-20 1:05 UTC (permalink / raw)
To: ltp
FYI, we noticed the following commit:
commit: 3f3bf5920d2df8b0b3df8ec90e21e67316688e95 ("xattr: Enable security.capability in user namespaces")
url: https://github.com/0day-ci/linux/commits/Stefan-Berger/xattr-Enable-security-capability-in-user-namespaces/20170712-035657
in testcase: ltp
with following parameters:
test: containers
test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
test-url: http://linux-test-project.github.io/
on test machine: 8 threads Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz with 4G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
[ 60.440119] <<<test_start>>>
[ 60.440120]
[ 60.441256] tag=userns06 stime=1500298556
[ 60.441258]
[ 60.442244] cmdline="userns06"
[ 60.442246]
[ 60.442943] contacts=""
[ 60.442945]
[ 60.443774] analysis=exit
[ 60.443776]
[ 60.444626] <<<test_output>>>
[ 60.444628]
[ 60.446472] user_namespace6 0 TINFO : Child process returned TPASS
[ 60.446474]
[ 60.448555] user_namespace6 0 TINFO : Child process returned TFAIL
[ 60.448557]
[ 60.449643] <<<execution_status>>>
[ 60.449645]
[ 60.450596] initiation_status="ok"
[ 60.450598]
[ 60.452640] duration=0 termination_type=exited termination_id=1 corefile=no
[ 60.452641]
[ 60.453663] cutime=0 cstime=0
[ 60.453665]
[ 60.454431] <<<test_end>>>
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Xiaolong
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.12.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
# CONFIG_NO_HZ_FULL_ALL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_RCU_NOCB_CPU=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_BPF is not set
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_POSIX_TIMERS=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_BPF_SYSCALL=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_USERFAULTFD=y
CONFIG_PCI_QUIRKS=y
CONFIG_MEMBARRIER=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
# CONFIG_PC104 is not set
#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLUB_MEMCG_SYSFS_ON is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLAB_MERGE_DEFAULT=y
# CONFIG_SLAB_FREELIST_RANDOM is not set
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SYSTEM_DATA_VERIFICATION is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
# CONFIG_STATIC_KEYS_SELFTEST is not set
CONFIG_OPTPROBES=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_UPROBES=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_NMI=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_ARCH_HAS_SET_MEMORY=y
CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_GCC_PLUGINS=y
# CONFIG_GCC_PLUGINS is not set
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_THIN_ARCHIVES=y
CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_HAVE_ARCH_HUGE_VMAP=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
CONFIG_HAVE_EXIT_THREAD=y
CONFIG_ARCH_MMAP_RND_BITS=28
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES=y
CONFIG_HAVE_COPY_THREAD_TLS=y
CONFIG_HAVE_STACK_VALIDATION=y
# CONFIG_HAVE_ARCH_HASH is not set
# CONFIG_ISA_BUS_API is not set
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_COMPAT_OLD_SIGACTION=y
# CONFIG_CPU_NO_EFFICIENT_FFS is not set
CONFIG_HAVE_ARCH_VMAP_STACK=y
CONFIG_VMAP_STACK=y
# CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set
# CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set
CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
CONFIG_STRICT_MODULE_RWX=y
# CONFIG_REFCOUNT_FULL is not set
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
# CONFIG_MODULE_COMPRESS is not set
# CONFIG_TRIM_UNUSED_KSYMS is not set
CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_BLOCK=y
CONFIG_BLK_SCSI_REQUEST=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y
# CONFIG_BLK_DEV_ZONED is not set
CONFIG_BLK_DEV_THROTTLING=y
# CONFIG_BLK_DEV_THROTTLING_LOW is not set
# CONFIG_BLK_CMDLINE_PARSER is not set
# CONFIG_BLK_WBT is not set
CONFIG_BLK_DEBUG_FS=y
# CONFIG_BLK_SED_OPAL is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_BLOCK_COMPAT=y
CONFIG_BLK_MQ_PCI=y
CONFIG_BLK_MQ_VIRTIO=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_MQ_IOSCHED_DEADLINE=y
CONFIG_MQ_IOSCHED_KYBER=y
# CONFIG_IOSCHED_BFQ is not set
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PADATA=y
CONFIG_ASN1=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_LOCK_SPIN_ON_OWNER=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
CONFIG_QUEUED_SPINLOCKS=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
CONFIG_QUEUED_RWLOCKS=y
CONFIG_FREEZER=y
#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_FAST_FEATURE_TESTS=y
CONFIG_X86_X2APIC=y
CONFIG_X86_MPPARSE=y
# CONFIG_GOLDFISH is not set
CONFIG_INTEL_RDT_A=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_NUMACHIP is not set
# CONFIG_X86_VSMP is not set
CONFIG_X86_UV=y
# CONFIG_X86_GOLDFISH is not set
# CONFIG_X86_INTEL_MID is not set
CONFIG_X86_INTEL_LPSS=y
# CONFIG_X86_AMD_PLATFORM_DEVICE is not set
CONFIG_IOSF_MBI=y
# CONFIG_IOSF_MBI_DEBUG is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
CONFIG_HYPERVISOR_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_PARAVIRT_SPINLOCKS=y
# CONFIG_QUEUED_LOCK_STAT is not set
CONFIG_XEN=y
CONFIG_XEN_PV=y
CONFIG_XEN_PV_SMP=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_PVHVM_SMP=y
CONFIG_XEN_512GB=y
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_XEN_PVH is not set
CONFIG_KVM_GUEST=y
# CONFIG_KVM_DEBUG_FS is not set
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_NO_BOOTMEM=y
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
# CONFIG_PROCESSOR_SELECT is not set
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_MAXSMP=y
CONFIG_NR_CPUS=8192
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_SCHED_MC_PRIO=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCELOG_LEGACY=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=m
CONFIG_X86_THERMAL_VECTOR=y
#
# Performance monitoring
#
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_PERF_EVENTS_INTEL_RAPL=y
CONFIG_PERF_EVENTS_INTEL_CSTATE=y
# CONFIG_PERF_EVENTS_AMD_POWER is not set
# CONFIG_VM86 is not set
CONFIG_X86_16BIT=y
CONFIG_X86_ESPFIX64=y
CONFIG_X86_VSYSCALL_EMULATION=y
CONFIG_I8K=m
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_X86_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=10
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_MEMORY_PROBE=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_HAVE_GENERIC_GUP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
CONFIG_HAVE_BOOTMEM_INFO_NODE=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
# CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is not set
CONFIG_MEMORY_HOTREMOVE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
CONFIG_MEMORY_BALLOON=y
CONFIG_BALLOON_COMPACTION=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
CONFIG_HWPOISON_INJECT=m
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_ARCH_WANTS_THP_SWAP=y
CONFIG_THP_SWAP=y
CONFIG_TRANSPARENT_HUGE_PAGECACHE=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set
# CONFIG_CMA_DEBUGFS is not set
CONFIG_CMA_AREAS=7
# CONFIG_MEM_SOFT_DIRTY is not set
CONFIG_ZSWAP=y
CONFIG_ZPOOL=y
CONFIG_ZBUD=y
# CONFIG_Z3FOLD is not set
CONFIG_ZSMALLOC=y
# CONFIG_PGTABLE_MAPPING is not set
# CONFIG_ZSMALLOC_STAT is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT=y
# CONFIG_DEFERRED_STRUCT_PAGE_INIT is not set
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_ARCH_HAS_ZONE_DEVICE=y
CONFIG_ZONE_DEVICE=y
CONFIG_FRAME_VECTOR=y
CONFIG_ARCH_USES_HIGH_VMA_FLAGS=y
CONFIG_ARCH_HAS_PKEYS=y
# CONFIG_PERCPU_STATS is not set
CONFIG_X86_PMEM_LEGACY_DEVICE=y
CONFIG_X86_PMEM_LEGACY=m
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
# CONFIG_X86_INTEL_MPX is not set
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
# CONFIG_EFI_MIXED is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
# CONFIG_KEXEC_FILE is not set
CONFIG_CRASH_DUMP=y
CONFIG_KEXEC_JUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
# CONFIG_RANDOMIZE_BASE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
CONFIG_BOOTPARAM_HOTPLUG_CPU0=y
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
# CONFIG_LEGACY_VSYSCALL_NATIVE is not set
CONFIG_LEGACY_VSYSCALL_EMULATE=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_MODIFY_LDT_SYSCALL=y
CONFIG_HAVE_LIVEPATCH=y
# CONFIG_LIVEPATCH is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y
#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_SUSPEND_SKIP_SYNC is not set
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_PM_ADVANCED_DEBUG=y
CONFIG_PM_TEST_SUSPEND=y
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_DPM_WATCHDOG is not set
# CONFIG_PM_TRACE_RTC is not set
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
# CONFIG_ACPI_DEBUGGER is not set
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
CONFIG_ACPI_EC_DEBUGFS=m
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_CPU_FREQ_PSS=y
CONFIG_ACPI_PROCESSOR_CSTATE=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_ACPI_CPPC_LIB=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_IPMI=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_ACPI_HOTPLUG_IOAPIC=y
CONFIG_ACPI_SBS=m
CONFIG_ACPI_HED=y
CONFIG_ACPI_CUSTOM_METHOD=m
CONFIG_ACPI_BGRT=y
# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
CONFIG_ACPI_NFIT=m
CONFIG_HAVE_ACPI_APEI=y
CONFIG_HAVE_ACPI_APEI_NMI=y
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_ACPI_APEI_MEMORY_FAILURE=y
CONFIG_ACPI_APEI_EINJ=m
CONFIG_ACPI_APEI_ERST_DEBUG=y
# CONFIG_DPTF_POWER is not set
CONFIG_ACPI_EXTLOG=m
# CONFIG_PMIC_OPREGION is not set
# CONFIG_ACPI_CONFIGFS is not set
CONFIG_SFI=y
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
#
# CPU frequency scaling drivers
#
CONFIG_X86_INTEL_PSTATE=y
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ_CPB=y
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_AMD_FREQ_SENSITIVITY=m
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=m
#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
#
# CPU Idle
#
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_GOV_LADDER is not set
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
CONFIG_INTEL_IDLE=y
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
CONFIG_PCIEAER_INJECT=m
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_POWER_SUPERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_PCIE_PME=y
# CONFIG_PCIE_DPC is not set
# CONFIG_PCIE_PTM is not set
CONFIG_PCI_BUS_ADDR_T_64BIT=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MSI_IRQ_DOMAIN=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
CONFIG_PCI_STUB=y
# CONFIG_XEN_PCIDEV_FRONTEND is not set
CONFIG_HT_IRQ=y
CONFIG_PCI_ATS=y
CONFIG_PCI_LOCKLESS_CONFIG=y
CONFIG_PCI_IOV=y
CONFIG_PCI_PRI=y
CONFIG_PCI_PASID=y
CONFIG_PCI_LABEL=y
# CONFIG_PCI_HYPERV is not set
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m
#
# DesignWare PCI Core Support
#
# CONFIG_PCIE_DW_PLAT is not set
#
# PCI host controller drivers
#
# CONFIG_VMD is not set
#
# PCI Endpoint
#
# CONFIG_PCI_ENDPOINT is not set
#
# PCI switch controller drivers
#
# CONFIG_PCI_SW_SWITCHTEC is not set
# CONFIG_ISA_BUS is not set
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA is not set
CONFIG_CARDBUS=y
#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_RAPIDIO is not set
# CONFIG_X86_SYSFB is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ELFCORE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
# CONFIG_X86_X32 is not set
CONFIG_COMPAT_32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y
CONFIG_NET_INGRESS=y
CONFIG_NET_EGRESS=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=m
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=m
# CONFIG_TLS is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_FIB_TRIE_STATS=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_CLASSID=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE_DEMUX=m
CONFIG_NET_IP_TUNNEL=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_SYN_COOKIES=y
CONFIG_NET_IPVTI=m
CONFIG_NET_UDP_TUNNEL=m
# CONFIG_NET_FOU is not set
# CONFIG_NET_FOU_IP_TUNNELS is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
# CONFIG_INET_ESP_OFFLOAD is not set
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_INET_UDP_DIAG=m
# CONFIG_INET_RAW_DIAG is not set
# CONFIG_INET_DIAG_DESTROY is not set
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
# CONFIG_TCP_CONG_NV is not set
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_TCP_CONG_DCTCP is not set
# CONFIG_TCP_CONG_CDG is not set
# CONFIG_TCP_CONG_BBR is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
# CONFIG_INET6_ESP_OFFLOAD is not set
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
# CONFIG_IPV6_ILA is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
# CONFIG_IPV6_VTI is not set
CONFIG_IPV6_SIT=m
CONFIG_IPV6_SIT_6RD=y
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_FOU is not set
# CONFIG_IPV6_FOU_TUNNEL is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
CONFIG_IPV6_PIMSM_V2=y
# CONFIG_IPV6_SEG6_LWTUNNEL is not set
# CONFIG_IPV6_SEG6_HMAC is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NET_PTP_CLASSIFY=y
CONFIG_NETWORK_PHY_TIMESTAMPING=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=m
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_INGRESS=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_ACCT=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_LOG_COMMON=m
# CONFIG_NF_LOG_NETDEV is not set
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_ZONES=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_EVENTS=y
# CONFIG_NF_CONNTRACK_TIMEOUT is not set
CONFIG_NF_CONNTRACK_TIMESTAMP=y
CONFIG_NF_CONNTRACK_LABELS=y
CONFIG_NF_CT_PROTO_DCCP=y
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=y
CONFIG_NF_CT_PROTO_UDPLITE=y
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_BROADCAST=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_SNMP=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
# CONFIG_NF_CT_NETLINK_TIMEOUT is not set
# CONFIG_NETFILTER_NETLINK_GLUE_CT is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_NF_NAT_PROTO_DCCP=y
CONFIG_NF_NAT_PROTO_UDPLITE=y
CONFIG_NF_NAT_PROTO_SCTP=y
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_SIP=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_REDIRECT=m
CONFIG_NETFILTER_SYNPROXY=m
CONFIG_NF_TABLES=m
# CONFIG_NF_TABLES_INET is not set
# CONFIG_NF_TABLES_NETDEV is not set
CONFIG_NFT_EXTHDR=m
CONFIG_NFT_META=m
# CONFIG_NFT_RT is not set
# CONFIG_NFT_NUMGEN is not set
CONFIG_NFT_CT=m
# CONFIG_NFT_SET_RBTREE is not set
# CONFIG_NFT_SET_HASH is not set
# CONFIG_NFT_SET_BITMAP is not set
CONFIG_NFT_COUNTER=m
CONFIG_NFT_LOG=m
CONFIG_NFT_LIMIT=m
# CONFIG_NFT_MASQ is not set
# CONFIG_NFT_REDIR is not set
CONFIG_NFT_NAT=m
# CONFIG_NFT_OBJREF is not set
# CONFIG_NFT_QUEUE is not set
# CONFIG_NFT_QUOTA is not set
# CONFIG_NFT_REJECT is not set
CONFIG_NFT_COMPAT=m
CONFIG_NFT_HASH=m
CONFIG_NETFILTER_XTABLES=y
#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=m
CONFIG_NETFILTER_XT_CONNMARK=m
CONFIG_NETFILTER_XT_SET=m
#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_AUDIT=m
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_HMARK=m
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_LED=m
CONFIG_NETFILTER_XT_TARGET_LOG=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_NAT=m
CONFIG_NETFILTER_XT_TARGET_NETMAP=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_REDIRECT=m
CONFIG_NETFILTER_XT_TARGET_TEE=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
CONFIG_NETFILTER_XT_MATCH_BPF=m
# CONFIG_NETFILTER_XT_MATCH_CGROUP is not set
CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLABEL=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_CPU=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ECN=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
# CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_IPVS=m
CONFIG_NETFILTER_XT_MATCH_L2TP=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_NFACCT=m
CONFIG_NETFILTER_XT_MATCH_OSF=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_RECENT=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_IP_SET=m
CONFIG_IP_SET_MAX=256
CONFIG_IP_SET_BITMAP_IP=m
CONFIG_IP_SET_BITMAP_IPMAC=m
CONFIG_IP_SET_BITMAP_PORT=m
CONFIG_IP_SET_HASH_IP=m
# CONFIG_IP_SET_HASH_IPMARK is not set
CONFIG_IP_SET_HASH_IPPORT=m
CONFIG_IP_SET_HASH_IPPORTIP=m
CONFIG_IP_SET_HASH_IPPORTNET=m
# CONFIG_IP_SET_HASH_IPMAC is not set
# CONFIG_IP_SET_HASH_MAC is not set
# CONFIG_IP_SET_HASH_NETPORTNET is not set
CONFIG_IP_SET_HASH_NET=m
# CONFIG_IP_SET_HASH_NETNET is not set
CONFIG_IP_SET_HASH_NETPORT=m
CONFIG_IP_SET_HASH_NETIFACE=m
CONFIG_IP_SET_LIST_SET=m
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
# CONFIG_IP_VS_FO is not set
# CONFIG_IP_VS_OVF is not set
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#
# IPVS SH scheduler
#
CONFIG_IP_VS_SH_TAB_BITS=8
#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m
#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
# CONFIG_NF_SOCKET_IPV4 is not set
CONFIG_NF_TABLES_IPV4=m
CONFIG_NFT_CHAIN_ROUTE_IPV4=m
# CONFIG_NFT_REJECT_IPV4 is not set
# CONFIG_NFT_DUP_IPV4 is not set
# CONFIG_NFT_FIB_IPV4 is not set
# CONFIG_NF_TABLES_ARP is not set
CONFIG_NF_DUP_IPV4=m
# CONFIG_NF_LOG_ARP is not set
CONFIG_NF_LOG_IPV4=m
CONFIG_NF_REJECT_IPV4=m
CONFIG_NF_NAT_IPV4=m
CONFIG_NFT_CHAIN_NAT_IPV4=m
CONFIG_NF_NAT_MASQUERADE_IPV4=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_RPFILTER=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_SYNPROXY=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_SECURITY=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
#
# IPv6: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV6=m
CONFIG_NF_CONNTRACK_IPV6=m
# CONFIG_NF_SOCKET_IPV6 is not set
CONFIG_NF_TABLES_IPV6=m
CONFIG_NFT_CHAIN_ROUTE_IPV6=m
# CONFIG_NFT_REJECT_IPV6 is not set
# CONFIG_NFT_DUP_IPV6 is not set
# CONFIG_NFT_FIB_IPV6 is not set
CONFIG_NF_DUP_IPV6=m
CONFIG_NF_REJECT_IPV6=m
CONFIG_NF_LOG_IPV6=m
CONFIG_NF_NAT_IPV6=m
CONFIG_NFT_CHAIN_NAT_IPV6=m
# CONFIG_NF_NAT_MASQUERADE_IPV6 is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RPFILTER=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_TARGET_SYNPROXY=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_RAW=m
CONFIG_IP6_NF_SECURITY=m
# CONFIG_IP6_NF_NAT is not set
CONFIG_NF_TABLES_BRIDGE=m
# CONFIG_NFT_BRIDGE_META is not set
# CONFIG_NF_LOG_BRIDGE is not set
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_IP6=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
#
# DCCP CCIDs Configuration
#
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=y
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_TFRC_LIB=y
#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_NET_DCCPPROBE is not set
CONFIG_IP_SCTP=m
CONFIG_NET_SCTPPROBE=m
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set
CONFIG_SCTP_COOKIE_HMAC_MD5=y
CONFIG_SCTP_COOKIE_HMAC_SHA1=y
CONFIG_INET_SCTP_DIAG=m
# CONFIG_RDS is not set
CONFIG_TIPC=m
CONFIG_TIPC_MEDIA_UDP=y
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_L2TP=m
CONFIG_L2TP_DEBUGFS=m
CONFIG_L2TP_V3=y
CONFIG_L2TP_IP=m
CONFIG_L2TP_ETH=m
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_MRP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_HAVE_NET_DSA=y
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_VLAN_8021Q_MVRP=y
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_6LOWPAN is not set
CONFIG_IEEE802154=m
# CONFIG_IEEE802154_NL802154_EXPERIMENTAL is not set
CONFIG_IEEE802154_SOCKET=m
CONFIG_MAC802154=m
CONFIG_NET_SCHED=y
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_MULTIQ=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFB=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_DRR=m
CONFIG_NET_SCH_MQPRIO=m
CONFIG_NET_SCH_CHOKE=m
CONFIG_NET_SCH_QFQ=m
CONFIG_NET_SCH_CODEL=m
CONFIG_NET_SCH_FQ_CODEL=m
# CONFIG_NET_SCH_FQ is not set
# CONFIG_NET_SCH_HHF is not set
# CONFIG_NET_SCH_PIE is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_PLUG=m
# CONFIG_NET_SCH_DEFAULT is not set
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=m
CONFIG_NET_CLS_CGROUP=y
CONFIG_NET_CLS_BPF=m
# CONFIG_NET_CLS_FLOWER is not set
# CONFIG_NET_CLS_MATCHALL is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_EMATCH_IPSET=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
# CONFIG_NET_ACT_SAMPLE is not set
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_ACT_CSUM=m
# CONFIG_NET_ACT_VLAN is not set
# CONFIG_NET_ACT_BPF is not set
# CONFIG_NET_ACT_CONNMARK is not set
# CONFIG_NET_ACT_SKBMOD is not set
# CONFIG_NET_ACT_IFE is not set
# CONFIG_NET_ACT_TUNNEL_KEY is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
CONFIG_DCB=y
CONFIG_DNS_RESOLVER=m
# CONFIG_BATMAN_ADV is not set
CONFIG_OPENVSWITCH=m
CONFIG_OPENVSWITCH_GRE=m
CONFIG_OPENVSWITCH_VXLAN=m
CONFIG_VSOCKETS=m
CONFIG_VMWARE_VMCI_VSOCKETS=m
# CONFIG_VIRTIO_VSOCKETS is not set
CONFIG_NETLINK_DIAG=m
CONFIG_MPLS=y
CONFIG_NET_MPLS_GSO=m
# CONFIG_MPLS_ROUTING is not set
# CONFIG_HSR is not set
# CONFIG_NET_SWITCHDEV is not set
# CONFIG_NET_L3_MASTER_DEV is not set
# CONFIG_NET_NCSI is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
# CONFIG_CGROUP_NET_PRIO is not set
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
CONFIG_BPF_JIT=y
CONFIG_NET_FLOW_LIMIT=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
CONFIG_NET_DROP_MONITOR=y
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_AF_KCM is not set
# CONFIG_STREAM_PARSER is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211=m
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
CONFIG_CFG80211_CRDA_SUPPORT=y
CONFIG_CFG80211_WEXT=y
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
# CONFIG_MAC80211_RC_MINSTREL_VHT is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
CONFIG_MAC80211_STA_HASH_MAX_SIZE=0
# CONFIG_WIMAX is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_RFKILL_GPIO is not set
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
# CONFIG_NET_9P_XEN is not set
# CONFIG_NET_9P_DEBUG is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
# CONFIG_PSAMPLE is not set
# CONFIG_NET_IFE is not set
# CONFIG_LWTUNNEL is not set
CONFIG_DST_CACHE=y
CONFIG_GRO_CELLS=y
# CONFIG_NET_DEVLINK is not set
CONFIG_MAY_USE_DEVLINK=y
CONFIG_HAVE_EBPF_JIT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_ALLOW_DEV_COREDUMP=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set
# CONFIG_TEST_ASYNC_DRIVER_PROBE is not set
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_DMA_SHARED_BUFFER=y
# CONFIG_DMA_FENCE_TRACE is not set
CONFIG_DMA_CMA=y
#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=200
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=m
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_BLOCK=m
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set
# CONFIG_MTD_PARTITIONED_MASTER is not set
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set
#
# LPDDR & LPDDR2 PCM memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_SPI_NOR is not set
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
# CONFIG_MTD_UBI_BLOCK is not set
# CONFIG_OF is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_NULL_BLK=m
CONFIG_BLK_DEV_FD=m
# CONFIG_PARIDE is not set
CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m
# CONFIG_ZRAM is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=0
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SKD is not set
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_RAM_DAX is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=m
# CONFIG_XEN_BLKDEV_BACKEND is not set
CONFIG_VIRTIO_BLK=y
# CONFIG_VIRTIO_BLK_SCSI is not set
# CONFIG_BLK_DEV_RBD is not set
CONFIG_BLK_DEV_RSXX=m
CONFIG_NVME_CORE=m
CONFIG_BLK_DEV_NVME=m
# CONFIG_NVME_FC is not set
# CONFIG_NVME_TARGET is not set
#
# Misc devices
#
CONFIG_SENSORS_LIS3LV02D=m
# CONFIG_AD525X_DPOT is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_ICS932S401 is not set
CONFIG_ENCLOSURE_SERVICES=m
CONFIG_SGI_XP=m
CONFIG_HP_ILO=m
CONFIG_SGI_GRU=m
# CONFIG_SGI_GRU_DEBUG is not set
CONFIG_APDS9802ALS=m
CONFIG_ISL29003=m
CONFIG_ISL29020=m
CONFIG_SENSORS_TSL2550=m
CONFIG_SENSORS_BH1770=m
CONFIG_SENSORS_APDS990X=m
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
CONFIG_VMWARE_BALLOON=m
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_PCI_ENDPOINT_TEST is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
# CONFIG_EEPROM_AT25 is not set
CONFIG_EEPROM_LEGACY=m
CONFIG_EEPROM_MAX6875=m
CONFIG_EEPROM_93CX6=m
# CONFIG_EEPROM_93XX46 is not set
# CONFIG_EEPROM_IDT_89HPESX is not set
CONFIG_CB710_CORE=m
# CONFIG_CB710_DEBUG is not set
CONFIG_CB710_DEBUG_ASSUMPTIONS=y
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
CONFIG_SENSORS_LIS3_I2C=m
#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=m
CONFIG_INTEL_MEI=y
CONFIG_INTEL_MEI_ME=y
# CONFIG_INTEL_MEI_TXE is not set
CONFIG_VMWARE_VMCI=m
#
# Intel MIC Bus Driver
#
# CONFIG_INTEL_MIC_BUS is not set
#
# SCIF Bus Driver
#
# CONFIG_SCIF_BUS is not set
#
# VOP Bus Driver
#
# CONFIG_VOP_BUS is not set
#
# Intel MIC Host Driver
#
#
# Intel MIC Card Driver
#
#
# SCIF Driver
#
#
# Intel MIC Coprocessor State Management (COSM) Drivers
#
#
# VOP Driver
#
# CONFIG_GENWQE is not set
# CONFIG_ECHO is not set
# CONFIG_CXL_BASE is not set
# CONFIG_CXL_AFU_DRIVER_OPS is not set
# CONFIG_CXL_LIB is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_ENCLOSURE=m
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
CONFIG_ISCSI_BOOT_SYSFS=m
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_SCSI_BNX2X_FCOE=m
CONFIG_BE2ISCSI=m
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_HPSA=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_3W_SAS=m
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=m
# CONFIG_SCSI_AIC7XXX is not set
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC94XX is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
CONFIG_SCSI_MVSAS_TASKLET=y
CONFIG_SCSI_MVUMI=m
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_ARCMSR=m
# CONFIG_SCSI_ESAS2R is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_MPT3SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT3SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS=m
# CONFIG_SCSI_SMARTPQI is not set
CONFIG_SCSI_UFSHCD=m
CONFIG_SCSI_UFSHCD_PCI=m
# CONFIG_SCSI_UFS_DWC_TC_PCI is not set
# CONFIG_SCSI_UFSHCD_PLATFORM is not set
CONFIG_SCSI_HPTIOP=m
# CONFIG_SCSI_BUSLOGIC is not set
CONFIG_VMWARE_PVSCSI=m
# CONFIG_XEN_SCSI_FRONTEND is not set
CONFIG_HYPERV_STORAGE=m
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
CONFIG_FCOE=m
CONFIG_FCOE_FNIC=m
# CONFIG_SCSI_SNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_ISCI=m
# CONFIG_SCSI_IPS is not set
CONFIG_SCSI_INITIO=m
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
CONFIG_SCSI_STEX=m
# CONFIG_SCSI_SYM53C8XX_2 is not set
CONFIG_SCSI_IPR=m
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA_FC=m
# CONFIG_TCM_QLA2XXX is not set
CONFIG_SCSI_QLA_ISCSI=m
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_WD719X is not set
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_PMCRAID=m
CONFIG_SCSI_PM8001=m
# CONFIG_SCSI_BFA_FC is not set
CONFIG_SCSI_VIRTIO=m
CONFIG_SCSI_CHELSIO_FCOE=m
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=y
CONFIG_SCSI_DH_HP_SW=y
CONFIG_SCSI_DH_EMC=y
CONFIG_SCSI_DH_ALUA=y
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
# CONFIG_SATA_ZPODD is not set
CONFIG_SATA_PMP=y
#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
CONFIG_SATA_AHCI_PLATFORM=m
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_ACARD_AHCI=m
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y
#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_SX4=m
CONFIG_ATA_BMDMA=y
#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=m
# CONFIG_SATA_DWC is not set
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_SVW=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m
#
# PATA SFF controllers with BMDMA
#
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=m
CONFIG_PATA_ARTOP=m
CONFIG_PATA_ATIIXP=m
CONFIG_PATA_ATP867X=m
CONFIG_PATA_CMD64X=m
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_PATA_HPT366=m
CONFIG_PATA_HPT37X=m
CONFIG_PATA_HPT3X2N=m
CONFIG_PATA_HPT3X3=m
# CONFIG_PATA_HPT3X3_DMA is not set
CONFIG_PATA_IT8213=m
CONFIG_PATA_IT821X=m
CONFIG_PATA_JMICRON=m
CONFIG_PATA_MARVELL=m
CONFIG_PATA_NETCELL=m
CONFIG_PATA_NINJA32=m
# CONFIG_PATA_NS87415 is not set
CONFIG_PATA_OLDPIIX=m
# CONFIG_PATA_OPTIDMA is not set
CONFIG_PATA_PDC2027X=m
CONFIG_PATA_PDC_OLD=m
# CONFIG_PATA_RADISYS is not set
CONFIG_PATA_RDC=m
CONFIG_PATA_SCH=m
CONFIG_PATA_SERVERWORKS=m
CONFIG_PATA_SIL680=m
CONFIG_PATA_SIS=m
CONFIG_PATA_TOSHIBA=m
# CONFIG_PATA_TRIFLEX is not set
CONFIG_PATA_VIA=m
# CONFIG_PATA_WINBOND is not set
#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_PATA_RZ1000 is not set
#
# Generic fallback / legacy drivers
#
CONFIG_PATA_ACPI=m
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_LEGACY is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
# CONFIG_MD_CLUSTER is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_MQ_DEFAULT is not set
CONFIG_DM_DEBUG=y
CONFIG_DM_BUFIO=m
# CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING is not set
CONFIG_DM_BIO_PRISON=m
CONFIG_DM_PERSISTENT_DATA=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_THIN_PROVISIONING=m
CONFIG_DM_CACHE=m
CONFIG_DM_CACHE_SMQ=m
# CONFIG_DM_ERA is not set
CONFIG_DM_MIRROR=m
CONFIG_DM_LOG_USERSPACE=m
CONFIG_DM_RAID=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_QL=m
CONFIG_DM_MULTIPATH_ST=m
CONFIG_DM_DELAY=m
CONFIG_DM_UEVENT=y
CONFIG_DM_FLAKEY=m
CONFIG_DM_VERITY=m
# CONFIG_DM_VERITY_FEC is not set
CONFIG_DM_SWITCH=m
# CONFIG_DM_LOG_WRITES is not set
# CONFIG_DM_INTEGRITY is not set
CONFIG_TARGET_CORE=m
CONFIG_TCM_IBLOCK=m
CONFIG_TCM_FILEIO=m
CONFIG_TCM_PSCSI=m
# CONFIG_TCM_USER2 is not set
CONFIG_LOOPBACK_TARGET=m
CONFIG_TCM_FC=m
CONFIG_ISCSI_TARGET=m
# CONFIG_ISCSI_TARGET_CXGB4 is not set
# CONFIG_SBP_TARGET is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LOGGING=y
#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
CONFIG_FIREWIRE_NET=m
# CONFIG_FIREWIRE_NOSY is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_MII=y
CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
# CONFIG_EQUALIZER is not set
CONFIG_NET_FC=y
CONFIG_IFB=m
CONFIG_NET_TEAM=m
CONFIG_NET_TEAM_MODE_BROADCAST=m
CONFIG_NET_TEAM_MODE_ROUNDROBIN=m
CONFIG_NET_TEAM_MODE_RANDOM=m
CONFIG_NET_TEAM_MODE_ACTIVEBACKUP=m
CONFIG_NET_TEAM_MODE_LOADBALANCE=m
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_VXLAN=m
# CONFIG_GENEVE is not set
# CONFIG_GTP is not set
# CONFIG_MACSEC is not set
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
CONFIG_TAP=m
# CONFIG_TUN_VNET_CROSS_LE is not set
CONFIG_VETH=m
CONFIG_VIRTIO_NET=y
CONFIG_NLMON=m
# CONFIG_ARCNET is not set
# CONFIG_ATM_DRIVERS is not set
#
# CAIF transport drivers
#
#
# Distributed Switch Architecture drivers
#
CONFIG_ETHERNET=y
CONFIG_MDIO=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
CONFIG_NET_VENDOR_AGERE=y
# CONFIG_ET131X is not set
CONFIG_NET_VENDOR_ALACRITECH=y
# CONFIG_SLICOSS is not set
# CONFIG_NET_VENDOR_ALTEON is not set
# CONFIG_ALTERA_TSE is not set
CONFIG_NET_VENDOR_AMAZON=y
# CONFIG_ENA_ETHERNET is not set
# CONFIG_NET_VENDOR_AMD is not set
CONFIG_NET_VENDOR_AQUANTIA=y
# CONFIG_AQTION is not set
CONFIG_NET_VENDOR_ARC=y
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATL2=m
CONFIG_ATL1=m
CONFIG_ATL1E=m
CONFIG_ATL1C=m
CONFIG_ALX=m
# CONFIG_NET_VENDOR_AURORA is not set
CONFIG_NET_CADENCE=y
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
# CONFIG_BCMGENET is not set
CONFIG_BNX2=m
CONFIG_CNIC=m
CONFIG_TIGON3=y
CONFIG_TIGON3_HWMON=y
# CONFIG_BNX2X is not set
# CONFIG_BNXT is not set
CONFIG_NET_VENDOR_BROCADE=y
CONFIG_BNA=m
CONFIG_NET_VENDOR_CAVIUM=y
# CONFIG_THUNDER_NIC_PF is not set
# CONFIG_THUNDER_NIC_VF is not set
# CONFIG_THUNDER_NIC_BGX is not set
# CONFIG_THUNDER_NIC_RGX is not set
# CONFIG_LIQUIDIO is not set
# CONFIG_LIQUIDIO_VF is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3=m
CONFIG_CHELSIO_T4=m
# CONFIG_CHELSIO_T4_DCB is not set
CONFIG_CHELSIO_T4VF=m
CONFIG_CHELSIO_LIB=m
CONFIG_NET_VENDOR_CISCO=y
CONFIG_ENIC=m
# CONFIG_CX_ECAT is not set
CONFIG_DNET=m
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_DE2104X_DSL=0
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
# CONFIG_NET_VENDOR_DLINK is not set
CONFIG_NET_VENDOR_EMULEX=y
CONFIG_BE2NET=m
CONFIG_BE2NET_HWMON=y
CONFIG_NET_VENDOR_EZCHIP=y
# CONFIG_NET_VENDOR_EXAR is not set
# CONFIG_NET_VENDOR_HP is not set
CONFIG_NET_VENDOR_INTEL=y
# CONFIG_E100 is not set
CONFIG_E1000=y
CONFIG_E1000E=y
CONFIG_E1000E_HWTS=y
CONFIG_IGB=y
CONFIG_IGB_HWMON=y
CONFIG_IGBVF=m
CONFIG_IXGB=m
CONFIG_IXGBE=y
CONFIG_IXGBE_HWMON=y
CONFIG_IXGBE_DCB=y
CONFIG_IXGBEVF=m
CONFIG_I40E=m
# CONFIG_I40E_DCB is not set
# CONFIG_I40EVF is not set
# CONFIG_FM10K is not set
# CONFIG_NET_VENDOR_I825XX is not set
CONFIG_JME=m
CONFIG_NET_VENDOR_MARVELL=y
CONFIG_MVMDIO=m
CONFIG_SKGE=m
CONFIG_SKGE_DEBUG=y
CONFIG_SKGE_GENESIS=y
CONFIG_SKY2=m
CONFIG_SKY2_DEBUG=y
CONFIG_NET_VENDOR_MELLANOX=y
CONFIG_MLX4_EN=m
CONFIG_MLX4_EN_DCB=y
CONFIG_MLX4_CORE=m
CONFIG_MLX4_DEBUG=y
# CONFIG_MLX5_CORE is not set
# CONFIG_MLXSW_CORE is not set
# CONFIG_MLXFW is not set
# CONFIG_NET_VENDOR_MICREL is not set
CONFIG_NET_VENDOR_MICROCHIP=y
# CONFIG_ENC28J60 is not set
# CONFIG_ENCX24J600 is not set
CONFIG_NET_VENDOR_MYRI=y
CONFIG_MYRI10GE=m
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
CONFIG_NET_VENDOR_NETRONOME=y
# CONFIG_NFP is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
CONFIG_NET_VENDOR_OKI=y
CONFIG_ETHOC=m
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
CONFIG_YELLOWFIN=m
CONFIG_NET_VENDOR_QLOGIC=y
CONFIG_QLA3XXX=m
CONFIG_QLCNIC=m
CONFIG_QLCNIC_SRIOV=y
CONFIG_QLCNIC_DCB=y
CONFIG_QLCNIC_HWMON=y
CONFIG_QLGE=m
CONFIG_NETXEN_NIC=m
# CONFIG_QED is not set
CONFIG_NET_VENDOR_QUALCOMM=y
# CONFIG_QCOM_EMAC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_ATP is not set
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R8169=y
CONFIG_NET_VENDOR_RENESAS=y
# CONFIG_NET_VENDOR_RDC is not set
CONFIG_NET_VENDOR_ROCKER=y
CONFIG_NET_VENDOR_SAMSUNG=y
# CONFIG_SXGBE_ETH is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
# CONFIG_NET_VENDOR_SIS is not set
CONFIG_NET_VENDOR_SOLARFLARE=y
CONFIG_SFC=m
CONFIG_SFC_MTD=y
CONFIG_SFC_MCDI_MON=y
CONFIG_SFC_SRIOV=y
CONFIG_SFC_MCDI_LOGGING=y
# CONFIG_SFC_FALCON is not set
CONFIG_NET_VENDOR_SMSC=y
CONFIG_EPIC100=m
# CONFIG_SMSC911X is not set
CONFIG_SMSC9420=m
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_NET_VENDOR_SYNOPSYS=y
# CONFIG_DWC_XLGMAC is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_MDIO_DEVICE=y
CONFIG_MDIO_BITBANG=m
# CONFIG_MDIO_GPIO is not set
# CONFIG_MDIO_THUNDER is not set
CONFIG_PHYLIB=y
CONFIG_SWPHY=y
# CONFIG_LED_TRIGGER_PHY is not set
#
# MII PHY device drivers
#
CONFIG_AMD_PHY=m
# CONFIG_AQUANTIA_PHY is not set
CONFIG_AT803X_PHY=m
# CONFIG_BCM7XXX_PHY is not set
CONFIG_BCM87XX_PHY=m
CONFIG_BCM_NET_PHYLIB=m
CONFIG_BROADCOM_PHY=m
CONFIG_CICADA_PHY=m
# CONFIG_CORTINA_PHY is not set
CONFIG_DAVICOM_PHY=m
# CONFIG_DP83848_PHY is not set
# CONFIG_DP83867_PHY is not set
CONFIG_FIXED_PHY=y
CONFIG_ICPLUS_PHY=m
# CONFIG_INTEL_XWAY_PHY is not set
CONFIG_LSI_ET1011C_PHY=m
CONFIG_LXT_PHY=m
CONFIG_MARVELL_PHY=m
# CONFIG_MARVELL_10G_PHY is not set
CONFIG_MICREL_PHY=m
# CONFIG_MICROCHIP_PHY is not set
# CONFIG_MICROSEMI_PHY is not set
CONFIG_NATIONAL_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_REALTEK_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_STE10XP=m
# CONFIG_TERANETICS_PHY is not set
CONFIG_VITESSE_PHY=m
# CONFIG_XILINX_GMII2RGMII is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_MPPE=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPPOATM=m
CONFIG_PPPOE=m
CONFIG_PPTP=m
CONFIG_PPPOL2TP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_SLIP=m
CONFIG_SLHC=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_USB_NET_DRIVERS=y
CONFIG_USB_CATC=y
CONFIG_USB_KAWETH=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8150=y
CONFIG_USB_RTL8152=m
# CONFIG_USB_LAN78XX is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_AX88179_178A=m
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=m
# CONFIG_USB_NET_HUAWEI_CDC_NCM is not set
CONFIG_USB_NET_CDC_MBIM=m
CONFIG_USB_NET_DM9601=y
# CONFIG_USB_NET_SR9700 is not set
# CONFIG_USB_NET_SR9800 is not set
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_USB_NET_GL620A=y
CONFIG_USB_NET_NET1080=y
CONFIG_USB_NET_PLUSB=y
CONFIG_USB_NET_MCS7830=y
CONFIG_USB_NET_RNDIS_HOST=y
CONFIG_USB_NET_CDC_SUBSET_ENABLE=y
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
CONFIG_USB_NET_CX82310_ETH=m
CONFIG_USB_NET_KALMIA=m
CONFIG_USB_NET_QMI_WWAN=m
CONFIG_USB_HSO=m
CONFIG_USB_NET_INT51X1=y
CONFIG_USB_IPHETH=y
CONFIG_USB_SIERRA_NET=y
CONFIG_USB_VL600=m
# CONFIG_USB_NET_CH9200 is not set
CONFIG_WLAN=y
# CONFIG_WIRELESS_WDS is not set
CONFIG_WLAN_VENDOR_ADMTEK=y
# CONFIG_ADM8211 is not set
CONFIG_WLAN_VENDOR_ATH=y
# CONFIG_ATH_DEBUG is not set
# CONFIG_ATH5K is not set
# CONFIG_ATH5K_PCI is not set
# CONFIG_ATH9K is not set
# CONFIG_ATH9K_HTC is not set
# CONFIG_CARL9170 is not set
# CONFIG_ATH6KL is not set
# CONFIG_AR5523 is not set
# CONFIG_WIL6210 is not set
# CONFIG_ATH10K is not set
# CONFIG_WCN36XX is not set
CONFIG_WLAN_VENDOR_ATMEL=y
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
CONFIG_WLAN_VENDOR_BROADCOM=y
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMSMAC is not set
# CONFIG_BRCMFMAC is not set
CONFIG_WLAN_VENDOR_CISCO=y
# CONFIG_AIRO is not set
CONFIG_WLAN_VENDOR_INTEL=y
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_IWL4965 is not set
# CONFIG_IWL3945 is not set
# CONFIG_IWLWIFI is not set
CONFIG_WLAN_VENDOR_INTERSIL=y
# CONFIG_HOSTAP is not set
# CONFIG_HERMES is not set
# CONFIG_P54_COMMON is not set
# CONFIG_PRISM54 is not set
CONFIG_WLAN_VENDOR_MARVELL=y
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_MWIFIEX is not set
# CONFIG_MWL8K is not set
CONFIG_WLAN_VENDOR_MEDIATEK=y
# CONFIG_MT7601U is not set
CONFIG_WLAN_VENDOR_RALINK=y
# CONFIG_RT2X00 is not set
CONFIG_WLAN_VENDOR_REALTEK=y
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
CONFIG_RTL_CARDS=m
# CONFIG_RTL8192CE is not set
# CONFIG_RTL8192SE is not set
# CONFIG_RTL8192DE is not set
# CONFIG_RTL8723AE is not set
# CONFIG_RTL8723BE is not set
# CONFIG_RTL8188EE is not set
# CONFIG_RTL8192EE is not set
# CONFIG_RTL8821AE is not set
# CONFIG_RTL8192CU is not set
# CONFIG_RTL8XXXU is not set
CONFIG_WLAN_VENDOR_RSI=y
# CONFIG_RSI_91X is not set
CONFIG_WLAN_VENDOR_ST=y
# CONFIG_CW1200 is not set
CONFIG_WLAN_VENDOR_TI=y
# CONFIG_WL1251 is not set
# CONFIG_WL12XX is not set
# CONFIG_WL18XX is not set
# CONFIG_WLCORE is not set
CONFIG_WLAN_VENDOR_ZYDAS=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_ZD1211RW is not set
CONFIG_WLAN_VENDOR_QUANTENNA=y
# CONFIG_QTNFMAC_PEARL_PCIE is not set
CONFIG_MAC80211_HWSIM=m
# CONFIG_USB_NET_RNDIS_WLAN is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
CONFIG_WAN=y
# CONFIG_LANMEDIA is not set
CONFIG_HDLC=m
CONFIG_HDLC_RAW=m
# CONFIG_HDLC_RAW_ETH is not set
CONFIG_HDLC_CISCO=m
CONFIG_HDLC_FR=m
CONFIG_HDLC_PPP=m
#
# X.25/LAPB support is disabled
#
# CONFIG_PCI200SYN is not set
# CONFIG_WANXL is not set
# CONFIG_PC300TOO is not set
# CONFIG_FARSYNC is not set
# CONFIG_DSCC4 is not set
CONFIG_DLCI=m
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
CONFIG_IEEE802154_DRIVERS=m
CONFIG_IEEE802154_FAKELB=m
# CONFIG_IEEE802154_AT86RF230 is not set
# CONFIG_IEEE802154_MRF24J40 is not set
# CONFIG_IEEE802154_CC2520 is not set
# CONFIG_IEEE802154_ATUSB is not set
# CONFIG_IEEE802154_ADF7242 is not set
# CONFIG_IEEE802154_CA8210 is not set
CONFIG_XEN_NETDEV_FRONTEND=m
# CONFIG_XEN_NETDEV_BACKEND is not set
CONFIG_VMXNET3=m
# CONFIG_FUJITSU_ES is not set
CONFIG_HYPERV_NET=m
CONFIG_ISDN=y
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y
#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m
#
# ISDN4Linux hardware drivers
#
#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set
CONFIG_ISDN_CAPI=m
# CONFIG_CAPI_TRACE is not set
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPIDRV=m
# CONFIG_ISDN_CAPI_CAPIDRV_VERBOSE is not set
#
# CAPI hardware drivers
#
CONFIG_CAPI_AVM=y
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
# CONFIG_CAPI_EICON is not set
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_CAPI=y
# CONFIG_GIGASET_I4L is not set
# CONFIG_GIGASET_DUMMYLL is not set
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
CONFIG_GIGASET_M101=m
# CONFIG_GIGASET_DEBUG is not set
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
CONFIG_MISDN=m
CONFIG_MISDN_DSP=m
CONFIG_MISDN_L1OIP=m
#
# mISDN hardware drivers
#
CONFIG_MISDN_HFCPCI=m
CONFIG_MISDN_HFCMULTI=m
CONFIG_MISDN_HFCUSB=m
CONFIG_MISDN_AVMFRITZ=m
CONFIG_MISDN_SPEEDFAX=m
CONFIG_MISDN_INFINEON=m
CONFIG_MISDN_W6692=m
CONFIG_MISDN_NETJET=m
CONFIG_MISDN_IPAC=m
CONFIG_MISDN_ISAR=m
CONFIG_ISDN_HDLC=m
# CONFIG_NVM is not set
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_LEDS=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
CONFIG_INPUT_SPARSEKMAP=m
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_DLINK_DIR685 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_TM2_TOUCHKEY is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_BYD=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_PS2_SENTELIC=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_PS2_FOCALTECH=y
# CONFIG_MOUSE_PS2_VMMOUSE is not set
CONFIG_MOUSE_PS2_SMBUS=y
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_APPLETOUCH=m
CONFIG_MOUSE_BCM5974=m
CONFIG_MOUSE_CYAPA=m
# CONFIG_MOUSE_ELAN_I2C is not set
CONFIG_MOUSE_VSXXXAA=m
# CONFIG_MOUSE_GPIO is not set
CONFIG_MOUSE_SYNAPTICS_I2C=m
CONFIG_MOUSE_SYNAPTICS_USB=m
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
CONFIG_TABLET_USB_ACECAD=m
CONFIG_TABLET_USB_AIPTEK=m
CONFIG_TABLET_USB_GTCO=m
# CONFIG_TABLET_USB_HANWANG is not set
CONFIG_TABLET_USB_KBTAB=m
# CONFIG_TABLET_USB_PEGASUS is not set
# CONFIG_TABLET_SERIAL_WACOM4 is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_PROPERTIES=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX_SERIAL is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GOODIX is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_EKTF2127 is not set
# CONFIG_TOUCHSCREEN_ELAN is not set
# CONFIG_TOUCHSCREEN_ELO is not set
CONFIG_TOUCHSCREEN_WACOM_W8001=m
CONFIG_TOUCHSCREEN_WACOM_I2C=m
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MELFAS_MIP4 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_WDT87XX_I2C is not set
# CONFIG_TOUCHSCREEN_WM97XX is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2004 is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_RM_TS is not set
# CONFIG_TOUCHSCREEN_SILEAD is not set
# CONFIG_TOUCHSCREEN_SIS_I2C is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_STMFTS is not set
# CONFIG_TOUCHSCREEN_SUR40 is not set
# CONFIG_TOUCHSCREEN_SURFACE3_SPI is not set
# CONFIG_TOUCHSCREEN_SX8654 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_TOUCHSCREEN_ZET6223 is not set
# CONFIG_TOUCHSCREEN_ZFORCE is not set
# CONFIG_TOUCHSCREEN_ROHM_BU21023 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_E3X0_BUTTON is not set
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_MMA8450 is not set
CONFIG_INPUT_APANEL=m
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_BEEPER is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_GPIO_DECODER is not set
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
# CONFIG_INPUT_KXTJ9 is not set
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_YEALINK=m
CONFIG_INPUT_CM109=m
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_PWM_BEEPER is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_IMS_PCU is not set
# CONFIG_INPUT_CMA3000 is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
# CONFIG_INPUT_IDEAPAD_SLIDEBAR is not set
# CONFIG_INPUT_DRV260X_HAPTICS is not set
# CONFIG_INPUT_DRV2665_HAPTICS is not set
# CONFIG_INPUT_DRV2667_HAPTICS is not set
# CONFIG_RMI4_CORE is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
# CONFIG_SERIO_PS2MULT is not set
CONFIG_SERIO_ARC_PS2=m
CONFIG_HYPERV_KEYBOARD=m
# CONFIG_USERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_NOZOMI=m
# CONFIG_ISI is not set
CONFIG_N_HDLC=m
CONFIG_N_GSM=m
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
# CONFIG_DEVKMEM is not set
#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_EXAR=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_FSL is not set
CONFIG_SERIAL_8250_DW=y
# CONFIG_SERIAL_8250_RT288X is not set
CONFIG_SERIAL_8250_LPSS=y
CONFIG_SERIAL_8250_MID=y
# CONFIG_SERIAL_8250_MOXA is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
CONFIG_SERIAL_ARC=m
CONFIG_SERIAL_ARC_NR_PORTS=1
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_DEV_BUS is not set
# CONFIG_TTY_PRINTK is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
# CONFIG_IPMI_SSIF is not set
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_HW_RANDOM_TPM=m
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
# CONFIG_HPET_MMAP_DEFAULT is not set
CONFIG_HANGCHECK_TIMER=m
CONFIG_UV_MMTIMER=m
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS=y
# CONFIG_TCG_TIS_SPI is not set
# CONFIG_TCG_TIS_I2C_ATMEL is not set
# CONFIG_TCG_TIS_I2C_INFINEON is not set
# CONFIG_TCG_TIS_I2C_NUVOTON is not set
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
# CONFIG_TCG_XEN is not set
# CONFIG_TCG_CRB is not set
# CONFIG_TCG_VTPM_PROXY is not set
# CONFIG_TCG_TIS_ST33ZP24_I2C is not set
# CONFIG_TCG_TIS_ST33ZP24_SPI is not set
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_ACPI_I2C_OPREGION=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_MUX=m
#
# Multiplexer I2C Chip support
#
# CONFIG_I2C_MUX_GPIO is not set
# CONFIG_I2C_MUX_LTC4306 is not set
# CONFIG_I2C_MUX_PCA9541 is not set
# CONFIG_I2C_MUX_PCA954x is not set
# CONFIG_I2C_MUX_PINCTRL is not set
# CONFIG_I2C_MUX_REG is not set
# CONFIG_I2C_MUX_MLXCPLD is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=y
CONFIG_I2C_ISCH=m
CONFIG_I2C_ISMT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
#
# ACPI drivers
#
CONFIG_I2C_SCMI=m
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DESIGNWARE_CORE=m
CONFIG_I2C_DESIGNWARE_PLATFORM=m
CONFIG_I2C_DESIGNWARE_PCI=m
# CONFIG_I2C_DESIGNWARE_BAYTRAIL is not set
# CONFIG_I2C_EMEV2 is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PCA_PLATFORM=m
# CONFIG_I2C_PXA_PCI is not set
CONFIG_I2C_SIMTEC=m
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_DIOLAN_U2C=m
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_ROBOTFUZZ_OSIF is not set
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m
CONFIG_I2C_VIPERBOARD=m
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_MLXCPLD is not set
CONFIG_I2C_STUB=m
# CONFIG_I2C_SLAVE is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_AXI_SPI_ENGINE is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_BUTTERFLY is not set
# CONFIG_SPI_CADENCE is not set
CONFIG_SPI_DESIGNWARE=m
# CONFIG_SPI_DW_PCI is not set
# CONFIG_SPI_DW_MMIO is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_LM70_LLP is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_PXA2XX=m
CONFIG_SPI_PXA2XX_PCI=m
# CONFIG_SPI_ROCKCHIP is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_ZYNQMP_GQSPI is not set
#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_LOOPBACK_TEST is not set
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_SPI_SLAVE is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
CONFIG_PPS_CLIENT_PARPORT=m
CONFIG_PPS_CLIENT_GPIO=m
#
# PPS generators support
#
#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y
CONFIG_DP83640_PHY=m
CONFIG_PTP_1588_CLOCK_KVM=y
CONFIG_PINCTRL=y
#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
# CONFIG_PINCTRL_AMD is not set
# CONFIG_PINCTRL_MCP23S08 is not set
# CONFIG_PINCTRL_SX150X is not set
CONFIG_PINCTRL_BAYTRAIL=y
# CONFIG_PINCTRL_CHERRYVIEW is not set
# CONFIG_PINCTRL_BROXTON is not set
# CONFIG_PINCTRL_CANNONLAKE is not set
# CONFIG_PINCTRL_GEMINILAKE is not set
# CONFIG_PINCTRL_SUNRISEPOINT is not set
CONFIG_GPIOLIB=y
CONFIG_GPIO_ACPI=y
CONFIG_GPIOLIB_IRQCHIP=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y
#
# Memory mapped GPIO drivers
#
# CONFIG_GPIO_AMDPT is not set
# CONFIG_GPIO_DWAPB is not set
# CONFIG_GPIO_EXAR is not set
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_ICH is not set
CONFIG_GPIO_LYNXPOINT=m
CONFIG_GPIO_MOCKUP=y
# CONFIG_GPIO_VX855 is not set
#
# Port-mapped I/O GPIO drivers
#
# CONFIG_GPIO_F7188X is not set
# CONFIG_GPIO_IT87 is not set
# CONFIG_GPIO_SCH is not set
# CONFIG_GPIO_SCH311X is not set
#
# I2C GPIO expanders
#
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_TPIC2810 is not set
#
# MFD GPIO expanders
#
#
# PCI GPIO expanders
#
# CONFIG_GPIO_AMD8111 is not set
# CONFIG_GPIO_ML_IOH is not set
# CONFIG_GPIO_PCI_IDIO_16 is not set
# CONFIG_GPIO_RDC321X is not set
#
# SPI GPIO expanders
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_PISOSR is not set
# CONFIG_GPIO_XRA1403 is not set
#
# USB GPIO expanders
#
# CONFIG_GPIO_VIPERBOARD is not set
# CONFIG_W1 is not set
# CONFIG_POWER_AVS is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_CHARGER_SBS is not set
# CONFIG_BATTERY_BQ27XXX is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_ISP1704 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_LTC3651 is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_BQ24190 is not set
# CONFIG_CHARGER_BQ24257 is not set
# CONFIG_CHARGER_BQ24735 is not set
# CONFIG_CHARGER_BQ25890 is not set
CONFIG_CHARGER_SMB347=m
# CONFIG_BATTERY_GAUGE_LTC2941 is not set
# CONFIG_CHARGER_RT9455 is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Native drivers
#
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
# CONFIG_SENSORS_AD7314 is not set
CONFIG_SENSORS_AD7414=m
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7X10=m
# CONFIG_SENSORS_ADT7310 is not set
CONFIG_SENSORS_ADT7410=m
CONFIG_SENSORS_ADT7411=m
CONFIG_SENSORS_ADT7462=m
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_ADT7475=m
CONFIG_SENSORS_ASC7621=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_K10TEMP=m
CONFIG_SENSORS_FAM15H_POWER=m
CONFIG_SENSORS_APPLESMC=m
CONFIG_SENSORS_ASB100=m
# CONFIG_SENSORS_ASPEED is not set
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS620=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_DELL_SMM=m
CONFIG_SENSORS_I5K_AMB=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
CONFIG_SENSORS_FSCHMD=m
# CONFIG_SENSORS_FTSTEUTATES is not set
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_G760A=m
# CONFIG_SENSORS_G762 is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_HIH6130 is not set
CONFIG_SENSORS_IBMAEM=m
CONFIG_SENSORS_IBMPEX=m
# CONFIG_SENSORS_I5500 is not set
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_POWR1220 is not set
CONFIG_SENSORS_LINEAGE=m
# CONFIG_SENSORS_LTC2945 is not set
# CONFIG_SENSORS_LTC2990 is not set
CONFIG_SENSORS_LTC4151=m
CONFIG_SENSORS_LTC4215=m
# CONFIG_SENSORS_LTC4222 is not set
CONFIG_SENSORS_LTC4245=m
# CONFIG_SENSORS_LTC4260 is not set
CONFIG_SENSORS_LTC4261=m
# CONFIG_SENSORS_MAX1111 is not set
CONFIG_SENSORS_MAX16065=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_MAX1668=m
CONFIG_SENSORS_MAX197=m
# CONFIG_SENSORS_MAX31722 is not set
CONFIG_SENSORS_MAX6639=m
CONFIG_SENSORS_MAX6642=m
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_MAX6697=m
# CONFIG_SENSORS_MAX31790 is not set
CONFIG_SENSORS_MCP3021=m
# CONFIG_SENSORS_TC654 is not set
# CONFIG_SENSORS_ADCXX is not set
CONFIG_SENSORS_LM63=m
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_LM93=m
CONFIG_SENSORS_LM95234=m
CONFIG_SENSORS_LM95241=m
CONFIG_SENSORS_LM95245=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_NTC_THERMISTOR=m
# CONFIG_SENSORS_NCT6683 is not set
CONFIG_SENSORS_NCT6775=m
# CONFIG_SENSORS_NCT7802 is not set
# CONFIG_SENSORS_NCT7904 is not set
CONFIG_SENSORS_PCF8591=m
CONFIG_PMBUS=m
CONFIG_SENSORS_PMBUS=m
CONFIG_SENSORS_ADM1275=m
# CONFIG_SENSORS_IR35221 is not set
CONFIG_SENSORS_LM25066=m
CONFIG_SENSORS_LTC2978=m
# CONFIG_SENSORS_LTC3815 is not set
CONFIG_SENSORS_MAX16064=m
# CONFIG_SENSORS_MAX20751 is not set
CONFIG_SENSORS_MAX34440=m
CONFIG_SENSORS_MAX8688=m
# CONFIG_SENSORS_TPS40422 is not set
CONFIG_SENSORS_UCD9000=m
CONFIG_SENSORS_UCD9200=m
CONFIG_SENSORS_ZL6100=m
# CONFIG_SENSORS_SHT15 is not set
CONFIG_SENSORS_SHT21=m
# CONFIG_SENSORS_SHT3x is not set
# CONFIG_SENSORS_SHTC1 is not set
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_DME1737=m
CONFIG_SENSORS_EMC1403=m
# CONFIG_SENSORS_EMC2103 is not set
CONFIG_SENSORS_EMC6W201=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_SCH56XX_COMMON=m
CONFIG_SENSORS_SCH5627=m
CONFIG_SENSORS_SCH5636=m
# CONFIG_SENSORS_STTS751 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_ADC128D818 is not set
CONFIG_SENSORS_ADS1015=m
CONFIG_SENSORS_ADS7828=m
# CONFIG_SENSORS_ADS7871 is not set
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA209=m
CONFIG_SENSORS_INA2XX=m
# CONFIG_SENSORS_INA3221 is not set
# CONFIG_SENSORS_TC74 is not set
CONFIG_SENSORS_THMC50=m
CONFIG_SENSORS_TMP102=m
# CONFIG_SENSORS_TMP103 is not set
# CONFIG_SENSORS_TMP108 is not set
CONFIG_SENSORS_TMP401=m
CONFIG_SENSORS_TMP421=m
CONFIG_SENSORS_VIA_CPUTEMP=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83795=m
# CONFIG_SENSORS_W83795_FANCTRL is not set
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83L786NG=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
# CONFIG_SENSORS_XGENE is not set
#
# ACPI drivers
#
CONFIG_SENSORS_ACPI_POWER=m
CONFIG_SENSORS_ATK0110=m
CONFIG_THERMAL=y
CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_WRITABLE_TRIPS=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set
CONFIG_THERMAL_GOV_FAIR_SHARE=y
CONFIG_THERMAL_GOV_STEP_WISE=y
CONFIG_THERMAL_GOV_BANG_BANG=y
CONFIG_THERMAL_GOV_USER_SPACE=y
# CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_EMULATION is not set
CONFIG_INTEL_POWERCLAMP=m
CONFIG_X86_PKG_TEMP_THERMAL=m
# CONFIG_INTEL_SOC_DTS_THERMAL is not set
#
# ACPI INT340X thermal drivers
#
# CONFIG_INT340X_THERMAL is not set
CONFIG_INTEL_PCH_THERMAL=m
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
# CONFIG_WATCHDOG_SYSFS is not set
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_WDAT_WDT is not set
# CONFIG_XILINX_WATCHDOG is not set
# CONFIG_ZIIRAVE_WATCHDOG is not set
# CONFIG_CADENCE_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_F71808E_WDT=m
CONFIG_SP5100_TCO=m
CONFIG_SBC_FITPC2_WATCHDOG=m
# CONFIG_EUROTECH_WDT is not set
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=y
CONFIG_IE6XX_WDT=m
CONFIG_ITCO_WDT=y
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_IT8712F_WDT=m
CONFIG_IT87_WDT=m
CONFIG_HP_WATCHDOG=m
CONFIG_HPWDT_NMI_DECODING=y
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
CONFIG_NV_TCO=m
# CONFIG_60XX_WDT is not set
# CONFIG_CPU5_WDT is not set
CONFIG_SMSC_SCH311X_WDT=m
# CONFIG_SMSC37B787_WDT is not set
CONFIG_VIA_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
# CONFIG_INTEL_MEI_WDT is not set
# CONFIG_NI903X_WDT is not set
# CONFIG_NIC7018_WDT is not set
# CONFIG_MEN_A21_WDT is not set
CONFIG_XEN_WDT=m
#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
#
# Watchdog Pretimeout Governors
#
# CONFIG_WATCHDOG_PRETIMEOUT_GOV is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
CONFIG_SSB_SDIOHOST_POSSIBLE=y
CONFIG_SSB_SDIOHOST=y
# CONFIG_SSB_SILENT is not set
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y
# CONFIG_SSB_DRIVER_GPIO is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
CONFIG_BCMA=m
CONFIG_BCMA_HOST_PCI_POSSIBLE=y
CONFIG_BCMA_HOST_PCI=y
# CONFIG_BCMA_HOST_SOC is not set
CONFIG_BCMA_DRIVER_PCI=y
CONFIG_BCMA_DRIVER_GMAC_CMN=y
# CONFIG_BCMA_DRIVER_GPIO is not set
# CONFIG_BCMA_DEBUG is not set
#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_BCM590XX is not set
# CONFIG_MFD_AXP20X_I2C is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9062 is not set
# CONFIG_MFD_DA9063 is not set
# CONFIG_MFD_DA9150 is not set
# CONFIG_MFD_DLN2 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_INTEL_QUARK_I2C_GPIO is not set
CONFIG_LPC_ICH=y
CONFIG_LPC_SCH=m
# CONFIG_INTEL_SOC_PMIC is not set
# CONFIG_INTEL_SOC_PMIC_CHTWC is not set
# CONFIG_MFD_INTEL_LPSS_ACPI is not set
# CONFIG_MFD_INTEL_LPSS_PCI is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX14577 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX77843 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_MENF21BMC is not set
# CONFIG_EZX_PCAP is not set
CONFIG_MFD_VIPERBOARD=m
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_UCB1400_CORE is not set
# CONFIG_MFD_RDC321X is not set
CONFIG_MFD_RTSX_PCI=m
# CONFIG_MFD_RT5033 is not set
# CONFIG_MFD_RTSX_USB is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
CONFIG_MFD_SM501=m
# CONFIG_MFD_SM501_GPIO is not set
# CONFIG_MFD_SKY81452 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP3943 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_TI_LMU is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65086 is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TI_LP873X is not set
# CONFIG_MFD_TPS65218 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TMIO is not set
CONFIG_MFD_VX855=m
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_REGULATOR is not set
CONFIG_MEDIA_SUPPORT=m
#
# Multimedia core support
#
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_RADIO_SUPPORT=y
# CONFIG_MEDIA_SDR_SUPPORT is not set
CONFIG_MEDIA_RC_SUPPORT=y
# CONFIG_MEDIA_CEC_SUPPORT is not set
# CONFIG_MEDIA_CONTROLLER is not set
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2=m
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEOBUF_VMALLOC=m
CONFIG_VIDEOBUF_DVB=m
CONFIG_VIDEOBUF2_CORE=m
CONFIG_VIDEOBUF2_MEMOPS=m
CONFIG_VIDEOBUF2_VMALLOC=m
CONFIG_VIDEOBUF2_DMA_SG=m
CONFIG_VIDEOBUF2_DVB=m
CONFIG_DVB_CORE=m
CONFIG_DVB_NET=y
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_MAX_ADAPTERS=8
CONFIG_DVB_DYNAMIC_MINORS=y
# CONFIG_DVB_DEMUX_SECTION_LOSS_LOG is not set
#
# Media drivers
#
CONFIG_RC_CORE=m
CONFIG_RC_MAP=m
CONFIG_RC_DECODERS=y
CONFIG_LIRC=m
CONFIG_IR_LIRC_CODEC=m
CONFIG_IR_NEC_DECODER=m
CONFIG_IR_RC5_DECODER=m
CONFIG_IR_RC6_DECODER=m
CONFIG_IR_JVC_DECODER=m
CONFIG_IR_SONY_DECODER=m
CONFIG_IR_SANYO_DECODER=m
CONFIG_IR_SHARP_DECODER=m
CONFIG_IR_MCE_KBD_DECODER=m
CONFIG_IR_XMP_DECODER=m
CONFIG_RC_DEVICES=y
CONFIG_RC_ATI_REMOTE=m
CONFIG_IR_ENE=m
# CONFIG_IR_HIX5HD2 is not set
CONFIG_IR_IMON=m
CONFIG_IR_MCEUSB=m
CONFIG_IR_ITE_CIR=m
CONFIG_IR_FINTEK=m
CONFIG_IR_NUVOTON=m
CONFIG_IR_REDRAT3=m
# CONFIG_IR_SPI is not set
CONFIG_IR_STREAMZAP=m
CONFIG_IR_WINBOND_CIR=m
# CONFIG_IR_IGORPLUGUSB is not set
CONFIG_IR_IGUANA=m
CONFIG_IR_TTUSBIR=m
# CONFIG_RC_LOOPBACK is not set
CONFIG_IR_GPIO_CIR=m
# CONFIG_IR_SERIAL is not set
# CONFIG_IR_SIR is not set
CONFIG_MEDIA_USB_SUPPORT=y
#
# Webcam devices
#
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_GSPCA=m
CONFIG_USB_M5602=m
CONFIG_USB_STV06XX=m
CONFIG_USB_GL860=m
CONFIG_USB_GSPCA_BENQ=m
CONFIG_USB_GSPCA_CONEX=m
CONFIG_USB_GSPCA_CPIA1=m
# CONFIG_USB_GSPCA_DTCS033 is not set
CONFIG_USB_GSPCA_ETOMS=m
CONFIG_USB_GSPCA_FINEPIX=m
CONFIG_USB_GSPCA_JEILINJ=m
CONFIG_USB_GSPCA_JL2005BCD=m
# CONFIG_USB_GSPCA_KINECT is not set
CONFIG_USB_GSPCA_KONICA=m
CONFIG_USB_GSPCA_MARS=m
CONFIG_USB_GSPCA_MR97310A=m
CONFIG_USB_GSPCA_NW80X=m
CONFIG_USB_GSPCA_OV519=m
CONFIG_USB_GSPCA_OV534=m
CONFIG_USB_GSPCA_OV534_9=m
CONFIG_USB_GSPCA_PAC207=m
CONFIG_USB_GSPCA_PAC7302=m
CONFIG_USB_GSPCA_PAC7311=m
CONFIG_USB_GSPCA_SE401=m
CONFIG_USB_GSPCA_SN9C2028=m
CONFIG_USB_GSPCA_SN9C20X=m
CONFIG_USB_GSPCA_SONIXB=m
CONFIG_USB_GSPCA_SONIXJ=m
CONFIG_USB_GSPCA_SPCA500=m
CONFIG_USB_GSPCA_SPCA501=m
CONFIG_USB_GSPCA_SPCA505=m
CONFIG_USB_GSPCA_SPCA506=m
CONFIG_USB_GSPCA_SPCA508=m
CONFIG_USB_GSPCA_SPCA561=m
CONFIG_USB_GSPCA_SPCA1528=m
CONFIG_USB_GSPCA_SQ905=m
CONFIG_USB_GSPCA_SQ905C=m
CONFIG_USB_GSPCA_SQ930X=m
CONFIG_USB_GSPCA_STK014=m
# CONFIG_USB_GSPCA_STK1135 is not set
CONFIG_USB_GSPCA_STV0680=m
CONFIG_USB_GSPCA_SUNPLUS=m
CONFIG_USB_GSPCA_T613=m
CONFIG_USB_GSPCA_TOPRO=m
# CONFIG_USB_GSPCA_TOUPTEK is not set
CONFIG_USB_GSPCA_TV8532=m
CONFIG_USB_GSPCA_VC032X=m
CONFIG_USB_GSPCA_VICAM=m
CONFIG_USB_GSPCA_XIRLINK_CIT=m
CONFIG_USB_GSPCA_ZC3XX=m
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set
CONFIG_USB_PWC_INPUT_EVDEV=y
# CONFIG_VIDEO_CPIA2 is not set
CONFIG_USB_ZR364XX=m
CONFIG_USB_STKWEBCAM=m
CONFIG_USB_S2255=m
# CONFIG_VIDEO_USBTV is not set
#
# Analog TV USB devices
#
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_SYSFS=y
CONFIG_VIDEO_PVRUSB2_DVB=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_HDPVR=m
CONFIG_VIDEO_USBVISION=m
# CONFIG_VIDEO_STK1160_COMMON is not set
# CONFIG_VIDEO_GO7007 is not set
#
# Analog/digital TV USB devices
#
CONFIG_VIDEO_AU0828=m
CONFIG_VIDEO_AU0828_V4L2=y
# CONFIG_VIDEO_AU0828_RC is not set
CONFIG_VIDEO_CX231XX=m
CONFIG_VIDEO_CX231XX_RC=y
CONFIG_VIDEO_CX231XX_ALSA=m
CONFIG_VIDEO_CX231XX_DVB=m
CONFIG_VIDEO_TM6000=m
CONFIG_VIDEO_TM6000_ALSA=m
CONFIG_VIDEO_TM6000_DVB=m
#
# Digital TV USB devices
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_DIB3000MC=m
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
CONFIG_DVB_USB_M920X=m
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_TTUSB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_USB_OPERA1=m
CONFIG_DVB_USB_AF9005=m
CONFIG_DVB_USB_AF9005_REMOTE=m
CONFIG_DVB_USB_PCTV452E=m
CONFIG_DVB_USB_DW2102=m
CONFIG_DVB_USB_CINERGY_T2=m
CONFIG_DVB_USB_DTV5100=m
CONFIG_DVB_USB_FRIIO=m
CONFIG_DVB_USB_AZ6027=m
CONFIG_DVB_USB_TECHNISAT_USB2=m
CONFIG_DVB_USB_V2=m
CONFIG_DVB_USB_AF9015=m
CONFIG_DVB_USB_AF9035=m
CONFIG_DVB_USB_ANYSEE=m
CONFIG_DVB_USB_AU6610=m
CONFIG_DVB_USB_AZ6007=m
CONFIG_DVB_USB_CE6230=m
CONFIG_DVB_USB_EC168=m
CONFIG_DVB_USB_GL861=m
CONFIG_DVB_USB_LME2510=m
CONFIG_DVB_USB_MXL111SF=m
CONFIG_DVB_USB_RTL28XXU=m
# CONFIG_DVB_USB_DVBSKY is not set
# CONFIG_DVB_USB_ZD1301 is not set
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_SMS_USB_DRV=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_USB_DEBUG is not set
# CONFIG_DVB_AS102 is not set
#
# Webcam, TV (analog/digital) USB devices
#
CONFIG_VIDEO_EM28XX=m
# CONFIG_VIDEO_EM28XX_V4L2 is not set
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_DVB=m
CONFIG_VIDEO_EM28XX_RC=m
CONFIG_MEDIA_PCI_SUPPORT=y
#
# Media capture support
#
# CONFIG_VIDEO_MEYE is not set
# CONFIG_VIDEO_SOLO6X10 is not set
# CONFIG_VIDEO_TW5864 is not set
# CONFIG_VIDEO_TW68 is not set
# CONFIG_VIDEO_TW686X is not set
# CONFIG_VIDEO_ZORAN is not set
#
# Media capture/analog TV support
#
CONFIG_VIDEO_IVTV=m
# CONFIG_VIDEO_IVTV_DEPRECATED_IOCTLS is not set
# CONFIG_VIDEO_IVTV_ALSA is not set
CONFIG_VIDEO_FB_IVTV=m
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DT3155 is not set
#
# Media capture/analog/hybrid TV support
#
CONFIG_VIDEO_CX18=m
CONFIG_VIDEO_CX18_ALSA=m
CONFIG_VIDEO_CX23885=m
CONFIG_MEDIA_ALTERA_CI=m
# CONFIG_VIDEO_CX25821 is not set
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_ENABLE_VP3054=y
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CX88_MPEG=m
CONFIG_VIDEO_BT848=m
CONFIG_DVB_BT8XX=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_RC=y
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_SAA7164=m
#
# Media digital TV PCI Adapters
#
CONFIG_DVB_AV7110_IR=y
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET_CORE=m
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
# CONFIG_DVB_B2C2_FLEXCOP_PCI_DEBUG is not set
CONFIG_DVB_PLUTO2=m
CONFIG_DVB_DM1105=m
CONFIG_DVB_PT1=m
# CONFIG_DVB_PT3 is not set
CONFIG_MANTIS_CORE=m
CONFIG_DVB_MANTIS=m
CONFIG_DVB_HOPPER=m
CONFIG_DVB_NGENE=m
CONFIG_DVB_DDBRIDGE=m
# CONFIG_DVB_SMIPCIE is not set
# CONFIG_DVB_NETUP_UNIDVB is not set
# CONFIG_V4L_PLATFORM_DRIVERS is not set
# CONFIG_V4L_MEM2MEM_DRIVERS is not set
# CONFIG_V4L_TEST_DRIVERS is not set
# CONFIG_DVB_PLATFORM_DRIVERS is not set
#
# Supported MMC/SDIO adapters
#
CONFIG_SMS_SDIO_DRV=m
CONFIG_RADIO_ADAPTERS=y
CONFIG_RADIO_TEA575X=m
# CONFIG_RADIO_SI470X is not set
# CONFIG_RADIO_SI4713 is not set
# CONFIG_USB_MR800 is not set
# CONFIG_USB_DSBR is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_SHARK is not set
# CONFIG_RADIO_SHARK2 is not set
# CONFIG_USB_KEENE is not set
# CONFIG_USB_RAREMONO is not set
# CONFIG_USB_MA901 is not set
# CONFIG_RADIO_TEA5764 is not set
# CONFIG_RADIO_SAA7706H is not set
# CONFIG_RADIO_TEF6862 is not set
# CONFIG_RADIO_WL1273 is not set
#
# Texas Instruments WL128x FM driver (ST based)
#
#
# Supported FireWire (IEEE 1394) Adapters
#
CONFIG_DVB_FIREDTV=m
CONFIG_DVB_FIREDTV_INPUT=y
CONFIG_MEDIA_COMMON_OPTIONS=y
#
# common driver options
#
CONFIG_VIDEO_CX2341X=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_CYPRESS_FIRMWARE=m
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_SMS_SIANO_MDTV=m
CONFIG_SMS_SIANO_RC=y
# CONFIG_SMS_SIANO_DEBUGFS is not set
#
# Media ancillary drivers (tuners, sensors, i2c, spi, frontends)
#
CONFIG_MEDIA_SUBDRV_AUTOSELECT=y
CONFIG_MEDIA_ATTACH=y
CONFIG_VIDEO_IR_I2C=m
#
# Audio decoders, processors and mixers
#
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_CS3308=m
CONFIG_VIDEO_CS5345=m
CONFIG_VIDEO_CS53L32A=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_WM8739=m
CONFIG_VIDEO_VP27SMPX=m
#
# RDS decoders
#
CONFIG_VIDEO_SAA6588=m
#
# Video decoders
#
CONFIG_VIDEO_SAA711X=m
#
# Video and audio decoders
#
CONFIG_VIDEO_SAA717X=m
CONFIG_VIDEO_CX25840=m
#
# Video encoders
#
CONFIG_VIDEO_SAA7127=m
#
# Camera sensor devices
#
#
# Flash devices
#
#
# Video improvement chips
#
CONFIG_VIDEO_UPD64031A=m
CONFIG_VIDEO_UPD64083=m
#
# Audio/Video compression chips
#
CONFIG_VIDEO_SAA6752HS=m
#
# SDR tuner chips
#
#
# Miscellaneous helper chips
#
CONFIG_VIDEO_M52790=m
#
# Sensors used on soc_camera driver
#
CONFIG_MEDIA_TUNER=m
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA827X=m
CONFIG_MEDIA_TUNER_TDA18271=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_MT2060=m
CONFIG_MEDIA_TUNER_MT2063=m
CONFIG_MEDIA_TUNER_MT2266=m
CONFIG_MEDIA_TUNER_MT2131=m
CONFIG_MEDIA_TUNER_QT1010=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_XC4000=m
CONFIG_MEDIA_TUNER_MXL5005S=m
CONFIG_MEDIA_TUNER_MXL5007T=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_MEDIA_TUNER_MAX2165=m
CONFIG_MEDIA_TUNER_TDA18218=m
CONFIG_MEDIA_TUNER_FC0011=m
CONFIG_MEDIA_TUNER_FC0012=m
CONFIG_MEDIA_TUNER_FC0013=m
CONFIG_MEDIA_TUNER_TDA18212=m
CONFIG_MEDIA_TUNER_E4000=m
CONFIG_MEDIA_TUNER_FC2580=m
CONFIG_MEDIA_TUNER_M88RS6000T=m
CONFIG_MEDIA_TUNER_TUA9001=m
CONFIG_MEDIA_TUNER_SI2157=m
CONFIG_MEDIA_TUNER_IT913X=m
CONFIG_MEDIA_TUNER_R820T=m
CONFIG_MEDIA_TUNER_QM1D1C0042=m
#
# Multistandard (satellite) frontends
#
CONFIG_DVB_STB0899=m
CONFIG_DVB_STB6100=m
CONFIG_DVB_STV090x=m
CONFIG_DVB_STV6110x=m
CONFIG_DVB_M88DS3103=m
#
# Multistandard (cable + terrestrial) frontends
#
CONFIG_DVB_DRXK=m
CONFIG_DVB_TDA18271C2DD=m
CONFIG_DVB_SI2165=m
CONFIG_DVB_MN88472=m
CONFIG_DVB_MN88473=m
#
# DVB-S (satellite) frontends
#
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_MT312=m
CONFIG_DVB_ZL10036=m
CONFIG_DVB_ZL10039=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_STV0288=m
CONFIG_DVB_STB6000=m
CONFIG_DVB_STV0299=m
CONFIG_DVB_STV6110=m
CONFIG_DVB_STV0900=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA10086=m
CONFIG_DVB_TDA8261=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_TUNER_ITD1000=m
CONFIG_DVB_TUNER_CX24113=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUA6100=m
CONFIG_DVB_CX24116=m
CONFIG_DVB_CX24117=m
CONFIG_DVB_CX24120=m
CONFIG_DVB_SI21XX=m
CONFIG_DVB_TS2020=m
CONFIG_DVB_DS3000=m
CONFIG_DVB_MB86A16=m
CONFIG_DVB_TDA10071=m
#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_DRXD=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m
CONFIG_DVB_TDA10048=m
CONFIG_DVB_AF9013=m
CONFIG_DVB_EC100=m
CONFIG_DVB_STV0367=m
CONFIG_DVB_CXD2820R=m
CONFIG_DVB_CXD2841ER=m
CONFIG_DVB_RTL2830=m
CONFIG_DVB_RTL2832=m
CONFIG_DVB_SI2168=m
# CONFIG_DVB_AS102_FE is not set
CONFIG_DVB_GP8PSK_FE=m
#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_TDA10023=m
CONFIG_DVB_STV0297=m
#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m
CONFIG_DVB_LGDT3305=m
CONFIG_DVB_LGDT3306A=m
CONFIG_DVB_LG2160=m
CONFIG_DVB_S5H1409=m
CONFIG_DVB_AU8522=m
CONFIG_DVB_AU8522_DTV=m
CONFIG_DVB_AU8522_V4L=m
CONFIG_DVB_S5H1411=m
#
# ISDB-T (terrestrial) frontends
#
CONFIG_DVB_S921=m
CONFIG_DVB_DIB8000=m
CONFIG_DVB_MB86A20S=m
#
# ISDB-S (satellite) & ISDB-T (terrestrial) frontends
#
CONFIG_DVB_TC90522=m
#
# Digital terrestrial only tuners/PLL
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TUNER_DIB0070=m
CONFIG_DVB_TUNER_DIB0090=m
#
# SEC control devices for DVB-S
#
CONFIG_DVB_DRX39XYJ=m
CONFIG_DVB_LNBP21=m
CONFIG_DVB_LNBP22=m
CONFIG_DVB_ISL6405=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_ISL6423=m
CONFIG_DVB_A8293=m
CONFIG_DVB_LGS8GXX=m
CONFIG_DVB_ATBM8830=m
CONFIG_DVB_TDA665x=m
CONFIG_DVB_IX2505V=m
CONFIG_DVB_M88RS2000=m
CONFIG_DVB_AF9033=m
#
# Tools to develop new frontends
#
# CONFIG_DVB_DUMMY_FE is not set
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_INTEL_GTT=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=64
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=m
CONFIG_DRM_MIPI_DSI=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
CONFIG_DRM_TTM=m
#
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
CONFIG_DRM_I2C_NXP_TDA998X=m
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_AMDGPU is not set
#
# ACP (Audio CoProcessor) Configuration
#
# CONFIG_DRM_NOUVEAU is not set
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_ALPHA_SUPPORT is not set
CONFIG_DRM_I915_CAPTURE_ERROR=y
CONFIG_DRM_I915_COMPRESS_ERROR=y
CONFIG_DRM_I915_USERPTR=y
# CONFIG_DRM_I915_GVT is not set
#
# drm/i915 Debugging
#
# CONFIG_DRM_I915_WERROR is not set
# CONFIG_DRM_I915_DEBUG is not set
# CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set
# CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set
# CONFIG_DRM_I915_SELFTEST is not set
# CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS is not set
# CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set
# CONFIG_DRM_VGEM is not set
CONFIG_DRM_VMWGFX=m
CONFIG_DRM_VMWGFX_FBCON=y
CONFIG_DRM_GMA500=m
CONFIG_DRM_GMA600=y
CONFIG_DRM_GMA3600=y
CONFIG_DRM_UDL=m
CONFIG_DRM_AST=m
CONFIG_DRM_MGAG200=m
CONFIG_DRM_CIRRUS_QEMU=m
CONFIG_DRM_QXL=m
# CONFIG_DRM_BOCHS is not set
# CONFIG_DRM_VIRTIO_GPU is not set
CONFIG_DRM_PANEL=y
#
# Display Panels
#
CONFIG_DRM_BRIDGE=y
CONFIG_DRM_PANEL_BRIDGE=y
#
# Display Interface Bridges
#
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
# CONFIG_DRM_HISI_HIBMC is not set
# CONFIG_DRM_TINYDRM is not set
# CONFIG_DRM_LEGACY is not set
# CONFIG_DRM_LIB_RANDOM is not set
#
# Frame buffer Devices
#
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_SM501 is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_XEN_FBDEV_FRONTEND is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
CONFIG_FB_HYPERV=m
# CONFIG_FB_SIMPLE is not set
# CONFIG_FB_SM712 is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_L4F00242T03 is not set
# CONFIG_LCD_LMS283GF05 is not set
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_ILI922X is not set
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
CONFIG_LCD_PLATFORM=m
# CONFIG_LCD_S6E63M0 is not set
# CONFIG_LCD_LD9040 is not set
# CONFIG_LCD_AMS369FG06 is not set
# CONFIG_LCD_LMS501KF03 is not set
# CONFIG_LCD_HX8357 is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_PWM is not set
CONFIG_BACKLIGHT_APPLE=m
# CONFIG_BACKLIGHT_PM8941_WLED is not set
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630A is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_GPIO is not set
# CONFIG_BACKLIGHT_LV5207LP is not set
# CONFIG_BACKLIGHT_BD6107 is not set
# CONFIG_BACKLIGHT_ARCXCNN is not set
# CONFIG_VGASTATE is not set
CONFIG_HDMI=y
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
# CONFIG_VGACON_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_SEQ_DEVICE=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_JACK=y
CONFIG_SND_JACK_INPUT_DEV=y
CONFIG_SND_OSSEMUL=y
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
CONFIG_SND_PCM_TIMER=y
CONFIG_SND_HRTIMER=m
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_MAX_CARDS=32
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_PROC_FS=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_SEQUENCER_OSS=m
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_SND_SEQ_MIDI_EVENT=m
CONFIG_SND_SEQ_MIDI_EMUL=m
CONFIG_SND_SEQ_VIRMIDI=m
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_OPL3_LIB_SEQ=m
# CONFIG_SND_OPL4_LIB_SEQ is not set
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCSP=m
CONFIG_SND_DUMMY=m
CONFIG_SND_ALOOP=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=5
CONFIG_SND_PCI=y
CONFIG_SND_AD1889=m
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
CONFIG_SND_ALI5451=m
CONFIG_SND_ASIHPI=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_OXYGEN_LIB=m
CONFIG_SND_OXYGEN=m
# CONFIG_SND_CS4281 is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CTXFI=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_INDIGOIOX=m
CONFIG_SND_INDIGODJX=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1_SEQ=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
CONFIG_SND_ES1968=m
CONFIG_SND_ES1968_INPUT=y
CONFIG_SND_ES1968_RADIO=y
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_LOLA=m
CONFIG_SND_LX6464ES=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MAESTRO3_INPUT=y
CONFIG_SND_MIXART=m
# CONFIG_SND_NM256 is not set
CONFIG_SND_PCXHR=m
# CONFIG_SND_RIPTIDE is not set
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
# CONFIG_SND_SONICVIBES is not set
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
# CONFIG_SND_YMFPCI is not set
#
# HD-Audio
#
CONFIG_SND_HDA=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=0
# CONFIG_SND_HDA_PATCH_LOADER is not set
CONFIG_SND_HDA_CODEC_REALTEK=m
CONFIG_SND_HDA_CODEC_ANALOG=m
CONFIG_SND_HDA_CODEC_SIGMATEL=m
CONFIG_SND_HDA_CODEC_VIA=m
CONFIG_SND_HDA_CODEC_HDMI=m
CONFIG_SND_HDA_CODEC_CIRRUS=m
CONFIG_SND_HDA_CODEC_CONEXANT=m
CONFIG_SND_HDA_CODEC_CA0110=m
CONFIG_SND_HDA_CODEC_CA0132=m
CONFIG_SND_HDA_CODEC_CA0132_DSP=y
CONFIG_SND_HDA_CODEC_CMEDIA=m
CONFIG_SND_HDA_CODEC_SI3054=m
CONFIG_SND_HDA_GENERIC=m
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDA_CORE=m
CONFIG_SND_HDA_DSP_LOADER=y
CONFIG_SND_HDA_I915=y
CONFIG_SND_HDA_PREALLOC_SIZE=512
CONFIG_SND_SPI=y
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_UA101=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
CONFIG_SND_USB_US122L=m
CONFIG_SND_USB_6FIRE=m
# CONFIG_SND_USB_HIFACE is not set
# CONFIG_SND_BCD2000 is not set
# CONFIG_SND_USB_POD is not set
# CONFIG_SND_USB_PODHD is not set
# CONFIG_SND_USB_TONEPORT is not set
# CONFIG_SND_USB_VARIAX is not set
CONFIG_SND_FIREWIRE=y
CONFIG_SND_FIREWIRE_LIB=m
# CONFIG_SND_DICE is not set
# CONFIG_SND_OXFW is not set
CONFIG_SND_ISIGHT=m
# CONFIG_SND_FIREWORKS is not set
# CONFIG_SND_BEBOB is not set
# CONFIG_SND_FIREWIRE_DIGI00X is not set
# CONFIG_SND_FIREWIRE_TASCAM is not set
# CONFIG_SND_FIREWIRE_MOTU is not set
# CONFIG_SND_FIREFACE is not set
# CONFIG_SND_SOC is not set
CONFIG_SND_X86=y
# CONFIG_HDMI_LPE_AUDIO is not set
CONFIG_SND_SYNTH_EMUX=m
CONFIG_AC97_BUS=m
#
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=m
CONFIG_HID_GENERIC=y
#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACCUTOUCH is not set
CONFIG_HID_ACRUX=m
# CONFIG_HID_ACRUX_FF is not set
CONFIG_HID_APPLE=y
CONFIG_HID_APPLEIR=m
# CONFIG_HID_ASUS is not set
CONFIG_HID_AUREAL=m
CONFIG_HID_BELKIN=y
# CONFIG_HID_BETOP_FF is not set
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
# CONFIG_HID_CORSAIR is not set
CONFIG_HID_PRODIKEYS=m
# CONFIG_HID_CMEDIA is not set
# CONFIG_HID_CP2112 is not set
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=m
# CONFIG_DRAGONRISE_FF is not set
# CONFIG_HID_EMS_FF is not set
CONFIG_HID_ELECOM=m
# CONFIG_HID_ELO is not set
CONFIG_HID_EZKEY=y
# CONFIG_HID_GEMBIRD is not set
# CONFIG_HID_GFRM is not set
CONFIG_HID_HOLTEK=m
# CONFIG_HOLTEK_FF is not set
# CONFIG_HID_GT683R is not set
CONFIG_HID_KEYTOUCH=m
CONFIG_HID_KYE=m
CONFIG_HID_UCLOGIC=m
CONFIG_HID_WALTOP=m
CONFIG_HID_GYRATION=m
CONFIG_HID_ICADE=m
CONFIG_HID_TWINHAN=m
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LCPOWER=m
CONFIG_HID_LED=m
# CONFIG_HID_LENOVO is not set
CONFIG_HID_LOGITECH=y
CONFIG_HID_LOGITECH_DJ=m
CONFIG_HID_LOGITECH_HIDPP=m
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set
CONFIG_HID_MAGICMOUSE=y
# CONFIG_HID_MAYFLASH is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_MULTITOUCH=m
# CONFIG_HID_NTI is not set
CONFIG_HID_NTRIG=y
CONFIG_HID_ORTEK=m
CONFIG_HID_PANTHERLORD=m
# CONFIG_PANTHERLORD_FF is not set
# CONFIG_HID_PENMOUNT is not set
CONFIG_HID_PETALYNX=m
CONFIG_HID_PICOLCD=m
CONFIG_HID_PICOLCD_FB=y
CONFIG_HID_PICOLCD_BACKLIGHT=y
CONFIG_HID_PICOLCD_LCD=y
CONFIG_HID_PICOLCD_LEDS=y
CONFIG_HID_PICOLCD_CIR=y
CONFIG_HID_PLANTRONICS=y
CONFIG_HID_PRIMAX=m
CONFIG_HID_ROCCAT=m
CONFIG_HID_SAITEK=m
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
# CONFIG_SONY_FF is not set
CONFIG_HID_SPEEDLINK=m
CONFIG_HID_STEELSERIES=m
CONFIG_HID_SUNPLUS=m
# CONFIG_HID_RMI is not set
CONFIG_HID_GREENASIA=m
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_HYPERV_MOUSE=m
CONFIG_HID_SMARTJOYPLUS=m
# CONFIG_SMARTJOYPLUS_FF is not set
CONFIG_HID_TIVO=m
CONFIG_HID_TOPSEED=m
CONFIG_HID_THINGM=m
CONFIG_HID_THRUSTMASTER=m
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_HID_UDRAW_PS3 is not set
CONFIG_HID_WACOM=m
CONFIG_HID_WIIMOTE=m
# CONFIG_HID_XINMO is not set
CONFIG_HID_ZEROPLUS=m
# CONFIG_ZEROPLUS_FF is not set
CONFIG_HID_ZYDACRON=m
# CONFIG_HID_SENSOR_HUB is not set
# CONFIG_HID_ALPS is not set
#
# USB HID support
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y
#
# I2C HID support
#
CONFIG_I2C_HID=m
#
# Intel ISH HID support
#
# CONFIG_INTEL_ISH_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_PCI=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_LEDS_TRIGGER_USBPORT is not set
CONFIG_USB_MON=y
CONFIG_USB_WUSB=m
CONFIG_USB_WUSB_CBAF=m
# CONFIG_USB_WUSB_CBAF_DEBUG is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
# CONFIG_USB_MAX3421_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PCI=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_U132_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
CONFIG_USB_HWA_HCD=m
# CONFIG_USB_HCD_BCMA is not set
# CONFIG_USB_HCD_SSB is not set
# CONFIG_USB_HCD_TEST_MODE is not set
#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_WDM=m
CONFIG_USB_TMC=m
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_REALTEK=m
CONFIG_REALTEK_AUTOPM=y
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m
CONFIG_USB_UAS=m
#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m
# CONFIG_USBIP_CORE is not set
# CONFIG_USB_MUSB_HDRC is not set
CONFIG_USB_DWC3=y
# CONFIG_USB_DWC3_HOST is not set
CONFIG_USB_DWC3_GADGET=y
# CONFIG_USB_DWC3_DUAL_ROLE is not set
#
# Platform Glue Driver Support
#
CONFIG_USB_DWC3_PCI=y
# CONFIG_USB_DWC2 is not set
# CONFIG_USB_CHIPIDEA is not set
# CONFIG_USB_ISP1760 is not set
#
# USB port drivers
#
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_SIMPLE is not set
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP210X=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
# CONFIG_USB_SERIAL_F81232 is not set
# CONFIG_USB_SERIAL_F8153X is not set
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
# CONFIG_USB_SERIAL_METRO is not set
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7715_PARPORT=y
CONFIG_USB_SERIAL_MOS7840=m
# CONFIG_USB_SERIAL_MXUPORT is not set
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_OTI6858=m
CONFIG_USB_SERIAL_QCAUX=m
CONFIG_USB_SERIAL_QUALCOMM=m
CONFIG_USB_SERIAL_SPCP8X5=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_SYMBOL=m
# CONFIG_USB_SERIAL_TI is not set
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_WWAN=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_SERIAL_OPTICON=m
CONFIG_USB_SERIAL_XSENS_MT=m
# CONFIG_USB_SERIAL_WISHBONE is not set
CONFIG_USB_SERIAL_SSU100=m
CONFIG_USB_SERIAL_QT2=m
# CONFIG_USB_SERIAL_UPD78F0730 is not set
CONFIG_USB_SERIAL_DEBUG=m
#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_SEVSEG=m
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
# CONFIG_USB_TRANCEVIBRATOR is not set
CONFIG_USB_IOWARRIOR=m
# CONFIG_USB_TEST is not set
# CONFIG_USB_EHSET_TEST_FIXTURE is not set
CONFIG_USB_ISIGHTFW=m
# CONFIG_USB_YUREX is not set
CONFIG_USB_EZUSB_FX2=m
# CONFIG_USB_HUB_USB251XB is not set
CONFIG_USB_HSIC_USB3503=m
# CONFIG_USB_HSIC_USB4604 is not set
# CONFIG_USB_LINK_LAYER_TEST is not set
# CONFIG_USB_CHAOSKEY is not set
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m
#
# USB Physical Layer drivers
#
CONFIG_USB_PHY=y
CONFIG_NOP_USB_XCEIV=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
#
# USB Peripheral Controller
#
# CONFIG_USB_FOTG210_UDC is not set
# CONFIG_USB_GR_UDC is not set
# CONFIG_USB_R8A66597 is not set
# CONFIG_USB_PXA27X is not set
# CONFIG_USB_MV_UDC is not set
# CONFIG_USB_MV_U3D is not set
# CONFIG_USB_M66592 is not set
# CONFIG_USB_BDC_UDC is not set
# CONFIG_USB_AMD5536UDC is not set
# CONFIG_USB_NET2272 is not set
# CONFIG_USB_NET2280 is not set
# CONFIG_USB_GOKU is not set
# CONFIG_USB_EG20T is not set
# CONFIG_USB_DUMMY_HCD is not set
CONFIG_USB_LIBCOMPOSITE=m
CONFIG_USB_F_MASS_STORAGE=m
# CONFIG_USB_CONFIGFS is not set
# CONFIG_USB_ZERO is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_G_NCM is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FUNCTIONFS is not set
CONFIG_USB_MASS_STORAGE=m
# CONFIG_USB_GADGET_TARGET is not set
# CONFIG_USB_G_SERIAL is not set
# CONFIG_USB_MIDI_GADGET is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
# CONFIG_USB_G_ACM_MS is not set
# CONFIG_USB_G_MULTI is not set
# CONFIG_USB_G_HID is not set
# CONFIG_USB_G_DBGP is not set
# CONFIG_USB_G_WEBCAM is not set
#
# USB Power Delivery and Type-C drivers
#
# CONFIG_TYPEC_UCSI is not set
# CONFIG_USB_LED_TRIG is not set
# CONFIG_USB_ULPI_BUS is not set
CONFIG_UWB=m
CONFIG_UWB_HWA=m
CONFIG_UWB_WHCI=m
CONFIG_UWB_I1480U=m
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_SDIO_UART=m
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=y
CONFIG_MMC_SDHCI_ACPI=m
CONFIG_MMC_SDHCI_PLTFM=m
# CONFIG_MMC_WBSD is not set
CONFIG_MMC_TIFM_SD=m
# CONFIG_MMC_SPI is not set
CONFIG_MMC_CB710=m
CONFIG_MMC_VIA_SDMMC=m
CONFIG_MMC_VUB300=m
CONFIG_MMC_USHC=m
# CONFIG_MMC_USDHI6ROL0 is not set
CONFIG_MMC_REALTEK_PCI=m
# CONFIG_MMC_TOSHIBA_PCI is not set
# CONFIG_MMC_MTK is not set
# CONFIG_MMC_SDHCI_XENON is not set
CONFIG_MEMSTICK=m
# CONFIG_MEMSTICK_DEBUG is not set
#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m
# CONFIG_MS_BLOCK is not set
#
# MemoryStick Host Controller Drivers
#
CONFIG_MEMSTICK_TIFM_MS=m
CONFIG_MEMSTICK_JMICRON_38X=m
CONFIG_MEMSTICK_R592=m
CONFIG_MEMSTICK_REALTEK_PCI=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
# CONFIG_LEDS_CLASS_FLASH is not set
# CONFIG_LEDS_BRIGHTNESS_HW_CHANGED is not set
#
# LED drivers
#
CONFIG_LEDS_LM3530=m
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
CONFIG_LEDS_LP3944=m
# CONFIG_LEDS_LP3952 is not set
CONFIG_LEDS_LP55XX_COMMON=m
CONFIG_LEDS_LP5521=m
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_LP5562=m
# CONFIG_LEDS_LP8501 is not set
# CONFIG_LEDS_LP8860 is not set
CONFIG_LEDS_CLEVO_MAIL=m
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA963X is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_PWM is not set
# CONFIG_LEDS_BD2802 is not set
CONFIG_LEDS_INTEL_SS4200=m
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_TLC591XX is not set
# CONFIG_LEDS_LM355x is not set
#
# LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)
#
CONFIG_LEDS_BLINKM=m
# CONFIG_LEDS_MLXCPLD is not set
# CONFIG_LEDS_USER is not set
# CONFIG_LEDS_NIC78BX is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
# CONFIG_LEDS_TRIGGER_DISK is not set
# CONFIG_LEDS_TRIGGER_MTD is not set
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
# CONFIG_LEDS_TRIGGER_CPU is not set
# CONFIG_LEDS_TRIGGER_GPIO is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_LEDS_TRIGGER_TRANSIENT=m
CONFIG_LEDS_TRIGGER_CAMERA=m
# CONFIG_LEDS_TRIGGER_PANIC is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=m
# CONFIG_EDAC_GHES is not set
CONFIG_EDAC_AMD64=m
# CONFIG_EDAC_AMD64_ERROR_INJECTION is not set
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82975X=m
CONFIG_EDAC_I3000=m
CONFIG_EDAC_I3200=m
# CONFIG_EDAC_IE31200 is not set
CONFIG_EDAC_X38=m
CONFIG_EDAC_I5400=m
CONFIG_EDAC_I7CORE=m
CONFIG_EDAC_I5000=m
CONFIG_EDAC_I5100=m
CONFIG_EDAC_I7300=m
CONFIG_EDAC_SBRIDGE=m
# CONFIG_EDAC_SKX is not set
# CONFIG_EDAC_PND2 is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_SYSTOHC is not set
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_ABB5ZES3 is not set
# CONFIG_RTC_DRV_ABX80X is not set
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1307_HWMON=y
# CONFIG_RTC_DRV_DS1307_CENTURY is not set
CONFIG_RTC_DRV_DS1374=m
# CONFIG_RTC_DRV_DS1374_WDT is not set
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_ISL12022=m
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8523=m
# CONFIG_RTC_DRV_PCF85063 is not set
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
CONFIG_RTC_DRV_M41T80_WDT=y
CONFIG_RTC_DRV_BQ32K=m
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=m
# CONFIG_RTC_DRV_RX8010 is not set
CONFIG_RTC_DRV_RX8581=m
CONFIG_RTC_DRV_RX8025=m
CONFIG_RTC_DRV_EM3027=m
# CONFIG_RTC_DRV_RV8803 is not set
#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1302 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1343 is not set
# CONFIG_RTC_DRV_DS1347 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6916 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RX4581 is not set
# CONFIG_RTC_DRV_RX6110 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_MCP795 is not set
CONFIG_RTC_I2C_AND_SPI=y
#
# SPI and I2C RTC drivers
#
CONFIG_RTC_DRV_DS3232=m
# CONFIG_RTC_DRV_PCF2127 is not set
CONFIG_RTC_DRV_RV3029C2=m
CONFIG_RTC_DRV_RV3029_HWMON=y
#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1286=m
CONFIG_RTC_DRV_DS1511=m
CONFIG_RTC_DRV_DS1553=m
# CONFIG_RTC_DRV_DS1685_FAMILY is not set
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_DS2404=m
CONFIG_RTC_DRV_STK17TA8=m
# CONFIG_RTC_DRV_M48T86 is not set
CONFIG_RTC_DRV_M48T35=m
CONFIG_RTC_DRV_M48T59=m
CONFIG_RTC_DRV_MSM6242=m
CONFIG_RTC_DRV_BQ4802=m
CONFIG_RTC_DRV_RP5C01=m
CONFIG_RTC_DRV_V3020=m
#
# on-CPU RTC drivers
#
#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set
#
# DMA Devices
#
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_ACPI=y
# CONFIG_INTEL_IDMA64 is not set
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_QCOM_HIDMA_MGMT is not set
# CONFIG_QCOM_HIDMA is not set
CONFIG_DW_DMAC_CORE=y
CONFIG_DW_DMAC=m
CONFIG_DW_DMAC_PCI=y
CONFIG_HSU_DMA=y
#
# DMA Clients
#
CONFIG_ASYNC_TX_DMA=y
CONFIG_DMATEST=m
CONFIG_DMA_ENGINE_RAID=y
#
# DMABUF options
#
CONFIG_SYNC_FILE=y
CONFIG_SW_SYNC=y
CONFIG_AUXDISPLAY=y
# CONFIG_HD44780 is not set
CONFIG_KS0108=m
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
CONFIG_CFAG12864B=m
CONFIG_CFAG12864B_RATE=20
# CONFIG_IMG_ASCII_LCD is not set
# CONFIG_PANEL is not set
CONFIG_UIO=m
CONFIG_UIO_CIF=m
CONFIG_UIO_PDRV_GENIRQ=m
# CONFIG_UIO_DMEM_GENIRQ is not set
CONFIG_UIO_AEC=m
CONFIG_UIO_SERCOS3=m
CONFIG_UIO_PCI_GENERIC=m
# CONFIG_UIO_NETX is not set
# CONFIG_UIO_PRUSS is not set
# CONFIG_UIO_MF624 is not set
# CONFIG_UIO_HV_GENERIC is not set
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_VFIO_PCI=m
# CONFIG_VFIO_PCI_VGA is not set
CONFIG_VFIO_PCI_MMAP=y
CONFIG_VFIO_PCI_INTX=y
CONFIG_VFIO_PCI_IGD=y
# CONFIG_VFIO_MDEV is not set
CONFIG_IRQ_BYPASS_MANAGER=m
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y
#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_VIRTIO_BALLOON=y
# CONFIG_VIRTIO_INPUT is not set
# CONFIG_VIRTIO_MMIO is not set
#
# Microsoft Hyper-V guest support
#
CONFIG_HYPERV=m
CONFIG_HYPERV_TSCPAGE=y
CONFIG_HYPERV_UTILS=m
CONFIG_HYPERV_BALLOON=m
#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
# CONFIG_XEN_SELFBALLOONING is not set
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=m
CONFIG_XEN_PCIDEV_BACKEND=m
# CONFIG_XEN_SCSI_BACKEND is not set
CONFIG_XEN_PRIVCMD=m
CONFIG_XEN_ACPI_PROCESSOR=m
# CONFIG_XEN_MCE_LOG is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y
CONFIG_XEN_ACPI=y
CONFIG_XEN_SYMS=y
CONFIG_XEN_HAVE_VPMU=y
CONFIG_STAGING=y
# CONFIG_PRISM2_USB is not set
# CONFIG_COMEDI is not set
# CONFIG_RTL8192U is not set
CONFIG_RTLLIB=m
CONFIG_RTLLIB_CRYPTO_CCMP=m
CONFIG_RTLLIB_CRYPTO_TKIP=m
CONFIG_RTLLIB_CRYPTO_WEP=m
CONFIG_RTL8192E=m
# CONFIG_RTL8723BS is not set
CONFIG_R8712U=m
# CONFIG_R8188EU is not set
# CONFIG_RTS5208 is not set
# CONFIG_VT6655 is not set
# CONFIG_VT6656 is not set
# CONFIG_FB_SM750 is not set
# CONFIG_FB_XGI is not set
#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_STAGING_MEDIA is not set
#
# Android
#
# CONFIG_LTE_GDM724X is not set
CONFIG_FIREWIRE_SERIAL=m
CONFIG_FWTTY_MAX_TOTAL_PORTS=64
CONFIG_FWTTY_MAX_CARD_PORTS=32
# CONFIG_LNET is not set
# CONFIG_DGNC is not set
# CONFIG_GS_FPGABOOT is not set
# CONFIG_CRYPTO_SKEIN is not set
# CONFIG_UNISYSSPAR is not set
# CONFIG_FB_TFT is not set
# CONFIG_WILC1000_SDIO is not set
# CONFIG_WILC1000_SPI is not set
# CONFIG_MOST is not set
# CONFIG_KS7010 is not set
# CONFIG_GREYBUS is not set
#
# USB Power Delivery and Type-C drivers
#
# CONFIG_TYPEC_TCPM is not set
CONFIG_X86_PLATFORM_DEVICES=y
CONFIG_ACER_WMI=m
CONFIG_ACERHDF=m
# CONFIG_ALIENWARE_WMI is not set
CONFIG_ASUS_LAPTOP=m
# CONFIG_DELL_LAPTOP is not set
# CONFIG_DELL_WMI is not set
CONFIG_DELL_WMI_AIO=m
# CONFIG_DELL_WMI_LED is not set
# CONFIG_DELL_SMO8800 is not set
# CONFIG_DELL_RBTN is not set
CONFIG_FUJITSU_LAPTOP=m
CONFIG_FUJITSU_TABLET=m
CONFIG_AMILO_RFKILL=m
CONFIG_HP_ACCEL=m
# CONFIG_HP_WIRELESS is not set
CONFIG_HP_WMI=m
CONFIG_MSI_LAPTOP=m
CONFIG_PANASONIC_LAPTOP=m
CONFIG_COMPAL_LAPTOP=m
CONFIG_SONY_LAPTOP=m
CONFIG_SONYPI_COMPAT=y
CONFIG_IDEAPAD_LAPTOP=m
# CONFIG_SURFACE3_WMI is not set
CONFIG_THINKPAD_ACPI=m
CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
CONFIG_THINKPAD_ACPI_VIDEO=y
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
CONFIG_SENSORS_HDAPS=m
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=m
CONFIG_ASUS_WMI=m
CONFIG_ASUS_NB_WMI=m
CONFIG_EEEPC_WMI=m
# CONFIG_ASUS_WIRELESS is not set
CONFIG_ACPI_WMI=m
CONFIG_WMI_BMOF=m
CONFIG_MSI_WMI=m
# CONFIG_PEAQ_WMI is not set
CONFIG_TOPSTAR_LAPTOP=m
CONFIG_TOSHIBA_BT_RFKILL=m
# CONFIG_TOSHIBA_HAPS is not set
# CONFIG_TOSHIBA_WMI is not set
CONFIG_ACPI_CMPC=m
# CONFIG_INTEL_CHT_INT33FE is not set
# CONFIG_INTEL_INT0002_VGPIO is not set
# CONFIG_INTEL_HID_EVENT is not set
# CONFIG_INTEL_VBTN is not set
CONFIG_INTEL_IPS=m
# CONFIG_INTEL_PMC_CORE is not set
# CONFIG_IBM_RTL is not set
CONFIG_SAMSUNG_LAPTOP=m
CONFIG_MXM_WMI=m
CONFIG_INTEL_OAKTRAIL=m
CONFIG_SAMSUNG_Q10=m
CONFIG_APPLE_GMUX=m
# CONFIG_INTEL_RST is not set
# CONFIG_INTEL_SMARTCONNECT is not set
CONFIG_PVPANIC=y
# CONFIG_INTEL_PMC_IPC is not set
# CONFIG_SURFACE_PRO3_BUTTON is not set
# CONFIG_INTEL_PUNIT_IPC is not set
# CONFIG_MLX_PLATFORM is not set
# CONFIG_MLX_CPLD_PLATFORM is not set
# CONFIG_INTEL_TURBO_MAX_3 is not set
CONFIG_PMC_ATOM=y
# CONFIG_CHROME_PLATFORMS is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y
#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_CDCE706 is not set
# CONFIG_COMMON_CLK_CS2000_CP is not set
# CONFIG_COMMON_CLK_NXP is not set
# CONFIG_COMMON_CLK_PWM is not set
# CONFIG_COMMON_CLK_PXA is not set
# CONFIG_COMMON_CLK_PIC32 is not set
# CONFIG_HWSPINLOCK is not set
#
# Clock Source drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_ATMEL_PIT is not set
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
CONFIG_MAILBOX=y
CONFIG_PCC=y
# CONFIG_ALTERA_MBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
#
# Generic IOMMU Pagetable Support
#
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_V2=m
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_SVM is not set
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
CONFIG_IRQ_REMAP=y
#
# Remoteproc drivers
#
# CONFIG_REMOTEPROC is not set
#
# Rpmsg drivers
#
# CONFIG_RPMSG_QCOM_GLINK_RPM is not set
#
# SOC (System On Chip) specific Drivers
#
#
# Broadcom SoC drivers
#
#
# i.MX SoC drivers
#
# CONFIG_SUNXI_SRAM is not set
# CONFIG_SOC_TI is not set
# CONFIG_SOC_ZTE is not set
CONFIG_PM_DEVFREQ=y
#
# DEVFREQ Governors
#
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=m
# CONFIG_DEVFREQ_GOV_PERFORMANCE is not set
# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
# CONFIG_DEVFREQ_GOV_USERSPACE is not set
# CONFIG_DEVFREQ_GOV_PASSIVE is not set
#
# DEVFREQ Drivers
#
# CONFIG_PM_DEVFREQ_EVENT is not set
CONFIG_EXTCON=y
#
# Extcon Device Drivers
#
# CONFIG_EXTCON_GPIO is not set
# CONFIG_EXTCON_INTEL_INT3496 is not set
# CONFIG_EXTCON_MAX3355 is not set
# CONFIG_EXTCON_RT8973A is not set
# CONFIG_EXTCON_SM5502 is not set
# CONFIG_EXTCON_USB_GPIO is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
CONFIG_NTB=m
# CONFIG_NTB_AMD is not set
# CONFIG_NTB_INTEL is not set
# CONFIG_NTB_PINGPONG is not set
# CONFIG_NTB_TOOL is not set
# CONFIG_NTB_PERF is not set
# CONFIG_NTB_TRANSPORT is not set
# CONFIG_VME_BUS is not set
CONFIG_PWM=y
CONFIG_PWM_SYSFS=y
# CONFIG_PWM_LPSS_PCI is not set
# CONFIG_PWM_LPSS_PLATFORM is not set
# CONFIG_PWM_PCA9685 is not set
CONFIG_ARM_GIC_MAX_NR=1
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set
#
# PHY Subsystem
#
CONFIG_GENERIC_PHY=y
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
CONFIG_POWERCAP=y
CONFIG_INTEL_RAPL=m
# CONFIG_MCB is not set
#
# Performance monitor support
#
CONFIG_RAS=y
# CONFIG_RAS_CEC is not set
# CONFIG_THUNDERBOLT is not set
#
# Android
#
# CONFIG_ANDROID is not set
CONFIG_LIBNVDIMM=m
CONFIG_BLK_DEV_PMEM=m
CONFIG_ND_BLK=m
CONFIG_ND_CLAIM=y
CONFIG_ND_BTT=m
CONFIG_BTT=y
CONFIG_ND_PFN=m
CONFIG_NVDIMM_PFN=y
CONFIG_NVDIMM_DAX=y
CONFIG_DAX=y
CONFIG_DEV_DAX=m
CONFIG_DEV_DAX_PMEM=m
CONFIG_NVMEM=m
# CONFIG_STM is not set
# CONFIG_INTEL_TH is not set
#
# FPGA Configuration Support
#
# CONFIG_FPGA is not set
#
# FSI support
#
# CONFIG_FSI is not set
# CONFIG_MULTIPLEXER is not set
#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
CONFIG_DMI_SYSFS=y
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m
# CONFIG_FW_CFG_SYSFS is not set
# CONFIG_GOOGLE_FIRMWARE is not set
#
# EFI (Extensible Firmware Interface) Support
#
CONFIG_EFI_VARS=y
CONFIG_EFI_ESRT=y
CONFIG_EFI_VARS_PSTORE=y
CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y
CONFIG_EFI_RUNTIME_MAP=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_RUNTIME_WRAPPERS=y
# CONFIG_EFI_BOOTLOADER_CONTROL is not set
# CONFIG_EFI_CAPSULE_LOADER is not set
# CONFIG_EFI_TEST is not set
# CONFIG_APPLE_PROPERTIES is not set
CONFIG_UEFI_CPER=y
# CONFIG_EFI_DEV_PATH_PARSER is not set
#
# Tegra firmware driver
#
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_FS_IOMAP=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_DLM=y
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_FS_O2CB=m
CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m
CONFIG_OCFS2_FS_STATS=y
CONFIG_OCFS2_DEBUG_MASKLOG=y
# CONFIG_OCFS2_DEBUG_FS is not set
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
# CONFIG_NILFS2_FS is not set
CONFIG_F2FS_FS=m
CONFIG_F2FS_STAT_FS=y
CONFIG_F2FS_FS_XATTR=y
CONFIG_F2FS_FS_POSIX_ACL=y
# CONFIG_F2FS_FS_SECURITY is not set
# CONFIG_F2FS_CHECK_FS is not set
# CONFIG_F2FS_FS_ENCRYPTION is not set
# CONFIG_F2FS_IO_TRACE is not set
# CONFIG_F2FS_FAULT_INJECTION is not set
CONFIG_FS_DAX=y
CONFIG_FS_DAX_PMD=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
# CONFIG_EXPORTFS_BLOCK_OPS is not set
CONFIG_FILE_LOCKING=y
CONFIG_MANDATORY_FILE_LOCKING=y
# CONFIG_FS_ENCRYPTION is not set
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_OVERLAY_FS=m
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_CHILDREN=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ORANGEFS_FS is not set
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_UBIFS_FS is not set
CONFIG_CRAMFS=m
CONFIG_SQUASHFS=m
CONFIG_SQUASHFS_FILE_CACHE=y
# CONFIG_SQUASHFS_FILE_DIRECT is not set
CONFIG_SQUASHFS_DECOMP_SINGLE=y
# CONFIG_SQUASHFS_DECOMP_MULTI is not set
# CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
# CONFIG_SQUASHFS_LZ4 is not set
CONFIG_SQUASHFS_LZO=y
CONFIG_SQUASHFS_XZ=y
# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
# CONFIG_SQUASHFS_EMBEDDED is not set
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
CONFIG_PSTORE_ZLIB_COMPRESS=y
# CONFIG_PSTORE_LZO_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
# CONFIG_PSTORE_FTRACE is not set
CONFIG_PSTORE_RAM=m
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_EXOFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
# CONFIG_NFS_V2 is not set
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=m
# CONFIG_NFS_SWAP is not set
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_PNFS_FILE_LAYOUT=m
CONFIG_PNFS_BLOCK=m
CONFIG_PNFS_FLEXFILE_LAYOUT=m
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
# CONFIG_NFS_V4_1_MIGRATION is not set
CONFIG_NFS_V4_SECURITY_LABEL=y
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFS_DEBUG=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
# CONFIG_NFSD_BLOCKLAYOUT is not set
# CONFIG_NFSD_SCSILAYOUT is not set
# CONFIG_NFSD_FLEXFILELAYOUT is not set
CONFIG_NFSD_V4_SECURITY_LABEL=y
# CONFIG_NFSD_FAULT_INJECTION is not set
CONFIG_GRACE_PERIOD=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_BACKCHANNEL=y
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_SUNRPC_DEBUG=y
# CONFIG_CEPH_FS is not set
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_CIFS_ACL=y
CONFIG_CIFS_DEBUG=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_DEBUG_DUMP_KEYS is not set
CONFIG_CIFS_DFS_UPCALL=y
CONFIG_CIFS_SMB2=y
# CONFIG_CIFS_SMB311 is not set
# CONFIG_CIFS_FSCACHE is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=y
CONFIG_9P_FS_POSIX_ACL=y
# CONFIG_9P_FS_SECURITY is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_MAC_ROMAN=m
CONFIG_NLS_MAC_CELTIC=m
CONFIG_NLS_MAC_CENTEURO=m
CONFIG_NLS_MAC_CROATIAN=m
CONFIG_NLS_MAC_CYRILLIC=m
CONFIG_NLS_MAC_GAELIC=m
CONFIG_NLS_MAC_GREEK=m
CONFIG_NLS_MAC_ICELAND=m
CONFIG_NLS_MAC_INUIT=m
CONFIG_NLS_MAC_ROMANIAN=m
CONFIG_NLS_MAC_TURKISH=m
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_DYNAMIC_DEBUG=y
#
# Compile-time checks and compiler options
#
# CONFIG_DEBUG_INFO is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_STACK_VALIDATION is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_MAGIC_SYSRQ_SERIAL=y
CONFIG_DEBUG_KERNEL=y
#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_PAGE_POISONING is not set
# CONFIG_DEBUG_PAGE_REF is not set
CONFIG_DEBUG_RODATA_TEST=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_MEMORY_NOTIFIER_ERROR_INJECT=m
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_HAVE_ARCH_KASAN=y
# CONFIG_KASAN is not set
CONFIG_ARCH_HAS_KCOV=y
# CONFIG_KCOV is not set
CONFIG_DEBUG_SHIRQ=y
#
# Debug Lockups and Hangs
#
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_WQ_WATCHDOG is not set
CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_ON_OOPS_VALUE=1
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHED_INFO=y
CONFIG_SCHEDSTATS=y
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_TIMEKEEPING is not set
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_LOCK_TORTURE_TEST=m
# CONFIG_WW_MUTEX_SELFTEST is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_PI_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
CONFIG_TORTURE_TEST=m
# CONFIG_RCU_PERF_TEST is not set
CONFIG_RCU_TORTURE_TEST=m
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set
CONFIG_NOTIFIER_ERROR_INJECTION=m
CONFIG_PM_NOTIFIER_ERROR_INJECT=m
# CONFIG_NETDEV_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
CONFIG_SCHED_TRACER=y
# CONFIG_HWLAT_TRACER is not set
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENTS=y
CONFIG_UPROBE_EVENTS=y
CONFIG_BPF_EVENTS=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
CONFIG_TRACING_MAP=y
CONFIG_HIST_TRIGGERS=y
# CONFIG_TRACEPOINT_BENCHMARK is not set
CONFIG_RING_BUFFER_BENCHMARK=m
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_TRACE_EVAL_MAP_FILE is not set
CONFIG_TRACING_EVENTS_GPIO=y
#
# Runtime Testing
#
CONFIG_LKDTM=m
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_TEST_SORT is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_RBTREE_TEST=m
CONFIG_INTERVAL_TREE_TEST=m
CONFIG_PERCPU_TEST=m
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_ASYNC_RAID6_TEST=m
# CONFIG_TEST_HEXDUMP is not set
# CONFIG_TEST_STRING_HELPERS is not set
CONFIG_TEST_KSTRTOX=m
CONFIG_TEST_PRINTF=m
CONFIG_TEST_BITMAP=m
# CONFIG_TEST_UUID is not set
# CONFIG_TEST_RHASHTABLE is not set
# CONFIG_TEST_HASH is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_TEST_LKM=m
CONFIG_TEST_USER_COPY=m
CONFIG_TEST_BPF=m
CONFIG_TEST_FIRMWARE=m
CONFIG_TEST_UDELAY=m
# CONFIG_MEMTEST is not set
CONFIG_TEST_STATIC_KEYS=m
# CONFIG_BUG_ON_DATA_CORRUPTION is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
# CONFIG_ARCH_WANTS_UBSAN_NO_NULL is not set
# CONFIG_UBSAN is not set
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
CONFIG_STRICT_DEVMEM=y
# CONFIG_IO_STRICT_DEVMEM is not set
CONFIG_EARLY_PRINTK_USB=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
# CONFIG_EARLY_PRINTK_EFI is not set
# CONFIG_EARLY_PRINTK_USB_XDBC is not set
# CONFIG_X86_PTDUMP_CORE is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_EFI_PGT_DUMP is not set
# CONFIG_DEBUG_WX is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_TLBFLUSH is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_X86_DECODER_SELFTEST=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_ENTRY is not set
# CONFIG_DEBUG_NMI_SELFTEST is not set
CONFIG_X86_DEBUG_FPU=y
# CONFIG_PUNIT_ATOM_DEBUG is not set
#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_COMPAT=y
CONFIG_PERSISTENT_KEYRINGS=y
CONFIG_BIG_KEYS=y
CONFIG_TRUSTED_KEYS=y
CONFIG_ENCRYPTED_KEYS=y
# CONFIG_KEY_DH_OPERATIONS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_WRITABLE_HOOKS=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_INTEL_TXT=y
CONFIG_LSM_MMAP_MIN_ADDR=65535
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
# CONFIG_HARDENED_USERCOPY is not set
# CONFIG_STATIC_USERMODEHELPER is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_LOADPIN is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
CONFIG_INTEGRITY_TRUSTED_KEYRING=y
CONFIG_INTEGRITY_AUDIT=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_LSM_RULES=y
# CONFIG_IMA_TEMPLATE is not set
CONFIG_IMA_NG_TEMPLATE=y
# CONFIG_IMA_SIG_TEMPLATE is not set
CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
CONFIG_IMA_DEFAULT_HASH_SHA1=y
# CONFIG_IMA_DEFAULT_HASH_SHA256 is not set
CONFIG_IMA_DEFAULT_HASH="sha1"
# CONFIG_IMA_WRITE_POLICY is not set
# CONFIG_IMA_READ_POLICY is not set
CONFIG_IMA_APPRAISE=y
CONFIG_IMA_APPRAISE_BOOTPARAM=y
CONFIG_IMA_TRUSTED_KEYRING=y
# CONFIG_IMA_BLACKLIST_KEYRING is not set
# CONFIG_IMA_LOAD_X509 is not set
CONFIG_EVM=y
CONFIG_EVM_ATTR_FSUUID=y
# CONFIG_EVM_LOAD_X509 is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_KPP2=y
CONFIG_CRYPTO_ACOMP2=y
CONFIG_CRYPTO_RSA=y
# CONFIG_CRYPTO_DH is not set
# CONFIG_CRYPTO_ECDH is not set
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
# CONFIG_CRYPTO_MCRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=m
CONFIG_CRYPTO_SIMD=m
CONFIG_CRYPTO_GLUE_HELPER_X86=m
CONFIG_CRYPTO_ENGINE=m
#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
CONFIG_CRYPTO_SEQIV=y
CONFIG_CRYPTO_ECHAINIV=m
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
# CONFIG_CRYPTO_KEYWRAP is not set
#
# Hash modes
#
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRYPTO_GHASH=m
# CONFIG_CRYPTO_POLY1305 is not set
# CONFIG_CRYPTO_POLY1305_X86_64 is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=m
CONFIG_CRYPTO_SHA256_SSSE3=m
CONFIG_CRYPTO_SHA512_SSSE3=m
# CONFIG_CRYPTO_SHA1_MB is not set
# CONFIG_CRYPTO_SHA256_MB is not set
# CONFIG_CRYPTO_SHA512_MB is not set
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_SHA3 is not set
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_TI is not set
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_BLOWFISH_X86_64=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_CAST6_AVX_X86_64=m
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_DES3_EDE_X86_64 is not set
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
# CONFIG_CRYPTO_CHACHA20 is not set
# CONFIG_CRYPTO_CHACHA20_X86_64 is not set
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_842 is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set
#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_DRBG_HMAC=y
# CONFIG_CRYPTO_DRBG_HASH is not set
# CONFIG_CRYPTO_DRBG_CTR is not set
CONFIG_CRYPTO_DRBG=y
CONFIG_CRYPTO_JITTERENTROPY=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
# CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC is not set
# CONFIG_CRYPTO_DEV_CCP is not set
# CONFIG_CRYPTO_DEV_QAT_DH895xCC is not set
# CONFIG_CRYPTO_DEV_QAT_C3XXX is not set
# CONFIG_CRYPTO_DEV_QAT_C62X is not set
# CONFIG_CRYPTO_DEV_QAT_DH895xCCVF is not set
# CONFIG_CRYPTO_DEV_QAT_C3XXXVF is not set
# CONFIG_CRYPTO_DEV_QAT_C62XVF is not set
# CONFIG_CRYPTO_DEV_NITROX_CNN55XX is not set
# CONFIG_CRYPTO_DEV_CHELSIO is not set
CONFIG_CRYPTO_DEV_VIRTIO=m
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
CONFIG_X509_CERTIFICATE_PARSER=y
# CONFIG_PKCS7_MESSAGE_PARSER is not set
#
# Certificates for signature checking
#
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set
# CONFIG_SYSTEM_BLACKLIST_KEYRING is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_IRQFD=y
CONFIG_HAVE_KVM_IRQ_ROUTING=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_KVM_VFIO=y
CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
CONFIG_KVM_COMPAT=y
CONFIG_HAVE_KVM_IRQ_BYPASS=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_MMU_AUDIT=y
CONFIG_VHOST_NET=m
# CONFIG_VHOST_SCSI is not set
# CONFIG_VHOST_VSOCK is not set
CONFIG_VHOST=m
# CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
# CONFIG_HAVE_ARCH_BITREVERSE is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_CRC8=m
# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_BTREE=y
CONFIG_INTERVAL_TREE=y
CONFIG_RADIX_TREE_MULTIORDER=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
# CONFIG_DMA_NOOP_OPS is not set
# CONFIG_DMA_VIRT_OPS is not set
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_GLOB=y
# CONFIG_GLOB_SELFTEST is not set
CONFIG_NLATTR=y
CONFIG_CLZ_TAB=y
CONFIG_CORDIC=m
# CONFIG_DDR is not set
CONFIG_IRQ_POLL=y
CONFIG_MPILIB=y
CONFIG_SIGNATURE=y
CONFIG_OID_REGISTRY=y
CONFIG_UCS2_STRING=y
CONFIG_FONT_SUPPORT=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_SG_SPLIT is not set
CONFIG_SG_POOL=y
CONFIG_ARCH_HAS_SG_CHAIN=y
CONFIG_ARCH_HAS_PMEM_API=y
CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
CONFIG_ARCH_HAS_MMIO_FLUSH=y
CONFIG_SBITMAP=y
-------------- next part --------------
#!/bin/sh
export_top_env()
{
export suite='ltp'
export testcase='ltp'
export category='functional'
export job_origin='/lkp/lkp/.src-20170713-182338/allot/cyclic:linux-devel:devel-hourly/nhm-white2/ltp.yaml'
export queue='bisect'
export testbox='nhm-white2'
export tbox_group='nhm-white2'
export submit_id='596cbccc0b9a93d8998bd5fd'
export job_file='/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml'
export id='bcf686732c701d15cf5dadb19fcea28e34ef0504'
export model='Nehalem'
export memory='4G'
export nr_cpu=8
export hdd_partitions=
export swap_partitions=
export rootfs_partition=
export netconsole_port=6671
export brand='Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz'
export need_kconfig='CONFIG_BLK_DEV_LOOP'
export commit='3f3bf5920d2df8b0b3df8ec90e21e67316688e95'
export kconfig='x86_64-rhel-7.2'
export compiler='gcc-6'
export rootfs='debian-x86_64-2016-08-31.cgz'
export enqueue_time='2017-07-17 21:34:04 +0800'
export _id='596cbccc0b9a93d8998bd5fd'
export _rt='/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95'
export user='lkp'
export head_commit='e457614996880c0ba13ddf22980b39b56030a491'
export base_commit='6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c'
export branch='linux-devel/devel-hourly-2017071420'
export result_root='/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0'
export LKP_SERVER='inn'
export max_uptime=3600
export initrd='/osimage/debian/debian-x86_64-2016-08-31.cgz'
export bootloader_append='root=/dev/ram0
user=lkp
job=/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml
ARCH=x86_64
kconfig=x86_64-rhel-7.2
branch=linux-devel/devel-hourly-2017071420
commit=3f3bf5920d2df8b0b3df8ec90e21e67316688e95
BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59
max_uptime=3600
RESULT_ROOT=/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0
LKP_SERVER=inn
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
earlyprintk=ttyS0,115200
console=ttyS0,115200
console=tty0
vga=normal
rw'
export lkp_initrd='/lkp/lkp/lkp-x86_64.cgz'
export modules_initrd='/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/modules.cgz'
export bm_initrd='/osimage/deps/debian-x86_64-2016-08-31.cgz/lkp_2017-05-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/rsync-rootfs_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/ltp_2017-07-01.cgz,/osimage/pkg/debian-x86_64-2016-08-31.cgz/ltp-x86_64-10f4a5476_2017-07-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/hw_2016-11-15.cgz'
export site='inn'
export LKP_CGI_PORT=80
export LKP_CIFS_PORT=139
export kernel='/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59'
export dequeue_time='2017-07-17 21:34:38 +0800'
export job_initrd='/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.cgz'
[ -n "$LKP_SRC" ] ||
export LKP_SRC=/lkp/${user:-lkp}/src
}
run_job()
{
echo $$ > $TMP/run-job.pid
. $LKP_SRC/lib/http.sh
. $LKP_SRC/lib/job.sh
. $LKP_SRC/lib/env.sh
export_top_env
run_monitor $LKP_SRC/monitors/wrapper kmsg
run_monitor $LKP_SRC/monitors/wrapper heartbeat
run_monitor $LKP_SRC/monitors/wrapper oom-killer
run_monitor $LKP_SRC/monitors/plain/watchdog
run_monitor $LKP_SRC/monitors/wrapper nfs-hang
run_test test='containers' $LKP_SRC/tests/wrapper ltp
}
extract_stats()
{
$LKP_SRC/stats/wrapper ltp
$LKP_SRC/stats/wrapper kmsg
$LKP_SRC/stats/wrapper time ltp.time
$LKP_SRC/stats/wrapper time
$LKP_SRC/stats/wrapper dmesg
$LKP_SRC/stats/wrapper kmsg
$LKP_SRC/stats/wrapper stderr
$LKP_SRC/stats/wrapper last_state
}
"$@"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.xz
Type: application/octet-stream
Size: 29584 bytes
Desc: not available
URL: <http://lists.linux.it/pipermail/ltp/attachments/20170720/067b8cdc/attachment-0001.obj>
-------------- next part --------------
2017-07-17 21:35:16 ./runltp -f containers
INFO: creating /lkp/benchmarks/ltp/output directory
INFO: creating /lkp/benchmarks/ltp/results directory
Checking for required user/group ids
'nobody' user id and group found.
'bin' user id and group found.
'daemon' user id and group found.
Users group found.
Sys group found.
Required users/groups exist.
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
PRETTY_NAME="Debian GNU/Linux stretch/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Linux nhm-white2 4.12.0-10318-g3f3bf59 #1 SMP Sat Jul 15 01:43:38 CST 2017 x86_64 GNU/Linux
Gnu C
util-linux linux 2.28.1
mount mountinfo, assert, debug)
modutils 23
e2fsprogs 1.43.1
Linux C Library > libc.2.23
Dynamic linker (ldd) 2.23
Procps 3.3.12
Net-tools 2.10-alpha
iproute2 iproute2-ss161212
Kbd 69:
Sh-utils 8.25
Modules Loaded rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver netconsole sr_mod cdrom sd_mod sg snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi intel_powerclamp coretemp ata_generic pata_acpi snd_hda_intel kvm_intel snd_hda_codec dcdbas dell_smm_hwmon firewire_ohci snd_hda_core snd_hwdep firewire_core crc_itu_t ata_piix uas snd_pcm serio_raw pcspkr kvm snd_timer irqbypass i7core_edac usb_storage snd libata crc32c_intel soundcore shpchp ip_tables broadcom bcm_phy_lib
free reports:
total used free shared buff/cache available
Mem: 4033168 165708 2948392 9032 919068 3656908
Swap: 0 0 0
/proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5852.25
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
stepping : 5
microcode : 0x3
cpu MHz : 2926.125
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
bugs :
bogomips : 5850.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
no big block device was specified on commandline.
Tests which require a big block device are disabled.
You can specify it with option -z
COMMAND: /lkp/benchmarks/ltp/bin/ltp-pan -e -S -a 4180 -n 4180 -p -f /tmp/ltp-QKIduxmJCG/alltests -l /lkp/benchmarks/ltp/results/LTP_RUN_ON-2017_07_17-21h_35m_16s.log -C /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.failed -T /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.tconf
LOG File: /lkp/benchmarks/ltp/results/LTP_RUN_ON-2017_07_17-21h_35m_16s.log
FAILED COMMAND File: /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.failed
TCONF COMMAND File: /lkp/benchmarks/ltp/output/LTP_RUN_ON-2017_07_17-21h_35m_16s.tconf
Running tests.......
<<<test_start>>>
tag=pidns01 stime=1500298516
cmdline="pidns01"
contacts=""
analysis=exit
<<<test_output>>>
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns02 stime=1500298516
cmdline="pidns02"
contacts=""
analysis=exit
<<<test_output>>>
Checking session id & group id inside container
Success: Got Group ID = 1 & Session ID = 1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns03 stime=1500298516
cmdline="pidns03"
contacts=""
analysis=exit
<<<test_output>>>
pidns03 1 TPASS : mounting procfs in a new namespace
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns04 stime=1500298516
cmdline="pidns04"
contacts=""
analysis=exit
<<<test_output>>>
PIDNS test is running inside container
pidns04 1 TPASS : Container init : I was not killed !
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns05 stime=1500298516
cmdline="pidns05"
contacts=""
analysis=exit
<<<test_output>>>
pidns05 0 TINFO : 5 Nested Containers are created
pidns05 1 TPASS : The number of containers killed are 2
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns06 stime=1500298517
cmdline="pidns06"
contacts=""
analysis=exit
<<<test_output>>>
pidns06 0 TINFO : Parent: Passing the pid of the process 4326
Container: killing parent pid=4326 failed as expected with ESRCH
Container: killing non-existent pid failed as expected with ESRCH
pidns06 0 TINFO : Parent: Passing the pid of the process 4326
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns10 stime=1500298517
cmdline="pidns10"
contacts=""
analysis=exit
<<<test_output>>>
cinit: kill(-1, sig) failed with -1 / ESRCH as expected
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns12 stime=1500298518
cmdline="pidns12"
contacts=""
analysis=exit
<<<test_output>>>
pidns12 0 TINFO : parent: PID is 4332
pidns12 1 TPASS : cinit: signalling PID (from other namespace) is 0 as expected
pidns12 0 TINFO : parent: PID is 4332
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns13 stime=1500298518
cmdline="pidns13"
contacts=""
analysis=exit
<<<test_output>>>
pidns13 0 TINFO : cinit2: writing some data in pipe
pidns13 0 TINFO : cinit1: setup handler for async I/O on pipe
pidns13 1 TPASS : cinit1: si_fd is 7, si_code is 1
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns16 stime=1500298520
cmdline="pidns16"
contacts=""
analysis=exit
<<<test_output>>>
pidns16 1 TPASS : container init continued successfuly, after handling signal -USR1
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns17 stime=1500298522
cmdline="pidns17"
contacts=""
analysis=exit
<<<test_output>>>
cinit: all children have terminated.
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns20 stime=1500298523
cmdline="pidns20"
contacts=""
analysis=exit
<<<test_output>>>
pidns20 0 TINFO : cinit: blocked SIGUSR1
pidns20 0 TINFO : cinit: unblocking SIGUSR1
pidns20 1 TPASS : cinit: user function is called as expected
pidns20 0 TINFO : parent: signalled SIGUSR1 to container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns30 stime=1500298523
cmdline="pidns30"
contacts=""
analysis=exit
<<<test_output>>>
mq_open succeeded
successfully registered for notification
successfully registered handler for SIGUSR1
signal originator PID = 0
parent is done - cleaning up
pidns30 0 TINFO : successfully created posix mqueue
pidns30 0 TINFO : mq_send succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns31 stime=1500298523
cmdline="pidns31"
contacts=""
analysis=exit
<<<test_output>>>
pidns31 0 TINFO : parent: successfully created posix mqueue
pidns31 0 TINFO : cinit: my father is ready to receive a message
pidns31 0 TINFO : cinit: mq_open succeeded
pidns31 0 TINFO : cinit: mq_send() succeeded
pidns31 0 TINFO : parent: successfully created posix mqueue
pidns31 0 TINFO : parent: successfully created child (pid = 4364)
pidns31 0 TINFO : parent: successfully registered for notification
pidns31 0 TINFO : parent: successfully registered handler for SIGUSR1
pidns31 1 TPASS : father: signal originator PID = 4364
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pidns32 stime=1500298523
cmdline="pidns32"
contacts=""
analysis=exit
<<<test_output>>>
pidns32 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=mqns_01 stime=1500298523
cmdline="mqns_01"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 1 TPASS : child process didn't find mqueue
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_01_clone stime=1500298523
cmdline="mqns_01 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_01 0 TINFO : Checking namespaces isolation from parent to child
posixmq_namespace_01 1 TPASS : child process didn't find mqueue
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_02 stime=1500298523
cmdline="mqns_02"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_02 0 TINFO : Checking namespaces isolation (child to parent)
posixmq_namespace_02 1 TPASS : Parent process can't see the mqueue
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through unshare(2).
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_02_clone stime=1500298523
cmdline="mqns_02 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_02 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_02 0 TINFO : Checking namespaces isolation (child to parent)
posixmq_namespace_02 1 TPASS : Parent process can't see the mqueue
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_03 stime=1500298523
cmdline="mqns_03"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through unshare(2)
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through unshare(2)
posixmq_namespace_03 0 TINFO : Checking correct umount+remount of mqueuefs
posixmq_namespace_03 1 TPASS : umount+remount of mqueuefs remounted the right fs
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_03_clone stime=1500298523
cmdline="mqns_03 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through clone(2)
posixmq_namespace_03 0 TINFO : Testing posix mq namespaces through clone(2)
posixmq_namespace_03 0 TINFO : Checking correct umount+remount of mqueuefs
posixmq_namespace_03 1 TPASS : umount+remount of mqueuefs remounted the right fs
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_04 stime=1500298523
cmdline="mqns_04"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through unshare(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 1 TPASS : Child mqueue fs still visible for parent
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mqns_04_clone stime=1500298523
cmdline="mqns_04 -clone"
contacts=""
analysis=exit
<<<test_output>>>
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 0 TINFO : Testing posix mq namespaces through clone(2).
posixmq_namespace_04 0 TINFO : Checking mqueue filesystem lifetime
posixmq_namespace_04 1 TPASS : Child mqueue fs still visible for parent
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=netns_netlink stime=1500298524
cmdline="netns_netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_netlink 1 TPASS : netlink interface pass
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv4_netlink stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv4_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_breakns_ns_exec_ipv4_netlink 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv4_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv6_netlink stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv6_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_breakns_ns_exec_ipv6_netlink 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv6_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv4_ioctl stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv4_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_breakns_ns_exec_ipv4_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv4_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=2
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ns_exec_ipv6_ioctl stime=1500298524
cmdline="netns_breakns.sh ns_exec ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ns_exec_ipv6_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_breakns_ns_exec_ipv6_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ns_exec_ipv6_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv4_netlink stime=1500298524
cmdline="netns_breakns.sh ip ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv4_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_breakns_ip_ipv4_netlink 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv4_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv6_netlink stime=1500298524
cmdline="netns_breakns.sh ip ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv6_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_breakns_ip_ipv6_netlink 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv6_netlink 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv4_ioctl stime=1500298525
cmdline="netns_breakns.sh ip ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv4_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_breakns_ip_ipv4_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv4_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_breakns_ip_ipv6_ioctl stime=1500298525
cmdline="netns_breakns.sh ip ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_breakns_ip_ipv6_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_breakns_ip_ipv6_ioctl 1 TPASS: controlling device over netlink
netns_breakns_ip_ipv6_ioctl 2 TPASS: controlling device over ioctl
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv4_netlink stime=1500298525
cmdline="netns_comm.sh ns_exec ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv4_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_comm_ns_exec_ipv4_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv4_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv4_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv6_netlink stime=1500298528
cmdline="netns_comm.sh ns_exec ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv6_netlink 1 TINFO: NS interaction: ns_exec | devices setup: netlink
netns_comm_ns_exec_ipv6_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv6_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv6_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=2
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv4_ioctl stime=1500298532
cmdline="netns_comm.sh ns_exec ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv4_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_comm_ns_exec_ipv4_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv4_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv4_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ns_exec_ipv6_ioctl stime=1500298535
cmdline="netns_comm.sh ns_exec ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ns_exec_ipv6_ioctl 1 TINFO: NS interaction: ns_exec | devices setup: ioctl
netns_comm_ns_exec_ipv6_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ns_exec_ipv6_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ns_exec_ipv6_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv4_netlink stime=1500298538
cmdline="netns_comm.sh ip ipv4 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv4_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_comm_ip_ipv4_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv4_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv4_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=3 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv6_netlink stime=1500298542
cmdline="netns_comm.sh ip ipv6 netlink"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv6_netlink 1 TINFO: NS interaction: ip | devices setup: netlink
netns_comm_ip_ipv6_netlink 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv6_netlink 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv6_netlink 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv4_ioctl stime=1500298546
cmdline="netns_comm.sh ip ipv4 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv4_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_comm_ip_ipv4_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv4_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv4_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_comm_ip_ipv6_ioctl stime=1500298549
cmdline="netns_comm.sh ip ipv6 ioctl"
contacts=""
analysis=exit
<<<test_output>>>
netns_comm_ip_ipv6_ioctl 1 TINFO: NS interaction: ip | devices setup: ioctl
netns_comm_ip_ipv6_ioctl 1 TPASS: configuration and communication over veth0
netns_comm_ip_ipv6_ioctl 2 TPASS: configuration and communication over veth1
netns_comm_ip_ipv6_ioctl 3 TPASS: configuration and communication over localhost
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=netns_sysfs stime=1500298553
cmdline="netns_sysfs.sh"
contacts=""
analysis=exit
<<<test_output>>>
netns_sysfs 1 TPASS: sysfs in new namespace has dummy_test1 interface
netns_sysfs 2 TPASS: sysfs in new namespace does not have dummy_test0 interface
netns_sysfs 3 TPASS: sysfs not affected by a separate namespace
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_none stime=1500298553
cmdline="shmnstest none"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : none
sysvipc_namespace 0 TINFO : shmid namespaces test : none
sysvipc_namespace 1 TPASS : plain cloned process found shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_clone stime=1500298553
cmdline="shmnstest clone"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : clone
sysvipc_namespace 0 TINFO : shmid namespaces test : clone
sysvipc_namespace 1 TPASS : clone: child process didn't find shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmnstest_unshare stime=1500298553
cmdline="shmnstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
sysvipc_namespace 0 TINFO : shmid namespaces test : unshare
sysvipc_namespace 0 TINFO : shmid namespaces test : unshare
sysvipc_namespace 1 TPASS : unshare: child process didn't find shmid
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_none stime=1500298553
cmdline="shmem_2nstest none"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 0 TINFO : Shared Memory namespace test : none
shmem_2nstest 1 TPASS : Plain cloned process able to access shmem segment created
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_clone stime=1500298553
cmdline="shmem_2nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 0 TINFO : Cont2: Able to allocate shmem seg with the same key
shmem_2nstest 0 TINFO : Shared Memory namespace test : clone
shmem_2nstest 1 TPASS : clone : In namespace2 unable to access the shmem seg created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmem_2nstest_unshare stime=1500298553
cmdline="shmem_2nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 0 TINFO : Cont1: Able to create shared mem segment
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 0 TINFO : Cont2: Able to allocate shmem seg with the same key
shmem_2nstest 0 TINFO : Shared Memory namespace test : unshare
shmem_2nstest 1 TPASS : unshare : In namespace2 unable to access the shmem seg created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shm_comm stime=1500298553
cmdline="shm_comm"
contacts=""
analysis=exit
<<<test_output>>>
shm_comm 1 TPASS : SysV shm: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_none stime=1500298553
cmdline="mesgq_nstest none"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : none
mesgq_nstest 0 TINFO : Mesg read of 18 bytes; Type 5: Msg: Message of type 5!
mesgq_nstest 0 TINFO : mesgq namespaces test : none
mesgq_nstest 1 TPASS : Plain cloned process found mesgq inside container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_clone stime=1500298553
cmdline="mesgq_nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : clone
mesgq_nstest 0 TINFO : mesgq namespaces test : clone
mesgq_nstest 1 TPASS : clone: Container didn't find mesgq
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mesgq_nstest_unshare stime=1500298553
cmdline="mesgq_nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
mesgq_nstest 0 TINFO : mesgq namespaces test : unshare
mesgq_nstest 0 TINFO : mesgq namespaces test : unshare
mesgq_nstest 1 TPASS : unshare: Container didn't find mesgq
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=msg_comm stime=1500298553
cmdline="msg_comm"
contacts=""
analysis=exit
<<<test_output>>>
msg_comm 1 TPASS : SysV msg: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_none stime=1500298553
cmdline="sem_nstest none"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : none
sem_nstest 0 TINFO : PID 5072: Fetched existing semaphore..id = 32769
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : none
sem_nstest 1 TPASS : Plain cloned process found semaphore inside container
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_clone stime=1500298553
cmdline="sem_nstest clone"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : clone
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : clone
sem_nstest 1 TPASS : clone: Container didn't find semaphore
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_nstest_unshare stime=1500298553
cmdline="sem_nstest unshare"
contacts=""
analysis=exit
<<<test_output>>>
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : unshare
sem_nstest 0 TINFO : Semaphore namespaces Isolation test : unshare
sem_nstest 1 TPASS : unshare: Container didn't find semaphore
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_none stime=1500298553
cmdline="semtest_2ns none"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 0 TINFO : Sem1: File locked, Critical section is updated...
semtest_2ns 0 TINFO : Semaphore Namespaces Test : none
semtest_2ns 1 TPASS : Plain cloned process able to access the semaphore created
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_clone stime=1500298555
cmdline="semtest_2ns clone"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 0 TINFO : Cont2: Able to create semaphore with sameKey
semtest_2ns 0 TINFO : Semaphore Namespaces Test : clone
semtest_2ns 1 TPASS : clone : In namespace2 unable to access the semaphore created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semtest_2ns_unshare stime=1500298555
cmdline="semtest_2ns unshare"
contacts=""
analysis=exit
<<<test_output>>>
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 0 TINFO : Cont1: Able to create semaphore
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 0 TINFO : Cont2: Able to create semaphore with sameKey
semtest_2ns 0 TINFO : Semaphore Namespaces Test : unshare
semtest_2ns 1 TPASS : unshare : In namespace2 unable to access the semaphore created in Namespace1
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sem_comm stime=1500298556
cmdline="sem_comm"
contacts=""
analysis=exit
<<<test_output>>>
sem_comm 1 TPASS : SysV sem: communication with identical keys between namespaces
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_1 stime=1500298556
cmdline="utstest unshare 1"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 1 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_2 stime=1500298556
cmdline="utstest unshare 2"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 2 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_3 stime=1500298556
cmdline="utstest unshare 3"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 3 (unshare): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_4 stime=1500298556
cmdline="utstest unshare 4"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 4 (unshare): successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_unshare_5 stime=1500298556
cmdline="utstest unshare 5"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : P2: P1 claims error
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_1 stime=1500298556
cmdline="utstest clone 1"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 1 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_2 stime=1500298556
cmdline="utstest clone 2"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 2 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_3 stime=1500298556
cmdline="utstest clone 3"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 3 (clone): success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_4 stime=1500298556
cmdline="utstest clone 4"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : test 4 (clone): successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=utstest_clone_5 stime=1500298556
cmdline="utstest clone 5"
contacts=""
analysis=exit
<<<test_output>>>
uts_namespace 1 TPASS : P2: P1 claims error
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns01 stime=1500298556
cmdline="mountns01"
contacts=""
analysis=exit
<<<test_output>>>
mountns01 1 TPASS : shared mount in child passed
mountns01 2 TPASS : shared mount in parent passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns02 stime=1500298556
cmdline="mountns02"
contacts=""
analysis=exit
<<<test_output>>>
mountns02 1 TPASS : private mount in child passed
mountns02 2 TPASS : private mount in parent passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns03 stime=1500298556
cmdline="mountns03"
contacts=""
analysis=exit
<<<test_output>>>
mountns03 1 TPASS : propagation from slave mount passed
mountns03 2 TPASS : propagation to slave mount passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mountns04 stime=1500298556
cmdline="mountns04"
contacts=""
analysis=exit
<<<test_output>>>
mountns04 1 TPASS : unbindable mount passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns01 stime=1500298556
cmdline="userns01"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace1 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns02 stime=1500298556
cmdline="userns02"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace2 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns03 stime=1500298556
cmdline="userns03"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace3 1 TPASS : setgroups can't be re-enabled
user_namespace3 0 TINFO : Child process returned TPASS
user_namespace3 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns04 stime=1500298556
cmdline="userns04"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace4 0 TINFO : Child process returned TPASS
user_namespace4 0 TINFO : Child process returned TPASS
user_namespace4 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns05 stime=1500298556
cmdline="userns05"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace5 0 TINFO : Child process returned TPASS
user_namespace5 0 TINFO : Child process returned TPASS
user_namespace5 0 TINFO : Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns06 stime=1500298556
cmdline="userns06"
contacts=""
analysis=exit
<<<test_output>>>
user_namespace6 0 TINFO : Child process returned TPASS
user_namespace6 0 TINFO : Child process returned TFAIL
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=userns07 stime=1500298556
cmdline="userns07"
contacts=""
analysis=exit
<<<test_output>>>
userns07 0 TINFO : Child process returned TPASS
incrementing stop
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
INFO: ltp-pan reported some tests FAIL
LTP Version: 20170516-93-g10f4a5476
###############################################################
Done executing testcases.
LTP Version: 20170516-93-g10f4a5476
###############################################################
-------------- next part --------------
---
#! jobs/ltp.yaml
suite: ltp
testcase: ltp
category: functional
ltp:
test: containers
job_origin: "/lkp/lkp/.src-20170713-182338/allot/cyclic:linux-devel:devel-hourly/nhm-white2/ltp.yaml"
#! queue options
queue: bisect
testbox: nhm-white2
tbox_group: nhm-white2
submit_id: 596cbccc0b9a93d8998bd5fd
job_file: "/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml"
id: bcf686732c701d15cf5dadb19fcea28e34ef0504
#! hosts/nhm-white2
model: Nehalem
memory: 4G
nr_cpu: 8
hdd_partitions:
swap_partitions:
rootfs_partition:
netconsole_port: 6671
brand: Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
#! include/category/functional
kmsg:
heartbeat:
#! include/ltp
need_kconfig: CONFIG_BLK_DEV_LOOP
#! include/queue/cyclic
commit: 3f3bf5920d2df8b0b3df8ec90e21e67316688e95
#! include/testbox/nhm-white2
cpufreq_governor:
#! default params
kconfig: x86_64-rhel-7.2
compiler: gcc-6
rootfs: debian-x86_64-2016-08-31.cgz
enqueue_time: 2017-07-17 21:34:04.819483840 +08:00
_id: 596cbccc0b9a93d8998bd5fd
_rt: "/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95"
#! schedule options
user: lkp
head_commit: e457614996880c0ba13ddf22980b39b56030a491
base_commit: 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
branch: linux-devel/devel-hourly-2017071420
result_root: "/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0"
LKP_SERVER: inn
max_uptime: 3600
initrd: "/osimage/debian/debian-x86_64-2016-08-31.cgz"
bootloader_append:
- root=/dev/ram0
- user=lkp
- job=/lkp/scheduled/nhm-white2/ltp-containers-debian-x86_64-2016-08-31.cgz-3f3bf5920d2df8b0b3df8ec90e21e67316688e95-20170717-120985-3w76sx-0.yaml
- ARCH=x86_64
- kconfig=x86_64-rhel-7.2
- branch=linux-devel/devel-hourly-2017071420
- commit=3f3bf5920d2df8b0b3df8ec90e21e67316688e95
- BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59
- max_uptime=3600
- RESULT_ROOT=/result/ltp/containers/nhm-white2/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/0
- LKP_SERVER=inn
- debug
- apic=debug
- sysrq_always_enabled
- rcupdate.rcu_cpu_stall_timeout=100
- net.ifnames=0
- printk.devkmsg=on
- panic=-1
- softlockup_panic=1
- nmi_watchdog=panic
- oops=panic
- load_ramdisk=2
- prompt_ramdisk=0
- drbd.minor_count=8
- systemd.log_level=err
- ignore_loglevel
- earlyprintk=ttyS0,115200
- console=ttyS0,115200
- console=tty0
- vga=normal
- rw
lkp_initrd: "/lkp/lkp/lkp-x86_64.cgz"
modules_initrd: "/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/modules.cgz"
bm_initrd: "/osimage/deps/debian-x86_64-2016-08-31.cgz/lkp_2017-05-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/rsync-rootfs_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/ltp_2017-07-01.cgz,/osimage/pkg/debian-x86_64-2016-08-31.cgz/ltp-x86_64-10f4a5476_2017-07-01.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/hw_2016-11-15.cgz"
site: inn
#! /lkp/lkp/.src-20170717-111651/include/site/inn
LKP_CGI_PORT: 80
LKP_CIFS_PORT: 139
oom-killer:
watchdog:
nfs-hang:
#! runtime status
#! user overrides
kernel: "/pkg/linux/x86_64-rhel-7.2/gcc-6/3f3bf5920d2df8b0b3df8ec90e21e67316688e95/vmlinuz-4.12.0-10318-g3f3bf59"
dequeue_time: 2017-07-17 21:34:38.045538335 +08:00
#! /lkp/lkp/.src-20170717-211357/include/site/inn
job_state: failed
loadavg: '0.62'
-------------- next part --------------
./runltp -f containers
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-11 15:05 ` Stefan Berger
(?)
@ 2017-07-14 23:41 ` Eric W. Biederman
-1 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:41 UTC (permalink / raw)
To: Stefan Berger
Cc: containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey, Stefan Berger
Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo@uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo@uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo@uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo@uid=1000 will be listed as security.foo in the user
> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
I am just going to quickly and publicly point out that as designed this
patch breaks evm inode metadata signing. As evm_config_xattrnames is not
updated.
While not completely insurmountable that seems like a strong limitation of
this design.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 23:41 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:41 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]
Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo(a)uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo(a)uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo(a)uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo(a)uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo(a)uid=1 will read security.foo(a)uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo(a)uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo(a)uid=1000 will be listed as security.foo in the user
> namespace, security.foo(a)uid=1001 becomes security.foo(a)uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
I am just going to quickly and publicly point out that as designed this
patch breaks evm inode metadata signing. As evm_config_xattrnames is not
updated.
While not completely insurmountable that seems like a strong limitation of
this design.
Eric
^ permalink raw reply [flat|nested] 288+ messages in thread
* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-14 23:41 ` Eric W. Biederman
0 siblings, 0 replies; 288+ messages in thread
From: Eric W. Biederman @ 2017-07-14 23:41 UTC (permalink / raw)
To: linux-security-module
Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
>
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
>
> Reading of extended attributes:
>
> 1a) Reading security.foo from a user namespace will read
> security.foo at uid=<uid> of the parent user namespace instead with uid
> being the mapping of root in that parent user namespace. An
> exception is if root is mapped to uid 0 on the host, and in this case
> we will read security.foo directly.
> --> reading security.foo will read security.foo at uid=1000 for uid
> mapping of root to 1000.
>
> 1b) If security.foo at uid=<uid> is not available, the security.foo of the
> parent namespace is tried to be read. This procedure is repeated up to
> the init user namespace. This step only applies for reading of extended
> attributes and provides the same behavior as older system where the
> host's extended attributes applied to user namespaces.
>
> 2) All security.foo at uid=<uid> with valid uid mapping in the user namespace
> can be read. The uid within the user namespace will be mapped to the
> corresponding uid on the host and that uid will be used in the name of
> the extended attribute.
> -> reading security.foo at uid=1 will read security.foo at uid=1001 for uid
> mapping of root to 1000, size of at least 2.
>
> All security.foo at uid=<uid> can be read (by root) on the host with values
> of <uid> also being subject to checking for valid mappings.
>
> 3) No other security.foo* can be read.
>
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
>
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo at uid=1000 will be listed as security.foo in the user
> namespace, security.foo at uid=1001 becomes security.foo at uid=1 and so on.
>
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
> ---
> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
> security/commoncap.c | 36 +++-
> security/selinux/hooks.c | 9 +-
> 3 files changed, 523 insertions(+), 31 deletions(-)
I am just going to quickly and publicly point out that as designed this
patch breaks evm inode metadata signing. As evm_config_xattrnames is not
updated.
While not completely insurmountable that seems like a strong limitation of
this design.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread
[parent not found: <87d192si18.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
[not found] ` <87d192si18.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2017-07-15 21:27 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-15 21:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lkp-JC7UmRfGjtg,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
casey-iSGtlc1asvQWG2LlvL+J4A,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
On 07/14/2017 07:41 PM, Eric W. Biederman wrote:
> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>
>> From: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo@uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo@uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo@uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo@uid=1000 will be listed as security.foo in the user
>> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>> Signed-off-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>> Reviewed-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
> I am just going to quickly and publicly point out that as designed this
> patch breaks evm inode metadata signing. As evm_config_xattrnames is not
> updated.
>
> While not completely insurmountable that seems like a strong limitation of
> this design.
EVM could be converted to get the list of xattrs and prefix-compare it
against the evm_config_xattrnames to do what it does now.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread
* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
2017-07-14 23:41 ` Eric W. Biederman
(?)
@ 2017-07-15 21:27 ` Stefan Berger
-1 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-15 21:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: containers, lkp, linux-kernel, zohar, tycho, serge,
James.Bottomley, vgoyal, christian.brauner, amir73il,
linux-security-module, casey
On 07/14/2017 07:41 PM, Eric W. Biederman wrote:
> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>
>> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo@uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo@uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo@uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo@uid=1000 will be listed as security.foo in the user
>> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
> I am just going to quickly and publicly point out that as designed this
> patch breaks evm inode metadata signing. As evm_config_xattrnames is not
> updated.
>
> While not completely insurmountable that seems like a strong limitation of
> this design.
EVM could be converted to get the list of xattrs and prefix-compare it
against the evm_config_xattrnames to do what it does now.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* Re: [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-15 21:27 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-15 21:27 UTC (permalink / raw)
To: lkp
[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]
On 07/14/2017 07:41 PM, Eric W. Biederman wrote:
> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>
>> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo(a)uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo(a)uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo(a)uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo(a)uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo(a)uid=1 will read security.foo(a)uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo(a)uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo(a)uid=1000 will be listed as security.foo in the user
>> namespace, security.foo(a)uid=1001 becomes security.foo(a)uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
> I am just going to quickly and publicly point out that as designed this
> patch breaks evm inode metadata signing. As evm_config_xattrnames is not
> updated.
>
> While not completely insurmountable that seems like a strong limitation of
> this design.
EVM could be converted to get the list of xattrs and prefix-compare it
against the evm_config_xattrnames to do what it does now.
Stefan
^ permalink raw reply [flat|nested] 288+ messages in thread* [PATCH v2] xattr: Enable security.capability in user namespaces
@ 2017-07-15 21:27 ` Stefan Berger
0 siblings, 0 replies; 288+ messages in thread
From: Stefan Berger @ 2017-07-15 21:27 UTC (permalink / raw)
To: linux-security-module
On 07/14/2017 07:41 PM, Eric W. Biederman wrote:
> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
>
>> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo at uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo at uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo at uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo at uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo at uid=1 will read security.foo at uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo at uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo at uid=1000 will be listed as security.foo in the user
>> namespace, security.foo at uid=1001 becomes security.foo at uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
> I am just going to quickly and publicly point out that as designed this
> patch breaks evm inode metadata signing. As evm_config_xattrnames is not
> updated.
>
> While not completely insurmountable that seems like a strong limitation of
> this design.
EVM could be converted to get the list of xattrs and prefix-compare it
against the evm_config_xattrnames to do what it does now.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 288+ messages in thread