Linux s390 Architecture development
 help / color / mirror / Atom feed
From: Ilya Leoshkevich <iii@linux.ibm.com>
To: David Laight <david.laight.linux@gmail.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 13:15:09 +0200	[thread overview]
Message-ID: <c641bbfe-04cb-4f2c-8533-1955368931a1@linux.ibm.com> (raw)
In-Reply-To: <20260827093224.6d4b1971@pumpkin>



On 8/27/26 10:32, David Laight wrote:
> 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 also considered that, but setting any threshold feels arbitrary and
will probably fail for punctuation-heavy command lines.

I also didn't want to make it a hard fail, because I'm not certain that
I know all uses cases. Perhaps there are people who wants umlauts and
what not? It would be bad to break whatever they are doing.

But at the same time it was very painful to debug the &nbsp; issue, so
I settled for the compromise: add a warning that will be helpful to
99.9% users and will only mildly annoy the 0.1% umlaut users.


I just had an off-list discussion with Heiko and we think about going
with your first proposal for v3: a new _ctype table for EBCDIC for
determining whether characters are printable. The overhead from this is
not bad as I thought it would be.
> (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.)

Linux on s390 still uses it for interfacing with traditional IBM
hypervisors (z/VM and PR/SM), which are very much alive and used today.
> David
> 
>>
>> [...]
> 


      reply	other threads:[~2026-08-27 11:15 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
2026-08-27 11:15       ` Ilya Leoshkevich [this message]

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=c641bbfe-04cb-4f2c-8533-1955368931a1@linux.ibm.com \
    --to=iii@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=david.laight.linux@gmail.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@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