So we probably didn't strictly need an rc8 this release, but with LPC
and the KS conference travel this upcoming week it just makes
everything easier.
And partly because of the extra week, we then had a few fixes that
maybe otherwise would have been delayed and marked for stable. The
most notable one (but hopefully not very noticeable) is fixing race
conditions in configfs. That won't affect very many people, with
configfs not all that widely used, but Christoph and Al both felt it
needed to be fixed.
Other than that, it really is a very small rc (and hopefully the final
week will be smaller still). In fact, the configfs fix along with a
vhost revert is about half of the patch. The rest is various small
things: a few sound fixes, some drm fixes, and a few other random
fixes. Even in the drm case, the selftest addition is bigger than the
core code patches.
The appended shortlog is short enough that it's easy enough to scroll
through if you are interested in the details.
Linus
---
Al Viro (4):
configfs: stash the data we need into configfs_buffer at open time
configfs_register_group() shouldn't be (and isn't) called in
rmdirable parts
configfs: new object reprsenting tree fragments
configfs: provide exclusion between IO and removals
Andrew Cooper (1):
Documentation/process: Volunteer as the ambassador for Xen
Baolin Wang (1):
dmaengine: sprd: Fix the DMA link-list configuration
Ben Skeggs (1):
drm/nouveau/sec2/gp102: add missing MODULE_FIRMWAREs
Benjamin Tissoires (1):
Input: elan_i2c - remove Lenovo Legion Y7000 PnpID
Christophe Leroy (1):
powerpc/64e: Drop stale call to smp_processor_id() which hangs SMP startup
Dan Carpenter (1):
drm/vmwgfx: Fix double free in vmw_recv_msg()
David Jander (2):
gpio: pca953x: correct type of reg_direction
gpio: pca953x: use pca953x_read_regs instead of regmap_bulk_read
Fabrizio Castro (1):
arm64: dts: renesas: hihope-common: Fix eMMC status
Geert Uytterhoeven (1):
arm64: dts: renesas: r8a77995: draak: Fix backlight regulator name
Gustavo Romero (2):
powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction
powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts
Hillf Danton (1):
keys: Fix missing null pointer check in request_key_auth_describe()
Hui Wang (1):
ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre
Ingo Molnar (1):
sched/core: Fix uclamp ABI bug, clean up and robustify
sched_read_attr() ABI logic and code
Jacob Pan (1):
iommu/vt-d: Remove global page flush support
James Smart (1):
scsi: lpfc: Raise config max for lpfc_fcp_mq_threshold variable
Jan Kaisrlik (1):
Revert "mmc: core: do not retry CMD6 in __mmc_switch()"
Jeff Moyer (1):
libnvdimm/pfn: Fix namespace creation on misaligned addresses
Jian-Hong Pan (1):
ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL
Joerg Roedel (1):
iommu/amd: Fix race in increase_address_space()
John S. Gruber (1):
x86/boot: Preserve boot_params.secure_boot from sanitizing
Kees Cook (1):
Documentation/process: Add Google contact for embargoed hardware issues
Laurent Pinchart (1):
drm/ingenic: Hardcode panel type to DPI
Lee Jones (1):
soc: qcom: geni: Provide parameter error checking
Liangyan (1):
sched/fair: Don't assign runtime for throttled cfs_rq
Linus Torvalds (2):
Revert "x86/apic: Include the LDR when clearing out APIC registers"
Linux 5.3-rc8
Lu Baolu (1):
Revert "iommu/vt-d: Avoid duplicated pci dma alias consideration"
Maxime Ripard (4):
drm/modes: Add a switch to differentiate free standing options
drm/modes: Fix the command line parser to take force options into account
drm/modes: Introduce a whitelist for the named modes
drm/selftests: modes: Add more unit tests for the cmdline parser
Michael S. Tsirkin (1):
Revert "vhost: access vq metadata through kernel virtual address"
Miguel Ojeda (1):
clang-format: Update with the latest for_each macro list
Nadav Amit (1):
mm/balloon_compaction: suppress allocation warnings
Nick Desaulniers (1):
include/linux/compiler.h: fix Oops for Clang-compiled kernels
Peter Zijlstra (1):
x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation
Sam Bazley (1):
ALSA: hda/realtek - Add quirk for HP Pavilion 15
Sasha Levin (1):
Documentation/process/embargoed-hardware-issues: Microsoft ambassador
Stuart Hayes (1):
iommu/amd: Flush old domains in kdump kernel
Takashi Iwai (2):
ALSA: hda - Fix potential endless loop at applying quirks
ALSA: hda/realtek - Fix overridden device-specific initialization
Tianyu Lan (1):
x86/hyper-v: Fix overflow bug in fill_gva_list()
Tiwei Bie (2):
vhost/test: fix build for vhost test
vhost/test: fix build for vhost test
Trilok Soni (1):
Documentation/process: Add Qualcomm process ambassador for
hardware security issues
Trond Myklebust (1):
NFS: Fix inode fileid checks in attribute revalidation code
Wenwen Wang (2):
dmaengine: ti: dma-crossbar: Fix a memory leak bug
dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe()
Yoshihiro Shimoda (1):
dmaengine: rcar-dmac: Fix DMACHCLR handling if iommu is mapped
Yunsheng Lin (1):
vhost: Remove unnecessary variable
jiang (1):
virtio-net: lower min ring num_free for efficiency
On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
> An alternative might be to make getrandom() just return an error
> instead of waiting. Sure, fill the buffer with "as random as we can"
> stuff, but then return -EINVAL because you called us too early.
That's probably one of the most sensible approaches. I must say I feel
quite annoyed by what randomness has become due to the misuse of poor
random sources by security components suddenly forcing all these sources
to become strong and having to become unavailable for everything which
doesn't need strong random. And most of the time the stuff which doesn't
need a strong random happens during early boot. It can range from issuing
a MAC address before setting a link up (when you have no chance to get
entropy) to providing a UUID for a file system, or use of ephemeral
randoms for session keys for the first access to a device for its
configuration. A number of these often end up with a system not
booting, unable to self-configure itself, or not being available when
expected.
It's too late now to change existing applications, but probably that
doing something like above would at least allow applications to
implement a fall back with the choice of "hey Mr user, there's not
enough entropy yet to propose you a secure password, so please type
20 random chars on the keyboard so that I can complete it", or
conversely "the syscall failed but I know I can still use the
buffer's contents for a MAC address".
But having to make the syscall to wait longer is never going to serve
anyone. Two minutes is an eternity for certain devices, and some from
the security world will consider that the syscall waited long enough
to produce a good security so it's OK to use it as a reliable source.
Failing immediately with whatever could be obtained is by far the
best solution in my opinion as the application has to take the
responsibility for using that buffer's contents.
Willy
-- still dreaming about the day boot loaders will collect entropy from
the DDR training phase and pass it to the kernel.
On Sun, Sep 15, 2019 at 10:02:18AM -0700, Linus Torvalds wrote:
> But on a PC, we can _almost_ guarantee entropy. Even with a golden
> image, we do mix in:
>
> - timestamp counter on every device interrupt (but "device interrupt"
> doesn't include things like the local CPU timer, so it really needs
> device activity)
>
> - random boot and BIOS memory (dmi tables, the EFI RNG entry, etc)
>
> - various device state (things like MAC addresses when registering
> network devices, USB device numbers, etc)
>
> - and obviously any CPU rdrand data
> ....
> But also note the "on a PC" part.
Hopefully there is no disagreement with this. I completely agree that
if we only care about user desktops running on PC's, getrandom(2)
should never block, and *hopefully* a big fact kernel stack dump will
cause developers to wake up and pay attention. And even if they don't
essentially all modern systems have RDRAND, and RDRAND will save you.
We're also not using the EFI RNG yet, but we should, and once we do,
that will again help for all modern PC's.
However, there are exceptions here --- and we don't even need to leave
the X86 architecture. If you are running in a VM, there won't be a
lot of interrutps, and some hosts may disable RDRAND (or are on a
system where RDRAND was buggy, and hence disabled), and the dmi tables
are pretty much constant and trivial for an attacker to deduce.
> But basically, you should never *ever* try to generate some long-lived
> key and then just wait for it without doing anything else. The
> "without doing anything else" is key here.
>
> But every time we've had a blocking interface, that's exactly what
> somebody has done. Which is why I consider that long blocking thing to
> be completely unacceptable. There is no reason to believe that the
> wait will ever end, partly exactly because we don't consider timer
> interrupts to add any timer randomness. So if you are just waiting,
> nothing necessarily ever happen.
Ultimately, the question is whether blocking is unacceptable, or
compromising the user's security is unacceptable. The former is much
more likely to cause users to whine on LKML and send complaints of
regressions to Linus. No question about that.
But not blocking is *precisely* what lead us to weak keys in network
devices that were sold by the millions to users in their printers,
wifi routers, etc. And with /dev/urandom, we didn't block, and we did
issue a warning messages, and it didn't stop consumer electronic
vendors from screwing up. And then there will be another paper
published, and someone will contact [email protected], and it will
be blamed on the Linux kernel, because best practice really *is* to
block until you can return cryptographic randomness, because we can
take it on *faith* that there will be some (and probably many) user
space programmers which rally don't know how to do system design,
especially secure systems design. Many of them won't even bother to
look at system logs.
And even blocking for 15 seconds may not necessarily help much, since
consumer grade electronics won't have a serial console, and hardware
engineers might not even notice a 15 second delay. Sure, someone who
is used to a laptop booting up in 3 seconds will be super annoyed by a
15 second delay --- but there are many contexts where a 15 second
delay is nothing.
It often takes a minute or more to start up a Cloud VM, for example,
and if users aren't checking the system logs --- and most IOT
application programmers won't be checking system logs, and 15 seconds
to boot might not even be noticed during development for some devices.
And even on a big x86 server, it can take 5+ minutes for it to boot
(between BIOS and kernel probe time), so 15 seconds won't be noticed.
Linus, I know you don't like the config approach, but the problem is
there is not going to be any "one size fits all" solution, because
Linux gets used in so many places. We can set up defaults so that for
x86, we never block and just create a big fat warning, and cross our
fingers and hope that's enough. But on other platforms, 15 seconds
won't be the right number, and you might actually need something
closer to two minutes before the delay will be noticed. And on some
of these other platforms, the use of "best effort" randomness might be
***far*** more catastrophic from a security perspective than on an
x86.
This is why I really want the CONFIG option. I'm willing to believe
that the x86 architecture will mostly be safe, so we could never ask
for the option on some set of architectures (unless CONFIG_EXPERT is
enabled). But there will be other architectures and use cases where
"never blocking" and "return best effort randomness" is going to be
unacceptable, and lead to massive security problems, that could be
quite harmful. So for those architectures, I'd really like to make
the CONFIG option be visible, and even default it to "block".
For the embedded use case, we want it to be blatently obvious that
there is a problem, so the developer finds it, and not the consumer.
And blocking forever really is the best way to force the embedded
programmer to notice that there is a problem, and then fix userspace,
or add a hardware RNG, etc. And that's because for embeeded
arhictectures, blocking really is no big deal, but letting a product
escape with a massive security hole caused by "best efforts"
randomness being garbage is in my book, completely unacceptable.
Regards,
- Ted
On Tue, Sep 17, 2019 at 10:42 AM Lennart Poettering
<[email protected]> wrote:
>
> So I think people nowadays prefer getrandom() over /dev/urandom
> primarily because of the noisy logging the kernel does when you use
> the latter on a non-initialized pool. If that'd be dropped then I am
> pretty sure that the porting from /dev/urandom to getrandom() you see
> in various projects (such as gdm/x11) would probably not take place.
Sad. So people were actually are perfectly happy with urandom, but you
don't want the warning, so you use getrandom() and as a result your
boot blocks.
What a sad sad reason for a bug.
Btw, having a "I really don't care deeply about some long-term secure
key" flag would soilve that problem too. We'd happily and silently
give you data.
The only reason we _do_ that silly printout for /dev/urandom is
exactly because /dev/random wasn't useful even for the people who
_really_ wanted secure randomness, so they started using /dev/urandom
despite the fact that it didn't necessarily have any entropy at all.
So this all actually fundamentally goes back to the absolutely horrid
and entirely wrong semantics of /dev/random that made it entirely
useless for the only thing it was actually designed for.
This is also an example of how hard-line "security" people that don't
see the shades of gray in between black and white are very much part
of the problem. If you have some unreasonable hard requirements,
you're going to do the wrong thing in the end.
At some point even security people need to realize that reality isn't
black-and-white. It's not also keeping us from making any sane
progress, I feel, because of that bogus "entropy is sacred", despite
the fact that our entropy calculations are actually just random
made-up stuff (but "hey, reasonable") to begin with and aren't really
black-and-white themselves.
> In fact, speaking for systemd: the noisy logging in the kernel is the
> primary (actually: only) reason that we prefer using RDRAND (if
> available) over /dev/urandom if we need "medium quality" random
> numbers, for example to seed hash tables and such. If the log message
> wasn't there we wouldn't be tempted to bother with RDRAND and would
> just use /dev/urandom like we used to for that.
That's also very sad. If we have rdrand, we'll actually mix it into
/dev/urandom regardless, so it's again just the whole "people started
using urandom for keys because random was broken" that is the cause of
this all.
I really really detest the whole inflexible "security" mindset.
> We can make boot hang in "sane", discoverable way.
That is certainly a huge advantage, yes. Right now I suspect that what
has happened is that this has probably been going on as some low-level
background noise for a while, and people either figured it out and
switched away from gdm (example: Christoph), or more likely some
unexplained boot problems that people just didn't chase down. So it
took basically a random happenstance to make this a kernel issue.
But "easily discoverable" would be good.
> The reason why I think this should also be logged by the kernel since
> people use netconsole and pstore and whatnot and they should see this
> there. If systemd with its infrastructure brings this to screen via
> plymouth then this wouldn't help people who debug much more low-level.
Well, I certainly agree with a kernel message (including a big
WARN_ON_ONCE), but you also point out that the last time we added
helpful messages to let people know, it had some seriously unintended
consequences ;)
Linus
Side note, and entirely unrelated to this particular problem, but
_because_ I was looking at the entropy init and sources of randomness
we have, I notice that we still don't use the ToD clock as a source.
There's not a whole lot of bits there, but at least one of the attacks
against entirely missing boot-time randomness was to look at the
output of get_random_bytes(), and just compare it across machines. We
sanitize things by going through a cryptographic hash function, but
that helps hide the internal entropy buffers from direct viewing, but
it still leaves the "are those internal entropy buffers the _same_
across machines" for the nasty embedded hardware case with identical
hardware.
Of course, some of those machines didn't even have a a time-of-day
clock either. But the fact that some didn't doesn't mean we shouldn't
take it into account.
So adding a "add_device_randomness()" to do_settimeofday64() (which
catches them all) wouldn't be a bad idea. Not perhaps "entropy", but
helping against detecting the case of basically very limited entropy
at all at early boot.
I'm pretty sure we discussed that case when we did those things
originally, but I don't actually see us doing it anywhere right now.
So we definitely have some sources of differences for different
systems that we could/should use, even if we might not be able to
really account them as "entropy". The whole "people generated a number
of the same keys" is just horrendously bad, even if they were to use
/dev/urandom that doesn't have any strict entropy guarantees.
Linus
On Tue, Sep 17, 2019 at 9:08 AM Lennart Poettering <[email protected]> wrote:
>
> Here's what I'd propose:
So I think this is ok, but I have another proposal. Before I post that
one, though, I just wanted to point out:
> 1) Add GRND_INSECURE to get those users of getrandom() who do not need
> high quality entropy off its use (systemd has uses for this, for
> seeding hash tables for example), thus reducing the places where
> things might block.
I really think that trhe logic should be the other way around.
The getrandom() users that don't need high quality entropy are the
ones that don't really think about this, and so _they_ shouldn't be
the ones that have to explicitly state anything. To those users,
"random is random". By definition they don't much care, and quite
possibly they don't even know what "entropy" really means in that
context.
The ones that *do* want high security randomness should be the ones
that know that "random" means different things to different people,
and that randomness is hard.
So the onus should be on them to say that "yes, I'm one of those
people willing to wait".
That's why I'd like to see GRND_SECURE instead. That's kind of what
GRND_RANDOM is right now, but it went overboard and it's not useful
even to the people who do want secure random numners.
Besides, the GRND_RANDOM naming doesn't really help the people who
don't know anyway, so it's just bad in so many ways. We should
probably just get rid of that flag entirely and make it imply
GRND_SECURE without the overdone entropy accounting, but that's a
separate issue.
When we do add GRND_SECURE, we should also add the GRND_INSECURE just
to allow people to mark their use, and to avoid the whole existing
confusion about "0".
> 2) Add a kernel log message if a getrandom(0) client hung for 15s or
> more, explaining the situation briefly, but not otherwise changing
> behaviour.
The problem is that when you have some graphical boot, you'll not even
see the kernel messages ;(
I do agree that a message is a good idea regardless, but I don't think
it necessarily solves the problems except for developers.
> 3) Change systemd-random-seed.service to log to console in the same
> case, blocking boot cleanly and discoverably.
So I think systemd-random-seed might as well just use a new
GRND_SECURE, and then not even have to worry about it.
That said, I think I have a suggestion that everybody can live with -
even if they might not be _happy_ about it. See next email.
> I am not a fan of randomly killing userspace processes that just
> happened to be the unlucky ones, to call this first... I see no
> benefit in killing stuff over letting boot hang in a discoverable way.
Absolutely agreed. The point was to not break things.
Linus
On Mi, 18.09.19 13:26, Linus Torvalds ([email protected]) wrote:
> On Wed, Sep 18, 2019 at 1:15 PM Alexander E. Patrakov
> <[email protected]> wrote:
> >
> > No, this is not the solution, if we take seriously not only getrandom
> > hangs, but also urandom warnings. In some setups (root on LUKS is one of
> > them) they happen early in the initramfs. Therefore "restoring" entropy
> > from the previous boot by a script that runs from the main system is too
> > late. That's why it is suggested to load at least a part of the random
> > seed in the boot loader, and that has not been commonly implemented.
>
> Honestly, I think the bootloader suggestion is naive and silly too.
>
> Yes, we now support it. And no, I don't think people will trust that
> either. And I suspect for good reason: there's really very little
> reason to believe that bootloaders would be any better than any other
> part of the system.
>
> So right now some people trust bootloaders exactly _because_ there
> basically is just one or two that do this, and the people who use them
> are usually the people who wrote them or are at least closely
> associated with them. That will change, and then people will say "why
> would I trust that, when we know of bug Xyz".
Doing the random seed in the boot loader is nice for two reasons:
1. It runs very very early, so that the OS can come up with fully
initialized entropy right from the beginning.
2. The boot loader generally has found some disk to read the kernel from,
i.e. has a place where stuff can be stored and which can be updated
(most modern boot loaders can write to disk these days, and so can
EFI). Thus, it can derive a new random seed from a stored seed on disk
and pass it to the OS *AND* update it right away on disk ensuring that
it is never reused again. The point where the OS kernel comes to an
equivalent point where it can write to disk is much much later,
i.e. after the initrd, after the transition to the actual OS, ony
after /var has been remounted writable.
So to me this is not about trust, but about "first place we can read
*AND* write a seed on disk".
i.e. the key to grok here: it's not OK to use a stored seed unless you
can at the same time update the it on disk, as only that protects you
from reusing the key if the system's startup is aborted due to power
failure or such.
> Adding an EFI variable (or other platform nonvolatile thing), and
> reading (and writing to it) purely from the kernel ends up being one
> of those things where you can then say "ok, if we trust the platform
> AT ALL, we can trust that". Since you can't reasonably do things like
> add EFI variables to your distro image by mistake.
NVRAM backing EFI vars sucks. Nothing you want to update on every
cycle. It's OK to update during OS installation, but during every
single boot? I'd rather not.
Lennart
--
Lennart Poettering, Berlin