linux-kernel - Re: [PATCH] riscv: Bump COMMAND_LINE

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACT4Y+Y1s2iE3OF8WHwb7F2crRjgnFCWQfoFvs3d-KgHpMLeKg@mail.gmail.com>
Date:   Thu, 9 Feb 2023 12:37:17 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Alex Ghiti <alex@...ti.fr>
Cc:     Palmer Dabbelt <palmer@...belt.com>, macro@...am.me.uk,
        david.abdurachmanov@...il.com,
        Paul Walmsley <paul.walmsley@...ive.com>,
        linux-api@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024

On Thu, 10 Nov 2022 at 22:01, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Mon, 21 Jun 2021 at 00:11, Alex Ghiti <alex@...ti.fr> wrote:
> >
> > Hi Palmer,
> >
> > Le 23/04/2021 à 04:57, Palmer Dabbelt a écrit :
> > > On Fri, 02 Apr 2021 11:33:30 PDT (-0700), macro@...am.me.uk wrote:
> > >> On Fri, 2 Apr 2021, David Abdurachmanov wrote:
> > >>
> > >>> > > >  This macro is exported as a part of the user API so it must
> > >>> not depend on
> > >>> > > > Kconfig.  Also changing it (rather than say adding
> > >>> COMMAND_LINE_SIZE_V2 or
> > >>> > > > switching to an entirely new data object that has its dimension
> > >>> set in a
> > >>> > > > different way) requires careful evaluation as external binaries
> > >>> have and
> > >>> > > > will have the value it expands to compiled in, so it's a part
> > >>> of the ABI
> > >>> > > > too.
> > >>> > >
> > >>> > > Thanks, I didn't realize this was part of the user BI.  In that
> > >>> case we
> > >>> > > really can't chage it, so we'll have to sort out some other way
> > >>> do fix
> > >>> > > whatever is going on.
> > >>> > >
> > >>> > > I've dropped this from fixes.
> > >>> >
> > >>> > Does increasing COMMAND_LINE_SIZE break user-space binaries? I would
> > >>> > expect it to work the same way as adding new enum values, or adding
> > >>> > fields at the end of versioned structs, etc.
> > >>> > I would assume the old bootloaders/etc will only support up to the
> > >>> > old, smaller max command line size, while the kernel will support
> > >>> > larger command line size, which is fine.
> > >>> > However, if something copies /proc/cmdline into a fixed-size buffer
> > >>> > and expects that to work, that will break... that's quite unfortunate
> > >>> > user-space code... is it what we afraid of?
> > >>> >
> > >>> > Alternatively, could expose the same COMMAND_LINE_SIZE, but internally
> > >>> > support a larger command line?
> > >>>
> > >>> Looking at kernel commit history I see PowerPC switched from 512 to
> > >>> 2048, and I don't see complaints about the ABI on the mailing list.
> > >>>
> > >>> If COMMAND_LINE_SIZE is used by user space applications and we
> > >>> increase it there shouldn't be problems. I would expect things to
> > >>> work, but just get truncated boot args? That is the application will
> > >>> continue only to look at the initial 512 chars.
> > >>
> > >>  The macro is in an include/uapi header, so it's exported to the userland
> > >> and a part of the user API.  I don't know what the consequences are for
> > >> the RISC-V port specifically, but it has raised my attention, and I think
> > >> it has to be investigated.
> > >>
> > >>  Perhaps it's OK to change it after all, but you'd have to go through
> > >> known/potential users of this macro.  I guess there shouldn't be that
> > >> many
> > >> of them.
> > >>
> > >>  In any case it cannot depend on Kconfig, because the userland won't have
> > >> access to the configuration, and then presumably wants to handle any and
> > >> all.
> > >
> > > It kind of feels to me like COMMAND_LINE_SIZE shouldn't have been part
> > > of the UABI to begin with.  I sent a patch to remove it from the
> > > asm-generic UABI, let's see if anyone knows of a reason it should be UABI:
> > >
> > > https://lore.kernel.org/linux-arch/20210423025545.313965-1-palmer@dabbelt.com/T/#u
> >
> > Arnd seemed to agree with you about removing COMMAND_LINE_SIZE from the
> > UABI, any progress on your side?
>
> Was this ever merged? Don't see this even in linux-next.

Ping. Still an issue at least for syzbot.