Forward terminal window size to guest PTY #75

rawan · 2026-03-29T10:10:44Z

rawan commented

2026-03-29 10:10:44 +00:00

NOTE : This branch contains the changes of both #70 and #73
so either merge this only to development and close the parent PR ( #73 )
or merge this after parent PR gets merged

https://forge.ourworld.tf/geomind_code/my_hypervisor/issues/72 **NOTE** : This branch contains the changes of both #70 and #73 so either merge this only to development and close the parent PR ( https://forge.ourworld.tf/geomind_code/my_hypervisor/pulls/73 ) or merge this after parent PR gets merged

rawan added 3 commits

2026-03-29 10:10:44 +00:00

fix: fix broken interactive signal handling

Unit and Integration Test / test (push) Successful in 2m19s

Details

a00dd8f7fa

feat: forward resize

Unit and Integration Test / test (push) Successful in 1m49s

Details

eaf140780e

fix: fixed silent errors

Unit and Integration Test / test (push) Successful in 1m51s

Details

c1cfbadadd

mahmoud commented

2026-03-30 09:35:03 +00:00

Sounds working, good job

mahmoud approved these changes

2026-03-30 09:35:09 +00:00

Dismissed

mahmoud dismissed mahmoud's review

2026-03-30 09:42:58 +00:00

Reason:

Approved by mistake

rawdaGastan requested changes

2026-03-31 13:25:23 +00:00

Dismissed

rawdaGastan left a comment

The resize protocol works by sending a special 4-byte marker \x01RSZ followed by 4 bytes of size data through the same stream as normal terminal data.

The problem: if a user does something like cat /bin/some_binary or pipes binary data, and that binary data happens to contain the bytes 0x01, 0x52, 0x53, 0x5a somewhere, the guest parser will think it's a resize message. It will:

Swallow 8 bytes of real data (the 4 "magic" bytes + the next 4 bytes it thinks are rows/cols)
Resize the terminal to whatever garbage values those next 4 bytes decode to
The user sees corrupted output and their terminal may resize to something unusable. With only 4 bytes of magic

The resize protocol works by sending a special 4-byte marker \x01RSZ followed by 4 bytes of size data through the same stream as normal terminal data. The problem: if a user does something like cat /bin/some_binary or pipes binary data, and that binary data happens to contain the bytes 0x01, 0x52, 0x53, 0x5a somewhere, the guest parser will think it's a resize message. It will: Swallow 8 bytes of real data (the 4 "magic" bytes + the next 4 bytes it thinks are rows/cols) Resize the terminal to whatever garbage values those next 4 bytes decode to The user sees corrupted output and their terminal may resize to something unusable. With only 4 bytes of magic

crates/my_hypervisor-init/src/shell_handler.rs

					
				@ -6,0 +65,4 @@

				            self.pos += 1;

				            if self.pos == RESIZE_MSG_LEN {

				                let rows = u16::from_be_bytes([self.buf[4], self.buf[5]]);

				                let cols = u16::from_be_bytes([self.buf[6], self.buf[7]]);

we should validate rows and cols to not be 0

rawan marked this conversation as resolved

crates/my_hypervisor-init/src/shell_handler.rs Outdated

					
				@ -156,0 +250,4 @@

				    fn test_resize_constants_match_protocol() {

				        // These bytes must match encode_resize() output in my_hypervisor-lib/src/vsock/protocol.rs

				        // If this test fails, the two crates have diverged.

				        assert_eq!(RESIZE_MAGIC, [0x01, 0x52, 0x53, 0x5a]); // SOH + "RSZ"

this will always pass even we changed the magic in protocol.rs

there is a corresponding test in protocol.rs that checks the same thing:

  fn test_encode_resize_known_values() {
        let msg = encode_resize(24, 80);
        assert_eq!(msg, [0x01, 0x52, 0x53, 0x5a, 0x00, 24, 0x00, 80]);
    }

That way if either side changes the format, one of the two tests breaks.

but we can add dev-dependency so that tests can use the same constant

there is a corresponding test in protocol.rs that checks the same thing: ``` fn test_encode_resize_known_values() { let msg = encode_resize(24, 80); assert_eq!(msg, [0x01, 0x52, 0x53, 0x5a, 0x00, 24, 0x00, 80]); } ``` That way if either side changes the format, one of the two tests breaks. but we can add dev-dependency so that tests can use the same constant

rawdaGastan marked this conversation as resolved

rawan commented

2026-04-01 09:52:28 +00:00

@rawdaGastan wrote in #75 (comment):

The resize protocol works by sending a special 4-byte marker \x01RSZ followed by 4 bytes of size data through the same stream as normal terminal data.

The problem: if a user does something like cat /bin/some_binary or pipes binary data, and that binary data happens to contain the bytes 0x01, 0x52, 0x53, 0x5a somewhere, the guest parser will think it's a resize message. It will:

Swallow 8 bytes of real data (the 4 "magic" bytes + the next 4 bytes it thinks are rows/cols) Resize the terminal to whatever garbage values those next 4 bytes decode to The user sees corrupted output and their terminal may resize to something unusable. With only 4 bytes of magic

this is very low risk case because:

It's on the stdin direction, not stdout. The user would have to type or pipe the exact bytes 0x01 0x52 0x53 0x5a into their terminal input. Running cat /bin/some_binary produces output on stdout (guest → host), which is not parsed for resize markers

The only way binary data hits this path is if someone does something like echo -e '\x01RSZ...' | chvm attach vm1 or cat binary_file | chvm attach vm1 which is an unusual edge case

so here are some suggestions if we do need to fix it:

Use a separate vsock port or channel for control messages
Add a checksum byte after the payload, ex: [magic 4B] [rows 2B] [cols 2B] [checksum of rows+cols 1B]

what do you think?

@rawdaGastan wrote in https://forge.ourworld.tf/geomind_code/my_hypervisor/pulls/75#issuecomment-16796: > The resize protocol works by sending a special 4-byte marker \x01RSZ followed by 4 bytes of size data through the same stream as normal terminal data. > > The problem: if a user does something like cat /bin/some_binary or pipes binary data, and that binary data happens to contain the bytes 0x01, 0x52, 0x53, 0x5a somewhere, the guest parser will think it's a resize message. It will: > > Swallow 8 bytes of real data (the 4 "magic" bytes + the next 4 bytes it thinks are rows/cols) Resize the terminal to whatever garbage values those next 4 bytes decode to The user sees corrupted output and their terminal may resize to something unusable. With only 4 bytes of magic this is very low risk case because: It's on the stdin direction, not stdout. The user would have to type or pipe the exact bytes 0x01 0x52 0x53 0x5a into their terminal input. Running cat /bin/some_binary produces output on stdout (guest → host), which is not parsed for resize markers The only way binary data hits this path is if someone does something like `echo -e '\x01RSZ...' | chvm attach vm1` or `cat binary_file | chvm attach vm1` which is an unusual edge case so here are some suggestions if we do need to fix it: - Use a separate vsock port or channel for control messages - Add a checksum byte after the payload, ex: [magic 4B] [rows 2B] [cols 2B] [checksum of rows+cols 1B] what do you think?

rawan added 1 commit

2026-04-01 10:16:05 +00:00

fix: added 0 rows, cols check

Unit and Integration Test / test (push) Successful in 1m55s

Details

a193e7b888

rawdaGastan commented

2026-04-01 11:06:38 +00:00

@rawan wrote in #75 (comment):

@rawdaGastan wrote in #75 (comment):

The resize protocol works by sending a special 4-byte marker \x01RSZ followed by 4 bytes of size data through the same stream as normal terminal data.
The problem: if a user does something like cat /bin/some_binary or pipes binary data, and that binary data happens to contain the bytes 0x01, 0x52, 0x53, 0x5a somewhere, the guest parser will think it's a resize message. It will:
Swallow 8 bytes of real data (the 4 "magic" bytes + the next 4 bytes it thinks are rows/cols) Resize the terminal to whatever garbage values those next 4 bytes decode to The user sees corrupted output and their terminal may resize to something unusable. With only 4 bytes of magic

this is very low risk case because:

It's on the stdin direction, not stdout. The user would have to type or pipe the exact bytes 0x01 0x52 0x53 0x5a into their terminal input. Running cat /bin/some_binary produces output on stdout (guest → host), which is not parsed for resize markers

The only way binary data hits this path is if someone does something like echo -e '\x01RSZ...' | chvm attach vm1 or cat binary_file | chvm attach vm1 which is an unusual edge case

so here are some suggestions if we do need to fix it:

Use a separate vsock port or channel for control messages

Add a checksum byte after the payload, ex: [magic 4B] [rows 2B] [cols 2B] [checksum of rows+cols 1B]

what do you think?

we can document it

@rawan wrote in https://forge.ourworld.tf/geomind_code/my_hypervisor/pulls/75#issuecomment-16966: > @rawdaGastan wrote in #75 (comment): > > > The resize protocol works by sending a special 4-byte marker \x01RSZ followed by 4 bytes of size data through the same stream as normal terminal data. > > The problem: if a user does something like cat /bin/some_binary or pipes binary data, and that binary data happens to contain the bytes 0x01, 0x52, 0x53, 0x5a somewhere, the guest parser will think it's a resize message. It will: > > Swallow 8 bytes of real data (the 4 "magic" bytes + the next 4 bytes it thinks are rows/cols) Resize the terminal to whatever garbage values those next 4 bytes decode to The user sees corrupted output and their terminal may resize to something unusable. With only 4 bytes of magic > > this is very low risk case because: > > It's on the stdin direction, not stdout. The user would have to type or pipe the exact bytes 0x01 0x52 0x53 0x5a into their terminal input. Running cat /bin/some_binary produces output on stdout (guest → host), which is not parsed for resize markers > > The only way binary data hits this path is if someone does something like `echo -e '\x01RSZ...' | chvm attach vm1` or `cat binary_file | chvm attach vm1` which is an unusual edge case > > so here are some suggestions if we do need to fix it: > > * Use a separate vsock port or channel for control messages > * Add a checksum byte after the payload, ex: [magic 4B] [rows 2B] [cols 2B] [checksum of rows+cols 1B] > > what do you think? we can document it

rawan added 1 commit

2026-04-01 12:54:50 +00:00

doc: document resize protocol edge case

Unit and Integration Test / test (push) Successful in 2m21s

Details

29b03e7564

rawan added 1 commit

2026-04-01 13:01:15 +00:00

Merge branch 'development' into fix_signals_resize

Unit and Integration Test / test (push) Successful in 1m53s

Details

58922d5e76