Re: module signing: Changing to MODULE_SIG_SHA3_512

[Josh Boyer]

On Thu, Nov 9, 2023 at 8:29 AM Josh Boyer  wrote:
>
> On Thu, Nov 9, 2023 at 8:23 AM Prarit Bhargava  wrote:
> >
> > On 11/9/23 08:13, Josh Boyer wrote:
> > > On Thu, Nov 9, 2023 at 8:03 AM Prarit Bhargava  wrote:
> > >>
> > >> On 11/8/23 08:33, Prarit Bhargava wrote:
> > >>> Hey everyone,
> > >>>
> > >>> The current kernel configs generate
> > >>>
> > >>> # CONFIG_MODULE_SIG_FORCE is not set
> > >>> CONFIG_MODULE_SIG_ALL=y
> > >>> # CONFIG_MODULE_SIG_SHA256 is not set
> > >>> # CONFIG_MODULE_SIG_SHA384 is not set
> > >>> CONFIG_MODULE_SIG_SHA512=y
> > >>> # CONFIG_MODULE_SIG_SHA3_256 is not set
> > >>> # CONFIG_MODULE_SIG_SHA3_384 is not set
> > >>> # CONFIG_MODULE_SIG_SHA3_512 is not set
> > >>> CONFIG_MODULE_SIG_HASH="sha512"
> > >>>
> > >>> With https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2802
> > >>>
> > >>> we can strengthen the module signing algorithm to
> > >>> CONFIG_MODULE_SIG_SHA3_512.
> > >>>
> > >>> I'd like to do this before Fedora40, as it will be the basis of
> > >>> centos-stream-10 and RHEL10.
> > >>>
> > >>> Thoughts or concerns?
> > >>>
> > >>> P.
> > >>
> > >> I took a closer look at this and there doesn't appear to be an issue
> > >> with doing this in the kernel.  Build times and boot times seem
> > >> consistent before and after the change.
> > >>
> > >> However, depmod (from kmod) needs an update if we make this change.  The
> > >> current fedora version of kmod, -31, segfaults in the modules_install
> > >> target.  I ran the latest upstream version of kmod and AFAICT that works.
> > >>
> > >> I will wait for kmod to be updated to at least version -32 and then
> > >> request that we change the module signing algorithm to SHA3_512, unless
> > >> there any objections.
> > >
> > > The latest kmod in fedora is -30.  I was just looking at packaging -31
> > > today.  Are the above version numbers typos, or did you get kmod from
> > > somewhere else?
> > >
> >
> > Whoops.  Yep, typos.  Sorry, off by one in my brain.
>
> OK, thanks.  I might look at the commits beyond -31 and see about
> adding them if they aren't too much of a departure from the release.

https://koji.fedoraproject.org/koji/buildinfo?buildID=2318246

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: module signing: Changing to MODULE_SIG_SHA3_512

[Josh Boyer]

On Thu, Nov 9, 2023 at 8:23 AM Prarit Bhargava  wrote:
>
> On 11/9/23 08:13, Josh Boyer wrote:
> > On Thu, Nov 9, 2023 at 8:03 AM Prarit Bhargava  wrote:
> >>
> >> On 11/8/23 08:33, Prarit Bhargava wrote:
> >>> Hey everyone,
> >>>
> >>> The current kernel configs generate
> >>>
> >>> # CONFIG_MODULE_SIG_FORCE is not set
> >>> CONFIG_MODULE_SIG_ALL=y
> >>> # CONFIG_MODULE_SIG_SHA256 is not set
> >>> # CONFIG_MODULE_SIG_SHA384 is not set
> >>> CONFIG_MODULE_SIG_SHA512=y
> >>> # CONFIG_MODULE_SIG_SHA3_256 is not set
> >>> # CONFIG_MODULE_SIG_SHA3_384 is not set
> >>> # CONFIG_MODULE_SIG_SHA3_512 is not set
> >>> CONFIG_MODULE_SIG_HASH="sha512"
> >>>
> >>> With https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2802
> >>>
> >>> we can strengthen the module signing algorithm to
> >>> CONFIG_MODULE_SIG_SHA3_512.
> >>>
> >>> I'd like to do this before Fedora40, as it will be the basis of
> >>> centos-stream-10 and RHEL10.
> >>>
> >>> Thoughts or concerns?
> >>>
> >>> P.
> >>
> >> I took a closer look at this and there doesn't appear to be an issue
> >> with doing this in the kernel.  Build times and boot times seem
> >> consistent before and after the change.
> >>
> >> However, depmod (from kmod) needs an update if we make this change.  The
> >> current fedora version of kmod, -31, segfaults in the modules_install
> >> target.  I ran the latest upstream version of kmod and AFAICT that works.
> >>
> >> I will wait for kmod to be updated to at least version -32 and then
> >> request that we change the module signing algorithm to SHA3_512, unless
> >> there any objections.
> >
> > The latest kmod in fedora is -30.  I was just looking at packaging -31
> > today.  Are the above version numbers typos, or did you get kmod from
> > somewhere else?
> >
>
> Whoops.  Yep, typos.  Sorry, off by one in my brain.

OK, thanks.  I might look at the commits beyond -31 and see about
adding them if they aren't too much of a departure from the release.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: module signing: Changing to MODULE_SIG_SHA3_512

[Josh Boyer]

On Thu, Nov 9, 2023 at 8:03 AM Prarit Bhargava  wrote:
>
> On 11/8/23 08:33, Prarit Bhargava wrote:
> > Hey everyone,
> >
> > The current kernel configs generate
> >
> > # CONFIG_MODULE_SIG_FORCE is not set
> > CONFIG_MODULE_SIG_ALL=y
> > # CONFIG_MODULE_SIG_SHA256 is not set
> > # CONFIG_MODULE_SIG_SHA384 is not set
> > CONFIG_MODULE_SIG_SHA512=y
> > # CONFIG_MODULE_SIG_SHA3_256 is not set
> > # CONFIG_MODULE_SIG_SHA3_384 is not set
> > # CONFIG_MODULE_SIG_SHA3_512 is not set
> > CONFIG_MODULE_SIG_HASH="sha512"
> >
> > With https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2802
> >
> > we can strengthen the module signing algorithm to
> > CONFIG_MODULE_SIG_SHA3_512.
> >
> > I'd like to do this before Fedora40, as it will be the basis of
> > centos-stream-10 and RHEL10.
> >
> > Thoughts or concerns?
> >
> > P.
>
> I took a closer look at this and there doesn't appear to be an issue
> with doing this in the kernel.  Build times and boot times seem
> consistent before and after the change.
>
> However, depmod (from kmod) needs an update if we make this change.  The
> current fedora version of kmod, -31, segfaults in the modules_install
> target.  I ran the latest upstream version of kmod and AFAICT that works.
>
> I will wait for kmod to be updated to at least version -32 and then
> request that we change the module signing algorithm to SHA3_512, unless
> there any objections.

The latest kmod in fedora is -30.  I was just looking at packaging -31
today.  Are the above version numbers typos, or did you get kmod from
somewhere else?

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Move xpad in kernel-modules ?

[Josh Boyer]

On Wed, Dec 2, 2020 at 4:18 PM Paul Bolle  wrote:
>
> Paul Bolle schreef op wo 02-12-2020 om 21:30 [+0100]:
> > Currently there seem to be over 6000 texlive packages. (Quick and dirty
> > measurements, sorry.) So splitting the  kernel into an absurd number of
> > packages for (obscure) modules isn't a no-no on principle.
>
> If I sort the installed packages on my laptop by size the kernel-core packages
> don't even make it into the top 10.
>
> (It's a fun thing to do queries like that. glibc-all-langpacks is over 200M. I
> wonder what it does. Now I know that iwl7260-firmware is 125M! Linux firmware
> is almost 300M. Does Fedora support systems that are usable without it?)
>
> I'm guessing kernel-core and the various kernel-modules* packages total about
> 120M. So why not dump everything in a single package?

The larger your installation is, the larger the problem space you
have.  For things like VMs where you want to upload/copy them around,
you incur transfer times, potentially networking costs, etc.  At
scale, small size increases add up to large costs.

Fedora hasn't exactly taken off in the cloud or in a hyperscale
fashion, but that doesn't mean we shouldn't try to address these
things.  The Minimization objective is a larger effort around what
initially started the kernel-core/kernel-modules split to begin with.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Move xpad in kernel-modules ?

[Josh Boyer]

On Wed, Dec 2, 2020 at 3:32 PM Paul Bolle  wrote:
>
> Marcelo Ricardo Leitner schreef op wo 02-12-2020 om 17:11 [-0300]:
> > Maybe, then taking it to the extreme, less common modules can all have its
> > own rpm package ;-)
>
> Vague ideas like this crossed my mind too.
>
> The local build I just finished for v5.9.12 generated less than 4000 modules.

We already do this in the packaging virtually.  You don't need 4000
kmod RPMs.  Every module gets a Provides: kmod(.ko) listed in
whatever RPM it happens to be in.  Very few packages in userspace take
advantage of this granularity.

josh

> Currently there seem to be over 6000 texlive packages. (Quick and dirty
> measurements, sorry.) So splitting the  kernel into an absurd number of
> packages for (obscure) modules isn't a no-no on principle.
>
> (See https://utcc.utoronto.ca/~cks/space/blog/linux/FedoraTexliveFailure for
> an eloquent argument how reasonable decisions can lead to unreasonable
> outcomes in the case of Fedora's handling of texlive packages. Note that my
> laptop has currently one texlive package installed. Does that benefit me more
> than the overhead of its gazillion packages at each dnf interaction?)
>
> Thanks,
>
>
> Paul Bolle
>
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Move xpad in kernel-modules ?

[Josh Boyer]

On Wed, Dec 2, 2020 at 2:15 PM Matthew Miller  wrote:
>
> On Wed, Dec 02, 2020 at 10:31:17AM -0500, Bastien Nocera wrote:
> > You should see the hoops people go through to make their controllers work,
> > either installing user-space drivers, or finding out how to solve the 
> > problem
> > by installing the right package:
> > https://rudd-o.com/linux-and-free-software/how-to-use-your-xbox-368-controllers-under-fedora
>
> Yeah, Windows has trained gamers that fiddling with drivers is the first
> answer to any problem. This is an opportunity for us to provide a better
> experience!

FWIW, I think it's time to get rid of kernel-modules-extra entirely.
The premise originally was "put modules that aren't widely used or
that we think are of lesser quality in here, and stop building them
entirely over time".  It hasn't really paid off because we never
actually disable anything in there and it causes this kind of
installation pain.  There's value in kernel-core/kernel-modules, but
kernel-modules-extra doesn't provide much value by itself.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Upcoming Fedora kernel workflow changes

[Josh Boyer]

On Wed, Mar 11, 2020 at 1:26 PM Josh Boyer  wrote:
>
> On Wed, Mar 11, 2020 at 1:21 PM Jeremy Cline  wrote:
> >
> > On Wed, 2020-03-11 at 12:58 -0400, Josh Boyer wrote:
> > > On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline 
> > > wrote:
> > > > Hi folks,
> > > >
> > > > This should come as no surprise to those who have been following
> > > > the
> > > > kernel list and/or saw Laura's Flock talk last summer, but there
> > > > are
> > > > some changes to the way the Fedora kernel is maintained coming in
> > > > the
> > > > next couple of weeks.
> > > >
> > > > For those folks who aren't committing directly to the kernel dist-
> > > > git,
> > > > this change won't really impact you, although contributing might be
> > > > easier.
> > > >
> > > > We're planning to switch from maintaining the kernel directly in
> > > > the
> > > > dist-git to using a kernel source tree along with a set of scripts
> > > > to
> > > > turn the source tree into something that can be automatically
> > > > checked
> > > > into the dist-git. This means anything committed directly to the
> > > > dist-
> > > > git repository will get overwritten on the next update.
> > > >
> > > > The git repository is currently hosted at
> > > > https://gitlab.com/cki-project/kernel-ark/. Documentation (still
> > > > very
> > > > rough) for common tasks is at
> > > > https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a
> > > > few
> > > > outstanding merge requests to get the tree fully synced up with the
> > > > current state of the dist-git repository, so if you decide to jump
> > > > in
> > > > and try things out, be aware things might not work.
> > >
> > > This looks like it will completely remove the need for
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
> > >
> > > Is that correct?  (Please let it be correct.)
> > >
> >
> > Eventually, yes. To start with we're just going to do Rawhide this
> > way, but assuming things go well handling stable releases the same way
> > should be straight-forward.
>
> Great.  Please let me know when I can stop generating that tree.

So, that tree is now officially stopped for the rawhide branch.  The
changes in the NVR broke the script that explodes and rebuilds it, and
I'm not going to invest any time to fix it.  I'll keep it running for
the stable branches until those are converted too.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Upcoming Fedora kernel workflow changes

[Josh Boyer]

On Wed, Apr 15, 2020 at 5:32 AM Thorsten Leemhuis  wrote:
>
> Am 15.04.20 um 00:37 schrieb Jeremy Cline:
> > On Tue, 2020-04-07 at 15:33 +, Jeremy Cline wrote:
> >> On Wed, 2020-03-11 at 16:40 +, Jeremy Cline wrote:
> >>
> >> Just a note folks, the plan is to do this starting next week after
> >> the close of the v5.7 merge window.
> >
> > Okay, this is now done. You may notice a number of stale options made
> > their way back into the config files, it's on my to-do list to clean
> > this up assuming there aren't any larger fires this week.
>
> There is one thing I really dislike about the scheme (one it didn't
> notice when I took a brief look at it weeks ago; sorry): There are no
> individual patches anymore in dist-git/the srpm and that afaics violates
> the packaging guidelines.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
>
> ```
> The files MUST then be checked into the Fedora Package revision control
> system […]. Storing the files in this way allows people to use standard
> tools to visualize the changes between revisions of the files and track
> additions and removals without a layer of indirection […].
> ```
> There are other rules in the patch section that afaics are violated.
> Were those violation discussed and blessed by the
> Fedora Packaging Committee or FESCo?

I don't think the split out patches "rule" is being violated here.
They changed the source tarball to one generated from the git tree and
they don't have any patches at the dist-git level at all.  Several
other packages in Fedora already do this, such as anaconda.

> I for one would dislike such an exception, because I sometimes look at
> kernel source packages from other dists and it is always annoying when I
> can't easily see individual patches. It also makes it way harder for
> users to remove one certain patch that Fedora applied for testing or
> other reasons.
>
> So you you maybe change the scheme so individual patch files land in the
> src.rpm?

Is there a reason you can't do that in the source git tree instead?

> P.S.: The "--with-vanilla" build option afaics doesn't work anymore, as
>  patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are always
> applied.

I'm not sure --with-vanilla will exist at all with the changes here.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Upcoming Fedora kernel workflow changes

[Josh Boyer]

On Fri, Mar 13, 2020 at 9:49 AM Neal Gompa  wrote:
>
> On Fri, Mar 13, 2020 at 9:42 AM Josh Boyer  wrote:
> >
> > On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa  wrote:
> > >
> > > On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera  wrote:
> > > >
> > > >
> > > >
> > > > - Original Message -
> > > > >
> > > > >
> > > > > On 3/12/20 10:57 AM, Bastien Nocera wrote:
> > > > > >
> > > > > >
> > > > > > - Original Message -
> > > > > > 
> > > > > >> The git tags are still signed by Linus. Does that cover your 
> > > > > >> concerns?
> > > > > >
> > > > > > Not really, no. I think that multiplying the intermediaries between
> > > > > > kernel.org
> > > > > > and the Fedora repos by adding gitlab.com in the middle might not 
> > > > > > be the
> > > > > > best of ideas.
> > > > > >
> > > > > > If the Fedora security team is fine with it, I'm fine with it, and 
> > > > > > even if
> > > > > > I
> > > > > > understand the practical concerns (pagure not being up to par to 
> > > > > > deal with
> > > > > > repos that size, and without a mail gateway support), I find it 
> > > > > > slightly
> > > > > > concerning.
> > > > > >
> > > > >
> > > > > I think this boils down to how much do you trust the kernel 
> > > > > maintainers.
> > > > > Keep in mind that the existing model requires the kernel maintainers
> > > > > to manually pull down a tree and extract the tarball and then upload.
> > > > > You can probably trust them to not do anything malicious but mistakes
> > > > > can happen (source: I screwed up many times). It's good to be 
> > > > > concerned
> > > > > about provenance as a threat model but I consider maintainers screwing
> > > > > up manual tasks to be a bigger threat model to Fedora kernel security
> > > > > so anything that moves towards automation is a benefit in my eyes.
> > > >
> > > > For me, it's about how much we trust gitlab.com _in addition_ to 
> > > > trusting
> > > > kernel.org and fedoraproject.org. I wouldn't be concerned at all if
> > > > the new "in-between" tree was at either of those 2 locations.
> > >
> > > For what it's worth, while I agree, I doubt the kernel maintainers
> > > will care about that. They clearly haven't cared given that the CKI
> > > project does not run on what most in the project generally considers
> > > "trusted infrastructure".
> >
> > Fedora's "trusted infrastructure" can't scale to what CKI is doing.
> > One could argue about what trusted infrastructure means in general,
> > because in my opinion there is no such thing, but it would be entirely
> > irresponsible to overwhelm already limited capacity with something
> > that is done at the scale CKI runs.  Figuring out how to get
> > comfortable with using cloud resources for workloads where that make
> > sense is critical to our long term success.
> >
> > (FWIW, I'm trying really hard not to read your comment as a slam on
> > the kernel team here.  I also find it an interesting example of
> > cognitive dissonance that CKI running in AWS somehow triggers this
> > comment, when all of Fedora is dependent on the mirror network to
> > serve the actual binaries to users and *that* is far more risky than
> > doing build testing in the cloud that doesn't even impact end-users.)
> >
>
> I am not slamming the kernel maintainers. They're doing excellent
> work, and many of the efforts as part of the CKI project are to be
> lauded. I am also not saying cloud resources in themselves are a
> problem, but it's not like you're running on a git server hosted in
> Fedora's AWS/Azure/GCP account.
>
> My principal concern has always been that projects under the Fedora
> banner (or something like it) should be under infrastructure that the
> Fedora Project controls.

Ah.  I see, well that makes sense, yes.

> Honestly, I don't care if it's RHOSP, Fedora's AWS/Azure/GCP, or a
> server in a Red Hat office or datacenter. What I care about is that
> when push comes to shove, we're not screwed by an external force in an
> unexpected fashion in a way where we

Re: Upcoming Fedora kernel workflow changes

[Josh Boyer]

On Fri, Mar 13, 2020 at 9:51 AM Peter Robinson  wrote:
>
> > > > > >> The git tags are still signed by Linus. Does that cover your 
> > > > > >> concerns?
> > > > > >
> > > > > > Not really, no. I think that multiplying the intermediaries between
> > > > > > kernel.org
> > > > > > and the Fedora repos by adding gitlab.com in the middle might not 
> > > > > > be the
> > > > > > best of ideas.
> > > > > >
> > > > > > If the Fedora security team is fine with it, I'm fine with it, and 
> > > > > > even if
> > > > > > I
> > > > > > understand the practical concerns (pagure not being up to par to 
> > > > > > deal with
> > > > > > repos that size, and without a mail gateway support), I find it 
> > > > > > slightly
> > > > > > concerning.
> > > > > >
> > > > >
> > > > > I think this boils down to how much do you trust the kernel 
> > > > > maintainers.
> > > > > Keep in mind that the existing model requires the kernel maintainers
> > > > > to manually pull down a tree and extract the tarball and then upload.
> > > > > You can probably trust them to not do anything malicious but mistakes
> > > > > can happen (source: I screwed up many times). It's good to be 
> > > > > concerned
> > > > > about provenance as a threat model but I consider maintainers screwing
> > > > > up manual tasks to be a bigger threat model to Fedora kernel security
> > > > > so anything that moves towards automation is a benefit in my eyes.
> > > >
> > > > For me, it's about how much we trust gitlab.com _in addition_ to 
> > > > trusting
> > > > kernel.org and fedoraproject.org. I wouldn't be concerned at all if
> > > > the new "in-between" tree was at either of those 2 locations.
> > >
> > > For what it's worth, while I agree, I doubt the kernel maintainers
> > > will care about that. They clearly haven't cared given that the CKI
> > > project does not run on what most in the project generally considers
> > > "trusted infrastructure".
> >
> > Fedora's "trusted infrastructure" can't scale to what CKI is doing.
> > One could argue about what trusted infrastructure means in general,
> > because in my opinion there is no such thing, but it would be entirely
> > irresponsible to overwhelm already limited capacity with something
> > that is done at the scale CKI runs.  Figuring out how to get
> > comfortable with using cloud resources for workloads where that make
> > sense is critical to our long term success.
>
> And git repos should be verifiable to the upstream so I believe this
> should be no worse than any other git ecosystem.
>
> > (FWIW, I'm trying really hard not to read your comment as a slam on
> > the kernel team here.  I also find it an interesting example of
> > cognitive dissonance that CKI running in AWS somehow triggers this
> > comment, when all of Fedora is dependent on the mirror network to
> > serve the actual binaries to users and *that* is far more risky than
> > doing build testing in the cloud that doesn't even impact end-users.)
>
> Package/repo signing mitigates that, but that can also be done in the
> git side of things too.

Provenance isn't what I was phrasing as risky.  We depend on the
mirror network to scale, which is entirely outside of our control and
if they decide it's no longer worth distributing Fedora binaries we'd
be screwed.  It's the exact concern Neal has :)

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Upcoming Fedora kernel workflow changes

[Josh Boyer]

On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa  wrote:
>
> On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera  wrote:
> >
> >
> >
> > - Original Message -
> > >
> > >
> > > On 3/12/20 10:57 AM, Bastien Nocera wrote:
> > > >
> > > >
> > > > - Original Message -
> > > > 
> > > >> The git tags are still signed by Linus. Does that cover your concerns?
> > > >
> > > > Not really, no. I think that multiplying the intermediaries between
> > > > kernel.org
> > > > and the Fedora repos by adding gitlab.com in the middle might not be the
> > > > best of ideas.
> > > >
> > > > If the Fedora security team is fine with it, I'm fine with it, and even 
> > > > if
> > > > I
> > > > understand the practical concerns (pagure not being up to par to deal 
> > > > with
> > > > repos that size, and without a mail gateway support), I find it slightly
> > > > concerning.
> > > >
> > >
> > > I think this boils down to how much do you trust the kernel maintainers.
> > > Keep in mind that the existing model requires the kernel maintainers
> > > to manually pull down a tree and extract the tarball and then upload.
> > > You can probably trust them to not do anything malicious but mistakes
> > > can happen (source: I screwed up many times). It's good to be concerned
> > > about provenance as a threat model but I consider maintainers screwing
> > > up manual tasks to be a bigger threat model to Fedora kernel security
> > > so anything that moves towards automation is a benefit in my eyes.
> >
> > For me, it's about how much we trust gitlab.com _in addition_ to trusting
> > kernel.org and fedoraproject.org. I wouldn't be concerned at all if
> > the new "in-between" tree was at either of those 2 locations.
>
> For what it's worth, while I agree, I doubt the kernel maintainers
> will care about that. They clearly haven't cared given that the CKI
> project does not run on what most in the project generally considers
> "trusted infrastructure".

Fedora's "trusted infrastructure" can't scale to what CKI is doing.
One could argue about what trusted infrastructure means in general,
because in my opinion there is no such thing, but it would be entirely
irresponsible to overwhelm already limited capacity with something
that is done at the scale CKI runs.  Figuring out how to get
comfortable with using cloud resources for workloads where that make
sense is critical to our long term success.

(FWIW, I'm trying really hard not to read your comment as a slam on
the kernel team here.  I also find it an interesting example of
cognitive dissonance that CKI running in AWS somehow triggers this
comment, when all of Fedora is dependent on the mirror network to
serve the actual binaries to users and *that* is far more risky than
doing build testing in the cloud that doesn't even impact end-users.)

josh

> I also am personally not a fan of the "source-git" approach for
> various reasons (including that it makes it *much* more difficult to
> identify downstream vs upstream changes, more easily leading to
> forks), but the kernel team actively contributes to upstream and our
> current policy makes it incredibly difficult to have non-upstream
> changes in the kernel, so I'm less worried there.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Upcoming Fedora kernel workflow changes

[Josh Boyer]

On Wed, Mar 11, 2020 at 1:21 PM Jeremy Cline  wrote:
>
> On Wed, 2020-03-11 at 12:58 -0400, Josh Boyer wrote:
> > On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline 
> > wrote:
> > > Hi folks,
> > >
> > > This should come as no surprise to those who have been following
> > > the
> > > kernel list and/or saw Laura's Flock talk last summer, but there
> > > are
> > > some changes to the way the Fedora kernel is maintained coming in
> > > the
> > > next couple of weeks.
> > >
> > > For those folks who aren't committing directly to the kernel dist-
> > > git,
> > > this change won't really impact you, although contributing might be
> > > easier.
> > >
> > > We're planning to switch from maintaining the kernel directly in
> > > the
> > > dist-git to using a kernel source tree along with a set of scripts
> > > to
> > > turn the source tree into something that can be automatically
> > > checked
> > > into the dist-git. This means anything committed directly to the
> > > dist-
> > > git repository will get overwritten on the next update.
> > >
> > > The git repository is currently hosted at
> > > https://gitlab.com/cki-project/kernel-ark/. Documentation (still
> > > very
> > > rough) for common tasks is at
> > > https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a
> > > few
> > > outstanding merge requests to get the tree fully synced up with the
> > > current state of the dist-git repository, so if you decide to jump
> > > in
> > > and try things out, be aware things might not work.
> >
> > This looks like it will completely remove the need for
> > https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
> >
> > Is that correct?  (Please let it be correct.)
> >
>
> Eventually, yes. To start with we're just going to do Rawhide this
> way, but assuming things go well handling stable releases the same way
> should be straight-forward.

Great.  Please let me know when I can stop generating that tree.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Upcoming Fedora kernel workflow changes

[Josh Boyer]

On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline  wrote:
>
> Hi folks,
>
> This should come as no surprise to those who have been following the
> kernel list and/or saw Laura's Flock talk last summer, but there are
> some changes to the way the Fedora kernel is maintained coming in the
> next couple of weeks.
>
> For those folks who aren't committing directly to the kernel dist-git,
> this change won't really impact you, although contributing might be
> easier.
>
> We're planning to switch from maintaining the kernel directly in the
> dist-git to using a kernel source tree along with a set of scripts to
> turn the source tree into something that can be automatically checked
> into the dist-git. This means anything committed directly to the dist-
> git repository will get overwritten on the next update.
>
> The git repository is currently hosted at
> https://gitlab.com/cki-project/kernel-ark/. Documentation (still very
> rough) for common tasks is at
> https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few
> outstanding merge requests to get the tree fully synced up with the
> current state of the dist-git repository, so if you decide to jump in
> and try things out, be aware things might not work.

This looks like it will completely remove the need for
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git

Is that correct?  (Please let it be correct.)

josh

>
> As part of this, we're going to start bridging merge requests to this
> list as emailed patch series for those who prefer email, and turn any
> emailed patches to the list into merge requests, so the list is going
> to get quite a bit more traffic.
>
> Regards,
> Jeremy
>
>
>
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Discussion: what would not blocking on btrfs look like?

[Josh Boyer]

On Wed, Aug 28, 2019 at 2:40 PM Josef Bacik  wrote:
>
> On Wed, Aug 28, 2019 at 02:35:39PM -0400, Laura Abbott wrote:
> > On 8/28/19 1:58 PM, Josef Bacik wrote:
> > > On Tue, Aug 27, 2019 at 07:53:20AM -0400, Laura Abbott wrote:
> > > > On 8/26/19 11:39 PM, Neal Gompa wrote:
> > > > > On Mon, Aug 26, 2019 at 11:16 AM Laura Abbott  
> > > > > wrote:
> > > > > >
> > > > > > On 8/23/19 9:00 PM, Chris Murphy wrote:
> > > > > > > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson
> > > > > > >  wrote:
> > > > > > >
> > > > > > > > So, there was recently a Thing where btrfs installs were 
> > > > > > > > broken, and
> > > > > > > > this got accepted as a release blocker:
> > > > > > > >
> > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388
> > > > > > >
> > > > > > > Summary: This bug was introduced and discovered in linux-next, it
> > > > > > > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch
> > > > > > > appeared during rc1, and the patch was merged into 5.3.0-rc2. The 
> > > > > > > bug
> > > > > > > resulted in a somewhat transient deadlock which caused installs to
> > > > > > > hang, but no corruption. The fix, 2 files changed, 12 insertions, 
> > > > > > > 8
> > > > > > > deletions (1/2 the insertions are comments).
> > > > > > >
> > > > > > > How remarkable or interesting is this bug? And in particular, 
> > > > > > > exactly
> > > > > > > how much faster should it have been fixed in order to avoid 
> > > > > > > worrying
> > > > > > > about it being a blocker bug?
> > > > > > >
> > > > > > > 7/25 14:27 utc bug patch was submitted to linux-btrfs@
> > > > > > > 7/25 22:33 utc bug was first reported in Fedora bugzilla
> > > > > > > 7/26 19:20 utc I confirmed upstream's patch related to this bug 
> > > > > > > with
> > > > > > > upstream and updated the Fedora bug
> > > > > > > 7/26 22:50 utc I confirmed it was merged into rc2, and updated 
> > > > > > > the Fedora bug
> > > > > > >
> > > > > > > So in the context of status quo, where Btrfs is presented as an 
> > > > > > > option
> > > > > > > in the installer and if there are bugs they Beta blocking, how 
> > > > > > > could
> > > > > > > or should this have been fixed sooner? What about the handling 
> > > > > > > should
> > > > > > > have been different?
> > > > > > >
> > > > > >
> > > > > > That's a fair question. This bug actually represents how this 
> > > > > > _should_
> > > > > > work. The concern is that in the past we haven't seen a lot 
> > > > > > engagement
> > > > > > in the past. Maybe today that has changed as demonstrated by this 
> > > > > > thread.
> > > > > > I'm still concerned about having this be a blocker vs. just keeping 
> > > > > > it
> > > > > > as an option, simply because a blocker stops the entire release and 
> > > > > > it
> > > > > > can be a last minute scramble to get things fixed. This was the 
> > > > > > ideal
> > > > > > case for a blocker bugs and I'm skeptical about all bugs going this 
> > > > > > well.
> > > > > > If we had a few more people who were willing to be on the btrfs 
> > > > > > alias and
> > > > > > do the work for blocker bugs it would be a much stronger case.
> > > > > >
> > > > >
> > > > > Out of curiosity, how many such issues have we had in the past 2
> > > > > years? I personally can't recall any monumental occasions where people
> > > > > were scrambling over *Btrfs* in Fedora. If anything, we continue to
> > > > > inherit the work that SUSE and Facebook are doing upstream as part of
> > > > > us continually updating our kernels, which I'm grateful for.
> > > > >
> > > > > And in the instances where we've had such issues, has anyone reached
> > > > > out to btrfs folks in Fedora? Chris and myself are the current ones,
> > > > > but there have been others in the past. Both of us are subscribed to
> > > > > the linux-btrfs mailing list, and Chris has a decent rapport with most
> > > > > of the btrfs developers.
> > > > >
> > > > > What more do you want? Actual btrfs developers in Fedora? We don't
> > > > > have any for the majority of filesystems Fedora supports, only XFS. Is
> > > > > there some kind of problem with communicating with the upstream kernel
> > > > > developers about Fedora bugs that I'm not aware of?
> > > > >
> > > >
> > > > Again, it's about length of overall development. ext and XFS have
> > > > a much longer history in general which is something that's important
> > > > for file system stability in general. It's also a bit of a catch-22
> > > > where the rate of btrfs use in Fedora is so low we don't actually
> > > > see issues.
> > > >
> > > > > > > I note here that ext2 and ext3 are offered as file systems in
> > > > > > > Custom/Advanced partitioning and in this sense have parity with 
> > > > > > > Btrfs.
> > > > > > > If this same bug occurred in ext2 or ext3 would or should that 
> > > > > > > cause
> > > > > > > discussion to drop them from the installer, even if the bug were 
> > > > > > > fixed
> > > > > > > within 24 hours of discovery 

Re: Discussion: what would not blocking on btrfs look like?

[Josh Boyer]

On Tue, Aug 27, 2019 at 8:48 AM Neal Gompa  wrote:
>
> On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer  wrote:
> >
> > On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa  wrote:
> > >
> > > On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer  
> > > wrote:
> > > >
> > > > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa  wrote:
> > > > >
> > > > > On Tue, Aug 27, 2019 at 5:55 AM  wrote:
> > > > > >
> > > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > > > > > > On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > > > > > > >
> > > > > > > > I understand them. The point is, for them and even us (the
> > > > > > > > installer)
> > > > > > > > is work on BTRFS not a priority. It's something we can't 
> > > > > > > > benefit on
> > > > > > > > RHEL and it could be almost completely replaced by LVM + xfs
> > > > > > > > solution.
> > > > > > > > However, it still giving us bugs and making our test surface
> > > > > > > > bigger.
> > > > > > > >
> > > > > > > > > From the Anaconda team PoV it would make our lives easier to 
> > > > > > > > > not
> > > > > > > > support BTRFS at all. I'm not saying that we should drop BTRFS 
> > > > > > > > in
> > > > > > > > Fedora, only that it would be easier for Anaconda team to be
> > > > > > > > without
> > > > > > > > that on Fedora.
> > > > > > >
> > > > > > > This is flat-out a trap. This is what makes Anaconda such a 
> > > > > > > failure
> > > > > > > as
> > > > > > > a community project. Why does the past (RHEL) affect the present 
> > > > > > > and
> > > > > > > future (Fedora)? There's basically no way whatsoever to make 
> > > > > > > anything
> > > > > > > better with this logic. The Anaconda releases that any 
> > > > > > > improvements
> > > > > > > would be going into aren't even landing into the RHEL 8 branch 
> > > > > > > that
> > > > > > > governs the latest iteration of Fedora's past. From any reasonable
> > > > > > > person's perspective, this answer makes no sense unless you're 
> > > > > > > using
> > > > > > > RHEL as an excuse to not support Fedora.
> > > > > > >
> > > > > >
> > > > > > RHEL is not the past. Everything we do we have to think that it 
> > > > > > will go
> > > > > > to RHEL and if it is Fedora specific we have to create a way to 
> > > > > > disable
> > > > > > the functionality for another RHEL branching. And yes, we have a few
> > > > > > things (not only a BTRFS) specific to Fedora the same way as a few
> > > > > > things specific to RHEL which are disabled on Fedora.
> > > > > >
> > > > > > And as I wrote before, I'm not saying that we will remove the BTRFS
> > > > > > support from Fedora. The point is that making the list specific to
> > > > > > releases smaller will make our live easier.
> > > > > >
> > > > >
> > > > > By definition, RHEL *is* the past from a Fedora context. It's forked
> > > > > from an old version of Fedora that's not supported anymore. It is the
> > > > > result of decisions that aren't supposed to apply to Fedora. And it is
> > > > > the result of a different bias that should never apply to Fedora if
> > > > > the RH ecosystem is supposed to be able to evolve.
> > > >
> > > > There is always the *next* RHEL.  Or, if you want to remove a product
> > > > context, the next enterprise operating system derived from Fedora.
> > > > RHEL/enterprise is both past and future and Fedora focuses on the
> > > > future.  You cannot dismiss enterprise as a target by waiving it away
> > > > as "past".
> > > >
> > >
> > > Until there's a branch in Anaconda's git for the next version of RHEL,
> > > it doesn't exist yet. I'm sure people are *thinking* about it, but
> > > it's obviously on 

Re: Discussion: what would not blocking on btrfs look like?

[Josh Boyer]

On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa  wrote:
>
> On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer  wrote:
> >
> > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa  wrote:
> > >
> > > On Tue, Aug 27, 2019 at 5:55 AM  wrote:
> > > >
> > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > > > > On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > > > > >
> > > > > > I understand them. The point is, for them and even us (the
> > > > > > installer)
> > > > > > is work on BTRFS not a priority. It's something we can't benefit on
> > > > > > RHEL and it could be almost completely replaced by LVM + xfs
> > > > > > solution.
> > > > > > However, it still giving us bugs and making our test surface
> > > > > > bigger.
> > > > > >
> > > > > > > From the Anaconda team PoV it would make our lives easier to not
> > > > > > support BTRFS at all. I'm not saying that we should drop BTRFS in
> > > > > > Fedora, only that it would be easier for Anaconda team to be
> > > > > > without
> > > > > > that on Fedora.
> > > > >
> > > > > This is flat-out a trap. This is what makes Anaconda such a failure
> > > > > as
> > > > > a community project. Why does the past (RHEL) affect the present and
> > > > > future (Fedora)? There's basically no way whatsoever to make anything
> > > > > better with this logic. The Anaconda releases that any improvements
> > > > > would be going into aren't even landing into the RHEL 8 branch that
> > > > > governs the latest iteration of Fedora's past. From any reasonable
> > > > > person's perspective, this answer makes no sense unless you're using
> > > > > RHEL as an excuse to not support Fedora.
> > > > >
> > > >
> > > > RHEL is not the past. Everything we do we have to think that it will go
> > > > to RHEL and if it is Fedora specific we have to create a way to disable
> > > > the functionality for another RHEL branching. And yes, we have a few
> > > > things (not only a BTRFS) specific to Fedora the same way as a few
> > > > things specific to RHEL which are disabled on Fedora.
> > > >
> > > > And as I wrote before, I'm not saying that we will remove the BTRFS
> > > > support from Fedora. The point is that making the list specific to
> > > > releases smaller will make our live easier.
> > > >
> > >
> > > By definition, RHEL *is* the past from a Fedora context. It's forked
> > > from an old version of Fedora that's not supported anymore. It is the
> > > result of decisions that aren't supposed to apply to Fedora. And it is
> > > the result of a different bias that should never apply to Fedora if
> > > the RH ecosystem is supposed to be able to evolve.
> >
> > There is always the *next* RHEL.  Or, if you want to remove a product
> > context, the next enterprise operating system derived from Fedora.
> > RHEL/enterprise is both past and future and Fedora focuses on the
> > future.  You cannot dismiss enterprise as a target by waiving it away
> > as "past".
> >
>
> Until there's a branch in Anaconda's git for the next version of RHEL,
> it doesn't exist yet. I'm sure people are *thinking* about it, but
> it's obviously on the back burner for a little while. I would expect
> to start to see a rhel-9 branch in Anaconda in 1.5 years, but for now
> it doesn't exist.

In 1.5 years is entirely too late.  Massively so.  I know people think
we're paying lip-service to upstream when discussing Fedora and RHEL,
but even with a terrible "import once" model the code being developed
in Fedora right now will materially land in RHEL 9.  Your presumption
on a branch needing to exist is simply incorrect.

> > > From the way you describe it, Fedora is just something occasionally
> > > give lip service to while your main focus is RHEL. That's fine, but
> > > that is a problem for the Fedora context.
> >
> > Neal, I don't understand.  The source code to anaconda is available.
> > What is preventing you from taking it and making a micro-fork that
> > does better btrfs enablement, and packaging that in Fedora and using
> > it in a spin?
> >
>
> I have seriously contemplated it. It isn't the first time I've done a
> fork because I had to[1].
>
> But the main reason I don't do it is because it will cause mor

Re: Discussion: what would not blocking on btrfs look like?

[Josh Boyer]

On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa  wrote:
>
> On Tue, Aug 27, 2019 at 5:55 AM  wrote:
> >
> > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > > On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > > >
> > > > I understand them. The point is, for them and even us (the
> > > > installer)
> > > > is work on BTRFS not a priority. It's something we can't benefit on
> > > > RHEL and it could be almost completely replaced by LVM + xfs
> > > > solution.
> > > > However, it still giving us bugs and making our test surface
> > > > bigger.
> > > >
> > > > > From the Anaconda team PoV it would make our lives easier to not
> > > > support BTRFS at all. I'm not saying that we should drop BTRFS in
> > > > Fedora, only that it would be easier for Anaconda team to be
> > > > without
> > > > that on Fedora.
> > >
> > > This is flat-out a trap. This is what makes Anaconda such a failure
> > > as
> > > a community project. Why does the past (RHEL) affect the present and
> > > future (Fedora)? There's basically no way whatsoever to make anything
> > > better with this logic. The Anaconda releases that any improvements
> > > would be going into aren't even landing into the RHEL 8 branch that
> > > governs the latest iteration of Fedora's past. From any reasonable
> > > person's perspective, this answer makes no sense unless you're using
> > > RHEL as an excuse to not support Fedora.
> > >
> >
> > RHEL is not the past. Everything we do we have to think that it will go
> > to RHEL and if it is Fedora specific we have to create a way to disable
> > the functionality for another RHEL branching. And yes, we have a few
> > things (not only a BTRFS) specific to Fedora the same way as a few
> > things specific to RHEL which are disabled on Fedora.
> >
> > And as I wrote before, I'm not saying that we will remove the BTRFS
> > support from Fedora. The point is that making the list specific to
> > releases smaller will make our live easier.
> >
>
> By definition, RHEL *is* the past from a Fedora context. It's forked
> from an old version of Fedora that's not supported anymore. It is the
> result of decisions that aren't supposed to apply to Fedora. And it is
> the result of a different bias that should never apply to Fedora if
> the RH ecosystem is supposed to be able to evolve.

There is always the *next* RHEL.  Or, if you want to remove a product
context, the next enterprise operating system derived from Fedora.
RHEL/enterprise is both past and future and Fedora focuses on the
future.  You cannot dismiss enterprise as a target by waiving it away
as "past".

> From the way you describe it, Fedora is just something occasionally
> give lip service to while your main focus is RHEL. That's fine, but
> that is a problem for the Fedora context.

Neal, I don't understand.  The source code to anaconda is available.
What is preventing you from taking it and making a micro-fork that
does better btrfs enablement, and packaging that in Fedora and using
it in a spin?

My guess would be that you perhaps don't have the time to do that.
That's reasonable.  I can say, with no uncertainty, that the anaconda
team doesn't have time to do it either.  The day to day things that
team is working on far outweigh btrfs as a priority, even in Fedora.
This team literally gets dozens of completely unrelated bugs they have
to look at and triage simply because it is the first thing people
interact with when they install the OS.  It's a catch-all.  Btrfs
enablement would continually sit on the back burner waiting to get
done.

Before you think I'm being naive or disingenuous, I'm truly not.  I
understand the frustration of wanting to get code into a project or
product that isn't willing to take that code.  However, it's not only
about the code.  The code review and acceptance isn't the end of the
time investment.  It is the start.  There's test cases, test
infrastructure, debugging support issues, on-going code changes and
refactoring, etc etc.  One of the ways to limit these impacts is to be
selective in what enablement you choose to bring into a project.  That
is what the anaconda team is doing here.  The beauty (and ugly!) of
open source is that you can still take the code and do what you want
if you are willing to make that investment.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Support buildid in kernel-headers

[Josh Boyer]

On Wed, Aug 21, 2019 at 2:47 PM Paul Moore  wrote:
>
> Hello,
>
> Last year there was a change to how the kernel-headers package is
> built, and unfortunately that change made it so that changes to the
> kernel's buildid variable do not carryover to the the kernel-header's
> build.  While I recognize that this is problem that only affects a
> small number of people, it would be nice to see this fixed.
>
> I'm attaching a small patch which fixes this for my use case, and

The list strips attachments.  Can you send it inline?

josh

> while I think it is a generic solution, I can't say I've spent enough
> time looking at it to say for certain.  I'm putting it out here as a
> way to help describe the problem as well as one possible solution.  If
> you have a different/better approach that's fine with me, I just want
> to see the buildid reflected in the kernel-header package build so I
> can drop this patch from my build process :)
>
> --
> paul moore
> www.paul-moore.com
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [PATCH 6/9] Remove some old modalias adjustments

[Josh Boyer]

On Thu, Aug 15, 2019 at 3:58 PM Laura Abbott  wrote:
>
> We've come a long way. Let's just leave these drivers alone.

Can we not build them at all instead?  Or put them in modules-extra if
we're too chicken to disable them entirely.

josh

> Signed-off-by: Laura Abbott 
> ---
>  die-floppy-die.patch | 29 -
>  kernel.spec  |  4 
>  no-pcspkr-modalias.patch | 22 --
>  3 files changed, 55 deletions(-)
>  delete mode 100644 die-floppy-die.patch
>  delete mode 100644 no-pcspkr-modalias.patch
>
> diff --git a/die-floppy-die.patch b/die-floppy-die.patch
> deleted file mode 100644
> index caaa2dde5..0
> --- a/die-floppy-die.patch
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -From: Kyle McMartin 
> -Date: Tue, 30 Mar 2010 00:04:29 -0400
> -Subject: [PATCH] die-floppy-die
> -
> -Kill the floppy.ko pnp modalias. We were surviving just fine without
> -autoloading floppy drivers, tyvm.
> -
> -Please feel free to register all complaints in the wastepaper bin.
> -
> -Bugzilla: N/A
> -Upstream-status: Fedora mustard
> 
> - drivers/block/floppy.c | 3 +--
> - 1 file changed, 1 insertion(+), 2 deletions(-)
> -
> -diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> -index a08cda955285..e320e1e679cf 100644
>  a/drivers/block/floppy.c
> -+++ b/drivers/block/floppy.c
> -@@ -4633,8 +4633,7 @@ static const struct pnp_device_id floppy_pnpids[] = {
> -   {"PNP0700", 0},
> -   {}
> - };
> --
> --MODULE_DEVICE_TABLE(pnp, floppy_pnpids);
> -+/* MODULE_DEVICE_TABLE(pnp, floppy_pnpids); */
> -
> - #else
> -
> diff --git a/kernel.spec b/kernel.spec
> index 1a7af5cd4..0e9ba6be4 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -497,10 +497,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
>
>  Patch111: input-kill-stupid-messages.patch
>
> -Patch112: die-floppy-die.patch
> -
> -Patch113: no-pcspkr-modalias.patch
> -
>  Patch115: Kbuild-Add-an-option-to-enable-GCC-VTA.patch
>
>  Patch116: crash-driver.patch
> diff --git a/no-pcspkr-modalias.patch b/no-pcspkr-modalias.patch
> deleted file mode 100644
> index 2ccd87202..0
> --- a/no-pcspkr-modalias.patch
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -From: "kernel-t...@fedoraproject.org" 
> -Date: Thu, 29 Jul 2010 16:46:31 -0700
> -Subject: [PATCH] no pcspkr modalias
> -
> -Bugzilla: N/A
> -Upstream-status: Fedora mustard
> 
> - drivers/input/misc/pcspkr.c | 1 -
> - 1 file changed, 1 deletion(-)
> -
> -diff --git a/drivers/input/misc/pcspkr.c b/drivers/input/misc/pcspkr.c
> -index 56ddba21de84..23534f420e68 100644
>  a/drivers/input/misc/pcspkr.c
> -+++ b/drivers/input/misc/pcspkr.c
> -@@ -23,7 +23,6 @@
> - MODULE_AUTHOR("Vojtech Pavlik ");
> - MODULE_DESCRIPTION("PC Speaker beeper driver");
> - MODULE_LICENSE("GPL");
> --MODULE_ALIAS("platform:pcspkr");
> -
> - static int pcspkr_event(struct input_dev *dev, unsigned int type,
> -   unsigned int code, int value)
> --
> 2.21.0
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [PATCH 2/9] Drop cpumask auto select patch

[Josh Boyer]

On Thu, Aug 15, 2019 at 3:57 PM Laura Abbott  wrote:
>
> We've been carrying a patch to make CPUMASK_OFFSTACK selectable
> without debugging for a long time now. The comment said this was
> going to be replaced with something else but that never seemed
> to happen. We're carrying it to have a higher number of CPUs but
> at this point I don't think it's worth it since the upper bound is
> now 512. This should be enough for most Fedora use cases so just
> drop the patch.

I likely agree, but copying Prarit because this was something he and I
poked at forever ago.

josh

> Signed-off-by: Laura Abbott 
> ---
>  .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS  |  2 +-
>  kernel.spec   |  2 --
>  ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 ---
>  3 files changed, 1 insertion(+), 37 deletions(-)
>  delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
>
> diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS 
> b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
> index 27d187f4d..9ce2b2de6 100644
> --- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
> +++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
> @@ -1 +1 @@
> -CONFIG_NR_CPUS=1024
> +CONFIG_NR_CPUS=512
> diff --git a/kernel.spec b/kernel.spec
> index a662ee004..4253ff035 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -495,8 +495,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
>  # Standalone patches
>  # 100 - Generic long running patches
>
> -Patch110: lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
> -
>  Patch111: input-kill-stupid-messages.patch
>
>  Patch112: die-floppy-die.patch
> diff --git a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch 
> b/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
> deleted file mode 100644
> index 5e6d6611e..00000
> --- a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -From: Josh Boyer 
> -Date: Mon, 11 Nov 2013 08:39:16 -0500
> -Subject: [PATCH] lib/cpumask: Make CPUMASK_OFFSTACK usable without debug
> - dependency
> -
> -When CPUMASK_OFFSTACK was added in 2008, it was dependent upon
> -DEBUG_PER_CPU_MAPS being enabled, or an architecture could select it.
> -The debug dependency adds additional overhead that isn't required for
> -operation of the feature, and we need CPUMASK_OFFSTACK to increase the
> -NR_CPUS value beyond 512 on x86.  We drop the current dependency and make
> -sure SMP is set.
> -
> -Bugzilla: N/A
> -Upstream-status: Nak'd, supposedly replacement coming to auto-select
> -
> -Signed-off-by: Josh Boyer 
> 
> - lib/Kconfig | 3 ++-
> - 1 file changed, 2 insertions(+), 1 deletion(-)
> -
> -diff --git a/lib/Kconfig b/lib/Kconfig
> -index 3a2ef67db6c7..4af1e7e5a611 100644
>  a/lib/Kconfig
> -+++ b/lib/Kconfig
> -@@ -396,7 +396,8 @@ config CHECK_SIGNATURE
> -   bool
> -
> - config CPUMASK_OFFSTACK
> --  bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
> -+  bool "Force CPU masks off stack"
> -+  depends on SMP
> -   help
> - Use dynamic allocation for cpumask_var_t, instead of putting
> - them on the stack.  This is a bit more expensive, but avoids
> --
> 2.21.0
>
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [PATCH 9/9] Remove crash driver

[Josh Boyer]

On Thu, Aug 15, 2019 at 4:02 PM Laura Abbott  wrote:
>
> This has since been replaced by other in kernel pieces. We
> can finally drop it.

Which pieces?

josh

>
> Signed-off-by: Laura Abbott 
> ---
>  crash-driver.patch | 722 -
>  kernel.spec|   2 -
>  2 files changed, 724 deletions(-)
>  delete mode 100644 crash-driver.patch
>
> diff --git a/crash-driver.patch b/crash-driver.patch
> deleted file mode 100644
> index 164dc90f5..0
> --- a/crash-driver.patch
> +++ /dev/null
> @@ -1,722 +0,0 @@
> -From 973e23bf27b0b2e5021321357fc570cccea3104c Mon Sep 17 00:00:00 2001
> -From: Dave Anderson 
> -Date: Tue, 26 Nov 2013 12:42:46 -0500
> -Subject: [PATCH] crash-driver
> -
> -Bugzilla: N/A
> -Upstream-status: Fedora mustard
> 
> - arch/arm/include/asm/crash-driver.h |   6 ++
> - arch/arm64/include/asm/crash-driver.h   |   6 ++
> - arch/ia64/include/asm/crash-driver.h|  90 ++
> - arch/ia64/kernel/ia64_ksyms.c   |   3 +
> - arch/powerpc/include/asm/crash-driver.h |   6 ++
> - arch/s390/include/asm/crash-driver.h|  60 +++
> - arch/s390/mm/maccess.c  |   2 +
> - arch/x86/include/asm/crash-driver.h |   6 ++
> - drivers/char/Kconfig|   3 +
> - drivers/char/Makefile   |   2 +
> - drivers/char/crash.c| 128 
> 
> - include/asm-generic/crash-driver.h  |  72 ++
> - 12 files changed, 384 insertions(+)
> - create mode 100644 arch/arm/include/asm/crash-driver.h
> - create mode 100644 arch/arm64/include/asm/crash-driver.h
> - create mode 100644 arch/ia64/include/asm/crash-driver.h
> - create mode 100644 arch/powerpc/include/asm/crash-driver.h
> - create mode 100644 arch/s390/include/asm/crash-driver.h
> - create mode 100644 arch/x86/include/asm/crash-driver.h
> - create mode 100644 drivers/char/crash.c
> - create mode 100644 include/asm-generic/crash-driver.h
> -
> -diff --git a/arch/arm/include/asm/crash-driver.h 
> b/arch/arm/include/asm/crash-driver.h
> -new file mode 100644
> -index 000..06e7ae9
>  /dev/null
> -+++ b/arch/arm/include/asm/crash-driver.h
> -@@ -0,0 +1,6 @@
> -+#ifndef _ARM_CRASH_H
> -+#define _ARM_CRASH_H
> -+
> -+#include 
> -+
> -+#endif /* _ARM_CRASH_H */
> -diff --git a/arch/arm64/include/asm/crash-driver.h 
> b/arch/arm64/include/asm/crash-driver.h
> -new file mode 100644
> -index 000..43b26da
>  /dev/null
> -+++ b/arch/arm64/include/asm/crash-driver.h
> -@@ -0,0 +1,6 @@
> -+#ifndef _ARM64_CRASH_H
> -+#define _ARM64_CRASH_H
> -+
> -+#include 
> -+
> -+#endif /* _ARM64_CRASH_H */
> -diff --git a/arch/ia64/include/asm/crash-driver.h 
> b/arch/ia64/include/asm/crash-driver.h
> -new file mode 100644
> -index 000..404bcb9
>  /dev/null
> -+++ b/arch/ia64/include/asm/crash-driver.h
> -@@ -0,0 +1,90 @@
> -+#ifndef _ASM_IA64_CRASH_H
> -+#define _ASM_IA64_CRASH_H
> -+
> -+/*
> -+ * linux/include/asm-ia64/crash-driver.h
> -+ *
> -+ * Copyright (c) 2004 Red Hat, Inc. All rights reserved.
> -+ *
> -+ * This program is free software; you can redistribute it and/or modify
> -+ * it under the terms of the GNU General Public License as published by
> -+ * the Free Software Foundation; either version 2, or (at your option)
> -+ * any later version.
> -+ *
> -+ * This program is distributed in the hope that it will be useful,
> -+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> -+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> -+ * GNU General Public License for more details.
> -+ *
> -+ * You should have received a copy of the GNU General Public License
> -+ * along with this program; if not, write to the Free Software
> -+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> -+ *
> -+ */
> -+
> -+#ifdef __KERNEL__
> -+
> -+#include 
> -+#include 
> -+#include 
> -+
> -+static inline void *
> -+map_virtual(u64 offset, struct page **pp)
> -+{
> -+  struct page *page;
> -+  unsigned long pfn;
> -+  u32 type;
> -+
> -+  if (REGION_NUMBER(offset) == 5) {
> -+  char byte;
> -+
> -+  if (__get_user(byte, (char *)offset) == 0)
> -+  return (void *)offset;
> -+  else
> -+  return NULL;
> -+  }
> -+
> -+  switch (type = efi_mem_type(offset))
> -+  {
> -+  case EFI_LOADER_CODE:
> -+  case EFI_LOADER_DATA:
> -+  case EFI_BOOT_SERVICES_CODE:
> -+  case EFI_BOOT_SERVICES_DATA:
> -+  case EFI_CONVENTIONAL_MEMORY:
> -+  break;
> -+
> -+  default:
> -+  printk(KERN_INFO
> -+  "crash memory driver: invalid memory type for %lx: %d\n",
> -+  offset, type);
> -+  return NULL;
> -+  }
> -+
> -+  pfn = offset >> PAGE_SHIFT;
> -+
> -+  if (!pfn_valid(pfn)) {
> -+  printk(KERN_INFO
> -+  "crash 

Re: Certificate used to sign Fedora kernels for UEFI Secure Boot?

[Josh Boyer]

On Mon, Aug 12, 2019 at 11:23 AM Paul Moore  wrote:
>
> On Fri, Aug 9, 2019 at 8:31 AM Paul Moore  wrote:
> >
> > Hello all,
> >
> > I'm not sure if this is the place for this, but if not perhaps you
> > could point me in the right direction?
> >
> > I'm looking for the certificate associated with the key used to sign
> > the Fedora kernels for UEFI Secure Boot.  What little information I've
> > found indicates that it should be part of the "shim" package sources,
> > but it isn't there, and looking back and random points in it's history
> > I can't seem to find it.  I've found the CA used to sign this mystery
> > certificate, but not the kernel's signing certificate.  Any help you
> > can provide would be appreciated.
> >
> > For reference, this is the certificate I'm looking for:
> >
> > Signer #0:
> >Subject: /CN=Fedora Secure Boot Signer
> >Issuer : /CN=Fedora Secure Boot CA
> >Serial : 9976F70F
> >
> > ... and no, I'm obviously not asking for the private key, just an
> > authoritative source for the public key certificate :)
>
> Nobody knows where to find the "CN=Fedora Secure Boot Signer"
> certificate?  That's a little scary :)

The people that can answer this question were all at Flock last week
and are traveling back from it now.

Generally speaking, Fedora infrastructure has a key they use that two
specific build hosts have access to.

josh

> I guess I can just extract it from the signed kernel image and verify
> it with the CA but that seems like a bad answer to me.
>
> --
> paul moore
> www.paul-moore.com
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [PATCH] Fix cross kernel headers location - rhbz#1642037

[Josh Boyer]

On Thu, Oct 25, 2018 at 7:50 AM Nicolas Chauvet  wrote:
>
> Le mar. 23 oct. 2018 à 17:54, Josh Boyer  a écrit :
> >
> > On Tue, Oct 23, 2018 at 11:12 AM Nicolas Chauvet  wrote:
> > >
> > > Cross compiled kernel headers are installed into /usr/*-linux-gnu/include/
> > > instead of /usr/*-linux-gnu/sys-root/usr/include/ where they can be
> > > found by default by the Fedora cross compiler toolchain.
> >
> > Is that a new change in how the cross compilers work?  The original
> > patch was added a long time ago based on the cross compiler behavior
> > in Fedora at the time.  If that's changed, where can we see that
> > documented?
>
> Hi Josh,
>
> Thx for rising this point.
> I've tried to sum-up my current understanding in rhbz#1642037.
>
> Basically this is the first time I'm using the fedora cross toolchain
> to build userland applications.

The Fedora cross toolchains are only built to cross-compile kernels.
It even says so right in the description:

Description  : Cross-build GNU C compiler.
 :
 : Only building kernels is currently supported.  Support for
 : cross-building user space programs is not currently provided as
 : that would massively multiply the number of packages.

I think you've hit an error in a usecase the toolchains don't even support.

josh

> I've reproduced this error in f28, f29. I haven't tested in in f27 yet.
> I confirm it's possible to build some applications with the
> arm-linux-gnu fedora toolchain once the glibc-arm-linux-gnu is
> installed.
> But as an example, the bug occurs as soon as the  header is
> included from a hello.c.
>
> As a side note I will be AFAIK later today until one week. So unless a
> solution is found I won't be able to work on this issue until back.
>
> Thx
> --
> -
>
> Nicolas (kwizart)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [PATCH] Fix cross kernel headers location - rhbz#1642037

[Josh Boyer]

On Tue, Oct 23, 2018 at 11:12 AM Nicolas Chauvet  wrote:
>
> Cross compiled kernel headers are installed into /usr/*-linux-gnu/include/
> instead of /usr/*-linux-gnu/sys-root/usr/include/ where they can be
> found by default by the Fedora cross compiler toolchain.

Is that a new change in how the cross compilers work?  The original
patch was added a long time ago based on the cross compiler behavior
in Fedora at the time.  If that's changed, where can we see that
documented?

josh

> Because the kernel-cross-headers package can be installed without the
> cross glibc-* binutils-* gcc-* counterparts, it has to own the sysroot
> directory.
>
> Signed-off-by: Nicolas Chauvet 
> ---
>  kernel.spec | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/kernel.spec b/kernel.spec
> index f6d1e2b2a..1ff196b81 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -1681,9 +1681,9 @@ find $RPM_BUILD_ROOT/usr/tmp-headers/include \
>
>  # Copy all the architectures we care about to their respective asm 
> directories
>  for arch in arm arm64 powerpc s390 x86 ; do
> -mkdir -p $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include
> -mv $RPM_BUILD_ROOT/usr/tmp-headers/include/arch-${arch}/asm 
> $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/
> -cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-generic 
> $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/.
> +mkdir -p $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/sys-root%{_includedir}
> +mv $RPM_BUILD_ROOT/usr/tmp-headers/include/arch-${arch}/asm 
> $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/sys-root%{_includedir}
> +cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-generic 
> $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/sys-root%{_includedir}.
>  done
>
>  # Remove the rest of the architectures
> @@ -1692,7 +1692,7 @@ rm -rf $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-*
>
>  # Copy the rest of the headers over
>  for arch in arm arm64 powerpc s390 x86 ; do
> -cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/* 
> $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/.
> +cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/* 
> $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/sys-root%{_includedir}/.
>  done
>
>  rm -rf $RPM_BUILD_ROOT/usr/tmp-headers
> @@ -1817,7 +1817,7 @@ fi
>
>  %if %{with_cross_headers}
>  %files cross-headers
> -/usr/*-linux-gnu/include/*
> +/usr/*-linux-gnu/sysroot
>  %endif
>
>  # empty meta-package
> --
> 2.17.2
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Any way to get the source of old fedora kernels?

[Josh Boyer]

On Sun, Jul 22, 2018 at 10:54 AM stan  wrote:
>
> I've been having an issue with Fedora virtual consoles coming up with
> the wrong color scheme for a while.  Instead of coming up with white on
> black, they come up as grey on white.  When I startx, X resets the
> parameters and they revert to white on black.  The settings programs
> don't work to change this from within the virtual consoles themselves.
>
> I think I've traced this to a problem with radeonfb not initializing
> the virtual console parameters properly, so that when systemd
> instantiates them, they don't get proper settings.  The problem is not
> there on an old 4.13.9 kernel on an old version of Fedora, while it is
> there on that old version with newer kernels. When I went to get the
> source in koji for that kernel, I see that it has been deleted, as have
> all other 4.13 kernels.  Is there a way to get the src.rpm for those
> older kernels, or are they gone to the great bin bucket in the sky?  Is
> there someplace else I could look for the source for an older kernel
> like that?  I just want to compare the radeonfb code to see if it
> changed.  It might be a race condition, since occasionally, the virtual
> consoles come up with the proper coloration. In that case there will be
> no change in radeonfb, and it is something about the boot process
> non-determinism causing the issue.  Is there a way to tell the kernel
> to boot deterministically? Some configuration option that says, don't
> do multithreading during boot?  That would allow radeonfb the time to
> fill the parameter struct before systemd uses it.

Any kernel that was shipped in a release is still in koij.  E.g.
https://koji.fedoraproject.org/koji/buildinfo?buildID=965691

All of the sources are also in Fedora dist-git on the various
branches. 'fedpkg clone kernel' and happy spelunking.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/MGZWD4BGTGDWVPS5YGCTMBOU5LED4GOH/

Re: Can't capture vmcore?

[Josh Boyer]

On Tue, Jan 9, 2018 at 1:51 PM, Maxim Burgerhout  wrote:
> I'm getting kernel panics in a VM that functions as a hypervisor, the moment
> I spin up the nested guest (on AMD ThreadRipper / Fedora 27). That is
> annoying, of course, so I try to be a good citizen and file a bug.
>
> For some reason though, I cannot get the core dumped. I get a core fine with
> sysrq, but not with this actual panic. I've followed [1] to set up kdump and
> crash, but everytime I trigger the crash and see my VM reboot, I see an
> empty /var/crash afterwards.
>
> As was able to get the vmcore written to /var/crash on in a RHEL7 guest, I'm
> starting to suspect a bug, but I'm unsure.
>
> Any pointers on how to debug this?
>
> [1] https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes

Adding the Fedora kernel list.

Kdump isn't automatically tested in Fedora and while it can work, it
can often be broken as well.  There might be someone on the kernel
list that is more familiar with the current state of kdump support in
Fedora, or alternative methods for getting the kernel backtrace.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Current specfile misapplies v4.14.10 stable update for fc26

[Josh Boyer]

On Tue, Jan 2, 2018 at 4:55 PM, Paul Bolle  wrote:
> On Tue, 2018-01-02 at 12:32 -0800, Laura Abbott wrote:
>> On 01/02/2018 08:35 AM, Paul Bolle wrote:
>> > A bit off topic: I suppose at the ultimate goal is to do rpmbuild from 
>> > within
>> > a proper git clone of the kernel repository. Ie, using a branch with 
>> > Fedora's
>> > patches, a specfile, and whatever else we need. Perhaps further gitifying 
>> > the
>> > current specfile helps to reach that goal. Not sure, though.
>>
>> If you're referring to the rpmbuild in the upstream kernel tree, I don't
>> think it's particularly feasible for an official distribution. We end up
>> doing a lot of extra things on top of what's necessary just to package the
>> kernel and modules. I do want to experiment with making the upstream rpmbuild
>> more useful though.
>
> That might be very useful, and probably is a lot of work, but that wasn't what
> I was hinting at. Sorry.
>
> We're juggling tarballs and patches to build Fedora specific kernel rpms while
> all information that we need is already in the kernel git repo clone that's
> already on our machines. So what I was hinting at that I would like to do
> git remote add kernel-pkg fedoraproject.org/whatever
>
> and then (in a kernel-pkg related branch) do
> rpmbuild --i-want-a-pony --foo --bar kernel.spec
>
> and end up with Fedora specific kernel rpms.
>
> Sounds simple, so it must be a tricky problem to solve.

If you're talking about local builds, it isn't tricky at all.  Someone
would just need to adjust the kernel.spec to do it and/or write steps
to have your local git tree in a state that the existing spec could
use.  You could even use the existing exploded tree because the
configs are all there as well.

If you're talking about building Fedora kernels officially from an
exploded tree, there are two tricky issues.

1) You still have to at least create a tarball and upload that because
koji can't build from exploded source.  That means you're uploading a
massive tarball every day and it's terrible.

2) The tracking of patches Fedora carries on top of upstream results
in forced rebases.  You see that with the existing exploded tree we
have on kernel.org, but that literally is just an exploded tree of
builds.  It's not really great for development.  For development
purposes, the forced rebases makes it really crappy to work with.  The
alternative is a ton of merges, which would be possible but alas is
not great either.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Current specfile misapplies v4.14.10 stable update for fc26

[Josh Boyer]

On Tue, Jan 2, 2018 at 4:35 PM, Paul Bolle <pebo...@tiscali.nl> wrote:
> On Tue, 2018-01-02 at 16:28 -0500, Josh Boyer wrote:
>> So if you want to use git apply instead of patch, I have no objections
>> that I can remember.  It'll just require some extra work to make sure
>> the git repo actually exists and that doesn't break other things.
>
> Git apply doesn't need a git repo. It is designed to be a patch replacement.

Interesting.  I wasn't aware of that.  Seems odd?

> (There's probably a lot of legacy stuff patch handles that "git apply"
> doesn't, but no-one cares.)

True, but I guess I wonder why they bothered designing a patch
replacement to begin with.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Current specfile misapplies v4.14.10 stable update for fc26

[Josh Boyer]

On Sun, Dec 31, 2017 at 9:13 PM, Laura Abbott  wrote:
> On 12/30/2017 04:52 AM, Paul Bolle wrote:
>>
>> 0) The v4.14.10 stable updates adds a new executable (tools/objtool/sync-
>> check.sh). Somehow this was added non-executable during my local build of
>> v4.14.10 (on fc26, that is). This made the build fail:
>>
>> [...]
>> + make -s ARCH=x86_64 V=1 -j4 bzImage
>> make[2]: execvp: ./sync-check.sh: Permission denied
>> make[2]: *** [Makefile:49:
>> [...]/BUILD/kernel-4.14.fc26/linux-4.14.10-1.local0.fc26.x86_64/tools/objtool/objtool]
>> Error 127
>> make[1]: *** [Makefile:62: objtool] Error 2
>> make: *** [Makefile:1623: tools/objtool] Error 2
>> make: *** Waiting for unfinished jobs
>> error: Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build)
>>
>>
>> RPM build errors:
>>  Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build)
>>
>> Anybody else seeing this?
>>
>
> Yes, this was something that needed a fixup in rawhide. I added
> the appropriate chmod. 4.14.10 is now building for F27 and F26.
>
>> 1) Switching the specfile from patch to "git apply" seems to do the right
>> thing. This is what I tried:
>>
>> diff --git a/kernel.spec b/kernel.spec
>> index 965345c2a26e..b2a1ffbe843d 100644
>> --- a/kernel.spec
>> +++ b/kernel.spec
>> @@ -1267,8 +1267,9 @@ fi
>>   # released_kernel with possible stable updates
>>   %if 0%{?stable_base}
>>   # This is special because the kernel spec is hell and nothing is
>> consistent
>> -xzcat %{SOURCE5000} | patch -p1 -F1 -s
>> -git commit -a -m "Stable update"
>> +xzcat %{SOURCE5000} | git apply -
>> +git add -A
>> +git commit -m "Stable update"
>>   %endif
>> # Drop some necessary files from the source dir into the buildroot
>>
>> 2) Would it make sense to further gitify the specfile and move from patch
>> to
>> "git apply" here (and a few other places)? Or should we expect patch to do
>> the
>> right thing? (In the latter case I guess I might have to report a bug
>> against
>> patch.)
>>
>
> We've generally been expecting patch to do the right thing and it's
> worked so far. I'm not opposed to gitifying more parts of the spec
> file but do you have a particular reason for doing so? It seemed
> like when Josh made the original change for git he had a few things
> in mind.

I have to put on my time-machine cap to even try and remember.  Here's
the best I can come up with.

If you look at where the cases where patch is being used, you'll
notice that some of them are before 'git init' is even run.  So as it
stands currently, you can't use git apply because the git repo doesn't
actually exist at those points.  Why that is boils down to 2 things:

1) Laziness and/or change minimalization when we introduced this.  You
might be able to move around the git init so you can use git apply,
but I just didn't bother at the time for reasons I don't remember.

2) Upstream sucks at patch generation.  If you look at the stable or
RC patches, they aren't nice mboxes of discreet commits.  They're
giant, code-only diffs that don't preserve individual changes at all.
Looking at that you wind up just applying the changes wholesale and
then doing a commit with "baseline" as the commit message.  Given that
the commit logs of the git tree during the build itself are useless
anyway (because koji doesn't read the commit logs), it doesn't matter
but it's still disappointing.  It means we wind up having to create
the exploded tree with tooling after the fact.  Oh well.

So if you want to use git apply instead of patch, I have no objections
that I can remember.  It'll just require some extra work to make sure
the git repo actually exists and that doesn't break other things.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Adding virtualbox guest driver to Fedora kernels (revisited)

[Josh Boyer]

On Tue, Dec 19, 2017 at 6:03 AM, Hans de Goede  wrote:
> Hi All,
>
> Good news, the vboxguest driver has been queued for
> upstream merging in char-misc-next. This just happened
> so I want to wait for a couple of days to make sure
> they stick and they do not get reverted for some reason.

Nice job!  That's been needed a long time and I'm really happy to see
your success in getting them upstream.

> Then I would like to add them as downstream patches
> to the rawhide kernels for now, they can be dropped
> once we rebase to 4.16.
>
> So as always when making non trivial changes, my
> question to the Fedora kernel team is, is adding
> these as downstream patches ok?

I have no strong opinion, but I'm curious why we wouldn't just wait
for 4.16.  That seems like a natural sync point so that everyone that
provides this driver as a kmod simply stops when the first 4.16 merge
window kernel lands.  Adding them now means more coordination for
users and kmod builders and I wonder if that will cause confusion.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: RFC: Moving kernel-tools out of kernel.spec

[Josh Boyer]

On Wed, Nov 29, 2017 at 10:16 AM, Prarit Bhargava <pra...@redhat.com> wrote:
>
>
> On 11/29/2017 10:07 AM, Josh Boyer wrote:
>> On Wed, Nov 29, 2017 at 9:58 AM, Prarit Bhargava <pra...@redhat.com> wrote:
>>> On 11/28/2017 09:16 PM, Josh Boyer wrote:
>>>> On Tue, Nov 28, 2017 at 5:03 PM, Laura Abbott <labb...@redhat.com> wrote:
>>>>> Like all good bits of software, the kernel.spec has grown over time.
>>>>> Part of this growth has come from building more of the userspace
>>>>> tools that live under the tools directory of the kernel. I've been
>>>>> experimenting with moving these to a separate spec file.
>>>>>
>>>>> Advantages:
>>>>> - Less stuff in the kernel.spec file (~300 line deletion)
>>>>> - Fewer build deps for things like perf
>>>>> - People building the kernel only get the kernel
>>>>> - Issues with userspace tools don't impact the kernel
>>>>> - Can likely drop most of the debuginfo regex nightmare for the userspace
>>>>> packages
>>>>>
>>>>> Disadvantages:
>>>>> - Would need to manually keep in sync on some cadence. This is mostly
>>>>> an issue for rawhide. Could we actually get away with only re-building
>>>>> on each new kernel version or do we need to resync on each -rc?
>>>>> - Would probably need to rework how tools are tied to kernel versions at
>>>>> the package level
>>>>> - Others added here
>>>
>>> IIUC this means if I have a patch that touches tools/power/turbostat and
>>> drivers/idle/intel_idle.c I now have to open up two bugzillas to track 
>>> things so
>>> that the kernel and kernel tools is synchronized?
>>
>> No?  Why would you need two bugs?
>
> For example, the kernel package is built every night.  And the kernel-tools
> package is now built randomly (if it is automatically built when the kernel
> package is built then there's no problem).
>
> I apply a patch that (in my example above) patches both tools/power/turbostat
> and drivers/idle/intel_idle.c I need *both* packages to be built.  If
> kernel-tools and the kernel packages are out-of-sync with one another then
> there's going to be a problem.

What does that have to do with bugs?  Nothing.  This is Fedora.  You
file a single bug, you point out the need to update two SRPMs with it.
And that's IF you file a bug at all :)  Let's not confuse the need to
coordinate with bug reporting.

Also, your example seems somewhat contrived.  If you patch the driver
but don't patch the tool, what happens?  Likely not much, otherwise
people would report broken tools all the time, right?

>>> There are times where tools/power require changes to real kernel code and 
>>> the
>>> userspace tools.  While this is happening less frequently, it has happened 
>>> in
>>> the past and it could happen in the future.  Anyone on the virt side of 
>>> things
>>> want to comment?  ISTR having a conversation with someone about versions of
>>> tools/hv requiring *specific* kernel versions (I'm foggy on the details).
>>
>> None of the existing kernel-tools packages have any sort of Requires
>> on specific kernel versions.  If that is actually a problem, they
>> could be added but it doesn't appear to actually be an issue today...
>>
>
> I've hit this situation a few times with RHEL, where someone updated the 
> kernel
> rpm but not the kernel-tools rpm.  It probably happens more often at the 
> server
> level because of the tools usage.  It has never taken more than a "Please 
> update
> your kernel-tools package" to get the reporter to fix the problem.

OK.  I'm not sure we've seen that in Fedora in... forever.  It would
be interesting to understand why there is the difference.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: RFC: Moving kernel-tools out of kernel.spec

[Josh Boyer]

On Wed, Nov 29, 2017 at 9:58 AM, Prarit Bhargava <pra...@redhat.com> wrote:
> On 11/28/2017 09:16 PM, Josh Boyer wrote:
>> On Tue, Nov 28, 2017 at 5:03 PM, Laura Abbott <labb...@redhat.com> wrote:
>>> Like all good bits of software, the kernel.spec has grown over time.
>>> Part of this growth has come from building more of the userspace
>>> tools that live under the tools directory of the kernel. I've been
>>> experimenting with moving these to a separate spec file.
>>>
>>> Advantages:
>>> - Less stuff in the kernel.spec file (~300 line deletion)
>>> - Fewer build deps for things like perf
>>> - People building the kernel only get the kernel
>>> - Issues with userspace tools don't impact the kernel
>>> - Can likely drop most of the debuginfo regex nightmare for the userspace
>>> packages
>>>
>>> Disadvantages:
>>> - Would need to manually keep in sync on some cadence. This is mostly
>>> an issue for rawhide. Could we actually get away with only re-building
>>> on each new kernel version or do we need to resync on each -rc?
>>> - Would probably need to rework how tools are tied to kernel versions at
>>> the package level
>>> - Others added here
>
> IIUC this means if I have a patch that touches tools/power/turbostat and
> drivers/idle/intel_idle.c I now have to open up two bugzillas to track things 
> so
> that the kernel and kernel tools is synchronized?

No?  Why would you need two bugs?

> There are times where tools/power require changes to real kernel code and the
> userspace tools.  While this is happening less frequently, it has happened in
> the past and it could happen in the future.  Anyone on the virt side of things
> want to comment?  ISTR having a conversation with someone about versions of
> tools/hv requiring *specific* kernel versions (I'm foggy on the details).

None of the existing kernel-tools packages have any sort of Requires
on specific kernel versions.  If that is actually a problem, they
could be added but it doesn't appear to actually be an issue today...

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: RFC: Moving kernel-tools out of kernel.spec

[Josh Boyer]

On Tue, Nov 28, 2017 at 5:03 PM, Laura Abbott  wrote:
> Like all good bits of software, the kernel.spec has grown over time.
> Part of this growth has come from building more of the userspace
> tools that live under the tools directory of the kernel. I've been
> experimenting with moving these to a separate spec file.
>
> Advantages:
> - Less stuff in the kernel.spec file (~300 line deletion)
> - Fewer build deps for things like perf
> - People building the kernel only get the kernel
> - Issues with userspace tools don't impact the kernel
> - Can likely drop most of the debuginfo regex nightmare for the userspace
> packages
>
> Disadvantages:
> - Would need to manually keep in sync on some cadence. This is mostly
> an issue for rawhide. Could we actually get away with only re-building
> on each new kernel version or do we need to resync on each -rc?
> - Would probably need to rework how tools are tied to kernel versions at
> the package level
> - Others added here
>
> I've experimented with something at https://pagure.io/kernel-tools-pkggit
> which is mostly a copy/paste of parts of the kernel.spec file. I'm
> mostly looking for general feedback about if this a good idea but
> I'm also interested in specific feedback if you have it.

If you define a specific cadence for updating, I think you can drop a
LOT of the vanilla dir and pre-release macro junk from the
kernel-tools.spec.  That stuff is optimized for %prep time on a large
tree done multiple times a day, using hardlinks and all kinds of other
stuff to keep from having to expand tarballs a lot.  I don't think it
makes sense to keep that structure in something we'd be looking at
building once a release or even once a week.

I'd suggest once per official RC is enough for rawhide.  You shouldn't
need to deal with git snapshots and building the tools during the
merge window is a wash.  Realistically, after the tools are merged
it's rare they get much in the way of updates between -rc2 and the
final release, but building once per RC would be good to start with.

Are you looking for maintainers of this package?  I know I've
volunteered in the past, and I'm happy to maintain it if nobody else
wants it.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Deprecating old networking protocols

[Josh Boyer]

On Wed, Nov 15, 2017 at 6:09 PM, R P Herrold  wrote:
> On Tue, 14 Nov 2017, Steven Whitehouse wrote:
>
>> I think it is probably overdue in the DECnet case, however I
>> did get a very happy with it for the most part. Anyway it is
>> clear that nobody is maintaining it and it seems sensible
>> that it should get removed unless someone with sufficient
>> time wants to step forward. That has not happened so far,
>
> I still have customers with Decnet in production (certain
> medical lab equipment 'just works' and uses the transport);
> until those units die, there will not be sufficient motivation
> on the customers' parts to spend the money to replace it (and
> at that time, a technology refresh will happen as well
>
> eyeglass labs, and colonoscopy testing, primarily
>
> The 'network' for units are physically isolated, and indeed,
> occasionally accessed only via a graphical terminal emulator
> such as VNC, facing into a TCP/IP network on a second
> interface.  No need for updates here

Are those units or anything that needs to talk to them over DECNet
running Fedora?

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Josh Boyer]

On Wed, Nov 8, 2017 at 2:14 PM, Don Zickus <dzic...@redhat.com> wrote:
> On Wed, Nov 08, 2017 at 01:48:36PM -0500, Josh Boyer wrote:
>> >> [1] https://github.com/npmccallum/census
>> >> [2] https://github.com/npmccallum/census/blob/master/client/plugins/
>> >> [3] https://github.com/npmccallum/census/pull/3
>> >
>> > Internally, we have been focusing on using 'lshw' as the tool that provides
>> > all that info and handles all the arch funkiness (and includes firmware).
>> > If there is anything missing, we have tried to push upstream to that
>> > project.
>> >
>> > Would that cover a lot of the info you are looking for?
>>
>> It sounds like lshw could provide the output for the local system if
>> someone wrote a census plugin for it.  What it doesn't seem to cover
>> at all is the "gather data and send it somewhere" part, right?
>
> I think it covers part of the 'gather data', no? :-)  I had assumed the
> census tool handles the 'send it' somewhere.

Sorry, I phrased that awkwardly.  I meant "gather the data from
multiple computers and send it to a central localtion".  But I think
we're saying the same thing.

> As part of the kernel CI work I am doing internally, we are trying to figure
> out a more universal way of exchange machine info when providing feedback
> that a test or patch broke.  Lots of folks have been using lshw.  This has
> made it easier to write scripts on top of that output compared to various
> custom output.  It isn't perfect, but it seems to do a reasonable job today.

Right.  Adding a census plugin to consume that could build on top of
it even further.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Josh Boyer]

On Wed, Nov 8, 2017 at 12:34 PM, Don Zickus  wrote:
> On Tue, Nov 07, 2017 at 10:49:02PM +, Jeremy Cline wrote:
>> Hey folks,
>>
>> For some time now, Fedora has operated without a database of hardware
>> users have. Smolt, the old hardware database, was retired in 2012[0] and
>> its intended successor[1] was never deployed by Fedora Infrastructure.
>>
>> It would be nice to have a hardware database, so I (and hopefully some
>> others) would like to get Census up and running for Fedora. Before we
>> look at deploying Census, however, it would be good to make sure it has
>> everything we need.
>>
>> Census has client plugins to collect information[2]. At the moment, it
>> has plugins for:
>>
>> * The vendor, device, subsystem_vendor, subsystem_device, and class from
>>   each PCI device
>>
>> * The idVendor, idProduct, bcdDevice, and bDeviceClass for USB devices
>>   as well as the bInterfaceClass, bInterfaceSubClass, and
>>   bInterfaceProtocol for each interface
>>
>> * The contents of /etc/os-release
>>
>> * All the RPMs installed on a system
>>
>> Other than the drivers bound to the PCI and USB devices (which is an
>> open PR[3]), what else would be good to collect?
>>
>> [0] https://fedoraproject.org/wiki/Smolt_retirement
>> [1] https://github.com/npmccallum/census
>> [2] https://github.com/npmccallum/census/blob/master/client/plugins/
>> [3] https://github.com/npmccallum/census/pull/3
>
> Internally, we have been focusing on using 'lshw' as the tool that provides
> all that info and handles all the arch funkiness (and includes firmware).
> If there is anything missing, we have tried to push upstream to that
> project.
>
> Would that cover a lot of the info you are looking for?

It sounds like lshw could provide the output for the local system if
someone wrote a census plugin for it.  What it doesn't seem to cover
at all is the "gather data and send it somewhere" part, right?

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [X86] x86 Architecture SIG

[Josh Boyer]

On Mon, Sep 11, 2017 at 1:22 PM, Justin Forbes  wrote:
> On Fri, Sep 8, 2017 at 9:41 PM, Jeff Backus  wrote:
>
>> (Apologies - resending because I wasn't subscribed earlier)
>>
>> Hi list,
>>
>> I'm contacting you on behalf of the x86 SIG. Today FESCo approved our
>> request to continue to support Fedora on x86 hardware, provided that we do
>> our part to keep things running.
>>
>> I encourage you to reach out to us when things do come up. You can find us
>> at x...@lists.fedoraproject.org or on #fedora-x86. We will likewise try to
>> be proactive in tracking down and triaging x86-related issues as well as
>> helping test and debug things.
>>
>> One caveat that FESCo attached to our request is that if you, the kernel
>> team are cleared to treat i686 as any other secondary arch when you run
>> into build issues. That is, you are allowed to ExcludeArch i686 until these
>> issues are resolved. We ask that you block FE-ExcludeArch-x86 so that we
>> can track these issues.
>>
>> Happy to do so.  There wasn't much need on the current issue because there
> are other problems keeping us from getting a successful build just yet.
> Yay, merge window. I really appreciate the SIG stepping forward and finding
> the solution for i686 though in a timely manner.
>
> Additionally, FESCo would like us to establish a minimum level of hardware
>> supported. We are working on this list and will follow up with you once we
>> have it completed. In the interim, we did want to address a couple of
>> concerns that were passed along by Stephen Smoogen:
>>
>> * We have decided to drop support for PAE, so please feel free to disable
>> it on the next build
>> * We have decided to continue to support pre-SSE2 hardware for the time
>> being
>
>
> Done, rawhide going forward will drop PAE. Current stable Fedora releases
> will continue to build PAE as it wouldn't be wise to drop support on an
> existing release.

This might require changes in Anaconda.  IIRC, it will look at the
cpuflags during install and look to install the PAE kernel if that
flag is present.  Unless the standard i686 kernel does a fake
Provides, it might cause install issues if it's missing.  At least
worth verifying.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Tue, Sep 5, 2017 at 6:25 PM, James Hogarth  wrote:
>
>
> On 5 September 2017 at 22:40, Chris Murphy  wrote:
>>
>> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy 
>> wrote:
>>
>> > FWIW, you can just download the F27 kernel, kernel-core,
>> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
>> > that same download directory and it will install it without complaint.
>> > I routinely run Fedora built n+1 (typically rawhide) kernels on
>> > current release OS.
>>
>> Small gotcha is that you can't upgrade perf, dnf will complain. But
>> usually rudimentary use of current perf will work with a newer kernel.
>>
>>
>>
>
> Right ... with kernel-tools and perf I'd rather have something built against
> the F26 userspace ... but I have run the rawhidenodebug kernels in the past
> for testing ... it's just nicer and more representative for testing what
> will end up in the F26 repos to have the kernel built against F26 in the
> stabilization COPR

I've suggested in the past that we ship the userspace tools in a
completely separate package, leaving ONLY kernel bits in the kernel
SRPM and subpackages.  Partly for this reason, and also because there
is no NEED to build e.g. perf daily.  I'm willing to put my money
where my mouth is and do the maintenance on the userspace side if
people want to pursue this.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] disable SWIOTLB on Power (#1480380)

[Josh Boyer]

On Fri, Aug 11, 2017 at 6:25 AM, Dan Horák  wrote:
> All supported platforms have IOMMU, thus disable.
> ---
>  baseconfig/powerpc/CONFIG_SWIOTLB | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I fixed this up to have a blurb in the kernel.spec changelog and
pushed it to f26 and rawhide.

josh

>
> diff --git a/baseconfig/powerpc/CONFIG_SWIOTLB 
> b/baseconfig/powerpc/CONFIG_SWIOTLB
> index 5405b65..ac62bf3 100644
> --- a/baseconfig/powerpc/CONFIG_SWIOTLB
> +++ b/baseconfig/powerpc/CONFIG_SWIOTLB
> @@ -1 +1 @@
> -CONFIG_SWIOTLB=y
> +# CONFIG_SWIOTLB is not set
> --
> 2.7.5
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] Enforce kernel-devel-uname-r >= uname-r if any kernel-devel-uname-r - rhbz#1450577

[Josh Boyer]

On Mon, Jul 24, 2017 at 9:40 AM, Nicolas Chauvet <kwiz...@gmail.com> wrote:
> 2017-07-24 15:28 GMT+02:00 Josh Boyer <jwbo...@fedoraproject.org>:
>> On Mon, Jul 24, 2017 at 9:20 AM, Nicolas Chauvet <kwiz...@gmail.com> wrote:
>>
>> Please add a descriptive changelog to the patch.  People shouldn't
>> have to go somewhere else to see why a change is being made.  I even
>> read the bug and still don't fully understand what problem you're
>> trying to solve.
>>
>>> ---
>>>  kernel.spec | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/kernel.spec b/kernel.spec
>>> index 6e2df747..377b71a0 100644
>>> --- a/kernel.spec
>>> +++ b/kernel.spec
>>> @@ -382,6 +382,11 @@ ExclusiveOS: Linux
>>>  %ifnarch %{nobuildarches}
>>>  Requires: kernel-core-uname-r = %{KVERREL}%{?variant}
>>>  Requires: kernel-modules-uname-r = %{KVERREL}%{?variant}
>>> +# Enforce kernel-devel varriant >= uname-r,varriant if installed - 
>>> rhbz#1450577
>>> +# Only needed for fedora kernel
>>> +%if 0%{?fedora}
>>
>> Why is a fedora conditional being added here?  This is only built in
>> Fedora already, and the spec file isn't shared with another downstream
>> directly.
> This is true, however I remember centos armhfp altarch often rebase on
> fedora kernel.

I don't think that's a reason to add that.

>>> +Requires: (kernel-devel-uname-r >= %{KVERREL}%{?variant} if 
>>> kernel-devel-uname-r)
>>
>> Adding this seems to now force this installation of a kernel-devel
> Well, this is not the case, as it's a boolean dependency. It will
> enforce the condition only if there is already a kernel-devel-uname
> variant.

From the packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#Rich.2FBoolean_dependencies

"Rich/Boolean dependencies
Packages MAY make limited use of the rich (or Boolean) dependency
feature supported in RPM. They MAY be used in Suggests:, Enhances: and
Supplements: dependencies. However, currently they MUST NOT be used in
Requires: or Recommends: dependencies as this will cause issues with
the package updates process."

So you're adding something that isn't allowed.

And I still don't know what problem you're trying to solve.  Still NAK.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: kernel-4.13-rc0 question

[Josh Boyer]

On Fri, Jul 14, 2017 at 7:46 AM, Sérgio Basto  wrote:
> Hi,
> I have a bug report that can't build virtualbox kmods for kernels on
> rawhide
>
> Larry Finger for opensuse wrote:
>
> Yes, it does not work for kernel 4.11. The "#ifndef" will eventually be
> replaced
> by "#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 13, 0)", but that will
> not work
> until kernel 4.13-rc1 is released. You asked about 4.13-rc0, but that
> entity
> does not exist here.
> If your kernel Makefile does indeed have 4.13, then use the kernel
> version test.
>
> So the main question is kernel Makefile does indeed have 4.13 ?

No, and it won't until upstream releases 4.13-rc1.  Merge window
kernels are called 4.12+ until that point.  The RPM versioning in
Fedora is a construct to reflect that we are working on what will be
the 4.13 code base.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: ppisar pushed to kernel (master). "perl dependency renamed to perl-interpreter "

[Josh Boyer]

On Thu, Jul 13, 2017 at 8:24 AM, Petr Pisar <ppi...@redhat.com> wrote:
> On Thu, Jul 13, 2017 at 08:15:14AM -0400, Josh Boyer wrote:
>> On Thu, Jul 13, 2017 at 3:54 AM,  <notificati...@fedoraproject.org> wrote:
>> > From 575a9e2f6afcad8fa21ca7b0c38278730e2670db Mon Sep 17 00:00:00 2001
>> > From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <ppi...@redhat.com>
>> > Date: Thu, 13 Jul 2017 09:54:13 +0200
>> > Subject: perl dependency renamed to perl-interpreter
>> >  
>> > <https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules>
>> >
>> > ---
>> >  kernel.spec | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/kernel.spec b/kernel.spec
>> > index eb45684..c4e1a37 100644
>> > --- a/kernel.spec
>> > +++ b/kernel.spec
>> > @@ -389,7 +389,7 @@ Requires: kernel-modules-uname-r = 
>> > %{KVERREL}%{?variant}
>> >  # List the packages used during the kernel build
>> >  #
>> >  BuildRequires: kmod, patch, bash, sh-utils, tar, git
>> > -BuildRequires: bzip2, xz, findutils, gzip, m4, perl, perl-Carp, 
>> > perl-devel, perl-generators, make, diffutils, gawk
>> > +BuildRequires: bzip2, xz, findutils, gzip, m4, perl-interpreter, 
>> > perl-Carp, perl-devel, perl-generators, make, diffutils, gawk
>>
>> I'd recommend wrapping the above in some conditional logic sot hat it
>> is perl on f26 and lower, and perl-interpreter otherwise.  People
>> build rawhide kernels on older releases, and this will prevent them
>> from doing so for really no good reason.
>>
> perl-interpreter exists since F24.

Ah!  Then nevermind :)

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: ppisar pushed to kernel (master). "perl dependency renamed to perl-interpreter "

[Josh Boyer]

On Thu, Jul 13, 2017 at 3:54 AM,   wrote:
> From 575a9e2f6afcad8fa21ca7b0c38278730e2670db Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
> Date: Thu, 13 Jul 2017 09:54:13 +0200
> Subject: perl dependency renamed to perl-interpreter
>  
>
> ---
>  kernel.spec | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel.spec b/kernel.spec
> index eb45684..c4e1a37 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -389,7 +389,7 @@ Requires: kernel-modules-uname-r = %{KVERREL}%{?variant}
>  # List the packages used during the kernel build
>  #
>  BuildRequires: kmod, patch, bash, sh-utils, tar, git
> -BuildRequires: bzip2, xz, findutils, gzip, m4, perl, perl-Carp, perl-devel, 
> perl-generators, make, diffutils, gawk
> +BuildRequires: bzip2, xz, findutils, gzip, m4, perl-interpreter, perl-Carp, 
> perl-devel, perl-generators, make, diffutils, gawk

I'd recommend wrapping the above in some conditional logic sot hat it
is perl on f26 and lower, and perl-interpreter otherwise.  People
build rawhide kernels on older releases, and this will prevent them
from doing so for really no good reason.

josh

>  BuildRequires: gcc, binutils, redhat-rpm-config, hmaccalc
>  BuildRequires: net-tools, hostname, bc, elfutils-devel
>  %if %{with_sparse}
> @@ -841,7 +841,7 @@ Provides: installonlypkg(kernel)\
>  AutoReqProv: no\
>  Requires(pre): findutils\
>  Requires: findutils\
> -Requires: perl\
> +Requires: perl-interpreter\
>  %description %{?1:%{1}-}devel\
>  This package provides kernel headers and makefiles sufficient to build 
> modules\
>  against the %{?2:%{2} }kernel package.\
> --
> cgit v1.1
>
>
> 
> https://src.fedoraproject.org/cgit/kernel.git/commit/?h=master=575a9e2f6afcad8fa21ca7b0c38278730e2670db
>
> --
> You received this message due to your preference settings at
> https://apps.fedoraproject.org/notifications/jwboyer.id.fedoraproject.org/email/5133
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Building kernel with fedpkg and custom config

[Josh Boyer]

On Fri, Jun 9, 2017 at 9:02 AM,   wrote:
>
> Hi Laura,
>
> Thanks for the reply, and indeed it works like a charm when I put that 
> #x86_64 header in the config file, likewise the kernel-local file also works 
> perfectly, when I keep the header in the file.
>
> One of the very few things I didn't try...
>
> I would suggest updating the wiki to reflect this. and avoid stupid questions 
> like this again. ;-)

It's a wiki.  If you have a FAS account, you can contribute by
updating it yourself :).

josh

> "If adding configuration options to the kernel-local file remember to keep 
> the original header" or something like that.
>
> However I stumbled upon another issue, when trying a "make localyesconfig" 
> fedpgk fails with the message that "modules.list" is empty, which isn't 
> surprising if it's supposed to be built without modules.
>
> Thanks again.
> regards
>
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] Drop kernel-devel virtual provide rhbz#1420754

[Josh Boyer]

On Tue, Feb 28, 2017 at 4:02 AM, Nicolas Chauvet  wrote:
> 2017-02-16 19:33 GMT+01:00 Nicolas Chauvet :
>> 2017-02-16 19:26 GMT+01:00 Nicolas Chauvet :
>>> ---
>>>  kernel.spec | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/kernel.spec b/kernel.spec
>>> index 4363050..38968ba 100644
>>> --- a/kernel.spec
>>> +++ b/kernel.spec
>>> @@ -815,7 +815,6 @@ Summary: Development package for building kernel 
>>> modules to match the %{?2:%{2}
>>>  Group: System Environment/Kernel\
>>>  Provides: kernel%{?1:-%{1}}-devel-%{_target_cpu} = %{version}-%{release}\
>>>  Provides: kernel-devel-%{_target_cpu} = %{version}-%{release}%{?1:+%{1}}\
>>> -Provides: kernel-devel = %{version}-%{release}%{?1:+%{1}}\
>>>  Provides: kernel-devel-uname-r = %{KVERREL}%{?variant}%{?1:+%{1}}\
>>>  Provides: installonlypkg(kernel)\
>>>  AutoReqProv: no\
>>> --
>>> 2.7.4
>>>
>>
>> So, this was the "light description version" of the patch.
>> please see a full rationale here http://bugzilla.redhat.com/1420754
>> Basically, this patch make the situation in sync with el7 kernel WRT
>> theses provides.
>> There is one virtual provides kernel-devel-uname-r
>> Other are real (packages) provides.
>>
>> That will restore the ability to prefer one kernel-devel varriant over
>> another one as (such as kernel-debug-devel).
>> In the current situation every kernel-devel varriant have this
>> kernel-devel (virtual) provide.
>
> Any answer from the kernel team about this ?

I'm not on the kernel team any longer.  However, I went digging and
this was fixed 2 years ago in RHEL for the exact same reasons with the
exact same fix.  So I guess ACK from me.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] set zEC12 as minimum hw level for s390x

[Josh Boyer]

On Fri, Feb 3, 2017 at 2:13 PM, Justin Forbes <jfor...@redhat.com> wrote:
> On Fri, Feb 3, 2017 at 11:08 AM, Josh Boyer <jwbo...@fedoraproject.org>
> wrote:
>>
>> On Thu, Feb 2, 2017 at 11:53 AM, Dan Horák <d...@danny.cz> wrote:
>>
>> Ack.  We did similar changes in rpm macros already so that gcc builds
>> for this platform by default.  Glibc will be making equivalent changes
>> as well.
>>
> So I have applied this for F26 in today's rawhide. I am assuming we want to
> limit this to F26 and newer?

Ah, great question.  Yes.  Dan will yell at me if I'm wrong.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] set zEC12 as minimum hw level for s390x

[Josh Boyer]

On Thu, Feb 2, 2017 at 11:53 AM, Dan Horák  wrote:

Ack.  We did similar changes in rpm macros already so that gcc builds
for this platform by default.  Glibc will be making equivalent changes
as well.

josh

> ---
>  baseconfig/s390x/CONFIG_MARCH_Z900   | 1 -
>  baseconfig/s390x/CONFIG_MARCH_Z990   | 1 -
>  baseconfig/s390x/CONFIG_MARCH_Z9_109 | 1 -
>  baseconfig/s390x/CONFIG_MARCH_ZEC12  | 1 +
>  4 files changed, 1 insertion(+), 3 deletions(-)
>  delete mode 100644 baseconfig/s390x/CONFIG_MARCH_Z900
>  delete mode 100644 baseconfig/s390x/CONFIG_MARCH_Z990
>  delete mode 100644 baseconfig/s390x/CONFIG_MARCH_Z9_109
>  create mode 100644 baseconfig/s390x/CONFIG_MARCH_ZEC12
>
> diff --git a/baseconfig/s390x/CONFIG_MARCH_Z900 
> b/baseconfig/s390x/CONFIG_MARCH_Z900
> deleted file mode 100644
> index 6fa9110..000
> --- a/baseconfig/s390x/CONFIG_MARCH_Z900
> +++ /dev/null
> @@ -1 +0,0 @@
> -# CONFIG_MARCH_Z900 is not set
> diff --git a/baseconfig/s390x/CONFIG_MARCH_Z990 
> b/baseconfig/s390x/CONFIG_MARCH_Z990
> deleted file mode 100644
> index b0c3638..000
> --- a/baseconfig/s390x/CONFIG_MARCH_Z990
> +++ /dev/null
> @@ -1 +0,0 @@
> -# CONFIG_MARCH_Z990 is not set
> diff --git a/baseconfig/s390x/CONFIG_MARCH_Z9_109 
> b/baseconfig/s390x/CONFIG_MARCH_Z9_109
> deleted file mode 100644
> index e19e966..000
> --- a/baseconfig/s390x/CONFIG_MARCH_Z9_109
> +++ /dev/null
> @@ -1 +0,0 @@
> -CONFIG_MARCH_Z9_109=y
> diff --git a/baseconfig/s390x/CONFIG_MARCH_ZEC12 
> b/baseconfig/s390x/CONFIG_MARCH_ZEC12
> new file mode 100644
> index 000..7dbcbb3
> --- /dev/null
> +++ b/baseconfig/s390x/CONFIG_MARCH_ZEC12
> @@ -0,0 +1 @@
> +CONFIG_MARCH_ZEC12=y
> --
> 2.7.4
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Adding out-of-tree wifi drivers to the Fedora kernel pkg

[Josh Boyer]

On Wed, Jan 18, 2017 at 9:28 AM, Hans de Goede <hdego...@redhat.com> wrote:
> Hi,
>
>
> On 18-01-17 13:10, Josh Boyer wrote:
>>
>> On Wed, Jan 18, 2017 at 5:18 AM, Hans de Goede <hdego...@redhat.com>
>>> And I still end up at my original unanswered question:
>>>
>>> "All I'm asking from the fedora kernel team is permission
>>> to add the driver."
>>
>>
>> I believe you also offered to maintain it, yes?
>
>
> Yes, if I get to go ahead to add these I will take care of them
> 100%, which is also why I want to start with just rtl8723bs and
> see how that goes.
>
> As said the Fedora kernel team can just comment out the patches
> when things break when rebasing to a new rc1, and I will take
> care of getting things fixed. Note if things break in a minor
> release e.g. going from 4.8.15 to 4.8.16 a heads-up of course
> would be appreciated, but I assume that is common sense.

We did this with another out-of-tree patchset a while ago to support
ACPI and UEFI on Aarch64 before that was upstream.  The maintainer of
that patchset did a great job and I think it worked well enough.  As I
said earlier, I don't have a say in the decision but if similar
efforts are in place for these drivers then it could be successful.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Adding out-of-tree wifi drivers to the Fedora kernel pkg

[Josh Boyer]

On Wed, Jan 18, 2017 at 5:18 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 17-01-17 21:59, Laura Abbott wrote:
>>
>> On 01/17/2017 05:19 AM, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 17-01-17 14:12, Thorsten Leemhuis wrote:

 Lo! Three quick question from someone who for some strange reason is
 interested in this topic:

 Hans de Goede wrote on 17.01.2017 13:11:
>
>
> As such I would like to (for starters) add this driver:
> https://github.com/hadess/rtl8723bs
>
> Which is fully open source and although not ready for
> upstream, actively maintained by the community, to the
> driver/staging directory of the Fedora kernel pkg.


 * wouldn't it make more sense to simply add the driver to the staging
 directory upstream?
>>>
>>>
>>> See my answer to Bastien's mail.
>>>
 * will users somehow made aware they are using drivers of lower quality
 which are maintained differently (they for example might vanish suddenly
 if maintainers lose interest, which normally doesn't happen with proper
 kernel drivers)
>>>
>>>
>>> Other then the standard tainting caused by this being in staging, no.
>>>
 * while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy
 still considered policy or is it a page everyone forgot about?
>>>
>>>
>>> I for one had never heard about that page.
>>>
>>> Regards,
>>>
>>> Hans
>>
>>
>>
>> Yes, that page should still be accurate wrt to staging policy although
>> I think the list of drivers might need to be updated.
>>
>> In general, I think upstreaming is the right approach to take and
>> if you are willing to go through staging, I think that could be
>> a good path to work to get the driver out of staging.
>
>
> I've the feeling this whole discussion has been derailed a bit
> by focusing too much on the rtl8723bs example.
>
> Quoting from my original mail, upstreaming was given as
> one possible solution:
>
> "d) Get the driver upstreamed. Unfortunately many of
>these drivers are vendor code, which often is ported
>windows code with lots of ugly glue; and the effort to
>get this upstream will take more time then I have
>to invest into this. Also if this were easy it would
>have been done by now, there are quite a few people
>interested in this."
>
> Nothing has changed wrt this, to be specific I would like
> to see the following wifi drivers be available in Fedora
> kernels:
>
> rtl8723bs
> rtl8189es
> rtl8189fs
> esp8089
> xradio
>
> And in the future possible others (rda599x comes to mind)
> and I simply do not have the bandwidth to get 1 one of
> these let alone all of these into staging, let alone
> fully mainlined.
>
> Currently we're crippling our user experience by refusing
> to ship drivers support this hardware even though there are
> fully open drivers to support these.

Hans, I think you need to take a deep breath.  You seem to have come
to this discussion with fully loaded guns blazing.

Nobody has refused your request.  There's been a discussion about the
best way to get it upstream.  Nobody has said no.

Also, I understand your argumentation about user experience but this
is the first I've heard of this issue and I couldn't find any reports
of this in bugzilla.  While it isn't relevant to the decision to add
the drivers, I do wonder how many users we have of such hardware.  It
seems we aren't crippling user experience as much as we would be
making it possible to use the hardware in the first place.  That could
certainly be a good thing.

> Again quoting from my original email:
>
> "I also believe that this rule goes against Fedora's
> basic principles:
>
> -It goes against the First principle, many other distros
>  are shipping with this driver
> -It goes against the Features principle, disallowing
>  people to have working wifi is a mis-Feature
> -It goes against the Freedom principle, if a contributor
>  is willing to spend time to maintain such a driver
>  he/she should have the freedom to do so"

Principles are good to have and provide guidance on how one should act
when possible.  Sometimes they're out-weighed by reality though.  I
mean, if we were to take them literally for every single issue, we'd
be supporting armv5, armv6, sparc, mips, mips64, etc etc.  That's not
hyperbole either.  Users have requested all of those.  The team simply
doesn't have the resources to do them all.  I know you know this, so
throwing principles in the Fedora kernel team's face seems a little
preachy just for the sake of getting what you want.

> And I still end up at my original unanswered question:
>
> "All I'm asking from the fedora kernel team is permission
> to add the driver."

I believe you also offered to maintain it, yes?  I have no say in this
decision, but that's going to be a key detail.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Repository of Kernels for Fedora

[Josh Boyer]

On Thu, Jan 12, 2017 at 8:47 AM, Benson Muite
<benson_mu...@emailplus.org> wrote:
>
>
> On 01/12/2017 03:32 PM, Josh Boyer wrote:
>>
>> On Thu, Jan 12, 2017 at 8:22 AM, Benson Muite
>> <benson_mu...@emailplus.org> wrote:
>>>
>>> Hi,
>>>
>>> Is there a repository of compiled linux kernels for Fedora similar to
>>> that
>>> for Ubunutu at:
>>> http://kernel.ubuntu.com/~kernel-ppa/mainline/
>>
>> Nothing quite like that, no.  All the kernels built and shipped for a
>> Fedora release are in koji though:
>>
>> https://koji.fedoraproject.org/koji/packageinfo?packageID=8
>
> Thanks.
>>
>>
>>> There are a few unofficial builds in copr, but would be helpful to know
>>> if
>>> one could change to different pre-built kernels rather than compiling for
>>> oneself.
>>
>> Different for what purpose?
>
> Some of the ones in Copr seem to offer better tuning, but information in
> koji is sufficient to try out older versions and slight modifications.

Better tuning for what?  If you could be more verbose in what you're
looking for, you might get better information on what is available.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Repository of Kernels for Fedora

[Josh Boyer]

On Thu, Jan 12, 2017 at 8:22 AM, Benson Muite
 wrote:
> Hi,
>
> Is there a repository of compiled linux kernels for Fedora similar to that
> for Ubunutu at:
> http://kernel.ubuntu.com/~kernel-ppa/mainline/

Nothing quite like that, no.  All the kernels built and shipped for a
Fedora release are in koji though:

https://koji.fedoraproject.org/koji/packageinfo?packageID=8

> There are a few unofficial builds in copr, but would be helpful to know if
> one could change to different pre-built kernels rather than compiling for
> oneself.

Different for what purpose?

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Fedora kernels should disable CONFIG_IWLWIFI_PCIE_RTPM

[Josh Boyer]

On Tue, Dec 20, 2016 at 1:18 PM, Jóhann B. Guðmundsson
<johan...@gmail.com> wrote:
> On 12/15/2016 12:01 PM, Josh Boyer wrote:
>
>> On Thu, Dec 15, 2016 at 5:37 AM, Hans de Goede <hdego...@redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I stumbled over this while looking into something completely different,
>>> according to:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=172411
>>>
>>> As this point in time it is better to not enable
>>> CONFIG_IWLWIFI_PCIE_RTPM, as it cause wifi disconnects
>>> on some platforms.
>>
>> There's no indication in the code that it's broken or unsafe to
>> enable.  Seems like a patch making it depend on config BROKEN or
>> config EXPERT or at least some kind of warning in the help text is
>> warranted.
>
>
> It's pretty clear from comment 7 in that upstream report that upstream does
> not deem it safe to have this option enabled at this point...

Yes, in the bug report.  My reply you quoted said "... in the
code...".  My point was, if upstream considered this unsafe they
should have indicated it in the code to begin with.  That way people
don't turn it on before they consider it ready.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Fedora kernels should disable CONFIG_IWLWIFI_PCIE_RTPM

[Josh Boyer]

On Thu, Dec 15, 2016 at 5:37 AM, Hans de Goede  wrote:
> Hi,
>
> I stumbled over this while looking into something completely different,
> according to:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=172411
>
> As this point in time it is better to not enable
> CONFIG_IWLWIFI_PCIE_RTPM, as it cause wifi disconnects
> on some platforms.

There's no indication in the code that it's broken or unsafe to
enable.  Seems like a patch making it depend on config BROKEN or
config EXPERT or at least some kind of warning in the help text is
warranted.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] config: Enable CONFIG_MODVERSIONS

[Josh Boyer]

On Thu, Dec 1, 2016 at 9:58 AM, Don Zickus  wrote:
> On Thu, Dec 01, 2016 at 07:53:06AM -0600, Justin Forbes wrote:
>> On Wed, Nov 30, 2016 at 8:03 PM, Don Zickus  wrote:
>>
>> > On Wed, Nov 30, 2016 at 04:25:30PM -0800, Laura Abbott wrote:
>> > > >  I don't think it would be a bad idea to enable in rawhide and see how
>> > it works out, from there it will trickle down as the stable releases get
>> > rebased.  While turning it on in theory shouldn't create a problem. I
>> > honestly don't get warm fuzzies making such a change without at least some
>> > time testing in rawhide. We are just a week or two away from 4.9 final now,
>> > so it isn't a huge delay.  The changes being proposed upstream are not even
>> > in next yet, so it has some time to be shaken out before it would ever see
>> > a stable release, though the feature would need to be enabled in rawhide
>> > for testing as that happens.
>> > > >
>> > > > Justin
>> > > >
>> > > >
>> > >
>> > > I'm not opposed to turning it on but I'm a little bit wary
>> > > of this causing unexpected problems for users. From
>> > > experience, how likely is it that a module passes the version
>> > > checks but something else has changed such that it no longer
>> > > works? Even if we can't officially support 3rd party modules,
>> > > I'd like to not make it too much worse within reason.
>> >
>> > Hi Laura,
>> >
>> > Thanks for the feedback!
>> >
>> > That can always be the case, static inlines for example.  But RHEL has been
>> > relying on this since RHEL-5 with many 3rd party drivers.  Various fixes
>> > have gone in to the genksyms tool to make this interface fairly reliable.
>> >
>>
>> RHEL relying on this without major issues is very different than Fedora
>> relying on it.  Fedora 23 which will EOL this month released with a 4.2
>> kernel and is currently using 4.8.10.
>
> Hi Justin,
>
> In that scenario, I would fully expect lots of symbols to break after each
> major kernel version release.  As a result a driver would fail to load and
> would need to be rebuilt.  No different than today.
>
> I don't expect Fedora to change any process or policy here.  I was just
> trying to point out that the MODVERSIONS technology works well (despite the
> upstream thread which broke things when enabling EXPORT_SYMBOL in asm
> files due to a bad binutil version).  :-)
>
> Based on the upstream thread, it seems there is widespread frustration with
> guaranteeing correct module load with different kernel versions.
> MODVERSIONS is pretty good today, but folks want better.  Red Hat would like
> to help promote better technology here as kabi is something of a value add
> on RHEL.
>
> It is easier to do that if we can sync up some of RHEL's process with Fedora
> to aid in flushing out issues.  That is really my main motivation here.
>
> We can then use RH's internal testing and tooling to help verify things.
>
> I believe it should have zero impact on Fedora.  The upstream discussion is
> now resolved for 4.9 if I understand things correctly.  But feel free to
> wait until 4.9 is actually released to make sure MODVERSIONS is no longer
> depending on BROKEN.

I think Linus removed the dependency on BROKEN, but there are still
some unresolved issues that make MODVERSIONS not functional.  Until
those get cleared up, I'm not sure it's safe to enable in 4.9.
Definitely something to keep an eye on as the release gets closer.

> In case you want to understand the technology a little bit better.  Today in
> Fedora, module loading is based on a version string check.  If the module's
> version string matches the kernel's string, it will load.  No other sanity
> check. So if a kernel is modified but the version string isn't updated, bad
> things may happen.
>
> MODVERSIONS takes a checksum of the _whole_ path of an EXPORT_SYMBOL and its
> parameters, recursively diving through structs until it gets to the very
> basic types of int, char, void, etc..  Sometimes 100 levels deep.  This is
> done by preprocessing the .c file into a .i fisrt. Once that extremely long
> string is created, it is checksummed and stored in the .ko as the CRC.
>
> Any out-of-tree module compiled has to go through the same steps and uses
> the crc symbols from Modules.symvers as its dependency.
>
> Upon module loading, if the CRCs don't match the module is blocked.  If they
> do match, it implies the structs, the offsets, the variable names,
> everything has not changed for that EXPORT_SYMBOL (ignoring code use of
> those struct elements).  That is a pretty decent sanity check that the
> driver should work on that kernel version.  Nothing is 100%, I get that, but
> with our experience on RHEL (and all the hairy rebased subsystems we do), it
> has worked pretty well.
>
> If Fedora continues to promote DKMS and akmod, then no one has to worry
> about this issue as those drivers will get stuck in extras/ and only be
> available to that kernel.  :-)

Just to clarify something, 

Re: [PATCH] config: Enable CONFIG_MODVERSIONS

[Josh Boyer]

On Wed, Nov 30, 2016 at 6:19 PM, Justin Forbes <jfor...@redhat.com> wrote:
> On Wed, Nov 30, 2016 at 4:33 PM, Josh Boyer <jwbo...@fedoraproject.org>
> wrote:
>>
>> On Wed, Nov 30, 2016 at 5:29 PM, Paul Bolle <pebo...@tiscali.nl> wrote:
>> > On Wed, 2016-11-30 at 17:15 -0500, Don Zickus wrote:
>> >> I noticed that CONFIG_MODVERSIONS was not enabled in Fedora.  I do not
>> >> know
>> >> the history and would be curious to know if someone knew.
>
>
> As for reasoning that it is turned off, I expect that is because it
> originally came into the kernel (2.6 days I think) as EXPERIMENTAL. By
> policy, we don't enable anything requiring CONFIG_EXPERIMENTAL without
> justification.  Though since EXPERIMENTAL is turned on for the occasional
> thing that is justified, it means we have to turn off those things manually
> in the config.  Rarely are those options revisited unless someone asks.
> That said, it is no longer EXPERIMENTAL.
>
>
>>
>> >> Otherwise, I would like to propose enabling it.
>
>
> While I don't think it really does much to help with the 3rd party driver
> situation in Fedora, I am all for helping RHEL.  In the Fedora case we are
> rebasing pretty frequently. and following the stable branch in between. As a
> result, most people are using either dkms or akmod to manage their 3rd party
> drivers.  Most of the bugs we do get are 3rd party drivers which just don't
> work with the latest kernel due to actual code changes or conflicts (such as
> upstream adding a new function that just happens to share a name with an
> nvidia function).
>
>>
>> > Shouldn't Fedora at least wait until the dust settles in
>> >
>> > https://lkml.kernel.org/r/<20161123210256.31501-1-kilob...@angband.pl>
>> >
>> > and related, and equally lively, threads?
>>
>> For Rawhide, yes.  But given the config option is most relevant for
>> stable Fedora releases, it's worth enabling there separately if that
>> is the decision that is come to.
>
>
>  I don't think it would be a bad idea to enable in rawhide and see how it
> works out, from there it will trickle down as the stable releases get
> rebased.  While turning it on in theory shouldn't create a problem. I
> honestly don't get warm fuzzies making such a change without at least some
> time testing in rawhide. We are just a week or two away from 4.9 final now,
> so it isn't a huge delay.  The changes being proposed upstream are not even
> in next yet, so it has some time to be shaken out before it would ever see a
> stable release, though the feature would need to be enabled in rawhide for
> testing as that happens.

Yeah, normally I'd advocate for the flow-down method too.  But at the
moment, it's just flat out broken for 4.9.  Jarod found a different
issue with similar symbol commits causing parallel builds to fail in
4.9 as well.  Which leads me to believe we should probably skip 4.9
unless this is a big enough issue to cause the final release to be
held up.

Given that, maybe it's best to wait for 4.10?

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] config: Enable CONFIG_MODVERSIONS

[Josh Boyer]

On Wed, Nov 30, 2016 at 5:29 PM, Paul Bolle  wrote:
> On Wed, 2016-11-30 at 17:15 -0500, Don Zickus wrote:
>> I noticed that CONFIG_MODVERSIONS was not enabled in Fedora.  I do not know
>> the history and would be curious to know if someone knew.
>>
>> Otherwise, I would like to propose enabling it.
>
> Shouldn't Fedora at least wait until the dust settles in
> https://lkml.kernel.org/r/<20161123210256.31501-1-kilob...@angband.pl>
>
> and related, and equally lively, threads?

For Rawhide, yes.  But given the config option is most relevant for
stable Fedora releases, it's worth enabling there separately if that
is the decision that is come to.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: arm64: F26 vs F25 kernel config for 4.9 (48-bit VA)

[Josh Boyer]

On Tue, Nov 22, 2016 at 2:14 PM, Jon Masters  wrote:
> Hi Folks,
>
> A quick reminder that, while 48-bit VA is enabled in rawhide/26:
>
> commit c0f22caded1d549e532d2ab3ce767f8f3d2206f8
> Author: Peter Robinson 
> Date:   Mon Oct 31 15:45:58 2016 +
>
> arm64: Enable 48bit VA
>
> Care should be taken to ensure this doesn't get accidentally pulled in
> when F25 rebases later on. Userspace isn't ready for it there. Folks
> know this, but we're on an internal RH call and someone asked that we
> specifically call this out to make sure everyone knows.

That was me.  Thanks for the reminder Jon.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] set z10 as minimum architecture level for s390x

[Josh Boyer]

On Tue, Nov 15, 2016 at 6:11 AM, Dan Horák  wrote:
> This is intended for f26/rawhide only.
>
>
> Dan
>
> On Tue, 15 Nov 2016 11:38:25 +0100
> Dan Horák  wrote:
>
>> ---
>>  config-s390x | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/config-s390x b/config-s390x
>> index 5368c01..8923379 100644
>> --- a/config-s390x
>> +++ b/config-s390x
>> @@ -1,7 +1,5 @@
>>  CONFIG_64BIT=y
>> -# CONFIG_MARCH_Z900 is not set
>> -CONFIG_MARCH_Z9_109=y
>> -# CONFIG_MARCH_Z990 is not set
>> +CONFIG_MARCH_Z10=y
>>
>>  CONFIG_NR_CPUS=64
>>  CONFIG_COMPAT=y

Applied and pushed out.  Thanks.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH 1/5] Run oldnoconfig make targets silently

[Josh Boyer]

On Mon, Nov 14, 2016 at 2:08 PM, Paul Bolle <pebo...@tiscali.nl> wrote:
> On Thu, 2016-11-10 at 19:38 -0500, Josh Boyer wrote:
>> [...] but it can't be at the expense of people that have
>> to do things with this package multiple times a day.
>
> Sure.
>
> But - to keep my reply at a reasonable length - setting defaults to values
> that casual builders, probably, expect shouldn't be seen as doing something at
> the expense of the people working with the package on a day to day basis.

You keep saying things like that, but I honestly have lost all context
of what you are actually wanting to change here and why.

Could you start with a summary email of the workflow you are desiring,
with some examples perhaps?  That would be helpful.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH 1/5] Run oldnoconfig make targets silently

[Josh Boyer]

On Thu, Nov 10, 2016 at 4:03 PM, Peter Robinson  wrote:
> On Thu, Nov 10, 2016 at 8:59 PM, Paul Bolle  wrote:
>> On Thu, 2016-11-10 at 20:28 +, Peter Robinson wrote:
>>> I agree with Josh, what is it that you're actually trying to achieve here?
>>
>> What I want to achieve is to make the build a bit more quiet. And I prefer it
>> to not do things for no good reason.
>>
>> But it turns out I can get what I want if we remove the call of "make
>> oldnoconfig" during %prep. There really is no need to do that for all config
>> files in configs/, as only one of those files will be used for the build. And
>> the file that actually will be used during %build will go through "make
>> oldnoconfig". So why bother doing that earlier during %prep?
>
> The reason it's done during prep for all config files is so that
> maintainers can do a basic "fedpkg prep" to make sure they haven't
> broken anything before pushing it. I do this numerous times a day when
> working on kernel stuff.

Right.

Paul, your changes make some logical sense but they break the workflow
of the people that have to maintain the package.  That's where most of
the pushback is going to come from.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH 3/5] Only run listnewconfig and oldnoconfig for one arch

[Josh Boyer]

On Thu, Nov 10, 2016 at 11:08 AM, Paul Bolle  wrote:
> During the %prep phase we run "make listnewconfig" and "make oldnoconfig" for
> all six supported architectures (arm64, arm, i386, powerpc, s390, and x86_64).
> We only care about the set of .configs that is relevant for the current build
> architecture. So skip these two make targets for the other architectures.
>
> Signed-off-by: Paul Bolle 

NAK on this one.

We used to only run it for the current build architecture.  However,
when we did that what wound up happening is that we'd have the new
options configured for that specific architecture (which is always
x86_64 because that is what people use), and it would then fail in
koji on the other architectures because of unset new configs.

So we run it for all arches to make sure we catch all new config
options as they come in.

josh

> ---
>  kernel.spec | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kernel.spec b/kernel.spec
> index f0fe21fef94b..e791d2565efc 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -1250,6 +1250,9 @@ for i in *.config
>  do
>mv $i .config
>Arch=`head -1 .config | cut -b 3-`
> +  if [ $Arch != %{hdrarch} ]; then
> +continue
> +  fi
>  %if %{listnewconfig_fail}
>make ARCH=$Arch listnewconfig | grep -E '^CONFIG_' >.newoptions || true
>if [ -s .newoptions ]; then
> --
> 2.7.4
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH 5/5] Remove references to (31 bits) s390

[Josh Boyer]

On Thu, Nov 10, 2016 at 11:08 AM, Paul Bolle  wrote:
> We don't build for (31 bits) s390 but only for (64 bits) s390x. So remove a 
> few
> irrelevant references to s390.
>
> Signed-off-by: Paul Bolle 

Seems fine.

josh

> ---
>  kernel.spec | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel.spec b/kernel.spec
> index 05e0190eea19..434059e759b3 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -216,7 +216,7 @@ Summary: The Linux kernel
>
>  %if %{with_vdso_install}
>  # These arches install vdso/ directories.
> -%define vdso_arches %{x86_32} x86_64 %{power64} s390 s390x aarch64
> +%define vdso_arches %{x86_32} x86_64 %{power64} s390x aarch64
>  %endif
>
>  # Overrides for generic default options
> @@ -324,7 +324,7 @@ Summary: The Linux kernel
>  # Which is a BadThing(tm).
>
>  # We only build kernel-headers on the following...
> -%define nobuildarches i386 s390
> +%define nobuildarches i386
>
>  %ifarch %nobuildarches
>  %define with_up 0
> @@ -359,7 +359,7 @@ Version: %{rpmversion}
>  Release: %{pkg_release}
>  # DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN 
> ARCHITECTURE BUILD.
>  # SET %%nobuildarches (ABOVE) INSTEAD
> -ExclusiveArch: %{x86_32} x86_64 ppc64 ppc64p7 s390 s390x %{arm} aarch64 
> ppc64le
> +ExclusiveArch: %{x86_32} x86_64 ppc64 ppc64p7 s390x %{arm} aarch64 ppc64le
>  ExclusiveOS: Linux
>  %ifnarch %{nobuildarches}
>  Requires: kernel-core-uname-r = %{KVERREL}%{?variant}
> @@ -380,7 +380,7 @@ BuildRequires: sparse
>  %if %{with_perf}
>  BuildRequires: zlib-devel binutils-devel newt-devel python-devel 
> perl(ExtUtils::Embed) bison flex xz-devel
>  BuildRequires: audit-libs-devel
> -%ifnarch s390 s390x %{arm}
> +%ifnarch s390x %{arm}
>  BuildRequires: numactl-devel
>  %endif
>  %endif
> --
> 2.7.4
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 19/20] MODSIGN: Support not importing certs from db

[Josh Boyer]

If a user tells shim to not use the certs/hashes in the UEFI db variable
for verification purposes, shim will set a UEFI variable called MokIgnoreDB.
Have the uefi import code look for this and not import things from the db
variable.

Signed-off-by: Josh Boyer <jwbo...@fedoraproject.org>
---
 kernel/modsign_uefi.c | 40 +++-
 1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/kernel/modsign_uefi.c b/kernel/modsign_uefi.c
index fe4a6f2bf10a..a41da14b1ffd 100644
--- a/kernel/modsign_uefi.c
+++ b/kernel/modsign_uefi.c
@@ -8,6 +8,23 @@
 #include 
 #include "module-internal.h"
 
+static __init int check_ignore_db(void)
+{
+   efi_status_t status;
+   unsigned int db = 0;
+   unsigned long size = sizeof(db);
+   efi_guid_t guid = EFI_SHIM_LOCK_GUID;
+
+   /* Check and see if the MokIgnoreDB variable exists.  If that fails
+* then we don't ignore DB.  If it succeeds, we do.
+*/
+   status = efi.get_variable(L"MokIgnoreDB", , NULL, , );
+   if (status != EFI_SUCCESS)
+   return 0;
+
+   return 1;
+}
+
 static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid, 
unsigned long *size)
 {
efi_status_t status;
@@ -47,7 +64,7 @@ static int __init load_uefi_certs(void)
efi_guid_t mok_var = EFI_SHIM_LOCK_GUID;
void *db = NULL, *dbx = NULL, *mok = NULL;
unsigned long dbsize = 0, dbxsize = 0, moksize = 0;
-   int rc = 0;
+   int ignore_db, rc = 0;
struct key *keyring = NULL;
 
/* Check if SB is enabled and just return if not */
@@ -60,17 +77,22 @@ static int __init load_uefi_certs(void)
return -EINVAL;
}
 
+   /* See if the user has setup Ignore DB mode */
+   ignore_db = check_ignore_db();
+
/* Get db, MokListRT, and dbx.  They might not exist, so it isn't
 * an error if we can't get them.
 */
-   db = get_cert_list(L"db", _var, );
-   if (!db) {
-   pr_err("MODSIGN: Couldn't get UEFI db list\n");
-   } else {
-   rc = parse_efi_signature_list(db, dbsize, keyring);
-   if (rc)
-   pr_err("Couldn't parse db signatures: %d\n", rc);
-   kfree(db);
+   if (!ignore_db) {
+   db = get_cert_list(L"db", _var, );
+   if (!db) {
+   pr_err("MODSIGN: Couldn't get UEFI db list\n");
+   } else {
+   rc = parse_efi_signature_list(db, dbsize, keyring);
+   if (rc)
+   pr_err("Couldn't parse db signatures: %d\n", 
rc);
+   kfree(db);
+   }
}
 
mok = get_cert_list(L"MokListRT", _var, );
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 18/20] MODSIGN: Import certificates from UEFI Secure Boot

[Josh Boyer]

Secure Boot stores a list of allowed certificates in the 'db' variable.
This imports those certificates into the system trusted keyring.  This
allows for a third party signing certificate to be used in conjunction
with signed modules.  By importing the public certificate into the 'db'
variable, a user can allow a module signed with that certificate to
load.  The shim UEFI bootloader has a similar certificate list stored
in the 'MokListRT' variable.  We import those as well.

In the opposite case, Secure Boot maintains a list of disallowed
certificates in the 'dbx' variable.  We load those certificates into
the newly introduced system blacklist keyring and forbid any module
signed with those from loading.

Signed-off-by: Josh Boyer <jwbo...@fedoraproject.org>
---
 certs/system_keyring.c| 13 ++
 include/keys/system_keyring.h |  1 +
 init/Kconfig  |  9 
 kernel/Makefile   |  3 ++
 kernel/modsign_uefi.c | 99 +++
 5 files changed, 125 insertions(+)
 create mode 100644 kernel/modsign_uefi.c

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 787eeead2f57..4d9123ed5c07 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -30,6 +30,19 @@ extern __initconst const u8 system_certificate_list[];
 extern __initconst const unsigned long system_certificate_list_size;
 
 /**
+ * get_system_keyring - Return a pointer to the system keyring
+ *
+ */
+struct key *get_system_keyring(void)
+{
+   struct key *system_keyring = NULL;
+
+   system_keyring = builtin_trusted_keys;
+   return system_keyring;
+}
+EXPORT_SYMBOL_GPL(get_system_keyring);
+
+/**
  * restrict_link_to_builtin_trusted - Restrict keyring addition by built in CA
  *
  * Restrict the addition of keys into a keyring based on the key-to-be-added
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 5bc291a3d261..56ff5715ab67 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -36,6 +36,7 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
 #ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
 extern struct key *system_blacklist_keyring;
 #endif
+extern struct key *get_system_keyring(void);
 
 #ifdef CONFIG_IMA_BLACKLIST_KEYRING
 extern struct key *ima_blacklist_keyring;
diff --git a/init/Kconfig b/init/Kconfig
index 461ad575a608..93646fd7b1c8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2009,6 +2009,15 @@ config MODULE_SIG_ALL
 comment "Do not forget to sign required modules with scripts/sign-file"
depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
 
+config MODULE_SIG_UEFI
+   bool "Allow modules signed with certs stored in UEFI"
+   depends on MODULE_SIG && SYSTEM_BLACKLIST_KEYRING && EFI
+   select EFI_SIGNATURE_LIST_PARSER
+   help
+ This will import certificates stored in UEFI and allow modules
+ signed with those to be loaded.  It will also disallow loading
+ of modules stored in the UEFI dbx variable.
+
 choice
prompt "Which hash algorithm should modules be signed with?"
depends on MODULE_SIG
diff --git a/kernel/Makefile b/kernel/Makefile
index eb26e12c6c2a..e0c2268cb97e 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -57,6 +57,7 @@ endif
 obj-$(CONFIG_UID16) += uid16.o
 obj-$(CONFIG_MODULES) += module.o
 obj-$(CONFIG_MODULE_SIG) += module_signing.o
+obj-$(CONFIG_MODULE_SIG_UEFI) += modsign_uefi.o
 obj-$(CONFIG_KALLSYMS) += kallsyms.o
 obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
 obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
@@ -113,6 +114,8 @@ obj-$(CONFIG_MEMBARRIER) += membarrier.o
 
 obj-$(CONFIG_HAS_IOMEM) += memremap.o
 
+$(obj)/modsign_uefi.o: KBUILD_CFLAGS += -fshort-wchar
+
 $(obj)/configs.o: $(obj)/config_data.h
 
 # config_data.h contains the same information as ikconfig.h but gzipped.
diff --git a/kernel/modsign_uefi.c b/kernel/modsign_uefi.c
new file mode 100644
index ..fe4a6f2bf10a
--- /dev/null
+++ b/kernel/modsign_uefi.c
@@ -0,0 +1,99 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "module-internal.h"
+
+static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid, 
unsigned long *size)
+{
+   efi_status_t status;
+   unsigned long lsize = 4;
+   unsigned long tmpdb[4];
+   void *db = NULL;
+
+   status = efi.get_variable(name, guid, NULL, , );
+   if (status != EFI_BUFFER_TOO_SMALL) {
+   pr_err("Couldn't get size: 0x%lx\n", status);
+   return NULL;
+   }
+
+   db = kmalloc(lsize, GFP_KERNEL);
+   if (!db) {
+   pr_err("Couldn't allocate memory for uefi cert list\n");
+   goto out;
+   }
+
+   status = efi.get_variable(name, guid, NULL, , db);
+   if (status != EFI_SUCCESS) {
+   kfree(db);
+   db = NULL;
+   

[PATCH 17/20] KEYS: Add a system blacklist keyring

[Josh Boyer]

This adds an additional keyring that is used to store certificates that
are blacklisted.  This keyring is searched first when loading signed modules
and if the module's certificate is found, it will refuse to load.  This is
useful in cases where third party certificates are used for module signing.

Signed-off-by: Josh Boyer <jwbo...@fedoraproject.org>
---
 certs/system_keyring.c| 22 ++
 include/keys/system_keyring.h |  4 
 init/Kconfig  |  9 +
 3 files changed, 35 insertions(+)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 50979d6dcecd..787eeead2f57 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -22,6 +22,9 @@ static struct key *builtin_trusted_keys;
 #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
 static struct key *secondary_trusted_keys;
 #endif
+#ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
+struct key *system_blacklist_keyring;
+#endif
 
 extern __initconst const u8 system_certificate_list[];
 extern __initconst const unsigned long system_certificate_list_size;
@@ -99,6 +102,16 @@ static __init int system_trusted_keyring_init(void)
if (key_link(secondary_trusted_keys, builtin_trusted_keys) < 0)
panic("Can't link trusted keyrings\n");
 #endif
+#ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
+   system_blacklist_keyring = keyring_alloc(".system_blacklist_keyring",
+   KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
+   ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
+KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH),
+   KEY_ALLOC_NOT_IN_QUOTA,
+   NULL, NULL);
+   if (IS_ERR(system_blacklist_keyring))
+   panic("Can't allocate system blacklist keyring\n");
+#endif
 
return 0;
 }
@@ -214,6 +227,15 @@ int verify_pkcs7_signature(const void *data, size_t len,
trusted_keys = builtin_trusted_keys;
 #endif
}
+#ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
+   ret = pkcs7_validate_trust(pkcs7, system_blacklist_keyring);
+   if (!ret) {
+   /* module is signed with a cert in the blacklist.  reject */
+   pr_err("Module key is in the blacklist\n");
+   ret = -EKEYREJECTED;
+   goto error;
+   }
+#endif
ret = pkcs7_validate_trust(pkcs7, trusted_keys);
if (ret < 0) {
if (ret == -ENOKEY)
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index fbd4647767e9..5bc291a3d261 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -33,6 +33,10 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
 #define restrict_link_by_builtin_and_secondary_trusted 
restrict_link_by_builtin_trusted
 #endif
 
+#ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
+extern struct key *system_blacklist_keyring;
+#endif
+
 #ifdef CONFIG_IMA_BLACKLIST_KEYRING
 extern struct key *ima_blacklist_keyring;
 
diff --git a/init/Kconfig b/init/Kconfig
index 34407f15e6d3..461ad575a608 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1859,6 +1859,15 @@ config SYSTEM_DATA_VERIFICATION
  module verification, kexec image verification and firmware blob
  verification.
 
+config SYSTEM_BLACKLIST_KEYRING
+   bool "Provide system-wide ring of blacklisted keys"
+   depends on KEYS
+   help
+ Provide a system keyring to which blacklisted keys can be added.
+ Keys in the keyring are considered entirely untrusted.  Keys in this
+ keyring are used by the module signature checking to reject loading
+ of modules signed with a blacklisted key.
+
 config PROFILING
bool "Profiling support"
help
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 20/20] Add sysrq option to disable secure boot mode

[Josh Boyer]

From: Kyle McMartin 

Bugzilla: N/A
Upstream-status: Fedora mustard
---
 arch/x86/kernel/setup.c | 36 
 drivers/input/misc/uinput.c |  1 +
 drivers/tty/sysrq.c | 19 +--
 include/linux/input.h   |  5 +
 include/linux/sysrq.h   |  8 +++-
 kernel/debug/kdb/kdb_main.c |  2 +-
 kernel/module.c |  2 +-
 7 files changed, 64 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index b93183336674..dab2882927c2 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,11 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 
 #include 
@@ -1286,6 +1291,37 @@ void __init i386_reserve_resources(void)
 
 #endif /* CONFIG_X86_32 */
 
+#ifdef CONFIG_MAGIC_SYSRQ
+#ifdef CONFIG_MODULE_SIG
+extern bool sig_enforce;
+#endif
+
+static void sysrq_handle_secure_boot(int key)
+{
+   if (!efi_enabled(EFI_SECURE_BOOT))
+   return;
+
+   pr_info("Secure boot disabled\n");
+#ifdef CONFIG_MODULE_SIG
+   sig_enforce = fips_enabled;
+#endif
+}
+static struct sysrq_key_op secure_boot_sysrq_op = {
+   .handler=   sysrq_handle_secure_boot,
+   .help_msg   =   "unSB(x)",
+   .action_msg =   "Disabling Secure Boot restrictions",
+   .enable_mask=   SYSRQ_DISABLE_USERSPACE,
+};
+static int __init secure_boot_sysrq(void)
+{
+   if (efi_enabled(EFI_SECURE_BOOT))
+   register_sysrq_key('x', _boot_sysrq_op);
+   return 0;
+}
+late_initcall(secure_boot_sysrq);
+#endif /*CONFIG_MAGIC_SYSRQ*/
+
+
 static struct notifier_block kernel_offset_notifier = {
.notifier_call = dump_kernel_offset
 };
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 92595b98e7ed..894ed3f74f04 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -379,6 +379,7 @@ static int uinput_allocate_device(struct uinput_device 
*udev)
if (!udev->dev)
return -ENOMEM;
 
+   udev->dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
udev->dev->event = uinput_dev_event;
input_set_drvdata(udev->dev, udev);
 
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 52bbd27e93ae..594bd731253a 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -479,6 +479,7 @@ static struct sysrq_key_op *sysrq_key_table[36] = {
/* x: May be registered on mips for TLB dump */
/* x: May be registered on ppc/powerpc for xmon */
/* x: May be registered on sparc64 for global PMU dump */
+   /* x: May be registered on x86_64 for disabling secure boot */
NULL,   /* x */
/* y: May be registered on sparc64 for global register dump */
NULL,   /* y */
@@ -522,7 +523,7 @@ static void __sysrq_put_key_op(int key, struct sysrq_key_op 
*op_p)
 sysrq_key_table[i] = op_p;
 }
 
-void __handle_sysrq(int key, bool check_mask)
+void __handle_sysrq(int key, int from)
 {
struct sysrq_key_op *op_p;
int orig_log_level;
@@ -542,11 +543,15 @@ void __handle_sysrq(int key, bool check_mask)
 
 op_p = __sysrq_get_key_op(key);
 if (op_p) {
+   /* Ban synthetic events from some sysrq functionality */
+   if ((from == SYSRQ_FROM_PROC || from == SYSRQ_FROM_SYNTHETIC) &&
+   op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
+   printk("This sysrq operation is disabled from 
userspace.\n");
/*
 * Should we check for enabled operations (/proc/sysrq-trigger
 * should not) and is the invoked operation enabled?
 */
-   if (!check_mask || sysrq_on_mask(op_p->enable_mask)) {
+   if (from == SYSRQ_FROM_KERNEL || 
sysrq_on_mask(op_p->enable_mask)) {
pr_cont("%s\n", op_p->action_msg);
console_loglevel = orig_log_level;
op_p->handler(key);
@@ -578,7 +583,7 @@ void __handle_sysrq(int key, bool check_mask)
 void handle_sysrq(int key)
 {
if (sysrq_on())
-   __handle_sysrq(key, true);
+   __handle_sysrq(key, SYSRQ_FROM_KERNEL);
 }
 EXPORT_SYMBOL(handle_sysrq);
 
@@ -659,7 +664,7 @@ static void sysrq_do_reset(unsigned long _state)
 static void sysrq_handle_reset_request(struct sysrq_state *state)
 {
if (state->reset_requested)
-   __handle_sysrq(sysrq_xlate[KEY_B], false);
+   __handle_sysrq(sysrq_xlate[KEY_B], SYSRQ_FROM_KERNEL);
 
if (sysrq_reset_downtime_ms)
mod_timer(>keyreset_timer,
@@ -810,8 +815,10 @@ static bool sysrq_handle_keypress(struct sysrq_state 
*sysrq,
 
default:
if (sysrq->active && value && value != 2) {
+   int from = sysrq->handle.dev->flags & 

[PATCH 16/20] Add an EFI signature blob parser and key loader.

[Josh Boyer]

From: Dave Howells 

X.509 certificates are loaded into the specified keyring as asymmetric type
keys.

[labb...@fedoraproject.org: Drop KEY_ALLOC_TRUSTED]
Signed-off-by: David Howells 
---
 crypto/asymmetric_keys/Kconfig  |   8 +++
 crypto/asymmetric_keys/Makefile |   1 +
 crypto/asymmetric_keys/efi_parser.c | 108 
 include/linux/efi.h |   4 ++
 4 files changed, 121 insertions(+)
 create mode 100644 crypto/asymmetric_keys/efi_parser.c

diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 331f6baf2df8..5f9002d3192e 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -61,4 +61,12 @@ config SIGNED_PE_FILE_VERIFICATION
  This option provides support for verifying the signature(s) on a
  signed PE binary.
 
+config EFI_SIGNATURE_LIST_PARSER
+   bool "EFI signature list parser"
+   depends on EFI
+   select X509_CERTIFICATE_PARSER
+   help
+ This option provides support for parsing EFI signature lists for
+ X.509 certificates and turning them into keys.
+
 endif # ASYMMETRIC_KEY_TYPE
diff --git a/crypto/asymmetric_keys/Makefile b/crypto/asymmetric_keys/Makefile
index 6516855bec18..c099fe15ed6d 100644
--- a/crypto/asymmetric_keys/Makefile
+++ b/crypto/asymmetric_keys/Makefile
@@ -10,6 +10,7 @@ asymmetric_keys-y := \
signature.o
 
 obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key.o
+obj-$(CONFIG_EFI_SIGNATURE_LIST_PARSER) += efi_parser.o
 
 #
 # X.509 Certificate handling
diff --git a/crypto/asymmetric_keys/efi_parser.c 
b/crypto/asymmetric_keys/efi_parser.c
new file mode 100644
index ..636feb18b733
--- /dev/null
+++ b/crypto/asymmetric_keys/efi_parser.c
@@ -0,0 +1,108 @@
+/* EFI signature/key/certificate list parser
+ *
+ * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt) "EFI: "fmt
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static __initdata efi_guid_t efi_cert_x509_guid = EFI_CERT_X509_GUID;
+
+/**
+ * parse_efi_signature_list - Parse an EFI signature list for certificates
+ * @data: The data blob to parse
+ * @size: The size of the data blob
+ * @keyring: The keyring to add extracted keys to
+ */
+int __init parse_efi_signature_list(const void *data, size_t size, struct key 
*keyring)
+{
+   unsigned offs = 0;
+   size_t lsize, esize, hsize, elsize;
+
+   pr_devel("-->%s(,%zu)\n", __func__, size);
+
+   while (size > 0) {
+   efi_signature_list_t list;
+   const efi_signature_data_t *elem;
+   key_ref_t key;
+
+   if (size < sizeof(list))
+   return -EBADMSG;
+
+   memcpy(, data, sizeof(list));
+   pr_devel("LIST[%04x] guid=%pUl ls=%x hs=%x ss=%x\n",
+offs,
+list.signature_type.b, list.signature_list_size,
+list.signature_header_size, list.signature_size);
+
+   lsize = list.signature_list_size;
+   hsize = list.signature_header_size;
+   esize = list.signature_size;
+   elsize = lsize - sizeof(list) - hsize;
+
+   if (lsize > size) {
+   pr_devel("<--%s() = -EBADMSG [overrun @%x]\n",
+__func__, offs);
+   return -EBADMSG;
+   }
+   if (lsize < sizeof(list) ||
+   lsize - sizeof(list) < hsize ||
+   esize < sizeof(*elem) ||
+   elsize < esize ||
+   elsize % esize != 0) {
+   pr_devel("- bad size combo @%x\n", offs);
+   return -EBADMSG;
+   }
+
+   if (efi_guidcmp(list.signature_type, efi_cert_x509_guid) != 0) {
+   data += lsize;
+   size -= lsize;
+   offs += lsize;
+   continue;
+   }
+
+   data += sizeof(list) + hsize;
+   size -= sizeof(list) + hsize;
+   offs += sizeof(list) + hsize;
+
+   for (; elsize > 0; elsize -= esize) {
+   elem = data;
+
+   pr_devel("ELEM[%04x]\n", offs);
+
+   key = key_create_or_update(
+   make_key_ref(keyring, 1),
+   "asymmetric",
+   NULL,
+   >signature_data,
+   esize - sizeof(*elem),
+  

[PATCH 09/20] x86: Restrict MSR access when module loading is restricted

[Josh Boyer]

From: Matthew Garrett 

Writing to MSRs should not be allowed if module loading is restricted,
since it could lead to execution of arbitrary code in kernel mode. Based
on a patch by Kees Cook.

Cc: Kees Cook 
Signed-off-by: Matthew Garrett 
---
 arch/x86/kernel/msr.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 7f3550acde1b..963ba4011923 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -83,6 +83,9 @@ static ssize_t msr_write(struct file *file, const char __user 
*buf,
int err = 0;
ssize_t bytes = 0;
 
+   if (secure_modules())
+   return -EPERM;
+
if (count % 8)
return -EINVAL; /* Invalid chunk size */
 
@@ -130,6 +133,10 @@ static long msr_ioctl(struct file *file, unsigned int ioc, 
unsigned long arg)
err = -EBADF;
break;
}
+   if (secure_modules()) {
+   err = -EPERM;
+   break;
+   }
if (copy_from_user(, uregs, sizeof regs)) {
err = -EFAULT;
break;
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 15/20] Add EFI signature data types

[Josh Boyer]

From: Dave Howells 

Add the data types that are used for containing hashes, keys and certificates
for cryptographic verification.

Bugzilla: N/A
Upstream-status: Fedora mustard for now

Signed-off-by: David Howells 
---
 include/linux/efi.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index 5af91b58afae..190858d62fe3 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -603,6 +603,9 @@ void efi_native_runtime_setup(void);
 #define LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID   EFI_GUID(0xe03fc20a, 0x85dc, 
0x406e,  0xb9, 0x0e, 0x4a, 0xb5, 0x02, 0x37, 0x1d, 0x95)
 #define LINUX_EFI_LOADER_ENTRY_GUIDEFI_GUID(0x4a67b082, 0x0a4c, 
0x41cf,  0xb6, 0xc7, 0x44, 0x0b, 0x29, 0xbb, 0x8c, 0x4f)
 
+#define EFI_CERT_SHA256_GUID   EFI_GUID(0xc1c41626, 0x504c, 
0x4092,  0xac, 0xa9, 0x41, 0xf9, 0x36, 0x93, 0x43, 0x28)
+#define EFI_CERT_X509_GUID EFI_GUID(0xa5c059a1, 0x94e4, 
0x4aa7,  0x87, 0xb5, 0xab, 0x15, 0x5c, 0x2b, 0xf0, 0x72)
+
 typedef struct {
efi_guid_t guid;
u64 table;
@@ -853,6 +856,20 @@ typedef struct {
efi_memory_desc_t entry[0];
 } efi_memory_attributes_table_t;
 
+typedef struct  {
+   efi_guid_t signature_owner;
+   u8 signature_data[];
+} efi_signature_data_t;
+
+typedef struct {
+   efi_guid_t signature_type;
+   u32 signature_list_size;
+   u32 signature_header_size;
+   u32 signature_size;
+   u8 signature_header[];
+   /* efi_signature_data_t signatures[][] */
+} efi_signature_list_t;
+
 /*
  * All runtime access to EFI goes through this structure:
  */
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 14/20] hibernate: Disable in a signed modules environment

[Josh Boyer]

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it in
a secure modules environment.

Signed-off-by: Josh Boyer <jwbo...@fedoraproject.org>
---
 kernel/power/hibernate.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index b26dbc48c75b..ab187ad3fc61 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "power.h"
@@ -67,7 +68,7 @@ static const struct platform_hibernation_ops *hibernation_ops;
 
 bool hibernation_available(void)
 {
-   return (nohibernate == 0);
+   return ((nohibernate == 0) && !secure_modules());
 }
 
 /**
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 13/20] efi: Add EFI_SECURE_BOOT bit

[Josh Boyer]

UEFI machines can be booted in Secure Boot mode.  Add a EFI_SECURE_BOOT bit
for use with efi_enabled.

Signed-off-by: Josh Boyer <jwbo...@fedoraproject.org>
---
 arch/x86/kernel/setup.c | 2 ++
 include/linux/efi.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d40e961753c9..b93183336674 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1162,7 +1162,9 @@ void __init setup_arch(char **cmdline_p)
 
 #ifdef CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE
if (boot_params.secure_boot) {
+   set_bit(EFI_SECURE_BOOT, );
enforce_signed_modules();
+   pr_info("Secure boot enabled\n");
}
 #endif
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index ce943d5accfd..5af91b58afae 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1046,6 +1046,7 @@ extern int __init efi_setup_pcdp_console(char *);
 #define EFI_ARCH_1 7   /* First arch-specific bit */
 #define EFI_DBG8   /* Print additional debug info 
at runtime */
 #define EFI_NX_PE_DATA 9   /* Can runtime data regions be mapped 
non-executable? */
+#define EFI_SECURE_BOOT10  /* Are we in Secure Boot mode? 
*/
 
 #ifdef CONFIG_EFI
 /*
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 12/20] efi: Disable secure boot if shim is in insecure mode

[Josh Boyer]

A user can manually tell the shim boot loader to disable validation of
images it loads.  When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set.  Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.

Signed-off-by: Josh Boyer <jwbo...@fedoraproject.org>
---
 arch/x86/boot/compressed/eboot.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ebc85c1eefd6..50e027f388d8 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -540,8 +540,9 @@ static void setup_efi_pci(struct boot_params *params)
 
 static int get_secure_boot(void)
 {
-   u8 sb, setup;
+   u8 sb, setup, moksbstate;
unsigned long datasize = sizeof(sb);
+   u32 attr;
efi_guid_t var_guid = EFI_GLOBAL_VARIABLE_GUID;
efi_status_t status;
 
@@ -565,6 +566,23 @@ static int get_secure_boot(void)
if (setup == 1)
return 0;
 
+   /* See if a user has put shim into insecure_mode.  If so, and the 
variable
+* doesn't have the runtime attribute set, we might as well honor that.
+*/
+   var_guid = EFI_SHIM_LOCK_GUID;
+   status = efi_early->call((unsigned 
long)sys_table->runtime->get_variable,
+   L"MokSBState", _guid, , ,
+   );
+
+   /* If it fails, we don't care why.  Default to secure */
+   if (status != EFI_SUCCESS)
+   return 1;
+
+   if (!(attr & EFI_VARIABLE_RUNTIME_ACCESS)) {
+   if (moksbstate == 1)
+   return 0;
+   }
+
return 1;
 }
 
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 10/20] Add option to automatically enforce module signatures when in Secure Boot mode

[Josh Boyer]

From: Matthew Garrett 

UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that all kernel modules also be signed. Add a configuration option
that enforces this automatically when enabled.

Signed-off-by: Matthew Garrett 
---
 Documentation/x86/zero-page.txt   |  2 ++
 arch/x86/Kconfig  | 11 ++
 arch/x86/boot/compressed/eboot.c  | 66 +++
 arch/x86/include/uapi/asm/bootparam.h |  3 +-
 arch/x86/kernel/setup.c   |  6 
 include/linux/module.h|  6 
 kernel/module.c   |  7 
 7 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index 95a4d34af3fd..b8527c6b7646 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -31,6 +31,8 @@ OffsetProto   NameMeaning
 1E9/001ALL eddbuf_entries  Number of entries in eddbuf (below)
 1EA/001ALL edd_mbr_sig_buf_entries Number of entries in 
edd_mbr_sig_buffer
(below)
+1EB/001ALL kbd_status  Numlock is enabled
+1EC/001ALL secure_boot Secure boot is enabled in the firmware
 1EF/001ALL sentinelUsed to detect broken bootloaders
 290/040ALL edd_mbr_sig_buffer EDD MBR signatures
 2D0/A00ALL e820_mapE820 memory map table
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636d1065..d666ef8b616c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1786,6 +1786,17 @@ config EFI_MIXED
 
   If unsure, say N.
 
+config EFI_SECURE_BOOT_SIG_ENFORCE
+   def_bool n
+   depends on EFI
+   prompt "Force module signing when UEFI Secure Boot is enabled"
+   ---help---
+ UEFI Secure Boot provides a mechanism for ensuring that the
+ firmware will only load signed bootloaders and kernels. Certain
+ use cases may also require that all kernel modules also be signed.
+ Say Y here to automatically enable module signature enforcement
+ when a system boots with UEFI Secure Boot enabled.
+
 config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index cc69e37548db..ebc85c1eefd6 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../string.h"
 #include "eboot.h"
@@ -537,6 +538,67 @@ static void setup_efi_pci(struct boot_params *params)
efi_call_early(free_pool, pci_handle);
 }
 
+static int get_secure_boot(void)
+{
+   u8 sb, setup;
+   unsigned long datasize = sizeof(sb);
+   efi_guid_t var_guid = EFI_GLOBAL_VARIABLE_GUID;
+   efi_status_t status;
+
+   status = efi_early->call((unsigned 
long)sys_table->runtime->get_variable,
+   L"SecureBoot", _guid, NULL, , );
+
+   if (status != EFI_SUCCESS)
+   return 0;
+
+   if (sb == 0)
+   return 0;
+
+
+   status = efi_early->call((unsigned 
long)sys_table->runtime->get_variable,
+   L"SetupMode", _guid, NULL, ,
+   );
+
+   if (status != EFI_SUCCESS)
+   return 0;
+
+   if (setup == 1)
+   return 0;
+
+   return 1;
+}
+
+
+/*
+ * See if we have Graphics Output Protocol
+ */
+static efi_status_t setup_gop(struct screen_info *si, efi_guid_t *proto,
+ unsigned long size)
+{
+   efi_status_t status;
+   void **gop_handle = NULL;
+
+   status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
+   size, (void **)_handle);
+   if (status != EFI_SUCCESS)
+   return status;
+
+   status = efi_call_early(locate_handle,
+   EFI_LOCATE_BY_PROTOCOL,
+   proto, NULL, , gop_handle);
+   if (status != EFI_SUCCESS)
+   goto free_handle;
+
+   if (efi_early->is64)
+   status = setup_gop64(si, proto, size, gop_handle);
+   else
+   status = setup_gop32(si, proto, size, gop_handle);
+
+free_handle:
+   efi_call_early(free_pool, gop_handle);
+   return status;
+}
+
 static efi_status_t
 setup_uga32(void **uga_handle, unsigned long size, u32 *width, u32 *height)
 {
@@ -1094,6 +1156,10 @@ struct boot_params *efi_main(struct efi_config *c,
else
setup_boot_services32(efi_early);
 
+   sanitize_boot_params(boot_params);
+
+   boot_params->secure_boot = get_secure_boot();
+
setup_graphics(boot_params);
 

[PATCH 11/20] efi: Add SHIM and image security database GUID definitions

[Josh Boyer]

Add the definitions for shim and image security database, both of which
are used widely in various Linux distros.

Signed-off-by: Josh Boyer <jwbo...@fedoraproject.org>
---
 include/linux/efi.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index 2d089487d2da..ce943d5accfd 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -592,6 +592,9 @@ void efi_native_runtime_setup(void);
 #define EFI_MEMORY_ATTRIBUTES_TABLE_GUID   EFI_GUID(0xdcfa911d, 0x26eb, 
0x469f,  0xa2, 0x20, 0x38, 0xb7, 0xdc, 0x46, 0x12, 0x20)
 #define EFI_CONSOLE_OUT_DEVICE_GUIDEFI_GUID(0xd3b36f2c, 0xd551, 
0x11d4,  0x9a, 0x46, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
 
+#define EFI_IMAGE_SECURITY_DATABASE_GUID   EFI_GUID(0xd719b2cb, 0x3d3a, 
0x4596, 0xa3, 0xbc, 0xda, 0xd0, 0x0e, 0x67, 0x65, 0x6f)
+#define EFI_SHIM_LOCK_GUID EFI_GUID(0x605dab50, 
0xe046, 0x4300, 0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23)
+
 /*
  * This GUID is used to pass to the kernel proper the struct screen_info
  * structure that was populated by the stub based on the GOP protocol instance
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 04/20] ACPI: Limit access to custom_method

[Josh Boyer]

From: Matthew Garrett 

custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if any such restrictions have been enabled.

Signed-off-by: Matthew Garrett 
---
 drivers/acpi/custom_method.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index c68e72414a67..4277938af700 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -29,6 +29,9 @@ static ssize_t cm_write(struct file *file, const char __user 
* user_buf,
struct acpi_table_header table;
acpi_status status;
 
+   if (secure_modules())
+   return -EPERM;
+
if (!(*ppos)) {
/* parse the table header to get the table length */
if (count <= sizeof(struct acpi_table_header))
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 08/20] kexec: Disable at runtime if the kernel enforces module loading restrictions

[Josh Boyer]

From: Matthew Garrett 

kexec permits the loading and execution of arbitrary code in ring 0, which
is something that module signing enforcement is meant to prevent. It makes
sense to disable kexec in this situation.

Signed-off-by: Matthew Garrett 
---
 kernel/kexec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 980936a90ee6..fce28bf7d5d7 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -194,6 +195,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned 
long, nr_segments,
return -EPERM;
 
/*
+* kexec can be used to circumvent module loading restrictions, so
+* prevent loading in that case
+*/
+   if (secure_modules())
+   return -EPERM;
+
+   /*
 * Verify we have a legal set of flags
 * This leaves us room for future extensions.
 */
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 05/20] asus-wmi: Restrict debugfs interface when module loading is restricted

[Josh Boyer]

From: Matthew Garrett 

We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions. Prevent that if any of
these features are enabled.

Signed-off-by: Matthew Garrett 
---
 drivers/platform/x86/asus-wmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index ce6ca31a2d09..55d23994d6a2 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1872,6 +1872,9 @@ static int show_dsts(struct seq_file *m, void *data)
int err;
u32 retval = -1;
 
+   if (secure_modules())
+   return -EPERM;
+
err = asus_wmi_get_devstate(asus, asus->debug.dev_id, );
 
if (err < 0)
@@ -1888,6 +1891,9 @@ static int show_devs(struct seq_file *m, void *data)
int err;
u32 retval = -1;
 
+   if (secure_modules())
+   return -EPERM;
+
err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
);
 
@@ -1912,6 +1918,9 @@ static int show_call(struct seq_file *m, void *data)
union acpi_object *obj;
acpi_status status;
 
+   if (secure_modules())
+   return -EPERM;
+
status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
 1, asus->debug.method_id,
 , );
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 02/20] PCI: Lock down BAR access when module security is enabled

[Josh Boyer]

From: Matthew Garrett 

Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to modify
kernel code, allowing them to circumvent disabled module loading or module
signing. Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.

Signed-off-by: Matthew Garrett 
---
 drivers/pci/pci-sysfs.c | 10 ++
 drivers/pci/proc.c  |  8 +++-
 drivers/pci/syscall.c   |  3 ++-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index bcd10c795284..a950301496f3 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci.h"
 
 static int sysfs_initialized;  /* = 0 */
@@ -716,6 +717,9 @@ static ssize_t pci_write_config(struct file *filp, struct 
kobject *kobj,
loff_t init_off = off;
u8 *data = (u8 *) buf;
 
+   if (secure_modules())
+   return -EPERM;
+
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -1007,6 +1011,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct 
bin_attribute *attr,
resource_size_t start, end;
int i;
 
+   if (secure_modules())
+   return -EPERM;
+
for (i = 0; i < PCI_ROM_RESOURCE; i++)
if (res == >resource[i])
break;
@@ -1106,6 +1113,9 @@ static ssize_t pci_write_resource_io(struct file *filp, 
struct kobject *kobj,
 struct bin_attribute *attr, char *buf,
 loff_t off, size_t count)
 {
+   if (secure_modules())
+   return -EPERM;
+
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
 }
 
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 2408abe4ee8c..59f321c56c18 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -116,6 +116,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const 
char __user *buf,
int size = dev->cfg_size;
int cnt;
 
+   if (secure_modules())
+   return -EPERM;
+
if (pos >= size)
return 0;
if (nbytes >= size)
@@ -195,6 +198,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned 
int cmd,
 #endif /* HAVE_PCI_MMAP */
int ret = 0;
 
+   if (secure_modules())
+   return -EPERM;
+
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -233,7 +239,7 @@ static int proc_bus_pci_mmap(struct file *file, struct 
vm_area_struct *vma)
struct pci_filp_private *fpriv = file->private_data;
int i, ret, write_combine;
 
-   if (!capable(CAP_SYS_RAWIO))
+   if (!capable(CAP_SYS_RAWIO) || secure_modules())
return -EPERM;
 
/* Make sure the caller is mapping a real resource for this device */
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index b91c4da68365..98f5637304d1 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "pci.h"
 
@@ -92,7 +93,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned 
long, dfn,
u32 dword;
int err = 0;
 
-   if (!capable(CAP_SYS_ADMIN))
+   if (!capable(CAP_SYS_ADMIN) || secure_modules())
return -EPERM;
 
dev = pci_get_bus_and_slot(bus, dfn);
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 01/20] Add secure_modules() call

[Josh Boyer]

From: Matthew Garrett 

Provide a single call to allow kernel code to determine whether the system
has been configured to either disable module loading entirely or to load
only modules signed with a trusted key.

Bugzilla: N/A
Upstream-status: Fedora mustard.  Replaced by securelevels, but that was nak'd

Signed-off-by: Matthew Garrett 
---
 include/linux/module.h |  6 ++
 kernel/module.c| 10 ++
 2 files changed, 16 insertions(+)

diff --git a/include/linux/module.h b/include/linux/module.h
index 0c3207d26ac0..05bd6c989a0c 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -641,6 +641,8 @@ static inline bool is_livepatch_module(struct module *mod)
 }
 #endif /* CONFIG_LIVEPATCH */
 
+extern bool secure_modules(void);
+
 #else /* !CONFIG_MODULES... */
 
 static inline struct module *__module_address(unsigned long addr)
@@ -750,6 +752,10 @@ static inline bool module_requested_async_probing(struct 
module *module)
return false;
 }
 
+static inline bool secure_modules(void)
+{
+   return false;
+}
 #endif /* CONFIG_MODULES */
 
 #ifdef CONFIG_SYSFS
diff --git a/kernel/module.c b/kernel/module.c
index f57dd63186e6..cb864505d020 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4284,3 +4284,13 @@ void module_layout(struct module *mod,
 }
 EXPORT_SYMBOL(module_layout);
 #endif
+
+bool secure_modules(void)
+{
+#ifdef CONFIG_MODULE_SIG
+   return (sig_enforce || modules_disabled);
+#else
+   return modules_disabled;
+#endif
+}
+EXPORT_SYMBOL(secure_modules);
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 03/20] x86: Lock down IO port access when module security is enabled

[Josh Boyer]

From: Matthew Garrett 

IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down by default.

Signed-off-by: Matthew Garrett 
---
 arch/x86/kernel/ioport.c | 5 +++--
 drivers/char/mem.c   | 4 
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 589b3193f102..ab8372443efb 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -28,7 +29,7 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long 
num, int turn_on)
 
if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
return -EINVAL;
-   if (turn_on && !capable(CAP_SYS_RAWIO))
+   if (turn_on && (!capable(CAP_SYS_RAWIO) || secure_modules()))
return -EPERM;
 
/*
@@ -108,7 +109,7 @@ SYSCALL_DEFINE1(iopl, unsigned int, level)
return -EINVAL;
/* Trying to gain more privileges? */
if (level > old) {
-   if (!capable(CAP_SYS_RAWIO))
+   if (!capable(CAP_SYS_RAWIO) || secure_modules())
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5bb1985ec484..7f1a7ab5850d 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -580,6 +581,9 @@ static ssize_t write_port(struct file *file, const char 
__user *buf,
unsigned long i = *ppos;
const char __user *tmp = buf;
 
+   if (secure_modules())
+   return -EPERM;
+
if (!access_ok(VERIFY_READ, buf, count))
return -EFAULT;
while (count-- > 0 && i < 65536) {
-- 
2.9.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Refresh Secure Boot patchset

[Josh Boyer]

The upstream 0-day bot found an issue with the existing patchset in the
rawhide kernel.  Everything builds fine as a whole, but if one were to
bisect the patches, a build would break because the shim GUID is used
in a patch before it is actually defined.

Fix this by inserting a patch in the series to explicitly define that
and the image security database GUIDs.  This posting is a refresh of the 
whole series, for completeness.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: realtek wireless modules

[Josh Boyer]

On Mon, Oct 10, 2016 at 2:02 PM, Peter Robinson  wrote:
> Hi Laura, Justin, et el,
>
> I've been playing with a handful of cheap USB wireless modules for
> support on the Raspberry Pi and other similar devices.
>
> I've noticed that there's a bunch of overlap regarding usb IDs between
> the newer (and IMO preferred) rtl8xxxu and the vendor collection of
> drivers so you often get both drivers loaded. I've tended to fix this
> by just blacklisting the vendor upstream drivers.

Wait, that's a situation that exists upstream?

> The question is how best to deal with this in a generic way to ensure
> a good experience with these in Fedora?
>
> Do we cross reference all the USB IDs and disable the non rtl8xxxu
> drivers once they have full coverage in rtl8xxxu? Do we actively patch
> out the IDs supported in rtl8xxxu from associated drivers?

I'd suggest posing this question on the upstream wireless list, with
the various driver maintainers CC'd.  If it's an upstream problem then
it really needs solving upstream.

josh
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: The future of secure boot patches in Fedora

[Josh Boyer]

On Mon, Aug 22, 2016 at 9:18 PM, Jarod Wilson <ja...@redhat.com> wrote:
> On Mon, Aug 22, 2016 at 08:34:02PM -0400, Josh Boyer wrote:
>> On Mon, Aug 22, 2016 at 8:22 PM, Jarod Wilson <ja...@redhat.com> wrote:
>> > On Mon, Aug 22, 2016 at 03:50:22PM -0600, Chris Murphy wrote:
>> >> On Mon, Aug 22, 2016 at 3:14 PM, Laura Abbott <labb...@redhat.com> wrote:
>> >> > On 08/22/2016 01:16 PM, Chris Murphy wrote:
>> >> >>
>> >> >> On Mon, Aug 22, 2016 at 2:08 PM, John Dulaney <jdula...@gnu.org> wrote:
>> >> >>>
>> >> >>> On Mon, Aug 22, 2016 at 12:28:18PM -0700, Laura Abbott wrote:
>> >> >>>>
>> >> >>>> The secure boot patches have been around in the Fedora tree for a 
>> >> >>>> while
>> >> >>>> now.
>> >> >>>> They work well enough but there has not been much active work in 
>> >> >>>> getting
>> >> >>>> them accepted upstream in recent years. The longer they exist out of
>> >> >>>> tree
>> >> >>>> the harder they get to maintain without extra support. If there 
>> >> >>>> isn't a
>> >> >>>> path for the current secure boot patch set to be accepted upstream, 
>> >> >>>> we
>> >> >>>> need
>> >> >>>> to seriously consider if it's worth carrying long term.
>> >> >>>>
>> >> >>>> Thoughts?
>> >> >>>
>> >> >>>
>> >> >>> So, how would we handle secure boot moving forward?
>> >> >>
>> >> >>
>> >> >> How are other distros handling this? Does upstream have an alternative?
>> >> >>
>> >> >
>> >> > There isn't one unified answer. Every distro seems to be doing something
>> >> > different because upstream hasn't provided a single solution.
>> >> >
>> >> > Moving forward, we would treat secure boot like feature that is still
>> >> > in progress. This means taking the existing secure boot patches or
>> >> > a new approach and submitting them in a way that's acceptable to the
>> >> > upstream
>> >> > community. This is also code for "I don't know but what we have isn't
>> >> > sustainable so let's discuss something better".
>> >>
>> >> Of course.
>> >>
>> >> What patch set are Red Hat and CentOS using? If they're not all using
>> >> the same thing is it viable to get them all using the same thing?
>> >
>> > They're using the same basic thing, but CentOS 7 and it's grandfather are
>> > based on a 3.10 kernel, so there's a gulf of difference in the codebase of
>> > that and current Fedora kernels, meaning there's no way they're going to
>> > be using exactly the same code. And once it works one particular way in
>>
>> Right.  Functionally they're fairly similar but even from a Kconfig
>> option standpoint they differ.
>>
>> > Red Hat Enterprise Linux, it's unlikely to be swapped out wholesale for
>> > the "new and improved" upstream way until the next major RHEL release.
>> > Enterprise stability and stuff. So yeah, no, you really can't get them all
>> > using the same thing. The kernel codebases are just fr too different
>> > for a fairly invasive patchset that touches bits and pieces all over the
>> > place in core areas.
>>
>> The problem here is that there is no "new and improved" upstream
>> stuff.  Fedora has a patchset that has limped along and been very
>> slightly tweaked with every rebase.  So really, there's no upstream
>> (in the kernel.org sense) stuff at all and that's the problem.
>
> Yeah, that's definitely the biggest problem here.
>
>> (BTW, aside from the key code, I would imagine most of the SB patchset
>> actually could apply to an older kernel without much difficulty.  It
>> patches paths that don't really change all that much.)
>
> Ah, I may have been mixing it up with another set, or just plain making
> bad assumptions about the complexity. I definitely had our old DSA module
> signing code that we are still carrying in RHEL6 vs. the RSA module
> signing code that finally went upstream in mind... I suppose it wouldn't

I think you're remembering the GPG signing that RHEL6 had.  RHEL7,
Fedora, and upstream don't use GPG signing at all.  They use certs and
slap them at the end.  That drastically simplifies some of the module
loading code, but it makes a lot of packaging bits uglier.

> patches. But yeah. Seems we (Red Hat) really ought to dedicate some
> resources towards getting something accepted upstream so we don't have to
> carry this around for eternity.

100% agreed.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: The future of secure boot patches in Fedora

[Josh Boyer]

On Tue, Aug 23, 2016 at 4:05 AM, Peter Robinson  wrote:
 The secure boot patches have been around in the Fedora tree for a
 while
 now.
 They work well enough but there has not been much active work in
 getting
 them accepted upstream in recent years. The longer they exist out of
 tree
 the harder they get to maintain without extra support. If there isn't
 a
 path for the current secure boot patch set to be accepted upstream,
 we
 need
 to seriously consider if it's worth carrying long term.

 Thoughts?
>>>
>>>
>>>
>>> So, how would we handle secure boot moving forward?
>>
>>
>>
>> How are other distros handling this? Does upstream have an alternative?
>>
>
> There isn't one unified answer. Every distro seems to be doing something
> different because upstream hasn't provided a single solution.
>
> Moving forward, we would treat secure boot like feature that is still
> in progress. This means taking the existing secure boot patches or
> a new approach and submitting them in a way that's acceptable to the
> upstream
> community. This is also code for "I don't know but what we have isn't
> sustainable so let's discuss something better".


 Of course.

 What patch set are Red Hat and CentOS using? If they're not all using
 the same thing is it viable to get them all using the same thing?
>>>
>>>
>>> They're using the same basic thing, but CentOS 7 and it's grandfather are
>>> based on a 3.10 kernel, so there's a gulf of difference in the codebase of
>>> that and current Fedora kernels, meaning there's no way they're going to
>>> be using exactly the same code. And once it works one particular way in
>>> Red Hat Enterprise Linux, it's unlikely to be swapped out wholesale for
>>> the "new and improved" upstream way until the next major RHEL release.
>>> Enterprise stability and stuff. So yeah, no, you really can't get them all
>>> using the same thing. The kernel codebases are just fr too different
>>> for a fairly invasive patchset that touches bits and pieces all over the
>>> place in core areas.
>>>
>>
>> You're right, distros aren't going to swap out what they have in existing
>> releases for the new hotness. I'd like to believe that if there was a
>> workable upstream solution many distros would choose to converge on that
>> for a future release with a corresponding kernel version. Maybe we will
>> have to maintain some version of these patches for older kernels like
>> Cent OS  but newer kernels could be common.
>
> Sounds like a good topic to be bought up at plumbers conf.

The problem is, it was.  Like 3 years ago.  We even had agreement.
Then things failed.

I'll be there and I'm happy to discuss it again, but I'm not holding my breath.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: The future of secure boot patches in Fedora

[Josh Boyer]

On Mon, Aug 22, 2016 at 8:22 PM, Jarod Wilson  wrote:
> On Mon, Aug 22, 2016 at 03:50:22PM -0600, Chris Murphy wrote:
>> On Mon, Aug 22, 2016 at 3:14 PM, Laura Abbott  wrote:
>> > On 08/22/2016 01:16 PM, Chris Murphy wrote:
>> >>
>> >> On Mon, Aug 22, 2016 at 2:08 PM, John Dulaney  wrote:
>> >>>
>> >>> On Mon, Aug 22, 2016 at 12:28:18PM -0700, Laura Abbott wrote:
>> 
>>  The secure boot patches have been around in the Fedora tree for a while
>>  now.
>>  They work well enough but there has not been much active work in getting
>>  them accepted upstream in recent years. The longer they exist out of
>>  tree
>>  the harder they get to maintain without extra support. If there isn't a
>>  path for the current secure boot patch set to be accepted upstream, we
>>  need
>>  to seriously consider if it's worth carrying long term.
>> 
>>  Thoughts?
>> >>>
>> >>>
>> >>> So, how would we handle secure boot moving forward?
>> >>
>> >>
>> >> How are other distros handling this? Does upstream have an alternative?
>> >>
>> >
>> > There isn't one unified answer. Every distro seems to be doing something
>> > different because upstream hasn't provided a single solution.
>> >
>> > Moving forward, we would treat secure boot like feature that is still
>> > in progress. This means taking the existing secure boot patches or
>> > a new approach and submitting them in a way that's acceptable to the
>> > upstream
>> > community. This is also code for "I don't know but what we have isn't
>> > sustainable so let's discuss something better".
>>
>> Of course.
>>
>> What patch set are Red Hat and CentOS using? If they're not all using
>> the same thing is it viable to get them all using the same thing?
>
> They're using the same basic thing, but CentOS 7 and it's grandfather are
> based on a 3.10 kernel, so there's a gulf of difference in the codebase of
> that and current Fedora kernels, meaning there's no way they're going to
> be using exactly the same code. And once it works one particular way in

Right.  Functionally they're fairly similar but even from a Kconfig
option standpoint they differ.

> Red Hat Enterprise Linux, it's unlikely to be swapped out wholesale for
> the "new and improved" upstream way until the next major RHEL release.
> Enterprise stability and stuff. So yeah, no, you really can't get them all
> using the same thing. The kernel codebases are just fr too different
> for a fairly invasive patchset that touches bits and pieces all over the
> place in core areas.

The problem here is that there is no "new and improved" upstream
stuff.  Fedora has a patchset that has limped along and been very
slightly tweaked with every rebase.  So really, there's no upstream
(in the kernel.org sense) stuff at all and that's the problem.

(BTW, aside from the key code, I would imagine most of the SB patchset
actually could apply to an older kernel without much difficulty.  It
patches paths that don't really change all that much.)

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: Kernel 4.7 rebase plans

[Josh Boyer]

On Mon, Aug 22, 2016 at 6:05 AM, Edward O'Callaghan
 wrote:
> Hi,
>
> Is there any movement on this? Sorry to rush but, without 4.7, polaris GPU's 
> are unsupported. Thus the changesets in amdgpu are critical for that hw 
> bringup, hence *really* looking forward to this hitting atleast testing as 
> soon as ideally possible. :/

Why wouldn't you use the rawhide kernel for that purpose?

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: building the rawhide kernel with cgroup-v2 cpu controller patches

[Josh Boyer]

On Tue, Aug 16, 2016 at 9:31 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> Unfortunately, due to the disagreements in the kernel development
> community, CPU controller cgroup v2 support has not been merged and
> enabling it requires applying two small out-of-tree kernel
> patches. The situation is explained in the following documentation:
>
> https://git.kernel.org/cgit/linux/kernel/git/tj/cgroup.git/tree/Documentation/cgroup-v2-cpu.txt?h=cgroup-v2-cpu
>
> While it isn't clear what will happen with CPU controller cgroup v2
> support, there are critical features which are possible only on cgroup
> v2 such as buffered write control making cgroup v2 essential for a lot
> of workloads. Also we finally have reliable empty cgroup reporting which
> avoids various systemd issues with zombie scope units and such.
>
> Systemd recently gained experimental support for the new cgroup v2 cpu
> controller [1], which of course only works for people who
> a) are running with systemd.unified_cgroup_hierarchy=1 and
> b) have a patched kernel. We would like to move closer towards
> switching to v2 hierarchy, with an eye towards using unified hierarchy
> by default, but we have a chicken and egg problem where we cannot
> encourage people to switch and test systemd with v2 hierarchy,
> since the kernel support is incomplete. And the kernel support does
> not get enough testing because it's incomplete and requires a
> substantive effort.
>
> Would it be possible to compile the rawhide kernels with the cgroup-v2-cpu
> patches [2]? This should cause no issue for v1 users, and would let the
> kernel and systemd functionality get wider testing, and hopefully nudge the
> kernel upstream towards finalizing the unified hierarchy support.

So the past 3 times we've done this, it didn't work out that way at
all.  Despite the kernel developers saying they want in-distro
testing, it hasn't actually helped the upstream merge conversation.
The utrace, Secure Boot, and kdbus code all was in Fedora for a very
long time and only portions of utrace were ever merged.  With kdbus is
wasn't a huge issue because it was self contained within a module, but
we're still carrying the Secure Boot patches today.  The cgroup-v2
patches aren't self contained and if the upstream community continues
to disagree we could be setting ourselves up for another round of
patches we're carrying that aren't upstream.

Whether or not Fedora carries these isn't my call, but I'd approach
this with caution.  If the systemd developers are looking to simply
have a kernel to test against, perhaps reviving the kernel-playground
COPR with these would be enough.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: fedora.git upstream 0-Day build testing

[Josh Boyer]

On Tue, Aug 9, 2016 at 2:32 PM, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> Hi kernel people,
>
> Recently the upstream 0-Day build testing project started building the
> exploded kernel git tree for Fedora on kernel.org:
>
> https://git.kernel.org/cgit/linux/kernel/git/jwboyer/fedora.git/
>
> That was somewhat of a surprise.  It has found a few things here and
> there, mostly in building for configurations or architectures that
> Fedora does not support.  Sometimes this causes maintainers to be
> mailed about build failures somewhat unexpectedly.  The most recent
> case as the crash driver on openrisc.
>
> The 0-Day maintainer said they can disable it, but I wanted to run it
> past the team first.  I can see value in doing it, even if it isn't
> directly applicable to Fedora itself at the moment.  Thoughts?

Follow up: Fengguang Wu points out that it can be enabled only for
specific ARCH as well.  So that's a possibility.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

fedora.git upstream 0-Day build testing

[Josh Boyer]

Hi kernel people,

Recently the upstream 0-Day build testing project started building the
exploded kernel git tree for Fedora on kernel.org:

https://git.kernel.org/cgit/linux/kernel/git/jwboyer/fedora.git/

That was somewhat of a surprise.  It has found a few things here and
there, mostly in building for configurations or architectures that
Fedora does not support.  Sometimes this causes maintainers to be
mailed about build failures somewhat unexpectedly.  The most recent
case as the crash driver on openrisc.

The 0-Day maintainer said they can disable it, but I wanted to run it
past the team first.  I can see value in doing it, even if it isn't
directly applicable to Fedora itself at the moment.  Thoughts?

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: [PATCH] Add touchscreen and pen driver for the Surface 3

[Josh Boyer]

On Fri, Jul 29, 2016 at 9:03 AM, Bastien Nocera  wrote:
> Yes, see the upstream "Input: surface3_spi - add surface pen support for 
> Surface 3" patch.
> But that's just the tip of the pen, the button at the top of it is a 
> Bluetooth device, so if you want to be more precise in the changelog entry.

OK.  Applied and pushed out.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: [PATCH] Add CrystalCove PWM support, for CherryTrail devices

[Josh Boyer]

On Thu, Jul 28, 2016 at 7:35 AM, Bastien Nocera  wrote:
> From: Bastien Nocera 
>
> ---
>  config-x86-generic | 2 +-
>  kernel.spec| 5 -
>  2 files changed, 5 insertions(+), 2 deletions(-)

Fixed up to apply and pushed.  A small comment below.

> diff --git a/config-x86-generic b/config-x86-generic
> index c9a654a..0f66965 100644
> --- a/config-x86-generic
> +++ b/config-x86-generic
> @@ -122,7 +122,7 @@ CONFIG_BXT_WC_PMIC_OPREGION=y
>  CONFIG_GPIO_CRYSTAL_COVE=y
>  CONFIG_AXP288_ADC=y
>  CONFIG_AXP288_FUEL_GAUGE=y
> -# CONFIG_PWM_CRC is not set
> +CONFIG_PWM_CRC=y
>
>
>  CONFIG_X86_INTEL_PSTATE=y
> diff --git a/kernel.spec b/kernel.spec
> index 35ac1fb..984d88f 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -42,7 +42,7 @@ Summary: The Linux kernel
>  # For non-released -rc kernels, this will be appended after the rcX and
>  # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
>  #
> -%global baserelease 1
> +%global baserelease 2
>  %global fedora_build %{baserelease}

This kind of change is fine, but mostly unnecessary since rawhide is
rebuilt every day.

>  # base_sublevel is the kernel version we're starting with and patching
> @@ -2168,6 +2168,9 @@ fi
>  #
>  #
>  %changelog
> +* Thu Jul 28 2016 Bastien Nocera  - 4.8.0-0.rc0.git1.2
> +- Add CrystalCove PWM support, for CherryTrail devices

We only add the version/release info if we're actually going to do a
build off of this specific commit.  Otherwise just omit that part.

Thanks.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: 3 patches for various skylake issues

[Josh Boyer]

On Sat, Jul 16, 2016 at 6:29 AM, Hans de Goede <hdego...@redhat.com> wrote:
> Hi,
>
> On 14-07-16 15:31, Josh Boyer wrote:
>>
>> On Thu, Jul 14, 2016 at 8:48 AM, Hans de Goede <hdego...@redhat.com>
>> wrote:
>>>
>>> Hi Kernel-team,
>>>
>>> I'm going on vacation for 2 weeks starting tomorrow, so I do
>>> not have time to do proper follow-up on these 3 patches,
>>> but IMHO it would be good to include these in the next
>>> Fedora kernel build:
>>>
>>> https://patchwork.freedesktop.org/series/9656/
>>> amdgpu fix, this fixes newer hybrid gfx systems with
>>> a discrete amd gpu from hanging after aprox. 5 - 30 min use.
>>>
>>> https://patchwork.freedesktop.org/series/9735/
>>> Prevents crashing from pipe underruns on skl (finally),
>>> along with slightly reducing how often displays flicker.
>>
>>
>> Do those two have Fedora bugs associated with them?
>
>
> The pipe underruns one is the root-cause of e.g. :
>
> 1338026 - Graphics Glitches nuc6i7kyk skylake/iris pro 580
>
> All in all a lot of people are seeing various related
> issues on skylake when using an external monitor on
> a laptop.
>
> Luyde just posted another related patch, I'll forward that
> to the Fedora kernel list.
>
> Lyude, is that one ready to get added to updates-testing
> kernels in your opinion ?
>
>
> The amd one likely also has a Fedorabug somewhere ...
> it at least has a bunch of RHEL bugs.
>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=96214
>>> This bug has 2 patches attached for 4.6.x resp. 4.7-rc#
>
>
> Self-nak on this one, upstream has come up with a different
> fix, so lets wait for the dust to settle a bit as this is
> only a WARN_ON anyways (although it may have some real
> implications too, it mostly seems harmless).

Too late.

>> I can add them today.  They likely won't land in updates-testing until
>> next week or the week after.
>
>
> If you can add the 2 patchwork ones + the one I'm about
> to forward that would be great. Note this very likely
> really is my last mail on this before going on vacation.

I added all 3 you sent originally, then _I_ went on vacation.  They're
all in 4.6.4-xxx.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: 3 patches for various skylake issues

[Josh Boyer]

On Thu, Jul 14, 2016 at 8:48 AM, Hans de Goede  wrote:
> Hi Kernel-team,
>
> I'm going on vacation for 2 weeks starting tomorrow, so I do
> not have time to do proper follow-up on these 3 patches,
> but IMHO it would be good to include these in the next
> Fedora kernel build:
>
> https://patchwork.freedesktop.org/series/9656/
> amdgpu fix, this fixes newer hybrid gfx systems with
> a discrete amd gpu from hanging after aprox. 5 - 30 min use.
>
> https://patchwork.freedesktop.org/series/9735/
> Prevents crashing from pipe underruns on skl (finally),
> along with slightly reducing how often displays flicker.

Do those two have Fedora bugs associated with them?

> https://bugs.freedesktop.org/show_bug.cgi?id=96214
> This bug has 2 patches attached for 4.6.x resp. 4.7-rc#
> fixing both that bug as well as:
>
>1340218 - [abrt] WARNING: CPU: 2 PID: 1944 at
> drivers/gpu/drm/i915/intel_uncore.c:649 __unclaimed_reg_debug+0x7b/0x90
> [i915]
>1325020 - [abrt] WARNING: CPU: 3 PID: 1648 at
> drivers/gpu/drm/i915/intel_uncore.c:599 hsw_unclaimed_reg_debug+0x6a/0x90
> [i915]()
>1342722 - [abrt] WARNING: CPU: 2 PID: 2433 at
> drivers/gpu/drm/i915/intel_uncore.c:599 hsw_unclaimed_reg_debug+0x69/0x90
> [i915]()
>1347681 - [abrt] WARNING: CPU: 2 PID: 1363 at
> drivers/gpu/drm/i915/intel_uncore.c:649 __unclaimed_reg_debug+0x7b/0x90
> [i915]
>  bko120451 - snd_hda_* crash after resuming laptop from suspend
>
> As said if these could be added to the Fedora kernel pkgs
> that would be great. If they cause issues please report
> them to Lyude (in the Cc) and if necessary revert them.

I can add them today.  They likely won't land in updates-testing until
next week or the week after.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: F25 Kernel Version

[Josh Boyer]

On Thu, Jun 30, 2016 at 8:21 AM, Christopher Covington
 wrote:
> Hi,
>
> Apologies if this is already documented somewhere, but I wasn't able to
> find it. What upstream kernel version(s) might Fedora 25 use?

We don't know yet.  It depends on the upstream kernel release schedule
and how that interacts with the F25 release schedule.

A best guess is that we'll have at least 4.8.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: Backporting skl_update_other_pipe_wm intel drm fixes to the Fedora 4.6 kernel

[Josh Boyer]

On Fri, Jun 17, 2016 at 1:54 PM, Hans de Goede  wrote:
> Hi,
>
> On 17-06-16 18:35, Peter Robinson wrote:
>>
>> On Fri, Jun 17, 2016 at 5:21 PM, Justin Forbes  wrote:
>>>
>>> This does indeed sound like a good plan, and would be much appreciated.
>>
>>
>> We'd also need to land it in 4.7 too?
>
>
> Yes, I'll take care of that too, though after doing it for 4.6.

I'll all for this.

4.6 is in the stabilization branch if you didn't notice already.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: Problem with MODULE_SIG=y

[Josh Boyer]

On Wed, Jun 15, 2016 at 11:29 AM, Jiri Pirko  wrote:
> Wed, Jun 15, 2016 at 05:22:23PM CEST, ido...@idosch.org wrote:
>>Wed, Jun 15, 2016 at 06:15:29PM IDT, labb...@redhat.com wrote:
>>>On 06/15/2016 02:55 AM, Ido Schimmel wrote:
 Hi,

 I work on a driver (drivers/net/ethernet/mellanox/mlxsw) that is made up
 of three modules: mlxsw_pci, mlxsw_core and a third module that is
 loaded by mlxsw_core according to the probed PCI device ID via
 request_module(). However, this function fails with rawhide kernels
 during boot.

 While debugging this, I found out that if I build the kernel myself with
 the exact same config, but set CONFIG_MODULE_SIG=n, then everything is
 fine. In addition, when modprobing mlxsw_pci myself all the modules are
 successfully loaded.

 Any ideas how this can be solved? Did anyone else bump into this
 problem?

 Thanks.

>>>
>>>Can you share kernel logs showing the error?
>>
>>The only error in the log is the one from the driver:
>>
>>mlxsw_pci :03:00.0: cannot register bus device
>>mlxsw_pci: probe of :03:00.0 failed with error -22
>
> Laura, note that this is because module mlxsw_spectrum failed to load in
> this function:
>
> static struct mlxsw_driver *mlxsw_core_driver_get(const char *kind)
> {
> struct mlxsw_driver *mlxsw_driver;
>
> spin_lock(_core_driver_list_lock);
> mlxsw_driver = __driver_find(kind);
> if (!mlxsw_driver) {
> spin_unlock(_core_driver_list_lock);
> request_module(MLXSW_MODULE_ALIAS_PREFIX "%s", kind);
> spin_lock(_core_driver_list_lock);
> mlxsw_driver = __driver_find(kind);
> }
> if (mlxsw_driver) {
> if (!try_module_get(mlxsw_driver->owner))
> mlxsw_driver = NULL;
> }
>
> spin_unlock(_core_driver_list_lock);
> return mlxsw_driver;
> }
>
> Here, "request_module" won't load the mlxsw_spectrum module. But this issue
> happens only during the boot time.
>
> If you try to "modprobe mlxsw_pci" by hand later on, all works fine.

Is mlxsw_pci actually in the initramfs, and is it signed in it?

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: [PATCH] fast-build.sh rpmbuild combo for faster compilation

[Josh Boyer]

On Tue, Jun 14, 2016 at 3:47 PM, Laura Abbott  wrote:
> On 06/13/2016 12:54 PM, Paul Bolle wrote:
>>
>> On vr, 2016-06-10 at 12:42 -0700, Miguel Flores Silverio wrote:
>>>
>>> +rpmbuild --target $1 --without debuginfo --without perf --without tools
>>> --rebuild $2
>>
>>
>> When I build locally I also have:
>> --with baseonly
>> --without debug
>> --without doc
>>
>> I've been using these additional flags for years. My hope is that doing
>> this speeds up building the kernel rpms. Of course I've never actually
>> measured anything so this might be cargo cult behavior on my side.
>>
>> (I also build with CONFIG_DEBUG_INFO unset, for a year or two now. See
>> https://lkml.org/lkml/2014/1/28/402 . I mainly noticed that it saves a
>> few GB of space in my rpmbuild directory, if memory serves me right.
>> Cargo cult again?)
>>
>
> Thanks for this info. CONFIG_DEBUG_INFO does save a bunch of disk space.
> It goes from ~7GB -> ~1.5GB which is much more reasonable.

To be clear, that means tools like crash, gdb, and the
kernel-debuginfo package won't work at all because the information
isn't part of the build.  If you just want to test compiling, that's
fine.  If you're actively developing something and just want a faster
build but need to debug issues, it might not be the best choice.

> I think --without debug would be a good addition to this. Miguel, can
> you send out another version of this patch with --without debug added?

Yes, that is probably a good addition.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: [PATCH] fast-build.sh rpmbuild combo for faster compilation

[Josh Boyer]

On Mon, Jun 13, 2016 at 4:34 PM, Prarit Bhargava <pra...@redhat.com> wrote:
>
>
> On 06/13/2016 03:35 PM, Laura Abbott wrote:
>> On 06/13/2016 11:41 AM, Josh Boyer wrote:
>>> On Mon, Jun 13, 2016 at 2:32 PM, Prarit Bhargava <pra...@redhat.com> wrote:
>>>> On 06/10/2016 03:42 PM, Miguel Flores Silverio wrote:
>>>>> Signed-off-by: Miguel Flores Silverio <floresmig...@gmail.com>
>>>>> ---
>>>>>  scripts/fast-build.sh | 13 +
>>>>>  1 file changed, 13 insertions(+)
>>>>>  create mode 100755 scripts/fast-build.sh
>>>>>
>>>>> diff --git a/scripts/fast-build.sh b/scripts/fast-build.sh
>>>>> new file mode 100755
>>>>> index 000..19eaa4d
>>>>> --- /dev/null
>>>>> +++ b/scripts/fast-build.sh
>>>>> @@ -0,0 +1,13 @@
>>>>> +#! /bin/sh
>>>>> +# Description:
>>>>> +# rpmbuild combo to build the given architecture with
>>>>> +# no debugging information, perf and tools.
>>>>> +#
>>>>> +# Sample usage:
>>>>> +# ./fast-build.sh x86_64 kernel-4.7.0-0.rc1.git1.2.fc25.src.rpm
>>>>> +
>>>>> +if [ -z "$1" ] || [ -z "$2" ]; then
>>>>> +echo "usage: $0 [ arch ] [ kernel-x.x.x.fcxx.src.rpm ] "
>>>>> +fi
>>>>> +
>>>>> +rpmbuild --target $1 --without debuginfo --without perf --without tools
>>>>> --rebuild $2
>>>>> --
>>>>
>>>> Is the --target really necessary?  Why not just do $(arch)?
>>>
>
> $(arch) should return the native target.
>
> I was assuming that the script would only be run natively ... but Laura brings
> up the important case of x86 64-bit vs 32-bit.

Fedora ships cross compilers as well.  And yes, people use them to
test build.  And yes, that's totally valid :).

>> Yes. Having a quick build shortcut reduces the burden on users building
>> their own kernel.
>
> Agreed (although I reserve the right to complain about minuscule things in
> future and have jboyer ignore those too :) :) ).

I only ignore them if they're misplaced.  If we were suggesting this
script was "THE" way to do builds then you'd have totally valid
arguments.  But that's not the case.  It's a helper, for arguably
community outreach purposes.

At any rate, it's a friendly ignore if you can conceive of it that way.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: [PATCH 2/4] Removes bumpspecfile.py

[Josh Boyer]

On Fri, Jun 10, 2016 at 3:23 PM, Miguel Flores Silverio
 wrote:
> No longer needed. Use rpmdev-bumpspec instead.

Ack.  Not too long ago rpmdev-bumpspec didn't actually parse the
kernel spec's macro handling so it wouldn't work.  That has been fixed
for a while though.

josh

>
> Signed-off-by: Miguel Flores Silverio 
> ---
>  scripts/bumpspecfile.py | 76 
> -
>  1 file changed, 76 deletions(-)
>  delete mode 100755 scripts/bumpspecfile.py
>
> diff --git a/scripts/bumpspecfile.py b/scripts/bumpspecfile.py
> deleted file mode 100755
> index bc02ab3..000
> --- a/scripts/bumpspecfile.py
> +++ /dev/null
> @@ -1,76 +0,0 @@
> -#!/usr/bin/python
> -#
> -# Uses git config options user.name and user.email, falls
> -# back to env vars $GIT_COMMITTER_NAME and $GIT_COMMITTER_EMAIL
> -#
> -import re
> -import sys
> -import time
> -import os
> -import string
> -
> -class Specfile:
> -def __init__(self,filename):
> -file=open(filename,"r")
> -self.lines=file.readlines()
> -self.vr=""
> -
> -def getNextVR(self,aspec):
> - # Get VR for changelog entry.
> -(ver,rel) = os.popen("LC_ALL=C rpm --specfile -q --qf '%%{version} 
> %%{release}\n' --define 'dist %%{nil}' %s | head -1" % 
> aspec).read().strip().split(' ')
> -   pos = 0
> -# general released kernel case, bump 1st field
> -fedora_build = rel.split('.')[pos]
> -if fedora_build == "0":
> -# this is a devel kernel, bump 2nd field
> -pos = 1
> -elif rel.split('.')[-1] != fedora_build:
> -# this is a branch, must bump 3rd field
> -pos = 2
> -fedora_build = rel.split('.')[pos]
> -if pos == 1 and len(rel.split('.')) > 4:
> -# uh... what? devel kernel in a branch? private build? just do 
> no VR in clog...
> -print "Warning: not adding any VR to changelog, couldn't tell 
> for sure which field to bump"
> -pos = -1
> -next_fedora_build = int(fedora_build) + 1
> -if pos == 0:
> -nextrel = str(next_fedora_build)
> -elif pos == 1:
> -nextrel = "0." + str(next_fedora_build)
> -elif pos == 2:
> -nextrel = rel.split('.')[0] + "." + rel.split('.')[1] + "." + 
> str(next_fedora_build)
> -if pos >= 0:
> -for s in rel.split('.')[pos + 1:]:
> -nextrel = nextrel + "." + s
> -self.vr = " "+ver+'-'+nextrel
> -
> -def addChangelogEntry(self,entry):
> -user = os.popen("git config --get user.name").read().rstrip()
> -if (user == ""):
> -user = os.environ.get("GIT_COMMITTER_NAME","Unknown")
> -email = os.popen("git config --get user.email").read().rstrip()
> -if (email == ""):
> -email = os.environ.get("GIT_COMMITTER_EMAIL","unknown")
> -if (email == "unknown"):
> -email = os.environ.get("USER","unknown")+"@fedoraproject.org"
> -changematch=re.compile(r"^%changelog")
> -date=time.strftime("%a %b %d %Y",   time.localtime(time.time()))
> -newchangelogentry="%changelog\n* "+date+" "+user+" 
> <"+email+">"+self.vr+"\n"+entry+"\n\n"
> -for i in range(len(self.lines)):
> -if(changematch.match(self.lines[i])):
> -self.lines[i]=newchangelogentry
> -break
> -
> -def writeFile(self,filename):
> -file=open(filename,"w")
> -file.writelines(self.lines)
> -file.close()
> -
> -if __name__=="__main__":
> -  aspec=(sys.argv[1])
> -  s=Specfile(aspec)
> -  entry=(sys.argv[2])
> -  s.getNextVR(aspec)
> -  s.addChangelogEntry(entry)
> -  s.writeFile(aspec)
> -
> --
> 2.7.4
> ___
> kernel mailing list
> kernel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: [PATCH] Removes allarchconfig.sh

[Josh Boyer]

On Fri, Jun 10, 2016 at 3:30 PM, Miguel Flores Silverio
 wrote:
> Functionality already implemented in kernel.spec file.

Ack.

For the history inclined, DaveJ tried to speed up 'make prep' in the
kernel spec by removing this functionality and only doing it for the
current arch.  The script was created to allow the "all arch" prep for
new config options during a merge window.  That actually worked out
poorly for a number of reasons, so we wound up adding it back into the
spec.  That leaves this script as junk.

josh
>
> Signed-off-by: Miguel Flores Silverio 
> ---
>  scripts/allarchconfig.sh | 16 
>  1 file changed, 16 deletions(-)
>  delete mode 100755 scripts/allarchconfig.sh
>
> diff --git a/scripts/allarchconfig.sh b/scripts/allarchconfig.sh
> deleted file mode 100755
> index f80c231..000
> --- a/scripts/allarchconfig.sh
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -#!/bin/sh
> -# Run from within a source tree.
> -
> -for i in configs/kernel-*.config
> -do
> -  cp -f $i .config
> -  Arch=`head -1 .config | cut -b 3-`
> -  echo $Arch \($i\)
> -  make ARCH=$Arch listnewconfig | grep -E '^CONFIG_' >.newoptions || true;
> -  if [ -s .newoptions ]; then
> -cat .newoptions;
> -exit 1;
> -  fi;
> -  rm -f .newoptions;
> -done
> -
> --
> 2.7.4
> ___
> kernel mailing list
> kernel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org