Bug#636266: libc6: fread() reads more than specified number of bytes

2011-08-02 Thread Philipp Marek 
On Tuesday 02 August 2011, Jonathan Nieder wrote:
> Not sure what libc can do about that.  Maybe the kernel could say,
> "Please, do not buffer when reading this file" and libc could respect
> that.  But fundamentally, buffering is what fread is all about,
...
> In the C and POSIX standards, the behavior of fread is defined in
> terms of fgetc.  To be reasonably fast and decrease the number of
> system calls, traditionally fgetc attempts to fill a large buffer
> when it calls read().  Should fread behave differently?  I would find
> it strange for fread(1, 1) to use a different sequence of system calls
> from fgetc.

Well, how about this: fopen() already seems to do an fstat(), and so it 
should easily see that this is neither a file nor a block device (and store 
that in the FILE somewhere).

I think that on sockets, pipes, character devices, and similar there should 
be _no_ readahead.


Regards,

Phil



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201108030833.01525.philipp.ma...@linbit.com

Bug#636266: libc6: fread() reads more than specified number of bytes

2011-08-02 Thread Jonathan Nieder 
# complex
severity 636266 wishlist
retitle 636266 libc6: fread(buf, 1, 1) from urandom consumes 4096 bytes of 
entropy
tags 636266 + upstream
quit

Hi Philipp,

Ph. Marek wrote:

> fopen()/fread() is used by some software packages (I noticed it via ECL) to
> read data from /dev/urandom.
>
> But fread() reads more bytes than specified (rounded up to 4096!), thereby
> decreasing the available entropy by a large amount.

Not sure what libc can do about that.  Maybe the kernel could say,
"Please, do not buffer when reading this file" and libc could respect
that.  But fundamentally, buffering is what fread is all about, so as
a first step I would suggest reporting the bug to the authors of each
program you find this in (after all, the same symptoms show up on
other platforms, too).

In the C and POSIX standards, the behavior of fread is defined in
terms of fgetc.  To be reasonably fast and decrease the number of
system calls, traditionally fgetc attempts to fill a large buffer
when it calls read().  Should fread behave differently?  I would find
it strange for fread(1, 1) to use a different sequence of system calls
from fgetc.

Anyway, I agree that this is a problem somewhere.  Thanks for
reporting it.  Ideas welcome.

Regards,
Jonathan

Meanwhile Linux suffers for the lack of erandom and frandom for
typical uses of random numbers, though that's another story.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110802141615.GB3397@elie

Bug#636266: libc6: fread() reads more than specified number of bytes

2011-08-01 Thread Ph. Marek 
Package: libc6
Version: 2.13-10
Severity: normal

fopen()/fread() is used by some software packages (I noticed it via ECL) to
read data from /dev/urandom.

But fread() reads more bytes than specified (rounded up to 4096!), thereby
decreasing the available entropy by a large amount.


To test, compile this program:
#include 
void main()
{
FILE *fh;

fh = fopen("/dev/urandom", "r");
fread(&fh, 1, 1, fh);
}

and run via strace:

...
brk(0x1e64000)  = 0x1e64000
open("/dev/urandom", O_RDONLY)  = 3
fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x768dbb60) = -1 EINVAL
(Invalid argument)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fac45b34000
read(3, "\242\261\204\215\221\313\253#\336\355\336u\37\3Gl\374
\332\301\271\363Z\327\7@.ziU\324\305"..., 4096) = 4096


This is a bug IMO; with urandom it discards a lot of entropy, and with random
it might cause hangs.



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.13-10Embedded GNU C Library: Binaries
ii  libgcc1   1:4.6.1-4  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0] 1.5.40 Debian configuration management sy
pn  glibc-doc  (no description available)
ii  locales   2.13-10Embedded GNU C Library: National L

-- debconf information:
* glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: ssh postfix openbsd-inetd cups cron atd apache2



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110801204809.23586.66023.reportbug@cacao