Branch "putty" has been renamed to "main" #2
Comments
ranvis
pushed a commit
that referenced
this issue
Jul 16, 2021
When do_paint breaks up a line of terminal text into contiguous runs of characters to treat the same, one of the criteria it uses is, 'Does this character even need redrawing? (or is it already displayed correctly from the previous redraw?)' When we encounter a character that matches its previous value, we end the previous run of characters, so that we can skip the one we've just encountered. That check was not taking account of the 'truecolour' field of the termchar it was checking. So it would sometimes falsely believe the character to be equivalent to its previously drawn value, even when in fact it was not, and hence insert a run break, anticipating that the previous character needed drawing and the current one did not. This didn't cause a _wrong_ redraw, because there's a separate loop further on which re-checks whether to actually draw things, which didn't make the same error. So the character that loop #1 thought didn't need a redraw, loop #2 knew _did_ need a redraw, and hence, everything did get redrawn. But by the time loop #2 is running, it's too late to change the run boundaries. So everything does get redrawn, but in much smaller chunks than it could have been. The net effect was that if the screen was filled with text displayed in true colour, and you changed it to the _same_ text in a different colour, then the whole terminal would be redrawn in one-character increments instead of the usual behaviour of folding together runs that can be drawn in one go. Thanks to Bradley Smith for debugging this very confusing issue!
ranvis
pushed a commit
that referenced
this issue
Nov 21, 2021
Now, we always try an initial CONNECT request with no auth at all, and wait for the proxy to reject it before sending a second try with auth. That way, we can wait to see what _kind_ of authentication the proxy requests, which will enable us to support something more secure than Basic, such as HTTP Digest. (I mean, it would _work_ to try Basic in request #1 and then retrying with Digest in #2 when the proxy asks for it. But if the aim of using Digest is to avoid sending the password in cleartext, it defeats the entire purpose to have sent it in cleartext anyway by the time you realise the server is prepared to do something better!)
ranvis
pushed a commit
that referenced
this issue
May 13, 2022
If the user holds down Alt-> so that the key repeats, then a second call to change_font_size can occur while the window resize from the previous one has yet to complete. This leads to the new pixel size of the window from resize #1 being interpreted in the light of the font size from reesize #2, so that the two get out of step and the _character_ size of the terminal changes as a result. The simplest fix is to disallow starting a second font-size-based window resize while the first is still in flight - which, now that the 'win_resize_pending' flag lives in window.c and not terminal.c, is easy to achieve.
ranvis
changed the title
ranvis
pushed a commit
that referenced
this issue
Dec 20, 2024
DIT, for 'Data-Independent Timing', is a bit you can set in the
processor state on sufficiently new Arm CPUs, which promises that a
long list of instructions will deliberately avoid varying their timing
based on the input register values. Just what you want for keeping
your constant-time crypto primitives constant-time.
As far as I'm aware, no CPU has _yet_ implemented any data-dependent
optimisations, so DIT is a safety precaution against them doing so in
future. It would be embarrassing to be caught without it if a future
CPU does do that, so we now turn on DIT in the PuTTY process state.
I've put a call to the new enable_dit() function at the start of every
main() and WinMain() belonging to a program that might do
cryptography (even testcrypt, in case someone uses it for something!),
and in case I missed one there, also added a second call at the first
moment that any cryptography-using part of the code looks as if it
might become active: when an instance of the SSH protocol object is
configured, when the system PRNG is initialised, and when selecting
any cryptographic authentication protocol in an HTTP or SOCKS proxy
connection. With any luck those precautions between them should ensure
it's on whenever we need it.
Arm's own recommendation is that you should carefully choose the
granularity at which you enable and disable DIT: there's a potential
time cost to turning it on and off (I'm not sure what, but plausibly
something of the order of a pipeline flush), so it's a performance hit
to do it _inside_ each individual crypto function, but if CPUs start
supporting significant data-dependent optimisation in future, then it
will also become a noticeable performance hit to just leave it on
across the whole process. So you'd like to do it somewhere in the
middle: for example, you might turn on DIT once around the whole
process of verifying and decrypting an SSH packet, instead of once for
decryption and once for MAC.
With all respect to that recommendation as a strategy for maximum
performance, I'm not following it here. I turn on DIT at the start of
the PuTTY process, and then leave it on. Rationale:
1. PuTTY is not otherwise a performance-critical application: it's
not likely to max out your CPU for any purpose _other_ than
cryptography. The most CPU-intensive non-cryptographic thing I can
imagine a PuTTY process doing is the complicated computation of
font rendering in the terminal, and that will normally be cached
(you don't recompute each glyph from its outline and hints for
every time you display it).
2. I think a bigger risk lies in accidental side channels from having
DIT turned off when it should have been on. I can imagine lots of
causes for that. Missing a crypto operation in some unswept corner
of the code; confusing control flow (like my coroutine macros)
jumping with DIT clear into the middle of a region of code that
expected DIT to have been set at the beginning; having a reference
counter of DIT requests and getting it out of sync.
In a more sophisticated programming language, it might be possible to
avoid the risk in #2 by cleverness with the type system. For example,
in Rust, you could have a zero-sized type that acts as a proof token
for DIT being enabled (it would be constructed by a function that also
sets DIT, have a Drop implementation that clears DIT, and be !Send so
you couldn't use it in a thread other than the one where DIT was set),
and then you could require all the actual crypto functions to take a
DitToken as an extra parameter, at zero runtime cost. Then "oops I
forgot to set DIT around this piece of crypto" would become a compile
error. Even so, you'd have to take some care with coroutine-structured
code (what happens if a Rust async function yields while holding a DIT
token?) and with nesting (if you have two DIT tokens, you don't want
dropping the inner one to clear DIT while the outer one is still there
to wrongly convince callees that it's set). Maybe in Rust you could
get this all to work reliably. But not in C!
DIT is an optional feature of the Arm architecture, so we must first
test to see if it's supported. This is done the same way as we already
do for the various Arm crypto accelerators: on ELF-based systems,
check the appropriate bit in the 'hwcap' words in the ELF aux vector;
on Mac, look for an appropriate sysctl flag.
On Windows I don't know of a way to query the DIT feature, _or_ of a
way to write the necessary enabling instruction in an MSVC-compatible
way. I've _heard_ that it might not be necessary, because Windows
might just turn on DIT unconditionally and leave it on, in an even
more extreme version of my own strategy. I don't have a source for
that - I heard it by word of mouth - but I _hope_ it's true, because
that would suit me very well! Certainly I can't write code to enable
DIT without knowing (a) how to do it, (b) how to know if it's safe.
Nonetheless, I've put the enable_dit() call in all the right places in
the Windows main programs as well as the Unix and cross-platform code,
so that if I later find out that I _can_ put in an explicit enable of
DIT in some way, I'll only have to arrange to set HAVE_ARM_DIT and
compile the enable_dit() function appropriately.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This repo used "putty" as a replacement of the official "master" since it is forked from the unofficial PuTTY repository back when PuTTY was only available in subversion repo.
Quite some time ago, the official repo started to use "main" as a master branch. Since the name is available in this repo too, I will switch branch name "putty" to "main".
For the time being, I maintain both "main" and deprecated "putty" sync. I will then remove "putty" at a good time.
The text was updated successfully, but these errors were encountered: