• Re: Qualcomm's Oryon boasts hardware "side-channel mitigations"

    From Scott Lurndal@21:1/5 to Anton Ertl on Fri Jun 14 16:09:56 2024
    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >https://images.anandtech.com/doci/21445/SDX_CPU_GPU%20Architecture%20Overview_15.jpg

    Unfortunately, they don't describe what they do, and "mitigation" has
    a weaker sound than "fix" to me, but maybe they mean a proper hardware
    fix. That would be the best case. The worst case would be that they
    just have added instructions or a special mode for disabling
    speculation.

    The Aarch64 architecture includes pointer auth, branch target ID,
    Speculation barrier instructions, architectural features to prevent exploitation of branch history buffers, and a few other features
    intended to address many of the speculation related attacks.

    I suspect that covers most of Qualcomms 'side-channel mitigations'.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to All on Fri Jun 14 15:46:02 2024
    https://images.anandtech.com/doci/21445/SDX_CPU_GPU%20Architecture%20Overview_15.jpg

    Unfortunately, they don't describe what they do, and "mitigation" has
    a weaker sound than "fix" to me, but maybe they mean a proper hardware
    fix. That would be the best case. The worst case would be that they
    just have added instructions or a special mode for disabling
    speculation.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Scott Lurndal on Fri Jun 14 17:16:25 2024
    scott@slp53.sl.home (Scott Lurndal) writes:
    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>https://images.anandtech.com/doci/21445/SDX_CPU_GPU%20Architecture%20Overview_15.jpg

    Unfortunately, they don't describe what they do, and "mitigation" has
    a weaker sound than "fix" to me, but maybe they mean a proper hardware
    fix. That would be the best case. The worst case would be that they
    just have added instructions or a special mode for disabling
    speculation.

    The Aarch64 architecture includes pointer auth, branch target ID,
    Speculation barrier instructions, architectural features to prevent >exploitation of branch history buffers, and a few other features
    intended to address many of the speculation related attacks.

    I suspect that covers most of Qualcomms 'side-channel mitigations'.

    That would be the worst case, then.

    I hope that at some point (Hot Chips?) they will be more concrete
    about what's behind their claims.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From MitchAlsup1@21:1/5 to Anton Ertl on Fri Jun 14 21:12:53 2024
    Anton Ertl wrote:

    https://images.anandtech.com/doci/21445/SDX_CPU_GPU%20Architecture%20Overview_15.jpg

    Unfortunately, they don't describe what they do, and "mitigation" has
    a weaker sound than "fix" to me, but maybe they mean a proper hardware
    fix. That would be the best case. The worst case would be that they
    just have added instructions or a special mode for disabling
    speculation.

    Maybe they just followed my advice on deferring state updates until
    after retirement.

    - anton

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to mitchalsup@aol.com on Sat Jun 15 07:56:32 2024
    mitchalsup@aol.com (MitchAlsup1) writes:
    Anton Ertl wrote:

    https://images.anandtech.com/doci/21445/SDX_CPU_GPU%20Architecture%20Overview_15.jpg

    Unfortunately, they don't describe what they do, and "mitigation" has
    a weaker sound than "fix" to me, but maybe they mean a proper hardware
    fix. That would be the best case. The worst case would be that they
    just have added instructions or a special mode for disabling
    speculation.

    Maybe they just followed my advice on deferring state updates until
    after retirement.

    Yes, that would be the best case (plus some cheaper fixes for some
    narrower side channels: contention on resources shared between cores,
    and timing of the misprediction recovery).

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Anton Ertl on Mon Jun 17 00:49:28 2024
    On Fri, 14 Jun 2024 15:46:02 GMT, Anton Ertl wrote:

    ... "mitigation" has a weaker sound than "fix" to me ...

    “Mitigation” seems to be the standard term when referring to security fixes. Think of “fix” as a marketing term, that could suggest that you
    will no further problems in future. Whereas the security pros use the
    cautious term, because they realize it is far more likely that further
    holes will be found in future.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Lawrence D'Oliveiro on Mon Jun 17 06:25:20 2024
    Lawrence D'Oliveiro <ldo@nz.invalid> writes:
    On Fri, 14 Jun 2024 15:46:02 GMT, Anton Ertl wrote:

    ... "mitigation" has a weaker sound than "fix" to me ...

    “Mitigation” seems to be the standard term when referring to security >fixes.

    When I look at <https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html>,
    e.g., for Meltdown (CVE-2017-5754), I see for some hardware "Software"
    (i.e., not fixed in hardware) and for other hardware (e.g., Tiger Lake
    U) "Not affected" (i.e., fixed in hardware, for CPUs like Tiger Lake U
    where the ancestors were affected; for cores where the ancestors were
    not affected, these were already constructed correctly, not fixed; but
    if you just look at the particular hardware without considering it's
    pedigree, it's just "not affected"); other entries (e.g., for Spectre
    v2) have "MCU+Software" (i.e., microcode changes for supporting
    software mitigations, i.e., not fixed in hardware) and
    "Hardware+Software" (i.e., hardware changes for supporting software mitigations, i.e., not fixed in hardware. I see no mention of
    "hardware mitigation" for CPUs there that are not affected.

    "Mitigation" has a weak sound to be because it is used when the
    security hole is not closed at all, but instead one suggests that
    someone else should do something or avoid something such that the still-existing vulnerability cannot be exploited. E.g., in the case
    of Spectre v2, to insert retpolines and/or new instructions like IBRS,
    STIBP, IBPB (provided in microcode or in hardware) in the software.

    Think of “fix” as a marketing term, that could suggest that you
    will no further problems in future.

    That's totally unlike any use of "fix" that I have seen. Bugfixes are
    provided for software all the time, and they do not promise that no
    other bugs will be found in the future.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)