Please remember to give karma for F26 kernels
by Laura Abbott
As we approach the release of F28 we've started to see a fall off in karma
for F26. If you have an F26 system around, please remember to test new
kernels and give karma.
Thanks,
Laura
6 years, 1 month
Re: Feature request: improved build-id generation
by Laura Abbott
ArOn 03/16/2018 11:37 AM, Cary Coutant wrote:
>>> Then I'm stating my case poorly. I want a way to inject additional
>>> data into the has computation.
>>
>> At one point, we proposed doing this via a linker- or assembler-oriented
>> extra "salt" parameter, which would be hashed into the buildid. This
>> would most naturally be a n-v-r-a string, so the build is reproducible.
>> Such a salt could be naturally injected via an environment variable set
>> by rpmbuild.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1002341 (salt!)
>> https://bugzilla.redhat.com/show_bug.cgi?id=1550152 (life without salt)
>
> I don't have a problem with adding a --build-id-salt="some arbitrary
> string" option, and I think "salt" is exactly the right term for this.
> I'd much prefer providing that than having you use a linker script.
> (I'm somewhat puzzled that you find the linker script option less
> objectionable than an object file with a note section.)
>
> As Nick said earlier, it's not that we don't care about your feature
> request. I simply wanted to explore the options, and I gave you a
> couple of options that require no new features at all.
>
> My other comments have been about the unnecessary conflating of a new
> option like --build-id-salt with the choice of hashing algorithm.
>
At least in the kernel we already have the infrastructure for
customizations to linker scripts so it's fairly easy to expand on that.
I have a prototype which should work, I just need to clean it up
for review to see if it's feasible to merge vs. adding a --build-id-salt
option.
Thanks,
Laura
> -cary
>
6 years, 1 month
[PATCH] kernel-tools.spec: Adding bpftool package
by Jiri Olsa
hi,
please consider attached change that adds bpftool sub
package to be generated within kernel-tools spec.
The reason to have bpftool in separate rpm is to
have minimal dependency for sosreport that will
depend on it.
The bpftool rpm contains following files:
$ rpm -ql -p bpftool-4.16.0-0.rc5.git0.1.fc29.x86_64.rpm
/etc/bash_completion.d/bpftool
/usr/sbin/bpftool
/usr/share/man/man8/bpftool-cgroup.8.gz
/usr/share/man/man8/bpftool-map.8.gz
/usr/share/man/man8/bpftool-prog.8.gz
/usr/share/man/man8/bpftool.8.gz
thanks,
jirka
---
kernel-tools.spec | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/kernel-tools.spec b/kernel-tools.spec
index c8cbcff104fd..2d190d0497b6 100644
--- a/kernel-tools.spec
+++ b/kernel-tools.spec
@@ -69,7 +69,7 @@ BuildRequires: kmod, patch, bash, tar, git
BuildRequires: bzip2, xz, findutils, gzip, m4, perl-interpreter, perl(Carp), perl-devel, perl-generators, make, diffutils, gawk
BuildRequires: gcc, binutils, redhat-rpm-config, hmaccalc
BuildRequires: net-tools, hostname, bc, elfutils-devel
-BuildRequires: zlib-devel binutils-devel newt-devel python2-devel perl(ExtUtils::Embed) bison flex xz-devel
+BuildRequires: zlib-devel binutils-devel newt-devel python2-devel python2-docutils perl(ExtUtils::Embed) bison flex xz-devel
BuildRequires: audit-libs-devel glibc-devel glibc-static
%ifnarch s390x %{arm}
BuildRequires: numactl-devel
@@ -164,6 +164,13 @@ Provides: kernel-tools-devel
This package contains the development files for the tools/ directory from
the kernel source.
+%package -n bpftool
+Summary: Inspection and simple manipulation of eBPF programs and maps
+License: GPLv2
+%description -n bpftool
+This package contains the bpftool, which allows inspection and simple
+manipulation of eBPF programs and maps.
+
%prep
%setup -q -n kernel-%{kversion}%{?dist} -c
@@ -233,6 +240,9 @@ popd
pushd tools/gpio/
make
popd
+pushd tools/bpf/bpftool
+make
+popd
###
### install
@@ -299,6 +309,9 @@ popd
pushd tools/kvm/kvm_stat
make INSTALL_ROOT=%{buildroot} install-tools
popd
+pushd tools/bpf/bpftool
+make DESTDIR=%{buildroot} prefix=%{_prefix} bash_compdir=%{_sysconfdir}/bash_completion.d/ mandir=%{_mandir} install doc-install
+popd
###
### scripts
@@ -368,6 +381,14 @@ popd
%{_includedir}/cpufreq.h
%{_includedir}/cpuidle.h
+%files -n bpftool
+%{_sbindir}/bpftool
+%{_sysconfdir}/bash_completion.d/bpftool
+%{_mandir}/man8/bpftool-cgroup.8.gz
+%{_mandir}/man8/bpftool-map.8.gz
+%{_mandir}/man8/bpftool-prog.8.gz
+%{_mandir}/man8/bpftool.8.gz
+
%changelog
* Mon Mar 12 2018 Jeremy Cline <jeremy(a)jcline.org> - 4.16.0-0.rc5.git0.1
- Linux 4.16-rc5
--
2.13.6
6 years, 1 month
Kernel change broken wireguard builds in unexpected way
by Bruno Wolff III
Normally when a kernel change causes a problem there is a compile error,
but I'm seeing a make problem. Builds work with
kernel-4.16.0-0.rc6.git0.2.fc28.x86_64, but not with
kernel-4.16.0-0.rc6.git2.2.fc29.x86_64.
The error output is:
[bruno@cerberus src]$ make KERNELDIR=/lib/modules/4.16.0-0.rc6.git2.2.fc29.x86_64/build clean all
CLEAN /home/bruno/WireGuard/src/.tmp_versions
CLEAN /home/bruno/WireGuard/src/Module.symvers
CLEAN /home/bruno/WireGuard/src/tools/{wg,*.o,*.d}
make[2]: *** No rule to make target '/home/bruno/WireGuard/src/main.o', needed by '/home/bruno/WireGuard/src/wireguard.o'. Stop.
make[1]: *** [Makefile:1556: _module_/home/bruno/WireGuard/src] Error 2
make: *** [Makefile:36: module] Error 2
Is this something Fedora specific? I wouldn't expect an rc6 change to
cause an issue like this.
I'm going to try building an upstream kernel to see if the problem is
upstream, but I probably won't have an answer until tomorrow.
6 years, 1 month
Re: Feature request: improved build-id generation
by Laura Abbott
On 03/15/2018 06:32 AM, Nick Clifton wrote:
> Hi Mark,
>
>> That might be an interesting alternative. Could you use this for e.g.
>> inserting a .comment section fragment with an unique (version) string?
>> That would be stripped away, but should still count for the build-id
>> hash calculation.
>
> If you know the value you want to store ahead of time, then it is easy:
>
> % cat comment.t
> SECTIONS
> {
> .comment (INFO) :
> {
> BYTE (0x12);
> BYTE (0x34);
> BYTE (0x56);
> BYTE (0x78);
> }
> }
>
> % gcc hello.c -Wl,comment.t
> % readelf -x.comment a.out
>
> Hex dump of section '.comment':
> 0x00000000 4743433a 2028474e 55292037 2e332e31 GCC: (GNU) 7.3.1
> 0x00000010 20323031 38303133 30202852 65642048 20180130 (Red H
> 0x00000020 61742037 2e332e31 2d322900 4743433a at 7.3.1-2).GCC:
> 0x00000030 2028474e 55292037 2e322e31 20323031 (GNU) 7.2.1 201
> 0x00000040 37303931 35202852 65642048 61742037 70915 (Red Hat 7
> 0x00000050 2e322e31 2d322900 12345678 .2.1-2)..4Vx
>
> (Note how the value has been appended to the .comment section).
>
> Unfortunately the linker does not have a STRING() operator to insert
> ascii codes into a section, so you have to construct the bytes by
> hand. Eg:
>
> % cat comment.t
> SECTIONS
> {
> .comment (INFO) :
> {
> BYTE (0x41);
> BYTE (0x42);
> BYTE (0x43);
> BYTE (0x00);
> }
> }
>
> % gcc hello.c -Wl,comment.t
> % readelf -p.comment a.out
>
> String dump of section '.comment':
> [ 0] GCC: (GNU) 7.3.1 20180130 (Red Hat 7.3.1-2)
> [ 2c] GCC: (GNU) 7.2.1 20170915 (Red Hat 7.2.1-2)
> [ 58] ABC
>
> A simple perl or python script could be used to create the comment.t
> linker script fragment.
>
> Cheers
> Nick
>
I think this approach looks promising. I'm going to see about prototyping
this approach.
Thanks,
Laura
6 years, 1 month
Re: Feature request: improved build-id generation
by Mark Wielaard
On Thu, 2018-03-15 at 11:36 +0000, Nick Clifton wrote:
> > > I think Fedora should be able to ask its tool chain to insert the
> > > extra data rather than hacking it in after the fact.
>
> I'll just note that another way to insert data into a linked binary
> is to use a linker script fragment referenced from the command line.
> I doubt that this would be any better than creating a "magic .o" file,
> but it is worth knowing.
That might be an interesting alternative. Could you use this for e.g.
inserting a .comment section fragment with an unique (version) string?
That would be stripped away, but should still count for the build-id
hash calculation.
Cheers,
Mark
6 years, 1 month
Re: Feature request: improved build-id generation
by Mark Wielaard
On Thu, 2018-03-15 at 00:45 -0700, Cary Coutant wrote:
> > > To inject explicit out-of-band data into the hash computation, you
> > > could insert an object with nothing but a note section, or even use
> > > --defsym to create a symbol table entry with your extra key(s).
> >
> > Fedora wants to insert extra data into the build-id of all packages in
> > its repository, and it does so right now by post-processing the
> > package. This is ugly, and it flat-out doesn't work for the kernel,
> > which is apparently breaking a legitimate debugging use case.
> >
> > I think Fedora should be able to ask its tool chain to insert the
> > extra data rather than hacking it in after the fact. Asking Fedora to
> > use --defsym for this purpose is IMO a non-starter, as is asking
> > Fedora to come up with some magic .o file and linking it into every
> > object.
>
> I understand your objection to the magic .o file, but why exactly is
> --defsym a "non-starter"? It's pretty close to what you're asking for
> (except for the spelling), it's already available, and it has the
> advantage of adding the extra data to the binary in a form where it
> can be easily extracted (e.g., with "nm").
>
> I don't understand the need for forcing two otherwise-identical
> binaries to have different build ids, simply because they're part of
> different distributions. Perhaps it would help if you could explain
> why you need that.
In theory two different build environments could produce the same
identical binary. Even different source files could if they express the
same algorithm and the compiler optimizes them the same way. But you
might still want to identify which came from which build. The build-id
is used to identify the build (environment) that produced the binary.
If the build environment is identical then in theory it should produce
identical binaries and build-ids. But this isn't necessarily the other
way around. For a distro it is nice to have unique build-id identifiers
for different package version builds. Then if you just have e.g. a core
file with a build-id in it, you can map it back to which package build
it came from.
The linker doesn't see the whole build environment, but it often has
enough to differentiate if there is debuginfo involved, which contains
the source file paths, compiler versions, command line options, etc. I
think in the case Andy is interested in, the vdso, just isn't "unique"
enough (it contains mostly assembly without debuginfo). The vdso is
also slightly special because it is build and then "inserted" into the
kernel image (so it can be mapped into the process space at runtime).
Which makes it difficult to "post-process".
If using new command line flags is out of the question, could the
linker use an environment variable as seed for the build-id hash
computation? Then a package build could just set e.g.
BUILD_ID_ENV="<package-version>". That could also be used for other
purposes to capture anything from the build environment that might make
a build unique.
Cheers,
Mark
6 years, 1 month
proper debuginfo for embedded vDSO
by Laura Abbott
Hi,
The kernel still doesn't have 100% parallel debuginfo because we can't update
the vDSO binary embedded in the the image. I'd like to see about updating
debugedit to be smart enough to do the recalculation of the buildid for both
the vmlinux and the embedded vDSO.
I'd like to avoid too tight a coupling between the kernel and debugedit
so if we want/need to change how the vDSO is generated it won't break too
many things. My idea is to stick the location of the vDSO in an ELF note
so debugedit knows where to look. As long as the kernel can generate this
section correctly, debugedit can find the embedded build-id and update
accordingly.
Obviously this would need approval from a wider audience but I'm looking
to get some early feedback before I spend too much time prototyping
something that has no chance of going anywhere.
Thoughts?
Thanks,
Laura
6 years, 1 month
Re: Feature request: improved build-id generation
by Linus Torvalds
On Wed, Mar 14, 2018 at 6:01 PM, Alan Modra <amodra(a)gmail.com> wrote:
> On Wed, Mar 14, 2018 at 04:40:25PM -0700, Andy Lutomirski wrote:
>>
>> I realize that the security issue here is barely relevant, but git’s use of SHA1 is *not* okay, and git is migrating away for a reason.
>
> Hmm, that's news to me. Heh, I've always been a bit suspicious of
> git's reliability. ;-)
I'm afraid Andy has listened to a few too many hard-liner security
people - the bad kind that don't know shades of gray, and the kind
that aren't generally worth listening to.
SHA1 with the known attack weakness fixed (aka "Hardened SHA1", the
way git already does) in a non-certificate environment is fine.
The fact is, data identification is different from some kind of
security that depends on the key. I wouldn't use even hardened SHA1
for some security certificate. But for file ID's? Andy is confused.
Linus
6 years, 1 month
