snapshot boot fails with error "entry point at 0x1001000"

2020-07-03 Thread Kastus Shchuka
Hi,

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 suspect I am hitting the same problem as in 
https://marc.info/?l=openbsd-misc=159325874410286=2.

Disk is partitioned with GPT, and system boots through EFI.

There were other reports about BOOTX86.EFI supposedely causing this problem,
as in https://marc.info/?l=openbsd-misc=159147446008114=2.

I tried to boot snapshot kernel on 6.7-release system to make use of older 
BOOTX86.EFI, 
but it stopped at the same line "entry point at 0x1001000"

I could be wrong, but I doubt that efi is the problem. It seems that kernel 
size is.

If kernel is smaller than 20MB, it boots. If it is larger, it doesn't.

Are there any other solutions than compiling a custom smaller kernel?

I cannot produce dmesg from snapshot, but here is dmesg from 6.7-release:

OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8201129984 (7821MB)
avail mem = 7939952640 (7572MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6d946000 (18 entries)
bios0: vendor American Megatrends Inc. version "P1.30" date 05/04/2018
bios0: ASRock J4105M
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT 
SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BGRT WDAT WSMT
acpi0: wakeup devices SIO1(S3) PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) HDAS(S3) 
XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
RP04(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1496.53 MHz, 06-7a-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 19MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.86 MHz, 06-7a-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.87 MHz, 06-7a-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 4MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.86 MHz, 06-7a-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 4MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP03)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus 3 (RP05)
acpiprt4 at acpi0: bus 4 (RP06)
acpiec0 at acpi0: not present
acpipwrres0 at acpi0: DRST

Re: Relayd with TLS and non-TLS backends - bug

2020-07-03 Thread Brian Brombacher


> On Jul 3, 2020, at 9:46 PM, Daniel Jakots  wrote:
> 
> On Fri, 3 Jul 2020 20:25:12 -0400, Brian Brombacher
>  wrote:
> 
>> My subjective net gain is simplicity, security, performance, and
>> flexibility.
> 
> I don't think adding ipsec (or a mesh vpn) into the mix achieve that but
> ymmv.
> 

Subjective is right :)

He has two hosts.  IPsec from one to the other.  Pre-negotiated encrypted 
channel.

MTU 1400 or so...

Four round-trip TCP packets to get the request on the backend... if the HTTP 
request is smaller than say 1300 bytes, to be really safe.

How is that slower?

-Brian



Re: Relayd with TLS and non-TLS backends - bug

2020-07-03 Thread Daniel Jakots
On Fri, 3 Jul 2020 20:25:12 -0400, Brian Brombacher
 wrote:

> My subjective net gain is simplicity, security, performance, and
> flexibility.

I don't think adding ipsec (or a mesh vpn) into the mix achieve that but
ymmv.



Re: Relayd with TLS and non-TLS backends - bug

2020-07-03 Thread Daniel Jakots
On Fri, 3 Jul 2020 19:14:17 -0400, Henry Bonath 
wrote:

> Daniel,
> 
> Thanks for taking the time to test this out.
> I just reloaded a test machine from scratch with -current and
> installed the HAProxy 2.0.15-4f39279 package.
> I loaded a very basic config file, and am also seeing the same exact
> issue on this one as well.
> Very strange that you are not -
> Would you mind sharing any additional details of your config file?
> Is there anything special about the certificate you have on the
> backend server?
> 
> I would love to understand what is going on here and what the
> difference is with my experience.

What is your backend running? Can you connect from the haproxy host with
nc(1) and/or openssl(1)?

I try to do my stuff as vanilla as possible so it's an RSA key signed
by LE.



Re: Relayd with TLS and non-TLS backends - bug

2020-07-03 Thread Brian Brombacher


> On Jun 11, 2020, at 4:28 PM, Toyam Cox  wrote:
> 
> Hello Misc,
> 
> Full config at end of email.
> 
> I've discussed the below in #openbsd on freenode, and was told to come
> here. At present, I have a setup where I need multiple unrelated
> servers under a single IP address. I used relayd to do https
> interception, read the Host header, and make decisions.
> 
> The very relevant part of my config is this:
> 
> forward to  port 80
> forward with tls to  port 443
> 
> The order here does not matter (unlike most relayd configs, I know,
> but I've tested in my configuration and it works).
> 
> When I have "with tls" on that second line, I see error lines like:
> relay web, session 3 (1 active), 0, [redacted] -> 10.0.0.102:80, TLS
> handshake error: handshake failed: error:14FFF3E7:SSL
> routines:(UNKNOWN)SSL_internal:unknown failure occurred, GET:
> Undefined error: 0
> 
> and, unhelpfully, relayd responds with no response. There is no
> return. Or, as curl puts it: curl: (52) Empty reply from server
> 
> When I remove "with tls" then I successfully reach the http backend,
> but since the https backend requires ssl, that connection no longer
> works. So it seems that 'with tls" affects all "forward" clauses, not
> just the one to which it's attached.
> 
> I believe this to be a bug.
> 
> cat >/etc/relayd.conf < table  { "10.0.0.101" }
> table  { "10.0.0.102" }
> # obviously obfuscated some values
> 
> interval 5
> timeout 1000
> 
> log connection
> 
> http protocol web {
> return error
> 
> match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
> match header set "X-Forwarded-For" value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
> 
> http websockets
> pass request quick header "Host" value "myhost.example.com" path
> "/Client/*" forward to 
> pass request quick header "Host" value "otherhost.example.com" forward
> to 
> 
> block
> }
> 
> relay web {
> listen on 10.0.0.100 port 443 tls
> protocol web
> 
> forward to  port 80 check http "/webservice.asmx" code 405
> forward with tls to  port 443 check https
> "/Client/SupportedBrowsers.html" host "myhost.example.com" code 200
> }
> EOF
> 

Not to change topics too drastically :)

Consider running the backend connection over a different encrypted transport, 
such as mesh iked(8) or upcoming wg(4).  It’s super easy to setup, and 
compatible with the other server OS.  Go further into the “SDN realm” with 
everything encapsulated in vxlan(4) for even more flexibility, including 
long-haul internet endpoints across varying firewall and NAT designs.  Pimp out 
the configs of your networking groups’ routers to de-encapsulate and decrypt 
the traffic for even more performance and compatibility.  Anything is possible 
as a front-end relay server with OpenBSD.

Why?  Well for one, you save on many rounds of TLS negotiation.  Upcoming 
performance enhancements to the networking stack will only help scale this 
method of relaying to more and more acceptable levels compared to non-encrypted 
networking.  My subjective net gain is simplicity, security, performance, and 
flexibility.

-Brian



Re: Relayd with TLS and non-TLS backends - bug

2020-07-03 Thread Henry Bonath
Daniel,

Thanks for taking the time to test this out.
I just reloaded a test machine from scratch with -current and
installed the HAProxy 2.0.15-4f39279 package.
I loaded a very basic config file, and am also seeing the same exact
issue on this one as well.
Very strange that you are not -
Would you mind sharing any additional details of your config file?
Is there anything special about the certificate you have on the backend server?

I would love to understand what is going on here and what the
difference is with my experience.

On Thu, Jul 2, 2020 at 4:38 PM Daniel Jakots  wrote:
>
> On Thu, 2 Jul 2020 14:00:48 -0400, Henry Bonath 
> wrote:
>
> > Note the missing Client Hello on the 6.7 machine as it jumps to
> > Application Data straight away.
> > Configuration files for HAProxy are identical on both systems.
> >
> > I'm currently spinning up a machine on -CURRENT just to see if there
> > is any difference,
> > as there is a newer version of HAProxy in packages under Snapshots.
> >
> > I was initially going to try to reach out to the package maintainer
> > for HAProxy but if this is happening in Relayd, then this "feels
> > like" a de-facto bug. I wonder if NGINX would exhibit the same
> > behavior.
> >
> > Has anyone else experienced such behavior with Load-Balancing TLS
> > Backends since upgrading to 6.7?
>
> I don't use TLS for my backend (the only backend I use nowadays is on
> localhost) so I can't speak for 6.7 (I only use -current, and when
> -current was 6.7, I didn't test that).
>
> I just tested my -current haproxy using another -current host of mine
> running nginx as a backend with TLS and it worked fine.
>
> backend https
>option forwardfor
>server web1 ln.chown.me:443 check ssl verify none
>
> and also with "verify required ca-file /etc/ssl/cert.pem"
>
>
> Maybe some libressl fix happened on -current was not deemed critical
> enough to be backported to 6.7?
>
> Cheers,
> Daniel



Re: ssh X forwarding and google-chrome

2020-07-03 Thread Stuart Henderson
On 2020-07-02, Paul de Weerd  wrote:
> Hi Gregory,
>
> On Thu, Jul 02, 2020 at 05:33:20PM +0300, Gregory Edigarov wrote:
>| Hello, everybody
>| 
>| does anybody know if there is any tricks?
>| 
>| In my office pc (currently linux) I have google-chrome installed,
>| and I absolutely need to access it from home.
>| 
>| "ssh -Y  google-chrome" just shows an empty and blank
>| window, no menu, no address bar.
>| May be there is some command line flags I am not aware of?
>
> If you absolutely must access something on one machine and ssh
> forwarding doesn't work, you could look at VNC-solutions such as
> x11vnc (available as a package on OpenBSD, probably also on your linux
> distro of choice).


I strongly recommend using tigervnc instead of x11vnc, it works pretty nicely.





Re: relayd multiple listen on same redirect

2020-07-03 Thread Sebastian Benoit
Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2020.07.03 10:31:18 +0300:
> Hi,
> 
> My setup in relayd is like this:
> 
> redirect radius {
>listen on $radius_addr udp port radius interface $ext_if
>pftag RELAYD_radius
>sticky-address
>forward to  mode least-states check icmp demote carp
> }
> 
> redirect radacct {
>listen on $radius_addr udp port radacct interface $ext_if
>pftag RELAYD_radius
>sticky-address
>forward to  mode least-states check icmp demote carp
> }
> 
> I want to combine it in one redirect but the redirect forwards it to the 
> first port defined in listen for both radius and radacct ports.
> 
> redirect radius {
>listen on $radius_addr udp port radius interface $ext_if
>listen on $radius_addr udp port radacct interface $ext_if
>pftag RELAYD_radius
>sticky-address
>forward to  mode least-states check icmp demote carp
> }
> 
> Is there another way to do this

No

> or do I have to stick with two redirects?

Yes.

/Benno



Re: ssh X forwarding and google-chrome

2020-07-03 Thread Gregory Edigarov




On 2020-07-02 17:33, Gregory Edigarov wrote:

Hello, everybody

does anybody know if there is any tricks?

In my office pc (currently linux) I have google-chrome installed, and 
I absolutely need to access it from home.


"ssh -Y  google-chrome" just shows an empty and blank window, 
no menu, no address bar.

May be there is some command line flags I am not aware of?

Thank you.

Well, after some rethinking I've decided to use ssh port forwarding, 
because I just need an access to one internal server.


--
With best regards,
  Gregory Edigarov



relayd multiple listen on same redirect

2020-07-03 Thread Kapetanakis Giannis
Hi,

My setup in relayd is like this:

redirect radius {
   listen on $radius_addr udp port radius interface $ext_if
   pftag RELAYD_radius
   sticky-address
   forward to  mode least-states check icmp demote carp
}

redirect radacct {
   listen on $radius_addr udp port radacct interface $ext_if
   pftag RELAYD_radius
   sticky-address
   forward to  mode least-states check icmp demote carp
}

I want to combine it in one redirect but the redirect forwards it to the first 
port defined in listen for both radius and radacct ports.

redirect radius {
   listen on $radius_addr udp port radius interface $ext_if
   listen on $radius_addr udp port radacct interface $ext_if
   pftag RELAYD_radius
   sticky-address
   forward to  mode least-states check icmp demote carp
}

Is there another way to do this or do I have to stick with two redirects?

thanks,

Giannis