On Sun Mar 24, 2024 at 1:29 AM EET, Jarkko Sakkinen wrote:
> Tracing with kprobes while running a monolithic kernel is currently
> impossible due the kernel module allocator dependency.
>
> Address the issue by allowing architectures to implement module_alloc()
> and module_memfre
...@profian.com/
# continuation
Signed-off-by: Jarkko Sakkinen
---
v2:
- Better late than never right? :-)
- Focus only to RISC-V for now to make the patch more digestable. This
is the arch where I use the patch on a daily basis to help with QA.
- Introduce HAVE_KPROBES_ALLOC flag to help with more
On Mon Feb 26, 2024 at 11:56 PM EET, Dave Hansen wrote:
> On 2/26/24 13:48, Haitao Huang wrote:
> > In case of overcomitting, i.e., sum of limits greater than the EPC
> > capacity, if one group has a fault, and its usage is not above its own
> > limit (try_charge() passes), yet total usage of the
On Mon Feb 19, 2024 at 10:25 PM UTC, Haitao Huang wrote:
> On Mon, 19 Feb 2024 14:42:29 -0600, Jarkko Sakkinen
> wrote:
>
> > On Mon Feb 19, 2024 at 3:56 PM UTC, Dave Hansen wrote:
> >> On 2/19/24 07:39, Haitao Huang wrote:
> >> > Remove all boolean parame
portunistically remove non-static declaration of
> > __sgx_alloc_epc_page() and a typo
> >
> > Signed-off-by: Haitao Huang
> > Suggested-by: Jarkko Sakkinen
> > ---
> > arch/x86/kernel/cpu/sgx/encl.c | 56 +--
> > arch/x8
_page() and a typo
>
> Signed-off-by: Haitao Huang
> Suggested-by: Jarkko Sakkinen
I think this is for better.
My view point for kernel patches overally is that:
1. A feature should leave the subsystem in cleaner state as
far as the existing framework of doing things goes.
2
On Mon Feb 19, 2024 at 3:12 PM UTC, Haitao Huang wrote:
> On Tue, 13 Feb 2024 19:52:25 -0600, Jarkko Sakkinen
> wrote:
>
> > On Tue Feb 13, 2024 at 1:15 AM EET, Haitao Huang wrote:
> >> Hi Jarkko
> >>
> >> On Mon, 12 Feb 2024 13:55:46 -0600, Jarkko Sakk
On Tue Feb 13, 2024 at 1:15 AM EET, Haitao Huang wrote:
> Hi Jarkko
>
> On Mon, 12 Feb 2024 13:55:46 -0600, Jarkko Sakkinen
> wrote:
>
> > On Mon Feb 5, 2024 at 11:06 PM EET, Haitao Huang wrote:
> >> From: Kristen Carlson Accardi
> >>
> >>
@low bits 12(). Prototype was for sgx_calc_section_metric()
> instead
>
> Cc: Jarkko Sakkinen
> Cc: Dave Hansen
> Cc: linux-...@vger.kernel.org
> Cc: x...@kernel.org
> Reviewed-by: Kai Huang
> Signed-off-by: Randy Dunlap
> ---
> v2: add Rev-by: Kai Huang
>
> arch/x86/kernel/
On Mon Feb 5, 2024 at 11:06 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When cgroup is enabled, all reclaimable pages will be tracked in cgroup
> LRUs. The global reclaimer needs to start reclamation from the root
> cgroup. Expose the top level cgroup reclamation function so
On Mon Feb 5, 2024 at 11:06 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> To determine if any page available for reclamation at the global level,
> only checking for emptiness of the global LRU is not adequate when pages
> are tracked in multiple LRUs, one per cgroup. For this
On Mon Feb 5, 2024 at 11:06 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When the EPC usage of a cgroup is near its limit, the cgroup needs to
> reclaim pages used in the same cgroup to make room for new allocations.
> This is analogous to the behavior that the global reclaimer
On Mon Feb 5, 2024 at 11:06 PM EET, Haitao Huang wrote:
> Enclave Page Cache(EPC) memory can be swapped out to regular system
"Enclave Page Cache (EPC)"
~
> memory, and the consumed memory should be charged to a proper
> mem_cgroup. Currently the selection of mem_cgroup to
On Mon Feb 5, 2024 at 11:06 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Implement the reclamation flow for cgroup, encapsulated in the top-level
> function sgx_epc_cgroup_reclaim_pages(). It does a pre-order walk on its
> subtree, and make calls to sgx_reclaim_pages() at each
On Fri Feb 2, 2024 at 6:34 PM EET, Haitao Huang wrote:
> On Thu, 01 Feb 2024 17:24:40 -0600, Jarkko Sakkinen
> wrote:
>
> > On Tue Jan 30, 2024 at 4:09 AM EET, Haitao Huang wrote:
> >> From: Kristen Carlson Accardi
> >>
> >> The misc cgroup control
On Tue Jan 30, 2024 at 4:09 AM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Implement the reclamation flow for cgroup, encapsulated in the top-level
> function sgx_epc_cgroup_reclaim_pages(). It does a pre-order walk on its
> subtree, and make calls to sgx_reclaim_pages() at each
c_page() to
> fail.
>*/
> - sgx_reclaim_pages();
> + sgx_reclaim_pages_global();
> cond_resched();
> }
>
> diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
> index 0e99e9ae3a67..2593c013d091 100644
> --- a/arch/x86/kernel/cpu/sgx/sgx.h
> +++ b/arch/x86/kernel/cpu/sgx/sgx.h
> @@ -110,6 +110,7 @@ void sgx_reclaim_direct(void);
> void sgx_mark_page_reclaimable(struct sgx_epc_page *page);
> int sgx_unmark_page_reclaimable(struct sgx_epc_page *page);
> struct sgx_epc_page *sgx_alloc_epc_page(void *owner, bool reclaim);
> +unsigned int sgx_reclaim_pages(struct sgx_epc_lru_list *lru, unsigned int
> *nr_to_scan);
>
> void sgx_ipi_cb(void *info);
>
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
>list)) {
> - spin_unlock(_global_lru.lock);
> + spin_unlock(>lock);
> return -EBUSY;
> }
>
> list_del(>list);
> page->flags &= ~SGX_EPC_PAGE_RECLAIMER_TRACKED;
> }
> - spin_unlock(_global_lru.lock);
> + spin_unlock(>lock);
>
> return 0;
> }
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
@@ -88,6 +88,21 @@ static inline void *sgx_get_epc_virt_addr(struct
> sgx_epc_page *page)
> return section->virt_addr + index * PAGE_SIZE;
> }
>
> +/*
> + * Contains EPC pages tracked by the global reclaimer (ksgxd) or an EPC
> + * cgroup.
> + */
> +struct sgx_epc_lru_list {
> + spinlock_t lock;
> + struct list_head reclaimable;
> +};
> +
> +static inline void sgx_lru_init(struct sgx_epc_lru_list *lru)
> +{
> + spin_lock_init(>lock);
> + INIT_LIST_HEAD(>reclaimable);
> +}
> +
> struct sgx_epc_page *__sgx_alloc_epc_page(void);
> void sgx_free_epc_page(struct sgx_epc_page *page);
>
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
bool __init sgx_page_cache_init(void)
> return false;
> }
>
> + misc_cg_set_capacity(MISC_CG_RES_SGX_EPC, capacity);
> +
> return true;
> }
>
> @@ -942,6 +987,9 @@ static int __init sgx_init(void)
> if (sgx_vepc_init() && ret)
> goto err_provision;
>
> + /* Setup cgroup if either the native or vepc driver is active */
> + sgx_epc_cgroup_init();
> +
> return 0;
>
> err_provision:
> diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
> index d2dad21259a8..a898d86dead0 100644
> --- a/arch/x86/kernel/cpu/sgx/sgx.h
> +++ b/arch/x86/kernel/cpu/sgx/sgx.h
> @@ -29,12 +29,17 @@
> /* Pages on free list */
> #define SGX_EPC_PAGE_IS_FREE BIT(1)
>
> +struct sgx_epc_cgroup;
> +
> struct sgx_epc_page {
> unsigned int section;
> u16 flags;
> u16 poison;
> struct sgx_encl_page *owner;
> struct list_head list;
> +#ifdef CONFIG_CGROUP_SGX_EPC
> + struct sgx_epc_cgroup *epc_cg;
> +#endif
> };
>
> /*
> diff --git a/include/linux/misc_cgroup.h b/include/linux/misc_cgroup.h
> index 2f6cc3a0ad23..1a16efdfcd3d 100644
> --- a/include/linux/misc_cgroup.h
> +++ b/include/linux/misc_cgroup.h
> @@ -46,11 +46,13 @@ struct misc_res_ops {
> * @max: Maximum limit on the resource.
> * @usage: Current usage of the resource.
> * @events: Number of times, the resource limit exceeded.
> + * @priv: resource specific data.
> */
> struct misc_res {
> u64 max;
> atomic64_t usage;
> atomic64_t events;
> + void *priv;
> };
>
> /**
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
(Dave, Michal)
> - Style fixes (Kai)
This version looks nice and smooth:
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Wed Jan 24, 2024 at 5:29 AM EET, Haitao Huang wrote:
> On Mon, 22 Jan 2024 14:25:53 -0600, Jarkko Sakkinen
> wrote:
>
> > On Mon Jan 22, 2024 at 7:20 PM EET, Haitao Huang wrote:
> >> From: Kristen Carlson Accardi
> >>
> >> SGX Enclave Page Cache
On Mon Jan 22, 2024 at 7:20 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When cgroup is enabled, all reclaimable pages will be tracked in cgroup
> LRUs. The global reclaimer needs to start reclamation from the root
> cgroup. Expose the top level cgroup reclamation function so
On Mon Jan 22, 2024 at 7:20 PM EET, Haitao Huang wrote:
> Enclave Page Cache(EPC) memory can be swapped out to regular system
> memory, and the consumed memory should be charged to a proper
> mem_cgroup. Currently the selection of mem_cgroup to charge is done in
> sgx_encl_get_mem_cgroup(). But it
On Mon Jan 22, 2024 at 7:20 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Implement the reclamation flow for cgroup, encapsulated in the top-level
> function sgx_epc_cgroup_reclaim_pages(). It does a pre-order walk on its
> subtree, and make calls to sgx_reclaim_pages() at each
On Mon Jan 22, 2024 at 7:20 PM EET, Haitao Huang wrote:
> From: Sean Christopherson
>
> Each EPC cgroup will have an LRU structure to track reclaimable EPC pages.
> When a cgroup usage reaches its limit, the cgroup needs to reclaim pages
> from its LRU or LRUs of its descendants to make room for
On Mon Jan 22, 2024 at 7:20 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> SGX Enclave Page Cache (EPC) memory allocations are separate from normal
> RAM allocations, and are managed solely by the SGX subsystem. The
> existing cgroup memory controller cannot be used to limit or
cgroup/misc.c
> +++ b/kernel/cgroup/misc.c
> @@ -24,6 +24,10 @@ static const char *const misc_res_name[] = {
> /* AMD SEV-ES ASIDs resource */
> "sev_es",
> #endif
> +#ifdef CONFIG_CGROUP_SGX_EPC
> + /* Intel SGX EPC memory bytes */
> + "sgx_epc",
> +#endif
> };
>
> /* Root misc cgroup */
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
le_notify(>events_file);
> }
>
> - for (j = cg; j != i; j = parent_misc(j))
> + for (j = cg; j != i; j = misc_cg_parent(j))
> misc_cg_cancel_charge(type, j, amount);
> misc_cg_cancel_charge(type, i, amount);
> return ret;
> @@ -223,7 +218,7 @@ void misc_cg_uncharge(enum misc_res_type type, struct
> misc_cg *cg, u64 amount)
> if (!(amount && valid_type(type) && cg))
> return;
>
> - for (i = cg; i; i = parent_misc(i))
> + for (i = cg; i; i = misc_cg_parent(i))
> misc_cg_cancel_charge(type, i, amount);
> }
> EXPORT_SYMBOL_GPL(misc_cg_uncharge);
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Mon Jan 22, 2024 at 7:20 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> The misc cgroup controller (subsystem) currently does not perform
> resource type specific action for Cgroups Subsystem State (CSS) events:
> the 'css_alloc' event when a cgroup is created and the
On Sat Jan 13, 2024 at 11:04 PM EET, Jarkko Sakkinen wrote:
> On Fri Jan 12, 2024 at 7:07 PM EET, Haitao Huang wrote:
> > On Sun, 17 Dec 2023 19:44:56 -0600, Huang, Kai wrote:
> >
> > >
> > >> >
> > >> > The point is, with or w/o
On Fri Jan 12, 2024 at 7:07 PM EET, Haitao Huang wrote:
> On Sun, 17 Dec 2023 19:44:56 -0600, Huang, Kai wrote:
>
> >
> >> >
> >> > The point is, with or w/o this patch, you can only reclaim 16 EPC
> >> pages
> >> > in one
> >> > function call (as you have said you are going to remove
> >> >
On Tue Jan 9, 2024 at 5:37 AM EET, Haitao Huang wrote:
> On Wed, 15 Nov 2023 14:25:59 -0600, Jarkko Sakkinen
> wrote:
>
> > On Mon Oct 30, 2023 at 8:20 PM EET, Haitao Huang wrote:
> >> From: Kristen Carlson Accardi
> >>
> >> The misc cgroup control
On Thu Jan 4, 2024 at 9:11 PM EET, Haitao Huang wrote:
> > The key question here is whether we want the SGX VM to be complex and
> > more like the real VM or simple when a cgroup hits its limit. Right?
> >
>
> Although it's fair to say the majority of complexity of this series is in
> support
On Wed Nov 8, 2023 at 10:46 PM EET, Dave Hansen wrote:
> On 11/8/23 12:31, Jo Van Bulck wrote:
> > Just a kind follow-up: from what I can see, this series has not been
> > merged into the x86/sgx branch of tip yet (assuming that's where it
> > should go next)?
> >
> > Apologies if I've overlooked
On Wed Nov 8, 2023 at 10:31 PM EET, Jo Van Bulck wrote:
> On 23.10.23 23:32, Jarkko Sakkinen wrote:
> > On Fri Oct 13, 2023 at 2:45 PM EEST, Jo Van Bulck wrote:
> >> On 10.10.23 11:44, Jarkko Sakkinen wrote:
> >>> Folks (sorry for top posting): I've now taken my
On Mon Oct 30, 2023 at 8:20 PM EET, Haitao Huang wrote:
> The scripts rely on cgroup-tools package from libcgroup [1].
>
> To run selftests for epc cgroup:
>
> sudo ./run_epc_cg_selftests.sh
>
> With different cgroups, the script starts one or multiple concurrent SGX
> selftests, each to run one
On Mon Oct 30, 2023 at 8:20 PM EET, Haitao Huang wrote:
> From: Sean Christopherson
>
> Change sgx_reclaim_pages() to use a list rather than an array for
> storing the epc_pages which will be reclaimed. This change is needed
> to transition to the LRU implementation for EPC cgroup support.
>
>
On Mon Oct 30, 2023 at 8:20 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Implement support for cgroup control of SGX Enclave Page Cache (EPC)
> memory using the misc cgroup controller. EPC memory is independent
> from normal system memory, e.g. must be reserved at boot from RAM
On Mon Oct 30, 2023 at 8:20 PM EET, Haitao Huang wrote:
> Use the lower 2 bits in the flags field of sgx_epc_page struct to track
> EPC states and define an enum for possible states for EPC pages tracked
> for reclamation.
>
> Add the RECLAIM_IN_PROGRESS state to explicitly indicate a page that is
On Mon Oct 30, 2023 at 8:20 PM EET, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> The misc cgroup controller (subsystem) currently does not perform
> resource type specific action for Cgroups Subsystem State (CSS) events:
> the 'css_alloc' event when a cgroup is created and the
On Mon, 2023-10-30 at 11:20 -0700, Haitao Huang wrote:
> SGX Enclave Page Cache (EPC) memory allocations are separate from normal RAM
> allocations, and
> are managed solely by the SGX subsystem. The existing cgroup memory
> controller cannot be used
> to limit or account for SGX EPC memory,
On Fri Oct 13, 2023 at 2:45 PM EEST, Jo Van Bulck wrote:
> On 10.10.23 11:44, Jarkko Sakkinen wrote:
> > Folks (sorry for top posting): I've now taken my old NUC7 out of the
> > dust and tested the series :-)
> >
> > Tested-by: Jarkko Sakkinen
>
> Thanks for test
today there's a few dependencies like libelf-dev.
I'm open for alternative proposals, just throwing something that
came up mind.
BR, Jarkko
On Tue, 2023-10-10 at 12:44 +0300, Jarkko Sakkinen wrote:
> Folks (sorry for top posting): I've now taken my old NUC7 out of the
> dust and tested the series
Folks (sorry for top posting): I've now taken my old NUC7 out of the
dust and tested the series :-)
Tested-by: Jarkko Sakkinen
Off-topic: I wish both Intel and AMD straighten up and deliver some
"home friendly" development hardware for the latest stuff. Just my
stance but the bigge
On Tue Oct 3, 2023 at 1:47 AM EEST, Jarkko Sakkinen wrote:
> On Wed Sep 27, 2023 at 4:56 AM EEST, Haitao Huang wrote:
> > On Tue, 26 Sep 2023 08:13:18 -0500, Jarkko Sakkinen
> > wrote:
> >
> > ...
> > >> > >> /**
> > >> > &
On Wed Sep 27, 2023 at 4:56 AM EEST, Haitao Huang wrote:
> On Tue, 26 Sep 2023 08:13:18 -0500, Jarkko Sakkinen
> wrote:
>
> ...
> >> > >> /**
> >> > >> @@ -410,7 +429,14 @@ misc_cg_alloc(struct cgroup_subsys_state
> >> > >> *par
On Tue Sep 26, 2023 at 4:10 PM EEST, Jarkko Sakkinen wrote:
> On Tue Sep 26, 2023 at 6:04 AM EEST, Haitao Huang wrote:
> > Hi Jarkko
> >
> > On Mon, 25 Sep 2023 12:09:21 -0500, Jarkko Sakkinen
> > wrote:
> >
> > > On Sat Sep 23, 2023 at 6:06 AM EEST
On Tue Sep 26, 2023 at 6:04 AM EEST, Haitao Huang wrote:
> Hi Jarkko
>
> On Mon, 25 Sep 2023 12:09:21 -0500, Jarkko Sakkinen
> wrote:
>
> > On Sat Sep 23, 2023 at 6:06 AM EEST, Haitao Huang wrote:
> >> From: Kristen Carlson Accardi
> >>
> >>
On Sat Sep 23, 2023 at 6:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Implement support for cgroup control of SGX Enclave Page Cache (EPC)
> memory using the misc cgroup controller. EPC memory is independent
> from normal system memory, e.g. must be reserved at boot from
On Sat Sep 23, 2023 at 6:06 AM EEST, Haitao Huang wrote:
> From: Sean Christopherson
>
> Add RECLAIM_IN_PROGRESS state to not rely on list_empty(_page->list)
> to determine if an EPC page is selected as a reclaiming candidate.
>
> When a page is being reclaimed from the page pool
On Sat Sep 23, 2023 at 6:06 AM EEST, Haitao Huang wrote:
> Use the lower 3 bits in the flags field of sgx_epc_page struct to
> track EPC states in its life cycle and define an enum for possible
> states. More state(s) will be added later.
>
> Signed-off-by: Haitao Huang
> ---
> V4:
> - No changes
On Sat Sep 23, 2023 at 6:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> The misc cgroup controller (subsystem) currently does not perform
> resource type specific action for Cgroups Subsystem State (CSS) events:
> the 'css_alloc' event when a cgroup is created and the
On Sat Sep 16, 2023 at 7:11 AM EEST, Haitao Huang wrote:
> Hi Jarkko
>
> On Wed, 13 Sep 2023 04:39:06 -0500, Jarkko Sakkinen
> wrote:
>
> > On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> >> From: Kristen Carlson Accardi
> >>
> >> Co
push the enclave base address
>
> callencl_body
>
> - pop %rbx # pop the enclave base address
> -
> /* Clear volatile GPRs, except RAX (EEXIT function). */
> xor %rcx, %rcx
> xor %rdx, %rdx
> --
> 2.25.1
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Implement support for cgroup control of SGX Enclave Page Cache (EPC)
> memory using the misc cgroup controller. EPC memory is independent
> from normal system memory, e.g. must be reserved at boot from
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> Add sgx_can_reclaim() wrapper and encapsulate direct references to the
> global LRU list in the reclaimer functions so that they can be called with
> an LRU list per EPC cgroup.
>
> Signed-off-by: Sean Christopherson
> Signed-off-by:
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Sean Christopherson
>
> Adjust and expose the top-level reclaim function as
> sgx_reclaim_epc_pages() for use by the upcoming EPC cgroup, which will
> initiate reclaim to enforce the max limit.
>
> Make these adjustments to the
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Sean Christopherson
>
> Introduce the OOM path for killing an enclave with a reclaimer that is no
> longer able to reclaim enough EPC pages. Find a victim enclave, which
> will be an enclave with only "unreclaimable" EPC pages left
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When an OOM event occurs, all pages associated with an enclave will need
> to be freed, including pages that are not currently tracked by the
> cgroup LRU lists.
>
> Add a new "unreclaimable" list to the
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> In a later patch, when a cgroup has exceeded the max capacity for EPC
> pages, it may need to identify and OOM kill a less active enclave to
> make room for other enclaves within the same group. Such a victim
> enclave would have no active
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Change sgx_reclaim_pages() to use a list rather than an array for
> storing the epc_pages which will be reclaimed. This change is needed
> to transition to the LRU implementation for EPC cgroup support.
>
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> Use the lower 3 bits in the flags field of sgx_epc_page struct to
> track EPC states in its life cycle and define an enum for possible
> states. More state(s) will be added later.
>
> Signed-off-by: Haitao Huang
> ---
> V4:
> - No changes
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Replace sgx_mark_page_reclaimable() and sgx_unmark_page_reclaimable()
> with sgx_record_epc_page() and sgx_drop_epc_page(). The
> sgx_record_epc_page() function adds the epc_page to the "reclaimable"
>
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> All EPC pages of enclaves including VA and SECS will be tracked in
s/VA/Version Array (VA)/
s/SECS/SGX Enclave Control Structure (SECS)/
Just a nitpick, because it is always good to remind what these
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Introduce a data structure to wrap the existing reclaimable list and its
> spinlock. Each cgroup later will have one instance of this structure to
> track EPC pages allocated for processes associated with
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> The SGX driver will need to get access to the root misc_cg object
> to do iterative walks and also determine if a charge will be
> towards the root cgroup or not.
What is "a charge" and why does SGX
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Consumers of the misc cgroup controller might need to perform separate
> actions for Cgroups Subsystem State(CSS) events: cgroup alloc and free.
nit: s/State(CSS)/State (CSS)/
"cgroup alloc" and "cgroup
Merge tag 'for-6.6-rc1-tag' of
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux (2023-09-12 11:28:00
-0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
tags/tpmdd-v6.6-rc2
for you to fetch changes up to
On Tue Sep 12, 2023 at 10:22 PM EEST, Mimi Zohar wrote:
> On Tue, 2023-09-12 at 12:49 +0300, Jarkko Sakkinen wrote:
> > On Tue Sep 12, 2023 at 10:41 AM EEST, Michal Suchánek wrote:
> > > On Mon, Sep 11, 2023 at 11:39:38PM -0400, Nayna wrote:
> > > >
> > > &
On Tue Sep 12, 2023 at 8:02 PM EEST, Justin M. Forbes wrote:
> Commit d2e8071bed0be ("tpm: make all 'class' structures const")
> unfortunately had a typo for the name on tpmrm.
>
> Fixes: d2e8071bed0b ("tpm: make all 'class' structures const")
> Signed-off-by: Justin M. Forbes
> ---
>
On Tue Sep 12, 2023 at 6:39 AM EEST, Nayna wrote:
>
> On 9/7/23 13:32, Michal Suchánek wrote:
> > Adding more CC's from the original patch, looks like get_maintainers is
> > not that great for this file.
> >
> > On Thu, Sep 07, 2023 at 06:52:19PM +0200, Michal Suchanek wrote:
> >> No other
On Tue Sep 12, 2023 at 10:41 AM EEST, Michal Suchánek wrote:
> On Mon, Sep 11, 2023 at 11:39:38PM -0400, Nayna wrote:
> >
> > On 9/7/23 13:32, Michal Suchánek wrote:
> > > Adding more CC's from the original patch, looks like get_maintainers is
> > > not that great for this file.
> > >
> > > On
On Tue Sep 12, 2023 at 10:51 AM EEST, Michal Suchánek wrote:
> On Tue, Sep 12, 2023 at 12:45:35AM +0300, Jarkko Sakkinen wrote:
> > On Thu Sep 7, 2023 at 7:52 PM EEST, Michal Suchanek wrote:
> > > No other platform needs CA_MACHINE_KEYRING, either.
> > >
> > > T
On Tue Sep 12, 2023 at 1:32 AM EEST, Justin M. Forbes wrote:
> Commit d2e8071bed0be ("tpm: make all 'class' structures const")
> unfortunately had a typo for the name on tpmrm.
>
> Fixes: d2e8071bed0b ("tpm: make all 'class' structures const")
> Signed-off-by: Justin M. Forbes
> ---
>
On Sat Sep 9, 2023 at 12:34 AM EEST, Eric Snowberg wrote:
> Currently root can dynamically update the blacklist keyring if the hash
> being added is signed and vouched for by the builtin trusted keyring.
> Currently keys in the secondary trusted keyring can not be used.
>
> Keys within the
On Mon Sep 11, 2023 at 4:29 PM EEST, Mimi Zohar wrote:
> Hi Eric,
>
> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> > Currently root can dynamically update the blacklist keyring if the hash
> > being added is signed and vouched for by the builtin trusted keyring.
> > Currently keys in
/char/tpm/tpm-chip.c
> @@ -33,7 +33,7 @@ const struct class tpm_class = {
> .shutdown_pre = tpm_class_shutdown,
> };
> const struct class tpmrm_class = {
> - .name = "tmprm",
> + .name = "tpmrm",
> };
> dev_t tpm_devt;
>
> --
> 2.41.0
Reviewed-by: Jarkko Sakkinen
Thanks, I'll queue this up for rc2.
BR, Jarkko
On Thu Sep 7, 2023 at 7:52 PM EEST, Michal Suchanek wrote:
> No other platform needs CA_MACHINE_KEYRING, either.
>
> This is policy that should be decided by the administrator, not Kconfig
s/administrator/distributor/ ?
> dependencies.
>
> cc: joeyli
> Signed-off-by: Michal Suchanek
> ---
>
memory
implementation to use only single invocation to register both key and blob
buffers.
[jarkko: Added cc to stable.]
Cc: sta...@vger.kernel.org # v5.16+
Fixes: 4615e5a34b95 ("optee: add FF-A support")
Reported-by: Jens Wiklander
Signed-off-by: Sumit Garg
On Tue Sep 5, 2023 at 3:01 PM EEST, Thorsten Leemhuis wrote:
> On 05.09.23 00:32, Jarkko Sakkinen wrote:
> > On Fri Sep 1, 2023 at 11:49 AM EEST, Thorsten Leemhuis wrote:
> >> On 29.08.23 10:38, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>> On 28.08.23
On Mon Sep 11, 2023 at 1:40 PM EEST, Jarkko Sakkinen wrote:
> Personally I think bugzilla, being user approachable system, should
> be better defined but *theoretically*, at least by the process, it
> can be fully ignored.
I.e. I don't think it should be ignored :-)
BR, Jarkko
his is somewhat fragile. What if struct trusted_key_payload has a
> > > > > > small
> > > > > > unexpected change in layout?
> > > > >
> > > > > key and blob buffers are just two adjacent fixed sized byte arrays. So
> > &
On Tue Sep 5, 2023 at 6:56 PM EEST, Casey Schaufler wrote:
> On 9/4/2023 2:08 PM, Jarkko Sakkinen wrote:
> > On Thu Aug 31, 2023 at 1:41 PM EEST, Roberto Sassu wrote:
> >> From: Roberto Sassu
> >>
> >> Add the idmap parameter to the definition, so that evm_in
On Fri, Apr 16, 2021 at 03:06:16PM +0800, Jisheng Zhang wrote:
> On Wed, 14 Apr 2021 16:12:23 +0300 Jarkko Sakkinen wrote:
>
>
> > > So kprobes ss ins slot page "must be in the range of relative branching
> > > only
> > > for x86 and arm"
>
On Wed, Apr 14, 2021 at 01:01:02PM +0200, Jethro Beekman wrote:
> On 2021-04-14 12:52, Jarkko Sakkinen wrote:
> > On Mon, Apr 12, 2021 at 10:59:56AM +0200, Raoul Strackx wrote:
> >> Creation of an SGX enclave consists of three steps. First, a new enclave
> >> environmen
Hi,
New features:
1. ARM TEE backend for kernel trusted keys to complete the existing TPM
backend.
2. ASN.1 format for TPM2 trusted keys to make them interact with the
user space stack, such as OpenConnect VPN.
Other than that, contains bunch of bug fixes.
/Jarkko
The following changes
On Wed, Apr 14, 2021 at 05:22:58PM +0900, Masami Hiramatsu wrote:
> Hi Jisheng,
>
> On Wed, 14 Apr 2021 15:27:28 +0800
> Jisheng Zhang wrote:
>
> \
> > >
> > > On Tue, 13 Apr 2021 18:03:24 +0800
> > > Jisheng Zhang wrote:
> > >
> > > > Use the __vmalloc_node_range() to simplify x86's
On Wed, Apr 14, 2021 at 03:27:28PM +0800, Jisheng Zhang wrote:
> Jisheng Zhang wrote:
>
> >
> >
> > Hi,
>
> Hi
>
> >
> > On Tue, 13 Apr 2021 18:03:24 +0800
> > Jisheng Zhang wrote:
> >
> > > Use the __vmalloc_node_range() to simplify x86's alloc_insn_page()
> > > implementation.
> >
t; Addresses-Coverity: ("Dereference null return value")
> Fixes: 830027e2cb55 ("KEYS: trusted: Add generic trusted keys framework")
> Signed-off-by: Colin Ian King
Reviewed-by: Jarkko Sakkinen
/Jarkko
On Mon, Apr 12, 2021 at 07:01:39PM +0200, Jethro Beekman wrote:
> On 2021-04-12 18:47, Dave Hansen wrote:
> > On 4/12/21 9:41 AM, Jethro Beekman wrote:
> >> Yes this still doesn't let one execute all possible ECREATE, EADD,
> >> EEXTEND, EINIT sequences.
> >
> > OK, so we're going in circles
On Mon, Apr 12, 2021 at 10:59:56AM +0200, Raoul Strackx wrote:
> Creation of an SGX enclave consists of three steps. First, a new enclave
> environment is created by the ECREATE leaf function. Some enclave settings
> are specified at this step by passing an SGX Enclave Control Structure
> (SECS)
> Signed-off-by: Zhihao Cheng
Reviewed-by: Jarkko Sakkinen
> ---
> drivers/char/tpm/tpm_tis_i2c_cr50.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/tpm/tpm_tis_i2c_cr50.c
> b/drivers/char/tpm/tpm_tis_i2c_cr50.c
> index ec9a65e7887d..f19c227d20f4
On Thu, Apr 08, 2021 at 07:26:08PM +0800, Zhihao Cheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 3a253caaad11 ("char: tpm: add i2c driver for cr50")
> Reported-by: Hulk Robot
> Signed-off-by: Zhihao
On Thu, Apr 08, 2021 at 11:32:23AM +0200, Borislav Petkov wrote:
> On Thu, Apr 08, 2021 at 12:13:21PM +0300, Jarkko Sakkinen wrote:
> > Actually I think read-only sysctl attributes would be a better idea.
>
> I still think debugfs is the right *start* for this: you play with t
The following commit has been merged into the x86/sgx branch of tip:
Commit-ID: ae40aaf6bdbf0354a75b8284a0de453fcf5f4d32
Gitweb:
https://git.kernel.org/tip/ae40aaf6bdbf0354a75b8284a0de453fcf5f4d32
Author:Jarkko Sakkinen
AuthorDate:Thu, 08 Apr 2021 12:29:24 +03:00
ast and it only prevented
ksgxd to trigger small time after the system had powered on.
Fixes: 51ab30eb2ad4 ("x86/sgx: Replace section->init_laundry_list with
sgx_dirty_page_list")
Signed-off-by: Jarkko Sakkinen
---
v2:
* Wrote more verbose and detailed description what is going on.
On Thu, Apr 08, 2021 at 10:56:40AM +0200, Borislav Petkov wrote:
> On Thu, Apr 08, 2021 at 11:48:46AM +0300, Jarkko Sakkinen wrote:
> > The regression is that the sgx_nr_free_pages is also incremented by
> > sgx_free_epc_pages(), and thus it ends up having double the number of
>
On Thu, Apr 08, 2021 at 11:52:40AM +0300, Jarkko Sakkinen wrote:
> On Wed, Apr 07, 2021 at 06:15:33PM +0200, Borislav Petkov wrote:
> > On Wed, Apr 07, 2021 at 07:09:11PM +0300, Jarkko Sakkinen wrote:
> > > I left out "epc" because they are already prefixed with &q
On Wed, Apr 07, 2021 at 06:15:33PM +0200, Borislav Petkov wrote:
> On Wed, Apr 07, 2021 at 07:09:11PM +0300, Jarkko Sakkinen wrote:
> > I left out "epc" because they are already prefixed with "sgx_".
>
> Are there any other "page" types which
101 - 200 of 8082 matches
Mail list logo
