RE: [RFC PATCH v2 1/3] x86/sgx: Add SGX specific LSM hooks

["Xing, Cedric" <cedric.xing@intel.com>]

Hi Casey,

> From: Casey Schaufler [mailto:casey@schaufler-ca.com]
> Sent: Thursday, June 27, 2019 3:07 PM
> 
> Don't use "lsm_ema". This isn't LSM infrastructure.
> Three letter abbreviations are easy to type, but are doomed to encounter
> conflicts and lead to confusion.
> I suggest that you use "enclave", because it doesn't start off
> conflicting with anything and is descriptive.
> 
> This code should not be mixed in with the LSM infrastructure.
> It should all be contained in its own module, under security/enclave.

lsm_ema is *intended* to be part of the LSM infrastructure. It is going to be shared among all LSMs that would like to track enclave pages and their origins. And they could be extended to store more information as deemed appropriate by the LSM module. The last patch of this series shows how to extend EMA inside SELinux.

> 
> > diff --git a/include/linux/lsm_ema.h b/include/linux/lsm_ema.h new
> > file mode 100644 index 000000000000..a09b8f96da05
> > --- /dev/null
> > +++ b/include/linux/lsm_ema.h
> 
> There's no need for this header to be used outside the enclave
> LSM. It should be "security/enclave/enclave.h"

This header file is supposed to be used by all LSM modules, similar to lsm_hooks.h. Hence it is placed in the same location.

> 
> 
> > @@ -0,0 +1,171 @@
> > +/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
> > +/**
> > + * Enclave Memory Area interface for LSM modules
> > + *
> > + * Copyright(c) 2016-19 Intel Corporation.
> > + */
> > +
> > +#ifndef _LSM_EMA_H_
> > +#define _LSM_EMA_H_
> > +
> > +#include <linux/list.h>
> > +#include <linux/mutex.h>
> > +#include <linux/fs.h>
> > +#include <linux/file.h>
> > +
> > +/**
> > + * lsm_ema - LSM Enclave Memory Area structure
> 
> How about s/lsm_ema/enclave/ ?

I understand your suggestion, but this structure is shared among all LSMs. And I think lsm_ema is pretty descriptive without being too verbose.

> 
> > + *
> > + * Data structure to track origins of enclave pages
> > + *
> > + * @link:
> > + *	Link to adjacent EMAs. EMAs are sorted by their addresses in
> ascending
> > + *	order
> > + * @start:
> > + *	Starting address
> > + * @end:
> > + *	Ending address
> > + * @source:
> > + *	File from which this range was loaded from, or NULL if not loaded
> from
> > + *	any files
> > + */
> > +struct lsm_ema {
> > +	struct list_head	link;
> > +	size_t			start;
> > +	size_t			end;
> > +	struct file		*source;
> > +};
> > +
> > +#define lsm_ema_data(ema, blob_sizes)	\
> > +	((char *)((struct lsm_ema *)(ema) + 1) + blob_sizes.lbs_ema_data)
> 
> Who uses this? The enclave LSM? Convention would have this
> be selinux_enclave(ema) for the SELinux code. This is
> inconsistent with the way other blobs are handled.

This is to be used in various LSMs. As you can see in the last patch of this series, selinux_ema() is defined as a wrapper of this macro.

> 
> > +
> > +/**
> > + * lsm_ema_map - LSM Enclave Memory Map structure
> 
> enclave_map
> 
> > + *
> > + * Container for EMAs of an enclave
> > + *
> > + * @list:
> > + *	Head of a list of sorted EMAs
> > + * @lock:
> > + *	Acquire before querying/updateing the list EMAs
> > + */
> > +struct lsm_ema_map {
> > +	struct list_head	list;
> > +	struct mutex		lock;
> > +};
> > +
> > +/**
> > + * These are functions to be used by the LSM framework, and must be
> defined
> > + * regardless CONFIG_INTEL_SGX is enabled or not.
> 
> Not acceptable for the LSM infrastructure. They
> are inconsistent with the way data is used there.

I'm not sure I understand this comment.

> 
> > + */
> > +
> > +#ifdef CONFIG_INTEL_SGX
> > +void lsm_ema_global_init(size_t);
> > +void lsm_free_ema_map(atomic_long_t *);
> > +#else
> > +static inline void lsm_ema_global_init(size_t ema_data_size)
> > +{
> > +}
> > +
> > +static inline void lsm_free_ema_map(atomic_long_t *p)
> > +{
> > +}
> > +#endif
> > +
> > +/**
> > + * Below are APIs to be used by LSM modules
> > + */
> > +
> > +struct lsm_ema_map *lsm_init_or_get_ema_map(atomic_long_t *);
> > +struct lsm_ema *lsm_alloc_ema(void);
> 
> Do you mean security_alloc_enclave()?
> That would go into security/security.h

No. Neither lsm_alloc_ema() above, nor lsm_free_ema() below, is LSM hook. They are APIs to deal with EMAs.

> 
> > +void lsm_free_ema(struct lsm_ema *);
> 
> Do you mean security_free_enclave()?
> That would go into security/security.h
> 
> > +void lsm_init_ema(struct lsm_ema *, size_t, size_t, struct file *);
> 
> This goes in the enclave LSM.

There's NO enclave LSM. This patch is introducing new LSM hooks applicable to all LSM modules, but not introducing new LSM modules.

> 
> > +int lsm_merge_ema(struct lsm_ema *, struct lsm_ema_map *);
> > +struct lsm_ema *lsm_split_ema(struct lsm_ema *, size_t, struct
> lsm_ema_map *);
> > +
> > +static inline struct lsm_ema_map *lsm_get_ema_map(struct file *f)
> > +{
> > +	return (void *)atomic_long_read(f->f_security);
> > +}
> > +
> > +static inline int __must_check lsm_lock_ema(struct lsm_ema_map *map)
> > +{
> > +	return mutex_lock_interruptible(&map->lock);
> > +}
> > +
> > +static inline void lsm_unlock_ema(struct lsm_ema_map *map)
> > +{
> > +	mutex_unlock(&map->lock);
> > +}
> > +
> > +static inline struct lsm_ema *lsm_prev_ema(struct lsm_ema *p,
> > +					   struct lsm_ema_map *map)
> > +{
> > +	p = list_prev_entry(p, link);
> > +	return &p->link == &map->list ? NULL : p;
> > +}
> > +
> > +static inline struct lsm_ema *lsm_next_ema(struct lsm_ema *p,
> > +					   struct lsm_ema_map *map)
> > +{
> > +	p = list_next_entry(p, link);
> > +	return &p->link == &map->list ? NULL : p;
> > +}
> > +
> > +static inline struct lsm_ema *lsm_find_ema(struct lsm_ema_map *map,
> size_t a)
> > +{
> > +	struct lsm_ema *p;
> > +
> > +	BUG_ON(!mutex_is_locked(&map->lock));
> > +
> > +	list_for_each_entry(p, &map->list, link)
> > +		if (a < p->end)
> > +			break;
> > +	return &p->link == &map->list ? NULL : p;
> > +}
> > +
> > +static inline int lsm_insert_ema(struct lsm_ema_map *map, struct
> lsm_ema *n)
> > +{
> > +	struct lsm_ema *p = lsm_find_ema(map, n->start);
> > +
> > +	if (!p)
> > +		list_add_tail(&n->link, &map->list);
> > +	else if (n->end <= p->start)
> > +		list_add_tail(&n->link, &p->link);
> > +	else
> > +		return -EEXIST;
> > +
> > +	lsm_merge_ema(n, map);
> > +	if (p)
> > +		lsm_merge_ema(p, map);
> > +	return 0;
> > +}
> > +
> > +static inline int lsm_for_each_ema(struct lsm_ema_map *map, size_t
> start,
> > +				   size_t end, int (*cb)(struct lsm_ema *,
> > +							 void *), void *arg)
> > +{
> > +	struct lsm_ema *ema;
> > +	int rc;
> > +
> > +	ema = lsm_find_ema(map, start);
> > +	while (ema && end > ema->start) {
> > +		if (start > ema->start)
> > +			lsm_split_ema(ema, start, map);
> > +		if (end < ema->end)
> > +			ema = lsm_split_ema(ema, end, map);
> > +
> > +		rc = (*cb)(ema, arg);
> > +		lsm_merge_ema(ema, map);
> > +		if (rc)
> > +			return rc;
> > +
> > +		ema = lsm_next_ema(ema, map);
> > +	}
> > +
> > +	if (ema)
> > +		lsm_merge_ema(ema, map);
> > +	return 0;
> > +}
> 
> There is no way that these belong as part of the LSM
> infrastructure. If you need an enclave management API
> you need to find some other place for it.

They are NO enclave management APIs. They don't manage enclaves. They track origins of enclave pages. They are needed by all LSMs.

As I stated in the cover letter, the primary question is how to prevent SGX from being abused as a backdoor to make executable pages that would otherwise not be executable without SGX. Any LSM module unaware of that would leave that "hole" open. So tracking enclave pages will become a common task for all LSMs that care page protections, and that's why I place it inside LSM infrastructure.