Re: Blob-free OpenBSD kernel needed
Countryguy, I guess my challenge would be this: If you consire all this easy and important, why don't you start right away implementing on those ideas and share the links with the results with everyone? (This is what I say to myself every time I think about something on the lines of your message. That is, it's not something to write about, or to suggest, but to get done. If it's good and relevant to you, start working on it, it's all BSD - maybe other people would follow you). I guess that's why projects like OpenBSD deserve respect: they are not just preaching the importance of security, they are actually working and building an OS consistent with this. And they are working on that for a looong time. So, the best "constructive critic" IMHO is 1) provide better code; or 2) fork. What will it be? "Nah, just had this great important revolutionary idea that I thought would change reality." Thanx, but... It's harder than this, YOU need to WORK on your idea, A LOT, implement it, ask for guidance from other people, make it better... Takes a good load of stamina. If you want HW freedom, I think the viable way is this: https://www.crowdsupply.com/purism/librem-15#products-top Don't forget to cryptograph all your messages, all your data, making sure it goes encrypted end to end always. Cheers! On Friday, June 5, 2015, wrote: > Hello, > It has come to my attention that OpenBSD does not included non-free > drivers, dubbed "blobs" - which is excellent. However, you still include > non-free firmware in the kernel and some packages. > > With spying revelations, it is well-known that non-free firmware can > contain backdoors. ( just one recent example: > http://www.wired.com/2015/02/nsa-firmware-hacking/ ) > > I would feel a lot safer if the kernel and packages were fully free, > containing no non-free drivers nor non-free "firmware". > > At the very least provide a separate branch of known "clean" 100% free > packages and kernel. For example the non-free athn and rsu firmware are > currently in the repository, and I would suspect other non-free firmware is > into the kernel. > > Offering a stripped kernel and separating those few packages only > increases the security of OpenBSD. > > Also, We can probably find replacements for most all the non-free > firmware. Taking for example this replacement for some of the athn > firmwares: https://github.com/qca/open-ath9k-htc-firmware > > All we'd need is a driver to load those instead of the blobs. > > > Thanks for your time and consideration!
Re: Blob-free OpenBSD kernel needed
> Hello, Hello Mr. Whoever you are, > It has come to my attention that OpenBSD does not included non-free > drivers, dubbed "blobs" - which is excellent. However, you still > include non-free firmware in the kernel and some packages. That is false. The kernel includes a few minor firmwares which are FREELY PROVIDED by the vendors of that hardware, since those vendors chose to not put those firmware onto ROMS on their cards. Those firmwares are FREE. Please indicate a single vendor who wants MONEY for that firmware. They don't want money. They want people to use the hardware which they skipped on adding a ROM to. That is why the firmware is free. A few other firmwares are slightly less free. Meaning they are free for money, but they try to stipulate subtle rules we do not want to impact the freedom of our source tree with. To solve this specific problem, a few creative developers in the group have found a way to package those up and make them available on the internet. OpenBSD has a tool built in which will download those, so that our base source tree remains full of freedom. Those are treated the same. If the hardware exists, we load it onto the hardware. The firmwares are NOT RUN BY THE HOST CPU. They are running on the network or other such hardware which you foolishly purchased! > With spying revelations, it is well-known that non-free firmware can > contain backdoors. ( just one recent example: > http://www.wired.com/2015/02/nsa-firmware-hacking/ ) You are speaking in riddles. Non-free firmware can contain backdoors just as well. 99% of the hardware we run on contains firmwares *IN ROM*. Those could contain backdoors. You use such machines. You sent your email from a machine containing ROM firmwares. Quite often, those are not in true ROM, either, but rewriteable using tricks that the vendors know, but which we don't know. > I would feel a lot safer if the kernel and packages were fully free, > containing no non-free drivers nor non-free "firmware". That's nice. Then don't run hardware which needs those firmwares. See, your problems are solved so easily! > At the very least provide a separate branch of known "clean" 100% > free packages and kernel. For example the non-free athn and rsu > firmware are currently in the repository, and I would suspect other > non-free firmware is into the kernel. You are so full of BS! The firmware for the athn driver is NOT IN THE REPOSITORY! For USB devices, the driver needs at least version 1.1 of the following firmware files, which are loaded when an interface is attached: /etc/firmware/athn-ar7010 /etc/firmware/athn-ar7010-11 /etc/firmware/athn-ar9271 A prepackaged version of the firmware can be installed using fw_update(1). There is Makefile somewhere in the ports tree which KNOWS where to find that firmware on the internet. That's it. Your definition of free is so clouded! Same with the rsu firmware. WHERE in the source repository do you see the bytes that came from the vendor? > Offering a stripped kernel and separating those few packages only > increases the security of OpenBSD. That is BS. If you don't want to run those firmware, don't buy and insert those particular USB devices. > Also, We can probably find replacements for most all the non-free > firmware. You are quite a persistant idiot. Find replacement of a firmware that a vendor wrote for their specific undocumented chip; which runs on the custom processor and hardware on the athn USB device? That runs on the rsu hardware, which is probably some kind of crappy vendor-modified ARM or MIPS or 8085 derived cpu attached to a blob of Verilog logic they designed in their own lab? You don't know jack shit about computers or electronics, that much is obvious. > Taking for example this replacement for some of the athn > firmwares: https://github.com/qca/open-ath9k-htc-firmware That is not a "device firmware". Those Atheros devices contain no cpu, only gate array logic to do their work. As a result, a driver has been written which runs on the NATIVE HOST CPU, meaning, inside Linux or OpenBSD. Same as our ath(4) driver. That is a non-firmware designed chipset. Once again you show that you don't know shit. > All we'd need is a driver to load those instead of the blobs. Good luck with that buckeroo. Looking forward to your complete rewrite of the Broadcom NetXtreme II 10/100/Gigabit firmware, by the way. There are about 25 versions of this product, and they have 4-6 MIPS 64-bit cpus running different firmwares on them. Total size, around 260K. It's like a bunch of independent operating systems running on propriety hardware! Please remember to send your new firmware source for that hardware nicely indented; we like the tabs + 4-space mode described in our style(9) page! Fact is, modern hardware simply "is what it is". Telling people that OpenBSD should not run on such hardware is a gigantic illusion. You com
Blob-free OpenBSD kernel needed
Hello, It has come to my attention that OpenBSD does not included non-free drivers, dubbed "blobs" - which is excellent. However, you still include non-free firmware in the kernel and some packages. With spying revelations, it is well-known that non-free firmware can contain backdoors. ( just one recent example: http://www.wired.com/2015/02/nsa-firmware-hacking/ ) I would feel a lot safer if the kernel and packages were fully free, containing no non-free drivers nor non-free "firmware". At the very least provide a separate branch of known "clean" 100% free packages and kernel. For example the non-free athn and rsu firmware are currently in the repository, and I would suspect other non-free firmware is into the kernel. Offering a stripped kernel and separating those few packages only increases the security of OpenBSD. Also, We can probably find replacements for most all the non-free firmware. Taking for example this replacement for some of the athn firmwares: https://github.com/qca/open-ath9k-htc-firmware All we'd need is a driver to load those instead of the blobs. Thanks for your time and consideration!
How to route squid traffic over a particular interface transparently
I'm currently running squid on my gateway - working well. I've got the standard couple of lines that they recommend putting into pf.conf pass in quick on inet proto tcp from 192.0.2.0/24 to port www divert-to 127.0.0.1 port 3129 pass out quick inet from 192.0.2.0/24 divert-reply My situation is that I need to route traffic coming from different sources out different WAN ports.. I'm not sure how to approach this - does anyone have any suggestions? Any tips appreciated. Thanks.
Re: Ajaxterm with httpd?
Hi Raf, On Fri 05/06/2015 03:33, Raf Czlonka wrote: > Httpd is not required in order to run 'ajaxterm' - it runs on its own > webserver. > > On -current: > > sudo pkg_add ajaxterm > sudo rcctl start ajaxterm > x-www-browser http://localhost:8022/ > > It's not tremendously useful on localhost, mind you :^), so you'll need > to use relayd(8) in order to both forward the HTTP traffic to port 8022 > on localhost as well as encapsulate it in TLS - a simple 'rdr-to' pf(4) > rule will suffice for testing, and *only* testing, purposes (i.e. do > *not* send your username or password over plain HTTP on an untrusted > network. In fact, I'm already using plain HTTP by means of a rdr-to rule in pf: pass in on $ext_if proto tcp from any to any port 8022 rdr-to 127.0.0.1 port 8022 and, of course, it is only for testing purpose. Now, in order to make the server accessible from the Internet, I need to encapsulate the traffic in TLS - as you correctly said - and I was thinking to something similar to the Apache's "proxy" plugin. As far as I understand from your reply, this can be obtained using relayd (and not httpd); ok, I'll dig into the documentation. Thanks a lot for your precious help. All the best -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
ifconfig.if rtsol autoconf diff
Had some trouble this morning in configuring inet6 on a new laptop. Finally figured out that rtsol is dropped and that the functionality is moved to the kernel. Diff for hostname.if(5) included. Someone might want to replace the "rtsol" keyword in the installer as well. Index: hostname.if.5 === RCS file: /cvs/src/share/man/man5/hostname.if.5,v retrieving revision 1.62 diff -u -p -r1.62 hostname.if.5 --- hostname.if.5 12 Jul 2014 16:59:06 - 1.62 +++ hostname.if.5 5 Jun 2015 13:30:46 - @@ -248,26 +248,24 @@ Valid options for a particular interface .Pp IPv6 stateless address autoconfiguration: .Bd -ragged -offset indent -.Li rtsol +.Li inet6 autoconf .Va options .Ed .Pp The above format has the following field values: .Bl -tag -width indent -offset indent -.It Li rtsol +.It Li autoconf The literal string -.Dq rtsol +.Dq autoconf if the interface is to be configured using IPv6 stateless address autoconfiguration. This should be used on single interface hosts only, since the IPv6 specifications are silent about the behavior on multi-interface hosts. Also note that the kernel must be configured as a host (i.e. non-router). -Add the following line into -.Xr sysctl.conf 5 : -.Bd -literal -offset indent -net.inet6.ip6.forwarding=0 -.Ed +This is the default. This value deprecates the +.Dq rtsol +field value. .It Va options Miscellaneous options to set on the interface, e.g., .Dq media 100baseTX mediaopt full-duplex .
The Memory Sinkhole - Unleashing an x86 Design Flaw Allowing Universal Privilege
Hello, just a fyi, august 5-6 https://www.blackhat.com/us-15/briefings.html#the-memory-sinkhole-unleashing-an-x86-design-flaw-allowing-universal-privilege-escalation https://news.ycombinator.com/item?id=9663249 "In x86, beyond ring 0 lie the more privileged realms of execution, where our code is invisible to AV, we have unfettered access to hardware, and can trivially preempt and modify the OS. The architecture has heaped layers upon layers of protections on these negative rings, but 40 years of x86 evolution have left a labyrinth of forgotten backdoors into the ultra-privileged modes. Lost in this byzantine maze of decades-old architecture improvements and patches, there lies a design flaw that's gone unnoticed for 20 years. In one of the most bizarre and complex vulnerabilities we've ever seen, we'll release proof-of-concept code exploiting the vast, unexplored wasteland of forgotten x86 features, to demonstrate how to jump malicious code from the paltry ring 0 into the deepest, darkest realms of the processor. Best of all, we'll do it with an architectural 0-day built into the silicon itself, directed against a uniquely vulnerable string of code running on every single system." presented by Christopher Domas https://www.blackhat.com/us-15/speakers/Christopher-Domas.html
Re: SOLVED! System BOOT (and load) Read-Only File System: SOLVED!
On June 5, 2015 12:56:41 PM GMT+02:00, Max Power wrote: >Thank you guys! >I solved in this way: >boot> boot -s ># mount -uw / ># fsck Why would you need, or want, to mount the fs rw (if at all) to fsck it? I have a feeling you are not telling us the whole story. How are your disks configured? /Alexander >Subject: System BOOT (and load) Read-Only File System >From:"Max Power" >Date:Thu, June 4, 2015 10:52 pm >To: misc@openbsd.org >-- > >Last night I turned off the server, all ok. >This morning I turned on the server (OpenBSD 5.7 amd64) and the system >loads read-only file system... I can not even settle with fsck (just >because the file system is read-only). A tip, thanks.
pppoe broken on either 5.7 or on if Intel 82541GI ?
Hi,
I have a box running with 5.6 and a pppoe device on vlan on em with
Intel I354 SGMII rev 0x03: msi
hardware:
- - -
20:21:26.689948 00:60:e0:5a:75:45 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid 7 pri
3 PPPoE-Discovery
code Initiation, version 1, type 1, id 0x, length 12
tag Service-Name, length 0
tag Host-Uniq, length 4 \376\012?\264
20:21:26.718782 00:30:88:1f:18:9a 00:60:e0:5a:75:45 8100 87: 802.1Q vid 7 pri
6 PPPoE-Discovery
code Offer, version 1, type 1, id 0x, length 63
tag Host-Uniq, length 4 \376\012?\264
tag AC-Name, length 27 FFMR71-se800-B2224180702381
tag AC-Cookie, length 16 \206\221lvg}\351\201Bv\243>\211;8\037
tag Service-Name, length 0
20:21:26.718803 00:60:e0:5a:75:45 00:30:88:1f:18:9a 8100 56: 802.1Q vid 7 pri
3 PPPoE-Discovery
code Request, version 1, type 1, id 0x, length 32
tag Service-Name, length 0
tag AC-Cookie, length 16 \206\221lvg}\351\201Bv\243>\211;8\037
tag Host-Uniq, length 4 \376\012?\264
20:21:26.853607 00:30:88:1f:18:9a 00:60:e0:5a:75:45 8100 67: 802.1Q vid 7 pri
6 PPPoE-Discovery
code Confirm, version 1, type 1, id 0x29fc, length 43
tag Service-Name, length 0
tag Host-Uniq, length 4 \376\012?\264
tag AC-Name, length 27 FFMR71-se800-B2224180702381
20:21:26.853628 00:60:e0:5a:75:45 00:30:88:1f:18:9a 8100 40: 802.1Q vid 7 pri
3 PPPoE-Session
code Session, version 1, type 1, id 0x29fc, length 16
LCP: Configure-Request, Magic-Number=1773963538,
Max-Rx-Unit=1492[|lcp]
20:21:26.872368 00:30:88:1f:18:9a 00:60:e0:5a:75:45 8100 60: 802.1Q vid 7 pri
6 PPPoE-Session
code Session, version 1, type 1, id 0x29fc, length 20
LCP: Configure-Request, Max-Rx-Unit=1492, Auth-Prot PAP,
Magic-Number=1567081095, Vendor-Ext
20:21:26.872386 00:60:e0:5a:75:45 00:30:88:1f:18:9a 8100 44: 802.1Q vid 7 pri
3 PPPoE-Session
code Session, version 1, type 1, id 0x29fc, length 20
LCP: Configure-Ack, Max-Rx-Unit=1492, Auth-Prot PAP,
Magic-Number=1567081095[|lcp]
20:21:26.872611 00:30:88:1f:18:9a 00:60:e0:5a:75:45 8100 60: 802.1Q vid 7 pri
6 PPPoE-Session
code Session, version 1, type 1, id 0x29fc, length 16
LCP: Configure-Ack, Magic-Number=1773963538, Max-Rx-Unit=1492,
Vendor-Ext
- - -
A similar box with identical configuration running 5.7-RELEASE on
Intel 82541GI" rev 0x05:
hardware fails so:
- - -
17:56:41.323171 00:0f:c9:04:db:87 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid 7 pri
3 PPPoE-Discovery
code Initiation, version 1, type 1, id 0x, length 12
tag Service-Name, length 0
tag Host-Uniq, length 4 \260\272\327\214
17:56:41.354542 00:30:88:1f:18:9a 00:0f:c9:04:db:87 8100 87: 802.1Q vid 7 pri
6 PPPoE-Discovery
code Offer, version 1, type 1, id 0x, length 63
tag Host-Uniq, length 4 \260\272\327\214
tag AC-Name, length 27 FFMR71-se800-B2224180702381
tag AC-Cookie, length 16 \347\030G\245\270#z Cd0=\2339{\225
tag Service-Name, length 0
17:56:41.354589 00:0f:c9:04:db:87 00:30:88:1f:18:9a 8100 56: 802.1Q vid 7 pri
3 PPPoE-Discovery
code Request, version 1, type 1, id 0x, length 32
tag Service-Name, length 0
tag AC-Cookie, length 16 \347\030G\245\270#z Cd0=\2339{\225
tag Host-Uniq, length 4 \260\272\327\214
17:56:41.491217 00:30:88:1f:18:9a 00:0f:c9:04:db:87 8100 67: 802.1Q vid 7 pri
6 PPPoE-Discovery
code Confirm, version 1, type 1, id 0x49b6, length 43
tag Service-Name, length 0
tag Host-Uniq, length 4 \260\272\327\214
tag AC-Name, length 27 FFMR71-se800-B2224180702381
17:56:41.491275 00:0f:c9:04:db:87 00:30:88:1f:18:9a 8100 40: 802.1Q vid 7 pri
3 PPPoE-Session
code Session, version 1, type 1, id 0x49b6, length 16
LCP: Configure-Request, Magic-Number=864862261,
Max-Rx-Unit=1492[|lcp]
17:56:41.509576 00:30:88:1f:18:9a 00:0f:c9:04:db:87 8100 60: 802.1Q vid 7 pri
6 PPPoE-Session
code Session, version 1, type 1, id 0x49b6, length 20
LCP: Configure-Request, Max-Rx-Unit=1492, Auth-Prot PAP,
Magic-Number=1077747764, Vendor-Ext
17:56:41.509623 00:0f:c9:04:db:87 00:30:88:1f:18:9a 8100 34: 802.1Q vid 7 pri
3 PPPoE-Session
code Session, version 1, type 1, id 0x49b6, length 10
LCP: Configure-Reject, Auth-Prot PAP[|lcp]
17:56:41.509701 00:30:88:1f:18:9a 00:0f:c9:04:db:87 8100 60: 802.1Q vid 7 pri
6 PPPoE-Session
code Session, version 1, type 1, id 0x49b6, length 16
LCP: Configure-Ack, Magic-Number=864862261, Max-Rx-Unit=1492,
Vendor-Ext
17:56:41.528690 00:30:88:1f:18:9a 00:0f:c9:04:db:87 8100 60: 802.1Q vid 7 pri
6 PPPoE-Session
code Session, version 1, type 1, id 0x49b6, length 21
LCP: Configure-Request, Max-Rx-Unit=1492, Auth-Prot CHAP/MD5,
Magic-Number=1077747764, Vendor-Ext
17:56:41.528729 00:0f:c9:04:db:87 00:30:88:1f:18:9a 8100 35: 802.1Q vid 7 pri
3 PPPoE-Session
code Session, versi
SOLVED! System BOOT (and load) Read-Only File System: SOLVED!
Thank you guys! I solved in this way: boot> boot -s # mount -uw / # fsck Original Message Subject: System BOOT (and load) Read-Only File System From:"Max Power" Date:Thu, June 4, 2015 10:52 pm To: misc@openbsd.org -- Last night I turned off the server, all ok. This morning I turned on the server (OpenBSD 5.7 amd64) and the system loads read-only file system... I can not even settle with fsck (just because the file system is read-only). A tip, thanks.
route-to looking for better ways
Hi, I have set up 2 tunnels to my VPS's from a OpenBSD pppoe gateway. Today I wanted to switch a source route from one tunnel to the other tunnel (at hetzner) and was dumbfounded after applying new rulesets [1], and killing the individual states of traffic on tun0. It didn't work so I'm left wondering whether this is a bug. I did a pfctl -Fstates as a last resort and that helped move everything over. But flushing all the states isn't my idea of fun. [1] this is an excerpt from my rules in /etc/pf.conf ### !!! this is the reroute to amsterdam ### # pass in on em3 inet from any to ! 192.168.181.1 route-to (tun0 10.99.99.1) #pass out on tun0 inet from 192.168.181.0/24 to any #match out on tun0 inet from to any nat-to (tun0) ### !!! this is the reroute to hetzner ### pass in on em3 inet from any to ! 192.168.181.1 route-to (tun1 10.88.88.1) pass out on tun1 inet from 192.168.181.0/24 to any match out on tun1 inet from to any nat-to (tun1) ### Is there a way I missed other than the pfclt -k id -k stateid, and the pfctl -Fstate? Cheers, -peter
