This patch is similiar to commit e795b9011 (RISC-V: Add libgcc helpers
for clz) but for MIPS target.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
In addition to what was already there, Gnulib's <intprops.h> needs SCHAR_MIN,
SCHAR_MAX, SHRT_MIN, INT_MIN, LONG_MIN, and LONG_MAX. Fixes build on CentOS 7.
Reported-by: "Chen, Farrah" <farrah.chen@intel.com>
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Even though we were parsing some DHCP options sent by the server, so far
we are only using the BOOTP 2-way handshake, even when talking to a DHCP
server.
Change this by actually sending out DHCP DISCOVER packets instead of the
generic (mostly empty) BOOTP BOOTREQUEST packets.
A pure BOOTP server would ignore the extra DHCP options in the DISCOVER
packet and would just reply with a BOOTREPLY packet, which we also
handle in the code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In respone to a BOOTREQUEST packet a BOOTP server would answer with a BOOTREPLY
packet, which ends the conversation for good. DHCP uses a 4-way handshake,
where the initial server respone is an OFFER, which has to be answered with
REQUEST by the client again, only to be completed by an ACKNOWLEDGE packet
from the server.
Teach the grub_net_process_dhcp() function to deal with OFFER packets,
and treat ACK packets the same es BOOTREPLY packets.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The BOOTP RFC describes the boot file name and the server name as being part
of the integral BOOTP data structure, with some limits on the size of them.
DHCP extends this by allowing them to be separate DHCP options, which is more
flexible.
Teach the code dealing with those fields to check for those DHCP options first
and use this information, if provided. We fall back to using the BOOTP
information if those options are not used.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently we have a global timeout for all network cards in the BOOTP/DHCP
discovery process.
Make this timeout a per-interface one, so better accommodate the upcoming
4-way DHCP handshake and to also cover the lease time limit a DHCP offer
will come with.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Change the interface of the function dealing with incoming BOOTP packets
to take an interface instead of a card, to allow more fine per-interface
state (timeout, handshake state) later on.
Use the opportunity to clean up the code a bit.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
DHCP specifies a special dummy option OVERLOAD, to allow DHCP options to
spill over into the (legacy) BOOTFILE and SNAME fields.
Parse and handle this option properly.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In order to be able to read from and write to model-specific registers,
two new modules are added. They are i386 specific, as the cpuid module.
rdmsr module registers the command rdmsr that allows reading from a MSR.
wrmsr module registers the command wrmsr that allows writing to a MSR.
wrmsr module is disabled if UEFI secure boot is enabled.
Please note that on SMP systems, interacting with a MSR that has a scope
per hardware thread, implies that the value only applies to the
particular cpu/core/thread that ran the command.
Also, if you specify a reserved or unimplemented MSR address, it will
cause a general protection exception (which is not currently being
handled) and the system will reboot.
Signed-off-by: Jesús Diéguez Fernández <jesusdf@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In order to maintain the coding style consistency, it was requested to
replace the methods that use "__asm__ __volatile__" with "asm volatile".
Signed-off-by: Jesús Diéguez Fernández <jesusdf@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add a new disk driver called obdisk for IEEE1275 platforms. Currently
the only platform using this disk driver is SPARC, however other IEEE1275
platforms could start using it if they so choose. While the functionality
within the current IEEE1275 ofdisk driver may be suitable for PPC and x86, it
presented too many problems on SPARC hardware.
Within the old ofdisk, there is not a way to determine the true canonical
name for the disk. Within Open Boot, the same disk can have multiple names
but all reference the same disk. For example the same disk can be referenced
by its SAS WWN, using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@w5000cca02f037d6d,0
It can also be referenced by its PHY identifier using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@p0
It can also be referenced by its Target identifier using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@0
Also, when the LUN=0, it is legal to omit the ,0 from the device name. So with
the disk above, before taking into account the device aliases, there are 6 ways
to reference the same disk.
Then it is possible to have 0 .. n device aliases all representing the same disk.
Within this new driver the true canonical name is determined using the the
IEEE1275 encode-unit and decode-unit commands when address_cells == 4. This
will determine the true single canonical name for the device so multiple ihandles
are not opened for the same device. This is what frequently happens with the old
ofdisk driver. With some devices when they are opened multiple times it causes
the entire system to hang.
Another problem solved with this driver is devices that do not have a device
alias can be booted and used within GRUB. Within the old ofdisk, this was not
possible, unless it was the original boot device. All devices behind a SAS
or SCSI parent can be found. Within the old ofdisk, finding these disks
relied on there being an alias defined. The alias requirement is not
necessary with this new driver. It can also find devices behind a parent
after they have been hot-plugged. This is something that is not possible
with the old ofdisk driver.
The old ofdisk driver also incorrectly assumes that the device pointing to by a
device alias is in its true canonical form. This assumption is never made with
this new driver.
Another issue solved with this driver is that it properly caches the ihandle
for all open devices. The old ofdisk tries to do this by caching the last
opened ihandle. However this does not work properly because the layer above
does not use a consistent device name for the same disk when calling into the
driver. This is because the upper layer uses the bootpath value returned within
/chosen, other times it uses the device alias, and other times it uses the
value within grub.cfg. It does not have a way to figure out that these devices
are the same disk. This is not a problem with this new driver.
Due to the way GRUB repeatedly opens and closes the same disk. Caching the
ihandle is important on SPARC. Without caching, some SAS devices can take
15 - 20 minutes to get to the GRUB menu. This ihandle caching is not possible
without correctly having the canonical disk name.
When available, this driver also tries to use the deblocker #blocks and
a way of determining the disk size.
Finally and probably most importantly, this new driver is also capable of
seeing all partitions on a GPT disk. With the old driver, the GPT
partition table can not be read and only the first partition on the disk
can be seen.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Many of GRUB's utilities don't check anywhere near all the possible
write errors. For example, if grub-install runs out of space when
copying a file, it won't notice. There were missing checks for the
return values of write, fflush, fsync, and close (or the equivalents on
other OSes), all of which must be checked.
I tried to be consistent with the existing logging practices of the
various hostdisk implementations, but they weren't entirely consistent
to start with so I used my judgement. The result at least looks
reasonable on GNU/Linux when I provoke a write error:
Installing for x86_64-efi platform.
grub-install: error: cannot copy `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' to `/boot/efi/EFI/debian/grubx64.efi': No space left on device.
There are more missing checks in other utilities, but this should fix
the most critical ones.
Fixes Debian bug #922741.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Much like on x86, we can work out if the system is running on top of EFI
firmware. If so, return "arm-efi". If not, fall back to "arm-uboot" as
previously.
Split out the code to (maybe) load the efivar module and check for
/sys/firmware/efi into a common helper routine is_efi_system().
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This reverts commit 082fd84d52.
Incorrect version of the patch was pushed into the git repo.
Reported-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Much like on x86, we can work out if the system is running on top
of EFI firmware. If so, return "arm-efi". If not, fall back to
"arm-uboot" as previously.
Heavily inspired by the existing code for x86.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We now have signature check logic in grub which allows us to treat
files differently depending on their file type.
Treat a loaded device tree like an overlayed ACPI table.
Both describe hardware, so I suppose their threat level is the same.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
This patch adds support for RISC-V to the grub build system. With this
patch, I can successfully build grub on RISC-V as a UEFI application.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Gcc may decide it wants to call helper functions to execute clz. Provide
them in our own copy of libgcc.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To support a new architecture we need to provide a few helper functions
for memory, cache, timer, etc support.
This patch adds the remainders of those. Some bits are still disabled,
as I couldn't guarantee that we're always running on models / in modes
where the respective hardware is available.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds awareness of RISC-V relocations throughout the grub tools
as well as dynamic linkage and elf->PE relocation conversion support.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We currently only support to run grub on RISC-V as UEFI payload. Ideally,
we also only want to support running Linux underneath as UEFI payload.
Prepare that with some Linux boot stub code. Once the arm64 target is
generalized, we can hook into that one and gain boot functionality.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds a 32/64 capable setjmp implementation for RISC-V.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The RISC-V ABI document outlines ELF header structure and relocation
information. Pull the respective magic numbers into our elf header
so we can make use of them.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The PE format defines magic numbers as well as relocation identifiers for
RISC-V. Add them to our include file, so we can make use of them.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some architectures want to boot Linux as plain UEFI binary. Today that
really only encompasses ARM and AArch64, but going forward more
architectures may adopt that model.
So rename our internal API accordingly.
Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There is UEFI firmware popping up in the wild now that implements stricter
permission checks using NX and write protect page table entry bits.
This means that firmware now may fail to load binaries if its individual
sections are not page aligned, as otherwise it can not ensure permission
boundaries.
So let's bump all efi section alignments up to 4k (EFI page size). That way
we will stay compatible going forward.
Unfortunately our internals can't deal very well with a mismatch of alignment
between the virtual and file offsets, so we have to also pad our target
binary a bit.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Julien ROBIN <julien.robin28@free.fr>
This patch allows to have bigger kernels. If the kernel grows, then it will
overwrite the initrd when it is extracted.
Signed-off-by: Guillaume GARDET <guillaume.gardet@arm.com>
Acked-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A certain amount of dynamic space is required for the handover from
GRUB/Linux-EFI-stub. This entails things like initrd addresses,
address-cells entries and associated strings.
But move this into a proper centralised #define rather than live-code
it in the loader.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
uboot_disk_write() is currently lacking the write support
to storage devices because, historically, those devices did not
implement block_write() in U-Boot.
The solution has been tested using a patched U-Boot loading
and booting GRUB in a QEMU vexpress-a9 environment.
The disk write operations were triggered with GRUB's save_env
command.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add support for performing basic TPM measurements. Right now this only
supports extending PCRs statically and only on UEFI. In future we might
want to have some sort of mechanism for choosing which events get logged
to which PCRs, but this seems like a good default policy and we can wait
to see whether anyone has a use case before adding more complexity.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Pass all commands executed by GRUB to the verifiers layer. Most verifiers will
ignore this, but some (such as the TPM verifier) want to be able to measure and
log each command executed in order to ensure that the boot state is as expected.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add xen_pvh support to grub-install.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Support mkimage for xen_pvh.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Add the needed code to setup the hypercall page for calling into the
Xen hypervisor.
Import the XEN_HVM_DEBUGCONS_IOPORT define from Xen unstable into
include/xen/arch-x86/xen.h
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Add the hooks to current code needed for Xen PVH. They will be filled
with code later when the related functionality is being added.
loader/i386/linux.c needs to include machine/kernel.h now as it needs
to get GRUB_KERNEL_USE_RSDP_ADDR from there. This in turn requires to
add an empty kernel.h header for some i386 platforms (efi, coreboot,
ieee1275, xen) and for x86_64 efi.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
include/grub/offsets.h needs some defines for Xen PVH mode.
Add them. While at it line up the values in the surrounding lines to
start at the same column.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
With Xen PVH mode adding a new machine type the machine related headers
need to be present for the build to succeed. Most of the headers just
need to include the related common i386 headers. Add those to the tree.
Note that xen_pvh/int.h needs to include pc/int_types.h instead of
pc/int.h in order to avoid the definition of grub_bios_interrupt().
xen_pvh/memory.h needs to include coreboot/memory.h (like some other
<machine>/memory.h do as well) as this contains just the needed stubs.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Some common code needs to be special cased for Xen PVH mode. This hits
mostly Xen PV mode specific areas.
Split include/grub/i386/pc/int_types.h off from
include/grub/i386/pc/int.h to support including this file later from
xen_pvh code without the grub_bios_interrupt definition.
Move definition of struct grub_e820_mmap_entry from
grub-core/mmap/i386/pc/mmap.c to include/grub/i386/memory.h in order
to make it usable from xen_pvh code.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Xen PVH guests will have the RSDP at an arbitrary address. Support that
by passing the RSDP address via the boot parameters to Linux.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
In order to support grub2 in Xen PVH environment some additional Xen
headers are needed as grub2 will be started in PVH mode requiring to
use several HVM hypercalls and structures.
Add the needed headers from Xen 4.10 being the first Xen version with
full (not only experimental) PVH guest support.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
ARM Xen fallout cleanup after commit ca0a4f689 (verifiers: File type for
fine-grained signature-verification controlling).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
An error emerged as when I was testing the verifiers branch, so instead
of putting it in pgp prefix, the verifiers is used to reflect what the
patch is based on.
While running verify_detached, grub aborts with error.
verify_detached /@/.snapshots/1/snapshot/boot/grub/grub.cfg
/@/.snapshots/1/snapshot/boot/grub/grub.cfg.sig
alloc magic is broken at 0x7beea660: 0
Aborted. Press any key to exit.
The error is caused by sig file descriptor been closed twice, first time
in grub_verify_signature() to which it is passed as parameter. Second in
grub_cmd_verify_signature() or in whichever opens the sig file
descriptor. The second close is not consider as bug to me either, as in
common rule of what opens a file has to close it to avoid file
descriptor leakage.
After all the design of grub_verify_signature() makes it difficult to keep
a good trace on opened file descriptor from it's caller. Let's refine
the application interface to accept file path rather than descriptor, in
this way the caller doesn't have to care about closing the descriptor by
delegating it to grub_verify_signature() with full tracing to opened
file descriptor by itself.
Also making it clear that sig descriptor is not referenced in error
returning path of grub_verify_signature_init(), so it can be closed
directly by it's caller. This also makes delegating it to
grub_pubkey_close() infeasible to help in relieving file descriptor
leakage as it has to depend on uncertainty of ctxt fields in error
returning path.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The API change of grub_file_open() for adding verifiers did not include
a type for device tree blobs. Add GRUB_FILE_TYPE_DEVICE_TREE_IMAGE to
the grub_file_type enum.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
verify.h was added without include guards. This means compiling anything
including both include/grub/verify.h and include/grub/lib/cmdline.h fails
(at least grub-core/loader/arm64/linux.c.
Add the necessary include guard.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This type of modules cannot be unloaded. This is useful if a given
functionality, e.g. UEFI secure boot shim signature verification, should
not be disabled if it was enabled at some point in time. Somebody may
say that we can use standalone GRUB2 here. That is true. However, the
code is not so big nor complicated hence it make sense to support
modularized configs too.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
This way if a verifier requires verification of a given file it can defer task
to another verifier (another authority) if it is not able to do it itself. E.g.
shim_lock verifier, posted as a subsequent patch, is able to verify only PE
files. This means that it is not able to verify any of GRUB2 modules which have
to be trusted on UEFI systems with secure boot enabled. So, it can defer
verification to other verifier, e.g. PGP one.
I silently assume that other verifiers are trusted and will do good job for us.
Or at least they will not do any harm.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Verifiers framework provides core file verification functionality which
can be used by various security mechanisms, e.g., UEFI secure boot, TPM,
PGP signature verification, etc.
The patch contains PGP code changes and probably they should be extracted
to separate patch for the sake of clarity.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Let's provide file type info to the I/O layer. This way verifiers
framework and its users will be able to differentiate files and verify
only required ones.
This is preparatory patch.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
