Re: sysctl for meltdown and mds mitigations
Fair enough. Thanks for the information. I will look at doing some profiling to figure out what the routing bottleneck is instead of going off a hunch. On Tue, May 26, 2020 at 5:13 PM Theo de Raadt wrote: > > And by the way, if it is *just routing* -- in the kernel -- then > neither Meltdown NOR MDS are involved in what you perceive as > performance problems, since those only happen upon *context switch > to/from userland*. > > As I was saying... we don't want to provide these knobs for people who > cannot make the correct decisions because they don't actually understand > the security issues. > > > Elias Carter wrote: > > > Would there be any interest in having a sysctl to enable/disable > > meltdown and mds mitigations? > > I was poking around 'sys/arch/amd64/amd64/cpu.c' and it appears that > > these mitigations are currently hardcoded. > > > > The benefit of having these sysctl's is that they would allow users to > > disable the mitigations for a tradeoff in performance. For example, I > > have an OpenBSD router only running dhcpd and pf which is struggling > > to keep up with a gigabit connection. Given that the system is only > > doing routing, I would assume it would be relatively low risk to > > disable the mitigations to get better performance. > > > > Thoughts? > > Elias > >
Re: sysctl for meltdown and mds mitigations
And by the way, if it is *just routing* -- in the kernel -- then neither Meltdown NOR MDS are involved in what you perceive as performance problems, since those only happen upon *context switch to/from userland*. As I was saying... we don't want to provide these knobs for people who cannot make the correct decisions because they don't actually understand the security issues. Elias Carter wrote: > Would there be any interest in having a sysctl to enable/disable > meltdown and mds mitigations? > I was poking around 'sys/arch/amd64/amd64/cpu.c' and it appears that > these mitigations are currently hardcoded. > > The benefit of having these sysctl's is that they would allow users to > disable the mitigations for a tradeoff in performance. For example, I > have an OpenBSD router only running dhcpd and pf which is struggling > to keep up with a gigabit connection. Given that the system is only > doing routing, I would assume it would be relatively low risk to > disable the mitigations to get better performance. > > Thoughts? > Elias >
Re: sysctl for meltdown and mds mitigations
Absolutely no interest at all. Not interested in the source code complexity (it is worse than you think), nor do we believe people's ability to make correct decisions in regards to complicated security issues. dhcpd, you say... Elias Carter wrote: > Would there be any interest in having a sysctl to enable/disable > meltdown and mds mitigations? > I was poking around 'sys/arch/amd64/amd64/cpu.c' and it appears that > these mitigations are currently hardcoded. > > The benefit of having these sysctl's is that they would allow users to > disable the mitigations for a tradeoff in performance. For example, I > have an OpenBSD router only running dhcpd and pf which is struggling > to keep up with a gigabit connection. Given that the system is only > doing routing, I would assume it would be relatively low risk to > disable the mitigations to get better performance. > > Thoughts? > Elias >
sysctl for meltdown and mds mitigations
Would there be any interest in having a sysctl to enable/disable meltdown and mds mitigations? I was poking around 'sys/arch/amd64/amd64/cpu.c' and it appears that these mitigations are currently hardcoded. The benefit of having these sysctl's is that they would allow users to disable the mitigations for a tradeoff in performance. For example, I have an OpenBSD router only running dhcpd and pf which is struggling to keep up with a gigabit connection. Given that the system is only doing routing, I would assume it would be relatively low risk to disable the mitigations to get better performance. Thoughts? Elias
Re: Restore pf tables metadata after a reboot
On Tue, May 26, 2020 at 11:25:21PM +0200, Anders Andersson wrote: > On Tue, May 26, 2020 at 2:14 PM Walter Alejandro Iglesias > wrote: > > > > I understand that this command: > > > > # pfctl -t spam -T expire > > > > Takes in care the "Cleared" date: > > > > # pfctl -t spam -vT show > > ___.___.22.65 > > Cleared: Mon May 25 16:10:22 2020 > > ___.___.167.62 > > Cleared: Mon May 25 16:10:22 2020 > > [...] > > > > Is there a way to save and restore tables metadata after a reboot > > preserving those dates? > > Isn't this what pfctl -S and -L does? I *guess* what pfctrl -S does is to save in a file the same you see in 'pfctl -s states' output but in binary format.
Re: rc.conf.local sorted?
On Tue, May 26, 2020 at 05:16:44PM +0200, Why 42? The lists account. wrote: > > On Mon, May 25, 2020 at 04:51:51PM +0200, Antoine Jacoutot wrote: > > > ... > > > It looks as if the file has been sorted e.g. > > Did you use rcctl(8) ? > > Hi Antoine, > > You are correct, that does it. I checked the history and after the > upgrade I had run rcctl to enable sensorsd. Just tested it again and > running an rcctl enable or disable command causes all the lines of > /etc/rc.conf.local to be alphabetically sorted. > > That seems like a defect to me, what do you think? That's what you get when mixing helper tools and manuals edits. They can work together but only up to a certain point... and in this case, comments don't fly. As long as everything works functionnaly, then I'd say we're good and can live with it. -- Antoine
Re: Restore pf tables metadata after a reboot
On Tue, May 26, 2020 at 2:14 PM Walter Alejandro Iglesias wrote: > > I understand that this command: > > # pfctl -t spam -T expire > > Takes in care the "Cleared" date: > > # pfctl -t spam -vT show > ___.___.22.65 > Cleared: Mon May 25 16:10:22 2020 > ___.___.167.62 > Cleared: Mon May 25 16:10:22 2020 > [...] > > Is there a way to save and restore tables metadata after a reboot > preserving those dates? Isn't this what pfctl -S and -L does?
Re: sysupgrade confused by additional disk?
On Mon, May 25, 2020 at 12:26:43PM -0400, Nick Holland wrote:
> While OpenBSD itself is great about using duids, those are defined in
> the 'a' partition of the boot disk..which is usually the first disk. But
> in your case, the "first disk" doesn't include the 'a' partitionand the
> /etc/fstab file...which is probably causing the upgrade kernel to choke.
Yeah, that's not how this works.
See distrib/miniroot/install.sub:
# Determine if the supplied disk is a potential root disk, by:
# - Check the disklabel if there is an 'a' partition of type 4.2BSD
# - Mount the partition (read-only) and look for typical root filesystem layout
is_rootdisk() {
local _d=$1 _rc=1
(
make_dev $_d
if disklabel $_d | grep -q '^ a: .*4\.2BSD ' &&
mount -t ffs -r /dev/${_d}a /mnt; then
ls -d /mnt/{bin,dev,etc,home,mnt,root,sbin,tmp,usr,var}
_rc=$?
umount -f /mnt
fi
rm -f /dev/{r,}$_d?
return $_rc
) >/dev/null 2>&1
}
--
I'm not entirely sure you are real.
Re: Openbsd 6.6 httpd custom 404 page
No, it's not. But that would be nice, at least to suggest a link to à search page for a lost user. For now, you have to modify sources and compile again. Le 26 mai 2020 17:34:11 GMT+02:00, Riccardo Giuntoli a écrit : >Hello there dear OpenBSD fellows. > >I would like to change default 404 page in httpd(8), and I've seen in >this >list that in past versions is hardcoded into the C sources. > >Now it's possible in httpd.conf(5) ? > >Very nice regards, > >RG.
Re: Setting permanent neighbor entry
Do it in hostname.if. You’ll win the race. > On May 26, 2020, at 2:14 PM, Demi M. Obenour wrote: > > On 2020-05-26 09:34, Kanto Andria wrote: >> Hello, >> man ndp is probably another solution >> >>On Tuesday, May 26, 2020, 9:17:25 a.m. EDT, Tommy Nevtelen >> wrote: >> >>> On 26/05/2020 11.38, Demi M. Obenour wrote: >>> What is the OpenBSD equivalent to this Linux command? >>> >>> ip neighbor add 2001:db8::1 dev xnf0 lladdr fe:ff:ff:ff:ff:ff router nud >>> permanent >>> >>> It doesn’t need to be a single command. If the existing userspace >>> tooling does not support this, is it possible to do it via the >>> kernel APIs? >> man arp > > I already tried this, but it does not work if there is already > an entry. Removing it and re-adding it is racy: a new entry might > appear before I can override it. > > Sincerely, > > Demi >
Re: Setting permanent neighbor entry
On 2020-05-26 09:34, Kanto Andria wrote: > Hello, > man ndp is probably another solution > > On Tuesday, May 26, 2020, 9:17:25 a.m. EDT, Tommy Nevtelen > wrote: > > On 26/05/2020 11.38, Demi M. Obenour wrote: >> What is the OpenBSD equivalent to this Linux command? >> >> ip neighbor add 2001:db8::1 dev xnf0 lladdr fe:ff:ff:ff:ff:ff router nud >> permanent >> >> It doesn’t need to be a single command. If the existing userspace >> tooling does not support this, is it possible to do it via the >> kernel APIs? > man arp I already tried this, but it does not work if there is already an entry. Removing it and re-adding it is racy: a new entry might appear before I can override it. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Setting permanent neighbor entry
Hello, man ndp is probably another solution On Tuesday, May 26, 2020, 9:17:25 a.m. EDT, Tommy Nevtelen wrote: On 26/05/2020 11.38, Demi M. Obenour wrote: > What is the OpenBSD equivalent to this Linux command? > > ip neighbor add 2001:db8::1 dev xnf0 lladdr fe:ff:ff:ff:ff:ff router nud > permanent > > It doesn’t need to be a single command. If the existing userspace > tooling does not support this, is it possible to do it via the > kernel APIs? man arp
Openbsd 6.6 httpd custom 404 page
Hello there dear OpenBSD fellows. I would like to change default 404 page in httpd(8), and I've seen in this list that in past versions is hardcoded into the C sources. Now it's possible in httpd.conf(5) ? Very nice regards, RG. -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: sant Pere de Ribes, BCN, Spain PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
Re: rc.conf.local sorted?
On Mon, May 25, 2020 at 04:51:51PM +0200, Antoine Jacoutot wrote: > > ... > > It looks as if the file has been sorted e.g. > Did you use rcctl(8) ? Hi Antoine, You are correct, that does it. I checked the history and after the upgrade I had run rcctl to enable sensorsd. Just tested it again and running an rcctl enable or disable command causes all the lines of /etc/rc.conf.local to be alphabetically sorted. That seems like a defect to me, what do you think? Thanks for the suggestion! Cheers, Robb.
vsrion of openbsd installer in one usb drive
Hello, I tried this work for me. 1. Install openbsd (basic packages:- bsd,bsd.rd and basexx.tgz) in a usb drive2. use the newly installed usb drive to boot up the system and then shut it down.3. use other openbsd system to delete all the contents of the usb drive except bsd.rd, bsd, boot. Then copy packages basexx>tgz compxx.tgz ... to the usb drive under xx/arch/ directory.4. When there is new version, you can store the packages (basexx.tgz ...) under yy/arch same usb drive and so on. Is there a better way to store verions of openbsd installer in usb drive ? Thanks Clarence
Re: Setting permanent neighbor entry
On 26/05/2020 15.34, Kanto Andria wrote: Hello, man ndp is probably another solution This is the correct way since it is v6 :) /T
Re: sysupgrade confused by additional disk?
shouldn’t sysupgrade default to use the disk where bad.rd launched from? I assume it’s the same disk that was running the system before boot. This would be ideal default behaviour since this is an upgrade. regards > On 25 May 2020, at 18:26, Nick Holland wrote: > > On 2020-05-25 10:21, Why 42? The lists account. wrote: > ,,, >> At some point I added a second (larger) disk to hold my user data (i.e. >> home). It seems that this new disk took over the name sd0 and the OpenBSD >> system disk itself became known as sd1. > > yep. Things like that are where the duids came in. > >> The OpenBSD OS still boots and runs without issue, however this change >> seems to have confused sysupgrade. After it downloads and reboots I now >> get prompted to choose I)nstall, U)grade, etc. If I recall correctly, >> this step used to run automatically without any intervention. Is that >> right? > > While OpenBSD itself is great about using duids, those are defined in > the 'a' partition of the boot disk..which is usually the first disk. But > in your case, the "first disk" doesn't include the 'a' partitionand the > /etc/fstab file...which is probably causing the upgrade kernel to choke. > >> My first thought was I could fix the issue by using sysctl to reassign >> the disk name to uuid mapping (i.e. the hw.disknames values) > ... > No, that won't work -- the disks are assigned at boot. > >> Any other suggestions as to how to fix this? >> >> Thinking some more about it, shouldn't sysupgrade just use those very >> disk uuid values to identify its targets in the first place ... thus >> avoiding the whole issue in the first place? > > think about that a moment. You are running OpenBSD. You run sysupgrade, > it pulls down all the new tgz files. And it ... REBOOTS. I think you > are asking that the old kernel passes info to the newly rebooted kernel. > > It's probably doable, or could fail earlier to let you know you have a > problem, but I'm driving myself batty thinking about the multi-platform > and edge cases. > > The best solution for YOU I can think of would be to put a small 'a' > partition on your sd0 for root, and have your system boot from that, > but use sd1 for all the rest of the system file systems. Or just do > traditional upgrades. > > Nick. >
Re: Setting permanent neighbor entry
On 26/05/2020 11.38, Demi M. Obenour wrote: What is the OpenBSD equivalent to this Linux command? ip neighbor add 2001:db8::1 dev xnf0 lladdr fe:ff:ff:ff:ff:ff router nud permanent It doesn’t need to be a single command. If the existing userspace tooling does not support this, is it possible to do it via the kernel APIs? man arp
Restore pf tables metadata after a reboot
I understand that this command: # pfctl -t spam -T expire Takes in care the "Cleared" date: # pfctl -t spam -vT show ___.___.22.65 Cleared: Mon May 25 16:10:22 2020 ___.___.167.62 Cleared: Mon May 25 16:10:22 2020 [...] Is there a way to save and restore tables metadata after a reboot preserving those dates?
Setting permanent neighbor entry
What is the OpenBSD equivalent to this Linux command? ip neighbor add 2001:db8::1 dev xnf0 lladdr fe:ff:ff:ff:ff:ff router nud permanent It doesn’t need to be a single command. If the existing userspace tooling does not support this, is it possible to do it via the kernel APIs? Sincerely, Demi signature.asc Description: OpenPGP digital signature
