Re: [9fans] ftpd on 9front
Quoth Garry :
> OK, so I am running ftpd on 9front, but on connecting I get:
>
> Connected to 192.168.1.108.
> 220 Plan 9 FTP server ready.
> 200 UTF8 always on
> User (192.168.1.108:(none)): glenda
> 331 Need password
> Password:
>
> 534 Command requires tls
> Login failed.
>
> Any ideas of how to get this work? I am indifferent to whether I either get
> TLS working or disable it, but I suppose getting TLS working is at least a
> learning experience.
>
> Any help much appreciated.
>
> Garry
To set up TLS, you can easily generate a self-signed cert; the manpage rsa(8)
has examples for httpd, it should be more or less the same for ftp. Note that
the private key needs to end up in a factotum that runs in the same namespace
as the daemon.
If you want a cert with a complete cert chain, you can also use auth/acmed
to generate a cert with letsencrypt; see man 8 acmed for details and examples.
There are no options to allow accepting your password in plain text, and I
would rather not add them. that said, it looks to be a one line patch to
disable all checking for that (see below, do *not* recommend).
--- a/sys/src/cmd/ip/ftpd.c
+++ b/sys/src/cmd/ip/ftpd.c
@@ -1089,7 +1089,7 @@
if(cistrcmp(cmd, t->name) == 0) {
if(t->needlogin && !ftpd.user.loggedin) {
reply(ftpd.out, "530 Command requires
login");
- } else if(t->needtls && !ftpd.conn.tlson) {
+ } else if(0 && t->needtls && !ftpd.conn.tlson) {
reply(ftpd.out, "534 Command requires
tls");
} else {
if(t->fn != passcmd)
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Td09db527ec1fde98-M72362e1da3f5d6fa01429103
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9Front on Intel N100?
Funny enough, I finally got another ethernet daughtboard for my
laptop, and this is apparently the chip (combo?) it has. I've found it
hasn't worked for me yet. I will look into it in the coming days!
Aidan
Quoth tlaro...@kergis.com:
> On Fri, Mar 28, 2025 at 07:24:28PM +1100, Oliver Lowe wrote:
> > Thanks for the tip!
> >
> > > I got a fanless mini PC with N100, Plan 9 installed no problem and
> > > recognised the network right away.
> >
> > What model NIC? I'm typing this from a N100 mini PC (running OpenBSD).
> > dmesg(8) reports the 2 network interfaces as:
> >
> > "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400)
> >
> > which I'm hoping should be supported based on my very non-expert
> > reading of /sys/src/9/pc/ether8169.c
>
> It is or will be supported since it is probably (from 0x5400) Macfg_68
> or Macfg_69:
>
> { 0x5400, Macfg_68, Jmb9k, Fdesc2 | Fphywk | F8168gplus | Fmagicpkt2,
> 0x8F00 },
> { 0x5400, Macfg_69, Jmb9k, Fdesc2 | Fphywk | F8168gplus | Fmagicpkt2,
> 0x8F00 },
>
> You can already verify the PCI vendor Id and the device Id. Should be
> one of these:
>
> enum { /* PCI vendors of */
> VRtl = 0x10EC, /* Realtek */
> VNcb = 0x10FF, /* NCube */
> VDlk = 0x1186, /* D-LINK */
> VAlt = 0x1259, /* Allied Telesis Inc */
> VUsr = 0x16EC, /* USRobotics */
> VLnk = 0x1737, /* Linksys */
>
> };
>
> And for the device:
>
> { VRtl, 0x8136, Rtl810x, Fpcie },
> { VRtl, 0x8161, Rtl8168, Fpcie }, /* RTL8168 add-on */
> { VRtl, 0x8162, Rtl8168, 0 }, /* RTL8168KB */
> { VRtl, 0x8168, Rtl8168, Fpcie }, /* RTL8168B */
> { VNcb, 0x8168, Rtl8168, 0 },
>
> --
> Thierry Laronde
> http://www.kergis.com/
> http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T25f54f1e44602c84-Mc42bcd76f32e7787773925e7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9Front on Intel N100?
On Fri, Mar 28, 2025 at 07:24:28PM +1100, Oliver Lowe wrote:
> Thanks for the tip!
>
> > I got a fanless mini PC with N100, Plan 9 installed no problem and
> > recognised the network right away.
>
> What model NIC? I'm typing this from a N100 mini PC (running OpenBSD).
> dmesg(8) reports the 2 network interfaces as:
>
> "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400)
>
> which I'm hoping should be supported based on my very non-expert
> reading of /sys/src/9/pc/ether8169.c
It is or will be supported since it is probably (from 0x5400) Macfg_68
or Macfg_69:
{ 0x5400, Macfg_68, Jmb9k, Fdesc2 | Fphywk | F8168gplus |
Fmagicpkt2, 0x8F00 },
{ 0x5400, Macfg_69, Jmb9k, Fdesc2 | Fphywk | F8168gplus |
Fmagicpkt2, 0x8F00 },
You can already verify the PCI vendor Id and the device Id. Should be
one of these:
enum { /* PCI vendors of */
VRtl = 0x10EC, /* Realtek */
VNcb = 0x10FF, /* NCube */
VDlk = 0x1186, /* D-LINK */
VAlt = 0x1259, /* Allied Telesis Inc */
VUsr = 0x16EC, /* USRobotics */
VLnk = 0x1737, /* Linksys */
};
And for the device:
{ VRtl, 0x8136, Rtl810x, Fpcie },
{ VRtl, 0x8161, Rtl8168, Fpcie }, /* RTL8168 add-on */
{ VRtl, 0x8162, Rtl8168, 0 }, /* RTL8168KB */
{ VRtl, 0x8168, Rtl8168, Fpcie }, /* RTL8168B */
{ VNcb, 0x8168, Rtl8168, 0 },
--
Thierry Laronde
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T25f54f1e44602c84-M222eb6809c3bb3aba9660828
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Acme event file and keyboard
You said "acme's event files on windows". To be absolutely precise: you mean this kind of window (from p9p and Edwood) (the 29 in this context)? ; 9p ls acme/29 addr body ctl data editout errors event rdsel tag wrsel xdata So: what's the exact command line with args that you're running? Because the error that you're seeing suggests that winwriteevent is sending a malformed message to acme. Do you get any complaint content in Acme's '+Errors' window? p9p Acme and Edwood both log some issues that show up in their file system implementation to +Errors. At least as how I understand the code, p9p Acme supports only the interception of (some) mouse events. The event flow in (e.g. Edwood) definitely does not include code to route key events to specific windows. This is perhaps a worthwhile API addition. Rob. On Wed, Mar 26, 2025 at 11:37 AM Matthieu Rakotojaona via 9fans < 9fans@9fans.net> wrote: > Has anyone managed to do anything productive with acme's event files on > windows and the keyboard ? All I can find is mouse-related scripts. > > I'm trying to do keybindings the easy way, by tapping into that event > file, but I have some issues: > > - When text is added the tag isn't updated with Undo and Put > > - Thinking it's because acme didn't receive the event, I send it with > winwriteevent from $PLAN9/lib/acme.rc but get "9p: write error: bad > event syntax". No error when using 9fans.net/go/acme, but still no > update on the tag > > Am I doing something wrong ? > -- Robert Kroeger rjkro...@liqui.org -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T08b139f442c68dca-Mc4bbcc6bf08001a870632574 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] An interesting article on the challenges chip designers face against secure startup
On Fri, Mar 28, 2025 at 07:04:05AM -0700, ron minnich wrote: > search for: keysight rp2350 hardware attacks > > (I'm done including links :-) > > Short form: it's getting easier by the day to put together glitching > hardware, for under $1000, and uncover those keys! [From the PR departement] This demonstrates once more: - That security relies first on simplicity (despite the conclusion, there is a mention about software too, i.e. compilers: "Due to an unlucky arrangement of instructions emitted by the compiler, injecting a fault which skips one out of two very specific instructions confuses the chip into rebooting to the hazardous boot type".); - That security has a cost and to maintain efficiency, strong security has to be done only once, and that it would be more secure for a task, verified, to execute once on a dedicated core than having to verify it at each running slot of time, having verified too that it had not been altered while sleeping and that the context on the core or the caches have not been "polluted" by a concurrent task. On the obvious side---it will probably not be a scoop to a lot of people---, I discovered, while working on the driver for the RTL 8125 and al. NICs, that there are instructions to allow to turn off the blinking led showing that there are network exchanges... All in all, trusting something that one doesn't build entirely (from hardware to software)---it may exhibit then errors but from involuntary faults---is, at best, naivety. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-M484bb3312349d42903435fed Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Acme event file and keyboard
Sorry I wasn't really clear, I'm talking about, in your example,
`acme/29/event`. acme(4) explains I can also receive keyboard events and I do,
I can get the characters I enter, but sending them back in has the behaviour I
explained. I'm using `wineventloop` from acme.rc, and my event function is
trivial:
```
fn event {
winwritevent $*
}
newwindow
wineventloop
```
As I said I don't have errors when using the go API, only with the acme.rc one.
I don't have anything special in +Errors
--
Matthieu
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T08b139f442c68dca-M336f69c7e238c2194c8283b1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Host security using TPMs
Aleksandar Kuktin writes: > I'd like to point out the problem with TPM is that, since the "trust" > chain originates with the manufacturer, or more accurately with > whomever controls the manufacturer, you'll never be in complete control > of the device. "Trusted computing" in this scenario means "can THEY > trust YOUR computer to serve THEM and work against YOU"? If you can't > change the key (all of them), or if you don't have the private key > (all of them), you simply don't have control over the boot process [...] There's no such thing as perfect security. Each of us individually decides what level of security is sufficient for our needs. For the purposes of running my Plan 9 network at home, if I could do host authentication using TPM, that would be sufficiently secure for my needs, and a *hell* of a lot more secure than the current scheme. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4aedea377a3d63c1-Mdb1e33d6715468d3f1891a45 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] An interesting article on the challenges chip designers face against secure startup
On Fri, Mar 28, 2025 at 09:20:44AM -0700, ron minnich wrote: > The relevance to plan 9: we have this thing we've used for about 30y now, > known to many of us as sdE0/nvram. > > IIUC, on the pre-x86 hardware, it really was a bit of NVRAM, the idea > being you had some bit of NVRAM on your system, hard to get to, which was a > good place to stash a key. > > X86 has always had the battery-backed CMOS memory, and it's always been too > small to hold anything useful, certainly not big enough for NVRAM, so I > always assumed that is why we ended up with sdE0/nvram. [Although, note, on > the LANL supercomputers, we did use a few bytes of CMOS to remember a > node's location on the source-routed Myrinet: not totally useless :-)] > > Creating a 512B partition on persistent storage to hold a secret key is, I > guess, what you do when you are on systems without a decent place to put > it. It never struck me as safe. > > I figure that at some point somebody is going to come in and show us a > better way to do it. Should that happen, it's good to be aware of just how > real the threats are. So I thought it would be nice to know, and possibly > interesting as well. My point, that was not clear I admit, is that I think that more than 90% of the threats come from the manufacturers and the vendors of the devices or the software, so that focusing on reducing the 10% left to 0.0001% or less is forgetting that this leaves the 90% intact. In the same order of ideas, I believe that present cryptography is indeed hard to break digitally but I'm convinced that it can be broken analogically---so that everybody uses digital cryptography that _almost_ nobody can break, but that one or two entities can and that they would be embarrassed if different not digital means were used. As long as somebody has physical access to the device (I guess this was the case for tampering with voltage)... One has to know exactly who has access. As long as the physical access is under control (for both the human beings and the material they bring with them), is there really a problem? The problem seems more the hype around a "100% trustworthy device" for RPI. > > > On Fri, Mar 28, 2025 at 8:06?AM wrote: > > > On Fri, Mar 28, 2025 at 07:04:05AM -0700, ron minnich wrote: > > > search for: keysight rp2350 hardware attacks > > > > > > (I'm done including links :-) > > > > > > Short form: it's getting easier by the day to put together glitching > > > hardware, for under $1000, and uncover those keys! > > > > [From the PR departement] This demonstrates once more: > > - That security relies first on simplicity (despite the > > conclusion, there is a mention about software too, i.e. compilers: > > "Due to an unlucky arrangement of instructions emitted by the > > compiler, injecting a fault which skips one out of two very specific > > instructions confuses the chip into rebooting to the hazardous boot > > type".); > > - That security has a cost and to maintain efficiency, > > strong security has to be done only once, and that it would > > be more secure for a task, verified, to execute once on a dedicated > > core than having to verify it at each running slot of time, having > > verified too that it had not been altered while sleeping and that the > > context on the core or the caches have not been "polluted" by a > > concurrent task. > > > > On the obvious side---it will probably not be a scoop to a lot of > > people---, I discovered, while working on the driver for the > > RTL 8125 and al. NICs, that there are instructions to allow > > to turn off the blinking led showing that there are network exchanges... > > > > All in all, trusting something that one doesn't build entirely (from > > hardware to software)---it may exhibit then errors but from involuntary > > faults---is, at best, naivety. > > -- > > Thierry Laronde > > http://www.kergis.com/ > > http://kertex.kergis.com/ > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-Mc15ac56eb1ee48d971b9e158 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] ftpd on 9front
OK, so I am running ftpd on 9front, but on connecting I get: Connected to 192.168.1.108. 220 Plan 9 FTP server ready. 200 UTF8 always on User (192.168.1.108:(none)): glenda 331 Need password Password: 534 Command requires tls Login failed. Any ideas of how to get this work? I am indifferent to whether I either get TLS working or disable it, but I suppose getting TLS working is at least a learning experience. Any help much appreciated. Garry -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td09db527ec1fde98-M416e6cc6e776d58a76102b9c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9Front on Intel N100?
It's using the rtl8169 driver, but I'm not sure how to get the exact chipset model, and Googling and Copiloting isn't helping. If you know the command to run in 9front to get the info you need, let me know I'll run it. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T25f54f1e44602c84-M437b494db7f0f9b7b2d69037 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9Front on Intel N100?
Thanks for the tip! > I got a fanless mini PC with N100, Plan 9 installed no problem and > recognised the network right away. What model NIC? I'm typing this from a N100 mini PC (running OpenBSD). dmesg(8) reports the 2 network interfaces as: "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400) which I'm hoping should be supported based on my very non-expert reading of /sys/src/9/pc/ether8169.c -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T25f54f1e44602c84-Me815b43805fa5e71bc6e2fb0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] An interesting article on the challenges chip designers face against secure startup
Most current asymmetric cryptography (public key) is vulnerable to various forms of attacks from quantum computers of a threshold size, not yet achieved but potentially feasible to see happen in the not-too-distant future. Symmetric ciphers (ex. AES, twofish) are generally more resistant. As to knowing who as physical access, that goes out the window if your laptop or cell phone gets stolen. Secure boot / encryption is more about protecting devices to the greatest extent possible when you lose physical control over them. On 3/28/25 14:06, tlaro...@kergis.com wrote: On Fri, Mar 28, 2025 at 09:20:44AM -0700, ron minnich wrote: The relevance to plan 9: we have this thing we've used for about 30y now, known to many of us as sdE0/nvram. IIUC, on the pre-x86 hardware, it really was a bit of NVRAM, the idea being you had some bit of NVRAM on your system, hard to get to, which was a good place to stash a key. X86 has always had the battery-backed CMOS memory, and it's always been too small to hold anything useful, certainly not big enough for NVRAM, so I always assumed that is why we ended up with sdE0/nvram. [Although, note, on the LANL supercomputers, we did use a few bytes of CMOS to remember a node's location on the source-routed Myrinet: not totally useless :-)] Creating a 512B partition on persistent storage to hold a secret key is, I guess, what you do when you are on systems without a decent place to put it. It never struck me as safe. I figure that at some point somebody is going to come in and show us a better way to do it. Should that happen, it's good to be aware of just how real the threats are. So I thought it would be nice to know, and possibly interesting as well. My point, that was not clear I admit, is that I think that more than 90% of the threats come from the manufacturers and the vendors of the devices or the software, so that focusing on reducing the 10% left to 0.0001% or less is forgetting that this leaves the 90% intact. In the same order of ideas, I believe that present cryptography is indeed hard to break digitally but I'm convinced that it can be broken analogically---so that everybody uses digital cryptography that _almost_ nobody can break, but that one or two entities can and that they would be embarrassed if different not digital means were used. As long as somebody has physical access to the device (I guess this was the case for tampering with voltage)... One has to know exactly who has access. As long as the physical access is under control (for both the human beings and the material they bring with them), is there really a problem? The problem seems more the hype around a "100% trustworthy device" for RPI. On Fri, Mar 28, 2025 at 8:06?AM wrote: On Fri, Mar 28, 2025 at 07:04:05AM -0700, ron minnich wrote: search for: keysight rp2350 hardware attacks (I'm done including links :-) Short form: it's getting easier by the day to put together glitching hardware, for under $1000, and uncover those keys! [From the PR departement] This demonstrates once more: - That security relies first on simplicity (despite the conclusion, there is a mention about software too, i.e. compilers: "Due to an unlucky arrangement of instructions emitted by the compiler, injecting a fault which skips one out of two very specific instructions confuses the chip into rebooting to the hazardous boot type".); - That security has a cost and to maintain efficiency, strong security has to be done only once, and that it would be more secure for a task, verified, to execute once on a dedicated core than having to verify it at each running slot of time, having verified too that it had not been altered while sleeping and that the context on the core or the caches have not been "polluted" by a concurrent task. On the obvious side---it will probably not be a scoop to a lot of people---, I discovered, while working on the driver for the RTL 8125 and al. NICs, that there are instructions to allow to turn off the blinking led showing that there are network exchanges... All in all, trusting something that one doesn't build entirely (from hardware to software)---it may exhibit then errors but from involuntary faults---is, at best, naivety. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-M8c4b99bd55d8720b5e5e56b1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Nix/9legacy: added NSEC syscall
In order to be as compatible as possible with current userland, and to facilitate diff'ing, I have added the NSEC syscall to Nix and put the Nix added syscalls after so that there are only additions when comparing. Todget() has been updated from the 9k version as well and, since the signature has changed, adaptation have been made to the calls in the Nix code but without adopting brutally new versions of touched sources since there may be added code specific to Nix. I have thus seen that monotonic time has been implemented in 9k (and is thus available with Nix too) with the new version of port/tod.c:todget() It compiles. If something is broken, you know who to blame, but have also a hint about where to look for :-^ -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbb689d7c28ef21eb-M2a9b449d23862af934114f20 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] An interesting article on the challenges chip designers face against secure startup
>On Fri, 28 Mar 2025 12:26:37 -0700 >"Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: > > ron minnich writes: > > > I figure that at some point somebody is going to come in and show > > us a better way to do it. Should that happen, it's good to be aware > > of just how real the threats are. So I thought it would be nice to > > know, and possibly interesting as well. > > Perhaps it's time to integrate TPM? That's been in the back of > my mind for a long time, but I have never had suitable hardware > to trying monkeying around with it. (That might change soon.) > > --lyndon Hi all! A long-time lurker here. I'd like to point out the problem with TPM is that, since the "trust" chain originates with the manufacturer, or more accurately with whomever controls the manufacturer, you'll never be in complete control of the device. "Trusted computing" in this scenario means "can THEY trust YOUR computer to serve THEM and work against YOU"? If you can't change the key (all of them), or if you don't have the private key (all of them), you simply don't have control over the boot process, and if you don't have control over the boot process, you simply have no control over the machine whatsoever. The machine can and will turn against you when it's true masters order it to. Then there's the entire thing about "war against general computing". Etc. This all is generally discussed under the heading "technofeudalism". -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. -- signature.asc Description: PGP signature -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-Mf2d73ed41ad414db5c2616ad Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] An interesting article on the challenges chip designers face against secure startup
The relevance to plan 9: we have this thing we've used for about 30y now, known to many of us as sdE0/nvram. IIUC, on the pre-x86 hardware, it really was a bit of NVRAM, the idea being you had some bit of NVRAM on your system, hard to get to, which was a good place to stash a key. X86 has always had the battery-backed CMOS memory, and it's always been too small to hold anything useful, certainly not big enough for NVRAM, so I always assumed that is why we ended up with sdE0/nvram. [Although, note, on the LANL supercomputers, we did use a few bytes of CMOS to remember a node's location on the source-routed Myrinet: not totally useless :-)] Creating a 512B partition on persistent storage to hold a secret key is, I guess, what you do when you are on systems without a decent place to put it. It never struck me as safe. I figure that at some point somebody is going to come in and show us a better way to do it. Should that happen, it's good to be aware of just how real the threats are. So I thought it would be nice to know, and possibly interesting as well. On Fri, Mar 28, 2025 at 8:06 AM wrote: > On Fri, Mar 28, 2025 at 07:04:05AM -0700, ron minnich wrote: > > search for: keysight rp2350 hardware attacks > > > > (I'm done including links :-) > > > > Short form: it's getting easier by the day to put together glitching > > hardware, for under $1000, and uncover those keys! > > [From the PR departement] This demonstrates once more: > - That security relies first on simplicity (despite the > conclusion, there is a mention about software too, i.e. compilers: > "Due to an unlucky arrangement of instructions emitted by the > compiler, injecting a fault which skips one out of two very specific > instructions confuses the chip into rebooting to the hazardous boot > type".); > - That security has a cost and to maintain efficiency, > strong security has to be done only once, and that it would > be more secure for a task, verified, to execute once on a dedicated > core than having to verify it at each running slot of time, having > verified too that it had not been altered while sleeping and that the > context on the core or the caches have not been "polluted" by a > concurrent task. > > On the obvious side---it will probably not be a scoop to a lot of > people---, I discovered, while working on the driver for the > RTL 8125 and al. NICs, that there are instructions to allow > to turn off the blinking led showing that there are network exchanges... > > All in all, trusting something that one doesn't build entirely (from > hardware to software)---it may exhibit then errors but from involuntary > faults---is, at best, naivety. > -- > Thierry Laronde > http://www.kergis.com/ > http://kertex.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-M023cc872fbda4674c9b7178f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] NIX this morning
On Thu, Mar 27, 2025 at 07:47:02AM -0700, ron minnich wrote: > Off to my day job :-) Ron, I've heard rumors (perhaps apocryphal) that there exists a state of being where there is no "day job" and you can spend all your time on things that are more intellectually satisfying than any suit could ever appreciate. I think they call it "retirement." Of course, that may be as mythical as "vacation." But I've got a basement full of unstarted and half-finished projects that are calling out for me find a path to this nirvana. BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T10229a3f9069de91-M025e341cd6009ff6e343eee1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] An interesting article on the challenges chip designers face against secure startup
search for: keysight rp2350 hardware attacks (I'm done including links :-) Short form: it's getting easier by the day to put together glitching hardware, for under $1000, and uncover those keys! -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-M2cd0d36e0a6b03ca1c3b15a8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] An interesting article on the challenges chip designers face against secure startup
Isn't that what the TPM is supposed to provide in a verifiable way? Arm's TrustZone presumably provides layered-isolation to keys and signatures that can be verified all the way to the manufacturer. I'm guessing they might be the basis for TPM hardware implementation. On Fri, Mar 28, 2025 at 9:56 AM ron minnich wrote: > > The relevance to plan 9: we have this thing we've used for about 30y now, > known to many of us as sdE0/nvram. > > IIUC, on the pre-x86 hardware, it really was a bit of NVRAM, the idea being > you had some bit of NVRAM on your system, hard to get to, which was a good > place to stash a key. > > X86 has always had the battery-backed CMOS memory, and it's always been too > small to hold anything useful, certainly not big enough for NVRAM, so I > always assumed that is why we ended up with sdE0/nvram. [Although, note, on > the LANL supercomputers, we did use a few bytes of CMOS to remember a node's > location on the source-routed Myrinet: not totally useless :-)] > > Creating a 512B partition on persistent storage to hold a secret key is, I > guess, what you do when you are on systems without a decent place to put it. > It never struck me as safe. > > I figure that at some point somebody is going to come in and show us a better > way to do it. Should that happen, it's good to be aware of just how real the > threats are. So I thought it would be nice to know, and possibly interesting > as well. > > > On Fri, Mar 28, 2025 at 8:06 AM wrote: >> >> On Fri, Mar 28, 2025 at 07:04:05AM -0700, ron minnich wrote: >> > search for: keysight rp2350 hardware attacks >> > >> > (I'm done including links :-) >> > >> > Short form: it's getting easier by the day to put together glitching >> > hardware, for under $1000, and uncover those keys! >> >> [From the PR departement] This demonstrates once more: >> - That security relies first on simplicity (despite the >> conclusion, there is a mention about software too, i.e. compilers: >> "Due to an unlucky arrangement of instructions emitted by the >> compiler, injecting a fault which skips one out of two very specific >> instructions confuses the chip into rebooting to the hazardous boot >> type".); >> - That security has a cost and to maintain efficiency, >> strong security has to be done only once, and that it would >> be more secure for a task, verified, to execute once on a dedicated >> core than having to verify it at each running slot of time, having >> verified too that it had not been altered while sleeping and that the >> context on the core or the caches have not been "polluted" by a >> concurrent task. >> >> On the obvious side---it will probably not be a scoop to a lot of >> people---, I discovered, while working on the driver for the >> RTL 8125 and al. NICs, that there are instructions to allow >> to turn off the blinking led showing that there are network exchanges... >> >> All in all, trusting something that one doesn't build entirely (from >> hardware to software)---it may exhibit then errors but from involuntary >> faults---is, at best, naivety. >> -- >> Thierry Laronde >> http://www.kergis.com/ >> http://kertex.kergis.com/ >> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > > 9fans / 9fans / see discussions + participants + delivery options Permalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-Mfcf4c51e9b2d7efd1db76cf8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
