3

I'm just getting into the massive topic of learning UEFI driver development and from what I understand so far, hardware peripherals are controlled using specific addresses mapped to memory. Well, the memory is hardware too. Is it not controlled by drivers?

I assume the CPU and motherboard have built-in circuits that handle this, but my curiosity is whether drivers have any hardware level control to this handling. I'd just prefer to know for sure and I'm not sure what manual would explain this.

[kernel/UEFI] driver <-> memory mapped address <-> firmware [hardware:keyboard]
[kernel/UEFI] driver <->          ?            <-> firmware [hardware:RAM]
                                guess:
                                 spec
       driver  <-> CPU microcode <-> motherboard circuit <-> firmware

I just think assumptions are bad and can't find a citation confirming the probable answer. The answer is relevant to security and which supply chain / standard we're trusting. Like PCIe or NVMe are standard specs, perhaps there's a standard for RAM <-> CPU communication?

Maybe this question is a better fit for an Engineering SE site?

J.Todd
  • 707
  • 1
  • 12
  • 34
  • Are you referring to something like Direct Memory Access (DMA)? https://en.wikipedia.org/wiki/Direct_memory_access#Principles – Salmonstrikes Aug 31 '21 at 10:48
  • @Salmonstrikes That's interesting but I don't think so. At least initially, thats looks like a way to access memory without the CPU. I'm pointing out that hardware connected to the motherboard is normally communicated with by programs running on the CPU (typically drivers) by writing to memory mapped to that hardware. RAM is also hardware connected to the motherboard, but clearly it doesn't communicate with programs running on the CPU in the same way other hardware communicates. So is there a RAM driver perhaps in UEFI that dictates it? Or a motherboard built-in circuit? – J.Todd Aug 31 '21 at 17:21
  • @Salmonstrikes in other words most peripheral hardware establishes control handles through a `[kernel/UEFI] driver <-> memory mapped address <-> firmware [hardware:keyboard]` relationship, whereas RAM is clearly different. I'm looking for articulation on how that works. `[kernel/UEFI] driver <-> ? <-> firmware [hardware:RAM]` Maybe that question mark is a driver that one with the right exploit can modify. Maybe it's microcode on the CPU. Maybe it's just circuitry on the mobo. It's likely a combination of those. I'd like to know exactly what method the CPU uses to communicate with memory. – J.Todd Aug 31 '21 at 17:30
  • 1
    At least some of it must be "hardwired", because the CPU has to jump to the reset vector and the target must already be mapped to the memory before the CPU starts executing instructions. – MiSimon Sep 01 '21 at 14:51

1 Answers1

1

From software development perspective, there isn't a driver for RAM control ‐ it's exposed as an indistinguishable part of the hardware via the Instruction Set for a given Architecture (ISA). Just like CPU is hardware, but without a driver to control it. Reason for drivers is access to hardware unknown to the ISA, such as a USB device, a particular manufacturer's SSD (which may or may not be present at power up time), graphics hardware, etc. Just like CPU, RAM must be present at power up ‐ you won't get much further than an error code via lights and beeps without RAM in your system at power up time. This isn't the case for most, if not all, other hardware; such other hardware is therefore optional, and isn't part of the ISA definition; drivers (software) are needed to access such optional hardware.

RAM is managed by both hardware (CPU; see Intel manual, volume 3), especially modern hardware, which provides virtualization support for a modern OS, including paging support, and software (the OS memory allocator), for purposes of virtualizing RAM for the running processes. No drivers though ‐ just addressing via ISA instructions.

If you're looking for an answer from a hardware perspective, such as the details of the bus circuitry, which CPU pins are involved, exact protocol, etc., then this question is a better candidate for Engineering StackExchange site.

CoolBots
  • 4,770
  • 2
  • 16
  • 30