In LzmaEnc_CodeOneBlock(), both GetOptimumFast() and GetOptimum()
returns a value of greater or equal to 1, which is assigned to
"len". But since LZMA_MATCH_LEN_MIN == 2, "len" should be validated
before performing "len - LZMA_MATCH_LEN_MIN" to avoid underflow
when "len" equals to 1.
Fixes: CID 51508
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
The potential overflow issue arises at "size += ret;" because "size"
is of type ssize_t (signed) while "len" is size_t (unsigned). Repeatedly
adding read sizes, "ret", to "size" can potentially exceed the maximum
value of ssize_t, causing it to overflow into a negative or incorrect value.
The fix is to ensure "len" is within the range of SSIZE_MAX.
Fixes: CID 473850
Fixes: CID 473863
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Similarly to Intel IMSM, there are BIOS and UEFI implementations that
support DDF containers natively.
DDF and IMSM are very similar in handling, especially these should not
be considered as RAID abstraction. This fixes the requirement of having
a device map when probing DDF containers.
Fixes: https://issues.redhat.com/browse/RHEL-44336
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Avoid attempting to defererence a NULL pointer to call read_symlink() when
the given filesystem does not provide a read_symlink() function. This could
be triggered if the calling filesystem had a file marked as a symlink.
This appears possible for HFS and was observed during fuzzing of NTFS.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct several infinite loops/hangs found during fuzzing. The issues
fixed here could occur if certain specific malformed NTFS file systems
were presented to GRUB. Currently, GRUB does not allow NTFS file system
access when lockdown mode is enforced, so these should be of minimal
impact.
The changes made in this commit generally correct issues such as attempting
to iterate through a buffer using a length read from the NTFS file system
without confirming the length is larger than 0.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct several memory access violations found during fuzzing.
The issues fixed here could occur if certain specific malformed NTFS
file systems were presented to GRUB. Currently, GRUB does not allow NTFS
file system access when lockdown mode is enforced, so these should be of
minimal impact.
The changes made in this commit generally correct issues where pointers
into data buffers were being calculated using lengths read from the
NTFS file system without sufficient bounds/sanity checking; or
attempting to access elements of a structure to free them, when the
structure pointer is NULL.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct ntfs_test test failures around attempting to validate attribute
list entries as attributes. The NTFS code uses common logic in some
places to parse both attributes and attribute_lists which complicates
validation. Attribute lists contain different headers including a
different size of the length field (2 bytes) at offset 4 instead of the
4 byte length field used in attributes at offset 4. There are other
differences as well, but attempting to validate attribute list types
using attribute header validation was causing failure of the NTFS test
suite. This change restores some of the validation logic which may be
shared between attributes and attribute lists to be closer to the
original logic prior to fixes for previous CVEs. A following commit will
address some of the implications of removing this validation logic by
correcting some fuzzer failures (some which are exposed by removing the
validation in some of the cases).
Fixes: 067b6d225 (fs/ntfs: Implement attribute verification)
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct ntfs_test test failures around attempting to validate attribute
run list values. The calculation was incorrect for the "curr" variable.
With previous calculation, some file systems would fail validation
despite being well-formed and valid. This was caused by incrementing
"curr" by min_size which included both the (already accounted for)
min_size as well as the size of the run list. Correct by making a new
variable "run_size" to denote the current run list size to increment
both "curr" and "min_size" separately.
Fixes: 067b6d225 (fs/ntfs: Implement attribute verification)
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Environment files may contain empty lines, which should be ignored
during parsing. Currently, these lines are not skipped and resulting in
incorrect behavior. This patch adds a check to skip empty lines along
with those starting with "#".
Signed-off-by: Shreenidhi Shedi <shreenidhi.shedi@broadcom.com>
Reviewed-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit b66c6f918 (fs/zfs: Fix a number of memory leaks in ZFS code)
fixes many of the same leaks detected in bug #63846 except one, which
is fixed here.
Fixes: https://savannah.gnu.org/bugs/?63846
Fixes: b66c6f918 (fs/zfs: Fix a number of memory leaks in ZFS code)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Those tests fail depending on the version of unifont. As we don't distribute
our own unifont it fails for most users. Disable them so that they don't mask
real failures. They can be reinstated once we solve unifont problem.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The option can be used to suppress output if we only want to test the
return value of the command.
Also, mention this option in the documentation.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Switching to another EFI boot application while there are secrets in
RAM is dangerous, because not all firmware is wiping memory on free.
To reduce the attack surface, wipe the passphrase acquired when
unlocking an encrypted volume.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit adds the grub_cryptodisk_erasesecrets() function to wipe
master keys from all cryptodisks. This function is EFI-only.
Since there is no easy way to "force unmount" a given encrypted disk,
this function renders all mounted cryptodisks unusable. An attempt to
read them will return garbage.
This is why this function must be used in "no way back" conditions.
Currently, it is used when unloading the cryptodisk module and when
performing the "exit" command (it is often used to switch to the next
EFI application). This function is not called when performing the
"chainloader" command, because the callee may return to GRUB. For this
reason, users are encouraged to use "exit" instead of "chainloader" to
execute third-party boot applications.
This function does not guarantee that all secrets are wiped from RAM.
Console output, chunks from disk read requests and other may remain.
This function does not clear the IV prefix and rekey key for geli disks.
Also, this commit adds the relevant documentation improvements.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When the --cryptodisk-only argument is given, also check the target
device using the "cryptocheck" command, if available.
This extends the checks to common layouts like LVM-on-LUKS, so the
--cryptodisk-only argument transparently handles such setups.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This command examines a given diskfilter device, e.g., an LVM disk,
and checks if underlying disks, physical volumes, are cryptodisks,
e.g., LUKS disks, this layout is called "LVM-on-LUKS".
The return value is 0 when all underlying disks (of a given device)
are cryptodisks (1 if at least one disk is unencrypted or in an
unknown state).
Users are encouraged to include the relevant check before loading
anything from an LVM disk that is supposed to be encrypted.
This further supports the CLI authentication, blocking bypass
attempts when booting from an encrypted LVM disk.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This allows users to restrict the "search" command's scope to
encrypted disks only.
Typically, this command is used to "rebase" $root and $prefix
before loading additional configuration files via "source" or
"configfile". Unfortunately, this leads to security problems,
like CVE-2023-4001, when an unexpected, attacker-controlled
device is chosen by the "search" command.
The --cryptodisk-only argument allows users to ensure that the
file system picked is encrypted.
This feature supports the CLI authentication, blocking bypass
attempts.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This further mitigates potential misuse of the CLI after the
root device has been successfully unlocked via TPM.
Fixes: CVE-2025-4382
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When large extent counter / NREXT64 support was added to GRUB, it missed
a couple of direct reads of nextents which need to be changed to the new
NREXT64-aware helper as well. Without this, we'll have mis-reads of some
directories with this feature enabled.
The large extent counter fix likely raced on merge with commit 07318ee7e
(fs/xfs: Fix XFS directory extent parsing) which added the new direct
nextents reads just prior, causing this issue.
Fixes: aa7c1322671e (fs/xfs: Add large extent counters incompat feature support)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Jon DeVree <nuxi@vault24.org>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The code goes on to allocate memory in another region on failure, hence
it should discard the error.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Other platforms specify license in platform-specific files but corresponding
code for emu is in kernel, so datetime ends up without license section.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Previously, NV index mode only supported persistent handles which are
only for TPM objects.
On the other hand, the "NV index" handle allows the user-defined data,
so it can be an alternative to the key file and support TPM 2.0 Key
File format immediately.
The following tpm2-tools commands store the given key file, sealed.tpm,
in either TPM 2.0 Key File format or the raw format into the NV index
handle 0x1000000.
# tpm2_nvdefine -C o \
-a "ownerread|ownerwrite" \
-s $(stat -c %s sealed.tpm) \
0x1000000
# tpm2_nvwrite -C o -i sealed.tpm 0x1000000
To unseal the key in GRUB, add the "tpm2_key_protector_init" command to
grub.cfg:
tpm2_key_protector_init --mode=nv --nvindex=0x1000000
cryptomount -u <UUID> --protector tpm2
To remove the NV index handle:
# tpm2_nvundefine -C o 0x1000000
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Extract the logic to handle the file buffer from the SRK recover
function to prepare to load the sealed key from the NV index handle,
so the NV index mode can share the same code path in the later patch.
The SRK recover function now only reads the file and sends the file
buffer to the new function.
Besides this, to avoid introducing more options for the NV index mode,
the file format is detected automatically before unmarshaling the data,
so there is no need to use the command option to specify the file format
anymore. In other words, "-T" and "-k" are the same now.
Also update grub.text to address the change.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following TPM 2.0 commands are introduced to tss2 to access the
TPM non-volatile memory associated with the NV index handles:
- TPM2_NV_DefineSpace,
- TPM2_NV_UndefineSpace,
- TPM2_NV_ReadPublic,
- TPM2_NV_Read,
- TPM2_NV_Write.
The related marshal/unmarshal functions are also introduced.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_tpm2_readpublic() and grub_tpm2_testparms() didn't check
authCommand when marshaling the input data buffer. Currently, there is
no caller using non-NULL authCommand. However, to avoid the potential
issue, the conditional check is added to insert authCommand into the
input buffer if necessary.
Also fix a few pointer checks.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The user may need to inspect the TPM 2.0 PCR values with the GRUB shell,
so the new tpm2_dump_pcr command is added to print all PCRs of the
specified bank.
Also update the document for the new command.
Signed-off-by: Gary Lin <glin@suse.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
PCR mismatch is one common cause of TPM key unsealing fail. Since the
system may be compromised, it is not safe to boot into OS to get the PCR
values and TPM eventlog for the further investigation.
To provide some hints, GRUB now dumps PCRs on policy fail, so the user
can check the current PCR values. PCR 0~15 are chosen to cover the
firmware, bootloader, and OS.
The sample output:
PCR Mismatch! Check firmware and bootloader before typing passphrase!
TPM PCR [sha256]:
00: 17401f37710984c1d8a03a81fff3ab567ae9291bac61e21715b890ee28879738
01: 7a114329ba388445a96e8db2a072785937c1b7a8803ed7cc682b87f3ff3dd7a8
02: 11c2776849e8e24b7d80c926cbc4257871bffa744dadfefd3ed049ce25143e05
03: 6c33b362073e28e30b47302bbdd3e6f9cee4debca3a304e646f8c68245724350
04: 62d38838483ecfd2484ee3a2e5450d8ca3b35fc72cda6a8c620f9f43521c37d1
05: d8a85cb37221ab7d1f2cc5f554dbe0463acb6784b5b8dc3164ccaa66d8fff0e1
06: 9262e37cbe71ed4daf815b4a4881fb7251c9d371092dde827557d5368121e10e
07: 219d542233be492d62b079ffe46cf13396a8c27e520e88b08eaf2e6d3b7e70f5
08: de1f61c973b673e505adebe0d7e8fb65fde6c24dd4ab4fbaff9e28b18df6ecd3
09: c1de7274fa3e879a16d7e6e7629e3463d95f68adcfd17c477183846dccc41c89
10: 0000000000000000000000000000000000000000000000000000000000000000
11: 0000000000000000000000000000000000000000000000000000000000000000
12: 0000000000000000000000000000000000000000000000000000000000000000
13: 0000000000000000000000000000000000000000000000000000000000000000
14: 9ab9ebe4879a7f4dd00c04f37e79cfd69d0dd7a8bcc6b01135525b67676a3e40
15: 0000000000000000000000000000000000000000000000000000000000000000
16: 0000000000000000000000000000000000000000000000000000000000000000
17: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23: 0000000000000000000000000000000000000000000000000000000000000000
error: failed to unseal sealed key (TPM2_Unseal: 0x99d).
error: no key protector provided a usable key for luks (af16e48f-746b-4a12-aae1-c14dcee429e0).
If the user happens to have the PCR values for key sealing, the PCR dump
can be used to identify the changed PCRs and narrow down the scope for
closer inspection.
Please note that the PCR dump is trustworthy only if the GRUB binary is
authentic, so the user has to check the GRUB binary thoroughly before
using the PCR dump.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update linux_kernel_params to match the v6.13.7 upstream version of boot_params.
Refactor most things out into structs, as the Linux kernel does.
edid_info should be a struct with "unsigned char dummy[128]" and efi_info should
be a struct as well, starting at 0x1c0. However, for backwards compatibility,
GRUB can have efi_systab at 0x1b8 and padding at 0x1bc (or padding at both spots).
This cuts into the end of edid_info. Make edid_info inline and only make it go
up to 0x1b8.
Signed-off-by: Patrick Colp <patrick.colp@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub_xnu_load_kext_from_dir(), when the call to grub_device_open()
failed, it simply cleaned up previously allocated memory and returned
GRUB_ERR_NONE. However, it neglected to free ctx->newdirname which is
allocated before the call to grub_device_open().
Fixes: CID 473859
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub_cmd_initrd(), initrd_ctx is allocated before calling
grub_relocator_alloc_chunk_align(). When that function fails,
initrd_ctx should be freed before exiting grub_cmd_initrd().
Fixes: CID 473852
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Fix memory leaks in make_vg() with new helper functions, free_pv()
and free_lv(). Additionally, correct a check after allocating
comp->segments->nodes that mistakenly checked lv->segments->nodes
instead, likely due to a copy-paste error.
Fixes: CID 473878
Fixes: CID 473884
Fixes: CID 473889
Fixes: CID 473890
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A regression was introduced recently as a part of the series of
filesystem related patches to address some CVEs found in GRUB.
This issue may cause either an infinite loop at startup when
accessing certain valid NTFS filesystems, or may cause a crash
due to a NULL pointer dereference on systems where NULL address
is invalid (such as may happen when calling grub-mount from
the operating system level).
Correct this issue by checking that at->attr_cur is within bounds
inside find_attr().
Fixes: https://savannah.gnu.org/bugs/?66855
Fixes: aff263187 (fs/ntfs: Fix out-of-bounds read)
Signed-off-by: B Horn <b@horn.uk>
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The grub_malloc() has been inadvertently removed from the code after it
has been modified to use safe math functions.
Fixes: 4beeff8a (net: Use safe math macros to prevent overflows)
Signed-off-by: Nicolas Frayer <nfrayer@redhat.com>
Tested-by: Marta Lewandowska <mlewando@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Change RMA size from 512 MB to 768 MB which will result in more memory
at boot time for PowerPC. When vTPM, Secure Boot or FADump are enabled
on PowerPC the 512 MB RMA memory is not sufficient for boot. With this
512 MB RMA, GRUB runs out of memory and fails to boot the machine.
Sometimes even usage of CDROM requires more memory for installation and
along with the options mentioned above exhausts the boot memory which
results in boot failures. Increasing the RMA size will resolves multiple
out of memory issues observed on PowerPC machines.
Failure details (GRUB debug console dump):
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 1
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum runtime space
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 0
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum runtime space
kern/file.c:215: Closing `/ppc/ppc64/initrd.img' ...
kern/disk.c:297: Closing `ieee1275//vdevice/v-scsi@30000067/disk@8300000000000000'...
kern/disk.c:311: Closing `ieee1275//vdevice/v-scsi@30000067/disk@8300000000000000' succeeded.
kern/file.c:225: Closing `/ppc/ppc64/initrd.img' failed with 3.
kern/file.c:148: Opening `/ppc/ppc64/initrd.img' succeeded.
error: ../../grub-core/kern/mm.c:552:out of memory.
Signed-off-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without this fix the GRUB failed to boot linux with "out of memory" after
trying to run a "search --fs-uuid..." on a system that has 7 ZFS pools
across about 80 drives.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Mark cachevol LV's as ignored features, which is true only if they are
configured as "writethrough". This patch does not let GRUB boot from
"writeback" cache-enabled LV's.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The LV matching must be done after processing the ignored feature
indirections, as integrity volumes & caches may have several levels
of indirection that the segments must be shifted through.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The PV matching must be completely finished before validating a volume,
otherwise referenced RAID stripes may not have PV data applied yet.
This change is required for integrity & cachevol support.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The cache_pool is never read or used, remove it.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch isn't necessary by itself, but when combined with subsequent
patches it enhances readability as ignored_features_lv is then used for
multiple types of extra LV's, not just cache LV's.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Like the GNU ls, first print a line with the directory path before printing
files in the directory, which will not have a directory component, but only
if there is more than one argument.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
For arguments that are paths to files, print the full path of the file.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The modification time for paths to files was not being printed because
the grub_dirhook_info, which contains the mtime, was initialized to NULL.
Instead of calling print_file() directly, use fs->fs_dir() to call
print_file() with a properly filled in grub_dirhook_info. This has the
added benefit of reducing code complexity.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Simplify the code by removing logic around which file printer to call.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
