On Thu, 1 May 2025 at 04:10, Luis Gerhorst <luis.gerho...@fau.de> wrote: > > ALU sanitization was introduced to ensure that a subsequent ptr access > can never go OOB, even under speculation. This is required because we > currently allow speculative scalar confusion. Spec. scalar confusion is > possible because Spectre v4 sanitization only adds a nospec after > critical stores (e.g., scalar overwritten with a pointer). > > If we add a nospec before the ALU op, none of the operands can be > subject to scalar confusion. As an ADD/SUB can not introduce scalar > confusion itself, the result will also not be subject to scalar > confusion. Therefore, the subsequent ptr access is always safe. > > We directly fall back to nospec for the sanitization errors > REASON_BOUNDS, _TYPE, _PATHS, and _LIMIT, even if we are not on a > speculative path. > > For REASON_STACK, we return the error -ENOMEM directly now. Previously, > sanitize_err() returned -EACCES for this case but we change it to > -ENOMEM because doing so prevents do_check() from falling back to a > nospec if we are on a speculative path. This would not be a serious > issue (the verifier would probably run into the -ENOMEM again shortly on > the next non-speculative path and still abort verification), but -ENOMEM > is more fitting here anyway. An alternative would be -EFAULT, which is > also returned for some of the other cases where push_stack() fails, but > this is more frequently used for verifier-internal bugs.
Hm, now looking at this and thinking more about this, I think recoverable error logic is probably ok as is. Scratch my earlier suggestion about unconditional handling. I guess what would be better would be handling everything except fatal ones. In case of fatal ones we should really quit verification and return. We may make partial changes to verifier state / env and try to bail out using -ENOMEM and -EFAULT. So unconditional continuation would be problematic as we'd act in a partial state never meant to be seen. The logic otherwise looks ok, so: Acked-by: Kumar Kartikeya Dwivedi <mem...@gmail.com> > > [...] >
