<feed xmlns='http://www.w3.org/2005/Atom'>
<title>amd-psp-re.git/hw/gbr_ih_set.py, branch main</title>
<subtitle>AMD PSP reverse engineering, emulator and vulnerability research</subtitle>
<id>https://git.sl0p.foo/amd-psp-re.git/atom/hw/gbr_ih_set.py?h=main</id>
<link rel='self' href='https://git.sl0p.foo/amd-psp-re.git/atom/hw/gbr_ih_set.py?h=main'/>
<link rel='alternate' type='text/html' href='https://git.sl0p.foo/amd-psp-re.git/'/>
<updated>2026-09-30T02:11:06Z</updated>
<entry>
<title>record the interrupt-ring-set probe as vacuous rather than as a passing check</title>
<updated>2026-09-30T02:11:06Z</updated>
<author>
<name>user</name>
<email>user@clank</email>
</author>
<published>2026-09-30T02:11:06Z</published>
<link rel='alternate' type='text/html' href='https://git.sl0p.foo/amd-psp-re.git/commit/?id=db3867ff175ef65a5583fd4b234ee8a30d7721c2'/>
<id>urn:sha1:db3867ff175ef65a5583fd4b234ee8a30d7721c2</id>
<content type='text'>
Ring creation rejects a base inside the trusted region with a distinct status, and the
interrupt-ring setter is the sibling path that points the processor at a host-supplied ring
which hardware writes into, taking its address from the same register pair, so the question
was whether that path carries the same check.

Every case returns the same error, including the valid address, so the path rejects
everything and is not functional in this configuration. The comparison therefore cannot be
made and the result is recorded as vacuous on the question asked, explicitly not as
evidence that the check is present. Writing a row claiming the path validates its address
would have repeated an earlier mistake where a detector's negative control never engaged.

What can be said is that the identifier is harmless, since the processor stays usable in
all four cases, consistent with the control-space sweep.
</content>
</entry>
</feed>
