Hello,
There is no security boundary between the crypto core and drivers, so you can assume that all pointers are valid (including the fact that they're non-null, except possibly for 0-size buffers).
You can also assume that the multipart operations follow a valid sequence (setup-update-update...-finish, or whatever is suitable for the operation type), and that every operation is eventually finished or aborted. Do however keep in mind that different operations can be interspersed (setup(op1); setup(op2); update(op1); update(op2); ...).
The validity of buffer sizes and cryptographic data is less clear-cut. It's definitely one of the areas that needs to be clarified before this specification reaches a final stage. In general, it's better if the core validates everything it can: it saves effort overall since there are far fewer core implementers than driver implementers, it allows the validation to be tested generically, it guarantees that the behavior is the same everywhere. However, there are also integration reasons to have the driver do validation. If the core is responsible for validation then yo can't have a driver for an algorithm that the core doesn't support, which is useful especially with secure elements. There's also some validation that benefits from acceleration, for example checking that the public key is a curve point before performing an ECDH operation. The driver specification should be explicit as to who checks what (we definitely must not end up with each side thinking that the other side will do it). But at this stage I don't know yet where the limit must be.
Best regards,