linux-kernel - [RFC/PATCH 0/3] Add devicetree scanning for randomness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1392168805-14200-1-git-send-email-lauraa@codeaurora.org>
Date:	Tue, 11 Feb 2014 17:33:22 -0800
From:	Laura Abbott <lauraa@...eaurora.org>
To:	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>, Arnd Bergmann <arnd@...db.de>
Cc:	Laura Abbott <lauraa@...eaurora.org>, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Kumar Gala <galak@...eaurora.org>,
	Kees Cook <keescook@...omium.org>
Subject: [RFC/PATCH 0/3] Add devicetree scanning for randomness

Hi,

This is an RFC to seed the random number pool earlier when using devicetree.
The big issue this is trying to solve is the fact that the stack canary for
ARM tends to be the same across bootups of the same device. This is because
the random number pools do not get initialized until after the canary has
been set up. The canary can be moved later, but in general there is still
no way to reliably get random numbers early for other features (e.g. vector
randomization).

The goal here is to allow devices to add to the random pools via
add_device_randomness or some other method of their chosing at FDT time.
I realize that ARCH_RANDOM is already available but this didn't work because
1) ARCH_RANDOM is not multi-platform compatible without added
infrastructure to ARM
2) There is no uniform way to generate the random numbers which
would require an additional framework (same result as #1, different
reasons)
3) Given there is no uniform way to generate the random numbers, it seems
unlikely that 'early' random numbers would work the same as 'non-early'
random number which adds another layer of complexity.

The big reason to skip ARCH_RANDOM though is that the random number generation
we have would be reasonable if only seeded earlier.

Thanks,
Laura

Laura Abbott (3):
  of: Add early randomness hooks
  arm: Add ARCH_WANT_OF_RANDOMNESS
  init: Move stack canary initialization after setup_arch

 arch/arm/Kconfig                  |    3 ++
 arch/arm/kernel/vmlinux.lds.S     |    1 +
 drivers/of/Kconfig                |    7 ++++++
 drivers/of/Makefile               |    1 +
 drivers/of/fdt.c                  |    7 ++++++
 drivers/of/of_randomness.c        |   43 +++++++++++++++++++++++++++++++++++++
 include/asm-generic/vmlinux.lds.h |    5 ++++
 include/linux/of_randomness.h     |   42 ++++++++++++++++++++++++++++++++++++
 init/main.c                       |    9 +++----
 9 files changed, 113 insertions(+), 5 deletions(-)
 create mode 100644 drivers/of/of_randomness.c
 create mode 100644 include/linux/of_randomness.h

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/