Don't leave a fresh tty's c_cflag at zero

[emkey1]

tty_alloc() copies c_iflag, c_oflag, c_lflag and c_cc from Linux's tty_std_termios, but leaves c_cflag at 0.

Zero is not a neutral default. The baud rate lives in the CBAUD bits of c_cflag, so 0 reads back as B0, which means "hang up the line", and also as CS5 with CREAD clear.

How I ran into it

ssh(1) from iSH to an OpenBSD host authenticated, printed the motd, and dropped immediately with Exit status 129 (128 + SIGHUP). The same client worked against every Linux host.

cfgetospeed() in both musl and glibc reads straight out of c_cflag, so ssh sees a terminal running at B0 and forwards it as TTY_OP_OSPEED in its pty-req. A BSD sshd honours that literally. The modes are applied before the fork, so nothing is signalled yet and the kernel just records an ospeed of 0. The login shell then takes the pty as its controlling terminal and calls tcsetattr to set up line editing; a shell that copies the whole struct and edits only c_iflag/c_lflag/c_cc carries the zero speed back in. A BSD tty driver SIGHUPs the session leader when it sees c_ospeed == 0, so the shell hangs itself up the instant it starts.

Linux servers are unaffected because their pty driver ignores B0, which is what makes this look like a server-side problem.

The change

Linux keeps the default per driver, so this does the same rather than picking one value for every tty:

• drivers/tty/vt/vt.c takes tty_std_termios as-is for the console, which includes HUPCL
• drivers/tty/pty.c overrides c_cflag to B38400|CS8|CREAD for both the master and the slave

The test is on the device type rather than the driver: the app drives its terminals through a tty_driver of its own, but pty_open_fake registers them under TTY_PSEUDO_SLAVE_MAJOR, so to the guest they are pty slaves and should not come up looking like a console.

The bits are inert inside iSH, which models no line discipline hardware, but guests read them back and forward them over the wire.

termios_from_real() needs the same treatment. It zero-initializes and then translates only the i/o/l flags and the control characters, so the CLI's own console tty came out at B0 as well. The host's c_cflag is not worth translating (BSD keeps the speed in a separate c_ospeed field rather than in CBAUD, and iSH models no baud rate), so it seeds the same nominal default instead.

Verification

Freshly allocated pty, tcgetattr on the slave. Same static i386 binary on iSH and on real Linux:

	before	after	real Linux
c_cflag	0000000	0000277	0000277
cfgetospeed()	0 (B0)	017 (B38400)	017 (B38400)
CSIZE	0 (CS5)	060 (CS8)	060 (CS8)
CREAD	clear	set	set

Console tty, tcgetattr on fd 0 over a real pty:

	before	after	Linux tty_std_termios
c_cflag	0000000	0002277	0002277

And the CLI's console tty, via busybox:

	before	after	real Linux
stty speed	0	38400	38400

Run on the Alpine 3.19.0 rootfs the App Store build downloads (ROOTFS_URL in app/iSH.xcconfig), against master 7864dd6. Real-Linux column is the same binary in a linux/386 container. stty -a still reports canonical mode, echo and the usual control characters.

The console row is checked against the kernel's value for that driver rather than against a measurement: a container's stdin is a pts, so there was nothing to measure it on directly.

One trap worth flagging for review: the kernel's termbits header spells these in hex, and the two neighbouring bits are easy to swap. HUPCL is 0x400, i.e. octal 0002000, while octal 0000400 is PARENB. PARENB_ is defined alongside it here so the mistake is harder to make, since ssh(1) forwards PARENB to the far end over the same wire path that makes the speed matter.