OpenMoko (Was: Re: Hardware Random Number Generators (RNG))
On Thu, 9 Jul 2020, Theo de Raadt wrote:
static const struct urng_type urng_devs[] = {
{ { USB_VENDOR_OPENMOKO2, USB_PRODUCT_OPENMOKO2_CHAOSKEY },
{64, 5, 0, 100, 5000} },
Interesting. That's what became of OpenMoko... a pool of DevIDs
for small device builders?
m
Re: Hardware Random Number Generators (RNG)
Daniel Jakots wrote:
> On Thu, 09 Jul 2020 16:35:13 -0600, "Theo de Raadt"
> wrote:
>
> > > PS I think the USB devices are probably a pretty good source of
> > > true entropy.
> >
> > Why do I bother explaining? I'm the maintainer of the openbsd
> > kernel's randomness code. I say I don't see the point in 1 line of
> > code to support these devices.
>
> But don't we have urng(4)?
static const struct urng_type urng_devs[] = {
{ { USB_VENDOR_OPENMOKO2, USB_PRODUCT_OPENMOKO2_CHAOSKEY },
{64, 5, 0, 100, 5000} },
{ { USB_VENDOR_ARANEUS, USB_PRODUCT_ARANEUS_ALEA },
{128, 1, 0, 100, 5000} },
Trivial.
> Or is there some subtlety between the cards it supports and OP's card I'm
> missing?
That card is garbage.
Re: Hardware Random Number Generators (RNG)
--- Theo de Raadt wrote: > And I went out of my way to politely explain it to you I would like a more detailed explanation, because I don't yet understand. That's why I asked for literature I could read. Thanks, Ken CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
ansible hostname.if role
Hello everybody, introducing this little ansible role to configure hostname.if(5) files. comments are welcome https://github.com/gred7/ansible-openbsd-interfaces-role.git
Re: Hardware Random Number Generators (RNG)
--- Theo de Raadt wrote: > And I don't give a rats ass about a cheap-ass garbage usb device > that can't even afford to allocate a proper usb device ID. > I don't care. I get that you think I'm wrong (and maybe I am!) but I don't yet understand why. Can you point me to some literature on the topic? Thanks, Ken PS I think the USB devices are probably a pretty good source of true entropy. CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
Re: Hardware Random Number Generators (RNG)
I wrote: >> How do I use a hardware random number generator to >> continuously seed /dev/random with new truly random numbers? --- Theo de Raadt wrote: > We consider these devices boring, because the kernel does a good enough job > creating random. > randomness only has a bootstrap problem. And these devices don't solve the > bootstrap problem. I'm thinking of headless servers, where randomness can ONLY come from the network. There is no keyboard, no mouse, etc. I'm also thinking of first boot after install, when keys are generated. I think that is what you mean by the bootstrap problem. Thanks, Ken PS I'm also thinking of very old hardware, without RDRAND in the CPU. Not to mention that you can't necessarily trust RDRAND! CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
Hardware Random Number Generators (RNG)
I have a few TrueRNG hardware random number generators. They are USB devices, and generally appear as modems. How do I use them to continuously seed /dev/random with new truly random numbers? It's got to be something very simple like tail -f /dev/TrueRNG > /dev/random or something like that. Right? Thanks, Ken CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
Re: Unbound Problems (Reverse Direction)
I appreciate your help! Either you solved the previous problem telling me to put $ORIGIN in my BIND zone files, or I had made a mistake with the 'set port=number' command in nslookup. In either case NSD is now working properly in both directions. But Unbound is only working correctly in the forward direction. I'm still doing something wrong, and I don't know what yet. Thanks, Ken CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
Re: Hardware Random Number Generators (RNG)
On Thu, 09 Jul 2020 16:35:13 -0600, "Theo de Raadt" wrote: > > PS I think the USB devices are probably a pretty good source of > > true entropy. > > Why do I bother explaining? I'm the maintainer of the openbsd > kernel's randomness code. I say I don't see the point in 1 line of > code to support these devices. But don't we have urng(4)? Or is there some subtlety between the cards it supports and OP's card I'm missing?
Re: Hardware Random Number Generators (RNG)
wrote: > --- Theo de Raadt wrote: > > And I went out of my way to politely explain it to you > > I would like a more detailed explanation, because I don't yet understand. > > That's why I asked for literature I could read. We publish our source tree, which contains the complete random number generation subsystem. Upon studying it, the major thing you'll notice is entropy is fully available *IN THE BOOT CODE* already, and thus *EVEN IN THE INSTALLER*, and it is passed onwards, so at most a random device can add entropy to a pool which is *already good enough*. That's the design. Since that is the design, what's the point of writing a crappy driver for a crappy device? No point.
Re: Hardware Random Number Generators (RNG)
wrote: > --- Theo de Raadt wrote: > > And I don't give a rats ass about a cheap-ass garbage usb device > > that can't even afford to allocate a proper usb device ID. > > I don't care. > > I get that you think I'm wrong (and maybe I am!) > but I don't yet understand why. We are not going to write code for these devices which claim to be serial ports. End of story. > Can you point me to some literature on the topic? Our source tree is publically available. > PS I think the USB devices are probably a pretty good source of true entropy. Why do I bother explaining? I'm the maintainer of the openbsd kernel's randomness code. I say I don't see the point in 1 line of code to support these devices. And I went out of my way to politely explain it to you, but you want to argue. Do you not understand that my points end the conversation? I hope you get over it.
Re: Hardware Random Number Generators (RNG)
wrote: > I wrote: > >> How do I use a hardware random number generator to > >> continuously seed /dev/random with new truly random numbers? > > --- Theo de Raadt wrote: > > We consider these devices boring, because the kernel does a good enough job > > creating random. > > randomness only has a bootstrap problem. And these devices don't solve the > > bootstrap problem. > > I'm thinking of headless servers, where randomness can ONLY come > from the network. There is no keyboard, no mouse, etc. Incorrect. > I'm also thinking of first boot after install, when keys are generated. Incorrect. We have ways. > I think that is what you mean by the bootstrap problem. Sorry, we want randomness before usb is working. > PS I'm also thinking of very old hardware, without RDRAND in the CPU. > Not to mention that you can't necessarily trust RDRAND! I'm not thinking of machines with or without rdrand. And I don't give a rats ass about a cheap-ass garbage usb device that can't even afford to allocate a proper usb device ID. I don't care.
Re: Hardware Random Number Generators (RNG)
We consider these devices boring, because the kernel does a good enough job creating random. randomness only has a bootstrap problem. And these devices don't solve the bootstrap problem. wrote: > I have a few TrueRNG hardware random number generators. > They are USB devices, and generally appear as modems. > > How do I use them to continuously seed /dev/random with new truly random > numbers? > It's got to be something very simple like > tail -f /dev/TrueRNG > /dev/random > or something like that. Right? > > Thanks, > Ken > > > > > > CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use > of the intended recipient and may contain material that is proprietary, > confidential, privileged or otherwise legally protected or restricted under > applicable government laws. Any review, disclosure, distributing or other use > without expressed permission of the sender is strictly prohibited. If you are > not the intended recipient, please contact the sender and delete all copies > without reading, printing, or saving. >
Unbound Problems (Reverse Direction)
Nope. I still don't have it working. NSD is working in both directions. Unbound is only working in the forward direction. Here is proof that both Unbound and NSD are working in the forward direction: 7 Soekris2# nslookup nas2 Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: Name: nas2.Foo.Bar Address: 172.24.10.2 Here is proof that NSD is working in the reverse direction: 8 Soekris2# nslookup > server 127.0.0.1 Default server: 127.0.0.1 Address: 127.0.0.1#53 > set port=53053 > 172.24.10.2 Server: 127.0.0.1 Address:127.0.0.1#53053 2.10.24.172.in-addr.arpaname = nas2.foo.bar. But somehow, Unbound is not working in the reverse direction: 6 Soekris2# nslookup 172.24.10.2 Server: 127.0.0.1 Address:127.0.0.1#53 ** server can't find 2.10.24.172.in-addr.arpa: NXDOMAIN Here is the relevant part of my unbound.conf: # Use nsd to resolve local names. # Do not send these queries to the root servers. stub-zone: name: Foo.Bar. stub-addr: 127.0.0.1@53053 stub-zone: name: 10.24.172.in-addr.arpa. stub-addr: 127.0.0.1@53053 stub-zone: name: 20.24.172.in-addr.arpa. stub-addr: 127.0.0.1@53053 stub-zone: name: 30.24.172.in-addr.arpa. stub-addr: 127.0.0.1@53053 stub-zone: name: 2.168.192.in-arpa.arpa. stub-addr: 127.0.0.1@53053 stub-zone: name: 224.in-addr.arpa. stub-addr: 127.0.0.1@53053 stub-zone: name: 255.in-addr.arpa. stub-addr: 127.0.0.1@53053 Any ideas? What am I still doing wrong?? NSD is listening on port 53053, and works (as proved above) for resolving in the reverse direction. Why doesn't unbound work? CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
Re: Unbound Problems (Reverse Direction)
please disregard this. as expected, if one mentions 'typo' it is inevitable that one will embarrass themselves profoundly. as it happens i read the config too quickly and entirely wrongly. On Thu, 9 Jul 2020 15:21:27 -0400, Amelia A Lewis wrote: > On Thu, 9 Jul 2020 17:44:48 +, ken.hendrick...@l3harris.com wrote: >> name: 2.168.192.in-arpa.arpa. > ^ > > It's a mystery, as well, why you would set up nsd (an authoritative > sever) if you're not delegating to it in the recursive/caching server. > But if you're gonna replicate the content in unbound.conf, don't typo > your network number. 9 != 7 > > Amy!
Re: Unbound Problems (Reverse Direction)
On Thu, 9 Jul 2020 17:44:48 +, ken.hendrick...@l3harris.com wrote: > name: 2.168.192.in-arpa.arpa. ^ It's a mystery, as well, why you would set up nsd (an authoritative sever) if you're not delegating to it in the recursive/caching server. But if you're gonna replicate the content in unbound.conf, don't typo your network number. 9 != 7 Amy!
Re: NSD Problems (Reverse Direction)
I asked: >> nsd works only in the forward direction: from a name to an IP address. >> I'm using my named zone files from way back. --- Amelia A Lewis wrote: > $ORIGIN > > You haven't got one. You have a comment saying what the origin is, > but no $ORIGIN directive in the example supplied. Adding the $ORIGIN directive solved the problem. Thank you, Ken CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi,
In my case replacing bootx64.efi with new one compiled with
aforementioned patch took off.
ODROID-H2 could boot kernel from latest snapshot.
Part of dmesg:
boot> boot bsd
booting hd0a:bsd: 14464328+3175440+344096+0+872448
[963989+128+1137408+860372]=0x14d15f0
entry point at 0x1001000
[ using 2962928 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 6.7-current (GENERIC.MP) #336: Tue Jul 7 22:27:36 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8385654784 (7997MB)
avail mem = 8116477952 (7740MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x79856000 (60 entries)
bios0: vendor American Megatrends Inc. version "5.13" date 04/27/2020
bios0: HARDKERNEL ODROID-H2
...
thanks Kastus
On 07.07.2020 20:55, Sven Wolf wrote:
Hi guys,
with the patch the kernel loads and doesn't stop at "entry point at
0x1001000". But the kernel stops with a "Stopped at
gfx_v9_0_wait_reg_mem+0x307: int $3"
So for my machine the patch is the right direction but not the
solution :( I've tried the boot with the current snapshot kernel.
Thanks and best regards,
Sven
On 7/6/20 6:32 AM, Kastus Shchuka wrote:
On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
Kastus Shchuka wrote:
“I installed 2020-07-03 snapshot on ASRock J4105M system and I am
not able to boot it.
Boot stops at the line
entry point at 0x1001000
If I try bsd.rd kernel, it boots just fine. After this failure with
snapshot I
installed 6.7-release, and it boots without any issues.”
I've experienced something similar, including the sensitivity to
kernel size. As best I can observe, the EFI bootloader is being
handed a different block of RAM than where the kernel is actually
loaded (which is at a fixed address defined in boot.c). Which block
of memory gets returned, and whether boot fails, seems to be
dependent on the particular UEFI ROM/chipset. In my case, debugging
over serial, I observe a page fault while the kernel is still being
loaded into RAM.
“Are there any other solutions than compiling a custom smaller kernel?”
Patching efiboot.c as follows and recompiling bootia32/bootx64
resolved it for me:
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -303,9 +303,9 @@ efi_memprobe(void)
bios_memmap_t *bm;
EFI_STATUS status;
EFI_PHYSICAL_ADDRESS
- addr = 0x1000ULL; /* Below 256MB */
+ addr = 0x100;
- status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
EfiLoaderData,
+ status = EFI_CALL(BS->AllocatePages, AllocateAddress,
EfiLoaderData,
EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
if (status != EFI_SUCCESS)
panic("BS->AllocatePages()");
Let me know if that helps. I can't guarantee that this is actually
what is causing your issue but it worked for me.
I tried this patch and was able to boot kernel from snapshot
2007-07-03 with recompiled BOOTX64.EFI.
It fixes the problem with EFI memory mapping on ASRock J4105M
motherboard.
I wonder what would it take for the patch to be accepted in -current?
Thanks,
Kastus
msyscall error during boot
Hello, I just upgraded one of my vmd virtual machine from OpenBSD 6.6 to 6.7 using sysupgrade and noticed a new msyscall error message I have never seen before during reboot as you can see below: ... preserving editor files. starting network daemons: sshd smtpd httpd. starting package daemons: dovecot postgresql php72_fpm netsnmpd. msyscall a35ee0ce000 a3000 error msyscall a35187dd000 a5000 error starting local daemons: cron. Thu Jul 9 08:07:15 CEST 2020 Any ideas where this could come from? and if it is bad? The VMD host itself also runs OpenBSD 6.7. Regards, Mabi
Installation in a Xen guest (pvgrub)
Hi, is there a possibility to install/boot OpenBSD in a Xen guest which is booted by pvgrub1 or pvgrub2? The pvgrub is configured to use a /boot/grub/grub.cfg of the guest in the 1st partition. In a non-Xen-grub there is a bsd-module which can boot the installer bsd.rd, but this bsd-module is not available in the xenhost-builds of grub. There is also no chain-module for chainloader configs. Any ideas? Thanks Markus
Re: SSL error wth dovecot + roundcube
On 2020-07-09, Matthew Weigel wrote: > On 7/8/20 7:57 PM, Aisha Tammy wrote: >> On dovecots side, I get: >> Jul 8 20:28:59 mail dovecot: imap-login: Disconnected (no auth attempts in >> 0 secs): user=<>, rip=98.109.25.191, lip=108.61.81.40, TLS handshaking: >> SSL_accept() >> failed: error:14037418:SSL routines:ACCEPT_SR_KEY_EXCH:tlsv1 alert unknown >> ca: SSL alert number 48, session= >> >> I think this might be some error with either ssl lib things in php or >> something similar. >> (An unlikelier scenario is that I have some errors with my dovecot imap ssl, >> but every other client, thunderbird/fairmail/k-9 mail are authenticating >> fine) > > I think it's actually a lot more likely, but you don't provide much > information about how you configured dovecot. > > The dovecot error is that it doesn't recognize the CA, which suggests The error logged is confusing at first look but what it means is that the client sent a tls alert message saying that it (the client) doesn't know the ca.
Re: SSL error wth dovecot + roundcube
On 2020-07-09, Aisha Tammy wrote: > OK I found the error, the error is definitely something on our side of the > port and not because of roundcube/dovecot > > When I turn peer verification off, roundcube is continues and establishes > connection. > I think that the reason for this is that roundcube needs to access the CA > cert files which are not inside the chroot /var/www/ > > I fixed the issue by copying the /etc/ssl/cert.pem file into the chroot > location and pointing the ca-cert config options to the proper place > > I really think this should be added to the README of the port. It's already in php's pkg-readme, which is the right place for it. On 2020-07-09, Daniel Jakots wrote: > On Wed, 8 Jul 2020 23:02:40 -0400, Aisha Tammy > wrote: > >> I can send a diff later but hopefully the maintainer can just add a >> small note? > > Then mailing the maintainer (with or without cc'ing ports@) will > increase your chance (vs just mailing misc@) ;) Yes!
Re: NSD Problems (Reverse Direction)
On 2020-07-09, Otto Moerbeek wrote: > On Thu, Jul 09, 2020 at 01:19:47AM +, ken.hendrick...@l3harris.com wrote: > >> > server 127.0.0.1 >> Default server: 127.0.0.1 >> Address: 127.0.0.1#53 >> > set port 53053 > ^ >> > 172.24.20.1 >> Server: 127.0.0.1 >> Address: 127.0.0.1#53 > ^^ > You're not asking the server you expect. > > Dunno why, never use it. Maybe has to do with the recent cleanup os > nslookup and friends. I prefer dig. It should be "set port=53053", not "set port 53053". But if this nsd+unbound setup is just to provide lookups for internal servers to clients of the unbound instance, it would be simpler to use unbound local-data statements.
Re: SSL error wth dovecot + roundcube
OK I found the error, the error is definitely something on our side of the port and not because of roundcube/dovecot When I turn peer verification off, roundcube is continues and establishes connection. I think that the reason for this is that roundcube needs to access the CA cert files which are not inside the chroot /var/www/ I fixed the issue by copying the /etc/ssl/cert.pem file into the chroot location and pointing the ca-cert config options to the proper place I really think this should be added to the README of the port. I can send a diff later but hopefully the maintainer can just add a small note? Aisha On 7/8/20 8:57 PM, Aisha Tammy wrote: > I'm trying to get roundcube setup on my server and everytime I try to connect > to dovecot, it gives a weird error on roundcubes side, in errors.log: > > [08-Jul-2020 21:34:18 +]: <6q9plqno> IMAP Error: Login failed for > ai...@aisha.cc against imap.aisha.cc from 10.7.0.1(X-Forwarded-For: > 98.109.25.191). Could > not connect to ssl://imap.aisha.cc:993: Unknown reason in > /roundcubemail/program/lib/Roundcube/rcube_imap.php on line 200 (POST > /?_task=login&_action=login) > > On the interface I get: > Connection to storage server failed > > On dovecots side, I get: > Jul 8 20:28:59 mail dovecot: imap-login: Disconnected (no auth attempts in 0 > secs): user=<>, rip=98.109.25.191, lip=108.61.81.40, TLS handshaking: > SSL_accept() > failed: error:14037418:SSL routines:ACCEPT_SR_KEY_EXCH:tlsv1 alert unknown > ca: SSL alert number 48, session= > > I think this might be some error with either ssl lib things in php or > something similar. > (An unlikelier scenario is that I have some errors with my dovecot imap ssl, > but every other client, thunderbird/fairmail/k-9 mail are authenticating fine) > > > Would love to get this fixed :( > > Thanks > Aisha >
