Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

49 participants
6027 discussions

by Chong Criston

3 days, 9 hours

mini dachshund puppies for sale

by Chong Criston

3 days, 9 hours

dachshund puppies for sale texas

by Chong Criston

3 days, 9 hours

Re: [PATCH net-next v3 2/2] dma-buf: heaps: system: add system_cc_decrypted heap for explicitly decrypted memory

by Jason Gunthorpe

On Mon, Mar 09, 2026 at 09:39:44AM -0600, Peter Gonda wrote: > Great feature to have thanks Jiri! A couple naive questions. > > On Thu, Mar 5, 2026 at 5:38 AM Jiri Pirko <jiri(a)resnulli.us> wrote: > > > > From: Jiri Pirko <jiri(a)nvidia.com> > > > > Add a new "system_cc_decrypted" dma-buf heap to allow userspace to > > allocate decrypted (shared) memory for confidential computing (CoCo) > > VMs. > > > > On CoCo VMs, guest memory is encrypted by default. The hardware uses an > > encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on > > Intel TDX) to control whether a given memory access is encrypted or > > decrypted. The kernel's direct map is set up with encryption enabled, > > so pages returned by alloc_pages() are encrypted in the direct map > > by default. To make this memory usable for devices that do not support > > DMA to encrypted memory (no TDISP support), it has to be explicitly > > decrypted. A couple of things are needed to properly handle > > decrypted memory for the dma-buf use case: > > > > - set_memory_decrypted() on the direct map after allocation: > > Besides clearing the encryption bit in the direct map PTEs, this > > also notifies the hypervisor about the page state change. On free, > > the inverse set_memory_encrypted() must be called before returning > > pages to the allocator. If re-encryption fails, pages > > are intentionally leaked to prevent decrypted memory from being > > reused as private. > > > > - pgprot_decrypted() for userspace and kernel virtual mappings: > > Any new mapping of the decrypted pages, be it to userspace via > > mmap or to kernel vmalloc space via vmap, creates PTEs independent > > of the direct map. These must also have the encryption bit cleared, > > otherwise accesses through them would see encrypted (garbage) data. > > So this only works on new mappings? What if there are existing > mappings to the memory that will be converted to shared? The set_memory_decrypted() is called during system_heap_allocate(), it is not possible to change dynamically between encrypted/decrypted. Once the heap is created every PTE is always created with the correct pgprot. Jason

3 days, 14 hours

Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory

by Leon Romanovsky

On Thu, Mar 05, 2026 at 01:36:40PM +0100, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > Current CC designs don't place a vIOMMU in front of untrusted devices. > Instead, the DMA API forces all untrusted device DMA through swiotlb > bounce buffers (is_swiotlb_force_bounce()) which copies data into > decrypted memory on behalf of the device. > > When a caller has already arranged for the memory to be decrypted > via set_memory_decrypted(), the DMA API needs to know so it can map > directly using the unencrypted physical address rather than bounce > buffering. Following the pattern of DMA_ATTR_MMIO, add > DMA_ATTR_CC_DECRYPTED for this purpose. Like the MMIO case, only the > caller knows what kind of memory it has and must inform the DMA API > for it to work correctly. > > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> > --- > v1->v2: > - rebased on top of recent dma-mapping-fixes > --- > include/linux/dma-mapping.h | 6 ++++++ > include/trace/events/dma.h | 3 ++- > kernel/dma/direct.h | 14 +++++++++++--- > 3 files changed, 19 insertions(+), 4 deletions(-) > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index 29973baa0581..ae3d85e494ec 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -85,6 +85,12 @@ > * a cacheline must have this attribute for this to be considered safe. > */ > #define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11) > +/* > + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted > + * (shared) for confidential computing guests. The caller must have > + * called set_memory_decrypted(). A struct page is required. > + */ > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12) While adding the new attribute is fine, I would expect additional checks in dma_map_phys() to ensure the attribute cannot be misused. For example, WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check that we are taking the direct path only. Thanks

3 days, 14 hours

Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory

by Jason Gunthorpe

On Mon, Mar 09, 2026 at 01:56:10PM +0100, Petr Tesarik wrote: > I don't want to start a bikeshedding discussion, so if everyone else > likes this name, let's keep it. But maybe the "_CC" (meaning > Confidential Comptuing) is not necessary. IIUC it's the same concept as > set_page_encrypted(), set_page_decrypted(), which does not refer to > CoCo either. Frankly I hate that AMD got their "encrypted" "decrypted" naming baked into the CC related APIs. I'm not at all convinced that they "do not refer to CoCo" in the way Linux uses them and other arches absolutely make them 100% tied to coco. If we are going to bikeshed the name it should be DMA_ATTR_CC_SHARED Jason

3 days, 16 hours

Cryptera Chain Signals Is A Legit Company

by hamtonbecky＠gmail.com

In the complex and often unpredictable world of cryptocurrency where security challenges and asset losses occur frequently Cryptera Chain Signals CCS has established itself as a trusted professional service provider dedicated to supporting individuals and organizations facing digital asset difficulties The company has developed a solid reputation through consistent focus on transparency technical precision and ethical standards in an industry where many operations face skepticism Cryptera Chain Signals was established with the primary goal of offering specialized assistance in cryptocurrency recovery and blockchain forensics Drawing from extensive backgrounds in cybersecurity digital investigations and financial analysis the team applies proven methodologies to help clients address issues such as lost wallet access stolen funds and scam related losses The firm operates with a clear commitment to client education and realistic expectations ensuring that every case begins with a thorough assessment of possibilities rather than empty promises What the company does centers on several core areas of expertise Cryptera Chain Signals provides advanced blockchain tracing services that allow for detailed mapping of transaction flows across public ledgers Using sophisticated clustering algorithms and analysis tools they follow the movement of funds even after they have passed through multiple addresses mixers or bridges This capability proves essential for victims of phishing attacks investment scams or unauthorized transfers as it generates actionable reports that can support interactions with law enforcement agencies and regulated exchanges In addition to tracing Cryptera Chain Signals offers technical support for wallet recovery scenarios These include cases involving forgotten seed phrases damaged hardware devices or corrupted software files The experts guide clients through secure restoration processes without ever requesting full private keys or sensitive credentials upfront Their approach incorporates non destructive data extraction techniques and emphasizes prevention strategies to help clients strengthen future security measures The company also assists with scam recovery by preparing comprehensive documentation and evidence packages tailored for legal proceedings or platform interventions Cryptera Chain Signals maintains strict confidentiality protocols and avoids common industry pitfalls such as demanding large cryptocurrency payments in advance or guaranteeing impossible outcomes This disciplined method has contributed to their credibility among those who have conducted independent research into recovery services Throughout their operations Cryptera Chain Signals CCS prioritizes collaboration with clients providing regular updates and clear explanations of technical concepts in accessible language The firm works on a case by case basis evaluating factors such as the type of blockchain involved the timing of the incident and the feasibility of intervention By focusing on evidence based strategies rather than hype they help clients make informed decisions about pursuing recovery options or focusing on prevention Client testimonies provide valuable insight into the practical impact of Cryptera Chain Signals work One individual from the United Kingdom shared how the company assisted after a major hardware wallet failure I had tried multiple diy approaches without success but the team at Cryptera Chain Signals used forensic methods to extract and restore access safely Their patience and detailed guidance turned a potentially permanent loss into a successful recovery Another client from Canada described their experience following a sophisticated investment scam After losing substantial funds the tracing service mapped the entire transaction path allowing coordination with an exchange for a partial asset freeze The professional reports and ongoing support made the entire process far less overwhelming and gave me a clear path forward when I felt completely lost A third testimonial comes from an Australian business owner who faced a phishing attack that compromised company wallets Cryptera Chain Signals delivered a full forensic analysis within days which proved instrumental in filing reports with authorities Their realistic assessment helped us recover a meaningful portion of the assets and more importantly taught us critical lessons about security that we now apply across our operations These accounts along with many others reflect recurring themes of technical competence honest communication and tangible support even in cases where complete recovery was not possible Clients frequently highlight the absence of pressure tactics and the emphasis on long term asset protection as distinguishing factors The legitimacy of Cryptera Chain Signals is further reinforced by their professional online presence clear service structure and consistent adherence to ethical guidelines In a field where advance fee frauds and unrealistic claims remain prevalent the company stands out by maintaining transparent processes and focusing on education rather than sensational marketing Their track record of handling diverse cases with discretion and expertise has earned recognition from those seeking reliable assistance In conclusion Cryptera Chain Signals CCS continues to demonstrate why it is regarded as a legitimate and professional option for cryptocurrency recovery and blockchain investigations By combining deep technical knowledge with a client first philosophy the company provides meaningful value in situations that often feel hopeless For anyone dealing with lost or stolen digital assets exploring their services may offer the clarity and guidance needed to move forward For more information or to schedule a confidential consultation visit the official website at https://www.crypterachainsignals.com or send an email to info(a)crypterachainsignals.com

3 days, 22 hours

Best Loan Offer For Your Business. WhatsApp: +447401473736

by myowntime26＠gmail.com

Best Loan Offer For Your Business. WhatsApp: +447401473736 Hello Mr. or Ms. This message is for individuals, for anyone in need of a personal loan to boost their business or rebuild their life . Are you looking for a loan to either restart your business, finance a project, or buy an apartment, but you are blacklisted by the bank or your application has been rejected? I am a private lender offering loans ranging from $10,000 to $8,000,000 to anyone able to meet the conditions, and an affordable interest rate of just 2%, we’re here to help you make your goals a reality. Looking for a Fast and Flexible Loan? 🌟 Whether it’s for personal needs, a big investment, or expanding your business, we’ve got you covered! Types of Loans We Offer: Personal Loans 💸 Investment & Real Estate Loans 🏡 House Renovation Loans 🔨 Charity & Community Support Loans ❤️ Debt Consolidation Loans 💳 Business Expansion Loans 📈 Student Loans 🎓 Car Loans 🚗 For a fast response and seamless service, contact us directly and Let us know the amount you need and your preferred repayment period, and we’ll get back to you in no time! Your financial solution is just an email away. We look forward to helping you achieve your dreams! Contact me for more information: Telegram: @Ranko3222 WhatsApp📞: +447401473736 https://toprapidsolution.blogspot.com/

4 days, 6 hours

Gold Available For Sale, We Offer The Best For You +447401473736

by myowntime26＠gmail.com

Gold Available For Sale, We Offer The Best For You +447401473736 Gold for Sale in USA, Kampala Uganda, Canada, Australia, Europe. No hidden payments and no payments upfront if you are a serious buyer. We do CIF to our serious buyers without delays or FOB to those more serious buyers who want to come to Uganda for a pick up. We recommend our good buyers to fly to uganda and do the testing and visit our mining sites and do a due diligence for more trust and long term business 24 Karat, 98+ Purity Gold Wholesale supplier. Gold world is a leading global supplier and trader of an extensive range of 24 Karat Gold. Our sales team is committed to providing impeccable services to our clients, and they are always ready to answer your questions. Smooth Delivery on Time Worldwide Along with the best quality of our 24 Karat Gold, we take care of the packaging process as well. We always involve high-technique packaging system which provide barrier protection against moisture, dust, or any kind of mechanical damage during transportation. Not only this, we perform smooth delivery of our 24 Karat Gold within the given date and time. Our entire gold product is delivered in 3–7 days by courier worldwide CONTACT: Telegram: @Ranko3222 WhatsApp📞: +447401473736 https://toprapidsolution.blogspot.com/ Impeccable Feature of 24 Karat Gold We Work Directly With The Gold buyers To Cut Out The Middle Man, So We Can Avoid Wasting Time. We Are The Leading Gold Sellers. Best Prices Guaranteed .Find Us In Uganda, Kampala. Trusted Gold Sellers — Buy Our Gold with Confidence. Easy Gold Selling Process. Easy Selling Process. Satisfaction Guaranteed. No Hidden Fees. Trusted Experts. Secure Transactions. Instant Quotes. Gold Bars, Gold Bullion And Nuggets. Gold dust, gold bars and gold nugget for sale· Gold nugget, Gold bar, Gold dust · gold bullion buyers and sell. Luxembourg, Singapore, Ireland, Qatar, Switzerland, Norway, United States, United Arab Emirates, Brunei, Hong Kong, germany, Austria, Belgium, Czech Republic, Denmark Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland We are everywhere in New York City, New York Los Angeles, California, Chicago, Illinois, Houston, Texas, Phoenix, Arizona, Philadelphia, Pennsylvania, San Antonio, Texas, San Diego, California, Dallas, Texas, San Jose, California, Austin, Texas, Jacksonville, Florida, Fort Worth, Texas, Columbus, Ohio, San Francisco, California, Charlotte, North Carolina, Indianapolis, Indiana Seattle, Washington, Denver, Colorado, Washington, D.C. Sydney, New South Wales, Melbourne, Victoria, Brisbane, Queensland, Perth, Western Australia, Adelaide, South Australia, Gold Coast, Queensland, Canberra, Australian, Capital Territory, Newcastle, New South Wales, Central Coast, New South Wales, Hobart, Tasmania SERIOUS INQUIRIES ONLY PLEASE

4 days, 6 hours

[PATCH v7 0/8] dma-buf: Use revoke mechanism to invalidate shared buffers

by Leon Romanovsky

Changelog: v7: * Fixed messed VFIO patch due to rebase. v6: https://patch.msgid.link/20260130-dmabuf-revoke-v6-0-06278f9b7bf0@nvidia.com * Added Reviewed-by tags. * Changed for blocking wait_for_completion() in VFIO * Fixed race between ->attach and move_notify, where priv->revoked is flipped and lock is released. v5: https://patch.msgid.link/20260124-dmabuf-revoke-v5-0-f98fca917e96@nvidia.com * Documented the DMA-BUF expectations around DMA unmap. * Added wait support in VFIO for DMA unmap. * Reordered patches. * Improved commit messages to document even more. v4: https://lore.kernel.org/all/20260121-dmabuf-revoke-v4-0-d311cbc8633d@nvidia… * Changed DMA_RESV_USAGE_KERNEL to DMA_RESV_USAGE_BOOKKEEP. * Made .invalidate_mapping() truly optional. * Added patch which renames dma_buf_move_notify() to be dma_buf_invalidate_mappings(). * Restored dma_buf_attachment_is_dynamic() function. v3: https://lore.kernel.org/all/20260120-dmabuf-revoke-v3-0-b7e0b07b8214@nvidia… * Used Jason's wordings for commits and cover letter. * Removed IOMMUFD patch. * Renamed dma_buf_attachment_is_revoke() to be dma_buf_attach_revocable(). * Added patch to remove CONFIG_DMABUF_MOVE_NOTIFY. * Added Reviewed-by tags. * Called to dma_resv_wait_timeout() after dma_buf_move_notify() in VFIO. * Added dma_buf_attach_revocable() check to VFIO DMABUF attach function. * Slightly changed commit messages. v2: https://patch.msgid.link/20260118-dmabuf-revoke-v2-0-a03bb27c0875@nvidia.com * Changed series to document the revoke semantics instead of implementing it. v1: https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com ------------------------------------------------------------------------- This series is based on latest VFIO fix, which will be sent to Linus very soon. https://lore.kernel.org/all/20260121-vfio-add-pin-v1-1-4e04916b17f1@nvidia.… Thanks ------------------------------------------------------------------------- This series documents a dma-buf “revoke” mechanism: to allow a dma-buf exporter to explicitly invalidate (“kill”) a shared buffer after it has been distributed to importers, so that further CPU and device access is prevented and importers reliably observe failure. The change in this series is to properly document and use existing core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. dma-buf has quietly allowed calling move_notify on pinned dma-bufs, even though legacy importers using dma_buf_attach() would simply ignore these calls. The intention was that move_notify() would tell the importer to expedite it's unmapping process and once the importer is fully finished with DMA it would unmap the dma-buf which finally signals that the importer is no longer ever going to touch the memory again. Importers that touch past their unmap() call can trigger IOMMU errors, AER and beyond, however read-and-discard access between move_notify() and unmap is allowed. Thus, we can define the exporter's revoke sequence for pinned dma-buf as: dma_resv_lock(dmabuf->resv, NULL); // Prevent new mappings from being established priv->revoked = true; // Tell all importers to eventually unmap dma_buf_invalidate_mappings(dmabuf); // Wait for any inprogress fences on the old mapping dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_BOOKKEEP, false, MAX_SCHEDULE_TIMEOUT); dma_resv_unlock(dmabuf->resv, NULL); // Wait for all importers to complete unmap wait_for_completion(&priv->unmapp_comp); However, dma-buf also supports importers that don't do anything on move_notify(), and will not unmap the buffer in bounded time. Since such importers would cause the above sequence to hang, a new mechanism is needed to detect incompatible importers. Introduce dma_buf_attach_revocable() which if true indicates the above sequence is safe to use and will complete in kernel-only bounded time for this attachment. Unfortunately dma_buf_attach_revocable() is going to fail for the popular RDMA pinned importer, which means we cannot introduce it to existing places using pinned move_notify() without potentially breaking existing userspace flows. Existing exporters that only trigger this flow for RAS errors should not call dma_buf_attach_revocable() and will suffer an unbounded block on the final completion, hoping that the userspace will notice the RAS and clean things up. Without revoke support on the RDMA pinned importers it doesn't seem like any other non-breaking option is currently possible. For new exporters, like VFIO and RDMA, that have userspace triggered revoke events, the unbouned sleep would not be acceptable. They can call dma_buf_attach_revocable() and will not work with the RDMA pinned importer from day 0, preventing regressions. In the process add documentation explaining the above details. Thanks Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Leon Romanovsky (8): dma-buf: Rename .move_notify() callback to a clearer identifier dma-buf: Rename dma_buf_move_notify() to dma_buf_invalidate_mappings() dma-buf: Always build with DMABUF_MOVE_NOTIFY vfio: Wait for dma-buf invalidation to complete dma-buf: Make .invalidate_mapping() truly optional dma-buf: Add dma_buf_attach_revocable() vfio: Permit VFIO to work with pinned importers iommufd: Add dma_buf_pin() drivers/dma-buf/Kconfig | 12 ----- drivers/dma-buf/dma-buf.c | 69 ++++++++++++++++++++----- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- drivers/gpu/drm/xe/tests/xe_dma_buf.c | 7 ++- drivers/gpu/drm/xe/xe_bo.c | 2 +- drivers/gpu/drm/xe/xe_dma_buf.c | 14 ++--- drivers/infiniband/core/umem_dmabuf.c | 13 ----- drivers/infiniband/hw/mlx5/mr.c | 2 +- drivers/iommu/iommufd/pages.c | 11 +++- drivers/iommu/iommufd/selftest.c | 2 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 80 ++++++++++++++++++++++------- include/linux/dma-buf.h | 17 +++--- 15 files changed, 153 insertions(+), 96 deletions(-) --- base-commit: 61ceaf236115f20f4fdd7cf60f883ada1063349a change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

4 days, 16 hours

← Newer
1
2
3
4
5
6
7
8
9
...
603
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig