leaky info and kernel modules

leaky info and kernel modules

[se iro]

saw post on reddit and github issues where rust compiler adds username and systems paths/info to **release** mode compile bins. also its pkg mgr cargo does the same with registry paths. otherwise its extra strings bloating output that not needed and strip command doesnt work. also not working is compiler opts described

does this impact chat of rust in linux since rust team seems to be ignoring the issue?

ref links (maybe more too):

https://www.reddit.com/r/rust/comments/mfax64/remove_username_from_binary_for_privacy/
https://github.com/rust-lang/rust/issues/40374
https://github.com/rust-lang/rust/issues/40552
https://github.com/rust-lang/rust/issues/75263
https://github.com/rust-lang/cargo/issues/5505

Re: leaky info and kernel modules

[Geoffrey Thomas]

On Wed, 7 Apr 2021, se iro wrote:

> saw post on reddit and github issues where rust compiler adds username 
> and systems paths/info to **release** mode compile bins. also its pkg 
> mgr cargo does the same with registry paths. otherwise its extra strings 
> bloating output that not needed and strip command doesnt work. also not 
> working is compiler opts described

I think what's going on is that, while this is unusual for most dynamic 
languages (and the Rust language intentionally targets the community of 
users of dynamic languages), it's actually the normal behavior for 
compiled languages - compiled C binaries include full paths in their 
debuginfo too. I checked a random released kernel that I'm running, and it 
has full source file paths (including the username, if you built in /home) 
in its debug info, so for the purposes of Rust in the Linux kernel, I 
don't think this is an effective change.

We should definitely match what the rest of the kernel does in terms of 
debug info, but I think we already do.

-- 
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com

Re: leaky info and kernel modules

[Miguel Ojeda]

Hi Se Iro,

On Wed, Apr 7, 2021 at 11:03 PM se iro <seiro22@mailfence.com> wrote:
>
> saw post on reddit and github issues where rust compiler adds username and systems paths/info to **release** mode compile bins. also its pkg mgr cargo does the same with registry paths. otherwise its extra strings bloating output that not needed and strip command doesnt work. also not working is compiler opts described
>
> does this impact chat of rust in linux since rust team seems to be ignoring the issue?

Yeah, Rust is adding few strings with paths (at least ~4 KiB from a
quick test in my case); while a non-Rust kernel, in-tree build without
`DEBUG_KERNEL` does not seem to contain any absolute paths (although
please note that kernels typically contain your username/host anyway
unless you tweak `KBUILD_BUILD_*` etc.).

So while I don't think it is that critical at the moment, any bloat
that can be reduced (e.g. those paths could be relative) is always a
good idea. It is also good for improving reproducibility of builds
etc.

I will create a quick issue about this.

Thanks!

Cheers,
Miguel

Re: leaky info and kernel modules

[Miguel Ojeda]

On Wed, Apr 7, 2021 at 11:50 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> I will create a quick issue about this.

Done:

    https://github.com/Rust-for-Linux/linux/issues/169

Cheers,
Miguel

Re: leaky info and kernel modules

[se iro]

you mention debug but this is building release mode not debug which is why it odd.
and yeah if these paths exists its not reproducible as they different for everyone else. steve k commented on reddit and said he thinks so long as build process is same its reproducible, not that hashing matching is require. rust team may have differ opinion on what reproducible builds are too which affect this like you say

> ----------------------------------------
> From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> Sent: Wed Apr 07 23:50:54 CEST 2021
> To: se iro <seiro22@mailfence.com>
> Cc: <rust-for-linux@vger.kernel.org>
> Subject: Re: leaky info and kernel modules
> 
> 
> Hi Se Iro,
> 
> On Wed, Apr 7, 2021 at 11:03 PM se iro <seiro22@mailfence.com> wrote:
> >
> > saw post on reddit and github issues where rust compiler adds username and systems paths/info to **release** mode compile bins. also its pkg mgr cargo does the same with registry paths. otherwise its extra strings bloating output that not needed and strip command doesnt work. also not working is compiler opts described
> >
> > does this impact chat of rust in linux since rust team seems to be ignoring the issue?
> 
> Yeah, Rust is adding few strings with paths (at least ~4 KiB from a
> quick test in my case); while a non-Rust kernel, in-tree build without
> `DEBUG_KERNEL` does not seem to contain any absolute paths (although
> please note that kernels typically contain your username/host anyway
> unless you tweak `KBUILD_BUILD_*` etc.).
> 
> So while I don't think it is that critical at the moment, any bloat
> that can be reduced (e.g. those paths could be relative) is always a
> good idea. It is also good for improving reproducibility of builds
> etc.
> 
> I will create a quick issue about this.
> 
> Thanks!
> 
> Cheers,
> Miguel


-- 
Sent with https://mailfence.com
Secure and private email

Re: leaky info and kernel modules

[Miguel Ojeda]

Hi Se Iro,

On Thu, Apr 8, 2021 at 4:38 AM se iro <seiro22@mailfence.com> wrote:
>
> you mention debug but this is building release mode not debug which is why it odd.

I was talking about release mode (please note I said "without"
`DEBUG_KERNEL`, not "with"). Perhaps I misunderstood you?

> and yeah if these paths exists its not reproducible as they different for everyone else. steve k commented on reddit and said he thinks so long as build process is same its reproducible, not that hashing matching is require. rust team may have differ opinion on what reproducible builds are too which affect this like you say

Reproducible builds are, in the end, about achieving the same output
every time. How to achieve that, however, can be easier or harder
depending on how much state/environment a project relies upon.

So, for instance, if we have absolute paths in the binary, then that
is one more thing to worry when preparing the build. That is why
removing the paths improves reproducibility, but it is not the only
thing that is required to achieve it for the kernel (i.e. we are not
breaking reproducibility just because we have those paths & one can
still achieve it by taking care of the paths).

Cheers,
Miguel