Re: disable PPP_BSDCOMP by default
On Tue, Mar 30, 2021 at 12:00:10AM +0200, Balder Oddson wrote: > On Thu, Mar 25, 2021 at 12:46:24PM -0600, Theo de Raadt wrote: > > No way for this diff. This is the wrong way. Surely there are ways > > to disable compression negotion on specific sessions, but removing > > the code from the kernel is the wrong knob. > > So whom do I explain for feedbeef OK? > You can run on Cray X1, where each terminal has a clock that is good? > Another way to do SMP is speed as security --- memory being dead. > That part doesnt get made with a shared vector machine in mind, and a > definiton of local and shared devices? Cray-1, otherwise this doesn't make sense, and reasoning why. How you come with sales arguments that involve being slower on integer operations, but since its scalar vector machine, as long as you have to do many, or many at the same time, I go faster anyways, so you can pay for what you use, if only integer operations. Anyways, these are also nice machines, even if small operations and integer operations take a hit, for the things done to make vectors to enable scalar operations for a net performance increase. Which should imply that virtual devices, and devices with a inherent clock are device drivers and daemons. Pretty nifty pipeline by antique standards. > > You don't need to check for many things at two thirds the speed of light > in copper, but if job done and time is deterministic. > Where everything is connected to a crossbarswitch, and buses are dead, > this analogue/non-interactive thing doesn't belong. > > The basic principle should be compatible with "everything is a filtered > file", "every file has an array of pointers with addresses" that is kept > around after berkley packet filter. And that this gives higher memory > bandwidth to feed beef. Huge performance increase with AVX2, but it can > also be used for this I believe, decreases memory operations and > therefore increases instructions per cycle, so can deal with more lesser > devices, dead or otherwise. > > Why is this ludicrous? And is this rationale good enough? > I believe something similar was done to increase the performance of some > physics simulation toolkit, but thats not kernel or OS design. > Path of a particle is not the same as the path of a particle. > > Vroom? > > > > > > Balder Oddson wrote: > > > > > Compression in PPP was great in the age of ISDN to increase speeds. > > > The more common use cases, and trends concerning TLS1.3 advancements. > > > > > > Having this enabled by default, and infrequently used could lead to > > > unintended consequences around how the data is passed around. > > > > > > > > > Index: GENERIC > > > === > > > RCS file: /cvs/src/sys/conf/GENERIC,v > > > retrieving revision 1.274 > > > diff -u -p -u -p -r1.274 GENERIC > > > --- GENERIC 25 Feb 2021 01:19:35 - 1.274 > > > +++ GENERIC 25 Mar 2021 18:07:58 - > > > @@ -50,8 +50,8 @@ option TCP_SIGNATURE # TCP MD5 Signatur > > > > > > option INET6 # IPv6 > > > option IPSEC # IPsec > > > -option PPP_BSDCOMP # PPP BSD compression > > > -option PPP_DEFLATE > > > +#option PPP_BSDCOMP # PPP BSD compression > > > +#option PPP_DEFLATE # Disabled by default, TLS1.3 trends > > > option PIPEX # Ppp IP EXtension, for npppd > > > option MROUTING# Multicast router > > > option MPLS# Multi-Protocol Label Switching > > > > -- Balder Oddson
Re: disable PPP_BSDCOMP by default
On Thu, Mar 25, 2021 at 12:46:24PM -0600, Theo de Raadt wrote: > No way for this diff. This is the wrong way. Surely there are ways > to disable compression negotion on specific sessions, but removing > the code from the kernel is the wrong knob. So whom do I explain for feedbeef OK? You can run on Cray X1, where each terminal has a clock that is good? Another way to do SMP is speed as security --- memory being dead. That part doesnt get made with a shared vector machine in mind, and a definiton of local and shared devices? You don't need to check for many things at two thirds the speed of light in copper, but if job done and time is deterministic. Where everything is connected to a crossbarswitch, and buses are dead, this analogue/non-interactive thing doesn't belong. The basic principle should be compatible with "everything is a filtered file", "every file has an array of pointers with addresses" that is kept around after berkley packet filter. And that this gives higher memory bandwidth to feed beef. Huge performance increase with AVX2, but it can also be used for this I believe, decreases memory operations and therefore increases instructions per cycle, so can deal with more lesser devices, dead or otherwise. Why is this ludicrous? And is this rationale good enough? I believe something similar was done to increase the performance of some physics simulation toolkit, but thats not kernel or OS design. Path of a particle is not the same as the path of a particle. Vroom? > > Balder Oddson wrote: > > > Compression in PPP was great in the age of ISDN to increase speeds. > > The more common use cases, and trends concerning TLS1.3 advancements. > > > > Having this enabled by default, and infrequently used could lead to > > unintended consequences around how the data is passed around. > > > > > > Index: GENERIC > > === > > RCS file: /cvs/src/sys/conf/GENERIC,v > > retrieving revision 1.274 > > diff -u -p -u -p -r1.274 GENERIC > > --- GENERIC 25 Feb 2021 01:19:35 - 1.274 > > +++ GENERIC 25 Mar 2021 18:07:58 - > > @@ -50,8 +50,8 @@ optionTCP_SIGNATURE # TCP MD5 Signatur > > > > option INET6 # IPv6 > > option IPSEC # IPsec > > -option PPP_BSDCOMP # PPP BSD compression > > -option PPP_DEFLATE > > +#optionPPP_BSDCOMP # PPP BSD compression > > +#optionPPP_DEFLATE # Disabled by default, TLS1.3 trends > > option PIPEX # Ppp IP EXtension, for npppd > > option MROUTING# Multicast router > > option MPLS# Multi-Protocol Label Switching > >
Re: disable PPP_BSDCOMP by default
On Thu, Mar 25, 2021 at 08:46:10PM -0600, Theo de Raadt wrote: > Balder Oddson wrote: > > > On Thu, Mar 25, 2021 at 03:40:15PM -0600, Theo de Raadt wrote: > > > Stuart Henderson wrote: > > > > > > > > Not having read the code, case in point on principle, I'm arguing that > > > > > there should be solid reasoning to enable it by default, as those > > > > > with a > > > > > need for it can certainly enable it and build a kernel. > > > > > > > > It's not that simple, using a custom kernel means you can't use > > > > syspatches > > > > so are more likely to stay on a vulnerable version if a kernel bug is > > > > fixed. > > > > > > I am perfectly happy if Balder is running a custom kernel. > > > > I am also happy if your kernel finds good use for the compression and > > deflation code, perhaps fiddling with microcode can be of use to make > > sure there is no instruction or data prefetch involved. > > > > Many interesting points about the immediate consequences for the code, > > perhapts its re-used and touching too many things? > > To summarize for the public, Balder is insinuating that the PPP > (historical CSLIP) compression code might be a security risk; apparently > to bolster his case that we should remove it from the kernel because it > (maybe) harms his strange usage case. So I had a weird experience at the release of 6.8. Went to the BSD blog reporting on Nannis hackathon report. Found that one of the pages were blocked by pf-badhost. When I rebooted, a loud "pop" sound occured before the bootloader and the machine powered off (t430s). This made me curious because I actually had newer firmware with a fix for the EC firmware, wondering if something had tried to place itself there. > Your proposed change will go nowhere, and increasing rhetoric is not > helping the case. > > Balder, please got shove a fork or spoon into your eye and leave us > alone. Furthermore if perforate both eyes, you won't need to see the > code again!!! This is not an experience where I can complain that machines crash in specific racks everytime they turn aggregates for the cooling system on and off, and whether someone can measure the power and look for sharp spikes in the current propagating backwards where no UPS or protection against it is in place. Not sure if all good choices can be found in the code.
Re: disable PPP_BSDCOMP by default
On Thu, Mar 25, 2021 at 03:40:15PM -0600, Theo de Raadt wrote: > Stuart Henderson wrote: > > > > Not having read the code, case in point on principle, I'm arguing that > > > there should be solid reasoning to enable it by default, as those with a > > > need for it can certainly enable it and build a kernel. > > > > It's not that simple, using a custom kernel means you can't use syspatches > > so are more likely to stay on a vulnerable version if a kernel bug is fixed. > > I am perfectly happy if Balder is running a custom kernel. I am also happy if your kernel finds good use for the compression and deflation code, perhaps fiddling with microcode can be of use to make sure there is no instruction or data prefetch involved. Many interesting points about the immediate consequences for the code, perhapts its re-used and touching too many things?
Re: disable PPP_BSDCOMP by default
On Thu, Mar 25, 2021 at 07:09:37PM +0100, Balder Oddson wrote: > Compression in PPP was great in the age of ISDN to increase speeds. > The more common use cases, and trends concerning TLS1.3 advancements. > > Having this enabled by default, and infrequently used could lead to > unintended consequences around how the data is passed around. Off list it has been suggested that this is ridiciolous. And perhaps this is, especially for the justifications given, thought be sufficient. >From a UNIX architectural perspectiv, adhering to things like "everything is a file". PPP device are not physical devices that can be used for a PPP connection, where it is more trivial with a practice to do compression and decompression before presenting the payload to the kernel so its forced to go through the usual barriers. Back in the day, when everything was a PPP connection for most people, this made good sense and also gave good performance. Having code in the kernel that is even better than say, base64 that can detangle a malicious payload isn't the point here. There shouldn't be targetable code in the kernel for these kinds of tasks that can be exploited. And the task should preferably be something outside of kernel space or in a real device driver. Not having read the code, case in point on principle, I'm arguing that there should be solid reasoning to enable it by default, as those with a need for it can certainly enable it and build a kernel. Maybe this isn't a huge concern for the network parts of the code, but as soon as there is multiprocessing and desktop applications involved, it becomes increasingly unattractive. What's the technical reasons for this code in 2020? > > > Index: GENERIC > === > RCS file: /cvs/src/sys/conf/GENERIC,v > retrieving revision 1.274 > diff -u -p -u -p -r1.274 GENERIC > --- GENERIC 25 Feb 2021 01:19:35 - 1.274 > +++ GENERIC 25 Mar 2021 18:07:58 - > @@ -50,8 +50,8 @@ option TCP_SIGNATURE # TCP MD5 Signatur > > option INET6 # IPv6 > option IPSEC # IPsec > -option PPP_BSDCOMP # PPP BSD compression > -option PPP_DEFLATE > +#option PPP_BSDCOMP # PPP BSD compression > +#option PPP_DEFLATE # Disabled by default, TLS1.3 trends > option PIPEX # Ppp IP EXtension, for npppd > option MROUTING # Multicast router > option MPLS# Multi-Protocol Label Switching -- Balder Oddson
disable PPP_BSDCOMP by default
Compression in PPP was great in the age of ISDN to increase speeds. The more common use cases, and trends concerning TLS1.3 advancements. Having this enabled by default, and infrequently used could lead to unintended consequences around how the data is passed around. Index: GENERIC === RCS file: /cvs/src/sys/conf/GENERIC,v retrieving revision 1.274 diff -u -p -u -p -r1.274 GENERIC --- GENERIC 25 Feb 2021 01:19:35 - 1.274 +++ GENERIC 25 Mar 2021 18:07:58 - @@ -50,8 +50,8 @@ optionTCP_SIGNATURE # TCP MD5 Signatur option INET6 # IPv6 option IPSEC # IPsec -option PPP_BSDCOMP # PPP BSD compression -option PPP_DEFLATE +#optionPPP_BSDCOMP # PPP BSD compression +#optionPPP_DEFLATE # Disabled by default, TLS1.3 trends option PIPEX # Ppp IP EXtension, for npppd option MROUTING# Multicast router option MPLS# Multi-Protocol Label Switching
Re: tls_config_parse_protocols.3: more prominent protocol list
On Wed, Dec 30, 2020 at 02:09:46AM +0100, Klemens Nanni wrote: > On Wed, Dec 30, 2020 at 02:02:44AM +0100, Klemens Nanni wrote: > >default (alias for "secure") > >legacy (alias for "all") > without double quotes > First time poster, so, Hi! Been browsing around this TLS topic, cipphers, standards, and options and would like to comment. With MSMTP I have provided a gnutls priority string that gives me ecdsa-secp256r1-sha SSL certificate option, rather than the "recommended for desktop" 2048 bits RSA. For most other thing, without application support to configure this for openssl, you end up with assumed 112 bit strengt RSA instead of assumed 128 bits NIST P-256 Curve. Or maybe I am wrong and missing some insight into openssl and libressl internals and how to check and confirm. With gnutls-cli, it seem that ECDSA certificates get chosen if it is TLS 1.3, and if it is TLS 1.2 it picks RSA. And without double checking, it looks like openssl chooses the latter in both protocols, where in TLS 1.2 one doesn't even seem to be guaranteed that the connection even uses the same signing algorithm as they certificate, let alone actually using or authenticating with the certificate to validate. Which is more interesting than how it can be somewhat difficult to get "recommended" ciphers from both standards with support in both. Irrespective of ciphers involved, is TLS 1.2 "secure" -- pun intended; and the symolic -- freudian-slip -- perhaps not an error needing correction. Given that "secure" and default both gives TLS 1.2 and higher, where there are two ways to guess incorrectly; whether its strength or technicalities involved, or correctly thereof. As a side note, how Debian provides a openssl.cnf to change default SECLEVEL doesn't seem to be in libressl, if at all possible, not documented sufficiently for clowns like me who like Curves, and it seems to be in the times to move away from RSA as the keys are getting bulky.
