Группа исследователей из китайских и американских университетов выявила новую уязвимость в процессорах Intel, приводящую к утечке по сторонним каналам информации о результате спекулятивного выполнения операций, которую можно использовать, например, для организации скрытого канала связи между  процессами или определения утечек при совершении атак класса Meltdown...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=59029

• Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 15:54 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:00 , 28-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Bob, 02:18 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,AlexN, 14:24 , 07-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:01 , 28-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:18 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 22:42 , 30-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Michael Shigorin, 22:53 , 03-Май-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 00:31 , 05-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Genry007, 06:37 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 08:49 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 09:45 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 10:09 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 10:20 , 29-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Den4ick, 17:35 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 18:41 , 30-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 19:19 , 30-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,edo, 11:24 , 30-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 11:59 , 30-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 11:59 , 30-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 19:21 , 30-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 22:47 , 30-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 08:03 , 01-Май-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 05:01 , 06-Май-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 07:59 , 06-Май-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 08:00 , 06-Май-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 08:04 , 01-Май-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 19:08 , 06-Май-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 08:19 , 01-Май-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 05:33 , 06-Май-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 07:58 , 06-Май-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 08:03 , 06-Май-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonomus, 15:58 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,bircoph, 16:11 , 28-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonomus, 16:22 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:51 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 01:46 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,edo, 11:25 , 30-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 00:14 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 11:23 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,n00by, 15:49 , 29-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,fidoman, 16:14 , 28-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,аНОНИМ, 16:35 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonomus, 16:37 , 28-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:58 , 28-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonomus, 17:05 , 28-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:43 , 28-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Neon, 22:08 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:22 , 28-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:45 , 28-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Неуклюжий танцор, 22:15 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:40 , 28-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:56 , 28-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonomus, 17:11 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,fidoman, 18:11 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 18:29 , 28-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонимусс, 20:52 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 21:31 , 28-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонимусс, 22:25 , 28-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 22:34 , 28-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 04:25 , 29-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,ivan_erohin, 08:32 , 29-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 14:29 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 11:44 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:42 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 22:52 , 30-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonimus, 20:58 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 21:45 , 28-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 04:28 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 11:50 , 29-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонимусс, 13:37 , 29-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 13:52 , 29-Апр-23
                • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonymous, 16:08 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 13:53 , 29-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонимусс, 15:20 , 29-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 16:17 , 29-Апр-23
                • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 20:04 , 30-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 22:11 , 06-Май-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,ivan_erohin, 08:40 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 23:05 , 30-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноньимъ, 03:37 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,аНОНИМ, 06:15 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноньимъ, 15:21 , 29-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,n00by, 16:07 , 29-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 22:13 , 06-Май-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:11 , 29-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 16:21 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 11:55 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 21:38 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 21:52 , 28-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонимусс, 22:18 , 28-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 22:41 , 28-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонимусс, 22:55 , 28-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 23:19 , 28-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:06 , 29-Апр-23
                • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 04:04 , 02-Май-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:08 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:46 , 01-Май-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 22:59 , 28-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 23:03 , 28-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 23:57 , 28-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонин, 00:37 , 29-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 01:24 , 29-Апр-23
                • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонин, 10:28 , 29-Апр-23
                  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 14:11 , 29-Апр-23
                    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонин, 15:34 , 29-Апр-23
                      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 16:00 , 29-Апр-23
                        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Анонимусс, 22:38 , 29-Апр-23
                          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 01:37 , 30-Апр-23
                    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 21:20 , 29-Апр-23
                      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 01:42 , 30-Апр-23
                        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 19:25 , 06-Май-23
                  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 14:30 , 29-Апр-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 11:42 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:19 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноньимъ, 03:27 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,аНОНИМ, 06:23 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,n00by, 16:25 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Neon, 23:13 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,soarin, 02:11 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 03:58 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,soarin, 05:41 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 15:13 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 15:54 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Срыватель покровов, 09:15 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Neon, 23:20 , 29-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,pda, 23:15 , 28-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,аНОНИМ, 06:10 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 11:46 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,аНОНИМ, 21:39 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 22:34 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 23:27 , 29-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Neon, 23:07 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 23:28 , 29-Апр-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,Вован, 16:07 , 28-Апр-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,InuYasha, 16:08 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,аНОНИМ, 16:34 , 28-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:52 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,аНОНИМ, 06:08 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 23:29 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 19:27 , 06-Май-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 23:28 , 29-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 22:11 , 30-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 22:31 , 30-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 09:54 , 01-Май-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 10:53 , 01-Май-23
                • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 11:24 , 01-Май-23
                  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 11:34 , 01-Май-23
                  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 19:30 , 06-Май-23
                • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:53 , 01-Май-23
                  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 10:46 , 02-Май-23
                    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 19:39 , 06-Май-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 10:57 , 01-Май-23
                • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 11:05 , 01-Май-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonomus, 17:01 , 28-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:14 , 28-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonomus, 17:23 , 28-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 23:30 , 29-Апр-23
            • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:55 , 01-Май-23
              • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 19:07 , 01-Май-23
                • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 19:46 , 06-Май-23
                  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 07:57 , 07-Май-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 18:14 , 28-Апр-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 12:09 , 29-Апр-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Ivan_83, 14:36 , 29-Апр-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,AKTEON, 16:28 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:42 , 28-Апр-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,nagual, 16:30 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:36 , 28-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:19 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,anonymous, 00:33 , 29-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 10:22 , 29-Апр-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:33 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 16:41 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Фанатик, 18:08 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 08:52 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 12:03 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 13:20 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 14:30 , 29-Апр-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Michael Shigorin, 22:57 , 03-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 09:46 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 12:01 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:56 , 01-Май-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Michael Shigorin, 22:58 , 03-Май-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 19:49 , 06-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Michael Shigorin, 22:57 , 03-Май-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Прыгающий Ленивец, 12:12 , 06-Май-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:15 , 28-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 11:48 , 01-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Прыгающий Ленивец, 12:23 , 06-Май-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 10:25 , 29-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 10:48 , 29-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 17:57 , 01-Май-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Michael Shigorin, 22:59 , 03-Май-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Прыгающий Ленивец, 12:28 , 06-Май-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 19:56 , 06-Май-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,Neon, 21:50 , 29-Апр-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 22:36 , 29-Апр-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 18:00 , 01-Май-23
      • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 19:05 , 01-Май-23
        • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 20:04 , 06-Май-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 07:58 , 07-Май-23
          • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 08:00 , 07-Май-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,антилошадь, 03:52 , 30-Апр-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,nc, 21:37 , 01-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,n00by, 09:23 , 02-Май-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 10:03 , 02-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Tron is Whistling, 11:25 , 02-Май-23
• Уязвимость в процессорах Intel, приводящая к утечке данных п...,Michael Shigorin, 23:01 , 03-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных п...,Аноним, 23:19 , 04-Май-23
• Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам,Tron is Whistling, 08:08 , 07-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам,Tron is Whistling, 08:12 , 07-Май-23
  • Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам,n00by, 07:04 , 08-Май-23
    • Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам,nagual, 20:55 , 30-Май-23

Может просто надо эти дыркопроцессоры использовать в закрытом контуре? Как правильные организации.

Пересадить всех на терминалы, а все железки пусть будут в облаках кого надо?

В self hosted, например)
--
Проще 1 сервак проконтролировать и грейдить, чем десятки и сотни клиентов. Разве нет?

Ни разу не слышал о беспроцессорных тонких клиентах. ))

>эти

Это какие ? Все что ли ?
https://www.opennet.me/opennews/art.shtml?num=57629

Кроме Cortex-A<In Order>

RISCV in order ничем не хуже. Да даже вот Atom есть, он in order и ему эти OoO проблемы чужды. Правда, никто не понимает смысл существования Atom если есть ARM но это уже другой вопрос.

Вы эти риск-хайп вообще щупальцами щупали-то?  В сравнении хотя бы с in-order ARM?..

> Вы эти риск-хайп вообще щупальцами щупали-то?  В сравнении хотя бы с
> in-order ARM?..

Влобовую сравнивать тяжко: 100% идентичные чипы где разница только в Core, а параметры обвеса 1 в 1 - еще поискать. Кроме того с RISCV все только начинается и когда идет портирование и bring up, сравнивать с уже устаканившейся экосистемой - так у тех как бы фора есть. А выравнивание будет через несколько лет, когда от bring up и обезглючки смогут к оптимизациям перейти.

А хотите фокус? Видите https://github.com/T-head-Semi/openc906/ ? Это то самое, от алибабы. А теперь смотрим процессорное ядро у Allwinner D1. Рррраз! https://linux-sunxi.org/D1

Знакомьтесь, опенсорс, XXI век. Да, так можно было. Что самое интересное, алибабе allwinner уж точно не конкурент, сильно другие задачи. И кто хотел по грабелькам попрыгать с RISCV могут это сделать за копейки. Да, пока там все сыренько и WIP, но, вообще, уже можно и с майнлайном потрепыхаться.

Meltdown - это "счастье" Интела.
У АМД его нет, поскольку кеши по другому.

У AMD его нет, поскольку проверка привилегий выполняется даже при спекулятивном исполнении. Что, естественно, слегка роняет общую производительность - но в интеле видимо решили читернуть, и вышло как вышло.

Все эти спектры с ефлагсами работают только в лабораторных условиях, да и то не всегда - малейший шум от процессов, и всё, привет, ничего уже не померить.

Из реальных уязвимостей две, обе интеловские, оба-двое братья-акробатья.

Мылдаун - там устраивается реальная загрузка одной из 256 страниц в кеш в зависимости от конкретного байта по конкретному адресу, далее замер "загружено - не загружено" производится очень легко, и сторонние процессы на результат слишком сильно не влияют, загрузка страницы в кеш - операция тяжёлая.

L1TF - механизм немножко отличается, но ситуация та же - загрузка страниц в кеш без проверки привилегий.

Какой шум от процессора? Ты гуманитарий? Все что есть скомпенсируется во время вычислений.

Если у тебя такой шум что ты даже не можешь узнать когда приходит сигнал это бракованный процессор он не будет работать бай дизайн.

Ты даже не понял о каком шуме речь.
ПТУшник?

Ты даже сам не понял что за бред ты пишешь. Дорогой наш багов.нет.

Ну, чувак, на шуме от процессора основан генератор случайных чисел, так то :)

Затворы щелкают?

Хронографическая гравицапа плавает.

> У AMD его нет, поскольку проверка привилегий выполняется даже при спекулятивном исполнении.

Для уязвимости из статьи оно разве играет роль?

Уязвимость из статьи - очередная лабораторная мышь, которая в реальном мире дохнет.
Я ж специально отметил: реальных - две.

(а всё остальное больше похоже на потуги интела "у нас не хуже")

Меня реально сейчас порвёт во время переката под столом, поэтому невнимательным просьба слово "процессов" как "процессор" далее не читать :D

> то не всегда - малейший шум от процессов, и всё, привет, ничего уже не померить.

В случае коммуникационного канала плохой SNR легко компенсируется снижением битрейта. А чтобы какой-нибудь ключ или пароль передать много и не надо.

Примерно до 0, да. Суток за трое-четверо 100% нагрузки утащите один бит из соседней вкладки браузера. Вот только проблема - её закроют за это время.

> Примерно до 0, да. Суток за трое-четверо 100% нагрузки утащите один бит

Это очень смелое утверждение, выдающее что вы совершенно не разбираетесь в вопросе. Думается там другой порядок величин будет.

> из соседней вкладки браузера. Вот только проблема - её закроют за это время.

Кроме вкладок браузера есть еще вооооооон те хостеры, у которых виртуалки месяцами вкалывают и какой-нибудь приватный ключ SSH "присоседившись на машину" получить было бы весьма козырно.

Как программа минимум это может позволить мутным типам получить N машин по цене одной. Что уже довольно неплохо. Как программа максимум, можно прицельно атаковать нужный хост, покупая у нужного хостера виртуалочки пока не выпадет на нужном хосте. А потом ее уже прицельно распетрушить.

Думаю да, порядок будет 30-40 суток. Или 300-400. В реальных условиях естественно. Особенно там, где есть что тащить.

>> есть еще вооооооон те хостеры, у которых виртуалки месяцами вкалывают

Именно. И там шума столько, что через эти страшные коронавирусные дыры вы вообще ничего не утащите.

RSA-ключ будете утаскивать лет 15, вот только проблема, опять же - его за это время сменят :D

> RSA-ключ будете утаскивать лет 15,

Это на 486 чтоли? А так, если тебе хочется подаунплеить что-нибудь иди квартальные отчеты интела почитай. И расскажи как они там кого увольнять не будут с такими отчетами и как у них все ок с процами.

И да - очередная ошибка кукаретиков из ПТУ: дыры side channel - это НЕ коммуникационный канал.

В коммуникационном канале ты управляешь отправляемым сигналом. Соответственно можешь "снижать битрейт" и делать прочие фокусы как тебе заблагорассудится.

Здесь же на отправляемый сигнал ты не влияешь никак. Он идёт с "битрейтом", тебе не подвластным. Ты просто пытаешься его перехватить, сиречь померить. А чтобы померить - SNR у тебя должен быть приемлемым, иначе ты будешь мерить шум океанов Марса.

> И да - очередная ошибка кукаретиков из ПТУ: дыры side channel -
> это НЕ коммуникационный канал.

Да не пались ты так. Про скрытый коммуникационный канал прямо в новости написано. Представляешь, парочка виртуалок может так между собой коммуницировать не имея никаких легитимных полномочий на IO куда либо (например "compute-only" конфиг, который, вот, окажется не только compute-only).

> В коммуникационном канале ты управляешь отправляемым сигналом. Соответственно можешь
> "снижать битрейт" и делать прочие фокусы как тебе заблагорассудится.

А кто сказал что у атакующего в принципе никогда нет совсем никакого контроля над атакуемым объектом? Не прямой так косвенный. Откуда следует что тот или иной процесс никогда не удастся спровоцировать на полезную (атакующему) активность?

> Здесь же на отправляемый сигнал ты не влияешь никак. Он идёт с
> "битрейтом", тебе не подвластным.

Это очень храброе допущение. Зачастую некий уровень контроля все же есть. Вот смотри, есть машина, есть ssh. Я не могу напрямую команды выполнить но могу формировать разный траф, с разными времянками, прося разные алгоритмы, а вон тот probe будет мерять отклик, если удалось его на тот же железный хост присоседить. И тут большой вопрос что это не содержит никакой полезной информации, с учетом тех свойств проца.

> Ты просто пытаешься его перехватить, сиречь померить.

А может быть и спровоцировать вызов того или иного сегмента кода могу. Сам по себе это легшитимный код, ничего полезного для атакующего официально не делающий. Неофициально с учетом таких свойств проца он утекает информацию и в конечном итоге кто знает чем это может закончиться.

> А чтобы померить - SNR у тебя должен быть приемлемым, иначе
> ты будешь мерить шум океанов Марса.

Спасибо капитан очевидность. Но на самом деле в крипто бывает достаточно и небольшого bias, RC4 многострадальный подтвердит.

На заборе тоже написано. Не вижу смысла продолжать, без базовых знаний понимание невозможно.

"парочка виртуалок может так между собой коммуницировать"
Вот это как раз и будет коммуникационный канал. Где ты управляешь и приёмником и передатчиком.
А "ойязвимости" с попытками применения только приёмника - это не коммуникационный канал. Это попытка перехвата сигнала.

мда... я надеялся что уже все ошибки спекулятивного выполнения закрыли патчами, а тут новая в решете :(
и ради +пару% скорости получаешь дырень в железе

напоминает адептов одного известного дырявого языка пограмирования, они тоже ради быстродействия готовы CVEшки писать

Это ты про Rust что ли? Да, они умеют, упиваясь своей иллюзией безопасности забывать о базовых вещах, ну CVE-2021-28032, например.

уязвимость в крейте (насколько я понимаю что-то типа либы, которую поддерживает какой-то чувак) в языке на котором почти ничего не написано? оно вообще в "std"?
как-то мелковато

я про например CVE-2022-2602 - бац и получаешь up привилегий в системе.
или CVE-2022-1966, CVE-2022-32250 - то же самоее
или еще лучше CVE-2023-1998 - позволяет обойти защиту от атак Spectre v2 (а зачем если есть еще куча дыр?)

еще можно вспомнить heartbleed... да тысячи их
каждую неделю на пеньке обсуждаются

Так heartbleed и не заявлял что он серебряная пуля безопасности в отличии от сомнительных ребят из мозиллы.
Ну а спектр, мелтдовн это скорее аппаратная особенность, которую очень хотят закрыть программными патчам, что иначе чем костылями и не назовешь, ну и результат соответствующий.
Ну а колосс раста опять разваливается - теперь вот и "крейт это не раст, а поделие какого-то чувака". На тот факт что и раст делали студенты (и пара сомнительных парней постарше) старательно не обращают внимание.

> я про например CVE-2022-2602 - бац и получаешь up привилегий в системе

кому это мешает кроме корпораций, зачем этот io_uring на пека и мобилах обычных пользователей ?

Затем, что это лучше, что придумали в event-driven со времён select.

Судя по тому что ты говоришь, у тебя нет вышки даже (или она была высижена задницей). Иначе невозможно объяснить, как ты баг во внешнем крейте записал в недостатки языка. Основы логики ж проходят на первых курсах!!

Интересно получается.
Как преимущества, так "легко и безопасно писать", "есть пакетный менеджер" и "куча безопасных библиотек есть и вот-вот еще больше наклепаем".
А как уязвимости так "это не раст", "это виноват разработчик", "не чуешь разницу между пакетным менеджером я языком?".
Ну так и в си уязвимости в либах и в руках разработчика, о чем вам еще в 2015 говорили.
Гребанные смузихлебы.

Может потому у Раста и нет стандарта? В Си библиотека получается частью языка.

в какой-то момент косякнули, решив совместить проверку привилегий вместе с актуализацией спекулятивного вычисления (по логике "в лоб" проверку надо было делать перед вычислением, возможно это усложняло схему), а теперь переделывать поздно.

Если 'проверять привилегии' до исполнения, само исполнение вместе с этой проверкой займёт раз 10 дольше времени.

...поэтому давайте отдадим свои данные рандомному скрипту запущенному в браузере

А Столлман предупреждал не запускать рандомные скрипты

а кто тебя будет спрашивать)?
с noscript половина интернета просто не откроется

просто надо делать чтобы браузер жил в "контейнере" с ограниченными привилегиями
не делать дырявые процессоры
ну и не писать дырявый код
все просто)

Так это... чтобы изоляция помогла, надо _каждую_ вкладку в отдельном контейнере, а не просто браузер. И то не факт, что помогут контейнеры, а не придётся каждую вкладку в отдельную виртуальную машину.

> с noscript половина интернета просто не откроется

А на хрена так делать ?!

Кто это?

Тот, кто не призывал хлебать смузи по каждому поводу и без повода.

А я всегда так делаю

Проверка нескольких бит увеличит время исполнения в 10 раз? По-моему, вы фантазируете.

Представь что в магазин не будут пускать нового покупателя, пока предыдущий не выберет, не оплатит, не сложит свои покупки и не выйдет из магазина. Вот нечто похожее и будет с процессором.

неудачная метафора подобна котенку с дверцей...

ну ладно, чего от гуманитариев еще ожидать, так вот в твоем случае оба покупателя скидывают все покупки в одну тележку
и потом один начинает тырить чужие купленные и оплаченные товары: макарошки, пельмени, бутылку джек-дениелса....

ты бы сильно обрадовался, что так быстро закончил поход в магазин если бы недосчитался вышеперчисленного?

10 там не будет никаким боком, но скорей всего пришлось бы делать копию TLB для каждой спекулятивной ветки, чтобы её исполнение не тормозило основное вычисление (фактически это ещё один недо-поток). Но в то же время была бы экономия за счёт того, что эти ветки обрывались на ошибке доступа, а не продолжали бы обсчитывать заведомо ненужное.

Чтобы вы понимали, на С писали ещё тогда когда производительности компа не хватало чтобы mp3 проиграть, а авторы раста ходили в садик.
При тех выч мощностях их бы послали даже не на 3 буквы на пинками, потому что их поделие тормозило бы дико, настолько что смысла его даже рассматривать нет.

Выбор был: пишем на С (может с асмовыми вставками) чтобы тяжёлые вычисления не тормозили или пишем на вижалбейсике или чем то подобном когда надо быстро накидать прототип или гуй.

То что сейчас кресты расжирели невероятно и появилась гниль (раст) - это следствие прогресса, который вы пытаетесь помножить на ноль.

> С писали ещё тогда когда производительности компа не хватало чтобы mp3 проиграть

Ты абсолютно, на все 146% прав. Но те времена канули в Лету.
Программы стали на десятки порядков сложнее, кодовая база выросла даже не знаю... на 1к%, на 10к%?
Можно сравнить ядро v1.0 и последнее v6.3. Можно даже выкинуть из него коды драйверов.

И старые инструменты оказались неприспособленными для этого.
Они постоянно приводят к однотипным проблемам, раз за разом одно и тоже.

Поэтому и инструменты должны меняться.
Сейчас поле обрабатывает навороченный трактор с gps, лидаром и кондишкой, а не раскидывают навоз палкой-копалкой. Хотя... кому-то палка роднее.

Так и С не стоит на месте, обновился и стандарт и компиляторы стали сильно умнее, появились анализаторы кода, появился ASAN и valgrind.

А программы - они просто наросли поверх того что было.
В ядро понапихали всякого нового, далеко не всегда нужного кому либо вообще.

Угу, а ошибки все те же.

> обновился и стандарт и компиляторы стали сильно умнее

Какой там стандарт в ядре? В ядре 5.18 (May 2022) они перешли на с11. В 22м году на с11.
Но это конечно же прорыв)) Потому что до этого там было gnu89. Всего 30+ лет отставания.

Если бы вы знали разницу то не ёрничали бы, в данном случае это скорее про требования к компилятору по фичам.

Ты не понял. Проблемы как раз из-за того что тянут совместимость с Си в процессоре. Код пишется для виртуальной Си машины. Все твои умствования упираются в реальность что проблема в том что тащат везде Си. Для Эльбрусов это хорошо потому как там нет замороченной внутренней архитектуры процессора, а вот в х86 чокнутых заморочек вагоны и отсюда все дыры.
Код языка можешь как угодно себе в голове вырисовывать, но я сомневаюсь что ты изучал тот же раст или другие языки. Если для безопасной работы с памятью нужно переписать драйвера на раст это хорошее решение.

> Код пишется для виртуальной Си машины

долго смеялся над этим растоманом в голос.

> Если для безопасной работы с памятью нужно переписать драйвера на раст это хорошее решение.

А я люблю переписывать все на расте и хвастаться. Каждый день я хожу по gitlab и github с git clone  и собераю всю C legacy какую вижу. На два полных гигабайта целый день уходит. Зато, когда после тяжёлого дня я прихожу домой [... продолжайте сами ...]

Шедеврально!
Вы настоящий растоман, поздравляю вас!

Нет, я ничего не изучал, с детства разговариваю на С, в садике меня никто не понимал, в школе тоже :))))

Начинал я с бесика на z80, там же дошёл до асма.
Потом был квик бейсик под дос, не долго, потом вижал бейсик, а потом его стало мало (где то за 2 года я стал гуру) и наконец то приобщился к элите и познал С, язык на котором в 2003 году можно было сделать всё что угодно в венде. И до сих пор на любой платформе и любой ОС я могу делать что угодно на С.
Перл, пхп, питон, вала, шелскрипт, луа, джава, джаваскрипт и хз что ещё - что то писал/правил по мелочи, мне не особо интересно что там у языков и как, нужный мне результат я получил не вникая.

>Угу, а ошибки все те же.

Так и в расте те же ошибки будут. Только вы сначала будете говорить "это unsafe", "это особенность реализации в линуксовом ядре", "это разработчик либы ошибся", "это код старый на новой архитектуре". Поотбиваетесь так несколько лет, может накормите обещаниями, а в итоге убежите на какой-нибудь новый хайповый язык с маркетингом лекарства от рака ("программирование через нейросети, пишешь промт и язык сам создает и обновляет безопасное и быстрое приложение, со временем будет все больше обучаться и становиться безопаснее"). И уже в нем будете наступать на те же грабли.

>Программы стали на десятки порядков сложнее

Чево? Один порядок - это в 10 раз. Два порядка - 100 раз. В десятичной системе, разумеется.
Гумо-не-тарий?

> Сейчас поле обрабатывает навороченный трактор с gps, лидаром и кондишкой, а не
> раскидывают навоз палкой-копалкой. Хотя... кому-то палка роднее.

А вон там, в Сан Франциско, народ хренеет с пробок. Сообщения о пробках в очередном крупном городе были бы, конечно, ничем не примечательны, если бы пробки не устраивали БЕСПИЛОТНЫЕ такси. Так что таксисты уже могут начинать понемногу сушить весла, это уже масспрод и его проблемы.

>  появилась гниль (раст)

давай больше пафоса) можешь рассказать про грибы порабощающие людей и прочие байки с РенТВ

а если серьезно то ты прав
на С писали в те времена когда:
1. разработкой занимались крутые перцы на зарплатах от универов, которые бесплатно делились програмками на дискетках
всем было плевать на то что язык состоит на половину из UB

2. ни о какой безопасности никто не думал, банков и онлайн покупок не было, облаков с фотками и  соц.сетей тоже

3. интернет был на начальном этапе развития (в виде университетских сетей), а потом просто медленный
это сейчас могут взломать сайт и выкачать 100500 гигов, а тогда надо было ехать к тебе домой, бить физиономию и отбирать комп целиком

4. программы были проще; кодовая база с тех времен увеличилась на порядки, просто посмотри размер ядра линука по годам и сейчас
требования к программам были меньше; обычный текстовый квест вызывал неподельный восторг, а сейчас попробуй объяснить, что мышка это излишество

5. никто не думал о том что будет многопоточность, виртуализация, контейнеры и  гипервизоры
что на одном компе будут крутиться одновременно куча сервисов

эти времена прошли, но до сих пор многие СИшники совершают одни и те же ошибки как и 15-20 лет назад: выходят за границы массивов, портят память соседям, очищают ее дважды и тд

Это как убеждать деда алкаша, что туалет вида "дырка в полу" это уже устаревшее, он тебе расскажет о том какой он крутой был в молодости и как из дырки удобно какахи вычерпывать. Ну и еще что-то про молодеж и смузихлебов.

Но есть и другие люди знакомы с проблемой и то что она не решается десятилетиями.
Например Линус Торвальдс.
Именно поэтому раст добавляется в ядро (а не отвратительные плюсы)

Проблема не в инструментах а в тех кто ими пользуется.
У современного поколения уже просто фобия перед С, замечу что это из области психи а не техники.
Если кто то совершает одни и теже ошибки - это опять же проблема его необучаемости.

1. И раньше писали разные люди и сильно по разному, и делились и нет, в этом плане мало что поменялось, разве что делится нынче стало на порядки проще.

2. Думали в первую очередь о скорости, потом чтобы не падало.
Эти приоритеты и сейсач никуда не делись, я лично не готов терпеть лаги только ради мнимой безопасности.
Банки онлайн были где то с 2005 года, по крайней мере я тогда уже точно видел их. У меня один клиент жаловался что SSL не работает и он туда попасть не может, оказалось зря я FIPS включил в групповой политике :)

5. Виртуализация, контейнеры, гипервизоры - это костыли.

Есть уже давно высокоуровневые языки, кому не нравится С - уходят туда, но это не останавливает их от таких же банальных ошибок.

Торвальдс не сам притащил гниль в ядро, он не стал сильно мешать этому, это сильно разные действия.
И чтобы вы знали, у венды есть кресты в ядре, и там дрова на крестах можно писать, кажется даже по дефолту подразумевается что ты на крестах пишешь, по крайней мере мне так запомнилось.

Опять пердежь в лужу. Знающие люди говорят что люди просто не разберутся в современном коде почему он так написан. За примером ходить далеко ненужно - взять те же иксы.
Вот иди сначала потрать время выясни хоть что-то прежде чем вещать с офигеть важной миной.

И как раст предлагает решать возрастающую сложность кода?
А никак. Но си который старается не делать лишних абстракций это плохо, а раст который делает DSL для макросов и смешивает разные модули (вроде линтера и компилятора) это почему-то хорошо.

> А никак.

А вот и нет. У раста есть куча вещей - мелких и не очень для этого.

Модули, крейты, пакеты позволяют легко дробить код на логические составляющие и изолировать друг от друга. Писать тесты - юнит тесты, модульные, интеграционные. Причем юнит-тесты пишутся в самом же коде, что очень удобно, т.к. можно без костылей тестировать приватные апи.

DSL для макросов как раз прекрасное решение, намного лучше тупого #define, потому что будет если у тебя в двух файлах два одинаковых #define? А в расте при коллизии имен ты просто указываешь "путь" к нужному.

Или напр. enum. Ну, в си они убогие by design, но еще добавляют проблем - значения должны быть уникальны во всех енамах. И опять привет коллизии. Или уродливые уникальные имена. В плюсах это решили через enum class, а в си, на момент когда о нее пришлось последний раз мараться, нет.

Нормальные "протоколы" в виде трейтов. Мощнейший инструмент, позволяет отделить "намерение" от "реализации", писать нормальные моки для тестов, заодно и избавляющий от кучи ошибок типизации. И необходимости передавать void* в качестве параметра))

> смешивает разные модули (вроде линтера и компилятора)

Конечно это хорошо - оно позволяет получить такой мощный анализ на этапе компиляции.
Даже не понятно, почему думаете что это плохо? Потому что раньше так не делали?

> Но си который старается не делать лишних абстракций это плохо

Плохо не то, что си "старается не делать лишних абстракций", а плохо то, что они не делают их когда это нужно. Вместо написания простых оберток над примитивами и работы с ними, используются чистые примитивы в десятках мест и в одном из них допускается косяк.

Вы обмазываетесь синтаксическим сахаром вместо решения реальных проблем.
Всё что вы описали это фап на сам процесс.

В случае раста это даже не сахар, это какие-то синтаксические экскременты.

Не удивительно что ваши "знающие" гнилеманы ни в чём кроме гнили разобратся не могут, у них мозги думают только про гнилостный сахар а не про технологии.

Ванюша, ну что ж ты все время к оскорблениям скатываешься - гниль, гниль, гниль - может что-то новое можешь сказать?

Спасибо, мы уже поняли что ты, отбитый, застрял где-то в 2000х и фапаешь на те времена.
Ну так и оставайся там вместе со своих Z80, вижуалбейсиком и божественной сишечкой без синтаксического сахара.
Печалька конечно, что ничего большего ты осилить не в состоянии, да и желания у тебя нет - все и так устраивает, как это у дидов было. И никакого сахара - чем больше строк кода, тем лучше.

Но что поделаешь, что за столько лет сишники так и не придумали как не допускать детских ошибок.
Приходится думать за них.

Так это же перевод, локализация названия, чего оно вам так режет уши?

Сишечка позволяет насыпать любое количество сахара, просто со времинем понимаешь что много сахара - зло, и стремишься его минимизировать дабы не писать "сектансткий код" который будет понятен только тебе. (сектанты заменяют термины и вводят свой новояз как средство для изоляции адептов от общества)

Сообщаю вам что у дедов всё хорошо и вы почему то до сих пор на всём дедовском живёте, так ничего своего и не сделав.
А детские ошибки вы как раз и совершаете, как и большая часть индустрии вы не в силах осознать что простой синтаксис - гарантия распространённости как среди носителей так и реализаций.
Высокоуровневым языкам это простительно, там задачи немного другие, а тому что претендует на роль системного языка нет.
В итоге будут очередные с++, д и прочая фигня которая имеет свою узкую нишу, из которой гниль никогда не вылезет.

Вообще-то "гниль" - это "rot", "putridness".
"Гниение" - это те же "rot", "putrescence", "decay", иносказательно "corruption".

Чтобы перевести "rust" как-то по-другому чем "ржавчина" или "коррозия", нужно быть представителем самой читающей нации и получить лучше в мире образование. Впрочем, остальные утверждения только показывают, что с программирование дела обстоят аналогично.

> Но что поделаешь, что за столько лет сишники так и не придумали
> как не допускать детских ошибок.

Вот те раз, MISRA даже бизнес на этом делает - и все "не придумали". Но вообще, статический анализатор можно и нашару запустить, так то.

> Приходится думать за них.

Такие думатели обычно решив 1 проблему создают 5 новых, значительно более сложных. Ну вот например что типовой хрустик будет делать если майкрософт его забанит в каргокульте? По причине ссанций или там какая сегодня левая пятка майкрософту что подсказала. Ты же не думаешь что их карманный директор в борде возбухать против этого станет?

> Банки онлайн были где то с 2005 года

банки онлайн (по диалапу или интернету) были с 2002 года.
помню как сейчас - клиент-банк местного сбербанка, ppp через диалап,
я отследил взаимодействие клиента и сервера и запретил все остальное фаерволлом
(NT4, WinRoute). потом очень злорадствовал, когда кое-кто подцепил оттуда
самоходную программу, предположительно от соседей по модемному пулу.

> У современного поколения уже просто фобия перед С, замечу что это из
> области психи а не техники.

У них скоорее проблема в hype driven. Стадный эффект. Маркетинг. Нет хайпа - все, это не круто.

В результате, правда, заканчивается тем что проекты фэйлятся оптом и в розницу т.к. даже если нахватать супертулов решающих все проблемы человечества это никак не улучшает уровень кодера и чуда не случается. Зато вон гора кода с периодом полураспада в год. См. как из демьяна удалили кучу поддержки матрикса, потому что мутный питонокод выкинули, он был такой что кроме автора никто ЭТО поддерживать не захотел.

Ну а потом начинаются массовые увольнения когда все эти прожЕкты сыпятся там и тут. Фэйсбук, майкрософт, твиттер, редхат... тактактак, кто следующий клиент thelayoff-ком, или как там его? Ща всех бесполезных и легко заменимых хайпонашек и побустают.

> Если кто то совершает одни и теже ошибки - это опять же
> проблема его необучаемости.

Абсолютно. И верования в серебряные пули способствуют факапам кодеров и фэйлам проектов. Почему-то.

> Эти приоритеты и сейсач никуда не делись, я лично не готов терпеть
> лаги только ради мнимой безопасности.

Ну вот лично я не использую по этому код на питоне и электроне. В принципе.

> SSL не работает и он туда попасть не может, оказалось зря
> я FIPS включил в групповой политике :)

FIPS очень специфичная штука регламентирующая криптоалгоритмы и включать ЭТО в любой настройке где оно есть надо ТОЛЬКО если от вас требуют комплайнс и требователи готовы к тому что за этим следует. В остальных случаях это грабли.

> 5. Виртуализация, контейнеры, гипервизоры - это костыли.

Можно конечно сказать что разделение корабля на герметичные отчеки это костыль, дескать, нормальный корабль не должен пробоины получать. Но на практике почему-то все пришли к герметичным отсекам, что улучшает шансы корабля не пойти на дно если какая-то хрень все же случилась. А в sci-fi это и космических кораблей касается.

> но это не останавливает их от таких же банальных ошибок.

Верования в то что тул подумает за кодера напротив ведут к появлению напыщенных и некомпетентных типажей, чей код раздалбывать одно удовольствие. Его достаточно тронуть немного и все разваливается.

> Торвальдс не сам притащил гниль в ядро, он не стал сильно мешать
> этому, это сильно разные действия.

Торвальдс видимо хочет посмотреть что у них получится. А почему бы и нет? У сей есть свои назойливые антифичи, и любой кто кодил что-то крупнее хелловорлда знает об этом. И а частности например работа с integer, pointer и UB. Первое в сях просто определено абы как и кодить на этом без багов рокетсайнс. Скажите вашему крупному проекту -Wconversion и расскажите как вам оно. Второе сделано так что не подлежит полноценному статическому анализу. Третьего слишком много в стандартах. Так быть не должно.

> дрова на крестах можно писать, кажется даже по дефолту подразумевается что
> ты на крестах пишешь, по крайней мере мне так запомнилось.

У винды так то и не осталось почти системных кодеров. Майкрософт всех разогнал.

Вы так пишите как-будто до поганой сишки и риск процессоров ничего не было.
А оно было.

>многопоточность, виртуализация, контейнеры и  гипервизоры

Костыли си процессоров.

>>многопоточность, виртуализация, контейнеры и  гипервизоры
> Костыли си процессоров.

Проблемы фанбоев в том, что они даже не удосужились ознакомиться с историей вычислительной техники. Все вышеотквоченное появилось задолго до сей.

Да, появились до сей, но в других формах наверное.

Раньше оно было в форме шкафа, а теперь в форме телефона.

> Раньше оно было в форме шкафа, а теперь в форме телефона.

Да уже и в форме SD-карточки есть. Да что там, вон та штука, меньше рисового зерна, умещает в себе больше чем тот шкаф.

Я так думаю, что человек неуклюже указал на "сходимость" в точку направлений развития языка и железа, их "тянет друг к другу". Смотри, проги для типичного компа в последние десятилетия в большинстве своем написаны на Си/Си++. При проектировании очередного, нового процессора, инженеры ориентируются в немалой степени и на существующий прикладной софт, который будет на новом изделии крутиться и который в основном на си/плюсах. И синтетические тесты потом крутят и из реальных программ попугаев выдавливают. Смотрят по существующим программам что там как типично ветвится, как данные гоняются, чтобы кэши оптимальнее загрузить, что можно распараллелить по конвеерам и до какой степени и т.д. и т.п. В свою очередь создатели компиляторов этих самых распространенных языков (и изредка создатели простых программ, где это нужно), опираясь на меняющуюся архитектуру процессора, выжимают из него оптимизациями всё что могут, подгоняют под ЦПУ - выравнивают данные в памяти, раскручивают циклы и т.д. и т.п. Такой вот постоянный непрерывный процесс сходимости двух сторон, программной и железячной, к синергии, подстройки друг к другу. А программная ширпотребная часть, повторюсь, в основном написана на си/плюсах.

Вы просто гениальный растоман!
Вам надо на конференциях доклады делать, гарантирую их будут смотреть все, только ради вас.

Как это принято у растоманов смешались в кучу кони, люди, языки, процессоры, архитектура, вирутуализация, времена, нравы и над всем этим конечно же царит адский си. Вот уж фантазия у людей бывает.

> При тех выч мощностях их бы послали даже не на 3 буквы на пинками, потому что их поделие тормозило бы дико, настолько что смысла его даже рассматривать нет.

Нет, дело не в том, что поделие бы тормозило, дело в том, что у тех процессоров не было современных техник оптимизации, а если бы они были, никаких суперкомпьютеров не хватило бы эти оптимизации проводить при компиляции.

> следствие прогресса, который вы пытаетесь помножить на ноль.

Глупости. Если современная техника лучше допотопной и позволяет писать и выполнять безопасный код, то какой смысл возиться с небезопасным? Ты ещё порекомендуй отказаться от языков высокого уровня, потому что когда-то компьютеры не могли компилировать и всё надо было писать на ассемблере и ещё нанимать девочек, которые будут мнемоники переводить в машинные коды.

Зачем мне ваша безопасность если оно жрёт и память и проц как не в себя а пользу я не вижу?

Поясню.
Мне не нужна безопасность какая то там, у меня для этого замок на двери, и если будет мало я куплю ствол и подключю сигнализацию.
Мне от компьютера нужно то что я заказывал - обработать нужную мне информацию и показать результат.

Вы же сами не понимаете нифига в безопасности, только как попугаи повторяете друг за другом, у вас просто религиозный культ.

Так проблема в том что "а пользу я не вижу".

> Мне от компьютера нужно то что я заказывал - обработать нужную мне информацию и показать результат.

Прям как в 80х! Не хватает только девочек с прикладной, которые будут забивать код в эвм))
Ну не самому же это делать в самом деле)

Объясняю на простом и доступном языке.

Я покупаю перфоратор потому что мне нужны дырки в стене которые он делает.
Мне не нужен перфоратор, не нужны буры, не нужен чемоданчик с запасными щётками, смазкой и тп, мне нужны ДЫРКИ в стене.

Точно так же с компьютером.
Я его купил чтобы лазать по инету, играть в игры, общатся.
Иногда мне приходится самому что то там дописывать, править баги, писать вообще новые проги с нуля - но только потому что мне нужен результат работы этих программ, не сами программы/патчи.

Вы со своей гнилью предлагаете мне вместо обычного перфоратора бош купить херош который стоит в 10х, жрёт электричества 10х, шумит 10х, при этом делает точно такие же дырки с стене, но в 10х раз медленнее.
Зато у него двойная изоляция на проводе, дифф автомат в вилке, и защита от дурака так чтобы я буром себе бошку не продырявил.

Нет, мне не интересно, пользуйтесь такми сами раз у вас столько фобий, я не боюсь ударов током и лишних дырок в организме настолько чтобы так страдать.

Объясняю на простом и доступном языке.

Ты считаешь что если тебе что-то не нужно, то это не нужно и всем остальным.
Это первая и самая важная ошибка. Тебе нужен комп чтобы он тебе что-то считал, на мобиле у тебя только пароль от wifi, а безопасность сводится к сигналке и стволу.
И больше тебе ничего не нужно. Но это ТВОИ ЛИЧНЫЕ проблемы.
Зато можешь поныть в интернетиках, смотря на прогресс.

> cтоит в 10х, жрёт электричества 10х, шумит 10х

Какая же бездарная брехня... Даже джава редко настолько медленнее чем дыряшка.
Основная идея раста как раз сделать все возможные проверки в compile-time.
И минимальное кол-во проверок во время выполнения.

И дело не в фобиях. Можно ездить на машине с коробкой без синхронизаторов. Можно взять старое двигло и каждые пару тысяч настраивать зазоры клапанов. Или менять прохудившиеся прокладки головки двигателя.
Но зачем? Не, ну хочется - вперед, но большинству это нафиг не сдалось.

> я не боюсь ударов током и лишних дырок в организме

Ну если действительно так, то осчастливь мир и сделай пару новых дырок))

PS. в перфах бош как раз двойная изоляция, плавный пуск и муфта от заклинивания.
Они заботятся о безопасности своих пользователей.

Меня устраивает то как оно есть сейчас, это вы с гнилью во все щели лезите.

С вам тоже разрешает включить массу compile time проверок, я вот включаю у себя в проектах, а то что другие не включают - это не проблема С.
Ходите с петицией к компиляторщикам чтобы включали всё по дефолту и -Werror заодно, получится не хуже вашей гнили, ругани будет точно больше.

Ещё раз, мне пофик что у боша, я купил дырки. )

> Даже джава редко настолько медленнее

Ну если копнуть историю, то java разрабатывалась для SPARC. И там она была вполне себе. С учётом всей сановской архитектуры. Даже на телефонах работала. Но Интел - это же другое, да. То, что её начали туда пихать, на железки которые до сих пор не имеют шин типа SBUS, NBUS - это "веяние рынка". Sun проcpали патамушта дорого.

> большинству это нафиг не сдалось

Большинству вообще ничего нафиг не сдалось, три основных функции организма - ихнее всё.

>PS. в перфах бош как раз двойная изоляция, плавный пуск и муфта от заклинивания.

И чо? Сдохнет скоро твой бош, как и вся европейская промышленность.

> И чо? Сдохнет скоро твой бош, как и вся европейская промышленность.

Очень интересно как какой-нибудь сименс с их промышленными контроллерами сдохнет. Может у них еще и конкуренты есть? :)

>мне нужны ДЫРКИ в стене.

Стеночный дырофил?

> Так проблема в том что "а пользу я не вижу".

Представляешь, для начала компьютер должен работать. И желательно - хорошо. А постоянные тупнями, лаги и дергание программ с ломовым жрачем ресурсов вызывают у пользователей только ненависть. Хоть трижды безопасно оно там будет, это не сильно ценно если остальные параметры трэш. А ультрабезопасность дорогой ценой пользователям не особо надо, такая вот печаль. Они лучше Win95 без системой прав будут пользоваться если UX лучше. И пользовались, т.к. это позволяло более дешевому компу шустро работать, а NT4 да и винтукей не очень хорошо продавались и даже такой кадавр как MS смог на более безопасную архитектуру ос перейти лишь с 3 серьезной попытки (у них и иные причины были, и много).

> а пользу я не вижу?

Глаза продери, может увидишь.

Ой, а чего это ты вдруг тему решил сменить? Я ему про Фому, он мне про Ерёму.

Ты заявил, что раст был невозможен в 70-е из-за тормознутости программ. Я говорю тебе, что нет. Он был невозможен из-за тормознутости компилятора: компилятор выполняет очень много работы, столько, сколько в 70-х было невозможно выполнить. А вот результат, в плане производительности и потребления памяти, как правило в пределах статистической погрешности от результата на C. Иногда быстрее, иногда медленнее, но там речь идёт о единицах процентов или меньше.

Да какие там 70-е, до CORE арихитектуры растоманов бы то 100% выгоняли везде понятнокакими тряпками.
У меня почти топовый п3 не мог обычный 720p h.264 проиграть программно, а тут ещё вы со своей поделкой.

Проверки там не все компиле тайм, и абстракции и прочий сахар тоже не бесплатный, поэтому на примитивном коде может быть около нулевая разница, а на практических реализациях разница может улететь в разы, как с крестами я неоднократно видел.

Потом у С компилетайм проверки почему то не тормозят, а у современного С их там очень не мало.

И последнее.
Если вы посмотрите на самые частые и проблемные события в бизапаснасте то обычно это социнжиниринг и ошибки в конфигурациях, ошибки логические тоже часто встречаются и они от языка не зависят.
Собственно ошибки связанные с особеностями С занимают весьма скромное место, и на мой взгляд не стоят решения через гниль.

> а на практических реализациях разница может улететь в разы

но пруфцов мы как всегда от тебя не дождемся?

> как с крестами я неоднократно видел.

гениально! берем один язык и говорим что совсем другой ведет себя аналогично

> Собственно ошибки связанные с особеностями С занимают весьма скромное место, и на мой взгляд не стоят решения через гниль.

просто вранье на вранье))
Давай откроем cvedetails для кернела, напр за 2022год, потому что 23 еще в процессе, и отсортируем по score от 7 и выше
CVE-2022-0435 - Overflow

CVE-2022-34918 - Buffer Overflow
CVE-2022-32250 - Use After Free
CVE-2022-29581 - Use After Free
CVE-2022-29156 - Double Free
CVE-2022-28893 - Use After Free
CVE-2022-23222 - NULL Pointer Dereference
CVE-2022-1998 - Use After Free
CVE-2022-1943 - Out-of-bounds Write
CVE-2022-1882 - Use After Free
CVE-2022-1786 - Use After Free
CVE-2022-1679 - Use After Free
CVE-2022-1652 - Use After Free
CVE-2022-1116 - Integer Overflow or Wraparound (юху! что-то новенькое!)
CVE-2022-0998 - Integer Overflow or Wraparound (ладно, не такое уж новенькое)
CVE-2022-0995 - Out-of-bounds Write
CVE-2022-0847 - Improper Initialization (ура! первая логическая... ну, как логическая, этот хлам просто позволяет так делать)
CVE-2022-0742 - Failure to Release Memory Before Removing Last Reference ('Memory Leak')
CVE-2022-0646 - Incomplete Cleanup (вторая логическая! но если бы был бы нормальный RAII, хотя стоп, мы же про си говорим, какой RAII...)
CVE-2022-0500 - Failure to Constrain Operations within the Bounds of a Memory Buffer
CVE-2022-0185 - Integer Overflow or Wraparound
CVE-2021-34866 - Access of Resource Using Incompatible Type ('Type Confusion') - логическая, исправляется нормальной системой типов
CVE-2021-22600 - Double Free
СVE-2021-4197 - Improper Authentication - логическая
CVE-2021-4157 - Failure to Constrain Operations within the Bounds of a Memory Buffer
CVE-2021-4154 - Use After Free
CVE-2021-4093 - Out-of-bounds Read
CVE-2021-3847 - Improper Preservation of Permissions - логическая
CVE-2021-3773 - хз, пусть будет логическая
CVE-2021-3760 - Use After Free
CVE-2021-3752 - Use After Free
CVE-2021-3715 - Use After Free
CVE-2021-3656 - Missing Authorization - логическая

Итого - у нас 33 ошибки, из которых максимум 7 логических, а остальные 26 (или 79%) - традиционное сишное д***мо с памятью.

И даже если раст смог бы избавить не от всех этих ошибок, а только от половины - то все равно бы "недопущенных" было бы больше чем логических.

И сколько дыряшного кода не приводит к CVE - можно только гадать.
А ты можешь думать что хочешь)))

Не дождётесь, я ж на гниле не пишу.

Всего 33 типа ошибки на такую огромную кодовую базу, давай покажи сколько с помощью них нахакали.

Вот тебе новость: http://www.opennet.me/opennews/art.shtml?num=59036
и такого полно, и всякое прямо без паролей в инет выставляют - даже ломать не надо.
Я это к тому, что в денежном эквиваленте ущерб от этих ошибок вообще не виден на общем фоне.

Потом сходи посмотри на вордпресс какойнить, который на пхп где С ошибок и близко нет, и оцени сколько ошибок там и насколько они эксплатируемые, и учти что кодовая база там по меньше.

> Всего 33 типа ошибки на такую огромную кодовую базу

Мда... ты опять недогоняешь. Это 33 cve за 2022 год с скором больше 7. А самих cve на порядок больше - 300 с чем-то за тот же год. Плюс не каждый баг является CVE. Думаю обычных багов порядка на два-три больше.

Поэтому еще раз - из группы ошибок, которые представляют наибольшую угрозу для безопасности пользователя - 79% сишного рукодупство с памятью. Что 10 лет назад, что 20 лет назад, что сейчас - сплошные out-of-bounds, use-after-free, double-free и тд. Сишники... сишники никогда не меняются

> Я это к тому, что в денежном эквиваленте ущерб от этих ошибок вообще не виден на общем фоне.

И пруфцов как обычно не будет?)

> Потом сходи посмотри на вордпресс

Ахаха, вот мы и скатились до сравнения ядра линукса с поделками на пыхе! Шикарно.
Может еще сравним с лабами школьников из спецшкол? На их фоне ядро будет выглядеть прост прекрасно.

Чувак, жизнь полна ошибок, ошибатся, признавать ошибки, исправлять ошибки - таков путь.

Я не знаю как вас воспитывали и обучали (надеюсь не сильно били током) что вы так боитесь любых ошибок.

Пых такой же как раст, или вы думаете что расте будут писать какие то особенные эльфы, совсем не похожие на гоблинов с пхп?
Любой высокоуровневый язык привлекает как раз низко квалифицированных разрабов, которые ничего не понимают и не хотят понимать.
А поскольку гниль пеарят как "язык для илиты где нет ошибак" то он быстро наберёт как раз разрабов уровня пхп пограмист, которые будут везде с умным видом говорить: "раз собралось значит ашибак нет, капелятыр гарантырует!" и будет плести кучу умных слов про трейты, тесты и прочее.

Не нравится пхп, возми какую нить джангу на петоне, или любой другой достаточно крупный проект на любом относительно выкоуровневом языке.

Те я веду к том, что среднее колличество ошибок относительно кодовой базы примерно постоянная величина если специально не проводить отбора пограмистов и специально не вводить в процесс разработки методики для уменьшения ошибок и их раннего обнаружения.
Условно через 10 лет на гниле будет быдлокодеров даже больше, потому что они придут с улицы и не будут нифига понимать в происходящем.
Это сейчас под действием пропаганды на гнль свитчатся всякие Сишники и крестовики которые что то видели и им надоело думать о том откуда берутся ошибки.

Мы не боимся ошибок. Просто на ошибках надо учиться. А не повторять их из года в года с жалкими оправданиями.
Ну а если ты не учишься... то у меня для тебя плохие новости))

А на си сейчас пишут великие умы? Или какие-то особенные эльфы?
Нет, такие же быдлокодеры что на пыхе, только с непомерным ЧСВ.

> и будет плести кучу умных слов про трейты, тесты и прочее.

Ахаха, ну да, тесты не нужны))

Мне пофиг на логически ошибки в проекте - они всегда были и будут.
Но вот не нравится, что условный чат клиент получит доступ куда не положено потому, что его разраб использует дырявый ImageMagick, быдлокодер которого не удосужился проверить входные данные.
Или получит рут, прислав как любят говорить, "специально оформленный пакет".

> Это сейчас под действием пропаганды на гнль свитчатся всякие Сишники и крестовики

Так это ж прекрасно! Если слабый разраб умудриться допустить ошибку с памятью в расте, только представь что он может натворить в проекте на с++ или си)))

Раз вы их не боитесь - чего постоянно о них говорите?

Ошибки повторяют и ли не обучаемые или по забывчивости, не внимательности либо их совершают в первый раз.
Это проблема людей, не языка.

На С пишут те кто может себе это позволить.
Все неосиляторы уходят на языки высокого уровня и какакодят там.
Какакодеры с пыха и петона и прочих не идут на С почти никогда потому что у них ничего не собирается, потом ничего не работает и падает непонятно почему.

Чтобы вас не беспокоило что у вас кто то там рут получит или ещё что то случится - нужно принимать меры чтобы это не имело серьёзных последствий, потому что это всё равно когданибудь случится, происто исходя из теории вероятности.

Прекрасно, только держите свою гниль по дальше от существующих проектов.

> чего постоянно о них говорите?

Потому что они наносят ущерб, в том числе экономический, это же очевидно!
Утечки перс. данных, украденные коммерческие секреты, вымогатели, шифровальщики. Это мало?

> или по забывчивости, не внимательности либо их совершают в первый раз.

Именно потому что мясные мешки забывчивые и невнимательные by design, то нужно переложить рутинные проверки на машину.

Все неосиляторы остались на сишечке. Потому что там и синтаксис примитивнейший, и стандартная либа убогая по самое немогу, поэтому сидишь целый день байтики из буфера в буфер перекладываешь. Годиков десять или двадцать.
А потом, с настолько окостеневшими мозгами, ничему новому научиться не можешь. Помню как один такой сишник-ембедевщик пытался хаскель освоить. Ржака продолжалась месяца два наверное, а потом он таки сдался.

> потому что это всё равно когданибудь случится

поэтому лучше чтобы шанс этого события был минимальным, "происто исходя из теории вероятности"

> Прекрасно, только держите свою гниль по дальше от существующих проектов.

Прекрасно, мы услышали твое крайне важное для нас мнение и продолжим улучшать существующие проекты))

И сколько утечек и взломов было по вине С дырок против общего числа?

Эмбед пограмисты - это ближе к электроникам, там несколько другой склад ума и несколько другая культура разработки.

Смешной у вас подход к теории вероятности.
Вам говорят что это не избежно а вы вместо рекавери и минимизации ущерба бегаете с надеждой что это не произойдёт.

> Чувак, жизнь полна ошибок, ошибатся, признавать ошибки, исправлять ошибки - таков путь.

Есть другой путь. Значительно бОльшую часть ошибок исключить. Вон разработчики андроида частично это смогли, выбрав другой путь - в новой нативщине вытеснять си/плюсы в пользу раста. Вот что они сказали в декабре 2022 насчет типичных сишных ошибок памяти:

"To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code."

и в новом нативном коде (это си/плюсы/раст) раста там уже 21% и планируют это дело увеличивать. Там же, в конце резюме, итог:

"What’s next?

Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story. To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers.

As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!"

А ты не думал что это не про раст а про сохранение бюджета и рабочих мест?

Ну вот что там в андройде ещё писать?
Основное написано, можно выгонять 80% народа, оставшиеся будут поддерживать то чот есть и допиливать редкие новые фичи.
И тут они нашли фатальный недостаток и теперь надо в поте лица всё переписать с нуля, давайте ещё рабов на галеру!!! И пайку увеличивайте!!! Срочно, тонем!!!!

> "To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code."
> раста там уже 21%

Ну да, а если просто переписать на С с нуля оно бы отличалось?)

> А ты не думал что это не про раст а про сохранение
> бюджета и рабочих мест?

С этим сейчас будет душновато. И тут коса вполне может найти на камень. Если кто не заметил, айти сейчас не очень. А самые хайпованые почему-то трансформируются в записи на layoffs.com или как там его правильно. Чем хайповее и сиюминутнее нечто - тем быстрее оказывается что без вот этих, дескать, можно и обойтись если прижало.

Вон там выше уже новый растоман: https://www.opennet.me/openforum/vsluhforumID3/130337.html#81
просто илита, ваш будущий коллега.

И даже если бы, да кабы, грибы, бабушка, дедушка, вот это всё.
Хеллоуворлдщики ядро не перепишут. Максимум пару драйверов на 500 строк, и то тех, где сложной логики нет.

>Мне не нужна безопасность какая то там, у меня для этого замок на двери, и если будет мало я куплю ствол и подключю сигнализацию.

Очень плохие новости для тебя. Лет тебе маловато, это пройдет, со временем...
А тем временем новое поколение напилит другой треш. Молодёжь сегодня разная бывает, да :)

Когда-то компьютеры отлично исполняли лисп и не только.

И только потом вдруг решили что это не круто и нужно писать на СИ под примитивные вычислители (си процессоры они же риск)

> Когда-то компьютеры отлично исполняли лисп и не только.
> И только потом вдруг решили что это не круто и нужно писать
> на СИ под примитивные вычислители (си процессоры они же риск)

Платные пропихиватели гнили готовы на всё, даже на искажение истории ВТ. За похлёбку в день.

Ричард Столлман считал, что он нашел злую силу, которая уничтожила
лабораторию. Он считал, что это Symbolics. Он дал себе клятву: «Я никогда не буду
использовать LISP'машину Symbolics сам, и никому не буду помогать в этом… Я не буду
говорить ни с кем, кто работает в Symbolics или с людьми, которые с ними поддерживают
отношения”.

...

Ричард Столлман ушел из МТИ, но в его голове созрел план: написать свою
версию популярной закрытой компьютерной операционной системы UNIX и раздать ее
всем желающим.

Стивен Леви
Хакеры: Герои компьютерной революции

И в итоге никакой ОС Ричард Столлман так и не написал. Маниловщина обыкновенная. А написали совсем другие люди.

> Выбор был: пишем на С (может с асмовыми вставками) чтобы тяжёлые вычисления не тормозили или пишем на вижалбейсике или чем то подобном когда надо быстро накидать прототип или гуй. То что сейчас кресты расжирели невероятно

Типичный бред от диванного аналитика.
Расжирели они разве что на машине разработчика, когда при компиляции можно день гулять.
Но пользователя это не волнует.

А ассемблер не является волшебной лампой Аладина. В среднем ты с ассемблерной вставкой тоже самое и сделаешь.

Насчёт результата не знаю а время компиляции крестов просто запредельное, как и у ржавчины.

Да, вставки на асме сейчас не часто имеют смысл когда речь об С проекте, но SIMD всё ещё может легко дать х2+ при удачном стечении обстоятельств и в правильных руках.

> но SIMD всё ещё может

ну да... хотя к чему это, какие-то бредовые заключения постоянно.

> время компиляции крестов просто запредельное, как и у ржавчины.

Ага. И ты не знаешь почему так, и никогда не трудился хотя бы погуглить этот вопрос, и считаешь всех вокруг тупыми, что они не умеют писать компиляторы или готовы мириться с таким временем компиляции.

Так кто тупой-то в этой ситуации на самом деле?

Нафигачили там синтаксического сахара вот оно часами и компилирует, как гниль.

При этом Си всё ещё хуже  Фортрана в вычислениях. Причины использовать Си не вижу.

Фортран для мазохистов, родом из 60х). Не осиливших Си.

Это не возможно. Дефективен сам подход независимой реализации кеша и спекулятивного выполнения.
Т.е. надо буквально добавлять дополнительную память для спекулятивных веток, организовывать COW копирование из основного и получать спекулятивный кеш для спекулятивной ветки, переключая его вместе с спекулятивным результатом, если спекулятивно выполненная инструкция оказалась по факту верной.

Теоретически это возможно. Но это может потребовать значительной переработки дизайна процессоров и не известно насколько сложной окажется исправленная реализация. Возможно непрактично сложной.

Ну или идти по другому пути. Пытаться всеми правдами и не правдами уменьшить время доступа к памяти до времени доступа к L1. Тогда от кеша можно будет отказаться. Только это может оказаться ещё более сложной задачей.

>[оверквотинг удален]
> COW копирование из основного и получать спекулятивный кеш для спекулятивной ветки,
> переключая его вместе с спекулятивным результатом, если спекулятивно выполненная инструкция
> оказалась по факту верной.
> Теоретически это возможно. Но это может потребовать значительной переработки дизайна процессоров
> и не известно насколько сложной окажется исправленная реализация. Возможно непрактично
> сложной.
> Ну или идти по другому пути. Пытаться всеми правдами и не правдами
> уменьшить время доступа к памяти до времени доступа к L1. Тогда
> от кеша можно будет отказаться. Только это может оказаться ещё более
> сложной задачей.

Вы прочитали отрывок 'как программисты на пыхопэ представляют себе процессор'

Бугагэ нет, прогромисты на пыхе разные бывают. Я например. Который с ассемблера начинал.
Скорее отрывок "процессоры в мире рoзовых поней и смyзи".

Умение погромировать на асме не даёт автоматического понимания, как устроены процессоры.

Бгг. Без понимания, как устроены процессоры, в асм лучше не соваться.

> Т.е. спекулятивно надо спекулятивно буквально спекулятивно добавлять спекулятивно дополнительную спекулятивную память спекулятивно для спекулятивных веток, спекулятивно организовывать спекулятивное COW копирование из основного спекулятива и спекулятивно получать спекулятивный кеш для спекулятивной ветки, спекулятивно переключая его вместе с спекулятивным результатом, если спекулятивно выполненная спекулятивная инструкция спекулятивно оказалась по спекулятивному факту спекулятивно верной.

Fixed.

Спекулятивное выполнение и есть принципиальное р.е.ш.е.т.о. Как его не штопай и не патчь. Ошибка в самой идее..

У вас есть идея лучше?

> можно использовать

А точно можно, простите? Хоть одна демка есть, ну делаться никто не просит сурсамм, но хотя бы сами бы реализовали и показали что "можно". Иначе это просто пук.

Админы Архива снова вздыхают над графиком трафика...

Пока есть потребность в производительности, будут атаки на замеры времён. Если проц заставить выполнять все инструкции монотонно (и, соответственно, медленно), то <s>жабокодеры вымрут</s> мир погрузится в двухтысячные. )

Абсолютно верно. Вышенаписавшему про 'дырени' нетоварищу-троллю могу посоветовать борду с процом allwinner D1 -- в нём нет никаких спекуляций и OoO, чисто 1 классический конвеер, как Патерсон и Хеннеси (для алкашей: не коньяк, а человек) завещали. Даже кеша Л2 нет, а Л1 быстро вымывается, атаки труднее делать. Ну и ядро ровно одно -- никаких там мультитрединговостей. Линукс там работает, так что всё ок. Но всё ТОРМОЗИТ...

> Но всё ТОРМОЗИТ

на arm cortex-a53 жабоандроид летает, известным уязвимостям не подвержен

https://developer.arm.com/Arm%20Security%20Center/...

Ещё бы был подвержен, 2-wide decode, dual-issuing SOME instructions. Это уровень примерно пеньтиума-одын, in-order. Ну а что андроид летает - это конечно же враки, он нигде не летает.

Летает, но низенько и недолго. Вместе с очередным китайфоном до ближайшей стены.

> Летает, но низенько и недолго. Вместе с очередным китайфоном до ближайшей стены.

Ну а ты можешь ксеон поставить в китайфон. И тележку с генератором бонусом к нему давать.

Собери мне уже хромиум на cortex-a53, потом расскажешь, сколько недель заняло.

> Собери мне уже хромиум на cortex-a53

таакие задачи отлично параллелятся так что ядер 100 уделают твой настольный дырявый пека на раз

Ну так давай 100 на 100 :D

С одним одинаковым БП на 100 Вт

БП мне абсолютно фиолетов, мне важно время сборки. Электричество дешевле времени.

> БП мне абсолютно фиолетов

потому что не понимаешь суть - с ооо процессор потребляет намного больше потому что исполняет бесполезный код а результаты выбрасывает

> Электричество дешевле времени

давно пора налог на глупость вводить

Это точно.
Тратить время на попытки сделать из буханки троллейбус - как раз поцыент для сего налога.

> потому что не понимаешь суть - с ооо процессор потребляет намного больше
> потому что исполняет бесполезный код а результаты выбрасывает

Ты так радостно спалил почему ARM придумал такую странную штуку как big.LITTLE, где они пытабтся и на елку влезть и зад не подрать. Но ты распинаешься перед интелфаном, которого вообще не хватит на осознание такого хайтека :)).

А так то идея весьма даже: пока нагрузка небольшая, пашут энергоэффективные in-order ядра. А если надо быстро и много посчитать, подымают "big" OoO ядра уже. Интелу конечно же до такого уровня технологий как раком до китая.

> БП мне абсолютно фиолетов, мне важно время сборки. Электричество дешевле времени.

Время у машин дешевое, вот не надо тут. Врядли вы разработчик хромиума чтобы вас время его сборки еще и реально волновало к тому же. А кого реально волновало - понаставили билдферм, которых можно и из A53 понаделать, вопрос в количестве. И тут еще вопрос что будет дороже, прожорливее и дольше билдить.

Понимаешь в чём дело, я могу в 1U (с кастомным охлаждением правда) зафигачить 192 ядра x86.
Куда ты при этом свои A53 девать будешь - я хз.

> Понимаешь в чём дело, я могу в 1U (с кастомным охлаждением правда)
> зафигачить 192 ядра x86.

Вы удумали с ARM в копипасте ядер зарубиться? Удачи на этом направлении :). Так то армовские ядра сильно мельче и если цель именно ядер накопипастить...

> Куда ты при этом свои A53 девать будешь - я хз.

Да блин, вон там у Ampere есть процы с дохреналионом ядер и вполне серверным обвесом и даже несколькими сокетами, если было надо вот именно это. А еще некоторые хостинги продают малины свинченые в тот же 1U, так что вместо виртуалки можно купить себе выделенный "микродедик", имеющий определенные плюсы относительно виртуалок (стабильный перфоманс который ни с кем не делится). Сколько у них там ядер лезет в 1U считать ессно надо.

И это... какойнить гигабитный свич на дофига портов стоит копейки, как и одноплатники. Можно дешево и сердито расширять понемногу даже и не будучи транснациональной корпой с мешком денег. Срубил эн денег на удачном проекте, добавил несколько одноплатничков в ферму, пустячок а бонус к компилу - вот он. И так в цикле. А твой 192 ядерный 1U стоит чемодан денег, и его только атомарно одним шматом. В крупной корпе такое еще попробуй себе выбей, они ж жадные что капец, особенно сейчас, когда прижимать стало. А "из своих" оно в таком виде и вовсе накладно получается.

Ну и да, давай с одним одинаковым БП. На 500W.
Я в таковой впихну ОДИН EPYC 9654P, у него правда не 100, а 96 ядер, но ничего, пойдёт.
А тебе удачи раскидать всё это на пачку A53.

Да, давай ещё в 1U форм-факторе, раз уж такая пьянка.

как тот самый нетоварищ-тролль могу только кинуть тебе ссылку на тесты фороникса за 19 год
https://www.phoronix.com/review/spec-melt-8way/2
потеря производительности от 9% до 44%

спустя джва года худший результат 77% от варианта без патчей
https://www.phoronix.com/review/spectre-meltdown-2/11

разница даже не на порядок!
неужели ты готов ради даже 44% просто сделать себе дырень в системе?
уязвимость которую может использовать вкладка в броузере?
аНОНИМ, ты серьезно?

Пруфы насчёт успешного и  работающего на реальной системе использования уязвимости вкладкой в браузере будут? Или как обычно?

Аноним нынче или ленивый пошел, или настолько глупый что поиск в интернете не осилил...

Вот proof-of-concept который написан на жабаскрипте
https://security.googleblog.com/2021/03/a-spectre-proof-of-c...

Нэ работает этот пох в реальных условиях, его под чистой системой ещё потюнить надо, чтобы хоть какой-то результат за конское время получить.

> Нэ работает этот пох в реальных условиях, его под чистой системой ещё
> потюнить надо, чтобы хоть какой-то результат за конское время получить.

Первый самолет тоже больше этажерку с колесами напоминал. Ничего не говорит о том до чего можно доразвить направление.

Для meltdown и l1tf рабочие похи есть буквально с момента появления - потому что оно реально работает.
Всё остальное - это попытка подслушать разговор в квартире за 500 метров через изменение оттенка светофора на перекрёстке, вызываемое вибрацией. В теории можно, но в реальном мире не работает.

> Всё остальное - это попытка подслушать разговор в квартире за 500 метров
> через изменение оттенка светофора на перекрёстке, вызываемое вибрацией.

Ты как мне кажется сильно недооцениваешь мощь цифровых технологий обработки сигналов.

> В теории можно, но в реальном мире не работает.

В реальном мире человечество совершенно рутинно работает с сигналами слабее шума по величине и это прекрасно работает.

Ну, давай, расскажи нам сказочек про уверенный приём одиночных сигналов слабее шума :D

Скажу так: защита в мобиле не нужна.
Но не потому что там ничего ценного не бывает, а потому что там обычно браузер тормозится на время когда он в фоне, ровно как и наоборот, так что вычитать чувствительную инфу из других приложений скорее всего никак не выйдет при всём желании.
Что до паролей из самого андйройда - у меня лично там только пароль от вифи, никаких аккаунтов я не добавляю в систему, шифрование данных мне тоже не интересно.

Понимаю. Скрывать тебе нечего, но пароли к своим аккуантам ты не дашь. Вот и вернулись в 2005 год.

Не дам, но и украсть через такие дырки их вряд ли выйдет.

<s>Грузите апельсины бочками </s>
Запускайте open-source applications на dedicated сервере (с)

Если у вас есть достаточно денег, то да.

Все эти Spectre и Meltdown носят чисто теоретический характер и якобы что то там позволяют определить, ни одного рабочего экспа так и не всплыло ... Данный тип атак следует назвать - атака для анонистов.

Тебе s/ничего_не_угрожает/нечего_скрывать

Молодец, лабораторные условия от реальной жизни не отличаешь, но лозунги зазубрил на "отлично"! Вот такие люди и нужны.

Как говорил Остап Бендер - нет ладьи значит и не было! Что, подгорает что любимка то дырявая даже через много лет после Спектра?

Да чем чаще это повторять тем будет более безопасно. Это как с растом. Главное верить в свою полную безопасность.

Всё-таки хорошо в архитектуре RISC-V, что там нет регистра флагов - меньше векторов атак на оседающие данные.

Ещё есть Power
https://www.opennet.me/opennews/art.shtml?num=51327
https://en.wikipedia.org/wiki/Power10

Там вообще ничего нет

Там вообще всё хорошо.
Кроме производительности.
Которой нет, не было, и в силу архитектуры - не будет.

Будет но позже.

... жаль только, жить в эту пору прекрасную ...

Сильно позже. От слова "никогда".

Итак, на что спорим?

В RISC-V можно вставить свой левый проц память там будет работать своя параллельная ос и об этом никто не узнает, пока ты не выйдешь на миллиардные обороты.

Ну с x64 до сих пор прокатывает и после миллиардных оборотов. И ничего, даже комментаторы на опеннете о параллельной оси во всех современных интеловских(кроме некоторых госконтрактов) и амдшных матерях. Да и на 99% ARM смартфонов тоже.

> В RISC-V можно вставить свой левый проц

Но пока вставили в x86, в виде ME и PSP. А с RISCV - особенно опенсорсным - всегда есть риск что кто-то выкатит респин без "фичи" и еще нагло попиарится на этом.

> А с RISCV - особенно опенсорсным

И как, много примеров?  Чтоб ещё и хоть калькулятор тянули -- особо не прошу.

> И как, много примеров?  Чтоб ещё и хоть калькулятор тянули --
> особо не прошу.

Я кажется другой анон, но вот лично вам в другом месте накинул пример как 906-й XuanTie накопипастили уже за копейки. При том этот хуан теперь начинается от 12 баксов за весь одноплатник. И если кто хотел с технологией познакомиться - "налетай, подешевело!"

Ну а сколько 12-баксовых хуанов можно накупить за стоимость 192-ядерного x86 пусть фаны интела и прочих переростков посчитают. Мне их столько не надо а вот десяток под более скромные задачи - пуркуа б да не па?!

Всё нужное там бережно сохранили, не переживайте за риск-хайп -- думаете, зря там айбиэмерку поставили главой фундейшена?..

http://vk.com/@erthink-risc-v

По ссылке похоже автор хотел бы прокатиться на чужом горбу, но вот желающих чтот не находится

CVE нет, протестировали три дырявых SkyLake'а, как-то всё неубедительно.

После SkyLake вышли Ice/Tiger/Rocket/Alder/Raptor.

Ну всё значит мы в полной безопасности.

В описании сказано, что для эксплуатации нужно уметь точно замерять время выполнения инструкции jcc. На практике непонятно как это сделать кроме как из под отладчика. Если мы можем отлаживать атакуемый процесс, то непонятно для чего все эти сложности, ведь можно просто прочитать из памяти строку, с которой идет сравнение.
Если же речь о замере времени отклика, какой-то более сложной системы, например, у нас есть программа, которая проверяет пароль и мы начнем скармливать ей разные пароли и очень точно мерять время отклика, то полученные данные будут сильно зашумлены

> приводящая к утечке данных по сторонним каналам

запретить сторонние каналы и дело с концом!

Гениальное решение!
Народ, тут к нам кажется целый депутат заглянул на огонек!

> запретить сторонние каналы и дело с концом!

Для этого сначала надо запретить законы физики. И математику тоже неплохо бы, на всякий случай.

Полагаете, AMD и МЦСТ удалось именно это?

Мцст удалось закрыть документацию и ограничить доступ к железу. У них есть баг баунти программа? Думаю при должном уровне заинтересованности дырок там будет найдено в товарном количестве.

> Полагаете, AMD и МЦСТ удалось именно это?

Полагаю что чуда не произошло и у больших процов неизбежно будут большие грабли, что бы маркетинг там не вещал. А вон то это вообще пример галантерейщика и кардинала 2.0.

АМД сейчас в верхней строчке топ500, за номером 1, если что. Вот это - демо технологических возможностей которое понятно любому технарю.

Никогда такого не было и вот опять.) Плата за спекулятивное выполнение операций. Принципиальная архитектурная дыра.

Там больше хайпа чем дыры ныне.

> Там больше хайпа чем дыры ныне.

Не, вот извините, еще начиная с времен 386 предполагалось что процессы будут изолированы друг от друга, и вообще. И тут вдруг оказывается что реальный уровень безопасности этого недоразумения мало ушел от Win95 и прочих DOS где всем можно все, система проходной двор, потому что интел видите ли решил срезать пару углов в оптимизациях перфоманса в надежде что никто не заметит развал абстракции в этом месте. А всякие хлипкие отговорки - вам интел что, доплачивает за даунплей? Или вы их акционер? Судя по длинному списку вулнов там халтура на халтуре и халтурой погоняет. Особенно у интеля, но и амд отметился. Да даже ARM слегка досталось.

Они и изолированы. Кроме как у штеуда, который привилегии на спекулятивке проверять читернул, и стали возможным meltdown с l1tf. Остальные вторичные каналы позволяют что-то там в лабе померить, но в реальных условиях, когда замеры смешиваются с шумом от кучи процессов, оно просто не работает - ни одного рабочего PoC разнокалиберных спектров, который бы не требовал чистой системы и тонкой настройки - так и не появилось.

> Они и изолированы.

Да вот как оказалось - довольно паршивая изоляция то. Крыша протекает. И при том у вот именно интеля больше и сильнее чем у всех остальных, которые не срезали углы в пользу перфоманса так по наглому.

> Кроме как у штеуда, который привилегии на спекулятивке проверять
> читернул, и стали возможным meltdown с l1tf. Остальные вторичные каналы позволяют
> что-то там в лабе померить, но в реальных условиях, когда замеры
> смешиваются с шумом от кучи процессов, оно просто не работает -

Вы явно недооцениваете мощь цифровой обработки сигналов. А исследователи лишь первые ласточки. Это я так, реимплементнув пару лабораторных странных технологий говорю. Представляешь, я вот тоже теперь могу _свето_ диодом померять свет, и даже неожиданный коммуникационный канал устроить. Просто заимплементив идеи из вон той статьи. Значит это работает а статьи не пустой звук. В отличие от сказочников опеннета.

> ни одного рабочего PoC разнокалиберных спектров, который бы не требовал чистой
> системы и тонкой настройки - так и не появилось.

Технологии не стоят на месте. Если есть минимальное отличие от рандома - усе, этого достаточно. Я даже немного умею в эту магию уже, поэтому рассказывать как это не работает ты будешь кому-то другому, кто эту магию чисел не пробовал на вкус.

От какого именно рандома? :)
Ещё раз: в случае перехвата именно вот этого вот сигнала (в отличие от радио например) - у тебя даже характеристик среды заранее нет.

Когда ты знаешь, что должно прийти - ты можешь магически попробовать это повыделять из шума.
Но нужны знания либо о шуме, либо о целевом сигнале, которые становятся частью собственно SNR в конечном расчёте.
В случае попытки увести то, не знаю, что, через неизвестную среду (неизвестное зашумление) - шансов нет.
Что собственно отсутствием сколь-либо рабочих даже PoC за 3 года и подтверждается.

всегда отключаю mitigations, всё это хрень полная, если ты не нефтяной магнат

Интересно, вот реальные хакеры и вирмейкеры пользуются этой экзотикой с временами выполнения инструкций, или все-же эксплуатируют банальные дыры в софте вроде переполнения буфера?

Шифровальщики распространяют через "партнёрки". Эксплуатируют человеческий фактор и любовь админов к сладкому шекелю.

В техпроцессик упёрлись, трудно перепродавать каждый год одно и тоже... Тащите большую чёрную книгу с бекдорами! Начинаем замедлять :3

Ну кстати да, похоже на то.
mitigations=off стало необходимостью, но и оно не 100% возврат, даже пересборка ныне уже не спасает. Но 99% - норм.

...когда читаешь очередные новости с того берега речки на своём "Эльбрус-16С"... :)

Но Ленинград 48к всё равно круче! :-)

Я наверн подытожу, задолбало реплаить на каждый спор.

Все эти расхайпанные гипотетические дыры, для которых за годы даже рабочего PoC не появилось - интересны разве каким-либо DoD, где даже малейший риск утечки не допускается.

Ради условного ООО Васян и Ко с парой миллионов евров на счетах никто даже заморачиваться с этим дерьмом не будет - проще директору этого ООО подослать спама с тёлочками, и он сам сольёт все пароли, где далее будут накопаны собственно аккаунты и банк-клиенты, что обычно и происходит. Не говоря уже о неизвестном Васяне Неко, который вообще мало кому интересен, разве что в спамбот машину превратить - чтобы вот тому ООО спам подсылать.

Понятно, что продаваны от железячников этот хайп подхватили и распузыривают, ведь можно напихать ещё больше затычек, и продать ещё больше вот этих вкусных процов постарше несведущему обывателю, перепуганному страшными утечками его паролей от соцсетей с фоточками котиков.

Но в целом ситуация немножко очевидна.

Вон в соседней новости ключи у мсявных утекли - и эта дыра куда поболее дыра, чем вот это всё.
К тому же очень весело эксплуатабельная при необходимости.

> задолбало реплаить на каждый спор.

Может в качестве подтверждения эффективности спрашивать экспертов по эксплуатации Спектрумов и Мельдония о размерах их бот-нетов?

С активистами СПО вроде работает просьба показать свой гитхап.

>> задолбало реплаить на каждый спор.
> Может в качестве подтверждения эффективности спрашивать экспертов по эксплуатации Спектрумов
> и Мельдония о размерах их бот-нетов?
> С активистами СПО вроде работает просьба показать свой гитхап.

Времена частных ботнетов в прошлом, теперь всё у спецслужб ...
Просто потому что взламывать шифры могут себе позволить только те кто может позволить создание квантового вычислителя.