Re: strange SMTP interaction with mail.openbsd.org ?
On 08-09-2020 10:30, Claus Assmann wrote: On Mon, Sep 07, 2020, Leen Besselink wrote: So I just got confirmation, when CHUNKING is in the EHLO then it will do STARTTLS, but after a second EHLO it will notice the CHUNKING and just QUIT. Interesting... but unfortunately that's not the problem I am seeing - my server does not offer CHUNKING and the "drops" seem to be random (maybe some artifact of the scheduling in smtpd?) Seems you are right. I waited longer now and CHUNKING is not in the EHLO banner, but I do see QUiT again without sending any emails. So even though I had turned it off and on a couple of times, it was probably just a coincidence.
Re: Troubleshooting rsync
Just to add to the archives I set up another Window 10 laptop, set up WSL but this time used OpenSUSE and rsync works fine. On Sun, Sep 6, 2020 at 5:32 AM Todd C. Miller wrote: > On Fri, 04 Sep 2020 22:57:03 -0700, Greg Thomas wrote: > > > Hey all, I'm trying to use WSL on Windows 10 to backup to my OpenBSD > server > > running 6.7 release. It looks like Debian on WSL is using rsync version > > 3.1.2. I tried both the rsync package and openrsync on OpenBSD with the > > same results.Basically rsync never exits and when I use four Vs for > > verbosity the last line is 'client_run waiting on..." rsync locally > works > > fine. > > Are you using WSL 1 or WSL 2? If possible, I'd suggest testing with WSL 2. > You can convert between WSL 1 and 2 pretty easily. > > - todd >
[ports] Bug in Alpine TLS patch applied in 6.7 (ports/mail/alpine)
Hi, I had a problem that with Thunderbird / mobile clients accessing alpine-based imapd server (imap-uw) over SSL/TLS, eventually the imapd server process goes into busy-loop consuming all possible CPU time. After a while the server was crawling with some tens or hundreds of busy-looping imapd processes. I found out that this is caused by the TLS patch that was added in 6.7 with header "Add workarounds to fix alpine with TLSv1.3". Involving following patch: patch-imap_src_osdep_unix_ssl_unix_c Removing this patch makes the problem go away. So I have to conclude there's a problem in this patch. I suspect it may be related to connection termination time. But I don't know enough about this TLS implementation and API to know how to fix this. Best regards, - Jussi
Re: VMM vulns?
So, if I'm reading this all correctly it looks like _most_ of the issues have been addressed. Seems these are left: - The TLB handling of guest pages is broken, in that the INVEPT instructions in the host could be issued on the wrong CPUs. This means that if UVM decides to swap out a guest page, the guest could still access it via stale TLB entries. On AMD CPUs, there is no TLB handling at all (??). - vmx_load_pdptes is broken. And for the suggestions: - Fix TLB handling - Provide *real* ASLR: randomize the PTE space and the direct map. Does that seem correct? Sent: Thursday, September 10, 2020 at 9:41 AM From: "Demi M. Obenour" To: misc@openbsd.org Subject: Re: VMM vulns? On 2020-09-03 01:09, Mike Larkin wrote: > On Wed, Sep 02, 2020 at 09:36:14PM -0400, Bryan Steele wrote: >> On Wed, Sep 02, 2020 at 02:03:35AM -0700, Mike Larkin wrote: >>> On Wed, Sep 02, 2020 at 03:35:54AM +0200, f...@disciples.com wrote: https://twitter.com/m00nbsd/status/1291257985734410244 I don't want to bump that old thread or start any arguments about this. I'm just curious if this tweet is accurate or have these issues been addressed? Were any of Maxime's suggestions implemented? >>> >>> I am not sure if anyone picked up the remaining issues after I left active >>> vmm development. At that time, I sent out my WIP diff for the TLB flush >>> issue >>> Maxime reported; it was not 100% complete. I am not sure if anyone is >>> working >>> on that or not, or any other issues he reported. >>> >>> -ml >> >> As far as I'm aware all the pvclock(4) issues were addressed by pd@ and >> mortimer@. >> >> https://marc.info/?l=openbsd-cvs&m=158180761313544&w=2[https://marc.info/?l=openbsd-cvs&m=158180761313544&w=2] >> https://marc.info/?l=openbsd-cvs&m=158269876318391&w=2[https://marc.info/?l=openbsd-cvs&m=158269876318391&w=2] >> >> The "assorted bugs and vulns" like the RDMSR passthrough and the XSETBV >> CPL check issues were handled by pd@, me and kettenis@ and they have all >> been committed. >> >> https://marc.info/?l=openbsd-cvs&m=158196338821895&w=2[https://marc.info/?l=openbsd-cvs&m=158196338821895&w=2] >> >> The direct map issue on Intel CPUs hinted at by Maxime was also fixed >> by kettenis@, deraadt@ and millert@. >> >> https://marc.info/?l=openbsd-cvs&m=158269724517998&w=2[https://marc.info/?l=openbsd-cvs&m=158269724517998&w=2] >> >> -Bryan. >> > > The TLB flush issues are still outstanding. > > -ml Yikes! Is https://openbsd.amsterdam[https://openbsd.amsterdam] affected? -Demi
Re: VMM vulns?
Demi M. Obenour [demioben...@gmail.com] wrote: > > Yikes! Is https://openbsd.amsterdam affected? > Unless they have a special version of vmm with bugfixes that don't exist anywhere else, then yes, of course.
Re: VMM vulns?
On 2020-09-03 01:09, Mike Larkin wrote: > On Wed, Sep 02, 2020 at 09:36:14PM -0400, Bryan Steele wrote: >> On Wed, Sep 02, 2020 at 02:03:35AM -0700, Mike Larkin wrote: >>> On Wed, Sep 02, 2020 at 03:35:54AM +0200, f...@disciples.com wrote: https://twitter.com/m00nbsd/status/1291257985734410244 I don't want to bump that old thread or start any arguments about this. I'm just curious if this tweet is accurate or have these issues been addressed? Were any of Maxime's suggestions implemented? >>> >>> I am not sure if anyone picked up the remaining issues after I left active >>> vmm development. At that time, I sent out my WIP diff for the TLB flush >>> issue >>> Maxime reported; it was not 100% complete. I am not sure if anyone is >>> working >>> on that or not, or any other issues he reported. >>> >>> -ml >> >> As far as I'm aware all the pvclock(4) issues were addressed by pd@ and >> mortimer@. >> >> https://marc.info/?l=openbsd-cvs&m=158180761313544&w=2 >> https://marc.info/?l=openbsd-cvs&m=158269876318391&w=2 >> >> The "assorted bugs and vulns" like the RDMSR passthrough and the XSETBV >> CPL check issues were handled by pd@, me and kettenis@ and they have all >> been committed. >> >> https://marc.info/?l=openbsd-cvs&m=158196338821895&w=2 >> >> The direct map issue on Intel CPUs hinted at by Maxime was also fixed >> by kettenis@, deraadt@ and millert@. >> >> https://marc.info/?l=openbsd-cvs&m=158269724517998&w=2 >> >> -Bryan. >> > > The TLB flush issues are still outstanding. > > -ml Yikes! Is https://openbsd.amsterdam affected? -Demi signature.asc Description: OpenPGP digital signature
Re: Assigning the same IP address to multiple interfaces
> On Sep 10, 2020, at 11:16 AM, Demi M. Obenour wrote: > > How do I assign the same IP and MAC address to multiple interfaces? > This is easy on Linux, but I cannot figure out how to do it on > OpenBSD. The (virtual) machine is assigned a single IP address by > the hypervisor, so changing the IP not an option, and bridging is > a no-go as all the peers share a MAC address. All netmasks are /32 > for IPv4 and /128 for IPv6. > > Each of the interfaces is a point-to-point Ethernet link, and both > its IP and MAC address and that of its peer are statically known. > All routes are also assigned statically. In short, I need to assign > a route based purely on the name of an interface. > > The -ifp keyword in route(8) seems like it should be used for this, > and the kernel sources indicate that it can be used to disambiguate > which interface should be selected. However, I was not able to get > it to work. I don’t have access to the VM I was using for testing > anymore, but if I recall correctly, the C code and shell scripts I > was using did the equivalent of the following: > > # ifconfig xnf0 inet 10.137.0.77 prefixlen 32 > # route -n delete 10.137.0.77/32 10.137.0.77 > # # this doesn’t work due to a route(8) bug ― I was using C code instead > # # I submitted a bug report (with patch) to bugs@ a while back > # route -n add -inet 10.137.255.254 -link fe:ff:ff:ff:ff:ff -ifp xnf0 -ifa > 10.137.0.77 > # ifconfig vether0 create lladdr fe:ff:ff:ff:ff:ff > # ifconfig vether0 inet 10.137.0.77 prefixlen 32 > # # this doesn’t work due to a route(8) bug ― I was using C code instead > # route -n add -inet 10.139.255.254 -link fe:ff:ff:ff:ff:ff -ifp vether0 -ifa > 10.137.0.77 > # route -n delete 10.137.0.77/32 10.137.0.77 > $ route -n show > > I expect that the route would to 10.139.255.254 would go through > vether0, but it goes through xnf0 instead. If I then run: > > # ifconfig xnf0 -inet > $ route -n show > > the route is gone. > > Should the above commands have worked? If not, is this just > unsupported in OpenBSD? If it is supported, what should I have done > differently? I did manage to create a workaround: I can assign each > interface a unique alias address from the 169.254.0.0/16 link-local > range, and use PF to NAT packets in this range to 10.137.0.77. > However, this feels like an ugly hack. > > For IPv6, I can use the link-local address of each interface as the > -ifa argument, so I am much less worried. > > Thank you for your time and attention. > > Sincerely, > > Demi M. Obenour > I’m confused by what you want to do, but maybe routing domains (route tables) can help solve your problem? Check out the keyword rdomain in ifconfig man page.
Assigning the same IP address to multiple interfaces
How do I assign the same IP and MAC address to multiple interfaces? This is easy on Linux, but I cannot figure out how to do it on OpenBSD. The (virtual) machine is assigned a single IP address by the hypervisor, so changing the IP not an option, and bridging is a no-go as all the peers share a MAC address. All netmasks are /32 for IPv4 and /128 for IPv6. Each of the interfaces is a point-to-point Ethernet link, and both its IP and MAC address and that of its peer are statically known. All routes are also assigned statically. In short, I need to assign a route based purely on the name of an interface. The -ifp keyword in route(8) seems like it should be used for this, and the kernel sources indicate that it can be used to disambiguate which interface should be selected. However, I was not able to get it to work. I don’t have access to the VM I was using for testing anymore, but if I recall correctly, the C code and shell scripts I was using did the equivalent of the following: # ifconfig xnf0 inet 10.137.0.77 prefixlen 32 # route -n delete 10.137.0.77/32 10.137.0.77 # # this doesn’t work due to a route(8) bug ― I was using C code instead # # I submitted a bug report (with patch) to bugs@ a while back # route -n add -inet 10.137.255.254 -link fe:ff:ff:ff:ff:ff -ifp xnf0 -ifa 10.137.0.77 # ifconfig vether0 create lladdr fe:ff:ff:ff:ff:ff # ifconfig vether0 inet 10.137.0.77 prefixlen 32 # # this doesn’t work due to a route(8) bug ― I was using C code instead # route -n add -inet 10.139.255.254 -link fe:ff:ff:ff:ff:ff -ifp vether0 -ifa 10.137.0.77 # route -n delete 10.137.0.77/32 10.137.0.77 $ route -n show I expect that the route would to 10.139.255.254 would go through vether0, but it goes through xnf0 instead. If I then run: # ifconfig xnf0 -inet $ route -n show the route is gone. Should the above commands have worked? If not, is this just unsupported in OpenBSD? If it is supported, what should I have done differently? I did manage to create a workaround: I can assign each interface a unique alias address from the 169.254.0.0/16 link-local range, and use PF to NAT packets in this range to 10.137.0.77. However, this feels like an ugly hack. For IPv6, I can use the link-local address of each interface as the -ifa argument, so I am much less worried. Thank you for your time and attention. Sincerely, Demi M. Obenour signature.asc Description: OpenPGP digital signature
