On 24/03/2021 23.18, Joe Perches wrote: > On Wed, 2021-03-24 at 22:27 +0100, Rasmus Villemoes wrote: >> On 24/03/2021 20.24, Joe Perches wrote: >>> On Wed, 2021-03-24 at 18:33 +0100, Rasmus Villemoes wrote: >>>> On 24/03/2021 18.20, Joe Perches wrote: >>>> >>>>> >>>>> Maybe it's better to output non PTR_ERR %pe uses as decimal so this >>>>> sort of code would work. >>>> >>>> No, because that would leak the pointer value when somebody has >>>> accidentally passed a real kernel pointer to %pe. >>> >>> I think it's not really an issue. >>> >>> _All_ code that uses %p<foo> extensions need inspection anyway. >> >> There are now a bunch of sanity checks in place that catch e.g. an >> ERR_PTR passed to an extension that would derefence the pointer; >> enforcing that only ERR_PTRs are passed to %pe (or falling back to %p) >> is another of those safeguards. >> >>> It's already possible to intentionally 'leak' the ptr value >>> by using %pe, -ptr so I think that's not really an issue. >>> >> >> Huh, what? I assume -ptr is shorthand for (void*)-(unsigned long)ptr. >> How would that leak the value if ptr is an ordinary kernel pointer? >> That's not an ERR_PTR unless (unsigned long)ptr is < 4095 or so. > > You are confusing ERR_PTR with IS_ERR No I'm not, I'm just being slightly sloppy - obviously when I say "not an ERR_PTR" I mean "not the result of ERR_PTR applied to a negative errno value", or "not the result of a valid invocation of ERR_PTR". But yes, feel free to read "not an ERR_PTR" as "something for which IS_ERR is false". Can you expand on why you think %pe, -ptr would leak the value of ptr? >> If you want to print the pointer value just do %px. No need for silly >> games. > > There's no silly game here. %pe would either print a string or a value. A hashed value, that is, never the raw value. > It already does that in 2 cases. Yes, if you pass it ERR_PTR(-1234) (where no E symbol exists) or ERR_PTR(-EINVAL) but CONFIG_SYMBOLIC_ERRNAME=n, it prints the value in decimal, because people will probably recognize "-22" and values in that range don't reveal anything about the kernel image. Anything outside [-4095,0] or so is hashed. Rasmus _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
