Re: AI-Driven Security Enhancements for OpenBSD Kernel
Alfredo Ortega writes: > Hi! Sorry if this is not the appropriate list to share openbsd-related > projects (perhaps it was misc?) > > I want to inform you about this project about using LLMs to inject > thousands of security checks into the OpenBSD kernel automatically. > > I'm sharing the first results at > https://github.com/ortegaalfredo/openbsd-hardcore , where I used the > automated tool to add thousands of additional security checks to the > netinet/netinet6 stack of kernel 7.5. My plan is to continue this > process with other subsystems, which will be largely automated, and to > improve the tool so it can be used in other projects. The tool is not > yet public but the idea is quite simple and can be implemented easily. > This is a demonstration of the capabilities of LLMs as a > code-refactoring tool. I had an idea in this space which should have a much better ROI and chances of acceptance. I'd start by grabbing a syzkaller report from https://syzkaller.appspot.com/openbsd. Ideally you want something with a reproducer. You should probably verify the repro still works. Then feed whatever data you find relevant into the magic box and ask it to give you a fix for the problem. Some relevant pieces would include the panic stack trace and the code around it. Since you know it is a real problem and have a way to verify the proposed solution, people will take you more seriously. When you have the first real fix - do let us know, I'll personally be very excited to look at the patches. Thanks Greg P.S. As much as I'd love for you to focus on OpenBSD, you'll find many more bugs to fix in other systems there.
Re: Do I need to wipe encrypted dual boot NVME before installation
> > I have a dual boot Devuan/OpenBSD, I wrote random data on my > > drive Whoy wuld you "write random data" on a drive you are about to reinstall? > > and then install the OSes, both are encrypted. > > Now, I want to remove this dual boot to have only OpenBSD > > and use it as a daily driver. Sure. > > My plan for this is to boot a GNU/Linux live usb, erase LUKS keys > > with cryptsetup command, use the wipefs command to erase LUKS > > header and reinstall OpenBSD with full disk encryption. > > Is it secure enough ? Do I need to do something with OpenBSD > > encrypted data as I have to with the LUKS keys/header on GNU/Linux ? Why would you complicate it like that? Just install OpenBSD anew.
No wake from sleep on Carbon X1 Thinkpad
Hello Misc, I occasionally have a problem in which my laptop doesn't wake from sleep. The power LED just keeps blinking indefinitely when I open the lid. Closing the lid and opening it again doesn't seem to help. The machine doesn't respond to a ping from the network. The occurrence of this is random -- I can't put my finger on what might be causing it. Openbsd is currently running v7.4 on v9 of an X1, but it has happened previously on X1 versions 4 and 5 with earlier versions of the OS. I have to hold the power button down until the machine turns off and then restart it. During boot there are a bunch of fsck corrections, but I haven't noticed anything fatal. However, this makes me nervous for obvious reasons. The machine can be either on battery or wall power as I recall. The battery is not near being depleted. Has anybody else experienced this? Any suggestions for diagnostics or fixes? Dave Raymond David J. Raymond david.raym...@nmt.edu http://kestrel.nmt.edu/~raymond
Can anyone in Alberta sign into their health records with OpenBSD?
I'm still using 7.4, but wondering if anyone from Alberta is able to use any version of OpenBSD and any browser to sign in to access their Health Records at: https://myhealth.alberta.ca/uam/pages/Dashboard.aspx
Re: Updated Operations Research tools
Thank you Ronald! Ive been exploring Operations Research tools every now and then, always relying on Linux; great to know we have some of those tools in OpenBSD as packages, will definitely take a look in the future. I'm running -current, far from being a "guru" in OR and OpenBSD, but if you need some help with testing in the future let me know. Regards Michel On Mon, 10 Jun 2024 at 10:00 PM Ronald Dahlgren wrote: > I am excited to announce a number of software packages that have been > updated to work on OpenBSD. > > 1. COIN-OR (coin-or.org) - The CBC solver was failing to build due to a > casting error. Pull request 653 (https://github.com/coin-or/Cbc/pull/653) > corrects this issue; > 2. HiGHS solver (https://ergo-code.github.io/HiGHS/stable/) - failed to > build due to the `strerror_r` prototype. Pull request 1783 ( > https://github.com/ERGO-Code/HiGHS/pull/1783) corrects this. > 3. Google or-tools (https://developers.google.com/optimization/) - > several compilation issues prevented building the associated Python > package. Pull requests 4257 (https://github.com/google/or-tools/pull/4257), > 4259 (https://github.com/google/or-tools/pull/4259), and 4266 ( > https://github.com/google/or-tools/pull/4266) correct each of these > problems. > > With these changes introduced, we can now run the relevant solvers and > python packages on an OpenBSD system! I'm so happy I was able to give back > to the OpenBSD community in this way. > > Ron >
Re: nginx optimizing
As https is default webserver of OpenBSD I think you out of luck. But you can start from here: https://blog.nginx.org/blog/performance-tuning-tips-tricks remembering that you should test settings one by one as some of them eg. "aio" are not compatible with OpenBSD. Jun 15, 2024 13:52:50 Corey Hickman : > Hello > > Is there any doc for optimizing nginx on openbsd server? for example, to get > better performance (QPS, throughput etc).
Re: booting and RAID-5
On Sat, 15 Jun 2024 14:05:07 +0100, Marco van Hulten wrote: > > Would a good approach be to create a root device on one disk (and maybe > altroots on one or both of the others) and use the rest of all disks as > RAID-5 device? Or is there a good reason to boot from a disk separate > from the envisioned RAID-5 configuration? > Why not use dedicated RAID-1 for / instead? -- wbr, Kirill
booting and RAID-5
Hello, I got a new amd64 system with 3 NVMe disks of each 2 TB, with the idea to put them in RAID-5. I did not realise until now that one cannot boot from RAID-5. Would a good approach be to create a root device on one disk (and maybe altroots on one or both of the others) and use the rest of all disks as RAID-5 device? Or is there a good reason to boot from a disk separate from the envisioned RAID-5 configuration? Thanks, Marco
nginx optimizing
Hello Is there any doc for optimizing nginx on openbsd server? for example, to get better performance (QPS, throughput etc). Thanks.
Re: Do I need to wipe encrypted dual boot NVME before installation
Everything is clear now. Even if I messed up with the dd command I understood what I needed to do : With GNU/Linux live : # cryptsetup erase /dev/nvme0n1p3 (my LUKS partition) # wipefs -a /dev/nvme0n1p3 With OpenBSD shell : # sysctl hw.disknames # cd /dev # sh MAKEDEV sd0 (my encrypted device) # dd if=/dev/urandom of=/dev/rsd0c bs=1m count=1 Like that I have a clean device ready to welcome OpenBSD. Thanks you. -- kz
Re: Do I need to wipe encrypted dual boot NVME before installation
If I understand your question correctly, you trying to ensure that the encryption key for your existing OpenBSD installation is specifically destroyed before re-using the disk, to protect against the possibility that somebody with access to the disk could use that key to decrypt the softraid crypto partition before the encrypted data has been overwritten simply due to regular usage of the disk after re-installation. There is no specific tool in the OpenBSD base system to do this. However the key material for an OpenBSD softraid cypto partition is stored along with the other softraid metadata at the beginning of the partition, so it can quickly and easily be overwritten using dd to write random data to the first megabyte or so. This is what I was looking for. You understood my question perfectly. I just have to know how to overwrite softraid metadata of my partition because it's not a the begining of the drive so I guess it's not the first megabyte. Thanks. -- kz
Re: info about cpu in dmesg
On 15.6.2024. 7:54, Rob Schmersel wrote: > On Fri, 14 Jun 2024 22:20:55 +0200 > Hrvoje Popovski wrote: > >> Hi all, >> >> I have question about cpu output in dmesg. >> I have Fujitsu RX2530m4 with 8 core Intel(R) Xeon(R) Gold 6134 and in >> dmesg I've noticed that core are 0,4,5,7,18,19,21,22 >> >> without HT >> cpu0: smt 0, core 0, package 0 >> cpu1: smt 0, core 4, package 0 >> cpu2: smt 0, core 5, package 0 >> cpu3: smt 0, core 7, package 0 >> cpu4: smt 0, core 18, package 0 >> cpu5: smt 0, core 19, package 0 >> cpu6: smt 0, core 21, package 0 >> cpu7: smt 0, core 22, package 0 >> >> with HT >> cpu0: smt 0, core 0, package 0 >> cpu1: smt 0, core 4, package 0 >> cpu2: smt 0, core 5, package 0 >> cpu3: smt 0, core 7, package 0 >> cpu4: smt 0, core 18, package 0 >> cpu5: smt 0, core 19, package 0 >> cpu6: smt 0, core 21, package 0 >> cpu7: smt 0, core 22, package 0 >> cpu8: smt 1, core 0, package 0 >> cpu9: smt 1, core 4, package 0 >> cpu10: smt 1, core 5, package 0 >> cpu11: smt 1, core 7, package 0 >> cpu12: smt 1, core 18, package 0 >> cpu13: smt 1, core 19, package 0 >> cpu14: smt 1, core 21, package 0 >> cpu15: smt 1, core 22, package 0 >> >> My understanding is that : >> package - cpu socket >> core - physical cpu cores >> smt - core thread >> cpuX - name of core ? >> >> I thought that in my case core should be from 0 to 7 ? >> > <--- snip dmesg ---> > > The Xeon gold 6000 series can have upto 22 cores. The 6134 just has > some of those cores disabled > Hi, makes sense, tnx ..
Re: Do I need to wipe encrypted dual boot NVME before installation
On Sat, Jun 15, 2024 at 09:01:51AM +, lafermedesanim...@posteo.net wrote: > I have a dual boot Devuan/OpenBSD, I wrote random data on my > drive and then install the OSes, both are encrypted. > Now, I want to remove this dual boot to have only OpenBSD > and use it as a daily driver. > My plan for this is to boot a GNU/Linux live usb, erase LUKS keys > with cryptsetup command, use the wipefs command to erase LUKS > header and reinstall OpenBSD with full disk encryption. > Is it secure enough ? Do I need to do something with OpenBSD > encrypted data as I have to with the LUKS keys/header on GNU/Linux ? If I understand your question correctly, you trying to ensure that the encryption key for your existing OpenBSD installation is specifically destroyed before re-using the disk, to protect against the possibility that somebody with access to the disk could use that key to decrypt the softraid crypto partition before the encrypted data has been overwritten simply due to regular usage of the disk after re-installation. There is no specific tool in the OpenBSD base system to do this. However the key material for an OpenBSD softraid cypto partition is stored along with the other softraid metadata at the beginning of the partition, so it can quickly and easily be overwritten using dd to write random data to the first megabyte or so.
Re: Do I need to wipe encrypted dual boot NVME before installation
On Sat, 15 Jun 2024 10:01:51 +0100, lafermedesanim...@posteo.net wrote: > > I have a dual boot Devuan/OpenBSD, I wrote random data on my > drive and then install the OSes, both are encrypted. > Now, I want to remove this dual boot to have only OpenBSD > and use it as a daily driver. > My plan for this is to boot a GNU/Linux live usb, erase LUKS keys > with cryptsetup command, use the wipefs command to erase LUKS > header and reinstall OpenBSD with full disk encryption. > Is it secure enough ? Do I need to do something with OpenBSD > encrypted data as I have to with the LUKS keys/header on GNU/Linux ? > Probably I don't understand your attack vecor, but where I stay if you reinstall with reformat whole disk, old data on the disk will be replaced or not, but it shouldn't create an issue, should it? -- wbr, Kirill
Do I need to wipe encrypted dual boot NVME before installation
Hi, I have a dual boot Devuan/OpenBSD, I wrote random data on my drive and then install the OSes, both are encrypted. Now, I want to remove this dual boot to have only OpenBSD and use it as a daily driver. My plan for this is to boot a GNU/Linux live usb, erase LUKS keys with cryptsetup command, use the wipefs command to erase LUKS header and reinstall OpenBSD with full disk encryption. Is it secure enough ? Do I need to do something with OpenBSD encrypted data as I have to with the LUKS keys/header on GNU/Linux ? Thanks, Kz
Re: info about cpu in dmesg
On Fri, 14 Jun 2024 22:20:55 +0200 Hrvoje Popovski wrote: > Hi all, > > I have question about cpu output in dmesg. > I have Fujitsu RX2530m4 with 8 core Intel(R) Xeon(R) Gold 6134 and in > dmesg I've noticed that core are 0,4,5,7,18,19,21,22 > > without HT > cpu0: smt 0, core 0, package 0 > cpu1: smt 0, core 4, package 0 > cpu2: smt 0, core 5, package 0 > cpu3: smt 0, core 7, package 0 > cpu4: smt 0, core 18, package 0 > cpu5: smt 0, core 19, package 0 > cpu6: smt 0, core 21, package 0 > cpu7: smt 0, core 22, package 0 > > with HT > cpu0: smt 0, core 0, package 0 > cpu1: smt 0, core 4, package 0 > cpu2: smt 0, core 5, package 0 > cpu3: smt 0, core 7, package 0 > cpu4: smt 0, core 18, package 0 > cpu5: smt 0, core 19, package 0 > cpu6: smt 0, core 21, package 0 > cpu7: smt 0, core 22, package 0 > cpu8: smt 1, core 0, package 0 > cpu9: smt 1, core 4, package 0 > cpu10: smt 1, core 5, package 0 > cpu11: smt 1, core 7, package 0 > cpu12: smt 1, core 18, package 0 > cpu13: smt 1, core 19, package 0 > cpu14: smt 1, core 21, package 0 > cpu15: smt 1, core 22, package 0 > > My understanding is that : > package - cpu socket > core - physical cpu cores > smt - core thread > cpuX - name of core ? > > I thought that in my case core should be from 0 to 7 ? > <--- snip dmesg ---> The Xeon gold 6000 series can have upto 22 cores. The 6134 just has some of those cores disabled
