There isn't any comparison operation with the passphrase, because there's nothing to compare it against. The plain-text passphrase isn't stored in the system anywhere (if it was, an attacker could steal it without guessing, brute-forcing, or needing some legit user to enter it). The exact operations done depend on the disk encryption software (Bitlocker, FileVault, VeraCrypt, LUKS, etc. all work a bit differently) and what mode it's operating in (sometimes, there's no passphrase at all; the key comes from a file on a flashdrive and/or a hardware security module called a Trusted Platform Module or TPM) but generally, the passphrase is run through some form of password hashing / key derivation algorithm, which is a non-reversible cryptographic operation that turns a passphrase into a binary string suitable for use as a cryptographic key. Even the output of that function (the digest) isn't going to be compared against anything directly either - after all, if the attacker gets that, then it's just skipping the passphrase -> hashing step, so you can't store the digest anywhere either - but you can hash it again, or use it to decrypt some secret and check the integrity of the decryption, and in either case (hashed key's digest, or authentication tag for decryption), that is data that can be safely stored on the disk because there's no way to get any actual secrets back out of it.
With that said, of course a maliciously modified CPU could steal the passphrase as it's entered. Every keystroke on the keyboard will, after various operations that might take place off-CPU (e.g. in a microcontroller inside the keyboard or on the motherboard's USB controller), end up entering the CPU (computer firmware - the BIOS or UEFI - have at least a basic keyboard driver in them, and it runs on the CPU even if the OS isn't running yet). You're not going to be capturing it during any comparisons - because none are performed on the passphrase - but it's still there for capture (briefly).
Mind you, there's lots of other places you could capture such data. A classic example is a hardware keylogger, either inside the keyboard itself or between the keyboard and the motherboard. Another option is in the USB host controller on the motherboard. Another is in the RAM, since that's where keyboard input is buffered until the CPU processes it (and also, mostly inevitable, any time the user types a string such as a passphrase it ends up, at least briefly, resident as a string in RAM). Finally, there's the keyboard driver in the firmware / pre-boot code.
CPUs are the most complex components of most computers (high-end GPUs may have more transistors, but may well still be a simpler design writ large), and only a few companies are capable of manufacturing high-end x86 CPUs, so it's a relatively unlikely place for a malicious implant. Not out of the question, but you'd need a ton of resources, and by the time it's even viable to replace somebody's CPU with a malicious one, there are easier attacks by far.
Also, this isn't really breaking hard drive encryption. This is just stealing the passphrase needed to get the decryption key. That defeats the encryption, but it doesn't break it, any more than somebody finding the "secret" key under your door mat and using it to unlock your front door is "breaking" your lock. Actually breaking the encryption - for any modern cryptographic cipher, implemented even half-decently - requires expert cryptanalysts to study the cipher for a way to even proceed (other than dumb brute-force) and even then, the best known attacks against any modern ciphers are well outside the potential of any one CPU even if you let it run for decades. Quantum computers might change this, for some ciphers, but they're still far from practical for use on real-world problems of even the size "encrypted hard disk and you don't have the key".