The --buffer command line option was passed to setvbuf(3).
Computers are fast enough and libc is good enough that
we realistically do not need this.
Hostboot's buildpnor.pl would pass --buffer 0x40000000
which resulted in a malloc(2GB), which would fail on systems
with less than 2GB of memory because sometimes
libc and the kernel are sane.
So, we keep the command line option for backwards compatibility
but completely ignore it.
In the few places where it was used to allocate a buffer to do
work in (and this was via a rather round-about way), we instead
just allocate something the size of the PNOR image.
Fixes: https://github.com/open-power/ffs/issues/7
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Without this commit , the size of the Table of Contents noted by
ffs_hdr->size was getting defaulted to 4kb (1 hostboot pagesize)
There should be no limitation on the size of the toc, but this
size was not getting incremented if there were enough entries to
push the size of the toc over 4kb. This commit adds logic to
increate the ffs_hdr->size as well as the "part" ffs_entries's size
as we add entries to the ffs_hdr
When running the fpart test suite under valgrind, you can see that it
writes unitialized data to disk (pnor) in the very first test:
./fpart/fpart --target /tmp/create.nor --size 64MiB --block 64kb \
--partition-offset 0x7f0000 --create
This is because libffs.c doesn't properly initialize the reserved area.
Thus, it could contain any old crap sitting around in memory,
essentially making the reserved fields useless.
Somebody will need to audit *EVERY* libffs created thing in the wild
before ever using that reserved space.
==8261== Syscall param write(buf) points to uninitialised byte(s)
==8261== at 0x4F27C20: __write_nocancel (syscall-template.S:84)
==8261== by 0x4EAE1DE: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1263)
==8261== by 0x4EAF978: new_do_write (fileops.c:518)
==8261== by 0x4EAF978: _IO_do_write@@GLIBC_2.2.5 (fileops.c:494)
==8261== by 0x4EAD9DF: _IO_file_sync@@GLIBC_2.2.5 (fileops.c:874)
==8261== by 0x4EA2FEE: fflush (iofflush.c:41)
==8261== by 0x406D31: ffs_flush (libffs.c:635)
==8261== by 0x408304: __ffs_fclose (libffs.c:718)
==8261== by 0x4032D9: __cleanup_ffs (cmd_create.c:108)
==8261== by 0x4032D9: create.5128 (cmd_create.c:108)
==8261== by 0x4056D2: command (command.c:229)
==8261== by 0x403400: command_create (cmd_create.c:118)
==8261== by 0x4018F8: process_args (main.c:431)
==8261== by 0x4018F8: main (main.c:565)
==8261== Address 0x402201c is in a rw- anonymous segment
Fixes: https://github.com/open-power/ffs/issues/11
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Stewart Smith