On 12/28/25 08:49, Henson Choi wrote:
>
> 3. Proposal Specifications
>
>
> 3.1 The Interface (Hook Points)
>
> We allow intervention by security experts through five contact points
> along the I/O path:
>
> * *Read/Write Hooks:* |mdread_post|, |mdwrite_pre|, |mdextend_pre|
> (Transformation of the data area)
> * *WAL Hooks:* |xlog_insert_pre|, |xlog_decode_pre| (Transformation of
> transaction logs)
>
>
> 3.2 The Protocol Identifier (PageHeader Transformation ID)
>
> We allocate 5 bits of |pd_flags| to define the “Security State” of a
> page. This serves as a *Status Message* sent by the security expert to
> the engine, utilized for key versioning and as a migration marker.
>
Isn't this rather problematic?
This seems to be meant to be extensible, which means there can be
multiple extensions setting the hooks. Which we generally allow, and the
custom is to call the previous hook.
What happens if there are multiple extensions implementing the hook?
Would that be allowed or prohibited in this case? Maybe it doesn't make
sense, but then why wouldn't it be possible?
FWIW I find it very unlikely we'd allow reserving pd_flags bits for an
extension. These bits are meant to be used by core, there's very limited
number of such bits.
In general, I'm somewhat skeptical of the claim a collection of hooks is
"low-barrier, high-safety". It seems pretty fragile to me, and I can
envision a lot of maintenance difficulties in the future. Not just for
the extension developers, but for the project too - adding a bunch of
random hooks is not free for us, we'll need to keep it working in future
releases, etc.
Perhaps the current SMGR code is not extensible/flexible enough, but
then we need to improve that. I'd imagine a simple SMGR doing the
encryption, but federating most of the work to a "full" SMGR. But I
haven't thought about that too much.
regards
--
Tomas Vondra
