Discussion:
Services that shouldn't be started in the first place: Was F29... hide.. grub
(too old to reply)
Gerald B. Cox
2018-06-20 16:33:05 UTC
Permalink
This isn't related to a service, but is throwing out an spurious error
message. There is a patch but it hasn't made it's way
yet into the Fedora kernel:

rt_cmos registration error: rhbz#1568276
Basically an error is being thrown because your system doesn't have battery
backup. To their credit, it was quickly identified
and patched. We now just have to wait for the patch to be applied.

However these:

The mcelog.service message is associated with rhbz#1166978
The dbxtool.service message is associated with rhbz#1508808
The rngd.service message is associated with rhbz#1490632

At least for me are the result of services being enabled by default, that
should never have been enabled for my
environment.

mcelog: I am using an AMD processor. This service only applies to Intel.
dbxtool: I am not using SecureBoot. This service only applies to machines
using SecureBoot.
rngd: I am not using a machine that has a hardware RNG generator

Again, if we are apparently so concerned about a streamlined user
experience, why are we
starting processes that aren't needed - and in fact are not appropriate for
a particular environment,
and then throwing out error messages which are spurious and confusing?

In my case, this caused me to spend hours individually tracking down all
these error messages
to find out that there is nothing wrong with my environment. Instead the
issue is these services
are inappropriately started for EVERYBODY - and in one case have been
languishing for years.

Last time I checked, Fedora wasn't an Intel only, SecureBoot only,
mandatory hardware RNG generator
environment.

If we truly are concerned about end user experience - this isn't the way to
go about it.
Here is another bug that was opened in 2014 and closed "WONTFIX because it
was directly tied to F24. Here we are with F28
and it still exists: https://bugzilla.redhat.com/show_bug.cgi?id=1166978
Again, if we're concerned about the cleaning up of the boot process, why
are we apparently ignoring bugs that are associated
with processes that fail and throw out spurious messages?
If I issue: systemctl status, it tells me my system is "degraded" because
systemctl list-units --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● dbxtool.service loaded failed failed Secure Boot DBX (blacklist)
updater
● mcelog.service loaded failed failed Machine Check Exception Logging
Daemon
● rngd.service loaded failed failed Hardware RNG Entropy Gatherer Daemon
The mcelog.service message is associated with rhbz#1166978
The dbxtool.service message is associated with rhbz#1508808
The rngd.service message is associated with rhbz#1490632
Hi,
= Proposed System Wide Change: Hide the grub menu =
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
I've updated this bug: https://bugzilla.redhat.com/sh
ow_bug.cgi?id=1406844
Basically, since at least F24 - maybe longer my boot has been interrupted
====> sp5100-tco sp5100-tco: I/O address 0x0cd6 already in use
The bug was closed, and then cloned and reopened.
As I mentioned before, I have no problem with the grub change as long as
there is documentation
that shows people how to reverse it if they wish - and Hans (thank you
very much) has agreed to this.
However, seems to me that having this bug (which appears to affect all
AMD users) languishing
for years seems to negate the reasoning behind this change. If we're
wanting to implement
a more or less cosmetic change which saves a few seconds, having spurious
messages
interrupting and slowing down the boot process should also be resolved.
Stephen Gallagher
2018-06-20 17:15:25 UTC
Permalink
Post by Gerald B. Cox
This isn't related to a service, but is throwing out an spurious error
message. There is a patch but it hasn't made it's way
rt_cmos registration error: rhbz#1568276
Basically an error is being thrown because your system doesn't have
battery backup. To their credit, it was quickly identified
and patched. We now just have to wait for the patch to be applied.
The mcelog.service message is associated with rhbz#1166978
The dbxtool.service message is associated with rhbz#1508808
The rngd.service message is associated with rhbz#1490632
At least for me are the result of services being enabled by default, that
should never have been enabled for my
environment.
mcelog: I am using an AMD processor. This service only applies to Intel.
dbxtool: I am not using SecureBoot. This service only applies to
machines using SecureBoot.
rngd: I am not using a machine that has a hardware RNG generator
Again, if we are apparently so concerned about a streamlined user
experience, why are we
starting processes that aren't needed - and in fact are not appropriate
for a particular environment,
and then throwing out error messages which are spurious and confusing?
In my case, this caused me to spend hours individually tracking down all
these error messages
to find out that there is nothing wrong with my environment. Instead the
issue is these services
are inappropriately started for EVERYBODY - and in one case have been
languishing for years.
Last time I checked, Fedora wasn't an Intel only, SecureBoot only,
mandatory hardware RNG generator
environment.
If we truly are concerned about end user experience - this isn't the way
to go about it.
The proper behavior here would be for these services not to be marked as
"failed" when the appropriate hardware is not present. When possible, we
should be using systemd's Condition* features to skip attempting to start
it at all, but for things where we can't know it ahead of time, we should
modify the start script to look for appropriate error codes/messages and
treat the service as "success" if it's skipped because it's not supported
on the current hardware.

This would be the ideal situation, because it means that if the situation
changes (e.g. mcelog gains AMD support in an update, someone plugs in an
hardware RNG device, etc.), the service will start working without
additional intervention.
Gerald B. Cox
2018-06-20 17:52:53 UTC
Permalink
Post by Stephen Gallagher
Post by Gerald B. Cox
This isn't related to a service, but is throwing out an spurious error
message. There is a patch but it hasn't made it's way
rt_cmos registration error: rhbz#1568276
Basically an error is being thrown because your system doesn't have
battery backup. To their credit, it was quickly identified
and patched. We now just have to wait for the patch to be applied.
The mcelog.service message is associated with rhbz#1166978
The dbxtool.service message is associated with rhbz#1508808
The rngd.service message is associated with rhbz#1490632
At least for me are the result of services being enabled by default, that
should never have been enabled for my
environment.
mcelog: I am using an AMD processor. This service only applies to Intel.
dbxtool: I am not using SecureBoot. This service only applies to
machines using SecureBoot.
rngd: I am not using a machine that has a hardware RNG generator
The proper behavior here would be for these services not to be marked as
"failed" when the appropriate hardware is not present. When possible, we
should be using systemd's Condition* features to skip attempting to start
it at all, but for things where we can't know it ahead of time, we should
modify the start script to look for appropriate error codes/messages and
treat the service as "success" if it's skipped because it's not supported
on the current hardware.
This would be the ideal situation, because it means that if the situation
changes (e.g. mcelog gains AMD support in an update, someone plugs in an
hardware RNG device, etc.), the service will start working without
additional intervention.
Agreed - there are commands which provide this information... for CPU
(Intel or AMD) and for querying whether or not one is using SecureBoot.
Can we please get the people who are responsible for the creation of these
services to fix them? The issue regarding battery backup (rhbz#1568276)
already has a patch created - we are just waiting for to be incorporated
into the kernel. We always seem to be chasing the next shiny object, but
ignore things that have been broken for years.
Lennart Poettering
2018-06-20 19:35:34 UTC
Permalink
Post by Stephen Gallagher
The proper behavior here would be for these services not to be marked as
"failed" when the appropriate hardware is not present. When possible, we
should be using systemd's Condition* features to skip attempting to start
it at all, …
Just to mention this: triggered by this mail I posted this PR:

https://github.com/systemd/systemd/pull/9360

This adds ConditionSecurity=uefi-secureboot, which could be nice and
accurate way to condition out that secureboot service.

That said, it'll probably be a while before that propagates into
fedora.

Lennart

--
Lennart Poettering, Red Hat
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/
Gerald B. Cox
2018-06-20 21:57:55 UTC
Permalink
Post by Lennart Poettering
Post by Stephen Gallagher
The proper behavior here would be for these services not to be marked as
"failed" when the appropriate hardware is not present. When possible, we
should be using systemd's Condition* features to skip attempting to start
it at all, 

https://github.com/systemd/systemd/pull/9360
This adds ConditionSecurity=uefi-secureboot, which could be nice and
accurate way to condition out that secureboot service.
That said, it'll probably be a while before that propagates into
fedora.
Lennart
Thanks...

For mcelog and rngd if you don't want to rely on the fact the the cpu is
AMD:

mcelog has an option --is-cpu-supported
and
rngd has an option --list

Either way, it's absolutely doable. No reason to burden users with
misleading, unneeded
error messages.
Adam Williamson
2018-06-20 22:26:03 UTC
Permalink
Post by Stephen Gallagher
Post by Gerald B. Cox
This isn't related to a service, but is throwing out an spurious error
message. There is a patch but it hasn't made it's way
rt_cmos registration error: rhbz#1568276
Basically an error is being thrown because your system doesn't have
battery backup. To their credit, it was quickly identified
and patched. We now just have to wait for the patch to be applied.
The mcelog.service message is associated with rhbz#1166978
The dbxtool.service message is associated with rhbz#1508808
The rngd.service message is associated with rhbz#1490632
At least for me are the result of services being enabled by default, that
should never have been enabled for my
environment.
mcelog: I am using an AMD processor. This service only applies to Intel.
dbxtool: I am not using SecureBoot. This service only applies to
machines using SecureBoot.
rngd: I am not using a machine that has a hardware RNG generator
Again, if we are apparently so concerned about a streamlined user
experience, why are we
starting processes that aren't needed - and in fact are not appropriate
for a particular environment,
and then throwing out error messages which are spurious and confusing?
In my case, this caused me to spend hours individually tracking down all
these error messages
to find out that there is nothing wrong with my environment. Instead the
issue is these services
are inappropriately started for EVERYBODY - and in one case have been
languishing for years.
Last time I checked, Fedora wasn't an Intel only, SecureBoot only,
mandatory hardware RNG generator
environment.
If we truly are concerned about end user experience - this isn't the way
to go about it.
The proper behavior here would be for these services not to be marked as
"failed" when the appropriate hardware is not present. When possible, we
should be using systemd's Condition* features to skip attempting to start
it at all, but for things where we can't know it ahead of time, we should
modify the start script to look for appropriate error codes/messages and
treat the service as "success" if it's skipped because it's not supported
on the current hardware.
Well, for rngd, the maintainer actually argued that he does *not* think
this is the "proper" behaviour. See
https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c11 . I don't agree
with him (as you can, er, tell from the subsequent discussion), but it
seemed worth noting it's not a universally agreed truth.

(I don't *think* he'd object to a Condition-type fix, though, if we
could come up with a reliable one).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/messa
Gerald B. Cox
2018-06-21 00:53:01 UTC
Permalink
Post by Adam Williamson
Post by Stephen Gallagher
The proper behavior here would be for these services not to be marked as
"failed" when the appropriate hardware is not present. When possible, we
should be using systemd's Condition* features to skip attempting to start
it at all, but for things where we can't know it ahead of time, we should
modify the start script to look for appropriate error codes/messages and
treat the service as "success" if it's skipped because it's not supported
on the current hardware.
Well, for rngd, the maintainer actually argued that he does *not* think
this is the "proper" behaviour. See
https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c11 . I don't agree
with him (as you can, er, tell from the subsequent discussion), but it
seemed worth noting it's not a universally agreed truth.
(I don't *think* he'd object to a Condition-type fix, though, if we
could come up with a reliable one).
I believe we're missing something fundamental here. If a program/service
etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is not
present - it shouldn't be a default.

The way to handle this (and other similar situations) is to take away the
default status until it can handle
situations where the hardware doesn't exist. This is systems programming
101 - and frankly I am a
bit surprised it's a matter of debate.
Samuel Sieb
2018-06-21 06:15:48 UTC
Permalink
I believe we're missing something fundamental here.  If a
program/service etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is not
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take away
the default status until it can handle
situations where the hardware doesn't exist.  This is systems
programming 101 - and frankly I am a
bit surprised it's a matter of debate.
There is a similar situation with other services, in particular the VM
support services. They are turned on by default, they would fail if not
running on the specific VM, but they are set to be conditional on being
run in that VM. I don't see how that is different than this case.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/message/PPZ6HHO
Gerald B. Cox
2018-06-21 06:21:20 UTC
Permalink
Post by Samuel Sieb
Post by Adam Williamson
I believe we're missing something fundamental here. If a program/service
etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is not
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take away the
default status until it can handle
situations where the hardware doesn't exist. This is systems programming
101 - and frankly I am a
bit surprised it's a matter of debate.
There is a similar situation with other services, in particular the VM
support services. They are turned on by default, they would fail if not
running on the specific VM, but they are set to be conditional on being run
in that VM. I don't see how that is different than this case.
_______________________________________________
I provided three examples, that caused systemd to report it was running in
degraded mode. Would you care to provide a sample and the associated
system error?
Stephen Gallagher
2018-06-21 13:39:03 UTC
Permalink
On Wed, Jun 20, 2018 at 3:26 PM, Adam Williamson <
Post by Gerald B. Cox
Post by Stephen Gallagher
The proper behavior here would be for these services not to be marked as
"failed" when the appropriate hardware is not present. When possible, we
should be using systemd's Condition* features to skip attempting to
start
Post by Stephen Gallagher
it at all, but for things where we can't know it ahead of time, we
should
Post by Stephen Gallagher
modify the start script to look for appropriate error codes/messages and
treat the service as "success" if it's skipped because it's not
supported
Post by Stephen Gallagher
on the current hardware.
Well, for rngd, the maintainer actually argued that he does *not* think
this is the "proper" behaviour. See
https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c11 . I don't agree
with him (as you can, er, tell from the subsequent discussion), but it
seemed worth noting it's not a universally agreed truth.
(I don't *think* he'd object to a Condition-type fix, though, if we
could come up with a reliable one).
I believe we're missing something fundamental here. If a program/service
etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is not
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take away the
default status until it can handle
situations where the hardware doesn't exist. This is systems programming
101 - and frankly I am a
bit surprised it's a matter of debate.
No one on this list is disagreeing that the defaults should not degrade the
system. I *do* think that your response is an overreaction: just because
software may have bugs on your hardware doesn't mean that it should be
turned off entirely. If it's causing problems for a small subset of users,
they can be manually disabled.

These services provide CONSIDERABLE benefit on the hardware that supports
it. Removing that as a default for those systems would be a significant
regression. That's not an acceptable solution.

Most of the people on this thread seem to agree: we can conditionalize the
defaults so it is either skipped or at least does not mark the service as
"failed" if the necessary hardware is not present. People are already
working on doing this.
Gerald B. Cox
2018-06-21 16:02:43 UTC
Permalink
Post by Stephen Gallagher
Post by Adam Williamson
I believe we're missing something fundamental here. If a program/service
etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is not
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take away the
default status until it can handle
situations where the hardware doesn't exist. This is systems programming
101 - and frankly I am a
bit surprised it's a matter of debate.
No one on this list is disagreeing that the defaults should not degrade
the system. I *do* think that your response is an overreaction: just
because software may have bugs on your hardware doesn't mean that it should
be turned off entirely. If it's causing problems for a small subset of
users, they can be manually disabled.
These services provide CONSIDERABLE benefit on the hardware that supports
it. Removing that as a default for those systems would be a significant
regression. That's not an acceptable solution.
Most of the people on this thread seem to agree: we can conditionalize the
defaults so it is either skipped or at least does not mark the service as
"failed" if the necessary hardware is not present. People are already
working on doing this.
Stephen, I'm not disputing the benefit - and I very much appreciate the
fact that people are working to conditionalize the defaults. What I do
disagree with is your characterization that this is a bug.
It is working as it was designed - and the design is faulty - and it's
pervasive. I've encountered THREE different processes that aren't properly
conditionalized. That's definitely not a bug - that's a systemic issue.
Yes, AMD processors are not as popular as Intel, but they do exist in
considerable numbers and most definitely should be
considered when things are implemented as defaults; additionally...
obviously... not everybody uses SecureBoot.
My comment regarding taking away default status was in regards to this
lingering for years.
I personally don't believe that is acceptable. If one can't figure out how
to fix things like this in a timely manner, then there is a problem.
Stephen Gallagher
2018-06-21 16:08:25 UTC
Permalink
Post by Gerald B. Cox
Post by Stephen Gallagher
Post by Adam Williamson
I believe we're missing something fundamental here. If a
program/service etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is not
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take away
the default status until it can handle
situations where the hardware doesn't exist. This is systems
programming 101 - and frankly I am a
bit surprised it's a matter of debate.
No one on this list is disagreeing that the defaults should not degrade
the system. I *do* think that your response is an overreaction: just
because software may have bugs on your hardware doesn't mean that it should
be turned off entirely. If it's causing problems for a small subset of
users, they can be manually disabled.
These services provide CONSIDERABLE benefit on the hardware that supports
it. Removing that as a default for those systems would be a significant
regression. That's not an acceptable solution.
Most of the people on this thread seem to agree: we can conditionalize
the defaults so it is either skipped or at least does not mark the service
as "failed" if the necessary hardware is not present. People are already
working on doing this.
Stephen, I'm not disputing the benefit - and I very much appreciate the
fact that people are working to conditionalize the defaults. What I do
disagree with is your characterization that this is a bug.
It is working as it was designed - and the design is faulty - and it's
pervasive. I've encountered THREE different processes that aren't properly
conditionalized. That's definitely not a bug - that's a systemic issue.
Yes, AMD processors are not as popular as Intel, but they do exist in
considerable numbers and most definitely should be
considered when things are implemented as defaults; additionally...
obviously... not everybody uses SecureBoot.
My comment regarding taking away default status was in regards to this
lingering for years.
I personally don't believe that is acceptable. If one can't figure out
how to fix things like this in a timely manner, then there is a problem.
Well, there was also a failure of escalation path here. If this was going
on for years without a resolution, why wasn't it raised on this list or to
FESCo a long time ago? Individual maintainers have their own priorities and
time constraints and don't always address every bug that comes their way.

However, had it risen up the chain, it's possible a group like FESCo might
take note and set down some rules/requirements. As it is, I think it's
probably time right now to move this to a FESCo ticket and see what we can
do about it. Gerald, if you feel strongly about this issue, please file it.
Gerald B. Cox
2018-06-21 16:24:08 UTC
Permalink
Stephen,

Yes, unfortunately, it appears that is needed. I'll create a ticket.

Thanks Stephen.
Post by Stephen Gallagher
Post by Gerald B. Cox
Post by Stephen Gallagher
Post by Adam Williamson
I believe we're missing something fundamental here. If a
program/service etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is not
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take away
the default status until it can handle
situations where the hardware doesn't exist. This is systems
programming 101 - and frankly I am a
bit surprised it's a matter of debate.
No one on this list is disagreeing that the defaults should not degrade
the system. I *do* think that your response is an overreaction: just
because software may have bugs on your hardware doesn't mean that it should
be turned off entirely. If it's causing problems for a small subset of
users, they can be manually disabled.
These services provide CONSIDERABLE benefit on the hardware that
supports it. Removing that as a default for those systems would be a
significant regression. That's not an acceptable solution.
Most of the people on this thread seem to agree: we can conditionalize
the defaults so it is either skipped or at least does not mark the service
as "failed" if the necessary hardware is not present. People are already
working on doing this.
Stephen, I'm not disputing the benefit - and I very much appreciate the
fact that people are working to conditionalize the defaults. What I do
disagree with is your characterization that this is a bug.
It is working as it was designed - and the design is faulty - and it's
pervasive. I've encountered THREE different processes that aren't properly
conditionalized. That's definitely not a bug - that's a systemic issue.
Yes, AMD processors are not as popular as Intel, but they do exist in
considerable numbers and most definitely should be
considered when things are implemented as defaults; additionally...
obviously... not everybody uses SecureBoot.
My comment regarding taking away default status was in regards to this
lingering for years.
I personally don't believe that is acceptable. If one can't figure out
how to fix things like this in a timely manner, then there is a problem.
Well, there was also a failure of escalation path here. If this was going
on for years without a resolution, why wasn't it raised on this list or to
FESCo a long time ago? Individual maintainers have their own priorities and
time constraints and don't always address every bug that comes their way.
However, had it risen up the chain, it's possible a group like FESCo might
take note and set down some rules/requirements. As it is, I think it's
probably time right now to move this to a FESCo ticket and see what we can
do about it. Gerald, if you feel strongly about this issue, please file it.
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
fedoraproject.org/message/YJOUFL2QBIQHZL5I52TLPZIA4VJLM6YK/
Adam Williamson
2018-06-21 16:38:43 UTC
Permalink
Post by Stephen Gallagher
Post by Gerald B. Cox
Post by Stephen Gallagher
Post by Adam Williamson
I believe we're missing something fundamental here. If a
program/service etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is not
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take away
the default status until it can handle
situations where the hardware doesn't exist. This is systems
programming 101 - and frankly I am a
bit surprised it's a matter of debate.
No one on this list is disagreeing that the defaults should not degrade
the system. I *do* think that your response is an overreaction: just
because software may have bugs on your hardware doesn't mean that it should
be turned off entirely. If it's causing problems for a small subset of
users, they can be manually disabled.
These services provide CONSIDERABLE benefit on the hardware that supports
it. Removing that as a default for those systems would be a significant
regression. That's not an acceptable solution.
Most of the people on this thread seem to agree: we can conditionalize
the defaults so it is either skipped or at least does not mark the service
as "failed" if the necessary hardware is not present. People are already
working on doing this.
Stephen, I'm not disputing the benefit - and I very much appreciate the
fact that people are working to conditionalize the defaults. What I do
disagree with is your characterization that this is a bug.
It is working as it was designed - and the design is faulty - and it's
pervasive. I've encountered THREE different processes that aren't properly
conditionalized. That's definitely not a bug - that's a systemic issue.
Yes, AMD processors are not as popular as Intel, but they do exist in
considerable numbers and most definitely should be
considered when things are implemented as defaults; additionally...
obviously... not everybody uses SecureBoot.
My comment regarding taking away default status was in regards to this
lingering for years.
I personally don't believe that is acceptable. If one can't figure out
how to fix things like this in a timely manner, then there is a problem.
Well, there was also a failure of escalation path here. If this was going
on for years without a resolution, why wasn't it raised on this list or to
FESCo a long time ago? Individual maintainers have their own priorities and
time constraints and don't always address every bug that comes their way.
However, had it risen up the chain, it's possible a group like FESCo might
take note and set down some rules/requirements. As it is, I think it's
probably time right now to move this to a FESCo ticket and see what we can
do about it. Gerald, if you feel strongly about this issue, please file it.
Note we already have a release criterion related to this:

"All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present."

That lets out the rngd and Intel vs. AMD cases, I guess - it is
specifically written to do so, after we decided once that we didn't
want to block the release on the rngd case or one like it - but it
would cover the Secure Boot case at least.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/message/PCKI2JZ54TWHRMFTQ
Gerald B. Cox
2018-06-21 16:46:09 UTC
Permalink
Interesting... thanks Adam... but the way I read that is specifically
tailored to "release criteria", not
design/implementation guidelines - i.e. to me this says, don't hold up a
release because someone
screwed up and didn't conditionalize the process correctly.
Post by Stephen Gallagher
On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher <
Post by Stephen Gallagher
Post by Adam Williamson
I believe we're missing something fundamental here. If a
program/service etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is
not
Post by Stephen Gallagher
Post by Stephen Gallagher
Post by Adam Williamson
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take
away
Post by Stephen Gallagher
Post by Stephen Gallagher
Post by Adam Williamson
the default status until it can handle
situations where the hardware doesn't exist. This is systems
programming 101 - and frankly I am a
bit surprised it's a matter of debate.
No one on this list is disagreeing that the defaults should not
degrade
Post by Stephen Gallagher
Post by Stephen Gallagher
the system. I *do* think that your response is an overreaction: just
because software may have bugs on your hardware doesn't mean that it
should
Post by Stephen Gallagher
Post by Stephen Gallagher
be turned off entirely. If it's causing problems for a small subset
of
Post by Stephen Gallagher
Post by Stephen Gallagher
users, they can be manually disabled.
These services provide CONSIDERABLE benefit on the hardware that
supports
Post by Stephen Gallagher
Post by Stephen Gallagher
it. Removing that as a default for those systems would be a
significant
Post by Stephen Gallagher
Post by Stephen Gallagher
regression. That's not an acceptable solution.
Most of the people on this thread seem to agree: we can
conditionalize
Post by Stephen Gallagher
Post by Stephen Gallagher
the defaults so it is either skipped or at least does not mark the
service
Post by Stephen Gallagher
Post by Stephen Gallagher
as "failed" if the necessary hardware is not present. People are
already
Post by Stephen Gallagher
Post by Stephen Gallagher
working on doing this.
Stephen, I'm not disputing the benefit - and I very much appreciate the
fact that people are working to conditionalize the defaults. What I do
disagree with is your characterization that this is a bug.
It is working as it was designed - and the design is faulty - and it's
pervasive. I've encountered THREE different processes that aren't
properly
Post by Stephen Gallagher
conditionalized. That's definitely not a bug - that's a systemic
issue.
Post by Stephen Gallagher
Yes, AMD processors are not as popular as Intel, but they do exist in
considerable numbers and most definitely should be
considered when things are implemented as defaults; additionally...
obviously... not everybody uses SecureBoot.
My comment regarding taking away default status was in regards to this
lingering for years.
I personally don't believe that is acceptable. If one can't figure out
how to fix things like this in a timely manner, then there is a
problem.
Post by Stephen Gallagher
Well, there was also a failure of escalation path here. If this was going
on for years without a resolution, why wasn't it raised on this list or
to
Post by Stephen Gallagher
FESCo a long time ago? Individual maintainers have their own priorities
and
Post by Stephen Gallagher
time constraints and don't always address every bug that comes their way.
However, had it risen up the chain, it's possible a group like FESCo
might
Post by Stephen Gallagher
take note and set down some rules/requirements. As it is, I think it's
probably time right now to move this to a FESCo ticket and see what we
can
Post by Stephen Gallagher
do about it. Gerald, if you feel strongly about this issue, please file
it.
"All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present."
That lets out the rngd and Intel vs. AMD cases, I guess - it is
specifically written to do so, after we decided once that we didn't
want to block the release on the rngd case or one like it - but it
would cover the Secure Boot case at least.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
fedoraproject.org/message/PCKI2JZ54TWHRMFTQAIQP333K5W7MPUQ/
Gerald B. Cox
2018-06-21 16:56:32 UTC
Permalink
I opened the ticket, it is here: https://pagure.io/fesco/issue/1918

Thanks again Stephen for the suggestion.
Post by Gerald B. Cox
Interesting... thanks Adam... but the way I read that is specifically
tailored to "release criteria", not
design/implementation guidelines - i.e. to me this says, don't hold up a
release because someone
screwed up and didn't conditionalize the process correctly.
On Thu, Jun 21, 2018 at 9:38 AM, Adam Williamson <
Post by Stephen Gallagher
On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher <
Post by Stephen Gallagher
Post by Adam Williamson
I believe we're missing something fundamental here. If a
program/service etc. requires specific hardware to work
and it can't gracefully handle situations where that hardware is
not
Post by Stephen Gallagher
Post by Stephen Gallagher
Post by Adam Williamson
present - it shouldn't be a default.
The way to handle this (and other similar situations) is to take
away
Post by Stephen Gallagher
Post by Stephen Gallagher
Post by Adam Williamson
the default status until it can handle
situations where the hardware doesn't exist. This is systems
programming 101 - and frankly I am a
bit surprised it's a matter of debate.
No one on this list is disagreeing that the defaults should not
degrade
Post by Stephen Gallagher
Post by Stephen Gallagher
the system. I *do* think that your response is an overreaction: just
because software may have bugs on your hardware doesn't mean that
it should
Post by Stephen Gallagher
Post by Stephen Gallagher
be turned off entirely. If it's causing problems for a small subset
of
Post by Stephen Gallagher
Post by Stephen Gallagher
users, they can be manually disabled.
These services provide CONSIDERABLE benefit on the hardware that
supports
Post by Stephen Gallagher
Post by Stephen Gallagher
it. Removing that as a default for those systems would be a
significant
Post by Stephen Gallagher
Post by Stephen Gallagher
regression. That's not an acceptable solution.
Most of the people on this thread seem to agree: we can
conditionalize
Post by Stephen Gallagher
Post by Stephen Gallagher
the defaults so it is either skipped or at least does not mark the
service
Post by Stephen Gallagher
Post by Stephen Gallagher
as "failed" if the necessary hardware is not present. People are
already
Post by Stephen Gallagher
Post by Stephen Gallagher
working on doing this.
Stephen, I'm not disputing the benefit - and I very much appreciate
the
Post by Stephen Gallagher
fact that people are working to conditionalize the defaults. What I
do
Post by Stephen Gallagher
disagree with is your characterization that this is a bug.
It is working as it was designed - and the design is faulty - and it's
pervasive. I've encountered THREE different processes that aren't
properly
Post by Stephen Gallagher
conditionalized. That's definitely not a bug - that's a systemic
issue.
Post by Stephen Gallagher
Yes, AMD processors are not as popular as Intel, but they do exist in
considerable numbers and most definitely should be
considered when things are implemented as defaults; additionally...
obviously... not everybody uses SecureBoot.
My comment regarding taking away default status was in regards to this
lingering for years.
I personally don't believe that is acceptable. If one can't figure
out
Post by Stephen Gallagher
how to fix things like this in a timely manner, then there is a
problem.
Post by Stephen Gallagher
Well, there was also a failure of escalation path here. If this was
going
Post by Stephen Gallagher
on for years without a resolution, why wasn't it raised on this list or
to
Post by Stephen Gallagher
FESCo a long time ago? Individual maintainers have their own priorities
and
Post by Stephen Gallagher
time constraints and don't always address every bug that comes their
way.
Post by Stephen Gallagher
However, had it risen up the chain, it's possible a group like FESCo
might
Post by Stephen Gallagher
take note and set down some rules/requirements. As it is, I think it's
probably time right now to move this to a FESCo ticket and see what we
can
Post by Stephen Gallagher
do about it. Gerald, if you feel strongly about this issue, please file
it.
"All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present."
That lets out the rngd and Intel vs. AMD cases, I guess - it is
specifically written to do so, after we decided once that we didn't
want to block the release on the rngd case or one like it - but it
would cover the Secure Boot case at least.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
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.or
Z54TWHRMFTQAIQP333K5W7MPUQ/
Adam Williamson
2018-06-21 17:07:25 UTC
Permalink
Post by Gerald B. Cox
Interesting... thanks Adam... but the way I read that is specifically
tailored to "release criteria", not
design/implementation guidelines - i.e. to me this says, don't hold up a
release because someone
screwed up and didn't conditionalize the process correctly.
I think you're being a *bit* harsh, here, btw, constantly talking about
how people are "screwing up". Conditionalized services are kind of an
advanced systemd feature and many people probably don't know about them
at all, and as we're discussing here, we *don't* actually have any
requirement that services be conditionalized in this way. I don't think
it's really fair to see this as packagers doing something horribly
wrong and bad. (Also note that it's not at all straightforward to
conditionalize some of these things in a reliable way - it seems
Lennart had to add a new feature to systemd to aid in conditionalizing
the secure boot-related service, and I don't think it'll be
particularly straightforward to find a correct conditionalization for
the rngd case either). It's just a situation we've identified where we
could possibly improve things.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/message/C52WF
Gerald B. Cox
2018-06-21 17:18:31 UTC
Permalink
On Thu, Jun 21, 2018 at 10:07 AM, Adam Williamson <
Post by Adam Williamson
Post by Gerald B. Cox
Interesting... thanks Adam... but the way I read that is specifically
tailored to "release criteria", not
design/implementation guidelines - i.e. to me this says, don't hold up a
release because someone
screwed up and didn't conditionalize the process correctly.
I think you're being a *bit* harsh, here, btw, constantly talking about
how people are "screwing up". Conditionalized services are kind of an
advanced systemd feature and many people probably don't know about them
at all, and as we're discussing here, we *don't* actually have any
requirement that services be conditionalized in this way. I don't think
it's really fair to see this as packagers doing something horribly
wrong and bad. (Also note that it's not at all straightforward to
conditionalize some of these things in a reliable way - it seems
Lennart had to add a new feature to systemd to aid in conditionalizing
the secure boot-related service, and I don't think it'll be
particularly straightforward to find a correct conditionalization for
the rngd case either). It's just a situation we've identified where we
could possibly improve things.
First of all, I'm not "constantly talking" about how people are "screwing
up". I made that comment in one email.
Second, if you're going to maintain something, maintain it. If you don't
do something properly, or optimally... own it
and don't make excuses. Learn to accept constructive criticism instead of
parsing someone's statements
searching for reasons to feign insult for use as a deflective excuse.
Adam Williamson
2018-06-21 17:48:52 UTC
Permalink
Post by Gerald B. Cox
On Thu, Jun 21, 2018 at 10:07 AM, Adam Williamson <
Post by Adam Williamson
Post by Gerald B. Cox
Interesting... thanks Adam... but the way I read that is specifically
tailored to "release criteria", not
design/implementation guidelines - i.e. to me this says, don't hold up a
release because someone
screwed up and didn't conditionalize the process correctly.
I think you're being a *bit* harsh, here, btw, constantly talking about
how people are "screwing up". Conditionalized services are kind of an
advanced systemd feature and many people probably don't know about them
at all, and as we're discussing here, we *don't* actually have any
requirement that services be conditionalized in this way. I don't think
it's really fair to see this as packagers doing something horribly
wrong and bad. (Also note that it's not at all straightforward to
conditionalize some of these things in a reliable way - it seems
Lennart had to add a new feature to systemd to aid in conditionalizing
the secure boot-related service, and I don't think it'll be
particularly straightforward to find a correct conditionalization for
the rngd case either). It's just a situation we've identified where we
could possibly improve things.
First of all, I'm not "constantly talking" about how people are "screwing
up". I made that comment in one email.
Second, if you're going to maintain something, maintain it. If you don't
do something properly, or optimally... own it
and don't make excuses. Learn to accept constructive criticism instead of
parsing someone's statements
searching for reasons to feign insult for use as a deflective excuse.
I don't maintain any of these services, so your criticism is neither
constructive nor accurate.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/message/VKHATZU52JA2ZIMNJVXGIOVEQZAV
Gerald B. Cox
2018-06-21 17:53:43 UTC
Permalink
On Thu, Jun 21, 2018 at 10:48 AM, Adam Williamson <
Post by Adam Williamson
I don't maintain any of these services, so your criticism is neither
constructive nor accurate.
Then why are you inserting yourself into this conversation and looking for
ways to be offended?
It's not about you. Relax.
Lennart Poettering
2018-06-21 17:27:54 UTC
Permalink
Post by Adam Williamson
Post by Gerald B. Cox
Interesting... thanks Adam... but the way I read that is specifically
tailored to "release criteria", not
design/implementation guidelines - i.e. to me this says, don't hold up a
release because someone
screwed up and didn't conditionalize the process correctly.
I think you're being a *bit* harsh, here, btw, constantly talking about
how people are "screwing up". Conditionalized services are kind of an
advanced systemd feature and many people probably don't know about them
at all, and as we're discussing here, we *don't* actually have any
requirement that services be conditionalized in this way. I don't think
it's really fair to see this as packagers doing something horribly
wrong and bad. (Also note that it's not at all straightforward to
conditionalize some of these things in a reliable way - it seems
Lennart had to add a new feature to systemd to aid in conditionalizing
the secure boot-related service, and I don't think it'll be
particularly straightforward to find a correct conditionalization for
the rngd case either). It's just a situation we've identified where we
could possibly improve things.
Just out of curiosity: when precisely is rngd supposed to be used? As
soon as there's a hardware RNG device /dev/hwrng? That should be
easy enough: ConditionFileExists=/dev/hwrng... Or are there other
cases when this is supposed to be start?

(Also, why is there a userspace component for this stuff in the first
place? I mean streaming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)

Lennart

--
Lennart Poettering, Red Hat
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproj
Adam Williamson
2018-06-21 17:50:10 UTC
Permalink
Post by Lennart Poettering
Post by Adam Williamson
Post by Gerald B. Cox
Interesting... thanks Adam... but the way I read that is specifically
tailored to "release criteria", not
design/implementation guidelines - i.e. to me this says, don't hold up a
release because someone
screwed up and didn't conditionalize the process correctly.
I think you're being a *bit* harsh, here, btw, constantly talking about
how people are "screwing up". Conditionalized services are kind of an
advanced systemd feature and many people probably don't know about them
at all, and as we're discussing here, we *don't* actually have any
requirement that services be conditionalized in this way. I don't think
it's really fair to see this as packagers doing something horribly
wrong and bad. (Also note that it's not at all straightforward to
conditionalize some of these things in a reliable way - it seems
Lennart had to add a new feature to systemd to aid in conditionalizing
the secure boot-related service, and I don't think it'll be
particularly straightforward to find a correct conditionalization for
the rngd case either). It's just a situation we've identified where we
could possibly improve things.
Just out of curiosity: when precisely is rngd supposed to be used? As
soon as there's a hardware RNG device /dev/hwrng? That should be
easy enough: ConditionFileExists=/dev/hwrng... Or are there other
cases when this is supposed to be start?
See https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c42 .
Post by Lennart Poettering
(Also, why is there a userspace component for this stuff in the first
place? I mean streaming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)
That, I don't know, and I'd sort of wondered the same. Don't know who
can enlighten us as to the answer.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedor
stan
2018-06-21 19:40:02 UTC
Permalink
On Thu, 21 Jun 2018 10:50:10 -0700
Post by Adam Williamson
Post by Lennart Poettering
(Also, why is there a userspace component for this stuff in the
first place? I mean streaming data from one corner of the kernel to
another corner of the kernel is something probably better done
inside of the kernel instead of involving userspace at all with
this...)
That, I don't know, and I'd sort of wondered the same. Don't know who
can enlighten us as to the answer.
Some maybe irrelevant information:

There is a user accessible kernel interface that allows user
started daemons to feed entropy into the kernel entropy pool. It works
via a callback mechanism. I use it to harvest entropy from atmospheric
noise and sound card noise and feed it into the pool. I'm not sure if
that is the same thing you are talking about. What it means is that
the kernel doesn't have to know anything about the device providing the
entropy (no need for a driver).

There is also a kernel process that harvests entropy from hard disk
noise and keyboard and mouse movement. I'm not sure if it is part of
rngd or not.

It's been a while since I looked at this so the details are fuzzy for
me.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/message/NBYSYK3SQ
Adam Williamson
2018-06-21 19:51:53 UTC
Permalink
Post by stan
On Thu, 21 Jun 2018 10:50:10 -0700
Post by Adam Williamson
Post by Lennart Poettering
(Also, why is there a userspace component for this stuff in the
first place? I mean streaming data from one corner of the kernel to
another corner of the kernel is something probably better done
inside of the kernel instead of involving userspace at all with
this...)
That, I don't know, and I'd sort of wondered the same. Don't know who
can enlighten us as to the answer.
There is a user accessible kernel interface that allows user
started daemons to feed entropy into the kernel entropy pool. It works
via a callback mechanism. I use it to harvest entropy from atmospheric
noise and sound card noise and feed it into the pool. I'm not sure if
that is the same thing you are talking about. What it means is that
the kernel doesn't have to know anything about the device providing the
entropy (no need for a driver).
There is also a kernel process that harvests entropy from hard disk
noise and keyboard and mouse movement. I'm not sure if it is part of
rngd or not.
Thanks for the note, but no, none of this is relevant to the specific
problem here.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/message/RVILXUJI6U65KVT75RERFVYGVXRHUDVM/
Gerald B. Cox
2018-06-21 18:00:31 UTC
Permalink
Post by Lennart Poettering
Just out of curiosity: when precisely is rngd supposed to be used? As
soon as there's a hardware RNG device /dev/hwrng? That should be
easy enough: ConditionFileExists=/dev/hwrng... Or are there other
cases when this is supposed to be start?
(Also, why is there a userspace component for this stuff in the first
place? I mean streaming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)
https://www.certdepot.net/rhel7-get-started-random-number-generator/
https://volumeintegration.com/best-entropy-generation-software-for-linux/

My understanding from the above is that "Rngd-tools and the rngd command is
not a tool to generate entropy.
It is a program that takes randomness from a true random hardware device
and puts it into /dev/random."

So, if you don't have the hardware device, it isn't to be used. There are
usb type devices such as
OneRNG, TrueRNG, Chaoskey, NeuG that you can purchase that can provide this
functionality.

This link from Wikipedia: https://en.wikipedia.org/wiki/RdRand

says that "*RDRAND* (previously known as *Bull Mountain*[1]
<https://en.wikipedia.org/wiki/RdRand#cite_note-1>) is an instruction
<https://en.wikipedia.org/wiki/Instruction_(computer_science)> for
returning random numbers from an Intel <https://en.wikipedia.org/wiki/Intel>
on-chip hardware random number generator
<https://en.wikipedia.org/wiki/Hardware_random_number_generator> which has
been seeded by an on-chip entropy source.[2]
<https://en.wikipedia.org/wiki/RdRand#cite_note-SIG-2> RDRAND is available
in Ivy Bridge <https://en.wikipedia.org/wiki/Ivy_Bridge_(microarchitecture)>
processors[a] <https://en.wikipedia.org/wiki/RdRand#cite_note-4> and is
part of the Intel 64 <https://en.wikipedia.org/wiki/Intel_64> and IA-32
<https://en.wikipedia.org/wiki/IA-32> instruction set architectures
<https://en.wikipedia.org/wiki/Instruction_set>. AMD added support for the
instruction in June 2015."

Also apparently: "

The CPUID <https://en.wikipedia.org/wiki/CPUID> instruction can be used to
check whether the central processing unit
<https://en.wikipedia.org/wiki/Central_processing_unit> (CPU) supports the
RDRAND instruction on both AMD and Intel CPUs. If supported, bit 30 of the
ECX register is set after calling CPUID standard function 01H.[9]
<https://en.wikipedia.org/wiki/RdRand#cite_note-10> AMD processors are
checked for the feature using the same test.[10]
<https://en.wikipedia.org/wiki/RdRand#cite_note-11> RDSEED availability can
be checked on Intel CPUs in a similar manner. If RDSEED is supported, the
bit 18 of the EBX register is set after calling CPUID standard function 07H.
[11] <https://en.wikipedia.org/wiki/RdRand#cite_note-12>

The opcode for RDRAND is 0x0F 0xC7, followed by a ModRM byte that specifies
the destination register and optionally combined with a REX prefix in 64
bit mode.[12]" <https://en.wikipedia.org/wiki/RdRand#cite_note-13>


So, apparently, the CPUID instruction holds the key and should be checked
to see if the CPU supports it. In the case of the external USB devices, I
don't believe you need to worry about those. If someone purchases
them, they would know they would need to take action to get it to work.
Gerald B. Cox
2018-06-21 18:08:16 UTC
Permalink
I just installed the cpuid package. Here is a portion of the output for my
processor. As you can see: RDRAND reported "= false" which means
my processor does not suppoprt the hardware random number generator feature.

feature information (1/ecx):
PNI/SSE3: Prescott New Instructions = true
PCLMULDQ instruction = true
DTES64: 64-bit debug store = false
MONITOR/MWAIT = true
CPL-qualified debug store = false
VMX: virtual machine extensions = false
SMX: safer mode extensions = false
Enhanced Intel SpeedStep Technology = false
TM2: thermal monitor 2 = false
SSSE3 extensions = true
context ID: adaptive or shared L1 data = false
SDBG: IA32_DEBUG_INTERFACE = false
FMA instruction = true
CMPXCHG16B instruction = true
xTPR disable = false
PDCM: perfmon and debug = false
PCID: process context identifiers = false
DCA: direct cache access = false
SSE4.1 extensions = true
SSE4.2 extensions = true
x2APIC: extended xAPIC support = false
MOVBE instruction = false
POPCNT instruction = true
time stamp counter deadline = false
AES instruction = true
XSAVE/XSTOR states = true
OS-enabled XSAVE/XSTOR = true
AVX: advanced vector extensions = true
F16C half-precision convert instruction = true
RDRAND instruction = false
hypervisor guest status = false
Post by Gerald B. Cox
Post by Lennart Poettering
Just out of curiosity: when precisely is rngd supposed to be used? As
soon as there's a hardware RNG device /dev/hwrng? That should be
easy enough: ConditionFileExists=/dev/hwrng... Or are there other
cases when this is supposed to be start?
(Also, why is there a userspace component for this stuff in the first
place? I mean streaming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)
https://www.certdepot.net/rhel7-get-started-random-number-generator/
https://volumeintegration.com/best-entropy-generation-software-for-linux/
My understanding from the above is that "Rngd-tools and the rngd command
is not a tool to generate entropy.
It is a program that takes randomness from a true random hardware device
and puts it into /dev/random."
So, if you don't have the hardware device, it isn't to be used. There are
usb type devices such as
OneRNG, TrueRNG, Chaoskey, NeuG that you can purchase that can provide
this functionality.
This link from Wikipedia: https://en.wikipedia.org/wiki/RdRand
says that "*RDRAND* (previously known as *Bull Mountain*[1]
<https://en.wikipedia.org/wiki/RdRand#cite_note-1>) is an instruction
<https://en.wikipedia.org/wiki/Instruction_(computer_science)> for
returning random numbers from an Intel
<https://en.wikipedia.org/wiki/Intel> on-chip hardware random number
generator <https://en.wikipedia.org/wiki/Hardware_random_number_generator>
which has been seeded by an on-chip entropy source.[2]
<https://en.wikipedia.org/wiki/RdRand#cite_note-SIG-2> RDRAND is
available in Ivy Bridge
<https://en.wikipedia.org/wiki/Ivy_Bridge_(microarchitecture)> processors
[a] <https://en.wikipedia.org/wiki/RdRand#cite_note-4> and is part of the Intel
64 <https://en.wikipedia.org/wiki/Intel_64> and IA-32
<https://en.wikipedia.org/wiki/IA-32> instruction set architectures
<https://en.wikipedia.org/wiki/Instruction_set>. AMD added support for
the instruction in June 2015."
Also apparently: "
The CPUID <https://en.wikipedia.org/wiki/CPUID> instruction can be used
to check whether the central processing unit
<https://en.wikipedia.org/wiki/Central_processing_unit> (CPU) supports
the RDRAND instruction on both AMD and Intel CPUs. If supported, bit 30
of the ECX register is set after calling CPUID standard function 01H.[9]
<https://en.wikipedia.org/wiki/RdRand#cite_note-10> AMD processors are
checked for the feature using the same test.[10]
<https://en.wikipedia.org/wiki/RdRand#cite_note-11> RDSEED availability
can be checked on Intel CPUs in a similar manner. If RDSEED is supported,
the bit 18 of the EBX register is set after calling CPUID standard function
07H.[11] <https://en.wikipedia.org/wiki/RdRand#cite_note-12>
The opcode for RDRAND is 0x0F 0xC7, followed by a ModRM byte that
specifies the destination register and optionally combined with a REX
prefix in 64 bit mode.[12]"
<https://en.wikipedia.org/wiki/RdRand#cite_note-13>
So, apparently, the CPUID instruction holds the key and should be checked
to see if the CPU supports it. In the case of the external USB devices, I
don't believe you need to worry about those. If someone purchases
them, they would know they would need to take action to get it to work.
Kyle Marek
2018-06-21 18:24:10 UTC
Permalink
Post by Gerald B. Cox
Post by Lennart Poettering
Just out of curiosity: when precisely is rngd supposed to be used? As
soon as there's a hardware RNG device /dev/hwrng? That should be
easy enough: ConditionFileExists=/dev/hwrng... Or are there other
cases when this is supposed to be start?
(Also, why is there a userspace component for this stuff in the first
place? I mean streaming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)
https://www.certdepot.net/rhel7-get-started-random-number-generator/
https://volumeintegration.com/best-entropy-generation-software-for-linux/
My understanding from the above is that "Rngd-tools and the rngd command is
not a tool to generate entropy.
It is a program that takes randomness from a true random hardware device
and puts it into /dev/random."
So, if you don't have the hardware device, it isn't to be used. There are
usb type devices such as
OneRNG, TrueRNG, Chaoskey, NeuG that you can purchase that can provide this
functionality.
That is interesting. Out of curiosity, does rngd have any support for a
smart card as a source of random numbers?

If so, I believe that would be an example of why the userspace daemon
might be useful; smart card communication kinda has to be userspace.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/message/O5YVUTSRHYOKFGWCLQE
Hans de Goede
2018-06-20 17:24:36 UTC
Permalink
Hi,
This isn't related to a service, but is throwing out an spurious error message.  There is a patch but it hasn't made it's way
rt_cmos registration error:  rhbz#1568276
Basically an error is being thrown because your system doesn't have battery backup.  To their credit, it was quickly identified
and patched.  We now just have to wait for the patch to be applied.
The mcelog.service message is associated with rhbz#1166978
The dbxtool.service message is associated with rhbz#1508808
The rngd.service message is associated with rhbz#1490632
At least for me are the result of services being enabled by default, that should never have been enabled for my
environment.
mcelog:  I am using an AMD processor.  This service only applies to Intel.
dbxtool:  I am not using SecureBoot.  This service only applies to machines using SecureBoot.
rngd:  I am not using a machine that has a hardware RNG generator
Again, if we are apparently so concerned about a streamlined user experience, why are we
starting processes that aren't needed - and in fact are not appropriate for a particular environment,
and then throwing out error messages which are spurious and confusing?
In my case, this caused me to spend hours individually tracking down all these error messages
to find out that there is nothing wrong with my environment.  Instead the issue is these services
are inappropriately started for EVERYBODY - and in one case have been languishing for years.
Last time I checked, Fedora wasn't an Intel only, SecureBoot only, mandatory hardware RNG generator
environment.
If we truly are concerned about end user experience - this isn't the way to go about it.
Note that any service failing will change things over from the silent boot we want to
have to showing details, starting with the:

Starting foo... [FAILED]

message, so I fully agree with you. I've put looking into the 3 service
bugs you refer to above at the end of my silent boot todo list. I first
want to get al the other bits involved working, but once that is done
making sure false-positive failures like this don't break the experience
definitely is something which we should work on.

Regards,

Hans
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org/message/3LVW5ZB
Continue reading on narkive:
Loading...