tor not working in 5.8 #1024

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

tor not working in 5.8 #1024

L.R. D.S.
I did the update of a box today, from 5.7 to 5.8 snapshot. Everything is working fine, except
the tor package. On 5.7 it work normally, without any additional configurations, but in 5.8 it
cannot complete connections. I watched my interface (re0) with tcpdump when trying a connection
and the connection go to the exit nodes, but can't download the content.
The package is from http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/
Default /etc/tor/torrc

What I tried:
- Purge packages/cache/configurations and reinstall;
- tor-resolve (in different domains);
- torsocks (cURL and Firefox);
- SOCKS5 in localhost:9050 (firefox);

Maybe:
- It's just a bad configuration (higher probability, since I'm not a sysadmin);
- Tor network instability;
- Tor incompatibility with -current 5.8;
- Bad compiled package;
- My ISP is blocking Tor connections (I don't think so).

Can someone help me here?
So far, that's the only trouble I have in 5.8 for now, thanks for the good job.
OpenSSL LibreSSL 2.2 and Zlib 1.2.3.

-----------------------------------------------------------------------------------------

dmesg

OpenBSD 5.8-beta (GENERIC.MP) #1024: Tue Jul 14 00:44:38 MDT 2015
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz ("GenuineIntel" 686-class) 3.21 GHz
cpu0: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
real mem  = 3629998080 (3461MB)
avail mem = 3544752128 (3380MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 12/22/11, SMBIOS rev. 2.7 @ 0xe98e0 (94 entries)
bios0: vendor American Megatrends Inc. version "1601" date 11/27/2013
bios0: ASUSTeK COMPUTER INC. P8H61-M LX2 R2.0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT DMAR SSDT SSDT
acpi0: wakeup devices P0P1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) PXSX(S4) RP04(S4) PXSX(S4) RP03(S4) PS2K(S4) PS2M(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz ("GenuineIntel" 686-class) 3.21 GHz
cpu1: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz ("GenuineIntel" 686-class) 3.21 GHz
cpu2: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz ("GenuineIntel" 686-class) 3.21 GHz
cpu3: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf8000000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus 1 (PEG0)
acpiprt5 at acpi0: bus -1 (PEG1)
acpiprt6 at acpi0: bus -1 (PEG2)
acpiprt7 at acpi0: bus -1 (PEG3)
acpiprt8 at acpi0: bus 5 (RP04)
acpiprt9 at acpi0: bus 3 (RP03)
acpiprt10 at acpi0: bus 4 (PXSX)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
bios0: ROM list: 0xc0000/0xe800
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: apic 2 int 16
pci1 at ppb0 bus 1
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 2500" rev 0x09
intagp at vga1 not configured
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1920x1080
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x05: msi
azalia0: codecs: VIA/0x0397
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5: apic 2 int 16
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 2 "Intel 82801BA Hub-to-PCI" rev 0xb5: apic 2 int 18
pci3 at ppb2 bus 3
ppb3 at pci3 dev 0 function 0 "ASMedia ASM1083/1085 PCIE-PCI" rev 0x03
pci4 at ppb3 bus 4
ppb4 at pci0 dev 28 function 3 "Intel 6 Series PCIE" rev 0xb5: apic 2 int 19
pci5 at ppb4 bus 5
re0 at pci5 dev 0 function 0 "Realtek 8168" rev 0x09: RTL8168F/8111F (0x4800), msi, address d8:50:e6:e7:c9:dc
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5
ehci1 at pci0 dev 29 function 0 "Intel 6 Series USB" rev 0x05: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
pcib0 at pci0 dev 31 function 0 "Intel H61 LPC" rev 0x05
pciide0 at pci0 dev 31 function 2 "Intel 6 Series SATA" rev 0x05: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using apic 2 int 20 for native-PCI interrupt
wd0 at pciide0 channel 1 drive 0: <TOSHIBA DT01ACA100>
wd0: 16-sector PIO, LBA48, 953868MB, 1953523055 sectors
wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 6 Series SMBus" rev 0x05: apic 2 int 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-10600
spdmem1 at iic0 addr 0x52: 8GB DDR3 SDRAM PC3-10600
pciide1 at pci0 dev 31 function 5 "Intel 6 Series SATA" rev 0x05: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide1: using apic 2 int 20 for native-PCI interrupt
atapiscsi0 at pciide1 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <TSSTcorp, DVD+-RW TS-H653G, D200> ATAPI 5/cdrom removable
cd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1 at pciide1 channel 1 drive 0: <HTS541060G9SA00>
wd1: 16-sector PIO, LBA48, 57230MB, 117208127 sectors
wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uhidev0 at uhub3 port 1 configuration 1 interface 0 "Logitech USB Receiver" rev 2.00/29.00 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub3 port 1 configuration 1 interface 1 "Logitech USB Receiver" rev 2.00/29.00 addr 3
uhidev1: iclass 3/1, 17 report ids
ums0 at uhidev1 reportid 2: 16 buttons, Z dir
wsmouse0 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 16: input=6, output=6, feature=0
uhid3 at uhidev1 reportid 17: input=19, output=19, feature=0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd0 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 005> SCSI2 0/direct fixed
sd0: 57168MB, 512 bytes/sector, 117081192 sectors
root on sd0a (c430f0d9250168c4.a) swap on sd0b dump on sd0b



--------------------------------------------------------------------------------



# dmidecode 2.12
SMBIOS 2.7 present.

BIOS Information
        Vendor: American Megatrends Inc.
        Version: 1601
        Release Date: 11/27/2013
        BIOS Revision: 4.6

Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: P8H61-M LX2 R2.0

Processor Information
        Socket Designation: LGA1155
        Type: Central Processor
        Family: Core 2 Duo
        Manufacturer: Intel
        Flags:
                FPU (Floating-point unit on-chip)
                VME (Virtual mode extension)
                DE (Debugging extension)
                PSE (Page size extension)
                TSC (Time stamp counter)
                MSR (Model specific registers)
                PAE (Physical address extension)
                MCE (Machine check exception)
                CX8 (CMPXCHG8 instruction supported)
                APIC (On-chip APIC hardware supported)
                SEP (Fast system call)
                MTRR (Memory type range registers)
                PGE (Page global enable)
                MCA (Machine check architecture)
                CMOV (Conditional move instruction supported)
                PAT (Page attribute table)
                PSE-36 (36-bit page size extension)
                CLFSH (CLFLUSH instruction supported)
                DS (Debug store)
                ACPI (ACPI supported)
                MMX (MMX technology supported)
                FXSR (FXSAVE and FXSTOR instructions supported)
                SSE (Streaming SIMD extensions)
                SSE2 (Streaming SIMD extensions 2)
                SS (Self-snoop)
                HTT (Multi-threading)
                TM (Thermal monitor supported)
                PBE (Pending break enabled)
        Version: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
        Voltage: 1.0 V
        External Clock: 100 MHz
        Max Speed: 3800 MHz
        Current Speed: 3211 MHz
        Status: Populated, Enabled
        Upgrade: Other
        L1 Cache Handle: 0x0005
        L2 Cache Handle: 0x0006
        L3 Cache Handle: 0x0007
        Core Count: 4
        Core Enabled: 1
        Characteristics:
                64-bit capable


--------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Michael McConville-2
On Wed, Jul 15, 2015 at 02:28:38AM +0200, L.R. D.S. wrote:
> I did the update of a box today, from 5.7 to 5.8 snapshot. Everything
> is working fine, except the tor package. On 5.7 it work normally,
> without any additional configurations, but in 5.8 it cannot complete
> connections. I watched my interface (re0) with tcpdump when trying a
> connection and the connection go to the exit nodes, but can't download
> the content.
>
> The package is from http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/

You changed your PKG_PATH or pkg.conf to that URL and ran 'sudo pkg_add
-u', right?

> Default /etc/tor/torrc
>
> What I tried:
> - Purge packages/cache/configurations and reinstall;
> - tor-resolve (in different domains);
> - torsocks (cURL and Firefox);
> - SOCKS5 in localhost:9050 (firefox);
>
> Maybe:
> - It's just a bad configuration (higher probability, since I'm not a sysadmin);
> - Tor network instability;
> - Tor incompatibility with -current 5.8;
> - Bad compiled package;
> - My ISP is blocking Tor connections (I don't think so).

Can you give examples of what's going wrong from the logs? They should
show up in /var/log/messages.

Also, there's a pretty well-populated mailing list for Tor on the BSDs:

        http://lists.nycbug.org/mailman/listinfo/tor-bsd

You may have better luck there. I suspect that this problem has a pretty
simple fix, though. I've been running snapshots for about five months
and have never had an issue with Tor (which I use daily), so I think
it's specific to your machine.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Michael McConville-2
In reply to this post by L.R. D.S.
On Wed, Jul 15, 2015 at 02:28:38AM +0200, L.R. D.S. wrote:
> The package is from http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/
>
> [...]
>
> OpenBSD 5.8-beta (GENERIC.MP) #1024: Tue Jul 14 00:44:38 MDT 2015
>     [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz ("GenuineIntel" 686-class) 3.21 GHz
> cpu0: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

Also, especially with a reasonably nice CPU like that, you should be on
amd64 unless you have a good reason not to be. It's more secure and
better maintained. I'd suggest installing an amd64 snapshot as your next
step. Note that you can't upgrade with a different architecture - it has
to be a reinstall.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

L.R. D.S.
In reply to this post by Michael McConville-2
Nevermind, the system time was wrong to tor could not use tls correctly.




> You changed your PKG_PATH or pkg.conf to that URL and ran 'sudo pkg_add
> -u', right?


Yes, of course. I just wanted to state that I downloaded the package from
the mother-server, not a mirror.


>Also, especially with a reasonably nice CPU like that, you should be on
>amd64 unless you have a good reason not to be. It's more secure and
>better maintained. I'd suggest installing an amd64 snapshot as your next
>step. Note that you can't upgrade with a different architecture - it has
>to be a reinstall.


Not that "nice". This hardware have many fancy things like UEFI and intel
ME.
I run i386 mostly because the /amd64.html say that "it is thus safer to
run those machines in i386 mode" because the port amd64 is for Athlon-64
and not for Intel x64. I know the amd64 will run fine in this machine,
but I don't bother because I just do simple things there and "it just
work".
Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Peter Hessler
On 2015 Jul 15 (Wed) at 05:27:37 +0200 (+0200), L.R. D.S. wrote:
:Not that "nice". This hardware have many fancy things like UEFI and intel
:ME.
:I run i386 mostly because the /amd64.html say that "it is thus safer to
:run those machines in i386 mode"

That is an incredibly ancient comment, and is eseentially no longer
relevant.


OK?

Index: amd64.html
===================================================================
RCS file: /cvs/openbsd/www/amd64.html,v
retrieving revision 1.253
diff -u -p -u -p -r1.253 amd64.html
--- amd64.html 2 Jul 2015 05:49:03 -0000 1.253
+++ amd64.html 15 Jul 2015 03:35:29 -0000
@@ -19,9 +19,7 @@
 <p>
 OpenBSD/amd64 runs on AMD's Athlon-64 family of processors in 64-bit mode.
 It also runs on processors made by other manufacturers which have cloned
-the AMD64 extensions.  (Some Intel processors lack support for important
-PAE NX bit, which means those machines will run without any W^X support --
-it is thus safer to run those machines in i386 mode).
+the AMD64 extensions.
 <p>
 Note that <a href="i386.html">OpenBSD/i386</a> also runs on these
 processors, but in 32-bit mode.


--
Familiarity breeds attempt.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Michael McConville-2
On Wed, Jul 15, 2015 at 05:36:30AM +0200, Peter Hessler wrote:
> On 2015 Jul 15 (Wed) at 05:27:37 +0200 (+0200), L.R. D.S. wrote:
> > Not that "nice". This hardware have many fancy things like UEFI and
> > intel ME.
>
> > I run i386 mostly because the /amd64.html say that "it is thus safer
> > to run those machines in i386 mode"
>
> That is an incredibly ancient comment, and is eseentially no longer
> relevant.

Agreed.

The full paragraph is:

> OpenBSD/amd64 runs on AMD's Athlon-64 family of processors in 64-bit
> mode. It also runs on processors made by other manufacturers which have
> cloned the AMD64 extensions. (Some Intel processors lack support for
> important PAE NX bit, which means those machines will run without any
> W^X support -- it is thus safer to run those machines in i386 mode).

And your CPU supports PAE NX:

        http://ark.intel.com/products/68316/Intel-Core-i5-3470-Processor-6M-Cache-up-to-3_60-GHz

If I'm reading your dmesg correctly, it's listed there as well.

Someone correct me if I'm wrong, but it seems that the days of i386
images being reasonable to run on amd64 hardware are coming to an end.
i386 support appears to be a fading priority for most projects and the
subset of amd64 features used is growing quickly.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Stuart Henderson
In reply to this post by Peter Hessler
On 2015-07-15, Peter Hessler <[hidden email]> wrote:

> On 2015 Jul 15 (Wed) at 05:27:37 +0200 (+0200), L.R. D.S. wrote:
>:Not that "nice". This hardware have many fancy things like UEFI and intel
>:ME.
>:I run i386 mostly because the /amd64.html say that "it is thus safer to
>:run those machines in i386 mode"
>
> That is an incredibly ancient comment, and is eseentially no longer
> relevant.
>
>
> OK?

I think it should go further, maybe "runs on x86-compatible CPUs in 64-bit mode"?
We don't really want to give people a reason not to try it.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Chris Cappuccio
In reply to this post by Michael McConville-2
Michael McConville [[hidden email]] wrote:
>
> Someone correct me if I'm wrong, but it seems that the days of i386
> images being reasonable to run on amd64 hardware are coming to an end.
> i386 support appears to be a fading priority for most projects and the
> subset of amd64 features used is growing quickly.

The N^X feature on OpenBSD/i386 can now provide better fine-grained control
if PAE available. This is new to OpenBSD 5.8. Before PAE was activated,
i386 used segments to provide an N^X feature. So, they are now at parity
with N^X.

I've never even ran across one of these very early 64-bit Intel chips
without N^X (those are the primary ones that you'd want to run i386 on).
Even my oldest 64-bit Pentium 4 chips claim NX support. The story goes
that Intel didn't want to copy AMD's NX support but implement it
differently. Microsoft told Intel they would only support one
implementation and AMD's was it.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Josh Grosse
On 2015-07-15 11:52, Chris Cappuccio replied to Michael McConville.
First, a quick reply to Michael:

> Michael McConville [[hidden email]] wrote:
>>
>> Someone correct me if I'm wrong, but it seems that the days of i386
>> images being reasonable to run on amd64 hardware are coming to an end.
>> i386 support appears to be a fading priority for most projects and the
>> subset of amd64 features used is growing quickly.

I still have several OpenBSD/i386 machines, and they work very well.

In the years to come, long after they are eventually replaced, I assume
that OpenBSD may still have i386 in the active pantheon, for testing the
robustness of its multi-architecture code base, if nothing else.

On 2015-07-15 11:52, Chris Cappuccio wrote:

> I've never even ran across one of these very early 64-bit Intel chips
> without N^X (those are the primary ones that you'd want to run i386
> on).
> Even my oldest 64-bit Pentium 4 chips claim NX support. The story goes
> that Intel didn't want to copy AMD's NX support but implement it
> differently. Microsoft told Intel they would only support one
> implementation and AMD's was it.

I believe I have one in inventory -- it is currently not in use, and is
powered off.  If memory serves the OS last installed on it was i386, due
due to the warning in the FAQ.

sam
Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

sam
On Wed, 15 Jul 2015 14:20:06 -0400
Josh Grosse <[hidden email]> wrote:

> On 2015-07-15 11:52, Chris Cappuccio replied to Michael McConville.
> First, a quick reply to Michael:
>
> > Michael McConville [[hidden email]] wrote:
> >>
> >> Someone correct me if I'm wrong, but it seems that the days of i386
> >> images being reasonable to run on amd64 hardware are coming to an
> >> end. i386 support appears to be a fading priority for most
> >> projects and the subset of amd64 features used is growing quickly.
>
> I still have several OpenBSD/i386 machines, and they work very well.
>
> In the years to come, long after they are eventually replaced, I
> assume that OpenBSD may still have i386 in the active pantheon, for
> testing the robustness of its multi-architecture code base, if
> nothing else.
>
> On 2015-07-15 11:52, Chris Cappuccio wrote:
>
> > I've never even ran across one of these very early 64-bit Intel
> > chips without N^X (those are the primary ones that you'd want to
> > run i386 on).
> > Even my oldest 64-bit Pentium 4 chips claim NX support. The story
> > goes that Intel didn't want to copy AMD's NX support but implement
> > it differently. Microsoft told Intel they would only support one
> > implementation and AMD's was it.
>
> I believe I have one in inventory -- it is currently not in use, and
> is powered off.  If memory serves the OS last installed on it was
> i386, due due to the warning in the FAQ.
>

PIE and ASLR other security features are either turned off on i386, in
compatibility modes, or are dialled down versions. It's not just about
a small speed difference, there are big security differences between
the architectures.

OpenBSD adds most of the security features for amd64 first, or in its
strongest iteration for amd64 anyway. So, while i386 isn't poisonous,
you should really use amd64 if you are able to.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Theo de Raadt
In reply to this post by L.R. D.S.
> PIE and ASLR other security features are either turned off on i386, in
> compatibility modes, or are dialled down versions. It's not just about
> a small speed difference, there are big security differences between
> the architectures.

That is false.
 
> OpenBSD adds most of the security features for amd64 first, or in its
> strongest iteration for amd64 anyway. So, while i386 isn't poisonous,
> you should really use amd64 if you are able to.

That is also false.

In fact, sparc64 has tended to be the leading architecture in the last
decade.  amd64 only caught up with kernel-side W^X in the last year,
while sparc64 had all the machine-dependent management correct, and
was only missing some machine-independent tuning.

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Josh Grosse
On 2015-07-15 15:05, Theo de Raadt wrote:

>> PIE and ASLR other security features are either turned off on i386, in
>> compatibility modes, or are dialled down versions. It's not just about
>> a small speed difference, there are big security differences between
>> the architectures.
>
> That is false.
>
>> OpenBSD adds most of the security features for amd64 first, or in its
>> strongest iteration for amd64 anyway. So, while i386 isn't poisonous,
>> you should really use amd64 if you are able to.
>
> That is also false.
>
> In fact, sparc64 has tended to be the leading architecture in the last
> decade.  amd64 only caught up with kernel-side W^X in the last year,
> while sparc64 had all the machine-dependent management correct, and
> was only missing some machine-independent tuning.

Since theo@ said I could, I think I'll continue to use my 32-bit-only
x86 CPUs until a compelling reason arises to replace them.  Those are
likely to be network bandwidth requirements in the long term for my AMD
Geodes, and imminent non-CPU hardware failures on an old Intel Atom
netbook.

It won't be because of of something in another architecture that grabs
my attenti.....Ooh, Shiny!!!

Reply | Threaded
Open this post in threaded view
|

Re: tor not working in 5.8 #1024

Theo de Raadt
In reply to this post by L.R. D.S.
> Since theo@ said I could, I think I'll continue to use my 32-bit-only
> x86 CPUs until a compelling reason arises to replace them.

As long as the cpu shows NXE in dmesg.