/g/ - Technology

install openbsd

[Make a Post]
[X]





Alternative Operating Systems Nanonymous No.1573 [D][U][F][S][L][A][C] >>1574 >>5527
File: 5c62a29805ea7f2e35a05ed8e2a3589448d31b24c5107db47870b7c6bd9569c5.jpg (dl) (81.70 KiB)

As a Linux user, I can't think of any moral or technical reason that I would stop using Linux in favor of a BSD operating system. My technical needs are met, I'm not forced to use systemd, and I'm familiar with the userland tools. Why should I use anything but Linux?

Nanonymous No.1574 [D] >>5549

>>1573
>Hurr durr convince me
The choice is yours. It is not our responsibility to ensure the long-term reliability of your system against bluehairs.
I don't give two shits whether you want to use a pozzed system or not.

Nanonymous No.1575 [D]

There really is no reason.

Nanonymous No.1584 [D] >>1599 >>1632

I use windows as i have been relatively tech illiterate up until recently. Being a relatively old guy i remember windows 95 and everything in between 10. All can say is that i loved windows XP and everything past 7 sucked. And then windows 10 came out and it has a fucking Microsoft store. I liked windows because it was convenient but it has forced me to consider Linux.

Nanonymous No.1599 [D] >>1600 >>1602 >>1655 >>1675

>>1584
I have not idea where to refer newcomers to Linux, there are so many options for people.

Nanonymous No.1600 [D] >>5527

>>1599
some live distro

Nanonymous No.1602 [D]

>>1599
Well which distro are you using?

Nanonymous No.1626 [D] >>5752

Personal preference is a reason.

Nanonymous No.1632 [D] >>5401

Windows is superior OS

>>1584
If you liked Win XP the most why aren't you fucking using it?

Nanonymous No.1635 [D] >>1657

>I got a Raspberry Pi to fuck with once to make a file server,
>then I got another Pi,
>then I got a laptop, put an SSD with a Linux Distro onto it,
>Have one Linux Laptop at my breakfast nook now,
>Another Linux Laptop upstairs with two screens attached to it to be my main workhorse,
>Another Linux Laptop setup to boot directly into Focuswriter
>Another Dual-Bootable Linux Laptop with Kali and another distro on it.
>Windows laptop is now in the closet.

Nanonymous No.1655 [D][U][F] >>1658 >>1675
File: 4ec8f4d0ca86de344bc82087272ded81b7c545afe93b31a95e07bf7e2387d097.jpg (dl) (559.19 KiB)

>>1599
Mint or Ubuntu. Always.

Nanonymous No.1657 [D] >>5527

>>1635
>using trannux
>ever
>>>/pig/

Nanonymous No.1658 [D]

>>1655
Probably the best option for newcomers, yes.
>Well which distro are you using?
Devuan.

Nanonymous No.1675 [D] >>1683 >>2853

>>1599
>>1655
The only distributions worth pointing newfags towards are MXLinux or Manjaro. MXLinux is infinitely better than ubuntu and it's cancerous derivatives even for newfags. Manjaro or any arch auto installer is also amazing because the biggest problem people will run into with linux is installing obscure software, which the AUR makes a non-issue. For years I avoided arch and arch based things because of people constantly talking about how spooky and difficult it is, when installing arch takes 20 minutes while following a guide and the AUR makes up for the time you would otherwise spend having to juggle stupid shit like .deb files and finding ppa's. The only reason I suggest MXLinux is that for whatever reason Manjaro and Antergos refuse to install in 50% of hardware I've tested them on, meanwhile the commies who made AntiX have somehow developed shit that runs on literally everything without a single issue.

Nanonymous No.1683 [D] >>1684 >>1707

>>1675
Fucking install openbsd you fucking newfag trannux user.

Nanonymous No.1684 [D] >>1685 >>1700

>>1683
I would, if I didn't want to use my computer for anything important.

Nanonymous No.1685 [D] >>1699

>>1684
You trannuxfags use precisely the same arguments as wangblowsfags used to. No surprise that Trannux is turning into Macroshit-controlled SystemD-permeated bluehair trash.
By the way, Hikkise once said that Nanochan was hosted on an OpenBSD system. In that case, you might want to leave, because according to you nanochan isn't anything important eh?

Nanonymous No.1699 [D]

>>1685
considering that you're here then no it's not

Nanonymous No.1700 [D]

>>1684
Why would you base the viability of an operating system for your own personal use on the fact that others use it for more important shit that you wouldn't ever do? If it works for you then that's good enough

Nanonymous No.1707 [D] >>2013 >>2014

>>1683
>xD you can use a single OS for everything
That's not how computers work. I do use openbsd. I also use arch, windows, gentoo, antix, tails, and a myriad of other operating systems on different computers depending on their use case. The guy I was responding to was asking which beginner OS is the best to use, and the answer to that question will always be MXLinux or any arch based distribution.

Nanonymous No.2011 [D] >>2015 >>6532

what are some simple (less than a couple of minutes a day) ways to help improve the direction of computing?
eg. giving page hits and reviews to well-made OSs on distrowatch.com and other sites
eg. promoting good yet usable OSs (MX, Void, Devuan ?) on normalfag sites like reddit and 4chan
eg. monetary donations to the right places, wherever those are

Nanonymous No.2012 [D]

*beginner usable, ie. can install flawlessly and easily on most normalfag hardware

Nanonymous No.2013 [D] >>2014

>>1707
You can, if you put some effort into learning how your system works

Nanonymous No.2014 [D]

>>1707
>>2013
You can, but it's not always optimal.
I more or less have one desktop/laptop os and a live boot os for fast booting, so 99% spent on one OS. The more range of things you do (esp. visual/audio stuff) and the more values you have (FOSS, security), the more likely you will need multiple OSs OS

Nanonymous No.2015 [D] >>2016

>>2011
>donations
Considering shit like the Linux foundation literally just gives your money to shit-skins I wouldn't ever give your money to anyone for ""charity"". Donating in any capacity is a very bugman thing to do. Keep your money and spend it wisely.

Nanonymous No.2016 [D] >>2017

>>2015
Chinks don't donate though. They hoard their money and belongings. It's usually white christcucks or liberals who do things like that.

Nanonymous No.2017 [D]

>>2016
Consumerist bugmen, not yellow jews.

Nanonymous No.2021 [D] >>2022 >>2729

would you donate to openbsd?

Nanonymous No.2022 [D]

>>2021
no, don't donate to openbsd, just learn programming and do some work for them/contribute to the code/documentation/whatever.
I would trust openbsd devs more than other projects because they're mostly white autistic weebs, but still, I don't have a clue what they do with all their donations and as such I am not interested in donating.

Nanonymous No.2713 [D] >>2716

This. I'd be using something without SystemD like Devuan, Artix, PCLinuxOS, Gentoo, etc. if I wasn't using suicide-inducing normalfag hardware.
There's literally nothing harder about the install for PCLinuxOS than Ubuntu, so it should be recommended for newbz wherever possible since it lacks SuckmyD. A situation where it wouldn't be possible is mine, where anything besides *buntu breaks after every attempt at getting graphics drivers to work.
>inb4 user error
I promise it isn't. I actually managed to have PCLinuxOS usable for my needs daily for awhile, until it failed to boot out of the blue.

Nanonymous No.2716 [D]

>>2713
What graphics card do you have?
>until it failed to boot out of the blue
What do you mean? The displaye server (xorg/wayland) or a kernel panic?

Nanonymous No.2729 [D]

>>2021
>would you donate to openbsd?
if openbsd enabled my business in some important way, I would throw them at least a token amount of money.

Nanonymous No.2853 [D]

>>1675
>time you would otherwise spend having to juggle stupid shit like .deb files
Never happened to me, everything you need is in repository.


Nanonymous No.5340 [D]
>alternative OS's

Theres about a billion gorillion zillion FRANS FILLION OF THEM!!!!!!!!!!!!!!!!!!11111 (wasn't he a french president or something?)


Here's a few:
9front/9atom/plan9/inferno
ReactOS
{Alpine,Gentoo,Funtoo,U/Xbuntu,Mint,Ultimate Edition,Slackware,Fedora,Scientific,Cent,Manjaro,Arch,Artix,Debian,Devuan,Clear,Void} Linux
{Net,Open,Liberty,Free,DragonFly,Ghost,Hardened,Mir}BSD and TrueOS
Solaris & OpenIndiana
Haiku
Minix
Redox
TempleOS/Shrine
Arca


DistroWatch is your friend:
https://www.distrowatch.com/

Nanonymous No.5341 [D] >>5578
>No reason not to use linux

Possible NSA backdoor.
Less likely than Win-i-have-downsyndrome-dows or Crapple, but:
https://old.reddit.com/r/linux/comments/54in5s/the_nsa_has_tried_to_backdoor_linux_three_times/

Nanonymous No.5401 [D] >>5403
>>1632 its no longer supported post 2020

Nanonymous No.5403 [D]
>>5401

The US Navy paid to have it extended back in 2014, I wonder if they are still using it or not:
https://www.rt.com/usa/270526-navy-millions-windows-xp/

Says until 2017, but who knows.

Nanonymous No.5404 [D] >>5481
>>2915
> the more likely you will need multiple OSs OS

yeop. Windows is superior for visual/audio software dev. Where as linux will always be the place I go to for scripting/coding. As of now, UNIX is what I use to learn commands, system administration, openbsd feels like a sandbox, a go to place for learning how it "works"

Nanonymous No.5481 [D] >>5528
>>5404

>Windows is superior for visual/audio software dev.

Superior or not (debatable), this makes it sound like it's okay to use Windows (which spies on people, reinforces ignorance, laziness and stupidity) is "okay" so long it's "necessary" or you "have to".
Unless you have to work for a business that's technically retarded (and have no reasonable sway over the retarded leadership), there is no excuse for that.

Nanonymous No.5527 [D]
>>1573
Nobody's forcing you to do anything, but I will say that getting stuck with whatever is your favorite without considering learning alternatives is how you get people stuck on Windows, defending everything that they know is evil and not wanting to move for the sake of comfort.

I gave Project Trident a try, but it just isn't useful as a workstation. I may use it on a NAS soon enough, but that's about it.

>>1600
I gave a buddy a knoppix drive awhile back. He absolutely loved it.

>>1657
Bitch, do you not know where you are?

Nanonymous No.5528 [D] >>5533
>>5481
>laziness
I'm lazy as fuck and I use linux precisely because it allows me to be lazy. Using computer is pain so why not spend few hours getting things comfy? afaik I can't do that on windows

Nanonymous No.5533 [D] >>5543
Using windows is fine for game and chilling, not for serious stuff.
It is possible to secure it to a decent point also.
inb4 you can't be sure they're not spying cause not open source
Who cares i can take the risk if all i do on windows is playing vidya
>>5528
If used with open shell, well configured settings/policies and with good software windows 10 LTSC is pretty comfy, i can definitely get lazy on windows xD
Linux feels more like a productivity OS to me, so i use it for developing.

Nanonymous No.5543 [D] >>5546
>>5533
breddy much. windows is only good becasue i still use a stand alone copy of photoshop i bought centuries ago. like almost every human being, one does not simply go form photoshop > gimp. its interface is unbelievable. cant get the same artistry results.

Nanonymous No.5544 [D]
maybe i could use wine, and run it on gnu/linux, but the cd install is really smooth.

Nanonymous No.5546 [D]
>>5543
Krita is fine for drawing.
Photoshop is still king in everything else sadly.

Nanonymous No.5549 [D]
>>1574
>it's pozzed because uhhh uhh
>because it us

Nanonymous No.5551 [D] >>5552 >>5554
https://www.bedrocklinux.org/introduction.html
This is an alternative distribution that uses software from many different Linux distributions called Bedrock Linux. It probably gets its name from all the source and package repositories it sleeps or has sex with. Hence the name, "Bedrock".
Are you feeling confused or enlightened yet? Almost all Linux distros are the same, but this distros puts that question to the test. Just be aware of the many STDs your bedrock can accumulate by using many different repositories.

Nanonymous No.5552 [D]
>>5551
Not free as in freedom, but free as in STDs. I like it.

Nanonymous No.5554 [D]
>>5551
I tried Bedrock Nyla once, it did not work.
It has been improved?

Nanonymous No.5578 [D] >>5595 >>5599 >>5615
>>5341
What reasons do you have for thinking other open source operating system projects haven't also been infiltrated by NSA? Why is OpenBSD more trustworthy than Linux?

Nanonymous No.5595 [D]
>>5578
OpenBSD is more trustworthy because there isn't an army of developers trying to bloat it the fuck up.
And it's not about evading the NSA. You won't be able to if you're a target, unless you airgap. It's about having a system that won't be vulnerable to the newest memebleed attack.

Nanonymous No.5599 [D]
>>5578 Reading Michael W. Lucas's book was enough to convince me openBSD is no gimmick.

>more trustworthy

Thats entirely up to you, but openBSD will teach you to be more competent with file systems, forcing you to learn how to solve your own problem, reading man pages, learning why things work the way they do. I'm still new with openBSD,but it's clear the user has absolute control over their system.

Nanonymous No.5615 [D]
>>5578

Haven't seen any evidence that a BSD has been infiltrated yet.

To be fair though, it's only smoke that shows any infiltration of Linux, not "facts".

Nanonymous No.5628 [D][U][F]
File: 65c5edbfb5a3cd42f70778c5fd8f10b2cb240e83c3d01ecc724dca78bf1b4b93.png (dl) (42.84 KiB)
I had to install Armbian on my A64 board, because I managed to fuck up when trying to install u-boot 2019.07, which takes forever to build btw (actually it never finished and the ssh session froze sometime around 6 hours into the compile). Originally had installed OpenBSD 6.5 on there, but had problems with the ethernet, kept getting watchdog errors and the interface would stop working. Some kind of voltage regulator not set right in dtb file, I guess.

Nanonymous No.5752 [D]
>>1626
>Personal preference is a reason.
Not a rational reason.

Nanonymous No.5753 [D] >>5754 >>5776 >>5881
In this entire thread, with over fifty posts, there has not been a single, good argument favoring the use of an alternative to GNU/Linux. This thread is a mindles, 4chan-tier flamewar.

>OpenBSD is more trustworthy
Proof? Why is OpenBSD more trustworthy than any other Linux distribution? What is the point of using a trustworthy operating system if you computer uses proprietary hardware; I doubt anyone here uses a RISC-V computer. It is childish to think that x200/x220 computers have not been fucked by the triple-letter surveillance agencies. If you want a private computer, cut your ethernet cable; have two computers: one connected to the internet and not connected to the internet.

>Linux's code of conduct
I despise Linux's code of conduct. But it is not just Linux—everything has a tranny-loving code of conduct. The only relevant OS that does not have a tranny-loving code of conduct is OpenBSD. However, not having a tranny-loving code of conduct is a weak reason to favor one operating system over another operating system. OpenBSD's code of conduct is the only reason to use OpenBSD as a desktop. However Gentoo Linux is better as a desktop OS in hundreds of categories over OpenBSD. Having a tranny-loving code of conduct does not imply that the software being written is bad. For now, the tranny-loving code of conduct has only slightly affected the Linux kernel's quality. But we don't know if it was due to the COC; correlation does not imply causation.

My arguments are solely for desktop operating systems.

Nanonymous No.5754 [D]
>>5753
*mindless

Nanonymous No.5774 [D] >>5775
>5753 is this bait?

Nanonymous No.5775 [D]
>>5774
No it is not bait.

Nanonymous No.5776 [D] >>5796
>>5753
>What is the point of using a trustworthy operating system if you computer uses proprietary hardware
https://en.wikipedia.org/wiki/Nirvana_fallacy
>I doubt anyone here uses a RISC-V computer
RISC-V is not even ready yet.
>It is childish to think that x200/x220 computers have not been fucked by the triple-letter surveillance agencies
As far as x86 goes, you have better assurance that this is not the case with x60/x220, because of coreboot and no microcode initialization.
>If you want a private computer, cut your ethernet cable
Not a solution.
>However Gentoo Linux is better as a desktop OS in hundreds of categories over OpenBSD
You say the discussion has "no good argument" and then you proceed to not argument your point. Why is Gentoo better?
>Why is OpenBSD more trustworthy than any other Linux distribution?
The code review method is different from linux. You can access the CVS mailing list and see the audit in realtime. OpenBSD favors correct code, so if you go to the CVS right now you'll see very few new functions added in favor of reviewing the old ones and making it correct/better.
OpenBSD, different from Linux, is not just a kernel. It is a entire operating system. This means they can integrate software and change those, in a way you can't do with linux because the kernel dev team is different from, say, Debian team (or any other distro). For example: if you need to add new functions for privsep, just like OpenBSD did with pledge and unveil, you have to modify the kernel. But it doesn't matter if you modify the kernel but do not apply the privsep measures in the base system (user space software). Because of the nature of OpenBSD this integration was seamless and now nearly every single software inside the base system has pledge/unveil.
OpenBSD has it's own alternative programs too, such as OpenIKED, OpenSSH, OpenSMTPD, OpenNTPD, OpenBGPD, httpd, relayd, acme-client, etc. The cryptography is reviewed (AES-256 on softraid-crypto and signify(1)) and the PRNG is non deterministic (arc4random). The tree is compiled with Clang and has reviews against memory management issues. It has ROP protections and W^X. The pf firewall is know as the best quality firewall ever made (pfSense is based on it, btw).
Most of these security measures appear first on OpenBSD and later on Linux-based operating systems or not at all. Normally only distros with GR-security received those security features.

Nanonymous No.5796 [D] >>6104
>>5776
>Gentoo https://packages.gentoo.org/packages/media-video/ffmpeg
>4.1.4, 101 options (barring cpu_flags ones)

>FreeBSD https://www.freshports.org/multimedia/ffmpeg/
>4.1.4, 91 options

>DragonflyBSD https://github.com/DragonFlyBSD/DPorts/blob/master/multimedia/ffmpeg/Makefile
>4.1.4, 82 options

>NetBSD http://pkgsrc.se/multimedia/ffmpeg4
>4.2, lacking important options (don't see opus or x265, for example) but still 15

>OpenBSD http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/graphics/ffmpeg/Makefile?rev=1.189&content-type=text/x-cvsweb-markup
>4.1.4, no options AT ALL

And I should add that FreeBSD and DragonflyBSD have poudriere and synth (and Ravenports getting its shit together), while Open/NetBSD are basically for binary cucks building occasional ports.
Honestly, this is pretty shameful considering the ridiculous amount of donations OpenBSD gets compared to Net or Dragonfly.

Add to that the lack of modern FS, bad SMP performances, anti-GPL autism and you get "masturbating monkeys".

Nanonymous No.5828 [D]
With any GNU/Linux distribution I don't sacrifice 3/4 of my CPU's preformace. This is important to me as I compile HUGE pieces of software often.

Nanonymous No.5881 [D] >>6103
>>5753
> Why should I use anything but Linux?
Wow, what a dumb question. Nodody's forcing you to do that. And more importantly, what OS you use is of no consequence to others.

Nanonymous No.5998 [D]
OpenBSD drivers for wireless cards lag super far behind current hardware.

I also like using bluetooth headsets and I'm sure bluetooth is a pain in the ass in OpenBSD.

Nanonymous No.6006 [D][U][F] >>6008
File: 2725554e62ea7916579ab5d98ccc2f4bc37824b82654c5be78861e19ace7f9f9.png (dl) (36.31 KiB)
Qubes OS masterrace, I can install any distro I want in muh virtual machines.

Nanonymous No.6008 [D] >>6009 >>6011
>>6006
>can't disprove my arguments in >>4669
>starts spamming Qubmeme in every thread
Huh.

Nanonymous No.6009 [D]
>>6008

When I click on >>4669 it does not take me to anything.

Nanonymous No.6010 [D]
That's because the post is not in this thread

Nanonymous No.6011 [D] >>6013 >>6018
>>6008
I don't use Qubes but I just read that thread and I don't see what the argument is supposed to be. You never explain why the gateway/host getting compromised are realistic threats short of some VM escape vulnerability.
Everyone knows that you're screwed if your host machine gets compromised. That's not news, and it holds true for every system. But an operating system kernel is typically going to be a much larger and more complex program than a hypervisor, and more likely to have vulnerabilities hidden inside.
It would seem to make more sense to use a bare metal hypervisor to handle isolation between sensitive programs than an operating system and I haven't really seen a solid argument against Qubes's architecture yet.

Nanonymous No.6012 [D] >>6013
All OS'es have different use cases. I use Hardened OpenBSD on my server, Funtoo on my home desktop, and Arch/Tails dual boot on my Go Laptop (can still build software with it cuz Stallmun GNU/linux).

Just don't use bloat and spyware. I'm looking at you Windicks.

Nanonymous No.6013 [D] >>6027 >>6157
>>6011
>Everyone knows that you're screwed if your host machine gets compromised.
The hypervisor too. That's the point.
>kernel is typically going to be a much larger and more complex program than a hypervisor
True if you only use one, but that's not the case of Qubes.
>use a bare metal hypervisor to handle isolation between sensitive programs
Not true. As I've said before, the isolation through hypervisor is bloaty. You're just stacking a pile of code above another, instead of actually isolating. If you build strong isolation functions, like pledge(2) or the much better seL4 capabilities, you can get stronger isolation without stacking code and with much simpler methods.
Software virtualization is not meant to be used as secure isolation. It never was. VMs are build to make servers cheaper, so you don't need to buy new hardware.
>I haven't really seen a solid argument against Qubes's architecture yet.
My argument is not just against Qubes, it's about software virtualization as a "security feature".
I would agree with the Qubes architecture if it used other ISA than x86 that supports hardware virtualization (like SPARC or some newer RISC-V).
>>6012
What do you mean by "hardened"? Share your configs...

Nanonymous No.6018 [D] >>6023
>>6011
can you link me directly to the thread. I looked at every OS related thread and could not find it and do not have time to go throu this whole site looking line by line at post numbers.

Nanonymous No.6023 [D]
>>6018
Here:
https://nanochanqwrwtmamtnhkfwbbcducc4i62ciss4byo6f3an5qdkhjngid.onion/g/4669.html#post4727

Nanonymous No.6027 [D] >>6045 >>6075
>>6013
>True if you only use one, but that's not the case of Qubes.
What? Qubes only uses a single hypervisor: Xen.
>My argument is not just against Qubes, it's about software virtualization as a "security feature".
Qubes uses hardware virtualization though.
Xen runs directly on top of hardware without an operating system underneath and it's relatively lightweight compared to a full operating system so it's easier to secure. Most Linux distributions come with millions of lines of pure bloat and zero days are found in the kernel all the time. Monolithic kernel design is shit for security.

Nanonymous No.6033 [D] >>6045
>sel4
vaporware
>RISC-V
vaporware
>SPARC
lol
>What do you mean by "hardened"?
>Share your configs...
oh you're just some dumb kid

Nanonymous No.6045 [D] >>6068
>>6027
>What? Qubes only uses a single hypervisor: Xen.
I meant that in order to run multiple VMs you'll need to execute the same code multiple times. If one vulnerability is found in this code, all other VMs can be compromised.
>Qubes uses hardware virtualization though.
Not on x86. This was already discussed on the other thread:
https://nanochanqwrwtmamtnhkfwbbcducc4i62ciss4byo6f3an5qdkhjngid.onion/g/4669.html#post4743

>relatively lightweight compared to a full operating system
In order to run the binaries (in this case the Tor binary and libevent) you need to run an OS inside Dom0. This means that now you not only have the "millions of lines of pure bloat and zero days" but also the Xen code, which has a history of vulnerabilities:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=xen

>Monolithic kernel design is shit for security.
I agree, but stacking hypervisors does not solve this issue.

>>6033
>vaporware
seL4 and RISC-V is already being used in industry. Read moar:
https://nanochanqwrwtmamtnhkfwbbcducc4i62ciss4byo6f3an5qdkhjngid.onion/g/4908.html

>oh you're just some dumb kid
>"ooh look how I'm such an expert!1!!"
Configs or GTFO. I'm curious of what you call "hardening" on a system that already has the most secure default configs... the maximum you can do is disable some daemons and change some sysctl.

Nanonymous No.6068 [D] >>6075
>>6045
>Not on x86. This was already discussed on the other thread:
Qubes doesn't support x86. Qubes does not run without VT-x and VT-d.
The proof is even in the thread you linked. Try reading your own sources.
https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
I don't understand why you would even link that thread, your post got ripped to pieces later on.

>you need to run an OS inside Dom0.
What is the attack surface though? It's a bit more complicated than more code = more bugs. I think what >>6045 is talking about is having Tor, Firefox, firewall, networking drivers and dom0 all as separate VMs. Your "millions of lines of pure bloat and zero days" is a non-argument if there is no way to trigger said bugs or if exploiting said bugs only gets you access to one isolated VM.

>I agree, but stacking hypervisors does not solve this issue.
Again there is only one hypervisor. What you're doing is splitting functionality across multiple VMs so that one VM getting compromised doesn't derail your whole operation.

>If one vulnerability is found in this code, all other VMs can be compromised.
That's the same deal with any monolithic OS too. What >>6045 is saying though is that Xen is a much smaller codebase so is easier to secure. Xen is 300k sloc (high estimate) and OpenBSD is 3.000.000 sloc (low estimate), they're not even in the same ball park. So even by your own primitive logic Qubes is more secure than OpenBSD.
http://old-list-archives.xenproject.org/archives/html/xen-devel/2008-09/msg00355.html
https://www.csoonline.com/article/3250653/is-the-bsd-os-dying-some-security-researchers-think-so.html

Nanonymous No.6075 [D] >>6077 >>6124 >>6157
>>6068
>Qubes doesn't support x86
You know very well I meant x86_64. Stop being autistic.
>The proof is even in the thread you linked.
There's no proof. The article only talks about SLAT, which is only for memory virtualization. Hardware assisted virtualization is different than complete hardware 'virtualization' (such as a coprocessor).
They also allow Intel ME and FSP to run on their "certified hardware", which is bullshit. I've already expressed this on the thread linked:
https://nanochanqwrwtmamtnhkfwbbcducc4i62ciss4byo6f3an5qdkhjngid.onion/g/4669.html#post4981

>your post got ripped to pieces
All arguments were addressed.
>Your "millions of lines of pure bloat and zero days" is a non-argument
I was ironically quoting the other anon >>6027
>What you're doing is splitting functionality
That's the point. Basically stacking code above code.
>That's the same deal with any monolithic OS too.
It is and I agreed with it on the previous post. The point is that you can have the same isolation without the bloat.
>Xen is 300k sloc (high estimate) and OpenBSD is 3.000.000 sloc (low estimate)
You're quantifing the whole OpenBSD there. The kernel is much simpler. Also, as I said before, with Xen you will replicate the instruction each time you run a new VM. Not only the Xen code, but also the firmware-based features it uses from Intel, which are a complete blackbox. On OpenBSD the kernel simply has rules to isolate (using pledge and unveil) and protect the memory (ROP, W^X, etc).

Nanonymous No.6077 [D]
>>6075
Xen runs just fine on a corebooted mobo.

Nanonymous No.6103 [D]
>>5881
It is of consequence actually, if everyone used Winblows then a consensus reality of turdtastic proportions would be created!!!!!
STOP ACTING LIKE OR EVEN IMPLYING THAT SHIT OS'S (or the use of them) ARE/IS OKAY!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Nanonymous No.6104 [D]
>>5796
Why are compile time options so important?
USE flags are a huge pain in the ass.

Nanonymous No.6124 [D] >>6128
>>6075
>There's no proof.
What's this then?
>One of the most important security improvements that we plan to introduce with the release of Qubes 4 is to ditch paravirtualization (PV) technology·

>The article only talks about SLAT
Did you read past the first line?
>Of course, to be compatible with Qubes OS, the BIOS must properly expose all the VT-x, VT-d, and SLAT functionality

>Hardware assisted virtualization is different than complete hardware 'virtualization' (such as a coprocessor).
Obviously you were talking about some shit you made up which happens to have the same name as things that actually exist. My mistake.

>They also allow Intel ME and FSP to run on their "certified hardware"
So you're admitting that Qubes is secure and now moving goal posts to "muh Intel ME Mossad-Illuminati backdoor ree ree ree". If you don't trust Intel then don't use Intel hardware. That's just your autistic threat model though, don't project it onto everyone else.

>Not only the Xen code, but also the firmware-based features it uses from Intel, which are a complete blackbox.
Hypervisors emulate hardware so they can't use the platform firmware for whatever random hardware they run on, they have to emulate it. For someone with such strong opinions on virtualization you really don't seem to have any understanding of the fundamentals.
https://github.com/coreboot/seabios
>with Xen you will replicate the instruction each time you run a new VM
With a kernel you will replicate the instruction each time you run a new process.
What the actual fuck is your point?

>On OpenBSD the kernel simply has rules to isolate (using pledge and unveil) and protect the memory (ROP, W^X, etc).
Yeah OpenBSD doesn't use code it all runs on magic. Only Xen has "instructions" right.

>That's the point. Basically stacking code above code.
You keep ree'ing about "bloat" but actually the point is, attack surface.
You think that having hypervisor + guest VM somehow makes everything 2x insecure. That's not how it works.
The initial attack surface is the same as non-virtualized system, outside world --> guest OS
Then userspace guest OS --> root/kernel space guest OS
Then root/kernel space guest OS --> hypervisor
Note that bugs in the hypervisor don't help an attacker attack the guest OS at all.
The hypervisor is adding defense in depth, not increase attack surface.

Nanonymous No.6128 [D][U][F] >>6144
File: 749ced3d3cf1a930e361224409e1c3088d355664d3dff3bbf6a564a4d9097227.jpg (dl) (188.85 KiB)
>>6124
You misunderstood what I'm saying about Qubes.
>You think that having hypervisor + guest VM somehow makes everything 2x insecure.
I never said that. What I said is that you can achieve better security using strong isolation, without needing virtualization.
>So you're admitting that Qubes is secure
Of course Qubes is secure (as far as the hardware goes). I never said it wasn't. This discussion started because a anon asked for a secure system and suggested himself Whonix/Qubes. I recommended OpenBSD instead, for the reasons we have been argumenting. I never said Qubes is insecure or that software virtualization is completely useless. In fact, Qubes is probably one of the most secure linux-based systems (together with Alpine).
>now moving goal posts to "muh Intel ME
This was one of my points since the beginning. Go read the thread linked above. Virtualization on x86_64 requires trusting their extensions (Intel VT and AMD-V). The VMM runs bellow ring 0 and what Intel calls "VMCS" (Virtual Machine Control Structue) runs the instructions to communicate with the guest. So you're basically increasing your reliance over two companies that have shown previously that cannot be trusted.
Proper isolation doesn't increase your trust over them, in the sense that you don't require new hardware/firmware features.
This document explain many possible attacks:
http://ss.pku.edu.cn/vs/style/resources/Hardware%20virtualization%20technology%20and%20its%20security.pdf

Even Qubes devs are aware of these:
http://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf

They demonstrated that hardware without 'Interrupt Remapping' was vulnerable. A quote from the paper:
>"We shall point out it's not the first time Intel is selling a half-baked security solution without informing customers about it."

As a kinda-related example: remember the Intel SGX and how they promised it was secure? It turned out very bad for them:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00117.html
https://en.wikipedia.org/wiki/Software_Guard_Extensions#Prime+Probe_attack
>If you don't trust Intel then don't use Intel hardware.
I don't. I'm currenly using AMD, but they are also not good enough (and we can't remove the PSP microcode).
>talking about some shit you made up
You're running the same instructions on the same circuit. You can achieve only a certain amount of isolation. What I meant by "complete hardware 'virtualization'" was the use of another physical processor. Such as what Keystone does:
https://keystone-enclave.org/
>Hypervisors emulate hardware so they can't use the platform firmware
>they can't use the platform firmware
Of course they can. In special the microcode.
https://twitter.com/_markel___/status/898631448361652228
>With a kernel you will replicate the instruction each time you run a new process.
Not the isolation mechanism. Pledge works as a 'firewall'. The software promises to use only one set of funcions (filesystem access, network access, etc). Same for unveil(2). If the software tries to make anything other than it promissed the kernel will simply kill the process. There's no new instructions made, unlike virtualization. Btw, this is way OpenBSD runs even on machines with 200MB of RAM and Qubes requires at least 4GB.
Capabilities is a even better way of doing that, such as what Capsicum and seL4 does.
https://www.cl.cam.ac.uk/research/security/capsicum/

Nanonymous No.6139 [D]
Why the hell would you dual boot Kali and not run it with a live usb or as a virtual machine?

Nanonymous No.6144 [D] >>6157 >>6193
>>6128
>Virtualization on x86_64 requires trusting their extensions (Intel VT and AMD-V)
You already trust Intel 100% by using their hardware so this is a non-argument.

>This document explain many possible attacks:
I only see one attack (interrupt remapping) which obviously only effects VMs with a physical device attached via pci-passthrough. It's not a general way to break out of any VM like you're implying.

>You're running the same instructions on the same circuit. You can achieve only a certain amount of isolation.
OpenBSD is also running "same instructions on the same circuit". You're comparing virtualization to having 2 physical machines and then concluding OpenBSD is more secure. That's some pretty lulzy logic, friend.

>What I meant by "complete hardware 'virtualization'" was the use of another physical processor. Such as what Keystone does:
Are you sure? Looks like TrustZone for RISC-V to me. I don't see anything about another physical processor.
https://docs.keystone-enclave.org/en/latest/Getting-Started/How-Keystone-Works/Keystone-Basics.html#overview
Enclaves are not the same thing as virtualization anyway. They're for running a few lines of sensitive code in a restricted environment, they can't run a full general purpose operating system or even an interactive application.

>Of course they can. In special the microcode.
Microcode is not firmware. Since only Intel signed microcode can run on Intel processors, anything bad that microcode can do is a non-argument. If you don't trust Intel then don't run Intel hardware.

>Not the isolation mechanism.
>There's no new instructions made, unlike virtualization.
You're saying processor instructions that OpenBSD use are secure and processor instructions that Qubes uses are backdoored because reasons. I'm not buying it. If you don't trust Intel then don't use Intel hardware.

>Pledge works as a 'firewall'
Pledge is not comparable to the isolation Qubes and VMs give you.
Pledge is code added by software authors to their own code.
If you don't trust the software to start with then pledge is completely useless.
The point of Qubes is that you as a user are in control of how things are isolated.
I can run shitty-almost-malware programs like skype or firefox inside a virtual machine and be confident that it cannot steal my files or keystrokes or whatever.
The same can't be said about OpenBSD because OpenBSD has no way of containing untrusted code. The only way Pledge can help is if you modify the untrusted application to add pledge calls (assuming you have the source code and understand what it's doing well enough to Pledge it).
Stop comparing niche OpenBSD gimmicks to real security isolation.

>There's no new instructions made, unlike virtualization. Btw, this is way OpenBSD runs even on machines with 200MB of RAM and Qubes requires at least 4GB.
The reason Qubes requires a lot of diskspace is because the guests are based on Fedora Linux. It has nothing to do with VT-x or VT-d.

>Capabilities is a even better way of doing that, such as what Capsicum and seL4 does.
Capsicum is just as useless as pledge. It's code software authors add to their own code to protect the user from 3rd party exploits. The user has no control.

Nanonymous No.6157 [D] >>6176
>>6144
At this point you're just trolling.
>You already trust Intel 100% by using their hardware so this is a non-argument.
You're increasing you're reliance on them, pushing more code into microcode control. Just because the platform is shitty is doesn't mean you shouldn't prevent it from doing even more nasty shit. And this goes not only for virtualization extensions, but also other Intel "features" (hyper-threading, for example).
>It's not a general way to break out of any VM like you're implying.
I didn't imply that. I used it to show you how even the Qubes devs are aware of virtualization issues and how their model requires you to trust even more on Intel's shit hardware.
Also, you completely ignored the other document linked, which has other kinds of possible attacks.
>You're comparing virtualization to having 2 physical machines and then concluding OpenBSD is more secure.
How intelectually dishonest of you. This point about 'true virtualization' started as a side-topic of the discussion. I was not argumenting for OpenBSD in this case, but what a possible solution for the future would be like. Let me quote (from >>6013 and >>6075)
>"I would agree with the Qubes architecture if it used other ISA than x86 that supports hardware virtualization (like SPARC or some newer RISC-V)."
>"Hardware assisted virtualization is different than complete hardware 'virtualization' (such as a coprocessor)."

>Are you sure? Looks like TrustZone for RISC-V to me
The first few lines on the link already explains it:
>"Keystone is an open framework for architecting trusted execution environments (TEEs) based on hardware enclaves."
>>"hardware enclaves"
>"Enclaves are environments isolated from the untrusted OS and other enclaves. Each enclave is given a private physical memory region which is accessible by only the enclave and SM."

>they can't run a full general purpose operating system
Because everyone in high-assurance computing knows you shouldn't be running a full OS as a isolation mechanism. It's just unnecessary overhead and won't protect more, will only create more complexity.
>Microcode is not firmware.
U wat? Of course it is, are you kidding me? Microcode is just software emulating physical instructions. It runs even before the init code and has access to everything. Anything that goes between the IC and the bootloader is firmware.
>anything bad that microcode can do is a non-argument.
Yeah, let's just blind ourselves and pretend nothing bad will happen.
>If you don't trust Intel then don't run Intel hardware.
Tell this to Qubes "certified hardware".
>processor instructions that Qubes uses are backdoored because reasons.
I never said it was backdoored. I said you need to trust them. This means that, if they make something wrong on their microcode or RTL, you're fucked. And, as Intel and AMD have shown before, they cannot be trusted.
>I'm not buying it.
That's fine, I'm not selling you anything. I think we've reached the discussion plateau now. Anything after that will be ad-infinitum.
>If you don't trust the software to start with then pledge is completely useless.
The software running the file shouldn't be vulnerable to begin with. Isolation is necessary to ensure confidentiality of information and other protections beyond what the software can do. Not to fill the holes in bad software.
>user are in control of how things are isolated.
The user shouldn't be in control of that. The system should be secure by default. As history have shown, users are idiots and will eventually fuck everything up.
>OpenBSD has no way of containing untrusted code.
You don't seem to understand the OpenBSD security, them.
>Qubes requires a lot of diskspace is because the guests are based on Fedora Linux.
I was talking about RAM, not diskspace.
>Capsicum is just as useless as pledge.
Heh.

Nanonymous No.6160 [D] >>6164
Why is OpenBSD more trustworthy?

In a nutshell, because of Theo. He is an utter tyrant and OpenBSD is small enough he sees almost every change that goes in. So it comes down to trusting that one guy. Compare and contrast how many 'key' developers have to be trusted in the chain of a Linux distro.

Nanonymous No.6164 [D]
>>6160
>small enough he sees almost every change that goes in.
Everyone can see the changes in realtime. You just have to access the CVS mailing list or the official twitter @Openbsd_src.
Not only Theo see the changes, but all the 30+ developers and the whole openbsd community.
You don't want to use OpenBSD? I don't give a single fuck. But don't go out shitting on other peoples work. They make a great job, much better than 90% of other open source projects. In fact it's so good that most people use their software and don't even know.

Nanonymous No.6176 [D] >>6189
>>6157
>At this point you're just trolling.
Just because you're upset doesn't mean I'm trolling. It means a small part of your brain is beginning to understand that you're wrong and doesn't like it. It's called Cognitive Dissonance.

>you completely ignored the other document linked
I can't access it over Tor. It would be better for you discussion anyway if you could paraphrase instead of just linking to technical papers you basically don't understand and then saying "HA!".

>The first few lines on the link already explains it:
Existing "enclave" technology like SGX and TrustZone are just extensions to the main processor. You said this Keystone thing is a separate processor but the evidence doesn't support that.

>Because everyone in high-assurance computing knows you shouldn't be running a full OS as a isolation mechanism.
Citation needed. Presumably "everyone" is OpenBSD fanbois who are in denial about its limitations.

>U wat? Of course it is, are you kidding me?
Microcode is microcode, that's why it has it's own name.

>I never said it was backdoored. I said you need to trust them. This means that, if they make something wrong on their microcode or RTL, you're fucked. And, as Intel and AMD have shown before, they cannot be trusted.
I realize English isn't your first language.
You were saying that the hardware which operating systems like OpenBSD rely on for security e.g. MMU or protection rings, are old and should be bug free and the hardware which Qubes relies on e.g. VT-x or VT-d is newer and might have more bugs?
That Invisible Things paper is from 2011 though. There was like 1 generation of Intel CPUs with this VT-d flaw, so Intel basically fixed it straight away. Any other virtualization bugs you want to discuss? Or are you just going to go back to "virtualization bad ree ree ree"?

>The software running the file shouldn't be vulnerable to begin with.
That's only a limitation of OpenBSD. On other platforms you can safely isolate bad code without modifying it to make it "trusted". That's what virtual machines and Qubes can do.

>The user shouldn't be in control of that. The system should be secure by default.
Again, you are just projecting OpenBSD limitations onto the rest of the world.
>OpenBSD: Most secure OS in the world (as long as you only run trusted code)
25 years and people are still fooled by this meme OS.

Nanonymous No.6188 [D] >>6189
You missed my point. Having it small enough one guy can see almost every change is a good thing. Compare to a Linux distro. Hell, Linus hasn't actually looked at most patches to Linux personally in over a decade. It is just too big for one mind to follow the pace of change to Linux. Multiply that by a distro like Debian or Fedora.

But the actual OpenBSD kernel and core utils can still be grasped by one mind. Very less likely to have one bad apple in a barrel of devels spread over the Internet stick a nasty in.

Nanonymous No.6189 [D] >>6200
>>6176
>upset
>Cognitive Dissonance
You're the one conveniently dropping all my important points and then calling some 'cog dissonance' bullshit. I do not discuss to "win". I discuss because I have confidence of what I'm saying and I want other to prove me wrong.
>I realize English isn't your first language.
What this have to do with anything?
>paraphrase instead of just linking
Here:
>"Driver domains are similar to traditional VMs [without hardware extensions], but they are assigned the privileges of choosing devices such as network card, disk controller etc."
>"We can attempt to get the complete control of the whole system by the mean of such a driver domain. In this attack scenario, we suppose that attackers have managed to get a full control of a certain driver domain."
And then he proceeds to explain how the attack works.
>are just extensions to the main processor
Humm... you might be right here. But, in the case of Keystone, it has physical separation too, as quoted on the other post ("Each enclave is given a private physical memory region").
>Citation needed.
All high-assurance systems require pass through Commom Criteria. This criteria have no mention whatsoever of virtualization. I could only find one Dutch company that sells laptops with virtualization-based 'security' for military contractors (they are "BND approved" or something like that). Most high-assurance systems in the last decade have focused on isolation mechanisms with formal verification, without virtualization. This is the case of software (seL4, CERTIKOS, Genode) and hardware (lowrisc, bluespec and galois). High level military contractors are also not interested in virtualization as a security feature. You can see the DOVER project from Draper, for example. Or how all the projects on the SSITH program from DARPA were not based on virtualization:
https://securehardware.org/

>Presumably "everyone" is OpenBSD fanbois
OpenBSD cannot be considered "high-assurance". In fact OpenBSD is very insecure when compared to military systems.
>Microcode is microcode
Microcode is firmware. Any software bellow the bootloader can be considered firmware.
But the fact is that it doesn't matter. You can call microcode if you want, as long as we understand the concept of what it is.
>MMU or protection rings
In order to post to x86 you have to use these. The argument is that you shouldn't increase your reliance over these retarded extensions. OpenBSD, by default, disables many of these Intel and AMD extensions.
>are old and should be bug free
Not really. They are probably full of bugs. The point is that you're not increasing this amount by adding other extensions on top of it.
>That Invisible Things paper is from 2011 though.
I know. Which is why I quoted only the last bit about how "Intel is selling a half-baked security solution".
>limitation of OpenBSD
It's a security model, not limitation. If you don't want to be exploited, don't run shit software. This is "Security 101".
>>6188
Oh, I get it. My bad. I agree with you. Linux is on the edge of unmaintainability, because of their added complexity over the years.

Nanonymous No.6193 [D]
>>6144
*spots random b8 in middle of thread*
>>Virtualization on x86_64 requires trusting their extensions (Intel VT and AMD-V)
>You already trust Intel 100% by using their hardware so this is a non-argument.
It also requires the extensions to be properly implemented, which they aren't. Why do you want virtualization anyway? So you can run a shit script kiddie OS like Linux or Windows to run muh legacy software?

Nanonymous No.6200 [D]
>>6189
<In order to post to x86
>In order to port to x86
Fix.

Nanonymous No.6496 [D]
Does anyone here use windows?

Nanonymous No.6532 [D][U][F] >>6548
File: 5df7276d0e9f3e5233f0df8e671b503b490d56c86fab69346c17902224e469c0.jpg (dl) (222.62 KiB)
>>2011
Pacifists have never in history achieved anything, so with that in mind, we can start being a little aggressive.
You can spam/shitpost/bait/etc in discussion places where java, windows, mac, arch linux, ubuntu, freebsd, facebook, systemd, any other one of the millions of tumors infesting computing are discussed.
Mailing lists are specially vulnerable and rely on obscurity to survive, because mail is trash.
Don't pin it on what you want to save because that'll have the opposite effect. Just make even talking about this stuff such a pain in the ass that people drop discussion, and eventually the subject itself.
You're not propping up good things, but you're dragging down bad things, which has the same effect.

That's what I do.

Nanonymous No.6548 [D] >>6558
>>6532
What is wrong with Arch tbh? No argument on rest in your list.

Nanonymous No.6558 [D]
>>6548
Arch uses systemd.

Nanonymous No.6823 [D][U][F]
File: 72c9a743c11a5a2e7e38359115f81457bd3e6370379123b1de8236480a95ad1b.jpg (dl) (510.74 KiB)
>use anything but linux
Options. Relying on Linux for everything in your life is a bad move if you're thinking in opsec terms. Since if Linux ever goes to shit and it might then you have your dick in your hand looking for something that doesn't fuck you over.
The BSDs are nice alternatives with good development, and OpenBSD is pushed for good reason. Personally I use obsd for a lot but I've been meaning to try out Ghost and Dragonfly for a while now. However, the BSDs are redundant upon a niche that Linux has filled.
So if you want something different I would look into non-unix os's like React/GreenTea and Capros since that is escaping the paradigm most OS's get which is if its not Linux it's Unix and Unix is almost always exactly the same.
To make it simple, Linux does almost everything and will with time be able to do everything Windows and OSX do. The bad thing about that is that there is a good chance that Gnu/Linux will get nigger'd so hard it will turn into a frankenstein version of Windows and the OS will lose a lot of its luster through bloat.