Skip to content
  • Daniel Borkmann's avatar
    bpf: Fix leakage of uninitialized bpf stack under speculation · 801c6058
    Daniel Borkmann authored
    The current implemented mechanisms to mitigate data disclosure under
    speculation mainly address stack and map value oob access from the
    speculative domain. However, Piotr discovered that uninitialized BPF
    stack is not protected yet, and thus old data from the kernel stack,
    potentially including addresses of kernel structures, could still be
    extracted from that 512 bytes large window. The BPF stack is special
    compared to map values since it's not zero initialized for every
    program invocation, whereas map values /are/ zero initialized upon
    their initial allocation and thus cannot leak any prior data in either
    domain. In the non-speculative domain, the verifier ensures that every
    stack slot read must have a prior stack slot write by the BPF program
    to avoid such data leaking issue.
    
    However, this is not enough: for example, when the pointer arithmetic
    operation moves the stack pointer from the last valid stack offset to
    the first valid offset, the sanitation logic allows for any intermediate
    offsets during speculative execution, which could then be used to
    extract any restricted stack content via side-channel.
    
    Given for unprivileged stack pointer arithmetic the use of unknown
    but bounded scalars is generally forbidden, we can simply turn the
    register-based arithmetic operation into an immediate-based arithmetic
    operation without the need for masking. This also gives the benefit
    of reducing the needed instructions for the operation. Given after
    the work in 7fedb63a
    
     ("bpf: Tighten speculative pointer arithmetic
    mask"), the aux->alu_limit already holds the final immediate value for
    the offset register with the known scalar. Thus, a simple mov of the
    immediate to AX register with using AX as the source for the original
    instruction is sufficient and possible now in this case.
    
    Reported-by: default avatarPiotr Krysiuk <piotras@gmail.com>
    Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
    Tested-by: default avatarPiotr Krysiuk <piotras@gmail.com>
    Reviewed-by: default avatarPiotr Krysiuk <piotras@gmail.com>
    Reviewed-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
    Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
    801c6058