[PATCH] Libc: change strmode to use mode_t
Here, we define mode_t so we can use it as the argument type in string.h
diff --git a/include/string.h b/include/string.h
index 9141c34..482fa275d53 100644
--- a/include/string.h
+++ b/include/string.h
@@ -119,6 +119,12 @@ size_t strxfrm_l(char *__restrict, const char
*__restrict, size_t, locale_t)
#endif
#if __BSD_VISIBLE
+
+#ifndef_MODE_T_DEFINED_
+#define_MODE_T_DEFINED_
+typedef__mode_tmode_t;
+#endif
+
voidexplicit_bzero(void *, size_t)
__attribute__ ((__bounded__(__buffer__,1,2)));
void *memmem(const void *, size_t, const void *, size_t);
diff --git a/lib/libc/string/strmode.c b/lib/libc/string/strmode.c
index 609b8931fbb..ded67b65d42 100644
--- a/lib/libc/string/strmode.c
+++ b/lib/libc/string/strmode.c
@@ -32,10 +32,8 @@
#include
#include
-/* XXX mode should be mode_t */
-
void
-strmode(int mode, char *p)
+strmode(mode_t mode, char *p)
{
/* print type */
switch (mode & S_IFMT) {
Re: log reason when a packet causes pf to add an IP to a table ?
On Mon, Jun 28, 2021 at 06:38:21PM +0200, Matthieu Herrb wrote: > I have rules like this one on the firewalls I manage: > > pass in on $in_if proto tcp from any to port ssh \ > flags S/SA keep state \ > (source-track rule, max-src-states 30, max-src-conn 20, \ > max-src-conn-rate 15/30, overload flush > global) > > block log from > > However some legitimate remote users get their addresses added to the > ssh-bruteforce table from time to time. > > I'd like to be able to figure out the reason (ie which condtion > triggers the overload). Is there a way to have it logged somewhere > that I'm missing ? `set debug notice' should syslog(3) addresses being overloaded in the first place, but I'm fairly certain there is currently no way to get more than that.
log reason when a packet causes pf to add an IP to a table ?
Hi I have rules like this one on the firewalls I manage: pass in on $in_if proto tcp from any to port ssh \ flags S/SA keep state \ (source-track rule, max-src-states 30, max-src-conn 20, \ max-src-conn-rate 15/30, overload flush global) block log from However some legitimate remote users get their addresses added to the ssh-bruteforce table from time to time. I'd like to be able to figure out the reason (ie which condtion triggers the overload). Is there a way to have it logged somewhere that I'm missing ? Thanks in avance, -- Matthieu Herrb
Issue with /bin/sh and IFS
Hi In looking at some shell code that counts %’s in strings, I discovered this small discrepancy in OpenBSD’s shell. I’m not sure if this is a bug or expected behaviour so thought I would ask here. It seems to be the way set is used. This shell script tickles the issue. The difference being the x is prefixed in the set command in the second case: msg="x%s konnte nicht genet werden, die Fehlermeldung lautet: %s." msg1="%s konnte nicht genet werden, die Fehlermeldung lautet: %s." IFS="%" set -- $msg echo "Message: $msg" >&2 echo "$#" >&2 set -- x$msg1 echo "Message: $msg1" echo " with x before" >&2 echo "$#" >&2 echo "" >&2 On OpenBSD, this is the output: Message: x%s konnte nicht genet werden, die Fehlermeldung lautet: %s. 3 Message: %s konnte nicht genet werden, die Fehlermeldung lautet: %s. with x before 4 On bash, NetBSD /bin/sh, MacOS /bin/sh and FreeBSD both values are 3. Any ideas? I can file a bug if necessary. Kind regards Chris
Re: yes(1): bypass stdio to improve throughput
Scott Cheloha writes: > No, no, I'm not being serious. Sorry. :) > > The throughput improvement with such a small code change is > interesting though. The interesting and serious question is whether there's something suboptimal in stdio buffering which can be cheaply improved. It seems unlikely that easy improvements remain after all these years. Thanks Greg
Re: Issue with /bin/sh and IFS
> Date: Mon, 28 Jun 2021 11:28:58 +0100 > From: Chris Pinnock > I’m not sure if this is a bug or expected behaviour so thought I > would ask here. src/bin/ksh/NOTES says: - field splitting (IFS): ksh88/ksh93 strip leading non-white space IFS chars, pdksh (and POSIX, I think) leave them intact. e.g. $ IFS="$IFS:"; read x; echo "<$x>" :: prints "<>" in at ksh, "<::>" in pdksh. but i cant see anything to justify the double-counting of IFS. > seems to be the way set is used. printf %s\\n x$msg1 shows set is not to blame (the blank line indicates an empty field). sorry i cant say anything very useful about it.
Re: tcpdump: print 802.11 sequence numbers properly
On Mon, Jun 28 2021, Stefan Sperling wrote:
> tcpdump -e -v -y IEEE802_11_RADIO currently prints sequence number
> and fragment number as a combined decimal value.
>
> This patch makes tcpdump display these values separately which is a lot
> easier to follow along as packets scroll by.
>
> ok?
ok jca@
> diff 18a81a05d6e3098eadc4b5e23d6656377f87591a /usr/src
> blob - 7528f50e45765f83d5d719d831df2880838bc28c
> file + usr.sbin/tcpdump/print-802_11.c
> --- usr.sbin/tcpdump/print-802_11.c
> +++ usr.sbin/tcpdump/print-802_11.c
> @@ -162,7 +162,9 @@ ieee80211_hdr(struct ieee80211_frame *wh)
> u_int16_t seq;
> TCARR(wh->i_seq);
> bcopy(wh->i_seq, , sizeof(u_int16_t));
> - printf(" (seq %u): ", letoh16(seq));
> + printf(" (seq %u frag %u): ",
> + letoh16(seq) >> IEEE80211_SEQ_SEQ_SHIFT,
> + letoh16(seq) & IEEE80211_SEQ_FRAG_MASK);
> } else
> printf(": ");
>
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] strcpys(): New function for copying strings safely
On 6/28/21 1:32 PM, Alejandro Colomar (man-pages) wrote: The other use is where you want a sequence of: len *= str_copy(dest + len, dest_len - len, src); But don't really want to test for overflow after each call. This is a legitimate use of strscpy(). Please, add it to glibc, as there is no libc function to do that. In this case returning the buffer length (including the added '\0' on truncation works quite nicely. No chance of writing outside the buffer, safe truncation and a simple 'len == dest_len' check for overflow. OTOH there are already too many string copy functions. There are, but because the standard ones don't serve all purposes correctly, so people need to develop their own. If libc provided the necessary functions, less custom string copy functions would be necessary, as Christoph said a long time ago, which is a good thing. As I see it, there are the following, each of which has its valid usage: strcpy(3): known input && known buffer strncpy(3): not for C strings; only for fixed width buffers of characters! strlcpy)3bsd): known input && unknown buffer Given that performance-wise it's similar to strscpy(), it should probably always be replaced by strscpy(). strscpy(): unknown input && truncation is silently ignored Except for performance-critical applications, this call may replace strcpy(3), to add some extra safety. strcpys(): unknown input && truncation may be an error (or not). This call can replace strscpy() in most cases, simplifying usage. The only case I can see that strscpy() is superior is for chains of strscpy(), where I'd only use strcpys() in the last one (if any strscpy() in the chain has been trunncated, so will the last strcpys() (unless it's "")). BTW, for chains of str_cpy(), a strscat() and a strcats() function should probably replace chained strcpy()s, so it would be something like: l = strscpy(n, dest, src); l = strscat(n - l, dest + l, src2); l = strscat(n - l, dest + l, src3); ... if (strcats(n - l, dest + l, srcN, NULL)) goto handle_truncation_or_error; And the user should make sure that srcN is not "" unless he doesn't care about truncation. Otherwise, check at every step. I'll send my source code for strscat and strcats, if strscpy and strcpys are considered for addition. -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/
Re: [RFC] strcpys(): New function for copying strings safely
Hello David,
On 6/28/21 10:15 AM, David Laight wrote:
From: Alejandro Colomar
Sent: 27 June 2021 20:47
On 6/27/21 9:26 PM, Alejandro Colomar (man-pages) wrote:
It is designed so that usage requires the minimum number of lines of
code for complete usage (including error handling checks):
[[
// When we already checked that 'size' is >= 1
// and truncation is not an issue:
strcpys_np(size, dest, src, NULL);
Also, given how unlikely this case is, I have in my code:
`[[gnu::warn_unused_result]]`
warn_unused_result is such a PITA it should never have been invented.
At least no one seems to have been stupid enough to apply it to fprintf()
(you need to do fflush() before looking for errors).
Okay. After some thought, I think removing it is better.
In most cases strcpy() is safe - but if the inputs are 'corrupt'
horrid things happen - so you need truncation for safety.
But you really may not care whether the data got truncated.
Yes, in most cases, expecially with literal strings ("xxx") and known
buffers, strcpy() is completely safe.
And yes, if the input is untrusted (may be corrupt or not), you need to
be prepared for truncation. You don't need to truncate, hey, maybe the
input is well-formed, but you need a function that may truncate if needed.
For that, we have strncpy(3), strlcpy(3bsd), and strscpy (kernel).
strncpy(3) is not for strings; it is for fixed length buffers. It has
high performance penalties, and yet doesn't guarantee a C-string.
DISCARDED.
strlcpy(3bsd) still requires that the input is a C-string, so it can't
be used with untrusted strings. It really is broken, as Linus said.
Its only valid use is if the input string is known (maybe a literal),
but the output buffer may be smaller than the input string. DISCARDED.
strscpy (kernel) is great. BUT it is not supported by glibc. The
reason for not including it (actually Ulrich used it for not including
strlcpy, but it also applies to strscpy) is that it doesn't report an
error when the string is truncated. I think that strscpy adds value to
the current strcpy variants, and should be added to glibc.
And then, coming back to truncation, yes, in some cases, truncation is
wanted, and not an error, for which strscpy is great (so please add it
to glibc :), but then there are other cases where truncation is not
wanted, but yet we deal with untrusted strings. That is the case that I
think Ulrich mentioned that wasn't covered by strlcpy (and isn't yet
covered by strscpy). And the reason to add this function.
Let's say a user introduces a username; it's an untrusted string, we
need to process it at least with strscpy(). But if it is corrupted (too
long), we don't want to silently store a truncated username; we want to
inform the user, so that he introduces a new (hopefully valid) username.
For that, strcpys() as defined in the previous email, is necessary.
The other use is where you want a sequence of:
len *= str_copy(dest + len, dest_len - len, src);
But don't really want to test for overflow after each call.
This is a legitimate use of strscpy(). Please, add it to glibc, as
there is no libc function to do that.
In this case returning the buffer length (including the added
'\0' on truncation works quite nicely.
No chance of writing outside the buffer, safe truncation and
a simple 'len == dest_len' check for overflow.
OTOH there are already too many string copy functions.
There are, but because the standard ones don't serve all purposes
correctly, so people need to develop their own. If libc provided the
necessary functions, less custom string copy functions would be
necessary, as Christoph said a long time ago, which is a good thing.
As I see it, there are the following, each of which has its valid usage:
strcpy(3):
known input && known buffer
strncpy(3):
not for C strings; only for fixed width buffers of characters!
strlcpy)3bsd):
known input && unknown buffer
Given that performance-wise it's similar to strscpy(),
it should probably always be replaced by strscpy().
strscpy():
unknown input && truncation is silently ignored
Except for performance-critical applications,
this call may replace strcpy(3), to add some extra safety.
strcpys():
unknown input && truncation may be an error (or not).
This call can replace strscpy() in most cases,
simplifying usage.
The only case I can see that strscpy() is superior
is for chains of strscpy(), where I'd only use strcpys()
in the last one (if any strscpy() in the chain has been
trunncated, so will the last strcpys() (unless it's "")).
For the reasons above, I propose both strscpy() and strcpys() for
inclusion in glibc. Both trivial sources are in the previous email.
Thanks,
Alex
---
BTW, I did some research in the kernel and glibc sources to see how are
str*cpy functions being used there:
Re: uao references & uao_swap_off() cleanup
On 23/06/21(Wed) 23:03, Jonathan Matthew wrote: > On Wed, Jun 23, 2021 at 09:37:10AM +0200, Martin Pieuchot wrote: > > On 16/06/21(Wed) 11:26, Martin Pieuchot wrote: > > > Diff below does two things: > > > > > > - Use atomic operations for incrementing/decrementing references of > > > anonymous objects. This allows us to manipulate them without holding > > > the KERNEL_LOCK(). > > > > > > - Rewrite the loop from uao_swap_off() to only keep a reference to the > > > next item in the list. This is imported from NetBSD and is necessary > > > to introduce locking around uao_pagein(). > > > > > > ok? > > > > Anyone? > > uao_reference_locked() and uao_detach_locked() are prototyped in > uvm_extern.h, so they should be removed here too. Thanks, I'll do that. > It doesn't look like uao_detach() is safe to call without the > kernel lock; it calls uao_dropswap() for each page, which calls > uao_set_swslot(), which includes a KERNEL_ASSERT_LOCKED(). > Should we keep the KERNEL_ASSERT_LOCKED() in uao_detach()? I prefer to keep the KERNEL_ASSERT_LOCKED() where it is needed and not spread it to all the callers. My current plan is to trade those assert by assertions on the vmobjlock so I don't want to add new ones.
Re: tcpdump: print 802.11 sequence numbers properly
On Mon, Jun 28, 2021 at 11:46:37AM +0200, Stefan Sperling wrote: > tcpdump -e -v -y IEEE802_11_RADIO currently prints sequence number > and fragment number as a combined decimal value. > > This patch makes tcpdump display these values separately which is a lot > easier to follow along as packets scroll by. Now sequence numbers (modulo fragments) happen to increment by one in tcpdump's output as one would usually expect. I looked at 802.11 just yesterday trying to figure out why the wifi is crap, the logs contain a lot and it can be daunting at first; this is definitely an improvement. OK kn
tcpdump: print 802.11 sequence numbers properly
tcpdump -e -v -y IEEE802_11_RADIO currently prints sequence number
and fragment number as a combined decimal value.
This patch makes tcpdump display these values separately which is a lot
easier to follow along as packets scroll by.
ok?
diff 18a81a05d6e3098eadc4b5e23d6656377f87591a /usr/src
blob - 7528f50e45765f83d5d719d831df2880838bc28c
file + usr.sbin/tcpdump/print-802_11.c
--- usr.sbin/tcpdump/print-802_11.c
+++ usr.sbin/tcpdump/print-802_11.c
@@ -162,7 +162,9 @@ ieee80211_hdr(struct ieee80211_frame *wh)
u_int16_t seq;
TCARR(wh->i_seq);
bcopy(wh->i_seq, , sizeof(u_int16_t));
- printf(" (seq %u): ", letoh16(seq));
+ printf(" (seq %u frag %u): ",
+ letoh16(seq) >> IEEE80211_SEQ_SEQ_SHIFT,
+ letoh16(seq) & IEEE80211_SEQ_FRAG_MASK);
} else
printf(": ");
