Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #210923 > unrolled thread

fix for no ssh

Back to article view | Back to linux.debian.user

Contents

  fix for no ssh Gene Heskett <gheskett@shentel.net> - 2019-07-07 16:30 +0200
    Re: fix for no ssh Tixy <tixy@yxit.co.uk> - 2019-07-07 16:50 +0200
      Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-07 18:50 +0200
        Re: fix for no ssh Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-07-07 19:50 +0200
          Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 09:00 +0200
            Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 11:10 +0200
              Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 12:20 +0200
                Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 13:00 +0200
                Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 16:50 +0200
                  Re: fix for no ssh Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-08 17:40 +0200
                    Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 18:20 +0200
                      Re: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-08 18:50 +0200
                        Re: fix for no ssh Curt <curty@free.fr> - 2019-07-09 10:20 +0200
                          Re: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-10 10:20 +0200
                            Re: fix for no ssh Curt <curty@free.fr> - 2019-07-10 11:30 +0200
                              Re: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-10 13:50 +0200
                                Re: fix for no ssh Reco <recoverym4n@enotuniq.net> - 2019-07-10 14:30 +0200
                                Re: fix for no ssh Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-10 15:10 +0200
                                  Re: fix for no ssh Curt <curty@free.fr> - 2019-07-10 16:10 +0200
                                  Re: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-11 14:10 +0200
                                    Re: fix for no ssh Reco <recoverym4n@enotuniq.net> - 2019-07-11 16:20 +0200
                                      Re: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-11 17:10 +0200
                                        Re: fix for no ssh Reco <recoverym4n@enotuniq.net> - 2019-07-11 17:20 +0200
                                Re: fix for no ssh Curt <curty@free.fr> - 2019-07-10 16:00 +0200
                                  Re: fix for no ssh David Wright <deblis@lionunicorn.co.uk> - 2019-07-10 21:20 +0200
                                  Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-10 21:30 +0200
                  [OT] Trustfulness. Was: Re: fix for no ssh "Thomas Schmitt" <scdbackup@gmx.net> - 2019-07-08 18:00 +0200
                    Re: [OT] Trustfulness. Was: Re: fix for no ssh Reco <recoverym4n@enotuniq.net> - 2019-07-08 18:10 +0200
                  Re: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-08 18:10 +0200
            Re: fix for no ssh Henrique de Moraes Holschuh <hmh@debian.org> - 2019-07-09 01:30 +0200
        Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 10:50 +0200
          Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 11:00 +0200
            Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 11:20 +0200
              Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 11:30 +0200
                Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 11:50 +0200
                  Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 12:00 +0200
                    Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 12:30 +0200
                      Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 18:30 +0200
                        Re: fix for no ssh Curt <curty@free.fr> - 2019-07-08 19:50 +0200
                          Re: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-08 20:20 +0200
                            Re: fix for no ssh Gene Heskett <gheskett@shentel.net> - 2019-07-08 21:00 +0200
                              Re: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-08 22:50 +0200
                                Fwd: fix for no ssh Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-07-08 23:50 +0200
                                  Re: Fwd: fix for no ssh Andy Smith <andy@strugglers.net> - 2019-07-09 00:40 +0200
                                Re: fix for no ssh John Hasler <jhasler@newsguy.com> - 2019-07-09 01:20 +0200
                                  Re: fix for no ssh Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-07-09 01:30 +0200
                                  Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-09 09:50 +0200
                              Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 23:00 +0200
                                Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 23:00 +0200
                            Re: fix for no ssh Curt <curty@free.fr> - 2019-07-10 09:50 +0200
                              Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-10 21:40 +0200
                        Re: fix for no ssh David Wright <deblis@lionunicorn.co.uk> - 2019-07-09 01:30 +0200
                          Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-09 10:00 +0200
                            Re: fix for no ssh David Wright <deblis@lionunicorn.co.uk> - 2019-07-10 01:20 +0200
                              Re: fix for no ssh Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-10 05:40 +0200
      Re: fix for no ssh Gene Heskett <gheskett@shentel.net> - 2019-07-07 22:50 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#211225

	Hi.

On Thu, Jul 11, 2019 at 12:03:53PM +0000, Andy Smith wrote:
> Hi Greg,
> 
> On Wed, Jul 10, 2019 at 09:03:16AM -0400, Greg Wooledge wrote:
> > The primary thing that's lacking is someone who actually knows all of
> > this stuff and can explain it properly.  Everyone on this mailing list is
> > grasping at straws that are lying around in various places, of different
> > types and quality and age, and trying to assemble a house out of them.
> 
> I think the wiki article at
> https://wiki.debian.org/BoottimeEntropyStarvation really shows that
> currently there is no such consensus available, as every solution
> listed (except buying extra entropy hardware)

That one is bad too.
Hardware random generator is not used by kernel directly, it requires
userspace program (such as hwrngd).
So, even if you put it into initrd alongside with the needed kernel
modules, there's still a noticeable delay between 'kernel rng is needed'
and 'sufficient entropy is available'.

Reco

[toc] | [prev] | [next] | [standalone]

#211228

On Thu, Jul 11, 2019 at 05:12:03PM +0300, Reco wrote:
> On Thu, Jul 11, 2019 at 12:03:53PM +0000, Andy Smith wrote:
> > I think the wiki article at
> > https://wiki.debian.org/BoottimeEntropyStarvation really shows that
> > currently there is no such consensus available, as every solution
> > listed (except buying extra entropy hardware)
> 
> That one is bad too.
> Hardware random generator is not used by kernel directly, it requires
> userspace program (such as hwrngd).
> So, even if you put it into initrd alongside with the needed kernel
> modules, there's still a noticeable delay between 'kernel rng is needed'
> and 'sufficient entropy is available'.

With no modifications and RDRAND instruction disabled, a Debian
buster VM I just created gets to crng: done in 49 seconds. By adding
the userspace daemon for EntropyKey, it gets there in 10 seconds.
Allowing RDRAND it gets there in 2 seconds.

I haven't tested it with my OneRNG devices yet.

I suspect I could also make the EntropyKey daemon start sooner if I
tried.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#211230

	Hi.

On Thu, Jul 11, 2019 at 03:00:57PM +0000, Andy Smith wrote:
> On Thu, Jul 11, 2019 at 05:12:03PM +0300, Reco wrote:
> > On Thu, Jul 11, 2019 at 12:03:53PM +0000, Andy Smith wrote:
> > > I think the wiki article at
> > > https://wiki.debian.org/BoottimeEntropyStarvation really shows that
> > > currently there is no such consensus available, as every solution
> > > listed (except buying extra entropy hardware)
> > 
> > That one is bad too.
> > Hardware random generator is not used by kernel directly, it requires
> > userspace program (such as hwrngd).
> > So, even if you put it into initrd alongside with the needed kernel
> > modules, there's still a noticeable delay between 'kernel rng is needed'
> > and 'sufficient entropy is available'.
> 
> With no modifications and RDRAND instruction disabled,

RDRAND is an exception to this as kernel does use it directly if
allowed. Devices that I wrote about are exposed to userspace via
/dev/hwrng character device.

For instance, this Exynos ARM SOC comes with HWRNG, but:

[    0.000000] random: get_random_bytes called from start_kernel+0x9c/0x528 with crng_init=0
[    0.772543] random: fast init done
[    9.006398] random: lvm: uninitialized urandom read (4 bytes read)
[   10.206032] random: lvm: uninitialized urandom read (4 bytes read)
[   10.363308] random: lvm: uninitialized urandom read (4 bytes read)
[   10.439771] random: lvm: uninitialized urandom read (2 bytes read)
[   12.322888] random: lvmconfig: uninitialized urandom read (4 bytes read)
[   12.861180] random: systemd: uninitialized urandom read (16 bytes read)
[   12.878890] random: systemd: uninitialized urandom read (16 bytes read)
[   14.126267] random: crng init done
[   14.714783] exynos-trng 10830600.rng: Exynos True Random Number Generator.

Note that the kernel needs entropy from the beginning, but gets the
possibility to use HWRNG on 14th second of uptime.

Reco

[toc] | [prev] | [next] | [standalone]

#211160

On 2019-07-10, Andy Smith <andy@strugglers.net> wrote:

> Secondly, the reason I asked you what you would like done is that in
> the message I replied to you said that the release notes were
> something that users don't read. But your proposed solution is to
> put more things in the release notes.

I said users don't read the release notes? I don't remember saying that.
I remember saying we can't assume or expect the "regular user" (for any
arbitrary definition of that) is following the technical discussions of
the development team. I do think, though, all users are responsible for
reading the release notes. That's life in the big city, as Mom used to
say. 

>> Further, I would like to know whether the patch will be "baked into the
>> kernel" or whether it can be toggled on and/or off at the *user's*
>> discretion. I don't remember being clear on this point after reading the
>> notes (maybe it's there and I missed it).
>> 
>> It wasn't clear to me, either, in the release-notes, the recommended way
>> forward for those with amd64 cpus lacking the RDRAND instruction (and who
>> therefore cannot "benefit" from the patch).
>
> In the release notes in the relevant section (5.1.4) the last
> paragraph is:
>
>     See the wiki (https://wiki.debian.org/BoottimeEntropyStarvation)
>     and DLange's overview of the issue
>     (https://daniel-lange.com/archives/152-hello-buster.html) for
>     other options.

> Both those pages have a list of different solutions and both mention
> that this RDRAND thing is enabled. Neither of them say how to
> disable it but they do say:
>
>     for amd64: use a recent kernel with CONFIG_RANDOM_TRUST_CPU set
>     (less recent kernels may need random.trust_cpu=on added to the
>     commandline)
>
> which kind of makes it obvious to me that to disable it you would do
> "random.trust_cpu=off". If you don't find this obvious maybe the
> wiki page could do with editing to improve that.

So for those with a recent kernel, who have a cpu that supports the
RDRAND instruction, to unset the 'CONFIG_RANDOM_TRUST_CPU' default, they
should put 'random.trust_cpu=off' on the kernel command line? And for
those using a less recent kernel with a cpu that supports the RDRAND
instruction, it might be enough not to add "random.trust_cpu=on" to the
kernel command line?

Sorry, but I'm still unclear about this.

> So what's lacking? Is it just that the release notes and linked pages
> mention that the user trusts the CPU but do not mention why
> some feel that is a bad idea?

> Maybe you could draft an extra paragraph for the release notes that
> contains a suitable warning? Although I do think if you are going to
> use the "even the author of the patch thinks it's bad!" argument
> then you should probably check with Ted Ts'o that that's an accurate
> representation of his views on using RDRAND for boot-time entropy.

His views shouldn't be "represented" at all. I thought it would be
honest to have something brief, up front, and simple, in the notes
themselves, like:

 For amd64 systems supporting the RDRAND instruction this issue is
 avoided by the Debian kernel using this instruction by default
 (CONFIG_RANDOM_TRUST_CPU). There are security implications in regard to
 applying this default in the view of some. See the comments of Theodore
 Ts'o (author of the patch) about this config option here:

 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39a8883a2b989d1d21bd8dd99f5557f0c5e89694

Sufficiently wishy-washy, I think (*on ne se mouille pas trop*), and those
who travel to the link can interpret Ts'o's remarks via their own brains
and arrive at their own conclusions inside of same. 

> As for the recommended way forward, I'm not sure that there is an
> easy answer if RDRAND isn't an option. There are complex trade-offs
> and I think it's probably right that users in this position read the
> wiki page and work out what's best for them.
>
> I do note that for a person in your situation (real hardware [not a
> virtual machine] with no RDRAND and no TPM), every listed solution
> has at least one expert that says it is a very bad idea! I don't
> think there is consensus here yet.
>
> In your position I think I'd probably hold my nose (as it says) and
> use haveged.

What about jiggling my mouse for a while?

> Cheers,
> Andy
>


-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

[toc] | [prev] | [next] | [standalone]

#211177

On Wed 10 Jul 2019 at 13:52:55 (-0000), Curt wrote:
> On 2019-07-10, Andy Smith <andy@strugglers.net> wrote:
> 
> > Secondly, the reason I asked you what you would like done is that in
> > the message I replied to you said that the release notes were
> > something that users don't read. But your proposed solution is to
> > put more things in the release notes.
> 
> I said users don't read the release notes? I don't remember saying that.
> I remember saying we can't assume or expect the "regular user" (for any
> arbitrary definition of that) is following the technical discussions of
> the development team. I do think, though, all users are responsible for
> reading the release notes. That's life in the big city, as Mom used to
> say. 

Perhaps it was easy to misread what you posted; would it be clearer to
rephrase it as "I think these reserves are relevant and pertinent to
the patch itself, and should be revealed in the Buster release-notes
for users who aren't following the technical discussions of the
development team".

But I also think you could withdraw your accusation of dishonesty on
the part of Debian, seeing that you (and others) aren't able to
express clearly what the problem is, what compromises have been made
in Debian's default method, and what the risks are with each of the
"solutions" proposed here and elsewhere.

> > As for the recommended way forward, I'm not sure that there is an
> > easy answer if RDRAND isn't an option. There are complex trade-offs
> > and I think it's probably right that users in this position read the
> > wiki page and work out what's best for them.
> >
> > I do note that for a person in your situation (real hardware [not a
> > virtual machine] with no RDRAND and no TPM), every listed solution
> > has at least one expert that says it is a very bad idea! I don't
> > think there is consensus here yet.
> >
> > In your position I think I'd probably hold my nose (as it says) and
> > use haveged.
> 
> What about jiggling my mouse for a while?

I've seen this, and random typing, being advised as a solution. But
it's always struck me that the best source of randomness (usually)
available nowadays is a microphone.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#211178

[Multipart message — attachments visible in raw view] — view raw

On Mi, 10 iul 19, 13:52:55, Curt wrote:
> 
> His views shouldn't be "represented" at all. I thought it would be
> honest to have something brief, up front, and simple, in the notes
> themselves, like:
> 
>  For amd64 systems supporting the RDRAND instruction this issue is
>  avoided by the Debian kernel using this instruction by default
>  (CONFIG_RANDOM_TRUST_CPU). There are security implications in regard to
>  applying this default in the view of some. See the comments of Theodore
>  Ts'o (author of the patch) about this config option here:
> 
>  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39a8883a2b989d1d21bd8dd99f5557f0c5e89694

How about:

$ reportbug release-notes

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#211006 — [OT] Trustfulness. Was: Re: fix for no ssh

Hi,

Curt quoted:
>  This will prevent getrandom(2) from blocking, if there is a
>  willingness to trust the CPU manufacturer.
>  Signed-off-by: Theodore Ts'o <tytso@mit.edu>

Apropos trusting strange allies:

  # mount debian-10.0.0-amd64-netinst.iso /mnt/iso
  mount: /dev/loop0 is write-protected, mounting read-only
  # mount /mnt/iso/boot/grub/efi.img /mnt/fat
  # strings /mnt/fat/efi/boot/bootx64.efi | fgrep Microsoft | wc -l
  43

It is futile to change the table cloth before the pig is out of the soup
  http://iartprints.com/uploadpic/michael_sowa/big/pig_in_soup.jpg


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#211008 — Re: [OT] Trustfulness. Was: Re: fix for no ssh

	Hi.

On Mon, Jul 08, 2019 at 05:57:49PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Curt quoted:
> >  This will prevent getrandom(2) from blocking, if there is a
> >  willingness to trust the CPU manufacturer.
> >  Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> 
> Apropos trusting strange allies:
> 
>   # mount debian-10.0.0-amd64-netinst.iso /mnt/iso
>   mount: /dev/loop0 is write-protected, mounting read-only
>   # mount /mnt/iso/boot/grub/efi.img /mnt/fat
>   # strings /mnt/fat/efi/boot/bootx64.efi | fgrep Microsoft | wc -l
>   43
> 
> It is futile to change the table cloth before the pig is out of the soup
>   http://iartprints.com/uploadpic/michael_sowa/big/pig_in_soup.jpg

rgrep Microsoft /lib/modules

Even if you're not using UEFI, they are still there :)

Reco

[toc] | [prev] | [next] | [standalone]

#211011

Hello,

On Mon, Jul 08, 2019 at 02:40:16PM -0000, Curt wrote:
> But as an innate altruist (just kidding), I'm wondering whether the
> regular user is aware of the implications of all this. What about people
> in Nation States ...  Well, you get the idea.

Thing is, if you can't trust that your CPU's implementation of
RDRAND hasn't been compromised then how can you trust that any other
aspect of your CPU hasn't been compromised?

Every Intel CPU contains a whole other operating system (Minix) and
no one outside of Intel knows exactly what it does. The situation
will not be markedly better at AMD.

Personally I use RDRAND and also hardware entropy sources
(EntropyKey and OneRNG).

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Please consider the environment before reading this e-mail.
 — John Levine

[toc] | [prev] | [next] | [standalone]

#211057

On Mon, 08 Jul 2019, Andrei POPESCU wrote:
> In my understanding what sysv-init does (crediting entropy over reboots) 
> is not secure for various reasons.

Writes to /dev/urandom using dd *DOES NOT* and *NEVER HAS* credited any
entropy to the pool.

Which is what sysvinit (actually, initscripts) did, last time I checked.

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#210969

On 2019-07-07, Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> 
> It sounds a lot like this issue:
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation

 Due to systemd needing entropy during boot and the kernel treating such calls
 as blocking when available entropy is low, the system may hang for minutes to
 hours until the randomness subsystem is sufficiently initialized (random: crng
 init done). For amd64 systems supporting the RDRAND instruction this issue is
 avoided by the Debian kernel using this instruction by default
(CONFIG_RANDOM_TRUST_CPU).

For amd64 systems with the RDRAND instruction, the euphemistically termed
"issue" (hanging for minutes or hours!) is "avoided." 

That avoidance is wonderful news for me, as I happen to have an amd64 system
myself. But does it support the RDRAND instruction? How do I find out? What do
I do if it doesn't? Here the notes suffer from a maddening silence.

At any rate, I case-insensitively grepped for the RDRAND flag in /proc/cpuinfo
and came up with nada (this is a pretty old machine), if that is indeed how you
discover whether you have the instruction or not.

But now I'm uncertain whether this bug will affect me or not.

https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html

https://lists.debian.org/debian-devel/2018/12/msg00184.html

I guess I would not be affected because I'm not running an entropy-hungry
service (or any services at all), but what a PITA to have gone on this wild
goose chase to finally find that out (if true). These release-notes for Buster,
as they stand, are apparently both wrong (migration of interface names) and
misleading (if the entropy-starvation stanza had begun, "For those running
services using the  getrandom() system call..." or something, I probably
wouldn't be here cluttering the forum with my bullshit).

> Kind regards, Andrei

[toc] | [prev] | [next] | [standalone]

#210971

[Multipart message — attachments visible in raw view] — view raw

On Lu, 08 iul 19, 08:40:06, Curt wrote:
> 
> I guess I would not be affected because I'm not running an entropy-hungry
> service (or any services at all), but what a PITA to have gone on this wild
> goose chase to finally find that out (if true). These release-notes for Buster,
> as they stand, are apparently both wrong (migration of interface names) and

This was fixed before the release.

You are aware that the Release Notes are work in progress as long as the 
corresponding Debian release is still in testing, right?

> misleading (if the entropy-starvation stanza had begun, "For those running
> services using the  getrandom() system call..." or something, I probably
> wouldn't be here cluttering the forum with my bullshit).

Patches welcome.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#210978

On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
> This was fixed before the release.

What?

> You are aware that the Release Notes are work in progress as long as the
> corresponding Debian release is still in testing, right?
>

How will the mistakes be fixed if no one points them out?

>> misleading (if the entropy-starvation stanza had begun, "For those running
>> services using the  getrandom() system call..." or something, I probably
>> wouldn't be here cluttering the forum with my bullshit).

> Patches welcome.
>

I've given them. Delete the erroneous stanza concerning the migration of
inteface names, and begin the stanza concerning the critcial systemd bug
as above (rephrases welcome).


-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

[toc] | [prev] | [next] | [standalone]

#210980

[Multipart message — attachments visible in raw view] — view raw

On Lu, 08 iul 19, 09:06:33, Curt wrote:
> On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> >
> > This was fixed before the release.
> 
> What?

Is there something wrong with the current wording?
 
> > You are aware that the Release Notes are work in progress as long as the
> > corresponding Debian release is still in testing, right?
> 
> How will the mistakes be fixed if no one points them out?

Yes, please! I'm sure you know how to use reportbug ;)
 
> >> misleading (if the entropy-starvation stanza had begun, "For those running
> >> services using the  getrandom() system call..." or something, I probably
> >> wouldn't be here cluttering the forum with my bullshit).
> 
> > Patches welcome.
> >
> 
> I've given them. Delete the erroneous stanza concerning the migration of
> inteface names, and begin the stanza concerning the critcial systemd bug
> as above (rephrases welcome).

I have no idea which daemons on my system are using getramdom().

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#210981

On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
> On Lu, 08 iul 19, 09:06:33, Curt wrote:
>> On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>> >
>> > This was fixed before the release.

>> What?
>
> Is there something wrong with the current wording?

I guess, as I thought I was referring to the release-notes, which
haven't been.

>> > You are aware that the Release Notes are work in progress as long
>> > as the
>> > corresponding Debian release is still in testing, right?

>> How will the mistakes be fixed if no one points them out?

> Yes, please! I'm sure you know how to use reportbug ;)

Actually, I don't, but I could give it a try. There was some uncertainty
in a recent thread about whether "it" had been fixed or not.

>> >> misleading (if the entropy-starvation stanza had begun, "For those running
>> >> services using the  getrandom() system call..." or something, I
>> >> probably wouldn't be here cluttering the forum with my bullshit).

>> > Patches welcome.

>> I've given them. Delete the erroneous stanza concerning the migration of
>> inteface names, and begin the stanza concerning the critcial systemd bug
>> as above (rephrases welcome).
>
> I have no idea which daemons on my system are using getramdom().

You got me there. AFAIK, openssh and openssl. 

> Kind regards,
> Andrei


-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

[toc] | [prev] | [next] | [standalone]

#210984

[Multipart message — attachments visible in raw view] — view raw

On Lu, 08 iul 19, 09:44:51, Curt wrote:
> On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> >
> > On Lu, 08 iul 19, 09:06:33, Curt wrote:
> >> On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> >> >
> >> > This was fixed before the release.
> 
> >> What?
> >
> > Is there something wrong with the current wording?
> 
> I guess, as I thought I was referring to the release-notes, which
> haven't been.

English is not my first language so I'm not sure what you mean here. 
Please kindly rephrase.

If there is still some inaccuracy please do provide more details 
(preferably with references) otherwise it's impossible to fix.
 
> > Yes, please! I'm sure you know how to use reportbug ;)
> 
> Actually, I don't, but I could give it a try.

You've been using Debian long enough, I'm sure you'll work it out ;)

> There was some uncertainty in a recent thread about whether "it" had 
> been fixed or not.

With "it" being...

> > I have no idea which daemons on my system are using getramdom().
> 
> You got me there. AFAIK, openssh and openssl. 

Apparently nowadays many daemons need it, and not only for encryption 
(e.g. to generate UUIDs).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#210986

On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
>
> On Lu, 08 iul 19, 09:44:51, Curt wrote:
>> On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>> >
>> > On Lu, 08 iul 19, 09:06:33, Curt wrote:
>> >> On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>> >> >
>> >> > This was fixed before the release.

>> >> What?
>> >
>> > Is there something wrong with the current wording?

>> I guess, as I thought I was referring to the release-notes, which
>> haven't been.

> English is not my first language so I'm not sure what you mean here.
> Please kindly rephrase.

I thought you were saying that
'/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism
for defining interface names in Buster (fixed). But the release-notes
(hmm, I think they've been modified since I last looked and now state
that that file is no longer "officially" supported by udev---but may
work in some cases). So I wouldn't be filing a bug report against that
stanza any longer, as current situation seems unverifiable. 

Sorry if I'm unclear.

> If there is still some inaccuracy please do provide more details
> (preferably with references) otherwise it's impossible to fix.

>> > Yes, please! I'm sure you know how to use reportbug ;)

>> Actually, I don't, but I could give it a try.
>
> You've been using Debian long enough, I'm sure you'll work it out ;)
>
>> There was some uncertainty in a recent thread about whether "it" had
>> been fixed or not.
>
> With "it" being...

Whether '/etc/udev/rules.d/70-persistent-net.rules' was respected or not
as means of defining interface names.

>> > I have no idea which daemons on my system are using getramdom().
>
>> You got me there. AFAIK, openssh and openssl.
>
> Apparently nowadays many daemons need it, and not only for encryption
> (e.g. to generate UUIDs).

Well, at the very least people should be informed who is likely to be
affected by the bug, and for those using amd64 how to check for the RDRAND
instruction, as well as what to do about it if they don't have it
(that's what I'd like to know, at any rate).

> Kind regards,
> Andrei
> --=20
> http://wiki.debian.org/FAQsFromDebianUser
>

-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

[toc] | [prev] | [next] | [standalone]

#211013

[Multipart message — attachments visible in raw view] — view raw

On Lu, 08 iul 19, 10:19:35, Curt wrote:
> 
> I thought you were saying that
> '/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism
> for defining interface names in Buster (fixed). But the release-notes
> (hmm, I think they've been modified since I last looked and now state
> that that file is no longer "officially" supported by udev---but may
> work in some cases). So I wouldn't be filing a bug report against that
> stanza any longer, as current situation seems unverifiable. 
 
For the record, the current wording (no official support) is based on 
input from the Debian systemd maintainers. They should know what is 
supported or not ;)

As far as I know the /etc/udev/rules.d/70-persistent-net.rules method 
can fail to properly rename the interfaces in certain situations which 
can leave your system without networking.

Not nice on remote machines.

It is also my understanding that systems with only one interface (of a 
given type[1]) are pretty safe with it or net.ifnames=0, so the impact 
on regular[2] desktop/laptop users should be minimal.

[1] assuming ethernet cards are always named ethX and wireless cards are 
always named wlanX by the kernel. I might have had a wireless card that 
came up as ethX, but that was a long time ago. Still, something to be 
aware of.

[2] one ethernet interface, usually integrated in the motherboard and 
one (additional) wireless interface for the laptops. Anything more 
complicated than that might break without warning.

> Well, at the very least people should be informed who is likely to be
> affected by the bug

In my understanding a lot of daemons are affected. Would it make sense 
to (try to) list them all?

> and for those using amd64 how to check for the RDRAND
> instruction, 

I agree that checking for the RDRAND instruction would indeed be a good 
addition. Someone (tm) needs to do the research and come up with a 
patch.

As I currently don't own any amd64 systems I can only offer to support 
with the wording, process of submitting the patch, etc.

> as well as what to do about it if they don't have it (that's what I'd 
> like to know, at any rate).

haveged is mentioned in the Release Notes.

jitterentropy-rngd was mentioned here on list as a newer alternative to 
haveged.

Using an external hardware random generator is another option I know of, 
possibly the most secure, if you trust the implementation.

I considered all of them. Ultimately I settled on none, because I only 
get about 5 seconds delay on my PINE A64+ (arm64):

amp@pine64:~$ sudo dmesg | grep 'random.*done'
[    6.785377] random: fast init done
[   11.632783] random: crng init done


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#211018

On 2019-07-08, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
>> Well, at the very least people should be informed who is likely to be
>> affected by the bug
>
> In my understanding a lot of daemons are affected. Would it make sense
> to (try to) list them all?

Well, then, you should make that explicit, viz. that almost everyone
risks waiting for minutes to hours booting due to entropy starvation
unless they are lucky enough to have a modern x86 CPU that supports the
RDRAND instruction, in which case Debian will effectuate by default a
workaround whose author, probably the leading expert in all things
random for the Linux OS named Theodore Ts'o, has stated clearly and
repeatedly is a BAD IDEA, because it "amounts to trusting that CPU
manufacturer (perhaps with the insistence or mandate of a Nation State's
intelligence or law enforcement agencies) has not installed a hidden
back door to compromise the CPU's random number generation facilities."

> I considered all of them. Ultimately I settled on none, because I only
> get about 5 seconds delay on my PINE A64+ (arm64):

I should be so lucky.

-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

[toc] | [prev] | [next] | [standalone]

#211022

Hi Curt,

On Mon, Jul 08, 2019 at 05:48:24PM -0000, Curt wrote:
> it "amounts to trusting that CPU manufacturer (perhaps with the
> insistence or mandate of a Nation State's intelligence or law
> enforcement agencies) has not installed a hidden back door to
> compromise the CPU's random number generation facilities."

Again, everyone using a popular CPU is already in that position.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web