simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  965057d6 Change strategy for the Arm instruction setting DIT.
  64712be3 Non-SSH backends: delay setting trust status to false.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2025-03-02 17:05:49

commit 965057d6d6c9de9fcf506c75b0a2fad22988c72b
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=965057d6d6c9de9fcf506c75b0a2fad22988c72b;hp=50e360fc7474898b4de0e3533aff50857f2b3289
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Feb 15 15:57:53 2025 +0000

    Change strategy for the Arm instruction setting DIT.
    
    Colin Watson reported that a build failure occurred in the AArch64
    Debian build of PuTTY 0.83:
    
    gcc now defaults to enabling branch protection using AArch64 pointer
    authentication, if the target architecture version supports it.
    Debian's base supported architecture does not, but Armv8.4-A does. So
    when I changed the compile flags for enable_dit.c to add
    -march=armv8.4-a, it didn't _just_ allow me to write the 'msr dit, %0'
    instruction in my asm statement; it also unexpectedly turned on
    pointer authentication in the containing function, which caused a
    SIGILL when running on a pre-Armv8.4-A CPU, because although the code
    correctly skipped the instruction that set DIT, it was already inside
    enable_dit() at that point and couldn't avoid going through the
    unsupported 'retaa' instruction which tries to check an auth code on
    the return address.
    
    An obvious approach would be to add -mbranch-protection=none to the
    compile flags for enable_dit.c. Another approach is to leave the
    _compiler_ flags alone, and change the architecture in the assembler,
    either via a fiddly -Wa,... option or by putting a .arch directive
    inside the asm statement. But both have downsides. Turning off branch
    protection is fine for the Debian build, but has the unwanted side
    effect of turning it off (in that one function) even in builds
    targeting a later architecture which _did_ want branch protection. And
    changing the assembler's architecture risks changing it _down_ instead
    of up, again perhaps invalidating other instructions generated by the
    compiler (like if some later security feature is introduced that gcc
    also wants to turn on by default).
    
    So instead I've taken the much simpler approach of not bothering to
    change the target architecture at all, and instead generating the move
    into DIT by hardcoding its actual instruction encoding. This meant I
    also had to force the input value into a specific register, but I
    don't think that does any harm (not _even_ wasting an extra
    instruction in codegen). Now we should avoid interfering with any
    security features the compiler wants to turn on or off: all of that
    should be independent of the instruction I really wanted.

 crypto/CMakeLists.txt | 11 +++++++++--
 crypto/enable_dit.c   |  6 +++++-
 2 files changed, 14 insertions(+), 3 deletions(-)

commit 64712be3cbc4a02bda4a92ca97e8d4f294abbe9a
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=64712be3cbc4a02bda4a92ca97e8d4f294abbe9a;hp=965057d6d6c9de9fcf506c75b0a2fad22988c72b
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Feb 27 12:51:18 2025 +0000

    Non-SSH backends: delay setting trust status to false.
    
    A user reported recently that if you connect to a Telnet server via a
    proxy that requires authentication, and enter the auth details
    manually in the PuTTY terminal window, then the entire Telnet session
    is shown with trust sigils to its left.
    
    This happens because telnet.c calls seat_set_trust_status(false) as
    soon as it's called new_connection() to make the Socket. But the
    interactive proxy authentication dialogue hasn't happened yet, at that
    point. So the proxy resets the trust status to true and asks for a
    username and password, and then nothing ever resets it to false,
    because telnet.c thought it had already done that.
    
    The solution is to defer the Telnet backend's change of trust status
    to when we get the notification that the socket is properly connected,
    which arrives via plug_log(PLUGLOG_CONNECT_SUCCESS).
    
    The same bug occurs in raw.c and supdup.c, but not in rlogin.c,
    because Rlogin has an initial authentication exchange known to the
    protocol, and already delays resetting the trust status until after
    that has concluded.

 otherbackends/raw.c    | 6 +++---
 otherbackends/supdup.c | 4 +++-
 otherbackends/telnet.c | 6 +++---
 3 files changed, 9 insertions(+), 7 deletions(-)