• =?UTF-8?Q?Re=3A_US-made_routers_and_a_p=C3=83ossibl_boon_for_RISC-V?=

    From BGB@[email protected] to comp.arch on Sat Mar 28 18:56:14 2026
    From Newsgroup: comp.arch

    On 3/28/2026 3:51 PM, MitchAlsup wrote:

    Thomas Koenig <[email protected]> posted:

    It seems that the Federal Communications Commission (the US
    authority) is requiring "all US-developed and made" for newly
    introduced routers, effective immediately, see

    https://www.fcc.gov/faqs-recent-updates-fcc-covered-list-regarding-routers-produced-foreign-countries

    For existing routers, at least security patches are sill allowed
    for a year, at least.

    Given that RISC-V is "at least as insecure" as x86, x86-64, ARM in
    the face of current attack vectors; and much of the RISC-V funding
    comes from China; I doubt it have much of a case here.


    My prediction is (assuming the US economy does well), the biggest
    beneficiary from this would likely be Intel and 32-bit x86 (where
    running 32-bit x86 code on an Atom or similar is likely a reasonable
    "Made in America" option; most of the ARM SoC's not being this, and also
    it makes sense to use an Intel CPU if you already need to go with an
    Intel WiFi chip or similar).

    My confidence in long term stability of the US economy isn't exactly
    high though.


    That is going to be interesting, especially even allied countries
    like Taiwan (TSMC) are also excluded.

    But perhaps an actually secure ISA (and rest of system) is being
    given an advantage where funding might be secured.


    Could be interesting.

    As for a new/secure architecture emerging, this seems low probability.


    More likely they will use something existing and call it "secure". Or
    maybe have a bunch of meetings, talk about security, bless something as secure, but ultimately very little actually happens (they vow to use the
    NX flag and ASLR or something, and maybe compile binaries with stack
    canaries enabled or something...).

    And/or some crap about rewriting everything in Rust or something.

    ...


    Could be a boon for RISC-V startups, but of course the CPU is
    only a part - the Wifi modules are also required.

    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@[email protected] to comp.arch on Sun Mar 29 00:41:45 2026
    From Newsgroup: comp.arch

    On Sat, 28 Mar 2026 23:12:52 -0000 (UTC), Thomas Koenig wrote:

    MIPS is dead, as is SPARC.

    Not so sure MIPS is dead. I think chips are still shipping for
    embedded uses. Also I think it’s the basis for the Chinese LoongArch architecture.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From jgd@[email protected] (John Dallman) to comp.arch on Sun Mar 29 05:50:40 2026
    From Newsgroup: comp.arch

    In article <10q9sg9$1321e$[email protected]>, [email protected]d (Lawrence D_Oliveiro) wrote:

    Not so sure MIPS is dead. I think chips are still shipping for
    embedded uses. Also I think it's the basis for the Chinese LoongArch architecture.

    LoongArch switched to an architecture of their own in 2021.

    <https://en.wikipedia.org/wiki/Loongson#Loongson_3_LoongArch_processors>

    John
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@[email protected] to comp.arch on Sun Mar 29 07:05:56 2026
    From Newsgroup: comp.arch

    On Sun, 29 Mar 2026 05:49 +0100 (BST), John Dallman wrote:

    In article <10q9sg9$1321e$[email protected]>, [email protected]d (Lawrence D_Oliveiro) wrote:

    Not so sure MIPS is dead. I think chips are still shipping for
    embedded uses. Also I think it's the basis for the Chinese
    LoongArch architecture.

    LoongArch switched to an architecture of their own in 2021.

    <https://en.wikipedia.org/wiki/Loongson#Loongson_3_LoongArch_processors>

    Did you read that?

    The ISA has been referred to as "a fork of MIPS64r6" due to a
    perceived lack of changes judging from instruction
    listings.[33][34] The Register reported in November 2021 that
    LoongArch might combine the best parts of MIPS and RISC-V, along
    with custom instructions.[35]
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From anton@[email protected] (Anton Ertl) to comp.arch on Sun Mar 29 10:08:35 2026
    From Newsgroup: comp.arch

    Thomas Koenig <[email protected]> writes:
    It seems that the Federal Communications Commission (the US
    authority) is requiring "all US-developed and made" for newly
    introduced routers, effective immediately, see

    https://www.fcc.gov/faqs-recent-updates-fcc-covered-list-regarding-routers-produced-foreign-countries

    Looks like one of the usual open tactics to extract bribe money:
    Donate some money to Trump, and you will be granted an exception from
    this policy. Has happened in other areas, and will continue to happen
    as long as the Trump administration has as much power as they
    currently have.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <[email protected]>
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Michael S@[email protected] to comp.arch on Sun Mar 29 13:23:22 2026
    From Newsgroup: comp.arch

    On Sat, 28 Mar 2026 23:12:52 -0000 (UTC)
    Thomas Koenig <[email protected]> wrote:

    MitchAlsup <[email protected]d> schrieb:

    Thomas Koenig <[email protected]> posted:

    It seems that the Federal Communications Commission (the US
    authority) is requiring "all US-developed and made" for newly
    introduced routers, effective immediately, see

    https://www.fcc.gov/faqs-recent-updates-fcc-covered-list-regarding-routers-produced-foreign-countries

    For existing routers, at least security patches are sill allowed
    for a year, at least.

    Given that RISC-V is "at least as insecure" as x86, x86-64, ARM in
    the face of current attack vectors; and much of the RISC-V funding
    comes from China; I doubt it have much of a case here.

    Secure or not secure is not the issue, it seems the FCC does
    not care about that.

    They care production, which "generally includes any major stage of the process through which the device is made including manufacturing,
    assembly, design, and development."

    So, using ARM as the CPU for a router seems to be out; they are
    UK-based. x86 CPUs are too power-hungry, so Intel and AMD are out.
    MIPS is dead, as is SPARC. NXP might be able to revive PowerPC
    for embedded applications in routers, but I somehow doubt it.

    That pretty much leaves... RISC-V.


    How many suitable RISC-V SOCs are manufactured on USA soil?
    I'd guess that hardly any. Today everybody who wants best perf/W
    fabs at TSMC and majority of the rest uses either older TSMC fabs or at Samsung.
    Of course, CPU is just one part in the BOM list and probably not
    even the biggest one. But you mentioned it already.


    That is going to be interesting, especially even allied countries
    like Taiwan (TSMC) are also excluded.

    But perhaps an actually secure ISA (and rest of system) is being
    given an advantage where funding might be secured.

    That would be good, but I somehow doubt that the timelines will
    work out.

    Could be a boon for RISC-V startups, but of course the CPU is
    only a part - the Wifi modules are also required.




    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From anton@[email protected] (Anton Ertl) to comp.arch on Sun Mar 29 10:13:20 2026
    From Newsgroup: comp.arch

    Lawrence =?iso-8859-13?q?D=FFOliveiro?= <[email protected]d> writes:
    Not so sure MIPS is dead. I think chips are still shipping for
    embedded uses.

    So its body is still moving, like a beheaded chicken. That does not
    make it less dead:

    |In March 2021, MIPS announced that the development of the MIPS
    |architecture had ended as the company is making the transition to
    |RISC-V.
    <https://en.wikipedia.org/wiki/MIPS_architecture>

    That's more than five years ago.

    Also I think it’s the basis for the Chinese LoongArch
    architecture.

    Many architectures are based on the MIPS architecture: Alpha, DLX,
    Nios II, RISC-V, LoongArch. That does not mean that any of them is
    MIPS. In particular, Loongarch has a different encoding compared to
    MIPS:

    Using Gforth's MIPS assembler:

    gforth -i kernl64l.fi startup.fs arch/mips/asm.fs
    ...
    assembler
    0 1 2 addu, \ corresponds to ADDU r0,r1,r2 in MIPS syntax
    here 4 - 4 dump

    outputs:

    7F812D48C5B8: 21 00 22 00 - !.".

    For Loongarch there is no ADDU in the assembler, showing one
    difference from MIPS. There are add.w and add.d, let's see what they
    assemble to:

    gforth -i kernl64l.fi startup.fs arch/loongarch64/asm.fs
    ...
    assembler
    0 1 2 add.w
    0 1 2 add.d
    here 8 - 8 dump
    7F5245490490: 20 08 10 00 20 88 10 00 - ... ...

    So neither of these instructions has the same encoding as the MIPS
    addu instruction.

    Let's also compare with RISC-V:

    gforth -i kernl64l.fi startup.fs arch/riscv/asm.fs
    0 1 2 add
    0 1 2 addw
    here 8 - 8 dump
    7F8EFEC8E058: 33 80 20 00 3B 80 20 00 - 3. .;. .

    So they all have different encodings for these instructions.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <[email protected]>
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From anton@[email protected] (Anton Ertl) to comp.arch on Sun Mar 29 11:34:04 2026
    From Newsgroup: comp.arch

    Thomas Koenig <[email protected]> writes:
    So, using ARM as the CPU for a router seems to be out; they are
    UK-based.

    According to the government of the USA (when they decided to forbid
    certain ARM lincensing or somesuch to certain Chinese companies, ARM
    is USA technology, and the fact that many core designs are coming out
    of the design center in Austin (IIRC) gives some credibility to the
    POV. OTOH, the ARM tax for any licensed cores or architectures goes
    to ARM (UK) and through them to Softbank (Japan) and its investores,
    wherever in the world they are, and that might be seen as a reason for
    counting even SoCs designed and manufactured in the USA, where the ARM
    core was deigned in Austin as being a non-USA SoC.

    x86 CPUs are too power-hungry

    My Tremont-based office desktop uses less power than my router, so I
    doubt that.

    NXP might be able to revive PowerPC
    for embedded applications in routers, but I somehow doubt it.

    If it's good business for them, they probably can be convinced. But
    NXP are have their headquarters in the Netherlands, so I doubt that
    PowerPCs from them will count as US-based without a significant bribe.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <[email protected]>
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From anton@[email protected] (Anton Ertl) to comp.arch on Sun Mar 29 11:48:47 2026
    From Newsgroup: comp.arch

    MitchAlsup <[email protected]d> writes:
    Given that RISC-V is "at least as insecure" as x86, x86-64, ARM in
    the face of current attack vectors
    ...
    But perhaps an actually secure ISA (and rest of system) is being
    given an advantage where funding might be secured.

    What kind of security do you think an ISA can provide or subvert and
    what attack vectors do you have in mind?

    At first nothing came to my mind; later I came up with constant-time instructions.

    Intel actually does define a subset of instructions whose execution
    time does not depend on the input or output data, which is very
    commendable, and allows to write constant-time code for defending
    against plain old (non-speculative) side-channel attacks.[1] I have
    not seen such a thing from other processor, ISA, or core
    manufacturers, but I have not looked for it.

    One frequent use in constant-time code is to use a conditional move
    instead of a branch, in the hope (or, I think, for Intel, with the
    guarantee) that it will be constant-time. RV64I does not have a
    conditional move, but maybe one of the extensions has conditional
    moves.

    Concerning routers, I expect that the software running on it comes
    from the router manufacturer, so the kind of security offered by
    constant-time instructions probably is not very relevant.

    [1] Of course, with Spectre all code that runs in the process where
    the secret lies can be used to extract the secret, and using
    constant-time code for the whole process is not practically feasible
    unless the process does very little. Intel had not introduced a
    Spectre-immune CPU yet, which is reproachable after more then 8 years.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <[email protected]>
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Niklas Holsti@[email protected] to comp.arch on Sun Mar 29 15:18:03 2026
    From Newsgroup: comp.arch

    On 2026-03-29 14:48, Anton Ertl wrote:
    MitchAlsup <[email protected]d> writes:
    Given that RISC-V is "at least as insecure" as x86, x86-64, ARM in
    the face of current attack vectors
    ...
    But perhaps an actually secure ISA (and rest of system) is being
    given an advantage where funding might be secured.

    What kind of security do you think an ISA can provide or subvert and
    what attack vectors do you have in mind?

    Mitch has described his protected return-address stack as a security
    feature.

    At first nothing came to my mind; later I came up with constant-time instructions.

    Intel actually does define a subset of instructions whose execution
    time does not depend on the input or output data, which is very
    commendable, and allows to write constant-time code for defending
    against plain old (non-speculative) side-channel attacks.[1] I have
    not seen such a thing from other processor, ISA, or core
    manufacturers, but I have not looked for it.

    Constant instruction-execution time is (or was, last I heard) a feature
    of the Mill architecture, and critical in the sense that the compiler's instruction scheduling depends on knowledge of those times, and wrong scheduling makes the computation fail. The Mill is also claimed to be
    immune to Spectre.

    But AFAIK no Mill processors are in production.

    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From jgd@[email protected] (John Dallman) to comp.arch on Sun Mar 29 14:23:40 2026
    From Newsgroup: comp.arch

    In article <[email protected]>,
    [email protected]d (Niklas Holsti) wrote:

    Constant instruction-execution time is (or was, last I heard) a
    feature of the Mill architecture, and critical in the sense that
    the compiler's instruction scheduling depends on knowledge of
    those times, and wrong scheduling makes the computation fail.

    Mill appears to have been abandoned.

    John
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Terje Mathisen@[email protected] to comp.arch on Sun Mar 29 15:26:31 2026
    From Newsgroup: comp.arch

    John Dallman wrote:
    In article <[email protected]>,
    [email protected]d (Niklas Holsti) wrote:

    Constant instruction-execution time is (or was, last I heard) a
    feature of the Mill architecture, and critical in the sense that
    the compiler's instruction scheduling depends on knowledge of
    those times, and wrong scheduling makes the computation fail.

    Mill appears to have been abandoned.


    That's news to me!

    There is still a lot of email traffic on the internal Mill server...

    Terje
    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Thomas Koenig@[email protected] to comp.arch on Sun Mar 29 13:45:27 2026
    From Newsgroup: comp.arch

    John Dallman <[email protected]> schrieb:
    In article <[email protected]>,
    [email protected]d (Niklas Holsti) wrote:

    Constant instruction-execution time is (or was, last I heard) a
    feature of the Mill architecture, and critical in the sense that
    the compiler's instruction scheduling depends on knowledge of
    those times, and wrong scheduling makes the computation fail.

    Mill appears to have been abandoned.

    Hmm... would be a pity.

    millcomputing.com seems to return NXDOMAIN, which is not a good
    sign, and things have been awfully quiet of late.

    Looking at the records at
    https://bizfileonline.sos.ca.gov/search/business the company
    is listed as "Forfeited - FTB, which seems to indicate that it
    no longer operating, possibly for not paying taxes. It is still
    listed in Delaware.

    So yes, the company (and project) seem to be defunct.
    --
    This USENET posting was made without artificial intelligence,
    artificial impertinence, artificial arrogance, artificial stupidity,
    artificial flavorings or artificial colorants.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Stefan Monnier@[email protected] to comp.arch on Sun Mar 29 09:26:48 2026
    From Newsgroup: comp.arch

    Thomas Koenig [2026-03-28 23:12:52] wrote:
    They care production, which "generally includes any major stage of the process through which the device is made including manufacturing,
    assembly, design, and development."

    So, using ARM as the CPU for a router seems to be out; they are
    UK-based. x86 CPUs are too power-hungry, so Intel and AMD are out.
    MIPS is dead, as is SPARC. NXP might be able to revive PowerPC
    for embedded applications in routers, but I somehow doubt it.

    That pretty much leaves... RISC-V.

    They also say:

    Is a router produced in the United States containing
    foreign-produced components now “covered equipment” and prohibited
    from FCC equipment authorization?

    • Non-“covered” devices do not become “covered” simply because they
    contain a “covered” component part, unless the “covered” component
    part is a modular transmitter under the FCC’s rules. 47 CFR §§
    2.903(b), 15.212.

    • Therefore, a router produced in the United States is not
    considered “covered” equipment solely because it contains one or
    more foreign-made components.

    which suggests to me that they may not care if the CPU is
    produced elsewhere.

    In any case, I highly doubt this is a decision based on security
    concerns (esp since they exclude real routers used in infrastructure:
    "Routers" is defined by National Institute of Standards and Technology’s Internal Report 8425A to mean consumer-grade networking devices that are primarily intended for residential use and can be installed by the
    customer).

    It's protectionism (and as Anton points out: combined with a nice
    opportunity for bribes).


    === Stefan
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From EricP@[email protected] to comp.arch on Sun Mar 29 11:51:31 2026
    From Newsgroup: comp.arch

    Stefan Monnier wrote:
    Thomas Koenig [2026-03-28 23:12:52] wrote:
    They care production, which "generally includes any major stage of the
    process through which the device is made including manufacturing,
    assembly, design, and development."

    So, using ARM as the CPU for a router seems to be out; they are
    UK-based. x86 CPUs are too power-hungry, so Intel and AMD are out.
    MIPS is dead, as is SPARC. NXP might be able to revive PowerPC
    for embedded applications in routers, but I somehow doubt it.

    That pretty much leaves... RISC-V.

    They also say:

    Is a router produced in the United States containing
    foreign-produced components now “covered equipment” and prohibited
    from FCC equipment authorization?

    • Non-“covered” devices do not become “covered” simply because they
    contain a “covered” component part, unless the “covered” component
    part is a modular transmitter under the FCC’s rules. 47 CFR §§
    2.903(b), 15.212.

    • Therefore, a router produced in the United States is not
    considered “covered” equipment solely because it contains one or
    more foreign-made components.

    which suggests to me that they may not care if the CPU is
    produced elsewhere.

    In any case, I highly doubt this is a decision based on security
    concerns (esp since they exclude real routers used in infrastructure: "Routers" is defined by National Institute of Standards and Technology’s Internal Report 8425A to mean consumer-grade networking devices that are primarily intended for residential use and can be installed by the
    customer).

    They say "router" but then refer to "modular transmitter" and
    further up it refers to "RF device":

    What constitutes “produced in a foreign country”?
    Is there a content threshold?

    - The National Security Determination states that “[p]roduction generally
    includes any major stage of the process through which the device is made
    including manufacturing, assembly, design, and development.”

    - In the equipment authorization process, applicants have to self-certify
    that any RF device is not “covered equipment.” Going forward, this
    includes self-certification that the RF device is not a router
    “produced in a foreign country.”

    - Applicants seeking equipment authorization for any router will bear
    responsibility or certifying, in good faith, that any such router was
    not “produced in a foreign country.”



    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From EricP@[email protected] to comp.arch on Sun Mar 29 12:08:59 2026
    From Newsgroup: comp.arch

    Anton Ertl wrote:
    MitchAlsup <[email protected]d> writes:
    Given that RISC-V is "at least as insecure" as x86, x86-64, ARM in
    the face of current attack vectors
    ....
    But perhaps an actually secure ISA (and rest of system) is being
    given an advantage where funding might be secured.

    What kind of security do you think an ISA can provide or subvert and
    what attack vectors do you have in mind?

    At first nothing came to my mind; later I came up with constant-time instructions.

    Intel actually does define a subset of instructions whose execution
    time does not depend on the input or output data, which is very
    commendable, and allows to write constant-time code for defending
    against plain old (non-speculative) side-channel attacks.[1] I have
    not seen such a thing from other processor, ISA, or core
    manufacturers, but I have not looked for it.

    One frequent use in constant-time code is to use a conditional move
    instead of a branch, in the hope (or, I think, for Intel, with the
    guarantee) that it will be constant-time. RV64I does not have a
    conditional move, but maybe one of the extensions has conditional
    moves.

    A Conditional Select CSEL instruction has 3 source operands and 1 dest
    does the same thing as CMOV without its internal hassles.
    It requires 3 source register fields but RV's FMADD R4-type format
    aready crossed that rubicon.

    Rd = CSEL_cc(Rs1)? Rs2 : Rs3


    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Stefan Monnier@[email protected] to comp.arch on Sun Mar 29 12:27:48 2026
    From Newsgroup: comp.arch

    They say "router" but then refer to "modular transmitter" and
    further up it refers to "RF device":

    Yup. Suggests it doesn't applies to "routers" only to the extent that
    they include an access point (or a cellular connection, I guess).


    === Stefan
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From scott@[email protected] (Scott Lurndal) to comp.arch on Sun Mar 29 18:39:05 2026
    From Newsgroup: comp.arch

    Niklas Holsti <[email protected]d> writes:
    On 2026-03-29 14:48, Anton Ertl wrote:
    MitchAlsup <[email protected]d> writes:
    Given that RISC-V is "at least as insecure" as x86, x86-64, ARM in
    the face of current attack vectors
    ...
    But perhaps an actually secure ISA (and rest of system) is being
    given an advantage where funding might be secured.

    What kind of security do you think an ISA can provide or subvert and
    what attack vectors do you have in mind?

    Mitch has described his protected return-address stack as a security >feature.

    At first nothing came to my mind; later I came up with constant-time
    instructions.

    Intel actually does define a subset of instructions whose execution
    time does not depend on the input or output data, which is very
    commendable, and allows to write constant-time code for defending
    against plain old (non-speculative) side-channel attacks.[1] I have
    not seen such a thing from other processor, ISA, or core
    manufacturers, but I have not looked for it.

    Constant instruction-execution time is (or was, last I heard) a feature
    of the Mill architecture, and critical in the sense that the compiler's >instruction scheduling depends on knowledge of those times, and wrong >scheduling makes the computation fail. The Mill is also claimed to be
    immune to Spectre.

    ARMv8/9 has a similar feature (Data Independent Timing). It can be
    enabled and disabled via a processor flag.

    There have been a number of features added to ARMv8/9 over the
    last decade and a half specifically addressing security, such
    as the aforementioned DIT, as well as memory tagging,
    encrypted pointer tags, etc.

    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From MitchAlsup@[email protected] to comp.arch on Sun Mar 29 18:56:53 2026
    From Newsgroup: comp.arch


    [email protected] (Anton Ertl) posted:

    MitchAlsup <[email protected]d> writes:
    Given that RISC-V is "at least as insecure" as x86, x86-64, ARM in
    the face of current attack vectors
    ...
    But perhaps an actually secure ISA (and rest of system) is being
    given an advantage where funding might be secured.

    What kind of security do you think an ISA can provide or subvert and
    what attack vectors do you have in mind?

    Spectré family
    Meltdown family
    RowHammer family
    Return Oriented Programming
    Stack Smashing
    High precision timer variances
    Constant time evaluation

    At first nothing came to my mind; later I came up with constant-time instructions.

    Intel actually does define a subset of instructions whose execution
    time does not depend on the input or output data, which is very
    commendable, and allows to write constant-time code for defending
    against plain old (non-speculative) side-channel attacks.[1] I have
    not seen such a thing from other processor, ISA, or core
    manufacturers, but I have not looked for it.

    One frequent use in constant-time code is to use a conditional move
    instead of a branch, in the hope (or, I think, for Intel, with the
    guarantee) that it will be constant-time. RV64I does not have a
    conditional move, but maybe one of the extensions has conditional
    moves.

    Concerning routers, I expect that the software running on it comes
    from the router manufacturer, so the kind of security offered by constant-time instructions probably is not very relevant.

    [1] Of course, with Spectre all code that runs in the process where
    the secret lies can be used to extract the secret, and using
    constant-time code for the whole process is not practically feasible
    unless the process does very little. Intel had not introduced a Spectre-immune CPU yet, which is reproachable after more then 8 years.

    - anton
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From MitchAlsup@[email protected] to comp.arch on Sun Mar 29 18:58:50 2026
    From Newsgroup: comp.arch


    Stefan Monnier <[email protected]> posted:

    Thomas Koenig [2026-03-28 23:12:52] wrote:
    They care production, which "generally includes any major stage of the process through which the device is made including manufacturing,
    assembly, design, and development."

    So, using ARM as the CPU for a router seems to be out; they are
    UK-based. x86 CPUs are too power-hungry, so Intel and AMD are out.
    MIPS is dead, as is SPARC. NXP might be able to revive PowerPC
    for embedded applications in routers, but I somehow doubt it.

    That pretty much leaves... RISC-V.

    They also say:

    Is a router produced in the United States containing
    foreign-produced components now “covered equipment” and prohibited
    from FCC equipment authorization?

    • Non-“covered” devices do not become “covered” simply because they
    contain a “covered” component part, unless the “covered” component
    part is a modular transmitter under the FCC’s rules. 47 CFR §§
    2.903(b), 15.212.

    • Therefore, a router produced in the United States is not
    considered “covered” equipment solely because it contains one or
    more foreign-made components.

    which suggests to me that they may not care if the CPU is
    produced elsewhere.

    Strange use of the word "covered".

    In any case, I highly doubt this is a decision based on security
    concerns (esp since they exclude real routers used in infrastructure: "Routers" is defined by National Institute of Standards and Technology’s Internal Report 8425A to mean consumer-grade networking devices that are primarily intended for residential use and can be installed by the
    customer).

    It's protectionism (and as Anton points out: combined with a nice
    opportunity for bribes).


    === Stefan
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Michael S@[email protected] to comp.arch on Mon Mar 30 02:11:35 2026
    From Newsgroup: comp.arch

    On Sun, 29 Mar 2026 18:56:53 GMT
    MitchAlsup <[email protected]d> wrote:
    [email protected] (Anton Ertl) posted:

    MitchAlsup <[email protected]d> writes:
    Given that RISC-V is "at least as insecure" as x86, x86-64, ARM in
    the face of current attack vectors
    ...
    But perhaps an actually secure ISA (and rest of system) is being
    given an advantage where funding might be secured.

    What kind of security do you think an ISA can provide or subvert and
    what attack vectors do you have in mind?

    Spectr� family
    Meltdown family
    RowHammer family
    Return Oriented Programming
    Stack Smashing
    High precision timer variances
    Constant time evaluation

    1,2,3 and 6 irrelevant for devices that do not run arbitrary untrusted binaries.
    7 is rellevant in theory, but in practice attack will be very hard.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Adam Sampson@[email protected] to comp.arch on Mon Mar 30 03:16:29 2026
    From Newsgroup: comp.arch

    [email protected] (Anton Ertl) writes:

    What kind of security do you think an ISA can provide or subvert and
    what attack vectors do you have in mind?

    Control flow integrity has been mentioned elsewhere in the thread -
    shadow stacks are a decent approach to that, but there are also things
    like branch target identification (simple but not hugely useful) and
    pointer authentication (more interesting, if there are enough bits spare
    in a regular pointer). The idea here is to prevent code injection (your
    classic 1990s buffer overflow, etc.) and ROP-like attacks where existing
    code is being invoked in an unexpected way.

    Safer approaches to pointers are another important area - this can be
    things like tagged pointers combined with tagged memory (again, if you
    have enough bits free in your pointers to make the tags infeasible to
    guess), or support for capability pointers that encode bounds and can't
    be falsified. CHERI is the most visible implementation of the latter,
    and it's a really neat piece of work. The aim of this is to catch a lot
    of the common attack vectors in memory-unsafe languages like C -
    out-of-bounds writes, use-after-free, reading uninitialised memory
    etc. - and it also has the potential to make the checks that memory-safe languages do cheaper, so it's a win all round.

    There are other aspects of the ISA design that might influence security
    through making existing techniques cheaper to implement - e.g. address
    space layout randomisation is pretty much standard these days, but the
    expense of implementing it differs a bit between architectures. So if
    you're designing a new architecture, making PIC code as efficient as
    possible means that people have less incentive to turn off ASLR...

    Thanks,
    --
    Adam Sampson <[email protected]> <http://offog.org/>
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From David Brown@[email protected] to comp.arch on Tue Mar 31 16:35:25 2026
    From Newsgroup: comp.arch

    On 29/03/2026 13:34, Anton Ertl wrote:
    Thomas Koenig <[email protected]> writes:
    So, using ARM as the CPU for a router seems to be out; they are
    UK-based.

    According to the government of the USA (when they decided to forbid
    certain ARM lincensing or somesuch to certain Chinese companies, ARM
    is USA technology, and the fact that many core designs are coming out
    of the design center in Austin (IIRC) gives some credibility to the
    POV. OTOH, the ARM tax for any licensed cores or architectures goes
    to ARM (UK) and through them to Softbank (Japan) and its investores,
    wherever in the world they are, and that might be seen as a reason for counting even SoCs designed and manufactured in the USA, where the ARM
    core was deigned in Austin as being a non-USA SoC.

    x86 CPUs are too power-hungry

    My Tremont-based office desktop uses less power than my router, so I
    doubt that.

    NXP might be able to revive PowerPC
    for embedded applications in routers, but I somehow doubt it.

    If it's good business for them, they probably can be convinced. But
    NXP are have their headquarters in the Netherlands, so I doubt that
    PowerPCs from them will count as US-based without a significant bribe.

    - anton

    All a manufacturer needs to do is award Trump the first ever award for promoting global unity through mindless xenophobia - if it is gold
    plated, it doesn't matter if it is designed in Iran and fabricated in
    North Korea, it will be on sale in the USA.

    --- Synchronet 3.21f-Linux NewsLink 1.2