linux-kernel - Re: [PATCH v2 2/2] kexec_file: Increase maximum file size to 4G

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+CK2bC5U5j1xkZKuOETANo1=PPpbJn2mKYOa2fK1GLFib0ibw@mail.gmail.com>
Date:   Tue, 7 Jun 2022 12:02:04 -0400
From:   Pasha Tatashin <pasha.tatashin@...een.com>
To:     Baoquan He <bhe@...hat.com>
Cc:     Sasha Levin <sashal@...nel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>, rburanyi@...gle.com,
        Greg Thelen <gthelen@...gle.com>, viro@...iv.linux.org.uk,
        kexec mailing list <kexec@...ts.infradead.org>,
        linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] kexec_file: Increase maximum file size to 4G

On Sun, Jun 5, 2022 at 10:56 PM Baoquan He <bhe@...hat.com> wrote:
>
> On 05/27/22 at 02:55am, Pasha Tatashin wrote:
> > In some case initrd can be large. For example, it could be a netboot
> > image loaded by u-root, that is kexec'ing into it.
> >
> > The maximum size of initrd is arbitrary set to 2G. Also, the limit is
> > not very obvious because it is hidden behind a generic INT_MAX macro.
> >
> > Theoretically, we could make it LONG_MAX, but it is safer to keep it
> > sane, and just increase it to 4G.
>
> Do we need to care about 32bit system where initramfs could be larger
> than 2G? On 32bit system, SSIZE_MAX is still 2G, right?

Yes, on 32-bit SSIZE_MAX is still 2G, so we are safe to keep 32-bit
systems run exactly as today.

#define KEXEC_FILE_SIZE_MAX    min_t(s64, 4LL << 30, SSIZE_MAX)
Is meant to protect against running over the 2G limit on 32-bit systems.

>
> Another concern is if 2G is enough. If we can foresee it might need be
> enlarged again in a near future, LONG_MAX certainly is not a good
> value, but a little bigger multiple of 2G can be better?

This little series enables increasing the max value above 2G, but
still keeps it within a sane size i.e. 4G, If 4G seems too small, I
can change it to 8G or 16G instead of 4G.

Thanks,
Pasha

>
> >
> > Increase the size to 4G, and make it obvious by having a new macro
> > that specifies the maximum file size supported by kexec_file_load()
> > syscall: KEXEC_FILE_SIZE_MAX.
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
> > ---
> >  kernel/kexec_file.c | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> > index 8347fc158d2b..f00cf70d82b9 100644
> > --- a/kernel/kexec_file.c
> > +++ b/kernel/kexec_file.c
> > @@ -31,6 +31,9 @@
> >
> >  static int kexec_calculate_store_digests(struct kimage *image);
> >
> > +/* Maximum size in bytes for kernel/initrd files. */
> > +#define KEXEC_FILE_SIZE_MAX  min_t(s64, 4LL << 30, SSIZE_MAX)
> > +
> >  /*
> >   * Currently this is the only default function that is exported as some
> >   * architectures need it to do additional handlings.
> > @@ -223,11 +226,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd,
> >                            const char __user *cmdline_ptr,
> >                            unsigned long cmdline_len, unsigned flags)
> >  {
> > -     int ret;
> > +     ssize_t ret;
> >       void *ldata;
> >
> >       ret = kernel_read_file_from_fd(kernel_fd, 0, &image->kernel_buf,
> > -                                    INT_MAX, NULL, READING_KEXEC_IMAGE);
> > +                                    KEXEC_FILE_SIZE_MAX, NULL,
> > +                                    READING_KEXEC_IMAGE);
> >       if (ret < 0)
> >               return ret;
> >       image->kernel_buf_len = ret;
> > @@ -247,7 +251,7 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd,
> >       /* It is possible that there no initramfs is being loaded */
> >       if (!(flags & KEXEC_FILE_NO_INITRAMFS)) {
> >               ret = kernel_read_file_from_fd(initrd_fd, 0, &image->initrd_buf,
> > -                                            INT_MAX, NULL,
> > +                                            KEXEC_FILE_SIZE_MAX, NULL,
> >                                              READING_KEXEC_INITRAMFS);
> >               if (ret < 0)
> >                       goto out;
> > --
> > 2.36.1.124.g0e6072fb45-goog
> >
>