From nobody Mon Nov 13 11:43:01 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4STSHr3p48z51H1L for ; Mon, 13 Nov 2023 11:43:52 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4STSHq65rdz4RwW for ; Mon, 13 Nov 2023 11:43:51 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=T7JqZSQI; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net; dmarc=pass (policy=quarantine) header.from=leidinger.net List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1699875828; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nFtAya5ssBABklhVhFS5rDqVxsfjryxoOx2+cNJeV4o=; b=T7JqZSQI64khfN/syNccva590Kv4V4KJcj5HLgGuBW9HaKrmbj4oXbfucBCaY6G8T2bdgb qLuZvanCzY6jRXkuZof54uCs+5iRFVkPOqGe+FHesuQxerK6rpdxkY70DCF5EafcBgEpZY km2Z5sqtS8SmBYqHhO/0LRDQW/3V7gj7iWPH2umqJJZ8bHVm6BBXHuUlqKTT1c8UHVJLl3 Y+RbEPumTEminRYo1Co6JlQr2ZdDT8/HIJy8WL5VbI1KLhBwetSpqmCACXGaIVp0pd7ju1 yK2j8akTCL3AWA2xWEsG06avW7TNaIli3Tp5ZKDKkcX0R/Z2+6XozaSChMosBA== Date: Mon, 13 Nov 2023 12:43:01 +0100 From: Alexander Leidinger To: Christian Weisgerber Cc: freebsd-arch@freebsd.org Subject: Re: Any particular reason we don't have sshd oomprotected by default? In-Reply-To: References: <8b9484ba83e373ece0e322e14c924da6@Leidinger.net> Message-ID: <3c3b4929125d113b230f8bbba33048ff@Leidinger.net> X-Sender: Alexander@Leidinger.net Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_77b79f65bc4763d99e6f66377879913f"; micalg=pgp-sha256 X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; HAS_ATTACHMENT(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4STSHq65rdz4RwW X-Spamd-Bar: ----- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_77b79f65bc4763d99e6f66377879913f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2023-11-13 11:10, schrieb Christian Weisgerber: > Alexander Leidinger: > >> We have syslogd oomprotected by default (/etc/defaults/rc.conf). Is >> there a >> particular reason we don't have sshd protected the same way? > > syslogd(8) can perform its function without forking, I think. > > sshd(8) needs to fork and spawn new processes to be useful. So I > don't know how useful that is in an OOM context. Conversely, your > existing sessions aren't affected when the sshd listening on port 22 > goes away. oomprotect can be set to inherit when forked. I have not done that in this patch. So the main listener on the socket is protected from oom situations, but not individual login sessions. Before proposing the patch in the review, I thought what may be a sensible solution, inherit or not inherit, and I settled on not inherit, as this still allows to login, but would be able to kill long running sessions which may (or may not) contribute to the oom situation. If someone has some strong arguments to change this to set oomprotect to inherit when forked for sshd, feel free to discuss them. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_77b79f65bc4763d99e6f66377879913f Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmVSC9MACgkQEg2wmwP4 2IZOPw/8DH7GA2fWH9PphQAnI49UjANVOx7T8lJI4b7A0/RCeRgK9iBzJRMqm36Y 9G+Q37gc/PyFbSUmRry2ROONVqFnOUJ3eYtJcfegSdIo3SJH2JZcfFA+yE5yXc96 4wo4o87Ptz0MTQ9jyHjziB1TTZKS2exVL2lG6Htr1Xw9JuXzrtZbywhSplWsZve7 8gMfko3aa8iORmaEcYO8diTt9eGyyue322iOlp7SHB/F1UAEUjZ7SBarbng8wHKs J9PVR6Hyu1+BFBMovhtVQ01B6I5cDCOc183T4ASTTsp4qBr9IXdQBszIDyRU/j0L bktcdLCkJi2eLTB+PpjpHgx4r8A5ar7+PpFfbZMRkY6pW8kTUJxYCb+f9NbzGzfu w3VlHFVL0KMUrB57qFgNsePo5CVUpTJxWC7c6M6+REApYVUzs6q3T9XiPlsizS52 +uaxzhQdYCAwJ9oAiZwYZx7RWtkPvgugIChpvv6arHpjXw6yIiWNboggjVr7rac+ p6SOriDuXsOx7ms4Pg/rYDJxu1YaDIKYdfbB6Atem6894HGbXIKxgZaRiSIia8qU 6KDanGwpGvdaS1Pha+fRfvJgxX0nbg9IyP8GlG5jzGngPvjwOUZPbVyPMmBI/Mej W0SwnlIDooei9bqMdnqgtc40kJPZiJWzqPBLNCvcC7wdWsk1BGI= =utmW -----END PGP SIGNATURE----- --=_77b79f65bc4763d99e6f66377879913f-- From nobody Fri Nov 17 11:12:05 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SWvPQ2mKsz50rLL for ; Fri, 17 Nov 2023 11:12:10 +0000 (UTC) (envelope-from olivier.freebsd@free.fr) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SWvPP32sQz3HJ6 for ; Fri, 17 Nov 2023 11:12:09 +0000 (UTC) (envelope-from olivier.freebsd@free.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=free.fr header.s=smtp-20201208 header.b=PG+2ETZ1; spf=pass (mx1.freebsd.org: domain of olivier.freebsd@free.fr designates 212.27.42.2 as permitted sender) smtp.mailfrom=olivier.freebsd@free.fr; dmarc=pass (policy=none) header.from=free.fr Received: from ravel.localnet (unknown [90.118.140.172]) (Authenticated sender: olivier.freebsd@free.fr) by smtp2-g21.free.fr (Postfix) with ESMTPSA id 4D0542003C1 for ; Fri, 17 Nov 2023 12:12:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1700219526; bh=cnD0xew82JyohBJCASQvkaviVbc6lDVBQgzi/f3EmW8=; h=From:To:Subject:Date:From; b=PG+2ETZ1T2RV1jGrpNuDEvNBboZAA7ROa0t4WPAD61RNTOW7HBvbE/8/YxgW2ne62 RgxLMCvAf0/z13mVDQfSpYAepUIX02Oq4D9DgmCS0JoRGaIgHH2OqRUMdJGevk4sVY JDgM14frOV0UT2Ddl9W2g/1Znq+kOw4ALJwdZtyMPRCMoXM/OEDO4rxYZF9Q3V8YNV 9i8B5SSksXntmH+zH9O9HaN/vyDGmCuL1vmOixd/UTbDRLBDSaJsmRWReg9Q9JSSnn rTZoxnl+F22Zg9m2v2B7XrH2IfjlpM0DWZoiHamFb5b4EUQl9sJQKwDBbEzVHScbXW x8k4kn8h9iuOQ== From: Olivier Certner To: freebsd-arch@freebsd.org Subject: Suppressing the _KPOSIX_PRIORITY_SCHEDULING kernel config option Date: Fri, 17 Nov 2023 12:12:05 +0100 Message-ID: <5428029.vKySYWdmsc@ravel> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-1.18 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.82)[0.818]; DMARC_POLICY_ALLOW(-0.50)[free.fr,none]; CTE_CASE(0.50)[]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:212.27.42.2]; R_DKIM_ALLOW(-0.20)[free.fr:s=smtp-20201208]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[212.27.42.2:from]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[free.fr:dkim]; FREEMAIL_ENVFROM(0.00)[free.fr]; DKIM_TRACE(0.00)[free.fr:+]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[free.fr]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:12322, ipnet:212.27.32.0/19, country:FR]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4SWvPP32sQz3HJ6 X-Spamd-Bar: - Hello, As part of my current work on rationalizing/fixing scheduling priorities, both from the point of view of users and internally, I've stumbled on this kernel config option. It currently controls whether the system calls related to process scheduling are compiled in instead of providing stubs. Here's the system calls list: - sched_setscheduler()/sched_getscheduler() - sched_setparam()/sched_getparam() - sched_yield() - sched_get_priority_max()/sched_get_priority_min()/sched_rr_get_interval() There are some problems with this build option: 1. These system functions are defined by the current POSIX standard as being part of the PS (Process Scheduling) and TPS (Thread Execution Scheduling) options, which also define a number of other ones (e.g., pthread_getschedparam()/pthread_setschedparam(), pthread_setschedprio() and a bunch of similar pthread_attr_*() functions) that by contrast we *unconditionally* provide (i.e., irrespective of _KPOSIX_PRIORITY_SCHEDULING). This is inconsistent. 2. The priority values handling it needs to implement is common to other parts, such as the PTHREAD_PRIO_PROTECT mutexes (POSIX options TPP and RPP, Non-Robust/Robust Mutex Priority Protection), which again we unconditionally provide. 3. The kernel currently doesn't compile without it. Additionally: 1. The code under _KPOSIX_PRIORITY_SCHEDULING is just a translation layer to the RT priorities facility which is the real implementation and, as you guessed it, again cannot be compiled out. 2. _KPOSIX_PRIORITY_SCHEDULING is present in MINIMAL (probably because of 3. above). 3. Quick-patching 3. above, I observe that the kernel size increase caused by this option is a whopping 4456 bytes (with debug options enabled). For all these reasons, I'm planning to just remove _KPOSIX_PRIORITY_SCHEDULING and have the code it controls always compiled in. An alternative would be the painful work of determining what would make sense to fall under this option and effectively separating the code properly, but I don't think it's worth it, and as can be seen from above the status quo is not satisfying either. Any objections? Or other thoughts? Thanks and regards. -- Olivier Certner