tinification: Make memory-access char devices optional
Subsystems (5)
cover tinification: Make memory-access char devices optional
This patchset adds a top-level config option, CONFIG_DEVMEM_BASE, and a series of dependent options below it which allow various devices such as /dev/mem, /dev/null, /dev/zero, /dev/random, etc. to be disabled. This allows embedded systems systems that don't need any or all of those devices to save the kernel memory associated with those devices.
It also adds a related option to disable the getrandom(2) syscall, CONFIG_GETRANDOM_SYSCALL, which allows code shared between it and /dev/*random to be compiled out as well.
Disabling of CONFIG_DEVMEM_BASE and its dependent options is only available if CONFIG_EMBEDDED is enabled; normal systems will still have everything enabled as usual.
bloat-o-meter shows a total 6k savings for a tinyconfig kernel with all options disabled, and about 10k savings for the same thing but using defconfig.
bloat-o-meter (based on tinyconfig):
add/remove: 0/55 grow/shrink: 1/3 up/down: 332/-6563 (-6231)
function old new delta extract_entropy 114 446 +332 __print_once 13 12 -1 write_null 3 - -3 read_null 3 - -3 mix_pool_bytes 17 14 -3 aio_read_null 3 - -3 pipe_to_null 4 - -4 mem_class 4 - -4 write_full 6 - -6 devkmsg_release 15 - -15 random_fasync 16 - -16 mmap_zero 16 - -16 aio_write_null 18 - -18 open_port 19 - -19 random_read 20 - -20 splice_write_null 24 - -24 null_lseek 25 - -25 mmap_mem_ops 32 - -32 mem_devnode 35 - -35 mmap_kmem 37 - -37 random_write 42 - -42 xfer_secondary_pool 60 - -60 write_pool 82 - -82 random_poll 83 - -83 read_iter_zero 95 - -95 urandom_read 96 - -96 memory_open 96 - -96 devkmsg_poll 97 - -97 read_port 98 - -98 mmap_mem 103 - -103 devkmsg_open 112 - -112 write_port 116 - -116 zero_fops 120 - -120 urandom_fops 120 - -120 random_fops 120 - -120 port_fops 120 - -120 null_fops 120 - -120 memory_fops 120 - -120 mem_fops 120 - -120 kmsg_fops 120 - -120 kmem_fops 120 - -120 full_fops 120 - -120 memory_lseek 122 - -122 devkmsg_llseek 144 - -144 chr_dev_init 162 3 -159 read_mem 162 - -162 extract_buf 164 - -164 _random_read.part 173 - -173 account 181 - -181 write_mem 184 - -184 devlist 192 - -192 extract_entropy_user 197 - -197 devkmsg_write 209 - -209 sys_getrandom 211 - -211 zero_bdi 244 - -244 read_kmem 290 - -290 random_ioctl 319 - -319 write_kmem 349 - -349 devkmsg_read 699 - -699
The following changes since commit 5eb11d6b3f55eb4d28c51ea7f641c0e5e255a70f:
Merge tag 'sound-3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2015-01-21 20:37:25 +1200)
are available in the git repository at:
git://git.yoctoproject.org/linux-yocto-contrib.git tzanussi/devmem-tinification-v1
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=tzanussi/devmem-tinification-v1
Tom Zanussi (10):
drivers/char: Support compiling out memory-access char devices drivers/char: Support compiling out /dev/mem drivers/char: Support compiling out /dev/port drivers/char: Support compiling out /dev/null drivers/char: Support compiling out /dev/zero drivers/char: Support compiling out /dev/full drivers/char: Support compiling out /dev/random drivers/char: Support compiling out /dev/urandom drivers/char: Support compiling out /dev/kmsg drivers/char: Support compiling out the getrandom(2) syscall
arch/x86/Kconfig.debug | 1 + drivers/char/Kconfig | 109 ++++++++++++++++++++++++++++++++++++++++++++++++- drivers/char/mem.c | 83 +++++++++++++++++++++++++++---------- drivers/char/random.c | 24 ++++++++--- kernel/printk/printk.c | 2 + kernel/sys_ni.c | 1 + 6 files changed, 192 insertions(+), 28 deletions(-)
Signature · 1 line
1.9.3
PATCH 1/10 drivers/char: Support compiling out memory-access char devices
Many embedded systems can get by without the complete set of memory-access char devices: /dev/mem, /dev/kmem, /dev/zero, /dev/null, /dev/full, /dev/random, /dev/urandom, /dev/port, and /dev/kmsg.
Omitting them all can be accomplished by disabling DEVMEM_BASE, a new EMBEDDED config option.
If DEVMEM_BASE is enabled, each of those devices can still be enabled individually.
bloat-o-meter (based on tinyconfig):
add/remove: 0/51 grow/shrink: 2/1 up/down: 313/-5820 (-5507)
function old new delta sys_getrandom 211 432 +221 do_syslog 1027 1119 +92 write_null 3 - -3 read_null 3 - -3 aio_read_null 3 - -3 pipe_to_null 4 - -4 mem_class 4 - -4 write_full 6 - -6 devkmsg_release 15 - -15 random_fasync 16 - -16 mmap_zero 16 - -16 aio_write_null 18 - -18 open_port 19 - -19 random_read 20 - -20 splice_write_null 24 - -24 null_lseek 25 - -25 mmap_mem_ops 32 - -32 mem_devnode 35 - -35 mmap_kmem 37 - -37 random_write 42 - -42 write_pool 82 - -82 random_poll 83 - -83 read_iter_zero 95 - -95 urandom_read 96 - -96 memory_open 96 - -96 devkmsg_poll 97 - -97 read_port 98 - -98 mmap_mem 103 - -103 devkmsg_open 112 - -112 check_syslog_permissions 114 - -114 zero_fops 116 - -116 write_port 116 - -116 urandom_fops 116 - -116 random_fops 116 - -116 port_fops 116 - -116 null_fops 116 - -116 memory_fops 116 - -116 mem_fops 116 - -116 kmsg_fops 116 - -116 kmem_fops 116 - -116 full_fops 116 - -116 memory_lseek 122 - -122 devkmsg_llseek 144 - -144 chr_dev_init 162 3 -159 read_mem 162 - -162 _random_read.part 173 - -173 write_mem 184 - -184 devlist 192 - -192 devkmsg_write 209 - -209 zero_bdi 244 - -244 read_kmem 290 - -290 random_ioctl 319 - -319 write_kmem 349 - -349 devkmsg_read 699 - -699
--- arch/x86/Kconfig.debug | 1 + drivers/char/Kconfig | 12 ++++++++++++ drivers/char/mem.c | 7 +++++++ 3 files changed, 20 insertions(+)
arch/x86/Kconfig.debug +1 -0
@@ -7,6 +7,7 @@ source "lib/Kconfig.debug" config STRICT_DEVMEM bool "Filter access to /dev/mem" + depends on DEVMEM_BASE ---help--- If this option is disabled, you allow userspace (root) access to all of memory, including kernel and userspace memory. Accidental
drivers/char/Kconfig +12 -0
@@ -6,8 +6,19 @@ menu "Character devices" source "drivers/tty/Kconfig" +config DEVMEM_BASE + bool "Base support for memory-access char devices" if EMBEDDED + default y + help + Say Y here if you want to support the various character + devices used to access memory, such as /dev/mem, /dev/null, + /dev/zero, /dev/random, etc. Many embedded systems can get + by without these devices; doing so will save memory. When + in doubt, say "Y". + config DEVKMEM bool "/dev/kmem virtual device support" + depends on DEVMEM_BASE default y help Say Y here if you want to support the /dev/kmem device. The
@@ -577,6 +588,7 @@ config DEVPORT bool depends on !M68K depends on ISA || PCI + depends on DEVMEM_BASE default y source "drivers/s390/char/Kconfig"
drivers/char/mem.c +7 -0
@@ -34,6 +34,7 @@# include <linux/efi.h> #endif +#ifdef CONFIG_DEVMEM_BASE #define DEVPORT_MINOR 4 static inline unsigned long size_inside_page(unsigned long start,
@@ -876,5 +877,11 @@ static int __init chr_dev_init(void) return tty_init(); } +#else +static int __init chr_dev_init (void ) +{ +return tty_init (); +} +#endif /* CONFIG_DEVMEM_BASE */ fs_initcall (chr_dev_init);
Signature · 1 line
1.9.3
PATCH 2/10 drivers/char: Support compiling out /dev/mem
In reply to Tom ZanussiMost embedded systems have no use for /dev/mem, and omitting it saves space. Add a new EMBEDDED config option to disable it.
mmap_mem() is shared between /dev/mem and /dev/kmem; making it __maybe_unused prevents it from emitting warnings if both devices are compiled out, while avoiding ugly compound ifdefs.
Also, STRICT_DEVMEM can now be refined to depend on DEVMEM rather than the big hammer, DEVMEM_BASE.
bloat-o-meter (based on tinyconfig):
add/remove: 0/4 grow/shrink: 1/0 up/down: 96/-565 (-469)
function old new deltammap_kmem 37 133 +96
mmap_mem 103 - -103 mem_fops 116 - -116 read_mem 162 - -162 write_mem 184 - -184
Here we see mmap_mem inlined in mmap_kmem and mmap_mem going away.
bloat-o-meter showing only CONFIG_DEVKMEM off:
add/remove: 0/4 grow/shrink: 0/0 up/down: 0/-792 (-792)
function old new delta
mmap_kmem 37 - -37 kmem_fops 116 - -116 read_kmem 290 - -290 write_kmem 349 - -349
bloat-o-meter showing the difference between only CONFIG_DEVKMEM off and both CONFIG_DEVKMEM and CONFIG_DEVMEM off:
add/remove: 0/5 grow/shrink: 0/0 up/down: 0/-597 (-597)
function old new delta
mmap_mem_ops 32 - -32 mmap_mem 103 - -103 mem_fops 116 - -116 read_mem 162 - -162 write_mem 184 - -184
Here we see mmap_mem going away as before, but also not being inlined by mmap_kmem because that's gone, and mmap_mem_ops goes away as well, because it's not being used by even an inlined mmap_mem.
--- arch/x86/Kconfig.debug | 2 +- drivers/char/Kconfig | 10 ++++++++++ drivers/char/mem.c | 9 ++++++++- 3 files changed, 19 insertions(+), 2 deletions(-)
arch/x86/Kconfig.debug +1 -1
@@ -7,7 +7,7 @@ source "lib/Kconfig.debug" config STRICT_DEVMEM bool "Filter access to /dev/mem" - depends on DEVMEM_BASE + depends on DEVMEM ---help--- If this option is disabled, you allow userspace (root) access to all of memory, including kernel and userspace memory. Accidental
drivers/char/Kconfig +10 -0
@@ -26,6 +26,16 @@ config DEVKMEM kind of kernel debugging operations. When in doubt, say "N". +config DEVMEM + bool "/dev/mem virtual device support" if EMBEDDED + depends on DEVMEM_BASE + default y + help + Say Y here if you want to support the /dev/mem device. The + /dev/mem device is used mainly by X and dosemu, and can be + disabled on systems that will never use either, such as many + embedded systems. When in doubt, say "Y". + config SGI_SNSC bool "SGI Altix system controller communication support" depends on (IA64_SGI_SN2 || IA64_GENERIC)
drivers/char/mem.c +8 -1
@@ -92,6 +92,7 @@ void __weak unxlate_dev_mem_ptr(phys_addr_t phys, void *addr) }#endif +#ifdef CONFIG_DEVMEM /* * This funcion reads the *physical* memory. The f_pos points directly to the * memory location.
@@ -220,6 +221,7 @@ static ssize_t write_mem(struct file *file, const char __user *buf, *ppos += written; return written; } +#endif int __weak phys_mem_access_prot_allowed (struct file *file,unsigned long pfn,unsigned long size,pgprot_t *vma_prot)
@@ -308,7 +310,8 @@ static const struct vm_operations_struct mmap_mem_ops = {#endif }; -static int mmap_mem (struct file *file,struct vm_area_struct *vma) +static int __maybe_unused mmap_mem (struct file *file, +struct vm_area_struct *vma) {size_t size = vma->vm_end - vma->vm_start;
@@ -716,6 +719,7 @@ static int open_port(struct inode *inode, struct file *filp)#define open_mem open_port#define open_kmem open_mem +#ifdef CONFIG_DEVMEM static const struct file_operations mem_fops = { .llseek = memory_lseek, .read = read_mem,
@@ -724,6 +728,7 @@ static const struct file_operations mem_fops = { .open = open_mem, .get_unmapped_area = get_unmapped_area_mem, }; +#endif #ifdef CONFIG_DEVKMEM static const struct file_operations kmem_fops = {
@@ -786,7 +791,9 @@ static const struct memdev {const struct file_operations *fops;struct backing_dev_info *dev_info; } devlist[] = { +#ifdef CONFIG_DEVMEM [1] = { "mem", 0, &mem_fops, &directly_mappable_cdev_bdi }, +#endif #ifdef CONFIG_DEVKMEM [2] = { "kmem", 0, &kmem_fops, &directly_mappable_cdev_bdi }, #endif
Signature · 1 line
1.9.3
PATCH 3/10 drivers/char: Support compiling out /dev/port
In reply to Tom ZanussiThere's already a CONFIG_DEVPORT option, but it isn't accessible to users. Give it some menu and help text and allow it to be toggled off.
Aside from giving embedded systems that don't need it the ability to turn it off, it also allows the code shared between it and other options to be compiled out (open_port() shared with /dev/mem, and memory_lseek() shared with /dev/mem and /dev/kmem; both functions have been changed to __maybe_unused for when all of the above are compiled out).
bloat-o-meter (based on tinyconfig):
add/remove: 0/3 grow/shrink: 0/0 up/down: 0/-330 (-330)
function old new delta
read_port 98 - -98 write_port 116 - -116 port_fops 116 - -116
bloat-o-meter showing the difference between both CONFIG_DEVKMEM and CONFIG_DEVMEM off and that plus CONFIG_DEVPORT off:
add/remove: 0/5 grow/shrink: 0/0 up/down: 0/-471 (-471)
function old new delta
open_port 19 - -19 read_port 98 - -98 write_port 116 - -116 port_fops 116 - -116 memory_lseek 122 - -122
So with all three configured out, we see the mutually shared open_port and memory_lseek drop out.
--- drivers/char/Kconfig | 7 ++++++- drivers/char/mem.c | 5 +++-- 2 files changed, 9 insertions(+), 3 deletions(-)
drivers/char/Kconfig +6 -1
@@ -595,11 +595,16 @@ config TELCLOCK controlling the behavior of this hardware. config DEVPORT - bool + bool "/dev/port virtual device support" depends on !M68K depends on ISA || PCI depends on DEVMEM_BASE default y + help + Say Y here if you want to support the /dev/port device. The + /dev/port device is a character device that allows userspace + access to I/O ports, which may be needed by some programs. + When in doubt, say "Y". source "drivers/s390/char/Kconfig"
drivers/char/mem.c +3 -2
@@ -682,7 +682,8 @@ static loff_t null_lseek(struct file *file, loff_t offset, int orig)* also note that seeking relative to the "end of file" isn't supported: * it has no meaning, so it returns -EINVAL. */ -static loff_t memory_lseek (struct file *file,loff_t offset,int orig) +static loff_t __maybe_unused memory_lseek (struct file *file,loff_t offset, +int orig) {loff_t ret;
@@ -707,7 +708,7 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig)return ret; } -static int open_port (struct inode *inode,struct file *filp) +static int __maybe_unused open_port (struct inode *inode,struct file *filp) {return capable (CAP_SYS_RAWIO ) ?0 : -EPERM ; }
Signature · 1 line
1.9.3
PATCH 4/10 drivers/char: Support compiling out /dev/null
In reply to Tom ZanussiSome embedded systems with tightly controlled userspace have no use for /dev/null, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.
write_null() and aio_write_null() are shared between /dev/null and /dev/zero; making it __maybe_unused prevents them from emitting warnings if both devices are compiled out, while avoiding ugly compound ifdefs. Similarly for null_lseek, shared between /dev/null, /dev/zero, and /dev/full.
bloat-o-meter (based on tinyconfig):
add/remove: 0/5 grow/shrink: 0/0 up/down: 0/-150 (-150)
function old new delta
read_null 3 - -3 aio_read_null 3 - -3 pipe_to_null 4 - -4 splice_write_null 24 - -24 null_fops 116 - -116
bloat-o-meter showing the difference between only CONFIG_DEVZERO and CONFIG_DEVFULL off and both those plus CONFIG_DEVNULL off:
add/remove: 0/8 grow/shrink: 0/0 up/down: 0/-196 (-196)
function old new delta
write_null 3 - -3 read_null 3 - -3 aio_read_null 3 - -3 pipe_to_null 4 - -4 aio_write_null 18 - -18 splice_write_null 24 - -24 null_lseek 25 - -25 null_fops 116 - -116
So with DEVZERO also configured out, we see the shared write_null, aio_write_null, and null_lseek drop out.
--- drivers/char/Kconfig | 10 ++++++++++ drivers/char/mem.c | 35 ++++++++++++++++++++++------------- 2 files changed, 32 insertions(+), 13 deletions(-)
drivers/char/Kconfig +10 -0
@@ -36,6 +36,16 @@ config DEVMEM disabled on systems that will never use either, such as many embedded systems. When in doubt, say "Y". +config DEVNULL + bool "/dev/null virtual device support" if EMBEDDED + depends on DEVMEM_BASE + default y + help + Say Y here if you want to support the /dev/null device. The + /dev/null device is used by many programs, but some embedded + systems with strictly controlled userspace may not need it. + When in doubt, say "Y". + config SGI_SNSC bool "SGI Altix system controller communication support" depends on (IA64_SGI_SN2 || IA64_GENERIC)
drivers/char/mem.c +22 -13
@@ -593,30 +593,19 @@ static ssize_t write_port(struct file *file, const char __user *buf, }#endif +#ifdef CONFIG_DEVNULL static ssize_t read_null (struct file *file,char __user *buf,size_t count,loff_t *ppos) {return 0 ; } -static ssize_t write_null (struct file *file,const char __user *buf, -size_t count,loff_t *ppos) -{ -return count; -} -static ssize_t aio_read_null (struct kiocb *iocb,const struct iovec *iov,unsigned long nr_segs,loff_t pos) {return 0 ; } -static ssize_t aio_write_null (struct kiocb *iocb,const struct iovec *iov, -unsigned long nr_segs,loff_t pos) -{ -return iov_length (iov, nr_segs); -} -static int pipe_to_null (struct pipe_inode_info *info,struct pipe_buffer *buf,struct splice_desc *sd) {
@@ -628,6 +617,21 @@ static ssize_t splice_write_null(struct pipe_inode_info *pipe, struct file *out, {return splice_from_pipe (pipe, out, ppos, len, flags, pipe_to_null); } +#endif + +static ssize_t __maybe_unused write_null (struct file *file, +const char __user *buf, +size_t count,loff_t *ppos) +{ +return count; +} + +static ssize_t __maybe_unused aio_write_null (struct kiocb *iocb, +const struct iovec *iov, +unsigned long nr_segs,loff_t pos) +{ +return iov_length (iov, nr_segs); +}static ssize_t read_iter_zero (struct kiocb *iocb,struct iov_iter *iter) {
@@ -669,7 +673,8 @@ static ssize_t write_full(struct file *file, const char __user *buf,* can fopen() both devices with "a" now. This was previously impossible. * -- SRB. */ -static loff_t null_lseek (struct file *file,loff_t offset,int orig) +static loff_t __maybe_unused null_lseek (struct file *file,loff_t offset, +int orig) {return file->f_pos =0 ; }
@@ -742,6 +747,7 @@ static const struct file_operations kmem_fops = { };#endif +#ifdef CONFIG_DEVNULL static const struct file_operations null_fops = { .llseek = null_lseek, .read = read_null,
@@ -750,6 +756,7 @@ static const struct file_operations null_fops = { .aio_write = aio_write_null, .splice_write = splice_write_null, }; +#endif #ifdef CONFIG_DEVPORT static const struct file_operations port_fops = {
@@ -798,7 +805,9 @@ static const struct memdev { #ifdef CONFIG_DEVKMEM [2 ] = {"kmem" ,0 , &kmem_fops, &directly_mappable_cdev_bdi }, #endif +#ifdef CONFIG_DEVNULL [3 ] = {"null" ,0666 , &null_fops,NULL }, +#endif #ifdef CONFIG_DEVPORT [4] = { "port", 0, &port_fops, NULL }, #endif
Signature · 1 line
1.9.3
PATCH 5/10 drivers/char: Support compiling out /dev/zero
In reply to Tom ZanussiSome embedded systems with tightly controlled userspace have no use for /dev/zero, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.
bloat-o-meter (based on tinyconfig):
add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-391 (-391)
function old new delta chr_dev_init 162 147 -15 mmap_zero 16 - -16 zero_fops 116 - -116 zero_bdi 244 - -244
--- drivers/char/Kconfig | 10 ++++++++++ drivers/char/mem.c | 15 +++++++++++---- 2 files changed, 21 insertions(+), 4 deletions(-)
drivers/char/Kconfig +10 -0
@@ -46,6 +46,16 @@ config DEVNULL systems with strictly controlled userspace may not need it. When in doubt, say "Y". +config DEVZERO + bool "/dev/zero virtual device support" if EMBEDDED + depends on DEVMEM_BASE + default y + help + Say Y here if you want to support the /dev/zero device. The + /dev/zero device is used by many programs, but some embedded + systems with strictly controlled userspace may not need it. + When in doubt, say "Y". + config SGI_SNSC bool "SGI Altix system controller communication support" depends on (IA64_SGI_SN2 || IA64_GENERIC)
drivers/char/mem.c +11 -4
@@ -633,7 +633,8 @@ static ssize_t __maybe_unused aio_write_null(struct kiocb *iocb,return iov_length (iov, nr_segs); } -static ssize_t read_iter_zero (struct kiocb *iocb,struct iov_iter *iter) +static ssize_t __maybe_unused read_iter_zero (struct kiocb *iocb, +struct iov_iter *iter) {size_t written =0 ;
@@ -652,6 +653,7 @@ static ssize_t read_iter_zero(struct kiocb *iocb, struct iov_iter *iter)return written; } +#ifdef CONFIG_DEVZERO static int mmap_zero (struct file *file,struct vm_area_struct *vma) {#ifndef CONFIG_MMU
@@ -661,6 +663,7 @@ static int mmap_zero(struct file *file, struct vm_area_struct *vma)return shmem_zero_setup (vma); return 0; } +#endif static ssize_t write_full (struct file *file,const char __user *buf,size_t count,loff_t *ppos)
@@ -767,6 +770,7 @@ static const struct file_operations port_fops = { };#endif +#ifdef CONFIG_DEVZERO static const struct file_operations zero_fops = { .llseek = zero_lseek, .read = new_sync_read,
@@ -785,6 +789,7 @@ static struct backing_dev_info zero_bdi = { .name = "char/mem", .capabilities = BDI_CAP_MAP_COPY | BDI_CAP_NO_ACCT_AND_WRITEBACK, }; +#endif static const struct file_operations full_fops = { .llseek = full_lseek,
@@ -811,7 +816,9 @@ static const struct memdev { #ifdef CONFIG_DEVPORT [4] = { "port", 0, &port_fops, NULL }, #endif +#ifdef CONFIG_DEVZERO [5] = { "zero", 0666, &zero_fops, &zero_bdi }, +#endif [7] = { "full", 0666, &full_fops, NULL }, [8] = { "random", 0666, &random_fops, NULL }, [9] = { "urandom", 0666, &urandom_fops, NULL },
@@ -864,12 +871,12 @@ static struct class *mem_class;static int __init chr_dev_init (void ) {int minor; -int err; - err =bdi_init (&zero_bdi); +#ifdef CONFIG_DEVZERO +int err =bdi_init (&zero_bdi);if (err)return err; - +#endif if (register_chrdev (MEM_MAJOR ,"mem" , &memory_fops))printk ("unable to get major %d for memory devs\n" ,MEM_MAJOR );
Signature · 1 line
1.9.3
Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
Quoted 6 lines · Tom Zanussi
Some embedded systems with tightly controlled userspace have no use for
/dev/zero, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.bloat-o-meter (based on tinyconfig):
Quoted 8 lines
add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-391 (-391)
function old new delta chr_dev_init 162 147 -15 mmap_zero 16 - -16 zero_fops 116 - -116 zero_bdi 244 - -244Signed-off-by Tom Zanussi <[email protected]>
I'm not sure that 400 bytes are worth additional Kconfig noise. .. and pretty much everyone needs /dev/zero...
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
Quoted 14 lines · Pavel Machek
Quoted 13 lines · Tom Zanussi
Some embedded systems with tightly controlled userspace have no use for
/dev/zero, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.bloat-o-meter (based on tinyconfig):
add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-391 (-391)
function old new delta chr_dev_init 162 147 -15 mmap_zero 16 - -16 zero_fops 116 - -116 zero_bdi 244 - -244
Quoted 4 lines
Quoted 1 line
Signed-off-by Tom Zanussi <[email protected]>I'm not sure that 400 bytes are worth additional
Kconfignoise. .. and pretty much everyone needs/dev/zero...
Relatively few, actually, given MMAP_ANONYMOUS. Memory isn't allocated via an mmap of /dev/zero. It's useful for systems with shells that want to redirect from it or read from it, but less useful for environments with entirely compiled code.
/dev/null is much more commonly needed, though there are still systems that won't need it (and can just disable read/writes on an fd entirely rather than duping /dev/null to that fd).
That said, I'd be entirely in favor of consolidating many of these "miscellaneous character device" options into a couple of Kconfig options. It doesn't seem critical to *individually* control each of these files in /dev.
Personally, I'm hoping that we eventually end up with a disableable CONFIG_CHAR similar to CONFIG_BLOCK.
- Josh Triplett
Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
Quoted 25 lines · On Wed 2015-01-28 13:51:06, [email protected] wrote:
Quoted 14 lines · Pavel Machek
Quoted 13 lines · Tom Zanussi
Some embedded systems with tightly controlled userspace have no use for
/dev/zero, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.bloat-o-meter (based on tinyconfig):
add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-391 (-391)
function old new delta chr_dev_init 162 147 -15 mmap_zero 16 - -16 zero_fops 116 - -116 zero_bdi 244 - -244Quoted 4 lines
Quoted 1 line
Signed-off-by Tom Zanussi <[email protected]>I'm not sure that 400 bytes are worth additional
Kconfignoise. .. and pretty much everyone needs/dev/zero...Relatively few, actually, given
MMAP_ANONYMOUS. Memory isn't allocated via an mmap of/dev/zero. It's useful for systems with shells that want to redirect from it or read from it, but less useful for environments with entirely compiled code.
Quoted 8 lines
/dev/nullis much more commonly needed, though there are still systems that won't need it (and can just disable read/writes on an fd entirely rather than duping/dev/nullto that fd).That said, I'd be entirely in favor of consolidating many of these "miscellaneous character device" options into a couple of
Kconfigoptions. It doesn't seem critical to *individually* control each of these files in /dev.
Yes, grouping it would make it more acceptable.
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
In reply to [email protected]Quoted 20 lines · On Wed, 2015-01-28 at 13:51 -0800, [email protected] wrote:
Quoted 14 lines · Pavel Machek
Quoted 13 lines · Tom Zanussi
Some embedded systems with tightly controlled userspace have no use for
/dev/zero, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.bloat-o-meter (based on tinyconfig):
add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-391 (-391)
function old new delta chr_dev_init 162 147 -15 mmap_zero 16 - -16 zero_fops 116 - -116 zero_bdi 244 - -244Quoted 4 lines
Quoted 1 line
Signed-off-by Tom Zanussi <[email protected]>I'm not sure that 400 bytes are worth additional
Kconfignoise. .. and pretty much everyone needs/dev/zero...
Quoted 9 lines
Relatively few, actually, given
MMAP_ANONYMOUS. Memory isn't allocated via an mmap of/dev/zero. It's useful for systems with shells that want to redirect from it or read from it, but less useful for environments with entirely compiled code.
/dev/nullis much more commonly needed, though there are still systems that won't need it (and can just disable read/writes on an fd entirely rather than duping/dev/nullto that fd).
For testing, I was able to boot my dev system (Ubuntu) into a usable shell with networking with only /dev/null and /dev/urandom. A restricted userspace could be made/verified to not touch /dev/null.
Quoted 5 lines
That said, I'd be entirely in favor of consolidating many of these "miscellaneous character device" options into a couple of
Kconfigoptions. It doesn't seem critical to *individually* control each of these files in /dev.
I can easily create a small set of groupings instead - how about something like: DEVMEM_RANDOM(/dev/random, /dev/urandom, getrandom()), DEVMEM_MEM (/dev/mem, /dev/kmem, /dev/port), DEVMEM_RW (/dev/null, /dev/zero), and DEVMEM_MISC (/dev/full, /dev/kmsg)?
That cuts the number in half, from 8->4 (we still have a separate DEVPORT and DEVKMEM regardless).
I can also get rid of DEVMEM_RANDOM entirely as mentioned in a previous post, and not allow those to be disabled at all, which saves even more on Kconfig noise.
If you have better ideas and/or naming, please let me know.
Quoted 3 lines
Personally, I'm hoping that we eventually end up with a disableable
CONFIG_CHARsimilar toCONFIG_BLOCK.
If we ditch DEVMEM_RANDOM i.e. make certain devices undisableable then it seems CONFIG_CHAR wouldn't be possible either.
Tom
Quoted 1 line
- Josh Triplett
Re: [PATCH 05/10] drivers/char: Support compiling out /dev/zero
Quoted 26 lines · Tom Zanussi
Quoted 25 lines · On Wed, 2015-01-28 at 13:51 -0800, [email protected] wrote:
Quoted 14 lines · Pavel Machek
Quoted 13 lines · Tom Zanussi
Some embedded systems with tightly controlled userspace have no use for
/dev/zero, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.bloat-o-meter (based on tinyconfig):
add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-391 (-391)
function old new delta chr_dev_init 162 147 -15 mmap_zero 16 - -16 zero_fops 116 - -116 zero_bdi 244 - -244Quoted 4 lines
Quoted 1 line
Signed-off-by Tom Zanussi <[email protected]>I'm not sure that 400 bytes are worth additional
Kconfignoise. .. and pretty much everyone needs/dev/zero...Relatively few, actually, given
MMAP_ANONYMOUS. Memory isn't allocated via an mmap of/dev/zero. It's useful for systems with shells that want to redirect from it or read from it, but less useful for environments with entirely compiled code.
Quoted 7 lines
Quoted 3 lines
/dev/nullis much more commonly needed, though there are still systems that won't need it (and can just disable read/writes on an fd entirely rather than duping/dev/nullto that fd).For testing, I was able to boot my dev system (Ubuntu) into a usable shell with networking with only
/dev/nulland/dev/urandom. A restricted userspace could be made/verified to not touch/dev/null.
And a carefully constructed system with narrower needs (rather than a general-purpose distribution) could avoid touching *any* files in /dev.
Quoted 5 lines
Quoted 4 lines
That said, I'd be entirely in favor of consolidating many of these "miscellaneous character device" options into a couple of
Kconfigoptions. It doesn't seem critical to *individually* control each of these files in /dev.
Quoted 7 lines
I can easily create a small set of groupings instead - how about something like:
DEVMEM_RANDOM(/dev/random, /dev/urandom, getrandom()),DEVMEM_MEM(/dev/mem,/dev/kmem,/dev/port),DEVMEM_RW(/dev/null,/dev/zero), andDEVMEM_MISC(/dev/full,/dev/kmsg)?That cuts the number in half, from 8->4 (we still have a separate DEVPORT and DEVKMEM regardless).
I don't think it makes sense to group full and kmsg. I'd suggest giving kmsg its own option (which likely needs to depend on printk, since it doesn't make sense without a kernel message buffer), and putting null, zero, and full together. (Though full seems like the least useful of the lot.)
Quoted 3 lines
I can also get rid of
DEVMEM_RANDOMentirely as mentioned in a previous post, and not allow those to be disabled at all, which saves even more onKconfignoise.
Please don't.
Quoted 5 lines
Quoted 2 lines
Personally, I'm hoping that we eventually end up with a disableable
CONFIG_CHARsimilar toCONFIG_BLOCK.If we ditch
DEVMEM_RANDOMi.e. make certain devices undisableable then it seemsCONFIG_CHARwouldn't be possible either.
An excellent reason not to ditch it, then.
- Josh Triplett
PATCH 6/10 drivers/char: Support compiling out /dev/full
In reply to Tom ZanussiMost embedded systems have no use for /dev/full, and omitting it saves space. Add a new EMBEDDED config option to disable it.
bloat-o-meter (based on tinyconfig):
add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-122 (-122)
function old new deltawrite_full 6 - -6full_fops 116 - -116
--- drivers/char/Kconfig | 11 +++++++++++ drivers/char/mem.c | 6 ++++++ 2 files changed, 17 insertions(+)
drivers/char/Kconfig +11 -0
@@ -56,6 +56,17 @@ config DEVZERO systems with strictly controlled userspace may not need it. When in doubt, say "Y". +config DEVFULL + bool "/dev/full virtual device support" if EMBEDDED + depends on DEVMEM_BASE + default y + help + Say Y here if you want to support the /dev/full device. The + /dev/full device is used mainly for testing how programs + respond to ENOSPC, and can be disabled on systems that will + never use it in production, such as many embedded systems. + When in doubt, say "Y". + config SGI_SNSC bool "SGI Altix system controller communication support" depends on (IA64_SGI_SN2 || IA64_GENERIC)
drivers/char/mem.c +6 -0
@@ -665,11 +665,13 @@ static int mmap_zero(struct file *file, struct vm_area_struct *vma) }#endif +#ifdef CONFIG_DEVFULL static ssize_t write_full (struct file *file,const char __user *buf,size_t count,loff_t *ppos) {return -ENOSPC ; } +#endif /* * Special lseek() function for /dev/null and /dev/zero. Most notably, you
@@ -791,12 +793,14 @@ static struct backing_dev_info zero_bdi = { };#endif +#ifdef CONFIG_DEVFULL static const struct file_operations full_fops = { .llseek = full_lseek, .read = new_sync_read, .read_iter = read_iter_zero, .write = write_full, }; +#endif static const struct memdev { const char *name;
@@ -819,7 +823,9 @@ static const struct memdev { #ifdef CONFIG_DEVZERO [5 ] = {"zero" ,0666 , &zero_fops, &zero_bdi }, #endif +#ifdef CONFIG_DEVFULL [7 ] = {"full" ,0666 , &full_fops,NULL }, +#endif [8] = { "random", 0666, &random_fops, NULL }, [9 ] = {"urandom" ,0666 , &urandom_fops,NULL }, #ifdef CONFIG_PRINTK
Signature · 1 line
1.9.3
PATCH 7/10 drivers/char: Support compiling out /dev/random
In reply to Tom ZanussiSome embedded systems with tightly controlled userspace have no use for /dev/random, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.
The newly marked __maybe_unused functions, random_write, random_ioctl, and random_fasync are shared between /dev/random and /dev/urandom, and will be compiled out if both devices are disabled.
bloat-o-meter (based on tinyconfig):
add/remove: 0/4 grow/shrink: 1/0 up/down: 139/-392 (-253)
function old new delta sys_getrandom 211 350 +139 random_read 20 - -20 random_poll 83 - -83 random_fops 116 - -116 _random_read.part 173 - -173
bloat-o-meter showing the difference between only CONFIG_DEVURANDOM off and both CONFIG_DEVURANDOM and CONFIG_DEVRANDOM off:
add/remove: 0/8 grow/shrink: 1/0 up/down: 144/-851 (-707)
function old new delta sys_getrandom 288 432 +144 random_fasync 16 - -16 random_read 20 - -20 random_write 42 - -42 write_pool 82 - -82 random_poll 83 - -83 random_fops 116 - -116 _random_read.part 173 - -173 random_ioctl 319 - -319
So we see the extra symbols drop, while _random_read is inlined into sys_getrandom.
--- drivers/char/Kconfig | 11 +++++++++++ drivers/char/mem.c | 2 ++ drivers/char/random.c | 16 ++++++++++++---- 3 files changed, 25 insertions(+), 4 deletions(-)
drivers/char/Kconfig +11 -0
@@ -67,6 +67,17 @@ config DEVFULL never use it in production, such as many embedded systems. When in doubt, say "Y". +config DEVRANDOM + bool "/dev/random virtual device support" if EMBEDDED + depends on DEVMEM_BASE + default y + help + Say Y here if you want to support the /dev/random + device. The /dev/random device is the blocking userspace + interface to the kernel random number generator, and can be + disabled on systems that will never use it in production, + such as many embedded systems. When in doubt, say "Y". + config SGI_SNSC bool "SGI Altix system controller communication support" depends on (IA64_SGI_SN2 || IA64_GENERIC)
drivers/char/mem.c +2 -0
@@ -826,7 +826,9 @@ static const struct memdev { #ifdef CONFIG_DEVFULL [7 ] = {"full" ,0666 , &full_fops,NULL }, #endif +#ifdef CONFIG_DEVRANDOM [8 ] = {"random" ,0666 , &random_fops,NULL }, +#endif [9] = { "urandom", 0666, &urandom_fops, NULL }, #ifdef CONFIG_PRINTK [11] = { "kmsg", 0644, &kmsg_fops, NULL },
drivers/char/random.c +12 -4
@@ -1370,11 +1370,13 @@ _random_read(int nonblock, char __user *buf, size_t nbytes) } } +#ifdef CONFIG_DEVRANDOM static ssize_t random_read (struct file *file,char __user *buf,size_t nbytes,loff_t *ppos) {return _random_read (file->f_flags &O_NONBLOCK , buf, nbytes); } +#endif static ssize_t urandom_read (struct file *file,char __user *buf,size_t nbytes,loff_t *ppos)
@@ -1394,6 +1396,7 @@ urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)return ret; } +#ifdef CONFIG_DEVRANDOM static unsigned int random_poll (struct file *file,poll_table * wait) {
@@ -1408,6 +1411,7 @@ random_poll(struct file *file, poll_table * wait) mask |=POLLOUT |POLLWRNORM ; return mask; } +#endif static int write_pool (struct entropy_store *r,const char __user *buffer,size_t count)
@@ -1431,8 +1435,9 @@ write_pool(struct entropy_store *r, const char __user *buffer, size_t count)return 0 ; } -static ssize_t random_write (struct file *file,const char __user *buffer, -size_t count,loff_t *ppos) +static ssize_t __maybe_unused random_write (struct file *file, +const char __user *buffer, +size_t count,loff_t *ppos) {size_t ret;
@@ -1446,7 +1451,8 @@ static ssize_t random_write(struct file *file, const char __user *buffer,return (ssize_t )count; } -static long random_ioctl (struct file *f,unsigned int cmd,unsigned long arg) +static long __maybe_unused random_ioctl (struct file *f,unsigned int cmd, +unsigned long arg) {int size, ent_count;int __user *p = (int __user *)arg;
@@ -1498,11 +1504,12 @@ static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg) } } -static int random_fasync (int fd,struct file *filp,int on) +static int __maybe_unused random_fasync (int fd,struct file *filp,int on) {return fasync_helper (fd, filp, on, &fasync); } +#ifdef CONFIG_DEVRANDOM const struct file_operations random_fops = { .read = random_read, .write = random_write,
@@ -1511,6 +1518,7 @@ const struct file_operations random_fops = { .fasync = random_fasync, .llseek = noop_llseek, }; +#endif const struct file_operations urandom_fops = { .read = urandom_read,
Signature · 1 line
1.9.3
PATCH 8/10 drivers/char: Support compiling out /dev/urandom
In reply to Tom ZanussiSome embedded systems with tightly controlled userspace have no use for /dev/urandom, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.
bloat-o-meter (based on tinyconfig):
add/remove: 0/2 grow/shrink: 1/0 up/down: 77/-212 (-135)
function old new delta sys_getrandom 211 288 +77
urandom_read 96 - -96urandom_fops 116 - -116
--- drivers/char/Kconfig | 11 +++++++++++ drivers/char/mem.c | 2 ++ drivers/char/random.c | 2 ++ 3 files changed, 15 insertions(+)
drivers/char/Kconfig +11 -0
@@ -78,6 +78,17 @@ config DEVRANDOM disabled on systems that will never use it in production, such as many embedded systems. When in doubt, say "Y". +config DEVURANDOM + bool "/dev/urandom virtual device support" if EMBEDDED + depends on DEVMEM_BASE + default y + help + Say Y here if you want to support the /dev/urandom + device. The /dev/urandom device is the nonblocking userspace + interface to the kernel random number generator, and can be + disabled on systems that will never use it in production, + such as many embedded systems. When in doubt, say "Y". + config SGI_SNSC bool "SGI Altix system controller communication support" depends on (IA64_SGI_SN2 || IA64_GENERIC)
drivers/char/mem.c +2 -0
@@ -829,7 +829,9 @@ static const struct memdev { #ifdef CONFIG_DEVRANDOM [8 ] = {"random" ,0666 , &random_fops,NULL }, #endif +#ifdef CONFIG_DEVURANDOM [9 ] = {"urandom" ,0666 , &urandom_fops,NULL }, +#endif #ifdef CONFIG_PRINTK [11] = { "kmsg", 0644, &kmsg_fops, NULL }, #endif
drivers/char/random.c +2 -0
@@ -1520,6 +1520,7 @@ const struct file_operations random_fops = { };#endif +#ifdef CONFIG_DEVURANDOM const struct file_operations urandom_fops = { .read = urandom_read, .write = random_write,
@@ -1527,6 +1528,7 @@ const struct file_operations urandom_fops = { .fasync = random_fasync, .llseek = noop_llseek, }; +#endif SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count, unsigned int, flags)
Signature · 1 line
1.9.3
PATCH 9/10 drivers/char: Support compiling out /dev/kmsg
In reply to Tom ZanussiSome embedded systems with tightly controlled userspace have no use for /dev/kmsg, and could benefit from the size savings gained by omitting it. Add a new EMBEDDED config option to disable it.
bloat-o-meter (based on tinyconfig):
add/remove: 0/8 grow/shrink: 1/1 up/down: 92/-1538 (-1446)
function old new delta
do_syslog 1027 1119 +92 devkmsg_release 15 - -15 devlist 192 160 -32 devkmsg_poll 97 - -97 devkmsg_open 112 - -112 check_syslog_permissions 114 - -114 kmsg_fops 116 - -116 devkmsg_llseek 144 - -144 devkmsg_write 209 - -209 devkmsg_read 699 - -699
--- drivers/char/Kconfig | 14 ++++++++++++++ drivers/char/mem.c | 2 +- kernel/printk/printk.c | 2 ++ 3 files changed, 17 insertions(+), 1 deletion(-)
drivers/char/Kconfig +14 -0
@@ -89,6 +89,20 @@ config DEVURANDOM disabled on systems that will never use it in production, such as many embedded systems. When in doubt, say "Y". +config DEVKMSG + bool "/dev/kmsg virtual device support" if EMBEDDED + depends on DEVMEM_BASE && PRINTK + default y + help + Say Y here if you want to support the /dev/kmsg device. The + /dev/kmsg device provides access to the raw kernel message + ring buffer, and can be disabled on systems that will never + use it in production, such as many embedded systems. The + kernel log buffer is also accessible via the syslog() kernel + interface and userspace tools such as dmesg (using -S) can + be directed to use that interface instead. When in doubt, + say "Y". + config SGI_SNSC bool "SGI Altix system controller communication support" depends on (IA64_SGI_SN2 || IA64_GENERIC)
drivers/char/mem.c +1 -1
@@ -832,7 +832,7 @@ static const struct memdev { #ifdef CONFIG_DEVURANDOM [9 ] = {"urandom" ,0666 , &urandom_fops,NULL }, #endif -#ifdef CONFIG_PRINTK +#ifdef CONFIG_DEVKMSG [11] = { "kmsg", 0644, &kmsg_fops, NULL }, #endif };
kernel/printk/printk.c +2 -0
@@ -505,6 +505,7 @@ int check_syslog_permissions(int type, bool from_file)return security_syslog (type); } +#ifdef CONFIG_DEVKMSG /* /dev/kmsg - userspace message inject/listen interface */ struct devkmsg_user {
@@ -797,6 +798,7 @@ const struct file_operations kmsg_fops = { .poll = devkmsg_poll, .release = devkmsg_release, }; +#endif #ifdef CONFIG_KEXEC /*
Signature · 1 line
1.9.3
PATCH 10/10 drivers/char: Support compiling out the getrandom(2) syscall
In reply to Tom ZanussiMany embedded systems have no use for getrandom, and could benefit from the size savings gained by omitting it. Add a new EXPERT config option, CONFIG_GETRANDOM_SYSCALL (default y), to support compiling it out.
The newly marked __maybe_unused _random_read is shared between getrandom(2) and /dev/random, and urandom_read is shared between getrandom(2) and /dev/urandom, and will be compiled out respectively if either devices and getrandom(2) are disabled.
bloat-o-meter (based on tinyconfig):
add/remove: 0/2 grow/shrink: 1/0 up/down: 163/-384 (-221)
function old new delta
random_read 20 183 +163 _random_read.part 173 - -173 sys_getrandom 211 - -211
Here, _random_read is inlined into random_read, which drops the cold part of the _random_read partial inline _random_read.part.
bloat-o-meter showing the difference between both CONFIG_DEVRANDOM and CONFIG_DEVURANDOM off and that plus CONFIG_GETRANDOM_SYSCALL off:
add/remove: 0/5 grow/shrink: 1/2 up/down: 332/-1038 (-706)
function old new delta extract_entropy 114 446 +332 __print_once 16 15 -1 mix_pool_bytes 17 14 -3 xfer_secondary_pool 60 - -60 extract_buf 164 - -164 account 181 - -181 extract_entropy_user 197 - -197 sys_getrandom 432 - -432
Here we see xfer_secondary_pool, extract_buf, and account inlined into extract_entropy, while extract_entropy_user from _random_read drops out because _random_read is dropped (random_read and _random_read.part drop out when only DEVRANDOM and DEVURANDOM are compiled out - _random_read is inlined into sys_getrandom in that case, which drops out when GETRANDOM_SYSCALL is disabled).
--- drivers/char/Kconfig | 13 +++++++++++++ drivers/char/random.c | 6 ++++-- kernel/sys_ni.c | 1 + 3 files changed, 18 insertions(+), 2 deletions(-)
drivers/char/Kconfig +13 -0
@@ -103,6 +103,19 @@ config DEVKMSG be directed to use that interface instead. When in doubt, say "Y". +config GETRANDOM_SYSCALL + bool "Enable getrandom(2) syscall" if EXPERT + default y + help + Say Y here if you want to enable the getrandom(2) syscall. + The getrandom(2) syscall provides a means to access the + kernel random number generator in cases where /dev/[u]random + is not available. It also adds optional blocking semantics + to the /dev/urandom entropy pool for programs that are + designed to use it. It can be disabled on systems that will + never use it in production, such as many embedded systems. + When in doubt, say "Y". + config SGI_SNSC bool "SGI Altix system controller communication support" depends on (IA64_SGI_SN2 || IA64_GENERIC)
drivers/char/random.c +4 -2
@@ -1339,7 +1339,7 @@ void rand_initialize_disk(struct gendisk *disk) }#endif -static ssize_t +static ssize_t __maybe_unused _random_read (int nonblock,char __user *buf,size_t nbytes) {ssize_t n;
@@ -1378,7 +1378,7 @@ random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos) }#endif -static ssize_t +static ssize_t __maybe_unused urandom_read (struct file *file,char __user *buf,size_t nbytes,loff_t *ppos) {int ret;
@@ -1530,6 +1530,7 @@ const struct file_operations urandom_fops = { };#endif +#ifdef CONFIG_GETRANDOM_SYSCALL SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count, unsigned int, flags) {
@@ -1552,6 +1553,7 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count, }return urandom_read (NULL , buf, count,NULL ); } +#endif /*************************************************************** * Random UUID interface
kernel/sys_ni.c +1 -0
@@ -159,6 +159,7 @@ cond_syscall(sys_uselib);cond_syscall (sys_fadvise64);cond_syscall (sys_fadvise64_64);cond_syscall (sys_madvise); +cond_syscall (sys_getrandom);/* arch-specific weak syscall entries */ cond_syscall (sys_pciconfig_read);
Signature · 1 line
1.9.3
Theodore Ts'o
maintainerRe: [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall
Quoted 4 lines · Tom Zanussi
Many embedded systems have no use for getrandom, and could benefit from the size savings gained by omitting it. Add a new EXPERT config option,
CONFIG_GETRANDOM_SYSCALL(default y), to support compiling it out.
I'm really not sure this is a good idea. Even the tiniest embedded device need secure crypto. In fact, one could argue that in the case of the Internet of Things, the tiniests embedded devices **especially** need secure crypto. It would be.... unfortunate.... if the next time North Korea gets upset at the Great Satan, that all of our light bulbs, refridgerators, cars, heating systems, etc., are subject to attack.
We know already that home routers are running ancient kernels that are absolutely no protection whatever. Is saving a few bytes really worth potentially opening up a similar attack vector on devices that will probably be at least an order of magnitude or more numerous than home routers, and even harder to upgrade once they get out there?
And if you don't have a good random number generator, you really are *toast*.
It's for this reason that /dev/[u]random were not eligible from being disabled from the very beginning; it's too much of an attractive nuisance to a clueless product manager....
- Ted
Re: [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall
Quoted 6 lines · Theodore Ts'o
Quoted 4 lines · Tom Zanussi
Many embedded systems have no use for getrandom, and could benefit from the size savings gained by omitting it. Add a new EXPERT config option,
CONFIG_GETRANDOM_SYSCALL(default y), to support compiling it out.
Quoted 8 lines
I'm really not sure this is a good idea. Even the tiniest embedded device need secure crypto. In fact, one could argue that in the case of the Internet of Things, the tiniests embedded devices **especially** need secure crypto. It would be.... unfortunate.... if the next time North Korea gets upset at the Great Satan, that all of our light bulbs, refridgerators, cars, heating systems, etc., are subject to attack.
Right, but not everything is networked - there are standalone embedded systems that could benefit from the savings. Anyway, it's not a huge savings so I could just remove them to avoid the temptation...
Tom.
Quoted 15 lines
We know already that home routers are running ancient kernels that are absolutely no protection whatever. Is saving a few bytes really worth potentially opening up a similar attack vector on devices that will probably be at least an order of magnitude or more numerous than home routers, and even harder to upgrade once they get out there?
And if you don't have a good random number generator, you really are *toast*.
It's for this reason that /dev/[u]random were not eligible from being disabled from the very beginning; it's too much of an attractive nuisance to a clueless product manager....
- Ted
Re: [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall
In reply to Theodore Ts'oQuoted 8 lines · Theodore Ts'o
Quoted 4 lines · Tom Zanussi
Many embedded systems have no use for getrandom, and could benefit from the size savings gained by omitting it. Add a new EXPERT config option,
CONFIG_GETRANDOM_SYSCALL(default y), to support compiling it out.I'm really not sure this is a good idea. Even the tiniest embedded device need secure crypto.
[...]
Quoted 6 lines
We know already that home routers are running ancient kernels that are absolutely no protection whatever. Is saving a few bytes really worth potentially opening up a similar attack vector on devices that will probably be at least an order of magnitude or more numerous than home routers, and even harder to upgrade once they get out there?
Quoted 6 lines
And if you don't have a good random number generator, you really are *toast*.
It's for this reason that /dev/[u]random were not eligible from being disabled from the very beginning; it's too much of an attractive nuisance to a clueless product manager....
Forcing the availability of the random devices and getrandom syscall will not force userspace to actually *use* them, and there do exist real devices that do not need them.
We're not yet talking about the full in-kernel entropy infrastructure, which should also be removable *if* you aren't using it for CONFIG_NET or similar. We're talking about the userspace interfaces. If you aren't running any userspace bits that open /dev/*random or that call getrandom, forcing the existence of those devices will not magically make the system more secure. Not all userspaces actually need randomness, and some of those that do have better alternatives than /dev/*random or getrandom (such as hardware RNGs).
- Josh Triplett