new restriction lint: pointer_format

[llogiq]

I read a blog post about kernel security, and how various features might get lost while porting to Rust. In kernel C, they have some guardrails against divulging pointers. An easy way to replicate that in Rust is a lint for pointer formatting. So that's what this lint does.

---

changelog: new [pointer_format] lint

[rustbot]

r? @samueltardieu

rustbot has assigned @samueltardieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[samueltardieu]

Lint example needs to be fixed. FCP thread created on Zulip.

@rustbot label +S-final-comment-period

[tgross35]

Is there any chance this could be adapted to check for any fmt trait being used on a pointer, rather than just the :p formatting? @nbdd0121 pointed out that a likely accident is printing via Debug, possibly through derives.

[llogiq]

Do you mean debug-formatting a function pointer? That should be workable for the direct case but might become pretty hard for the general case.

[tgross35]

I think a specific example would be something like this:

#[derive(Debug)]
pub struct S {
    pub p: *const u32,
}

pub fn foo(a: *const u32) {
    println!("{a:?}");
}

pub fn bar(a: S) {
    println!("{a:?}");
}

fn main() {
    foo(&0u32);
    bar(S{p: &0u32});
}

I'm not sure how this would be done in clippy since it would need to check whether a crate calls the Pointer / Debug implementations for raw pointers in the crate. If this isn't easy then checking directly in the format string still does help.

[llogiq]

A thing we might do there is to walk the types of the arguments (as far as they derive Debug, we should not go into manual implementations) and see if there's any raw pointer or reference.

[kpreid]

“…misuse for exfiltrating…” makes it sound like this is protection against attempts to insert malicious code into a project. Is auditing such code within scope for clippy? If not, it might be good to change the wording.

Also, “kernel context” isn’t very clear to people not familiar with what it’s talking about and sounds like it might be a formal or common Rust term, which it is not. How about something more like “In (projects|codebases|crates) such as operating system kernels,”?

[llogiq]

Yeah, I'm working on some code to add that. I may not be able to look through manual Debug impls, though, so it's a best-effort thing at best.

[ojeda]

Ideally, there would be a way to customize all pointer printing, i.e. including :p and :?, so that we can get them hashed as expected, and thus at that point we wouldn't need to lint for it. Meanwhile, this lint can be useful (and may be for other projects that do not want any printing whatsoever, too).