Golovanov399's blog

Meltdown + spectre vs testing systems
By Golovanov399, history, 6 years ago, In English

Hello everyone,

Some of you may know about recently discovered vulnerabilities (well, technically, there in one vulnerability and two attacks using it). I am not a cybersecurity expert, I know what is going on about the "read-all-those-breaking-news-titles" level, but as I understood, some things can slow down by 30%. So I have a couple of questions:

  1. Do testing systems like codeforces, yandex.contest, topcoder, atcoder, csacademy etc apply the patch? I don't know if testing machines store something that is important and shouldn't be stolen.

  2. If yes, does this mean that we now should multiply all time limits by 0.7? Maybe this coefficient is not so small because 30% is reached on some other type of operations which are not used in cp? On the other hand, branch prediction is used almost always in cp, as I know.

Somebody who knows how this works, answer, please.

  • Vote: I like it
  • +89
  • Vote: I do not like it

Comments Comments (12)
| Write comment?
»
6 years ago, # |
  Vote: I like it 0 Vote: I do not like it

If yes, does this mean that we now should multiply all time limits by 0.7?

You mean divide right?

but apparently according to google, newer patch will not slow down the processor significantly, so maybe it wont be such a issue.

→ Reply
  • »
    »
    6 years ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    Multiply by 0.7 = divide by 10/7 => decrease. I mean, if I see "tl = 1s" in a problem, should I think of it like "so my code should work about 0.7 secs measuring as in 2017"?

    → Reply
»
6 years ago, # |
  Vote: I like it +80 Vote: I do not like it

We should hardly expect a noticeable impact for contest submissions, as they have little need for syscalls. The only ones which are really needed are for standard I/O, but even here the number of syscalls is usually much smaller than the number of I/O operations due to buffering.

→ Reply
  • »
    »
    6 years ago, # ^ |
    ← Rev. 2   Vote: I like it 0 Vote: I do not like it

    The meltdown doesn't need syscalls. So I suppose the fix will affect something more than the syscalls , like branch predictions, or the meltdown won't be fixed. And as a result, any program with if statements in them will be slower.

    Edit: I was wrong. The fix won't affect the speed of something like if(a<b) {} else {}.

    → Reply
»
6 years ago, # |
  Vote: I like it 0 Vote: I do not like it

I am not a cybersecurity expert, but

  1. It's still very hard to make an attack on codeforces (etc.).
  2. A performance of a typical competitive programming code should not be affected by the patch as you never switch to kernel.
→ Reply
  • »
    »
    6 years ago, # ^ |
      Vote: I like it +5 Vote: I do not like it

    it may affect IO and/or memory allocations.

    → Reply
»
6 years ago, # |
  Vote: I like it 0 Vote: I do not like it

I read something about the two attacks and didn't see anything about the kernel. How could you assume the slow down is caused by syscalls or switching to kernel? I think the patches should fix the problems about branch prediction and so any code with if statement will be affacted, even if it doesn't make any syscall.

→ Reply
  • »
    »
    6 years ago, # ^ |
      Vote: I like it +10 Vote: I do not like it

    Software fix of attack is removing kernel data from process memory, instead of rely on hardware protection. After it, process can read memory which is available for it with no attack and useless kernel interrupt handlers. But when syscall happens kernel memory is needed. So on each syscall kernel need to map and unmap pages, which cost some time.

    → Reply
    • »
      »
      »
      6 years ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      I think we also need to seperate the memories of different processes from each other, as well as seperating the kernel data from processes. So each memory reading, like x=a[i], now cost some more time, right?

      → Reply
      • »
        »
        »
        »
        6 years ago, # ^ |
          Vote: I like it +12 Vote: I do not like it

        They were always separated.

        Memory management on OS level is a bit more complex. You can read in wiki for example.

        Same physical memory can have several logical addresses, and moreover (not fully sure about this, to be honest) kernel often have full physical memory mapping in it's memory. So although you can't read memory of other process directly, you can read something, and try to find, for example, a password used by other process, using this mapping. You will not know which process memory you are reading, but is it really important?

        When just executing your code, nothing changed by the fix. But when you try to make syscall (for allocating memory, reading from disk, or sending somthing to network) kernel need to do a lot of extra work and drop a lot of caches.

        → Reply
        • »
          »
          »
          »
          »
          6 years ago, # ^ |
            Vote: I like it 0 Vote: I do not like it

          Thanks for the explaination. So a process can read something from other process's memory, by the meltdown attack scheme. And this scheme only read memories which is not a syscall. If nothing changed by the fix, this attack scheme will remain successful. Did I got it right?

          → Reply
          • »
            »
            »
            »
            »
            »
            6 years ago, # ^ |
              Vote: I like it 0 Vote: I do not like it

            Well, you can't read other memory process. You can read some memory which is mapped for your process, but normally only accessible when you are inside kernel code in syscall. If no such memory mapped, when you are not in syscall, you can't do anything bad. And nothing changed when you accesses legitimate addresses. While meltdown need "accessing" adresses which normally should not be accessed, and this will not work after fix.

            → Reply