Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

29 participants
5339 discussions

Start a nNew thread

linaro-mm-sig@lists.linaro.org Password Update

by lists.linaro.org

1 week, 1 day

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

by John Stultz

On Mon, Feb 23, 2026 at 1:51 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. > > - DMA_ATTR_CC_DECRYPTED for DMA mapping: > Since the pages are already decrypted, the DMA API needs to be > informed via DMA_ATTR_CC_DECRYPTED so it can map them correctly > as unencrypted for device access. > > On non-CoCo VMs, the system_cc_decrypted heap is not registered > to prevent misuse by userspace that does not understand > the security implications of explicitly decrypted memory. > > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> Thanks for reworking this! I've not reviewed it super closely, but I believe it resolves my objection on your first version. Few nits/questions below. > @@ -296,6 +345,14 @@ static void system_heap_dma_buf_release(struct dma_buf *dmabuf) > for_each_sgtable_sg(table, sg, i) { > struct page *page = sg_page(sg); > > + /* > + * Intentionally leak pages that cannot be re-encrypted > + * to prevent decrypted memory from being reused. > + */ > + if (buffer->decrypted && > + system_heap_set_page_encrypted(page)) > + continue; > + What are the conditions where this would fail? How much of an edge case is this? I fret this opens a DoS vector if one is able to allocate from this heap and then stress the system when doing the free. Should there be some global list of leaked decrypted pages such that the mm subsystem could try again later to recover these? > diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h > index 648328a64b27..d97b668413c1 100644 > --- a/include/linux/dma-heap.h > +++ b/include/linux/dma-heap.h > @@ -10,6 +10,7 @@ > #define _DMA_HEAPS_H > > #include <linux/types.h> > +#include <uapi/linux/dma-heap.h> > > struct dma_heap; > > diff --git a/include/uapi/linux/dma-heap.h b/include/uapi/linux/dma-heap.h > index a4cf716a49fa..ab95bb355ed5 100644 > --- a/include/uapi/linux/dma-heap.h > +++ b/include/uapi/linux/dma-heap.h > @@ -18,8 +18,7 @@ > /* Valid FD_FLAGS are O_CLOEXEC, O_RDONLY, O_WRONLY, O_RDWR */ > #define DMA_HEAP_VALID_FD_FLAGS (O_CLOEXEC | O_ACCMODE) > > -/* Currently no heap flags */ > -#define DMA_HEAP_VALID_HEAP_FLAGS (0ULL) > +#define DMA_HEAP_VALID_HEAP_FLAGS (0) > > /** > * struct dma_heap_allocation_data - metadata passed from userspace for Are these header changes still necessary? thanks -john

1 week, 1 day

TOP 3 BEST EXPERIENCED CRYPTOCURRENCY RECOVERY EXPERT META TECH RECOVERY PRO

by jonesmicheal5245＠gmail.com

Ask META TECH RECOVERY PRO for help via: Telegram:@metatechrecoveryproteam metatech-recoverypro.com https://metatechrecoverypro.com W/S +1 (469) 692‑8049. META TECH RECOVERY PRO provides expert cyber investigation and digital forensics services delivered by seasoned professionals in the cyber investigations industry. Our specialists possess extensive, demonstrable experience in cyber intelligence, fraud investigation, cybercrime mitigation, anti–money laundering analysis, insider theft and espionage investigations, computer forensics, forensic accounting, internet defamation and brand protection, copyright and trademark enforcement, data breach response, intellectual property protection, cybersecurity assessment, penetration testing (conducted only with explicit authorization), and corporate and executive threat intelligence. Core capabilities and services - Digital forensics and incident response: Rapid containment, evidence preservation, root-cause analysis, and remediation guidance following security incidents or data breaches. - Financial and asset tracing: Proven methodologies for tracing and recovering misappropriated funds and assets across domestic and international channels. - Fraud and cybercrime investigations: Comprehensive investigations into phishing, business email compromise, payment fraud, and related schemes, including coordination with law enforcement when appropriate. - Forensic accounting: Reconstruction of transactional histories and preparation of evidentiary reports suitable for litigation or regulatory proceedings. - Device and data recovery: Recovery and analysis of lost or compromised devices, emails, and digital records using industry-standard forensic techniques. - Intellectual property and brand protection: Investigation of IP theft, counterfeit distribution, online infringement, and strategic remediation. - Authorized penetration testing and vulnerability assessment: Security testing performed only under formal engagement and authorization to identify and remediate system vulnerabilities. - Expert witness and reporting services: Clear, defensible technical reporting and courtroom testimony provided by experienced investigators. Ethics and compliance All engagements are conducted in strict compliance with applicable laws, regulations, and ethical standards. Activities that would involve unlawful access to third-party accounts or devices are neither offered nor performed. Where account or device access is required, we pursue lawful avenues, including cooperation with clients, platforms, and law enforcement, or obtain explicit legal authorization. Representative outcomes - Successfully traced and assisted recovery of diverted corporate funds through coordinated international inquiry and legal channels. - Recovered critical evidentiary data from compromised devices enabling successful prosecution or civil remedy. - Identified and remediated systemic vulnerabilities through authorized penetration testing, reducing organizational risk exposure. Engagement process 1. Initial consultation to assess scope, legal constraints, and objectives. 2. Formal engagement with defined deliverables, timelines, and chain-of-custody procedures. 3. Investigation, remediation recommendations, and documented findings. 4. Ongoing support, including coordination with legal counsel and law enforcement where required. Engage META TECH RECOVERY PRO for authoritative, META TECH RECOVERY PRO Team positions itself as a trusted partner for entities confronting the technical, legal, and operational complexities of cyber intrusions and crypto-asset theft. Through meticulous forensic practice, sophisticated blockchain tracing, and coordinated legal engagement, the firm aims to recover assets, attribute malicious activity where possible, and strengthen clients’ defenses against future incidents.

1 week, 1 day

TOP 3 BEST EXPERIENCED CRYPTOCURRENCY RECOVERY EXPERT META TECH RECOVERY PRO

by jonesmicheal5245＠gmail.com

1 week, 1 day

Best Recovery Service for Cryptocurrency How To Recover Stolen Crypto META TECH RECOVERY PRO

by jonesmicheal5245＠gmail.com

1 week, 2 days

Re: [PATCH 1/5] dma-mapping: avoid random addr value print out on error path

by Marek Szyprowski

On 09.02.2026 16:38, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > dma_addr is unitialized in dma_direct_map_phys() when swiotlb is forced > and DMA_ATTR_MMIO is set which leads to random value print out in > warning. Fix that by just returning DMA_MAPPING_ERROR. > > Fixes: e53d29f957b3 ("dma-mapping: convert dma_direct_*map_page to be phys_addr_t based") > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> Applied to dma-mapping-fixes, thanks! > --- > kernel/dma/direct.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h > index da2fadf45bcd..62f0d9d0ba02 100644 > --- a/kernel/dma/direct.h > +++ b/kernel/dma/direct.h > @@ -88,7 +88,7 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev, > > if (is_swiotlb_force_bounce(dev)) { > if (attrs & DMA_ATTR_MMIO) > - goto err_overflow; > + return DMA_MAPPING_ERROR; > > return swiotlb_map(dev, phys, size, dir, attrs); > } Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

1 week, 2 days

Re: [PATCH rdma-next v3 2/3] RDMA/uverbs: Add DMABUF object type and operations

by Guenter Roeck

On Sun, Feb 01, 2026 at 04:34:05PM +0200, Edward Srouji wrote: > From: Yishai Hadas <yishaih(a)nvidia.com> > > Expose DMABUF functionality to userspace through the uverbs interface, > enabling InfiniBand/RDMA devices to export PCI based memory regions > (e.g. device memory) as DMABUF file descriptors. This allows > zero-copy sharing of RDMA memory with other subsystems that support the > dma-buf framework. > > A new UVERBS_OBJECT_DMABUF object type and allocation method were > introduced. > > During allocation, uverbs invokes the driver to supply the > rdma_user_mmap_entry associated with the given page offset (pgoff). > > Based on the returned rdma_user_mmap_entry, uverbs requests the driver > to provide the corresponding physical-memory details as well as the > driver’s PCI provider information. > > Using this information, dma_buf_export() is called; if it succeeds, > uobj->object is set to the underlying file pointer returned by the > dma-buf framework. > > The file descriptor number follows the standard uverbs allocation flow, > but the file pointer comes from the dma-buf subsystem, including its own > fops and private data. > > When an mmap entry is removed, uverbs iterates over its associated > DMABUFs, marks them as revoked, and calls dma_buf_move_notify() so that > their importers are notified. > > The same procedure applies during the disassociate flow; final cleanup > occurs when the application closes the file. > > Signed-off-by: Yishai Hadas <yishaih(a)nvidia.com> > Signed-off-by: Edward Srouji <edwards(a)nvidia.com> When trying to build powerpc:ppc64e_defconfig: ERROR: modpost: "dma_resv_wait_timeout" [drivers/infiniband/core/ib_core.ko] undefined! ERROR: modpost: "dma_buf_move_notify" [drivers/infiniband/core/ib_core.ko] undefined! ERROR: modpost: "dma_resv_reset_max_fences" [drivers/infiniband/core/ib_core.ko] undefined! The code now requires CONFIG_DMA_SHARED_BUFFER which is not enabled for this platform. Guenter

1 week, 2 days

Re: [PATCH 08/13] dt-bindings: serial: fsl-linflexuart: add clock input properties

by Krzysztof Kozlowski

On 16/02/2026 16:02, Larisa Grigore wrote: > From: Radu Pirea <radu-nicolae.pirea(a)nxp.com> > > Add optional support for the two clock inputs used by the LINFlexD UART > controller: > - "lin": LIN_BAUD_CLK > - "ipg": LINFLEXD_CLK > > The clock inputs are kept optional to maintain compatibility with the > S32V234 platform. Does S32V234 have the clocks? I don't understand the "maintain compatibility" in this context. Either you have or you have not clocks, which should be expressed in schema (: false, see example schema). > > Signed-off-by: Radu Pirea <radu-nicolae.pirea(a)nxp.com> > Co-developed-by: Larisa Grigore <larisa.grigore(a)oss.nxp.com> > Signed-off-by: Larisa Grigore <larisa.grigore(a)oss.nxp.com> > --- > .../bindings/serial/fsl,s32-linflexuart.yaml | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml > index 4171f524a928..885f0b1b3492 100644 > --- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml > +++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml > @@ -34,6 +34,14 @@ properties: > interrupts: > maxItems: 1 > > + clocks: > + maxItems: 2 > + > + clock-names: > + items: > + - const: lin > + - const: ipg > + > required: > - compatible > - reg > @@ -48,3 +56,13 @@ examples: > reg = <0x40053000 0x1000>; > interrupts = <0 59 4>; > }; > + > + - | > + serial@401c8000 { > + compatible = "nxp,s32g2-linflexuart", > + "fsl,s32v234-linflexuart"; > + reg = <0x401C8000 0x3000>; > + interrupts = <0 82 1>; > + clocks = <&clks 14>, <&clks 13>; > + clock-names = "lin", "ipg"; Just add the clocks to existing example. No need for new example for each new property. > + }; Best regards, Krzysztof

1 week, 2 days

Cryptocurrency Scam Recovery Services; Consult ZEUS CRYPTO RECOVERY SERVICES

by karenschafer030＠gmail.com

ZEUS CRYPTO RECOVERY SERVICES is a specialized digital asset recovery and blockchain intelligence firm dedicated to helping individuals and organizations reclaim lost, stolen, or inaccessible cryptocurrency funds. Leveraging advanced blockchain forensics, cybersecurity expertise, and strategic investigative methods, ZEUS CRYPTO RECOVERY SERVICES works to trace digital transactions, identify fraudulent activity, and pursue viable recovery pathways. The company combines technical precision with legal and compliance awareness to support clients affected by scams, hacking incidents, phishing attacks, investment fraud, and wallet access issues. With a client-focused approach, ZEUS CRYPTO RECOVERY prioritizes transparency, confidentiality, and clear communication throughout the recovery process. Each case is handled with a structured assessment strategy, ensuring that clients receive an honest evaluation of recovery feasibility and actionable next steps. Driven by integrity and innovation, ZEUS aims to restore financial confidence in the evolving digital economy by delivering reliable, secure, and results-oriented crypto recovery solutions. Learn More on their Website: https://zeusrecoveryservices.com Email-Box: support(a)zeusrecoveryservices.com WhatsApp-Number: +447841900082

1 week, 2 days

Cryptocurrency Scam Recovery Services; Consult ZEUS CRYPTO RECOVERY SERVICES

by karenschafer030＠gmail.com

1 week, 2 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig