[RFC] Add read-only DDR5 SPD5118 register module for Intel i801

[AllxSmr]

Request for review

Draft/RFC: add a small DDR5 SPD5118 register-read module for a monitoring client that must not expose generic SMBus writes. I am requesting architecture/security review and guidance on the hardware acceptance work needed before this could be considered for merging and subsequent upstream signing/release. This candidate has not been run in the Windows kernel or on real hardware. Please do not treat it as ready to deploy.

Scope and interface

• New root module Ddr5ReadOnly.p; existing modules, headers and CI are unchanged.
• The sole hardware IOCTL is ioctl_ddr5_read, with exactly four input cells [address, direction, register, protocol] and one output cell. unload only releases the fixed mapping.
• Full-width validation, before any hardware native, permits addresses 0x50..0x57, direction 1, word reads (protocol 3) at 0x00, 0x03, 0x31, and byte reads (protocol 2) at 0x05, 0x0b, 0x1a.
• No generic transfer, caller-controlled write payload, peripheral data/configuration writes, PCI writes, page switching, sensor enabling, or arbitrary memory/MSR export. No application/vendor-specific caller lock.
• Discovery is currently limited to Intel client bus 0/device 31/function 4 or 3, with SMBus class, MMIO decode and SMBus host mode already enabled. PCI class/vendor matching is not proof of compatibility with every matching controller.
• The module necessarily writes controller transaction/handshake registers to issue a read and clean up. The peripheral direction is always forced to read. It refuses unavailable/in-use/incompatible controller state and bounds its polling by both elapsed time and iteration count.

"Read-only" is a restriction on this module's exported operations, intended to execute in PawnIO's kernel-resident interpreter. It is not a claim that stock PawnIO, other signed modules, other handles/drivers or an administrator cannot write hardware. It is not a dedicated read-only driver or a machine-wide write prohibition.

Reproducible local evidence

tests/ddr5-readonly/ contains a standalone C mock host and a Windows PowerShell/CMake build entry point. All hardware natives are mocked; no driver installation, UAC, security-setting change or hardware access is involved.

Executed against this submission's module and headers from base 52a7e536dff3e53c96917a28caac5e0fa6510696:

• Pawn 4.1.7152, 64-bit cells, flags -C64 -;+ -(+ -p: module compilation completed with no warnings.
• 65,585 compiled-module request cases passed, including denied write requests, full-width invalid values, buffer/protocol mismatches, busy/disabled controller states and an own-transaction timeout.
• Compiled public/native allowlists passed. Denied requests must not reach a hardware native; permitted writes must stay within checked controller offsets/values and use the read-direction bit.
• Unsigned AMX SHA256: 8E3644DE53D116D2212013759133BA72DA69C358363B34B3053F0B2C515CBFF3.

The harness verifies the upstream compiler source ZIP hash and documents two generated compiler/VM compatibility corrections for modern MinGW/Windows LLP64. It does not alter module bytecode. The repository's Linux compiler CI is a separate check; local mock results are not a claim of upstream CI success or kernel/hardware safety.

Open acceptance questions

• Is this narrow, per-register read interface useful/acceptable upstream, or would you prefer another design within the existing i801 module?
• Please review controller ownership, MMIO ordering, failure/abort cleanup and the discovery restrictions. Firmware/ACPI concurrency, native failures and suspend/resume are not validated by this harness.
• The caller must hold Access_SMBUS.HTP.Method across its scan and verify SPD5118 identity/capabilities/page/sensor state before interpreting temperatures. The module returns raw registers, not DIMM identification or converted temperatures.
• No signing, installation or real-hardware acceptance is claimed or requested before review and the required validation. Advice on a suitable hardware test matrix is welcome.

References and license

• Contribution guidelines.
• Existing SmbusI801.p at the pinned base: register layout/transaction sequence reference, with Steve-Tech's LGPL attribution retained in the new module.
• Linux SPD5118 register/protocol reference: used as a reference; GPL implementation code was not copied.
• Pawn 4.1.7152 compiler source, pinned by SHA256 in the reproducible harness.

Added module and test-harness code: LGPL-2.1-or-later, under the repository's COPYING. The implementation and mock harness were prepared with AI assistance; independent review and actual hardware validation remain outstanding.

[Blacktempel]

This seems unnecessary.
Just access the module via the SMBus and restrict writes.

The name is also misleading as it's not a "Ddr5" but rather a specific Intel access.

I would not test this on my hardware, but I also did not check the code as it's quite unreadable.
Apparently this AI has not heard of empty lines before.

Feel free to test this on your own hardware and report back if it has survived it.