RFC: server-side XCB

[Keith Packard]

Jamey Sharp <jamey at minilop.net> writes:

> We've talked about doing the xserver equivalent of XCB for years--that is,
> auto-generating the protocol serialization and deserialization code from
> XCB's machine-readable descriptions of the X protocol and extensions.
>
> Considering the recent CVEs in that code, I think it's time. So I want to
> collect folks' thoughts on what server-side XCB should look like.
>
> At a high level, which code should we be generating? Off the top of my
> head, I'm thinking the dispatch tables and all the swap procedures, as a
> first target in order to get the codegen infrastructure merged and tested.
> Then it'd be nice to generate code that validates arguments and returns
> appropriate errors. Thoughts?

The CVEs have all been related to bounds checking, so if we generated
the swapping code for the requests, and then length checking for both
normal and swapped cases, we'd be in much better shape.

Most of the reply byte swapping stuff is coded ad-hoc into the normal
request paths; pulling that into separate code would be 'hard' as we
often generate reply data incrementally.

Event swapping should be easy to automate.

> XCB's code generator is implemented in Python. Can we make the same choice
> in the xserver build process?

That seems fine to me.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20141220/bae54d1c/attachment.sig>