On 5/23/25 08:54, Jarkko Sakkinen wrote:
>> +void sgx_dec_usage_count(void)
>> +{
>> +atomic64_dec(&sgx_usage_count);
>> +}
> I think these both should be static inlines in arch/x86/kernel/cpu/sgx.h.
> Global symbols is over the top. Even if I think disassembly (when doing
> debugging, bug hunt
On 5/20/25 12:57, Jarkko Sakkinen wrote:
> unlikely() is both (minor) optimization and documents that it is not expected
> branch so it obviously makes sense here.
I'm not a big fan of unlikely() being thrown in without specific
reasons. I don't think we need an annotation to tell us that the path
On 5/19/25 00:24, Elena Reshetova wrote:
> The SGX attestation architecture assumes a compromise
> of all running enclaves and cryptographic assets
> (like internal SGX encryption keys) whenever a microcode
> update affects SGX. To mitigate the impact of this presumed
> compromise, a new supervisor
that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.
But otherwise it looks great:
Acked-by: Dave Hansen
On 5/14/25 00:32, Reshetova, Elena wrote:
>> This was the recent discussion I am aware we had on this matter:
>> https://lkml.org/lkml/2024/2/5/1595
>> The measurements were done for older platform (skylake), but I am not
>> aware of any architectural changes since that time to improve this.
> And
On 5/8/25 07:07, Reshetova, Elena wrote:
...
>> Actually, I think I wrote changelogs for this once upon a time. Could
>> you please go dig those up and use them?
>
> Could you please suggest where can I find them? Was it for the previous
> submission done by Cathy?
Yes. There were also some long
On 5/7/25 04:14, Elena Reshetova wrote:
> In case an SGX vulnerability is discovered and TCB recovery
> for SGX is triggered, Intel specifies a process that must be
> followed for a given vulnerability. Steps to mitigate can vary
> based on vulnerability type, affected components, etc.
> In some ca
On 4/29/25 04:44, Reshetova, Elena wrote:
>> On 4/25/25 14:58, Sean Christopherson wrote:
>>> On Fri, Apr 25, 2025, Dave Hansen wrote:
>>>> On 4/25/25 14:04, Sean Christopherson wrote:
>>>>> Userspace is going to be waiting on ->release() no matter wh
On 4/25/25 14:58, Sean Christopherson wrote:
> On Fri, Apr 25, 2025, Dave Hansen wrote:
>> On 4/25/25 14:04, Sean Christopherson wrote:
>>> Userspace is going to be waiting on ->release() no matter what.
>> Unless it isn't even involved and it happens automatica
On 4/25/25 14:04, Sean Christopherson wrote:
> Userspace is going to be waiting on ->release() no matter what.
Unless it isn't even involved and it happens automatically.
On 4/25/25 12:29, Sean Christopherson wrote:
> --- a/arch/x86/kernel/cpu/sgx/virt.c
> +++ b/arch/x86/kernel/cpu/sgx/virt.c
> @@ -255,6 +255,7 @@ static int sgx_vepc_release(struct inode *inode, struct
> file *file)
> xa_destroy(&vepc->page_array);
> kfree(vepc);
>
> + sgx_dec_usa
On 4/25/25 10:40, Sean Christopherson wrote:
> So then why on earth is the kernel implementing automatic updates?
Because it's literally the least amount of code and doesn't create any
new ABI.
> I read back through most of the cover letters, and IIUC, we went
> straight from "destroy all enclave
On 4/9/25 09:55, Vladis Dronov wrote:
...
> Fix this by adding "-mno-avx" to ENCL_CFLAGS in Makefile. Add some comments
> about this to code locations where enclave's xfrm field is set.
>
> Suggested-by: Dave Hansen
> Signed-off-by: Vladis Dronov
First of all, th
On 3/4/25 14:56, Jarkko Sakkinen wrote:
> The total size calculated for EPC can overflow u64 given the added up page
> for SECS. Further, the total size calculated for shmem can overflow even
> when the EPC size stays within limits of u64, given that it adds the extra
> space for 128 byte PCMD str
On 2/20/25 13:16, Vishal Annapurve wrote:
> Direct HLT instruction execution causes #VEs for TDX VMs which is routed
> to hypervisor via TDCALL. safe_halt() routines execute HLT in STI-shadow
> so IRQs need to remain disabled until the TDCALL to ensure that pending
> IRQs are correctly treated as w
On 2/20/25 13:16, Vishal Annapurve wrote:
> Since enabling CONFIG_PARAVIRT_XXL is too bloated for TDX guest
> like platforms, move HLT and SAFE_HLT paravirt calls under
> CONFIG_PARAVIRT.
I guess it's just one patch, but doesn't this expose CONFIG_PARAVIRT=y
users to what _was_ specific to CONFIG_
On 2/13/25 00:04, John Hubbard wrote:
>
> 2) I'm unable to reproduce what you saw, because in ALL cases (before
> or after the commit, and with or without a revert), I get the same
> results on my Intel test machine:
>
> $ ./protection_keys_64
> has pkeys: 0
> running PKEY tests for u
Hi John,
On 6/13/24 19:30, John Hubbard wrote:
> --- a/tools/testing/selftests/mm/protection_keys.c
> +++ b/tools/testing/selftests/mm/protection_keys.c
> @@ -42,7 +42,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
I'm not quite sure how but this b
On 2/11/25 16:32, andrzej zaborowski wrote:
>> Actually, now that I think about it even more, why would ETRACK or
>> EBLOCK access the page itself? They seem superficially like they'd be
>> metadata-only too.
> I haven't seen a crash in either of these (always in EWB), I didn't
> want to imply that
On 2/11/25 13:18, Huang, Kai wrote:
>>> This requires low-level SGX implementation knowledge to fully
>>> understand. Both what "ETRACK, EBLOCK and EWB" are in the first place,
>>> how they are involved in reclaim and also why EREMOVE doesn't lead to
>>> the same fate.
>>
>> Does it? [I'll dig up I
I don't expect everyone to know the rules of every little part of the
kernel. But, it's really easy to see a pattern with:
git log arch/x86/kernel/cpu/sgx/
That usually works for every little nook and cranny of the kernel and
will show you what the subject rules are.
Could you do that fo
On 1/24/25 12:17, Maciej Wieczor-Retman wrote:
>> Could you poke around and see if there is any existing ABI that we can
>> use to query LA57 support? Maybe one of the things KVM exports, or some
>> TASK_SIZE_MAX comparisons?
> Sure, I'll try to find some other way.
>
> My previous tactic was to m
On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
...
> + switch (test->later) {
> + case GET_USER_USER:
> + /* Control group - properly tagger user pointer */
> + ptr = (void *)set_metadata((uint64_t)ptr, test->lam);
> + break;
s/tagger/tagged/ ?
> +
On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
> +static inline int kernel_has_lam(void)
> +{
> + unsigned long bits;
> +
> + syscall(SYS_arch_prctl, ARCH_GET_MAX_TAG_BITS, &bits);
> + return !!bits;
> +}
Generally, I'm less picky about selftest/ code than in-kernel code. But
people r
On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
> -/* Check 5-level page table feature in CPUID.(EAX=07H, ECX=00H):ECX.[bit 16]
> */
> static inline int cpu_has_la57(void)
> {
> - unsigned int cpuinfo[4];
> -
> - __cpuid_count(0x7, 0, cpuinfo[0], cpuinfo[1], cpuinfo[2], cpuinfo[3]);
> -
On 9/5/24 07:24, Jarkko Sakkinen wrote:
>> +for_each_online_node(nid) {
>> +if (!node_isset(nid, sgx_numa_mask) &&
>> +node_state(nid, N_MEMORY) && node_state(nid, N_CPU))
>> +pr_info("node%d has both CPUs and memory but doesn't
>> have an EPC se
On 8/29/24 23:02, Aaron Lu wrote:
>> Also, I do think we should probably add some kind of sanity warning to
>> the SGX code in another patch. If a node on an SGX system has CPUs and
>> memory, it's very likely it will also have some EPC. It can be
>> something soft like a pr_info(), but I think i
n *a* node that has SGX
memory. This avoids the deadlock looking for the current SGX-
lacking node to show up in the loop when it never will.
The code looks fine, so feel free to add:
Acked-by: Dave Hansen
Also, I do think we should probably add some kind of sanity warning to
On 7/3/24 16:35, Tim Merrifield wrote:
> VMCALL and VMMCALL instructions are used by x86 guests to request services
> from the host VMM. Both VMCALL and VMMCALL are not restricted to CPL 0.
> This allows userspace software like open-vm-tools to communicate directly
> with the VMM.
Could we please
On 6/3/24 11:42, Haitao Huang wrote:
>> Second, convince me that this _needs_ a new bit. Why can't we just have
>> a bit that effectively means "return EBUSY if you see this bit when
>> handling a fault".
>
> IIUC, reclaimer_writing_to_pcmd() also uses
> SGX_ENCL_PAGE_BEING_RECLAIMED to check if
On 5/17/24 04:06, Dmitrii Kuvaiskii wrote:
...
First, why is SGX so special here? How is the SGX problem different
than what the core mm code does?
> --- a/arch/x86/kernel/cpu/sgx/encl.h
> +++ b/arch/x86/kernel/cpu/sgx/encl.h
> @@ -25,6 +25,9 @@
> /* 'desc' bit marking that the page is being re
On 5/17/24 04:06, Dmitrii Kuvaiskii wrote:
> We wrote a trivial stress test to reproduce the hangs observed in
> real-world applications. The test stresses #PF-based page allocation and
> SGX_IOC_ENCLAVE_REMOVE_PAGES flows in the SGX driver:
This seems like something we'd want in the kernel SGX se
On 5/23/24 11:39, Jürgen Groß wrote:
>>
>> Let's just keep it simple. How about the attached patch?
>
> Simple indeed. The attachment is empty. 😛
Let's try this again.diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 5358d43886ad..c193c9e60a1b 100644
--- a/arch/x86/kerne
On 5/16/24 06:02, Chen Yu wrote:
> Performance drop is reported when running encode/decode workload and
> BenchSEE cache sub-workload.
> Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused
> native_pv_lock_init() function warning"). When CONFIG_PARAVIRT_SPINLOCKS
> is disabled the v
On 5/15/24 06:54, Jarkko Sakkinen wrote:
> I'd cut out 90% of the description out and just make the argument of
> the wrong error code, and done. The sequence is great for showing
> how this could happen. The prose makes my head hurt tbh.
The changelog is too long, but not fatally so. I'd much ra
On 5/10/24 12:06, Dongli Zhang wrote:
> } else {
> + /*
> + * This call borrows from the comments and implementation
> + * of apic_update_vector(): "If the target CPU is offline
> + * then the regular release mechanism via the cleanup
> +
On 4/26/24 07:18, Bojun Zhu wrote:
> for (c = 0 ; c < modp->length; c += PAGE_SIZE) {
> + if (sgx_check_signal_and_resched()) {
> + if (!c)
> + ret = -ERESTARTSYS;
> +
> + goto out;
> + }
This constru
On 4/16/24 07:15, Jarkko Sakkinen wrote:
> On Tue Apr 16, 2024 at 8:42 AM EEST, Huang, Kai wrote:
> Yes, exactly. I'd take one week break and cycle the kselftest part
> internally a bit as I said my previous response. I'm sure that there
> is experise inside Intel how to implement it properly. I.e.
On 3/30/24 04:23, Jarkko Sakkinen wrote:
>>> I also wonder is cgroup-tools dependency absolutely required or could
>>> you just have a function that would interact with sysfs?
>> I should have checked email before hit the send button for v10 🙂.
>>
>> It'd be more complicated and less readable to do
On 2/26/24 14:34, Huang, Kai wrote:
> So I am trying to get the actual downside of doing per-cgroup reclaim or
> the full reason that we choose global reclaim.
Take the most extreme example:
while (hit_global_sgx_limit())
reclaim_from_this(cgroup);
You eventually end up w
On 2/26/24 14:24, Huang, Kai wrote:
> What is the downside of doing per-group reclaim when try_charge()
> succeeds for the enclave but failed to allocate EPC page?
>
> Could you give an complete answer why you choose to use global reclaim
> for the above case?
There are literally two different li
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 system has exceeded
> the capacity, whether we do global reclaim
On 2/26/24 03:36, Huang, Kai wrote:
>> In case of overcomitting, even if we always reclaim from the same cgroup
>> for each fault, one group may still interfere the other: e.g., consider an
>> extreme case in that group A used up almost all EPC at the time group B
>> has a fault, B has to fai
On 2/19/24 07:39, Haitao Huang wrote:
> Remove all boolean parameters for 'reclaim' from the function
> sgx_alloc_epc_page() and its callers by making two versions of each
> function.
>
> Also opportunistically remove non-static declaration of
> __sgx_alloc_epc_page() and a typo
>
> Signed-off-by
On 2/16/24 13:38, Haitao Huang wrote:
> On Fri, 16 Feb 2024 09:15:59 -0600, Dave Hansen
> wrote:
...
>> Does this 'indirect' change any behavior other than whether it does a
>> search for an mm to find a place to charge the backing storage?
>
> No.
>
>>
On 2/5/24 13:06, Haitao Huang wrote:
> @@ -414,7 +416,7 @@ static void sgx_reclaim_pages_global(void)
> void sgx_reclaim_direct(void)
> {
> if (sgx_should_reclaim(SGX_NR_LOW_PAGES))
> - sgx_reclaim_pages_global();
> + sgx_reclaim_pages_global(false);
> }
>
> stat
On 2/5/24 13:06, Haitao Huang wrote:
> static struct mem_cgroup *sgx_encl_get_mem_cgroup(struct sgx_encl *encl)
> {
> @@ -1003,14 +1001,6 @@ static struct mem_cgroup
> *sgx_encl_get_mem_cgroup(struct sgx_encl *encl)
> struct sgx_encl_mm *encl_mm;
> int idx;
>
> - /*
> - *
There's very little about how the LRU design came to be in this cover
letter. Let's add some details.
How's this?
Writing this up, I'm a lot more convinced that this series is, in
general, taking the right approach. I honestly don't see any other
alternatives. As much as I'd love to do somethi
On 10/30/23 11:20, Haitao Huang wrote:
> @@ -527,16 +530,13 @@ void sgx_mark_page_reclaimable(struct sgx_epc_page
> *page)
> int sgx_unmark_page_reclaimable(struct sgx_epc_page *page)
> {
> spin_lock(&sgx_global_lru.lock);
> - if (page->flags & SGX_EPC_PAGE_RECLAIMER_TRACKED) {
> -
On 1/4/24 11:11, Haitao Huang wrote:
> If those are OK with users and also make it acceptable for merge
> quickly, I'm happy to do that 🙂
How about we put some actual numbers behind this? How much complexity
are we talking about here? What's the diffstat for the utterly
bare-bones implementation
On 12/18/23 13:24, Haitao Huang wrote:> @Dave and @Michal, Your
thoughts? Or could you confirm we should not
> do reclaim per cgroup at all?
What's the benefit of doing reclaim per cgroup? Is that worth the extra
complexity?
The key question here is whether we want the SGX VM to be complex and
mo
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 anything, and please let me know if there's
> something on my end t
On 10/18/23 08:26, Haitao Huang wrote:
> Maybe not in sense of killing something. My understanding memory.reclaim
> does not necessarily invoke the OOM killer. But what I really intend to
> say is we can have a separate knob for user to express the need for
> reducing the current usage explicitly a
On 10/17/23 21:37, Haitao Huang wrote:
> Yes we can introduce misc.reclaim to give user a knob to forcefully
> reducing usage if that is really needed in real usage. The semantics
> would make force-kill VMs explicit to user.
Do any other controllers do something like this? It seems odd.
On 9/28/23 16:08, Reinette Chatre wrote:
> I'd like to check in on the status of this patch. This two month old
> patch looks to be a needed fix and has Jarkko and Kai's review tags,
> but I am not able to find it queued or merged in tip or upstream.
> Apologies if I did not look in the right spot,
On 9/14/23 03:31, Huang, Kai wrote:
>> Signed-off-by: Haitao Huang
>> Cc: Sean Christopherson
> You don't need 'Cc:' Sean if the patch has Sean's SoB.
It is a SoB for Sean's @intel address and cc's his @google address.
It is fine.
On 9/11/23 11:27, Justin Stitt wrote:
> `strncpy` is deprecated and we should prefer more robust string apis.
I dunno. It actually seems like a pretty good fit here.
> In this case, `message.str` is not expected to be NUL-terminated as it
> is simply a buffer of characters residing in a union wh
*
> + * Returns 0 on success or negative error code on a failure to perform
> + * the cache maintenance.
> + */
WBINVD is a scary beast. But, there's also no better alternative in the
architecture. I don't think any of my comments above are deal breakers,
so from the x86 side:
Acked-by: Dave Hansen
On 4/20/21 4:12 PM, Kuppuswamy, Sathyanarayanan wrote:
> On 4/20/21 12:59 PM, Dave Hansen wrote:
>> On 4/20/21 12:20 PM, Kuppuswamy, Sathyanarayanan wrote:
>>>>> approach is, it adds a few extra instructions for every
>>>>> TDCALL use case when compared to di
On 4/20/21 12:20 PM, Kuppuswamy, Sathyanarayanan wrote:
>>> approach is, it adds a few extra instructions for every
>>> TDCALL use case when compared to distributed checks. Although
>>> it's a bit less efficient, it's worth it to make the code more
>>> readable.
>>
>> What's a "distributed check"?
On 3/26/21 4:38 PM, Kuppuswamy Sathyanarayanan wrote:
> Implement common helper functions to communicate with
> the TDX Module and VMM (using TDCALL instruction).
This is missing any kind of background. I'd say:
Guests communicate with VMMs with hypercalls. Historically, these are
implemented us
On 4/19/21 11:10 AM, Andy Lutomirski wrote:
> I’m confused by this scenario. This should only affect physical pages
> that are in the 2M area that contains guest memory. But, if we have a
> 2M direct map PMD entry that contains kernel data and guest private
> memory, we’re already in a situation in
On 4/19/21 10:46 AM, Brijesh Singh wrote:
> - guest wants to make gpa 0x1000 as a shared page. To support this, we
> need to psmash the large RMP entry into 512 4K entries. The psmash
> instruction breaks the large RMP entry into 512 4K entries without
> affecting the previous validation. Now the w
On 4/16/21 8:40 AM, Kirill A. Shutemov wrote:
> /*
> - * If SME is active, the trampoline area will need to be in
> - * decrypted memory in order to bring up other processors
> + * If SME or KVM memory protection is active, the trampoline area will
> + * need to be in decr
On 4/16/21 8:40 AM, Kirill A. Shutemov wrote:
> Mirror SEV, use SWIOTLB always if KVM memory protection is enabled.
...
> arch/x86/mm/mem_encrypt.c | 44 ---
> arch/x86/mm/mem_encrypt_common.c | 48 ++
The changelog need to at least me
On 4/16/21 5:35 AM, Michal Hocko wrote:
> I have to confess that I haven't grasped the initialization
> completely. There is a nice comment explaining a 2 socket system with
> 3 different NUMA nodes attached to it with one node being terminal.
> This is OK if the terminal node is PMEM but h
On 4/15/21 9:24 AM, Andy Lutomirski wrote:
> In the patches, *as submitted*, if you trip the XFD #NM *once* and you
> are the only thread on the system to do so, you will eat the cost of a
> WRMSR on every subsequent context switch.
I think you're saying: If a thread trips XFD #NM *once*, every sw
On 4/14/21 9:07 PM, Wei Xu wrote:
> On Wed, Apr 14, 2021 at 1:08 AM Oscar Salvador wrote:
>> Fast class/memory are pictured as those nodes with CPUs, while Slow
>> class/memory
>> are PMEM, right?
>> Then, what stands for medium class/memory?
>
> That is Dave's example. I think David's guess ma
On 4/14/21 8:51 AM, Sean Christopherson wrote:
>> Could this access to and kfree of encl_mm possibly be after the
>> kfree(encl_mm) noted above?
> No, the mmu_notifier_unregister() ensures that all in-progress notifiers
> complete
> before it returns, i.e. SGX's notifier call back is not reachable
On 3/1/21 11:51 PM, Bard Liao wrote:
> +++ b/drivers/soundwire/dmi-quirks.c
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +// Copyright(c) 2021 Intel Corporation.
It looks like this is already in intel-next, so this may be moot. But,
is there a specific reason this
On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote:
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) Intel Corporation. All rights reserved.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/misc/intel,keembay-xlink.yaml#";
> +$schema: "http://devicetree.org/meta-sc
On 4/12/21 8:58 AM, Jethro Beekman wrote:
> On 2021-04-12 17:36, Dave Hansen wrote:
>> On 4/12/21 1:59 AM, Raoul Strackx wrote:
>>> This patch set adds a new ioctl to enable userspace to execute EEXTEND
>>> leaf functions per 256 bytes of enclave memory. With this patch
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 now.
I don't believe we necessarily *WANT* or need Linux to support "all
possible ECREATE, EADD, EEXTEND, EINIT sequences". Ye
On 4/12/21 1:59 AM, Raoul Strackx wrote:
> This patch set adds a new ioctl to enable userspace to execute EEXTEND
> leaf functions per 256 bytes of enclave memory. With this patch in place,
> Linux will be able to build all valid SGXv1 enclaves.
This didn't cover why we need a *NEW* ABI for this i
On 4/8/21 11:17 AM, Oscar Salvador wrote:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -8490,7 +8490,8 @@ static int __alloc_contig_migrate_range(struct
> compact_control *cc,
> cc->nr_migratepages -= nr_reclaimed;
>
> ret = migrate_pages(&cc->migratepages, all
On 4/8/21 1:26 AM, Oscar Salvador wrote:
> On Thu, Apr 01, 2021 at 11:32:19AM -0700, Dave Hansen wrote:
>> The protocol for node_demotion[] access and writing is not
>> standard. It has no specific locking and is intended to be read
>> locklessly. Readers must take ca
On 4/8/21 1:03 AM, Oscar Salvador wrote:
> I think this patch and patch#2 could be squashed
>
> Reviewed-by: Oscar Salvador
Yeah, that makes a lot of sense. I'll do that for the next version.
On 4/8/21 8:27 AM, Jethro Beekman wrote:
> But the native “executable format” for SGX is very clearly defined in
> the Intel SDM as a specific sequence of ECREATE, EADD, EEXTEND and
> EINIT calls. It's that sequence that's used for loading the enclave
> and it's that sequence that's used for code
On 4/6/21 9:31 AM, Kirill A. Shutemov wrote:
> On Thu, Apr 01, 2021 at 02:01:15PM -0700, Dave Hansen wrote:
>>> @@ -1977,8 +1978,8 @@ static int __set_memory_enc_dec(unsigned long addr,
>>> int numpages, bool enc)
>>> struct cpa_data cpa;
>>> int
On 4/6/21 9:00 AM, Kirill A. Shutemov wrote:
>>> --- a/arch/x86/mm/ioremap.c
>>> +++ b/arch/x86/mm/ioremap.c
>>> @@ -87,12 +87,12 @@ static unsigned int __ioremap_check_ram(struct resource
>>> *res)
>>> }
>>>
>>> /*
>>> - * In a SEV guest, NONE and RESERVED should not be mapped encrypted becau
On 4/6/21 8:54 AM, Kirill A. Shutemov wrote:
> On Thu, Apr 01, 2021 at 01:13:16PM -0700, Dave Hansen wrote:
>>> @@ -56,6 +61,9 @@ static void tdx_get_info(void)
>>>
>>> td_info.gpa_width = rcx & GENMASK(5, 0);
>>> td_info.attributes = rdx;
&
On 4/6/21 8:37 AM, Kirill A. Shutemov wrote:
> On Thu, Apr 01, 2021 at 01:06:29PM -0700, Dave Hansen wrote:
>> On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
>>> From: "Kirill A. Shutemov"
>>>
>>> Intel TDX doesn't allow VMM to acces
On 4/6/21 12:44 AM, David Hildenbrand wrote:
> On 02.04.21 17:26, Kirill A. Shutemov wrote:
>> TDX architecture aims to provide resiliency against confidentiality and
>> integrity attacks. Towards this goal, the TDX architecture helps enforce
>> the enabling of memory integrity for all TD-private m
On 4/5/21 1:37 PM, Rick Edgecombe wrote:
> +static void __dispose_pages(struct list_head *head)
> +{
> + struct list_head *cur, *next;
> +
> + list_for_each_safe(cur, next, head) {
> + list_del(cur);
> +
> + /* The list head is stored at the start of the page */
> +
It occurred to me that I've been doing a lot of digging in the TDX spec
lately. I think we can all agree that the "Architecture Specification"
is not the world's easiest, most disgestable reading. It's hard to
figure out what the Linux relation to the spec is.
One bit of Documentation we need fo
On 4/2/21 2:32 PM, Andi Kleen wrote:
>> If we go this route, what are the rules and restrictions? Do we have to
>> say "no MMIO in #VE"?
>
> All we have to say is "No MMIO in #VE before getting thd TDVEINFO arguments"
> After that it can nest without problems.
Well, not exactly. You still can't
On 4/2/21 1:20 PM, Jethro Beekman wrote:
> On 2021-04-02 21:50, Dave Hansen wrote:
>> Again, how does this save space?
>>
>> Are you literally talking about the temporary cost of allocating *one* page?
>
> No I'm talking about the amount of disk space/network tr
On 4/2/21 12:38 PM, Jethro Beekman wrote:
> On 2021-04-02 20:42, Dave Hansen wrote:
>> On 4/2/21 11:31 AM, Jethro Beekman wrote:
>>> On 2021-04-02 17:53, Dave Hansen wrote:
>>>> But, why would an enclave loader application ever do this?
>>>
>>> e.
On 4/2/21 11:31 AM, Jethro Beekman wrote:
> On 2021-04-02 17:53, Dave Hansen wrote:
>> On 4/2/21 1:38 AM, Jethro Beekman wrote:
>>>> So, we're talking here about pages that have been EEADDED, but for
>>>> which we do not want to include the entire conten
On 4/2/21 1:38 AM, Jethro Beekman wrote:
>> So, we're talking here about pages that have been EEADDED, but for
>> which we do not want to include the entire contents of the page?
>> Do these contents always include the beginning of the page, or can
>> the holes be anywhere?
> Holes can be anywhere,
On 4/1/21 7:48 PM, Andi Kleen wrote:
>> I've heard things like "we need to harden the drivers" or "we need to do
>> audits" and that drivers might be "whitelisted".
>
> The basic driver allow listing patches are already in the repository,
> but not currently posted or complete:
>
> https://github
On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
> Intel's Trust Domain Extensions (TDX) protect guest VMs from malicious
> hosts and some physical attacks. This series adds the bare-minimum
> support to run a TDX guest. The host-side support will be submitted
> separately. Also support for adv
On 4/1/21 3:35 PM, Wei Xu wrote:
> A small suggestion: Given that migrate_pages() requires that
> *nr_succeeded should be initialized to 0 when it is called due to its
> use of *nr_succeeded in count_vm_events() and trace_mm_migrate_pages(),
> it would be less error-prone if migrate_pages() initial
On 4/1/21 1:01 PM, Yang Shi wrote:
> On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen
> wrote:
>>
>>
>> From: Dave Hansen
>>
>> This is mostly derived from a patch from Yang Shi:
>>
>>
>> https://lore.kernel.org/linux-mm/15604685
On 4/1/21 3:26 PM, Sean Christopherson wrote:
> On Thu, Apr 01, 2021, Dave Hansen wrote:
>> On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
>>> From: "Kirill A. Shutemov"
>>>
>>> Handle #VE due to MMIO operations. MMIO triggers #VE with EPT_VIOL
On 4/1/21 2:15 PM, Kuppuswamy, Sathyanarayanan wrote:
> On 4/1/21 2:08 PM, Dave Hansen wrote:
>> On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
>>> +bool is_tdx_guest(void)
>>> +{
>>> + return static_cpu_has(X86_FEATURE_TDX_GUEST);
>>> +}
>&
On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
> From: "Kirill A. Shutemov"
>
> TDX doesn't allow to perform DMA access to guest private memory.
> In order for DMA to work properly in TD guest, user SWIOTLB bounce
> buffers.
>
> Move AMD SEV initialization into common code and adopt for TD
On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
> +bool is_tdx_guest(void)
> +{
> + return static_cpu_has(X86_FEATURE_TDX_GUEST);
> +}
Why do you need is_tdx_guest() as opposed to calling
cpu_feature_enabled(X86_FEATURE_TDX_GUEST) everywhere?
> +int tdx_map_gpa(phys_addr_t gpa, int numpages, bool private)
> +{
> + int ret, i;
> +
> + ret = __tdx_map_gpa(gpa, numpages, private);
> + if (ret || !private)
> + return ret;
> +
> + for (i = 0; i < numpages; i++)
> + tdx_accept_page(gpa + i*PAGE_SIZE);
>
On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
> From: "Kirill A. Shutemov"
>
> All ioremap()ed paged that are not backed by normal memory (NONE or
> RESERVED) have to be mapped as shared.
s/paged/pages/
> +/* Make the page accesable by VMM */
> +#define pgprot_tdx_shared(prot) __pgprot(
1 - 100 of 2995 matches
Mail list logo
