• Re: Port forwarding from RPi to Windows machine

    From Theo@3:770/3 to kyonshi on Mon Feb 5 18:06:50 2024
    kyonshi <gmkeros@gmail.com> wrote:
    I am behind a NAT, but I have a single RPi 3 running on a public IP. Now
    I found that to use a specific application properly on my Windows laptop
    I would need to have it on a public IP occasionally, so some clients
    could connect to it.
    Is there a way to make some sort of port forwarding from the Raspberry
    (which has both a publich eth0 IP and a private wlan0 IP) to my Windows machine via an app on the Raspberry? I tried with miniupnpc, but it
    demands a router that can be set to forward ports, and my ISP doesn't
    like that.

    If you're running SSH on the Pi on a public port you can make a port
    forward. This tunnels port 1234 to port 4567 on the Windows machine:

    ssh -L 1234:windows-pc.lan:4567 pi@raspberrypi.my.house

    with windows-pc.lan and raspberrypi.my.house being the DNS names or IP addresses of the machines concerned. Then you tell whatever app you're
    using to connect to localhost port 1234. eg if the Windows box is running a web app you're tell your browser to go to http://localhost:1234/

    To do this you need to run SSH first, and the connection will go away once
    the SSH session is closed.

    You can also tunnel a SOCKS proxy:

    ssh -D 3456 pi@raspberrypi.my.house

    and then configure Windows / browser / etc to use the SOCKS proxy on
    localhost port 3456. This will allow connection to all machines on your network as if you were there.


    It is also possible to have the Pi permanently port forward, but for that
    you expose the Windows machine to every attacker on the internet. SSH is designed for that and is probably more secure.

    Another option is to run a VPN server on the Pi and connect to it via a VPN client, which allows you into your home network. Wireguard is a simple and efficient VPN, or OpenVPN has some ways to get around ISP blocking of VPNs.

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to kyonshi on Tue Feb 6 00:51:21 2024
    On 2/5/24 12:40 PM, kyonshi wrote:
    I am behind a NAT, but I have a single RPi 3 running on a public IP. Now
    I found that to use a specific application properly on my Windows laptop
    I would need to have it on a public IP occasionally, so some clients
    could connect to it.
    Is there a way to make some sort of port forwarding from the Raspberry
    (which has both a publich eth0 IP and a private wlan0 IP) to my Windows machine via an app on the Raspberry? I tried with miniupnpc, but it
    demands a router that can be set to forward ports, and my ISP doesn't
    like that.


    IF you can get it, spend a few extra $$$ on a static IP.
    Makes things a LOT easier.

    To deal with dynamic IPs ... first off there are $$$
    services. Basically they monitor your real IP, then
    update DNS servers to match per change.

    However I don't like paying extra $$$, or giving
    commercial entities too much access/info.

    So, I wrote a little Python sockets daemon that
    polls for a coded packet from the dest - plus
    one for the dest that detects an IP change and
    sends it on via the tiny packet over a selected
    port. The client polls this port, and uses the
    packet to update the current IP address. A
    'personal' version of DDNS utils. Not 'public'
    however, no providers DNS nums are changed. COULD
    be in theory though ...

    If I can find it in The Mess I could post the
    daemon/poller code. Not very flexible, but
    it worked ok for years. Thing is, the desired
    target for the IP daemon WAS a static IP. For
    broader use you'd have to have the same or
    post the info elsewhere (a provider acct
    that offers ssh access to a file maybe.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to 68g.1499@etr6.net on Tue Feb 6 08:38:02 2024
    On Tue, 6 Feb 2024 00:51:21 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

    To deal with dynamic IPs ... first off there are $$$
    services. Basically they monitor your real IP, then
    update DNS servers to match per change.

    There are free DNS services that support dynamic DNS (eg he.net),
    and most domain registrars provide DNS with the domain including dynamic entries.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to Ahem A Rivet's Shot on Wed Feb 7 01:39:07 2024
    On 2/6/24 3:38 AM, Ahem A Rivet's Shot wrote:
    On Tue, 6 Feb 2024 00:51:21 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

    To deal with dynamic IPs ... first off there are $$$
    services. Basically they monitor your real IP, then
    update DNS servers to match per change.

    There are free DNS services that support dynamic DNS (eg he.net),
    and most domain registrars provide DNS with the domain including dynamic entries.

    All the "big" services quit offering free versions
    a long time ago. DynDNS was good. But now ... $$$

    Obscure services, um ... don't want them in my boxes
    and it was funner to kinda write my own.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to 68g.1499@etr6.net on Wed Feb 7 07:19:04 2024
    On Wed, 7 Feb 2024 01:39:07 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

    On 2/6/24 3:38 AM, Ahem A Rivet's Shot wrote:
    On Tue, 6 Feb 2024 00:51:21 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

    To deal with dynamic IPs ... first off there are $$$
    services. Basically they monitor your real IP, then
    update DNS servers to match per change.

    There are free DNS services that support dynamic DNS (eg
    he.net), and most domain registrars provide DNS with the domain
    including dynamic entries.

    All the "big" services quit offering free versions
    a long time ago. DynDNS was good. But now ... $$$

    no-ip is still around and still free, joined these days by dynu, afraid.org, duckdns and clouddns all of which provide much the same service
    as dyndns used to. If you have a domain registered then there's the
    registrar and he.net.

    Obscure services, um ... don't want them in my boxes

    The only thing that goes in your box is the daemon that registers changes of IP address, many of them publish the details so you can write
    your own.

    and it was funner to kinda write my own.

    Fair enough that's always a good reason.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=C3=B6rn_Lundin?=@3:770/3 to All on Wed Feb 7 09:06:56 2024
    On 2024-02-07 07:39, 68g.1499 wrote:

      Obscure services, um ... don't want them in my boxes
      and it was funner to kinda write my own.


    With duckdns you do that yourself (or they provide a simple script)

    My crontab contains a script containing this (obfuscated)
    Not very obscure

    #!/bin/bash
    domain=some.name.duckdns.org
    token=xxxx-x-x-x-x-x-x-xxx url="https://www.duckdns.org/update?domains=${domain}&token=${token}&ip="
    echo url=${url} | curl -k -o /var/log/duck.log -K - 2> /dev/null
    echo "$(date)" >/tmp/duckdns.log


    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From mm0fmf@3:770/3 to Ahem A Rivet's Shot on Wed Feb 7 20:55:11 2024
    On 07/02/2024 07:19, Ahem A Rivet's Shot wrote:
    On Wed, 7 Feb 2024 01:39:07 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

    On 2/6/24 3:38 AM, Ahem A Rivet's Shot wrote:
    On Tue, 6 Feb 2024 00:51:21 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

    To deal with dynamic IPs ... first off there are $$$
    services. Basically they monitor your real IP, then
    update DNS servers to match per change.

    There are free DNS services that support dynamic DNS (eg
    he.net), and most domain registrars provide DNS with the domain
    including dynamic entries.

    All the "big" services quit offering free versions
    a long time ago. DynDNS was good. But now ... $$$

    no-ip is still around and still free, joined these days by dynu, afraid.org, duckdns and clouddns all of which provide much the same service as dyndns used to. If you have a domain registered then there's the
    registrar and he.net.

    Obscure services, um ... don't want them in my boxes

    The only thing that goes in your box is the daemon that registers changes of IP address, many of them publish the details so you can write
    your own.

    and it was funner to kinda write my own.

    Fair enough that's always a good reason.


    afraid.org works very well for $0

    I have a script called by cron every 15mins

    #! /bin/bash

    wget -O - http://freedns.afraid.org/dynamic/update.php?<some_magic_UID>
    /tmp/afraid_dns.log 2>& 1

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Higton@3:770/3 to Ahem A Rivet's Shot on Wed Feb 7 21:16:39 2024
    In message <20240207071904.4821f2362f045ff803d62b57@eircom.net>
    Ahem A Rivet's Shot <steveo@eircom.net> wrote:

    On Wed, 7 Feb 2024 01:39:07 -0500 "68g.1499" <68g.1499@etr6.net> wrote:

    On 2/6/24 3:38 AM, Ahem A Rivet's Shot wrote:
    On Tue, 6 Feb 2024 00:51:21 -0500 "68g.1499" <68g.1499@etr6.net> wrote:

    To deal with dynamic IPs ... first off there are $$$
    services. Basically they monitor your real IP, then
    update DNS servers to match per change.

    There are free DNS services that support dynamic DNS (eg he.net), and most domain registrars provide DNS with the domain including dynamic entries.

    All the "big" services quit offering free versions
    a long time ago. DynDNS was good. But now ... $$$

    no-ip is still around and still free

    ... and I use it successfully. Also dynv6.com for IPv6 DDNS (I have two entries).

    David

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1502@3:770/3 to All on Fri Feb 9 04:14:38 2024
    On 2/7/24 3:55 PM, mm0fmf wrote:
    On 07/02/2024 07:19, Ahem A Rivet's Shot wrote:
    On Wed, 7 Feb 2024 01:39:07 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

    On 2/6/24 3:38 AM, Ahem A Rivet's Shot wrote:
    On Tue, 6 Feb 2024 00:51:21 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

         To deal with dynamic IPs ... first off there are $$$
         services. Basically they monitor your real IP, then
         update DNS servers to match per change.

        There are free DNS services that support dynamic DNS (eg
    he.net), and most domain registrars provide DNS with the domain
    including dynamic entries.

        All the "big" services quit offering free versions
        a long time ago. DynDNS was good. But now ... $$$

        no-ip is still around and still free, joined these days by dynu,
    afraid.org, duckdns and clouddns all of which provide much the same
    service
    as dyndns used to. If you have a domain registered then there's the
    registrar and he.net.

        Obscure services, um ... don't want them in my boxes

        The only thing that goes in your box is the daemon that registers
    changes of IP address, many of them publish the details so you can write
    your own.

        and it was funner to kinda write my own.

        Fair enough that's always a good reason.


    afraid.org works very well for $0

    I have a script called by cron every 15mins

    #! /bin/bash

    wget -O - http://freedns.afraid.org/dynamic/update.php?<some_magic_UID>
    /tmp/afraid_dns.log 2>& 1


    DO gloss over the source code, just in case :-)

    I'm inclined to NOT trust 3rd-party daemons
    these days. If anyone is offering $0 services,
    well, HOW do they stay in biz ???

    BTW, the code needed for a dynamic DNS daemon
    should be quite SHORT. I know this because I've
    writ my own more than once. If your "free" service
    is hundreds or thousands of lines then BEWARE.

    Just sayin'

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=C3=B6rn_Lundin?=@3:770/3 to All on Fri Feb 9 10:30:15 2024
    On 2024-02-09 10:14, 68g.1502 wrote:

    I have a script called by cron every 15mins

    #! /bin/bash

    wget -O -
    http://freedns.afraid.org/dynamic/update.php?<some_magic_UID>  >>
    /tmp/afraid_dns.log 2>& 1


      DO gloss over the source code, just in case  :-)


    Gloss over wget's source code?
    Because that is the only one mentioned here. no daemons, just plain
    wget. And I got an example with curl. Installed by the OS




    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From mm0fmf@3:770/3 to All on Fri Feb 9 10:00:33 2024
    On 09/02/2024 09:30, Björn Lundin wrote:
    On 2024-02-09 10:14, 68g.1502 wrote:

    I have a script called by cron every 15mins

    #! /bin/bash

    wget -O -
    http://freedns.afraid.org/dynamic/update.php?<some_magic_UID>  >>
    /tmp/afraid_dns.log 2>& 1


       DO gloss over the source code, just in case  :-)


    Gloss over wget's source code?
    Because that is the only one mentioned here. no daemons, just plain
    wget. And I got an example with curl. Installed by the OS





    I blocked the nym changing troll sometime back. At first I thought it
    was someone's AI experiment. But it's too full of shit and wrong so much
    of the time that even AI isn't that dumb.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1503@3:770/3 to All on Fri Feb 9 20:41:11 2024
    On 2/9/24 5:00 AM, mm0fmf wrote:
    On 09/02/2024 09:30, Björn Lundin wrote:
    On 2024-02-09 10:14, 68g.1502 wrote:

    I have a script called by cron every 15mins

    #! /bin/bash

    wget -O -
    http://freedns.afraid.org/dynamic/update.php?<some_magic_UID>  >>
    /tmp/afraid_dns.log 2>& 1


       DO gloss over the source code, just in case  :-)


    Gloss over wget's source code?
    Because that is the only one mentioned here. no daemons, just plain
    wget. And I got an example with curl. Installed by the OS





    I blocked the nym changing troll sometime back. At first I thought it
    was someone's AI experiment. But it's too full of shit and wrong so much
    of the time that even AI isn't that dumb.


    Feelings of inadequacy dude ? :-)

    Wget and the daemons for dynDNS and friends are very
    different things BTW.

    And hmmmm ... when IS the last time anyone actually
    DID look-over wget's source code ??? The best place
    to hide evil is inside something deemed "old and
    reliable" .....

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to 68g.1504@exr3.net on Sat Feb 10 07:14:27 2024
    On Fri, 9 Feb 2024 20:41:11 -0500
    "68g.1503" <68g.1504@exr3.net> wrote:

    Wget and the daemons for dynDNS and friends are very
    different things BTW.

    No they are not - every dynamic dns service I know of updates in essentially the same way, you make an http(s) request with the domain, an authentication key and optionally the IP address (otherwise it uses the source). Usually curl or wget is used to make the request, it is good
    practice to minimise the requests by checking for IP changes but not
    necessary. My ddns daemon looks like this:

    #!/bin/sh
    old_external=''
    while true
    do
    external_ip=`fetch -q -o - http://ifconfig.me/ip`
    if [ "$external_ip" -a "$old_external" != "$external_ip" ]
    then
    curl -s -4 "https://<HOST>:<KEY>@dyn.dns.he.net/nic/update?hostname=<HOST>"
    fi
    sleep 30
    done

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Ahem A Rivet's Shot on Sat Feb 10 07:40:58 2024
    Ahem A Rivet's Shot wrote:

    every dynamic dns service I know of updates in essentially the same
    way, you make an http(s) request with the domain, an authentication
    key and optionally the IP address

    And then there are DNS providers which accept RFC1996 compliant NOTIFY transactions, rather than rolling their own ...

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Andy Burns on Sat Feb 10 08:14:57 2024
    On Sat, 10 Feb 2024 07:40:58 +0000
    Andy Burns <usenet@andyburns.uk> wrote:


    Ahem A Rivet's Shot wrote:

    every dynamic dns service I know of updates in essentially the same
    way, you make an http(s) request with the domain, an authentication
    key and optionally the IP address

    And then there are DNS providers which accept RFC1996 compliant NOTIFY transactions, rather than rolling their own ...

    That's for relaying updates from master to slave DNS servers not
    for announcing a change of dynamic IP to the master.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Sat Feb 10 10:56:05 2024
    On 10/02/2024 10:47, Björn Lundin wrote:
    On 2024-02-10 02:41, 68g.1503 wrote:
       And hmmmm ... when IS the last time anyone actually
       DID look-over wget's source code ??? The best place
       to hide evil is inside something deemed "old and
       reliable" .....

    Are you saying you are looking into EVERY package's source code you
    download via apt BEFORE you install it?
    Or are you saying that one should do it?

    Sounds bit hysterical to me.

    You do know that both wget and curl are provided by debian based (and
    most other ) distribution via their repository tool ?

    If you don't trust your distribution, you should switch, or roll your
    own distribution.
    But then - I guess you have lots of work ahead of you verifying/looking
    over source code ...

    Not hard to build a simple wget clone using libcurl


    --
    “It is hard to imagine a more stupid decision or more dangerous way of
    making decisions than by putting those decisions in the hands of people
    who pay no price for being wrong.”

    Thomas Sowell

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=C3=B6rn_Lundin?=@3:770/3 to All on Sat Feb 10 11:47:32 2024
    On 2024-02-10 02:41, 68g.1503 wrote:
      And hmmmm ... when IS the last time anyone actually
      DID look-over wget's source code ??? The best place
      to hide evil is inside something deemed "old and
      reliable" .....

    Are you saying you are looking into EVERY package's source code you
    download via apt BEFORE you install it?
    Or are you saying that one should do it?

    Sounds bit hysterical to me.

    You do know that both wget and curl are provided by debian based (and
    most other ) distribution via their repository tool ?

    If you don't trust your distribution, you should switch, or roll your
    own distribution.
    But then - I guess you have lots of work ahead of you verifying/looking
    over source code ...

    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sat Feb 10 13:44:06 2024
    On Sat, 10 Feb 2024 10:56:05 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    Not hard to build a simple wget clone using libcurl

    Well yes libcurl does all the work.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=C3=B6rn_Lundin?=@3:770/3 to The Natural Philosopher on Sat Feb 10 19:37:04 2024
    On 2024-02-10 11:56, The Natural Philosopher wrote:
    On 10/02/2024 10:47, Björn Lundin wrote:
    On 2024-02-10 02:41, 68g.1503 wrote:
       And hmmmm ... when IS the last time anyone actually
       DID look-over wget's source code ??? The best place
       to hide evil is inside something deemed "old and
       reliable" .....

    Are you saying you are looking into EVERY package's source code you
    download via apt BEFORE you install it?
    Or are you saying that one should do it?

    Sounds bit hysterical to me.

    You do know that both wget and curl are provided by debian based (and
    most other ) distribution via their repository tool ?

    If you don't trust your distribution, you should switch, or roll your
    own distribution.
    But then - I guess you have lots of work ahead of you
    verifying/looking over source code ...

    Not hard to build a simple wget clone using libcurl


    Of course not - but I was referring to that if you don't trust the
    binaries from your distribution, then you'd need to check ALL source code.
    Not only wget/curl - but everything from kernel all the way to web browsers

    Either you trust your distribution or not.


    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to bnl@nowhere.com on Sat Feb 10 19:12:44 2024
    On Sat, 10 Feb 2024 19:37:04 +0100
    Björn Lundin <bnl@nowhere.com> wrote:

    Of course not - but I was referring to that if you don't trust the
    binaries from your distribution, then you'd need to check ALL source code. Not only wget/curl - but everything from kernel all the way to web
    browsers

    Do all that and you are *still* open to Ken Thompson's attack via a poisoned compiler.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=C3=B6rn_Lundin?=@3:770/3 to Ahem A Rivet's Shot on Sat Feb 10 23:13:20 2024
    On 2024-02-10 20:12, Ahem A Rivet's Shot wrote:
    On Sat, 10 Feb 2024 19:37:04 +0100
    Björn Lundin <bnl@nowhere.com> wrote:

    Of course not - but I was referring to that if you don't trust the
    binaries from your distribution, then you'd need to check ALL source code. >> Not only wget/curl - but everything from kernel all the way to web
    browsers

    Do all that and you are *still* open to Ken Thompson's attack via a poisoned compiler.


    Well, verifying gcc sources could be included in the above - 'between
    kernel and web browser'. At least if you are installing compilers



    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to bnl@nowhere.com on Sun Feb 11 05:17:08 2024
    On Sat, 10 Feb 2024 23:13:20 +0100
    Björn Lundin <bnl@nowhere.com> wrote:

    On 2024-02-10 20:12, Ahem A Rivet's Shot wrote:
    On Sat, 10 Feb 2024 19:37:04 +0100
    Björn Lundin <bnl@nowhere.com> wrote:

    Of course not - but I was referring to that if you don't trust the
    binaries from your distribution, then you'd need to check ALL source
    code. Not only wget/curl - but everything from kernel all the way to
    web browsers

    Do all that and you are *still* open to Ken Thompson's attack
    via a poisoned compiler.


    Well, verifying gcc sources could be included in the above - 'between
    kernel and web browser'. At least if you are installing compilers

    The point of Ken Thomson's attack is that you have to compile those
    gcc sources and that compiler can poison the binary you produce from the
    clean gcc sources. So inspecting sources doesn't help you.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sun Feb 11 08:58:50 2024
    On 11/02/2024 05:17, Ahem A Rivet's Shot wrote:
    On Sat, 10 Feb 2024 23:13:20 +0100
    Björn Lundin <bnl@nowhere.com> wrote:

    On 2024-02-10 20:12, Ahem A Rivet's Shot wrote:
    On Sat, 10 Feb 2024 19:37:04 +0100
    Björn Lundin <bnl@nowhere.com> wrote:

    Of course not - but I was referring to that if you don't trust the
    binaries from your distribution, then you'd need to check ALL source
    code. Not only wget/curl - but everything from kernel all the way to
    web browsers

    Do all that and you are *still* open to Ken Thompson's attack
    via a poisoned compiler.


    Well, verifying gcc sources could be included in the above - 'between
    kernel and web browser'. At least if you are installing compilers

    The point of Ken Thomson's attack is that you have to compile those
    gcc sources and that compiler can poison the binary you produce from the clean gcc sources. So inspecting sources doesn't help you.

    Obviously one must write one's own compiler!

    A mere snap for any greybeard unix sysadmin...

    --
    “It is hard to imagine a more stupid decision or more dangerous way of
    making decisions than by putting those decisions in the hands of people
    who pay no price for being wrong.”

    Thomas Sowell

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sun Feb 11 10:02:46 2024
    On 11/02/2024 09:07, Ahem A Rivet's Shot wrote:
    On Sun, 11 Feb 2024 08:58:50 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 11/02/2024 05:17, Ahem A Rivet's Shot wrote:
    On Sat, 10 Feb 2024 23:13:20 +0100

    The point of Ken Thomson's attack is that you have to compile
    those gcc sources and that compiler can poison the binary you produce
    from the clean gcc sources. So inspecting sources doesn't help you.

    Obviously one must write one's own compiler!

    So what do you compile it with ?

    You don't. You already wrote your own assembler. In machine code!

    You compile the proto-compiler with THAT.

    THEN you can use it to compile future versions of itself.

    An assemblers is - or ought to be - a 1:1 translator from human readable
    to machine readable commands.

    It cant be corrupted.

    Unless the chip itself is compromisesd :-)

    So design your own chip!

    That is what happened with the early days of ARM chips. I know people
    involved in writing those compilers..


    If the compiler you use to compile
    your clean room compiler is poisoned then so will be the compiled compiler despite your clean room code. That's the Thompson trap.

    The only way out of the Thompson trap is to write a new compiler
    from scratch in assembler and assemble it by hand. Then you just have to trust the hardware.

    Or design it yourself.

    The ARM is a special CPU that was designed initially to beat the 6502
    and walk all over z80s and 8080s.

    Because they couldn't afford massive wafers, it was strictly limited in hardware. All they could do was a very basic instruction set and a lot
    of on-chip registers. And a three instruction set pipeline and clock it
    as fast as it would go. And a 32 bit address bus. To take advantage of
    a lot more RAM that was getting cheaper by the day. The low power was
    simply a cost saving measure - a plastic cased low dissipation chip was *cheaper*.

    And a few - maybe only one - very bright boys (sophie wilson) , looked
    at the absolute minimum of what those instructions had to do.

    Complex instructions could be written to use those registers and
    accessing them was super fast.

    In a way it mimicked what was happening in CISC but pulled the microcode
    out of the chip into external software libraries.

    And there it was. The Acorn Risc Machine. Not a very much used chip
    until mobile computing came along, when its low power performance and
    ability to be integrated under license into anyone else's hardware chips
    made it a world beater.

    https://arstechnica.com/gadgets/2022/09/a-history-of-arm-part-1-building-the-first-chip/

    Read the whole story.



    --
    For in reason, all government without the consent of the governed is the
    very definition of slavery.

    Jonathan Swift

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sun Feb 11 09:07:42 2024
    On Sun, 11 Feb 2024 08:58:50 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 11/02/2024 05:17, Ahem A Rivet's Shot wrote:
    On Sat, 10 Feb 2024 23:13:20 +0100

    The point of Ken Thomson's attack is that you have to compile
    those gcc sources and that compiler can poison the binary you produce
    from the clean gcc sources. So inspecting sources doesn't help you.

    Obviously one must write one's own compiler!

    So what do you compile it with ? If the compiler you use to compile your clean room compiler is poisoned then so will be the compiled compiler despite your clean room code. That's the Thompson trap.

    The only way out of the Thompson trap is to write a new compiler
    from scratch in assembler and assemble it by hand. Then you just have to
    trust the hardware.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=C3=B6rn_Lundin?=@3:770/3 to Ahem A Rivet's Shot on Sun Feb 11 13:22:37 2024
    On 2024-02-11 06:17, Ahem A Rivet's Shot wrote:


    The point of Ken Thomson's attack is that you have to compile those
    gcc sources and that compiler can poison the binary you produce from the clean gcc sources. So inspecting sources doesn't help you.


    Ah, oh, didn't know that.

    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to bnl@nowhere.com on Sun Feb 11 13:48:42 2024
    On Sun, 11 Feb 2024 13:22:37 +0100
    Björn Lundin <bnl@nowhere.com> wrote:

    On 2024-02-11 06:17, Ahem A Rivet's Shot wrote:
    The point of Ken Thomson's attack is that you have to compile
    those gcc sources and that compiler can poison the binary you produce
    from the clean gcc sources. So inspecting sources doesn't help you.


    Ah, oh, didn't know that.

    It was a classic eye-opening paper, it is extremely hard to get a system that is certain not to contain any hidden surprises - you have have
    to write your own assembler in machine code, compiler in assembler and
    build your own hardware, from scratch.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sun Feb 11 14:04:38 2024
    On Sun, 11 Feb 2024 10:02:46 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    So design your own chip!

    Do you trust the chip layout software not to embed a backdoor or something ? What do you run that chip layout software on and why do you
    trust that system. You'd best start from MSI TTL/CMOS logic and build your
    own system to run the chip design software (that you write or at least
    audit) to design the chips.

    The ARM is a special CPU that was designed initially to beat the 6502
    and walk all over z80s and 8080s.

    I know - I was in Cambridge and in the business when it was being
    done. I knew about the ARM before it was released, they were pretty good at keeping it out of the rumour mill but nothing is completely secret in Cambridge. Earliest rumours had Andy Hopper involved.

    The modern ARMv8 architecture bears little resemblance to the
    original ARM used in the Archimedes, it has become massively complex. Even
    so for the time the performance of the original ARM was stunning, matched
    only by the Transputer which was weird and expensive. Once thought to be
    the future of computing the Transputer is all but forgotten, while ARMv8 has become the dominant 64 bit architecture (measured in numbers of CPUs manufactured).

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From mm0fmf@3:770/3 to Ahem A Rivet's Shot on Sun Feb 11 14:53:16 2024
    On 11/02/2024 14:04, Ahem A Rivet's Shot wrote:
    On Sun, 11 Feb 2024 10:02:46 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    So design your own chip!

    Do you trust the chip layout software not to embed a backdoor or something ? What do you run that chip layout software on and why do you
    trust that system. You'd best start from MSI TTL/CMOS logic and build your own system to run the chip design software (that you write or at least
    audit) to design the chips.

    The ARM is a special CPU that was designed initially to beat the 6502
    and walk all over z80s and 8080s.

    I know - I was in Cambridge and in the business when it was being
    done. I knew about the ARM before it was released, they were pretty good at keeping it out of the rumour mill but nothing is completely secret in Cambridge. Earliest rumours had Andy Hopper involved.

    The modern ARMv8 architecture bears little resemblance to the
    original ARM used in the Archimedes, it has become massively complex. Even
    so for the time the performance of the original ARM was stunning, matched only by the Transputer which was weird and expensive. Once thought to be
    the future of computing the Transputer is all but forgotten, while ARMv8 has become the dominant 64 bit architecture (measured in numbers of CPUs manufactured).


    I have a Transputer T9000 coffee mug somewhere. It has 4 handles spaced
    90deg apart... for those that know ;-)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sun Feb 11 14:52:15 2024
    On 11/02/2024 14:04, Ahem A Rivet's Shot wrote:
    On Sun, 11 Feb 2024 10:02:46 +0000
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    So design your own chip!

    Do you trust the chip layout software not to embed a backdoor or something ? What do you run that chip layout software on and why do you
    trust that system. You'd best start from MSI TTL/CMOS logic and build your own system to run the chip design software (that you write or at least
    audit) to design the chips.


    I think that its pretty difficult to encode an invisible backdoor in the silicon and not have it spotted at some fairly early stage.

    So many of these 'threat narratives' are, when examined closely,
    implausible to the point of downright impossibility.

    You can examine the machine code that your compiler and linker
    assembles. And people do. I certainly have done. If it doesn't match
    what you asked for in the high level language, there are questions to be answered.

    And of course the lower level the language the easier it is to check.
    One reason why I don't like C++ and friends.

    And likewise, if the silicon is updating bits of memory you didn't ask
    it to, or doing stuff that you dont recognise as valid...

    lets face it, I was watching an illicit free stream of an F1 race and
    suddenly frames started dropping...and I looked at my network widget and
    saw my uplink to the internet was being saturated. I was it seemed, part
    of some javascript botnet. It finished as soon as I closed the browser
    window.

    These things get *noticed*.

    The ARM is a special CPU that was designed initially to beat the 6502
    and walk all over z80s and 8080s.

    I know - I was in Cambridge and in the business when it was being
    done. I knew about the ARM before it was released, they were pretty good at keeping it out of the rumour mill but nothing is completely secret in Cambridge. Earliest rumours had Andy Hopper involved.

    The modern ARMv8 architecture bears little resemblance to the
    original ARM used in the Archimedes, it has become massively complex.

    True, but not germane to the point that its possible for a very small
    number of people to create a CPU, write an assembler, write a compile in assembler and bootsrtap their way to a known (to them, at least) good
    secure chipset and toolchain.

    And the antidote to all these people who assure you that lizards are
    running the earth and bugging their brains with embedded chips is to
    tell them to do precisely that.

    Or assure them that the only reason they think that, is *because the
    lizards want then to*.

    :-)



    --
    "When one man dies it's a tragedy. When thousands die it's statistics."

    Josef Stalin

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to none@invalid.com on Sun Feb 11 15:31:09 2024
    On Sun, 11 Feb 2024 14:53:16 +0000
    mm0fmf <none@invalid.com> wrote:

    I have a Transputer T9000 coffee mug somewhere. It has 4 handles spaced
    90deg apart... for those that know ;-)

    When I first read about the Transputer I wanted to hook 16 of them
    up into a hypercube.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From mm0fmf@3:770/3 to Ahem A Rivet's Shot on Sun Feb 11 16:37:59 2024
    On 11/02/2024 15:31, Ahem A Rivet's Shot wrote:
    On Sun, 11 Feb 2024 14:53:16 +0000
    mm0fmf <none@invalid.com> wrote:

    I have a Transputer T9000 coffee mug somewhere. It has 4 handles spaced
    90deg apart... for those that know ;-)

    When I first read about the Transputer I wanted to hook 16 of them
    up into a hypercube.


    I have programmed hypercubes of Analog Devices SHARC processors. The
    number crunching power was "awesome" back in the late 90s.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to All on Mon Feb 12 16:14:25 2024
    bW0wZm1mIHdyb3RlOg0KDQo+IEkgaGF2ZSBhIFRyYW5zcHV0ZXIgVDkwMDAgY29mZmVlIG11 ZyBzb21ld2hlcmUuIEl0IGhhcyA0IGhhbmRsZXMgc3BhY2VkIA0KPiA5MGRlZyBhcGFydC4u LiBmb3IgdGhvc2UgdGhhdCBrbm93IPCfmIkNCg0KSSB3YW50ZWQgdG8gZG8gbXkgZmluYWwg eWVhciBwcm9qZWN0IHVzaW5nIHRyYW5zcHV0ZXJzLCB1bmZvcnR1bmF0ZWx5IGl0IA0KdHVy bmVkIG91dCB0aGUgZGVwYXJ0bWVudCBvbmx5IGhhZCBvbmUgZGV2IGJvYXJkIGFuZCBjb3Vs ZG4ndCBnZXQgYW55IA0KbW9yZSAuLi4gZW5kZWQgdXAgdXNpbmcgQXBvbGxvIHdvcmtzdGF0 aW9ucyBpbnN0ZWFkLg0KDQo=

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to druck on Mon Feb 12 22:17:42 2024
    druck <news@druck.org.uk> wrote:
    Luckily ARM doesn't have a management engine - yet!

    Arm doesn't have a management engine, because Arm (mostly) don't make chips. That's up to Qualcomm, Samsung or whoever. You don't get a full datasheet
    for what's in one of those.

    In the case of the original Pi, the Arm *is* the management engine. It was used for managing the GPU, which was the main function of the chip originally.

    (well sorta, the original Broadcom chips didn't have an Arm in them)

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to The Natural Philosopher on Mon Feb 12 21:46:52 2024
    On 11/02/2024 14:52, The Natural Philosopher wrote:
    I think that its pretty difficult to encode an invisible backdoor in the silicon and not have it spotted at some fairly early stage.

    Then don't hide it, have it there in plain sight - like the Intel
    Management Engine, and the AMD equivalent.

    So many of these 'threat narratives' are, when examined closely,
    implausible to the point of downright impossibility.

    The more you examine details of the IME that we know about, the more
    worrying it gets. It's a CPU within CPU running closed software with
    higher privilege than main CPU, able to access all memory, any hardware
    and create its own network connections.

    You can examine the machine code that your compiler and linker
    assembles. And people do. I certainly have done. If it doesn't match
    what you asked for in the high level language, there are questions to be answered.

    You can look at the assembler of the main CPU as much as you like, but
    you've no idea what is running on the IME.

    Luckily ARM doesn't have a management engine - yet!

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Theo on Tue Feb 13 09:16:03 2024
    On 12/02/2024 22:17, Theo wrote:
    druck <news@druck.org.uk> wrote:
    Luckily ARM doesn't have a management engine - yet!

    Arm doesn't have a management engine, because Arm (mostly) don't make chips. That's up to Qualcomm, Samsung or whoever. You don't get a full datasheet for what's in one of those.

    In the case of the original Pi, the Arm *is* the management engine. It was used for managing the GPU, which was the main function of the chip originally.

    (well sorta, the original Broadcom chips didn't have an Arm in them)

    Theo

    Tell me more. This is a corner of history I am only vaguely familiar
    with., Wasn't the original chip a failed set top box chip? Which is why
    it always had HDMI.....

    --
    "First, find out who are the people you can not criticise. They are your oppressors."
    - George Orwell

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to druck on Tue Feb 13 09:13:36 2024
    On 12/02/2024 21:46, druck wrote:
    On 11/02/2024 14:52, The Natural Philosopher wrote:
    I think that its pretty difficult to encode an invisible backdoor in
    the silicon and not have it spotted at some fairly early stage.

    Then don't hide it, have it there in plain sight - like the Intel
    Management Engine, and the AMD equivalent.

    So many of these 'threat narratives' are, when examined closely,
    implausible to the point of downright impossibility.

    The more you examine details of the IME that we know about, the more
    worrying it gets. It's a CPU within CPU running closed software with
    higher privilege than main CPU, able to access all memory, any hardware
    and create its own network connections.

    You can examine the machine code that your compiler and linker
    assembles. And people do. I certainly have done. If it doesn't match
    what you asked for in the high level language, there are questions to
    be answered.

    You can look at the assembler of the main CPU as much as you like, but
    you've no idea what is running on the IME.

    Luckily ARM doesn't have a management engine - yet!

    ---druck

    Indeed. CISC processors running microcode are definitely in the 'secret software' class.
    Which is the nice thing about ARM. Keep it simple and run it blazingly
    fast. Although my friend who worked on the first chip at Acorn says it
    is massively more complex today than the original incarnation.

    But even microcode can be disassembled if you have the right kit and
    skills...

    --
    "Corbyn talks about equality, justice, opportunity, health care, peace, community, compassion, investment, security, housing...."
    "What kind of person is not interested in those things?"

    "Jeremy Corbyn?"

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to The Natural Philosopher on Tue Feb 13 10:55:58 2024
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 12/02/2024 22:17, Theo wrote:
    druck <news@druck.org.uk> wrote:
    Luckily ARM doesn't have a management engine - yet!

    Arm doesn't have a management engine, because Arm (mostly) don't make chips.
    That's up to Qualcomm, Samsung or whoever. You don't get a full datasheet for what's in one of those.

    In the case of the original Pi, the Arm *is* the management engine. It was used for managing the GPU, which was the main function of the chip originally.

    (well sorta, the original Broadcom chips didn't have an Arm in them)

    Theo

    Tell me more. This is a corner of history I am only vaguely familiar
    with., Wasn't the original chip a failed set top box chip? Which is why
    it always had HDMI.....

    https://en.wikipedia.org/wiki/Alphamosaic https://en.wikipedia.org/wiki/VideoCore

    The original Videocore graphics processor was designed by a Cambridge
    company called Alphamosaic. They were then bought by Broadcom in 2004.
    They were used as GPUs that were in addition to the primary processor in the system - eg in phones and media players (the 5th gen video iPod has a
    Videocore 2, the Nokia 808 Pureview has a VC4 [*]). There wasn't a CPU in
    them at this point - all the software was running on the GPU, which would communicate with the host CPU on a separate chip. For example the video
    iPod used an ARM7 CPU (PortalPlayer 5021C-TDF, dual ARM7 at about 75MHz).

    When the Pi project was coming together, the folks at Cambridge Broadcom
    were looking for a suitable chip. The VC4 was already in production and did roughly what they wanted but had no CPU, so the decision was made to modify
    the existing chip. The story goes that they raided their parts bin, found
    an already-decade-old ARM1176 and slapped it in the VC4 - I heard the
    timeline for this was a month. The rest is history.

    This is why the Pi Zero and 1 have the ancient ARMv6 CPU architecture, where other vendors were already shipping ARMv7 CPUs (Cortex A8 and similar)
    around 2007 or so. And also why the boot process on Pi 1-3 is backwards
    from what we're used to: they boot the GPU first and only later does the GPU start up the Arm. The GPU is the main processor in the system, the Arm is
    a secondary processor.

    Theo

    [*] I believe the image processing stack for the 808 Pureview with its then-massive sensor was written by Broadcom and/or Nokia Cambridge folks,
    some of whom later worked on the Pi camera interface.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to tnp@invalid.invalid on Tue Feb 13 17:46:22 2024
    In article <uqfbs0$20vgk$3@dont-email.me>,
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    Indeed. CISC processors running microcode are definitely in the 'secret >software' class.
    Which is the nice thing about ARM. Keep it simple and run it blazingly
    fast. Although my friend who worked on the first chip at Acorn says it
    is massively more complex today than the original incarnation.

    I've been poking around at these lately:

    https://github.com/BrunoLevy/learn-fpga/ https://github.com/bl0x/learn-fpga-amaranth/

    Two different HDLs, but with the same goal: start from nothing to bring up a RISC-V CPU on an FPGA. In its simplest form, you get only 11 instructions...not even integer multiply. It's even simpler than the 6502
    on which I got through high school and most of college.

    --
    _/_
    / v \ Scott Alfter (remove the obvious to send mail)
    (IIGS( https://alfter.us/ Top-posting!
    \_^_/ >What's the most annoying thing on Usenet?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andrew Smallshaw@3:770/3 to The Natural Philosopher on Wed Feb 14 21:02:37 2024
    On 2024-02-11, The Natural Philosopher <tnp@invalid.invalid> wrote:

    An assemblers is - or ought to be - a 1:1 translator from human readable
    to machine readable commands.

    There is _plenty_ of scope for an assembler to choose whatever
    opcodes it wants. Consider the simplest case of a NOP - some
    architectures have a specific NOP opcode, others it is simply a
    shorthand for an operation that does nothing, e.g. add 0 to a
    register and so on. Regardless there are plenty of alternatives
    that can be chosen. Things get more opaque once addressing modes,
    the size of jumps, immediate operands and so on are considered.
    I'm reminded of the warning in the A86 manual "this assembler
    generates a unique fingerprint in these cases, which I can detect
    in the binary whether you are registered or not".

    If the compiler you use to compile
    your clean room compiler is poisoned then so will be the compiled compiler >> despite your clean room code. That's the Thompson trap.

    There's a lot of mysticism that has been attached to that over the
    years, mostly by people who have never read the original report.
    It wasn't some magical AI code fairy that could identify that you
    were compiling any abstract compiler or login program and automatically
    conjure up appropriate code for the circumstances, it used
    fingerprinting IIRC at the token level (i.e. after the code is
    broken in to "words", but before parsing to figure out how those
    "words" are associated with each other). An independent implementation
    of functionally equivalent code, or even the same code after heavy
    edits over time, would not be affected.

    The ARM is a special CPU that was designed initially to beat the 6502
    and walk all over z80s and 8080s.

    No, it was designed for the Archimedes, pure and simple. The 8086
    was already one the market thus the rest of the industry essentially leapfrogged 16 bit and jumped straight to 32 bit. To this day 16
    bitters are few and far between. There's 8086-80286, MSP430, and...
    err... Well there's the original 68000 but that was 32 bit from a
    software viewpoint.

    Because they couldn't afford massive wafers, it was strictly limited in hardware. All they could do was a very basic instruction set and a lot
    of on-chip registers. And a three instruction set pipeline and clock it
    as fast as it would go. And a 32 bit address bus. To take advantage of
    a lot more RAM that was getting cheaper by the day. The low power was
    simply a cost saving measure - a plastic cased low dissipation chip was *cheaper*.

    And a few - maybe only one - very bright boys (sophie wilson) , looked
    at the absolute minimum of what those instructions had to do.

    That's a very romanticised view, it often happens in science and
    engineering when one of the characters has an interesting personal
    story, Alan Turing and Stephen Hawking would be others that come
    to mind. The feature set was a committee effort, the high level
    design was Roger/Sophie Wilson and the low level Steve Furber.
    But as above, it was designed for the Archimedes, no more and no
    less.

    The primary design objectives were a low per-unit cost (not design
    cost as sometimes stated) and a minimum of glue logic between major
    subsystems. I recall seeing a "triangle" diagram with the corners
    cut off, the centre of the triangle was the CPU, the corners were
    memory controller, graphics, and peripheral bus.

    You're correct to identify a plastic package as a design criteria,
    from memory the target was £2/chip which implied that over a ceramic
    one. None of the group had any chip design experience, they knew
    a plastic package meant no more than a 1-2W power dissipation, but
    had no idea what that meant in terms of design. Thus they optimised
    for power at every opportunity and undercut the target by orders
    of magnitude.

    The other dimension to lowering the cost of the package was reducing
    pin out to the bare minimum, hence the 24 bit (not 32 bit) address
    bus. Size of the wafer was an irrelevance since they never baked
    their own chips, die size yes they wanted to keep small to lower
    cost but not an over-riding consideration - it wasn't that much
    smaller than many other designs of the period.

    This is from my lecture notes and also a couple of pints while at
    Uni 25 years ago. The lecturer for hardware design was none other
    than Steve Furber who co-designed and literally wrote the book on
    the thing.

    --
    Andrew Smallshaw
    andrews@sdf.org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Andrew Smallshaw on Wed Feb 14 22:37:37 2024
    Andrew Smallshaw <andrews@sdf.org> wrote:
    The primary design objectives were a low per-unit cost (not design
    cost as sometimes stated) and a minimum of glue logic between major subsystems. I recall seeing a "triangle" diagram with the corners
    cut off, the centre of the triangle was the CPU, the corners were
    memory controller, graphics, and peripheral bus.

    You're correct to identify a plastic package as a design criteria,
    from memory the target was £2/chip which implied that over a ceramic
    one. None of the group had any chip design experience, they knew
    a plastic package meant no more than a 1-2W power dissipation, but
    had no idea what that meant in terms of design. Thus they optimised
    for power at every opportunity and undercut the target by orders
    of magnitude.

    The other dimension to lowering the cost of the package was reducing
    pin out to the bare minimum, hence the 24 bit (not 32 bit) address
    bus. Size of the wafer was an irrelevance since they never baked
    their own chips, die size yes they wanted to keep small to lower
    cost but not an over-riding consideration - it wasn't that much
    smaller than many other designs of the period.

    This is from my lecture notes and also a couple of pints while at
    Uni 25 years ago. The lecturer for hardware design was none other
    than Steve Furber who co-designed and literally wrote the book on
    the thing.

    That's about right - ARM1/ARM2 was designed specifically for the Archimedes, and various design decisions that remain in Aarch32 are because of specific constraints on that platform. For example ARM2 had no cache and was
    designed to make best use of FPM DRAM. Every instruction took two cycles except some where sequential memory accesses could be completed in a single cycle - hence LDM/STM instructions.

    Matt Evans (another of Steve's former students) did a good talk on this at
    CCC a few years ago: https://media.ccc.de/v/36c3-10703-the_ultimate_acorn_archimedes_talk

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Theo on Thu Feb 15 21:26:17 2024
    On 14/02/2024 22:37, Theo wrote:
    That's about right - ARM1/ARM2 was designed specifically for the Archimedes, and various design decisions that remain in Aarch32 are because of specific constraints on that platform. For example ARM2 had no cache and was
    designed to make best use of FPM DRAM. Every instruction took two cycles except some where sequential memory accesses could be completed in a single cycle - hence LDM/STM instructions.

    I know what you mean there, but just to clarify, the majority of
    arithmetic instructions took one cycle (except an extra cycle when using
    shift by a register or where the PC was the destination, and multiplies
    were up to 3 cycles).

    Memory loads and stores were two cycles, one to set up the transfer and
    one to do the transfer, but the memory system allowed a read or write to
    the next word in just one cycle. So the LDM and STM instructions were
    included which could transfer from 1 to 16 registers at a cost of 1 +
    number of registers transferred cycles (as long as it was within the
    same memory page). That did make quite a high upper bound on the
    interrupt latency though, which was an issue for real-time use.

    Strange how I can remember that from 35 years ago, but then you only had
    to know a few classes of instruction timings in order to be able to
    write highly optimised assembler. It became more and more complex with
    each subsequent ARM generation, and has been best left to a compiler for
    quite a while.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Lawrence D'Oliveiro@3:770/3 to All on Mon Feb 19 05:39:00 2024
    On Fri, 9 Feb 2024 20:41:11 -0500, 68g.1503 wrote:

    And hmmmm ... when IS the last time anyone actually
    DID look-over wget's source code ??? The best place
    to hide evil is inside something deemed "old and
    reliable" .....

    That’s what they want you to think.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)