Per definition vsprint assumes that the provided buffer it writes to is
large enough to contain the formatted string. As printf uses a fixed
sized buffer (81 bytes) and has no size checks the use of vsprintf can
easily cause buffer overflows. Protect against these buffer overflows by
using vsnprintf instead.
While at it fix a typo in the comment.
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The zipl boot loaders have their own minimalistic libc implementation.
In it printf and sprintf use vsprintf for string formatting. Per
definition vsprintf assumes that the buffer it writes to is large enough
to contain the formatted string and performs no size checks. This is
problematic for the boot loaders because the buffer they use are often
allocated on the stack. Thus even small changes to the string format can
potentially cause buffer overflows on the stack with the well known
consequences. Protect against such errors by implementing vsnprintf.
Later patches will make use of it.
This implementation of vsnprintf only supports a small subset of format
options defined in the C standard. In particular it allows the
specifiers:
* %s (strings)
* %o (unsigned int octal)
* %u (unsigned int decimal)
* %x (unsigned int hexadecimal)
Integer specifiers (o, u, and x) always use the long form, i.e. assume the
argument to be of type 'unsigned long int'. The length modified 'l' can
be given but is ignored.
Furthermore, it is possible to provide the optional field width (aligned
to the right only) and precision as decimal integer (i.e. not via '*')
as well as the flag for zero padding integers (i.e. '0').
The implementation was heavily inspired by the implementation in
lib/vsprintf.c from the Linux kernel tree.
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The binary Linux kernel image is built to be loaded to memory address
0x0 but the first 64 kbyte contain an IPL header that is not used for
disk IPL. zIPL strips away this IPL header when writing IPL records to
disk, loads the remaining data to memory address 0x10000 and uses the
memory area below that for its own boot loader code.
The Secure Boot firmware feature checks the integrity of an installed
image during IPL using a checksum that was generated for the full image.
Since the checksum becomes invalid if the IPL header is removed, zIPL
must be changed to write the full image to disk.
This patch modifies the zIPL logic to no longer strip away the IPL
header. Instead the full image is loaded to a higher memory address and
relocated by the stage 3 boot loader code to its final location.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The program check handler has a bug in calculating the address of the target
to jump to. Furthermore the use of relative addresses in the exception table
can lead to situations where the (calculated) fault is not unique. Storing
the absolute address of the fault and target in the exception table solves
both problems.
This patch is intended to:
- Modify exception table to store the absolute address of 'fault' and
'target' points
- Adjust program check handler function pgm_check_handler_fn() accordingly
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.vnet.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This commit is based on the s390-tools-1.39.0 version.
Changes on top of s390-tools-1.39.0:
- Add MIT license to all source files
- Add LICENSE file
- Transform REAMDE to README.md (markdown)
- Add AUTHORS.md file
- Add CONTRIBUTING.md file
- Move changelog from README to CHANGELOG.md file
Reviewed-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Philipp Rudo