From: David Laight <david.laight.linux@gmail.com>
To: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] s390: Warn if kernel command line contains non-printable EBCDIC characters
Date: Thu, 27 Aug 2026 09:32:24 +0100 [thread overview]
Message-ID: <20260827093224.6d4b1971@pumpkin> (raw)
In-Reply-To: <4ed90c1e-0edf-4d12-b4d7-d439a8113669@linux.ibm.com>
On Wed, 26 Aug 2026 16:08:50 +0200
Ilya Leoshkevich <iii@linux.ibm.com> wrote:
> On 8/26/26 15:51, David Laight wrote:
> > On Tue, 25 Aug 2026 17:08:08 +0200
> > Ilya Leoshkevich <iii@linux.ibm.com> wrote:
> >
> >> Users may accidentally add multi-byte UTF-8 characters to zipl.conf
> >> parmline, for example, by copying snippets containing non-breaking
> >> spaces (\xC2\xA0) from web pages.
> >>
> >> The kernel will then interpret the entire command line as EBCDIC,
> >> making it unusable. Distinguish this situation from the legitimate
> >> EBCDIC conversion by looking for non-printable characters and issue
> >> a warning.
> >
> > Would it be better to check for the entire line being printable ebcdic?
> > All of EBCDIC a-zA-Z0-9 have the 0x80 bit set and most of 0x20..0x7f
> > are invalid or control characters (or punctuation).
> >
> > David
>
> I actually started with that, but this required introducing a new
> _ctype-like table (unfortunately it's not as simple as checking a
> couple ranges), so I decided against that and took a shortcut via
> ASCII.
Could you get the conversion function to return an error if it found
invalid EBCDIC characters?
If there is a single UTF8 character (eg non-breaking space) you really
want to treat the line as ASCII.
Actually you could count the number of characters with the 0x80 bit set.
If more than 1/2 assume EBCDIC (all of 0-9a-zA-Z have the bit set).
(I didn't realise anyone still used EBCDIC.
I guess the unix implementation(s) use ASCII (otherwise too much code
is broken) but the old IBM OS uses EBCDIC.
I worked for ICL for a while, their old 1900 series (from the early
1970s) used 6bit characters (4 in a 24bit word) that were ACSII codes
32-95. The replacement 2900 series (very late 1970s) used EBCDIC internally
(I guess because IBM used it...) but all the peripherals were ASCII.)
David
>
> [...]
next prev parent reply other threads:[~2026-08-27 8:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 15:08 [PATCH] s390: Warn if kernel command line contains non-printable EBCDIC characters Ilya Leoshkevich
2026-08-25 15:20 ` sashiko-bot
2026-08-26 9:29 ` Heiko Carstens
2026-08-26 14:17 ` Ilya Leoshkevich
2026-08-26 13:51 ` David Laight
2026-08-26 14:08 ` Ilya Leoshkevich
2026-08-27 8:32 ` David Laight [this message]
2026-08-27 11:15 ` Ilya Leoshkevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260827093224.6d4b1971@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox