Re: refactor mbuf parsing on driver level
On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote: > On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote: > > Hi, > > > > we have several drivers which have to parse the content of mbufs. This > > diff suggest a central parsing function for this. Thus, we can reduce > > redundant code. > > > > I just start with ix(4) and ixl(4) because it was easy to test for me. > > But, this could also improve em(4), igc(4), ale(4) and oce(4). > > > > I'm not sure about the name, the api nor the place of this code. So, if > > someone has a better idea: i'm open to anything. > > > > bye, > > Jan > > > > Hi, > > I like code this deduplication. I like this code deduplication.
Re: refactor mbuf parsing on driver level
On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote:
> Hi,
>
> we have several drivers which have to parse the content of mbufs. This
> diff suggest a central parsing function for this. Thus, we can reduce
> redundant code.
>
> I just start with ix(4) and ixl(4) because it was easy to test for me.
> But, this could also improve em(4), igc(4), ale(4) and oce(4).
>
> I'm not sure about the name, the api nor the place of this code. So, if
> someone has a better idea: i'm open to anything.
>
> bye,
> Jan
>
Hi,
I like code this deduplication.
This newly introduced function doesn't touch ifnet but only extracts
protocol headers from mbuf(9). I guess mbuf_extract_headers() or
something like is much better for name with the ern/uipc_mbuf2.c as
place.
> Index: dev/pci/if_ix.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
> retrieving revision 1.189
> diff -u -p -r1.189 if_ix.c
> --- dev/pci/if_ix.c 2 Sep 2022 14:08:09 - 1.189
> +++ dev/pci/if_ix.c 17 Jan 2023 16:31:19 -
> @@ -2477,23 +2477,18 @@ static inline int
> ixgbe_csum_offload(struct mbuf *mp, uint32_t *vlan_macip_lens,
> uint32_t *type_tucmd_mlhl, uint32_t *olinfo_status)
> {
> - struct ether_header *eh = mtod(mp, struct ether_header *);
> - struct mbuf *m;
> - int hoff;
> + struct ether_header *eh = NULL;
> + struct ip *ip = NULL;
> + struct ip6_hdr *ip6 = NULL;
> int offload = 0;
> uint32_t iphlen;
> uint8_t ipproto;
>
> - *vlan_macip_lens |= (sizeof(*eh) << IXGBE_ADVTXD_MACLEN_SHIFT);
> + if_parse(mp, , , , NULL, NULL);
>
> - switch (ntohs(eh->ether_type)) {
> - case ETHERTYPE_IP: {
> - struct ip *ip;
> -
> - m = m_getptr(mp, sizeof(*eh), );
> - KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip));
> - ip = (struct ip *)(mtod(m, caddr_t) + hoff);
> + *vlan_macip_lens |= (sizeof(*eh) << IXGBE_ADVTXD_MACLEN_SHIFT);
>
> + if (ip) {
> iphlen = ip->ip_hl << 2;
> ipproto = ip->ip_p;
>
> @@ -2503,26 +2498,14 @@ ixgbe_csum_offload(struct mbuf *mp, uint
> }
>
> *type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV4;
> - break;
> - }
> -
> #ifdef INET6
> - case ETHERTYPE_IPV6: {
> - struct ip6_hdr *ip6;
> -
> - m = m_getptr(mp, sizeof(*eh), );
> - KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip6));
> - ip6 = (struct ip6_hdr *)(mtod(m, caddr_t) + hoff);
> -
> + } else if (ip6) {
> iphlen = sizeof(*ip6);
> ipproto = ip6->ip6_nxt;
>
> *type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV6;
> - break;
> - }
> #endif
> -
> - default:
> + } else {
> return offload;
> }
>
> Index: dev/pci/if_ixl.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_ixl.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 if_ixl.c
> --- dev/pci/if_ixl.c 5 Aug 2022 13:57:16 - 1.84
> +++ dev/pci/if_ixl.c 16 Jan 2023 23:58:05 -
> @@ -2784,12 +2784,15 @@ ixl_load_mbuf(bus_dma_tag_t dmat, bus_dm
> static uint64_t
> ixl_tx_setup_offload(struct mbuf *m0)
> {
> - struct mbuf *m;
> - int hoff;
> + struct ether_header *eh = NULL;
> + struct ip *ip = NULL;
> + struct ip6_hdr *ip6 = NULL;
> + struct tcphdr *th = NULL;
> uint64_t hlen;
> uint8_t ipproto;
> uint64_t offload = 0;
>
> +
> if (ISSET(m0->m_flags, M_VLANTAG)) {
> uint64_t vtag = m0->m_pkthdr.ether_vtag;
> offload |= IXL_TX_DESC_CMD_IL2TAG1;
> @@ -2800,39 +2803,23 @@ ixl_tx_setup_offload(struct mbuf *m0)
> M_IPV4_CSUM_OUT|M_TCP_CSUM_OUT|M_UDP_CSUM_OUT))
> return (offload);
>
> - switch (ntohs(mtod(m0, struct ether_header *)->ether_type)) {
> - case ETHERTYPE_IP: {
> - struct ip *ip;
> -
> - m = m_getptr(m0, ETHER_HDR_LEN, );
> - KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip));
> - ip = (struct ip *)(mtod(m, caddr_t) + hoff);
> + if_parse(m0, , , , , NULL);
>
> + if (ip) {
> offload |= ISSET(m0->m_pkthdr.csum_flags, M_IPV4_CSUM_OUT) ?
> IXL_TX_DESC_CMD_IIPT_IPV4_CSUM :
> IXL_TX_DESC_CMD_IIPT_IPV4;
>
> hlen = ip->ip_hl << 2;
> ipproto = ip->ip_p;
> - break;
> - }
> -
> #ifdef INET6
> - case ETHERTYPE_IPV6: {
> - struct ip6_hdr *ip6;
> -
> - m = m_getptr(m0, ETHER_HDR_LEN, );
> - KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip6));
> - ip6 = (struct ip6_hdr *)(mtod(m, caddr_t) + hoff);
> -
> + } else if (ip6) {
> offload |= IXL_TX_DESC_CMD_IIPT_IPV6;
>
> hlen = sizeof(*ip6);
>
Explicitly opt into checking policies
Until a few minutes ago, the new validator checked policies by default.
The legacy validator and OpenSSL don't do so. Let's explicitly enable
policy checks for all these validators (X509_V_FLAG_EXPLICIT_POLICY is
not enough - our X509_VERIFY_PARAM_set_flags() manual even calls out
that trap).
Index: validate.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/validate.c,v
retrieving revision 1.52
diff -u -p -r1.52 validate.c
--- validate.c 4 Jan 2023 14:22:43 - 1.52
+++ validate.c 4 Jan 2023 21:42:10 -
@@ -396,6 +396,7 @@ valid_x509(char *file, X509_STORE_CTX *s
cryptoerrx("X509_VERIFY_PARAM_add0_policy");
flags = X509_V_FLAG_CRL_CHECK;
+ flags |= X509_V_FLAG_POLICY_CHECK;
flags |= X509_V_FLAG_EXPLICIT_POLICY;
flags |= X509_V_FLAG_INHIBIT_MAP;
X509_STORE_CTX_set_flags(store_ctx, flags);
Re: Preferred TERM for pkg_add
On Mon, Jan 09, 2023 at 01:52:03PM +, Nicholas Marriott wrote: > > From a quick look it will happily fall back to carriage return and space > if the capabilities it would prefer (el and hpa/RI) are not present, so > probably anything would do. > > Or you could check if the terminfo entry existed with something like > "tput el >/dev/null 2>&1" before running pkg_add. > Thanks for taking a look and suggesting how to detect available terminfo entries. To keep things simple it seems we can start with a static value. We can always make it more dynamic later if needed. As for dumb vs unknown it seems dumb has one less capability: ``` $ infocmp dumb # Reconstructed via infocmp from file: /usr/share/terminfo/d/dumb dumb|80-column dumb tty, am, cols#80, bel=^G, cr=^M, cud1=^J, ind=^J, $ infocmp unknown # Reconstructed via infocmp from file: /usr/share/terminfo/u/unknown unknown|unknown terminal type, am, gn, cols#80, bel=^G, cr=^M, cud1=^J, ind=^J, ``` They are identical except for unknown also having the "gn" capability (generic line type as defined in terminfo(5)). So just going with the "least capable" dumb seems like a good start. Regards, Patrik Lundin
Re: mem.4: be more accurate about securelevel
On Tue, Jan 17, 2023 at 11:02:07PM +0100, Theo Buehler wrote: > > at least this tool works for me: > > Surely you have kern.allowkmem=1 set. Yes, I do.
refactor mbuf parsing on driver level
Hi,
we have several drivers which have to parse the content of mbufs. This
diff suggest a central parsing function for this. Thus, we can reduce
redundant code.
I just start with ix(4) and ixl(4) because it was easy to test for me.
But, this could also improve em(4), igc(4), ale(4) and oce(4).
I'm not sure about the name, the api nor the place of this code. So, if
someone has a better idea: i'm open to anything.
bye,
Jan
Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.189
diff -u -p -r1.189 if_ix.c
--- dev/pci/if_ix.c 2 Sep 2022 14:08:09 - 1.189
+++ dev/pci/if_ix.c 17 Jan 2023 16:31:19 -
@@ -2477,23 +2477,18 @@ static inline int
ixgbe_csum_offload(struct mbuf *mp, uint32_t *vlan_macip_lens,
uint32_t *type_tucmd_mlhl, uint32_t *olinfo_status)
{
- struct ether_header *eh = mtod(mp, struct ether_header *);
- struct mbuf *m;
- int hoff;
+ struct ether_header *eh = NULL;
+ struct ip *ip = NULL;
+ struct ip6_hdr *ip6 = NULL;
int offload = 0;
uint32_t iphlen;
uint8_t ipproto;
- *vlan_macip_lens |= (sizeof(*eh) << IXGBE_ADVTXD_MACLEN_SHIFT);
+ if_parse(mp, , , , NULL, NULL);
- switch (ntohs(eh->ether_type)) {
- case ETHERTYPE_IP: {
- struct ip *ip;
-
- m = m_getptr(mp, sizeof(*eh), );
- KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip));
- ip = (struct ip *)(mtod(m, caddr_t) + hoff);
+ *vlan_macip_lens |= (sizeof(*eh) << IXGBE_ADVTXD_MACLEN_SHIFT);
+ if (ip) {
iphlen = ip->ip_hl << 2;
ipproto = ip->ip_p;
@@ -2503,26 +2498,14 @@ ixgbe_csum_offload(struct mbuf *mp, uint
}
*type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV4;
- break;
- }
-
#ifdef INET6
- case ETHERTYPE_IPV6: {
- struct ip6_hdr *ip6;
-
- m = m_getptr(mp, sizeof(*eh), );
- KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip6));
- ip6 = (struct ip6_hdr *)(mtod(m, caddr_t) + hoff);
-
+ } else if (ip6) {
iphlen = sizeof(*ip6);
ipproto = ip6->ip6_nxt;
*type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV6;
- break;
- }
#endif
-
- default:
+ } else {
return offload;
}
Index: dev/pci/if_ixl.c
===
RCS file: /cvs/src/sys/dev/pci/if_ixl.c,v
retrieving revision 1.84
diff -u -p -r1.84 if_ixl.c
--- dev/pci/if_ixl.c5 Aug 2022 13:57:16 - 1.84
+++ dev/pci/if_ixl.c16 Jan 2023 23:58:05 -
@@ -2784,12 +2784,15 @@ ixl_load_mbuf(bus_dma_tag_t dmat, bus_dm
static uint64_t
ixl_tx_setup_offload(struct mbuf *m0)
{
- struct mbuf *m;
- int hoff;
+ struct ether_header *eh = NULL;
+ struct ip *ip = NULL;
+ struct ip6_hdr *ip6 = NULL;
+ struct tcphdr *th = NULL;
uint64_t hlen;
uint8_t ipproto;
uint64_t offload = 0;
+
if (ISSET(m0->m_flags, M_VLANTAG)) {
uint64_t vtag = m0->m_pkthdr.ether_vtag;
offload |= IXL_TX_DESC_CMD_IL2TAG1;
@@ -2800,39 +2803,23 @@ ixl_tx_setup_offload(struct mbuf *m0)
M_IPV4_CSUM_OUT|M_TCP_CSUM_OUT|M_UDP_CSUM_OUT))
return (offload);
- switch (ntohs(mtod(m0, struct ether_header *)->ether_type)) {
- case ETHERTYPE_IP: {
- struct ip *ip;
-
- m = m_getptr(m0, ETHER_HDR_LEN, );
- KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip));
- ip = (struct ip *)(mtod(m, caddr_t) + hoff);
+ if_parse(m0, , , , , NULL);
+ if (ip) {
offload |= ISSET(m0->m_pkthdr.csum_flags, M_IPV4_CSUM_OUT) ?
IXL_TX_DESC_CMD_IIPT_IPV4_CSUM :
IXL_TX_DESC_CMD_IIPT_IPV4;
hlen = ip->ip_hl << 2;
ipproto = ip->ip_p;
- break;
- }
-
#ifdef INET6
- case ETHERTYPE_IPV6: {
- struct ip6_hdr *ip6;
-
- m = m_getptr(m0, ETHER_HDR_LEN, );
- KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip6));
- ip6 = (struct ip6_hdr *)(mtod(m, caddr_t) + hoff);
-
+ } else if (ip6) {
offload |= IXL_TX_DESC_CMD_IIPT_IPV6;
hlen = sizeof(*ip6);
ipproto = ip6->ip6_nxt;
- break;
- }
#endif
- default:
+ } else {
panic("CSUM_OUT set for non-IP packet");
/* NOTREACHED */
}
@@ -2842,15 +2829,12 @@ ixl_tx_setup_offload(struct mbuf *m0)
switch (ipproto) {
case IPPROTO_TCP: {
- struct tcphdr *th;
-
if (!ISSET(m0->m_pkthdr.csum_flags, M_TCP_CSUM_OUT))
Re: mem.4: be more accurate about securelevel
> at least this tool works for me: Surely you have kern.allowkmem=1 set.
Re: mem.4: be more accurate about securelevel
On Tue, Jan 17, 2023 at 04:23:48PM -0500, Bryan Steele wrote:
> On Tue, Jan 17, 2023 at 09:37:24PM +0100, Jan Klemkow wrote:
> > Hi,
> >
> > This diff adjust the manpage of mem(4) to be more accurate. You can
> > open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
> >
> > kern/spec_vnops.c:
> >
> > if (ap->a_cred != FSCRED && (ap->a_mode & FWRITE)) {
> > ...
> > /*
> > * When running in secure mode, do not allow opens
> > * for writing of /dev/mem, /dev/kmem, or character
> > * devices whose corresponding block devices are
> > * currently mounted.
> > */
> > if (securelevel >= 1) {
> > ...
> > if (iskmemdev(dev))
> > return (EPERM);
> > }
> > }
> >
> > OK?
> >
> > bye,
> > Jan
>
> Are you sure about that? Have you tested it?
>
> https://github.com/openbsd/src/commit/19aedf236181e81baf170421900911c82671fae4
at least this tool works for me:
#include
#include
#include
#include
#include
#include
#include
int
main(void)
{
kvm_t *kd;
int mem;
struct nlist nl[] = {
{"_ix_debug_ioctl"},
{NULL}
};
char errbuf[_POSIX2_LINE_MAX];
if ((kd = kvm_open(_PATH_KSYMS, NULL, NULL, O_RDWR, errbuf)) == NULL)
errx(EXIT_FAILURE, "%s", errbuf);
if (kvm_nlist(kd, nl) == -1)
errx(EXIT_SUCCESS, "%s", kvm_geterr(kd));
if (kvm_read(kd, nl[0].n_value, , sizeof mem) != sizeof(mem))
errx(EXIT_SUCCESS, "%s", kvm_geterr(kd));
printf("mem: %d\n", mem);
mem = 1;
if (kvm_write(kd, nl[0].n_value, , sizeof mem) != sizeof(mem))
errx(EXIT_SUCCESS, "%s", kvm_geterr(kd));
if (kvm_close(kd) == -1)
err(EXIT_FAILURE, "kvm_close");
return EXIT_SUCCESS;
}
Re: mem.4: be more accurate about securelevel
On Tue, Jan 17, 2023 at 09:37:24PM +0100, Jan Klemkow wrote:
> Hi,
>
> This diff adjust the manpage of mem(4) to be more accurate. You can
> open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
>
> kern/spec_vnops.c:
>
> if (ap->a_cred != FSCRED && (ap->a_mode & FWRITE)) {
> ...
> /*
>* When running in secure mode, do not allow opens
>* for writing of /dev/mem, /dev/kmem, or character
>* devices whose corresponding block devices are
>* currently mounted.
>*/
> if (securelevel >= 1) {
> ...
> if (iskmemdev(dev))
> return (EPERM);
> }
> }
>
> OK?
>
> bye,
> Jan
Are you sure about that? Have you tested it?
https://github.com/openbsd/src/commit/19aedf236181e81baf170421900911c82671fae4
> Index: man4.alpha/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.alpha/mem.4,v
> retrieving revision 1.6
> diff -u -p -r1.6 mem.4
> --- man4.alpha/mem.4 12 Jan 2018 04:36:44 - 1.6
> +++ man4.alpha/mem.4 17 Jan 2023 18:51:10 -
> @@ -62,7 +62,7 @@ kernel virtual memory begins at
> .Li 0xfc23 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.amd64/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.amd64/mem.4,v
> retrieving revision 1.6
> diff -u -p -r1.6 mem.4
> --- man4.amd64/mem.4 12 Jan 2018 04:36:44 - 1.6
> +++ man4.amd64/mem.4 17 Jan 2023 18:48:23 -
> @@ -63,7 +63,7 @@ The kernel virtual memory begins at addr
> .Li 0x8000 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.hppa/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.hppa/mem.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 mem.4
> --- man4.hppa/mem.4 12 Jan 2018 04:36:44 - 1.4
> +++ man4.hppa/mem.4 17 Jan 2023 18:52:28 -
> @@ -51,7 +51,7 @@ On hppa, the physical memory range is al
> address 0; kernel virtual memory begins at address 0 as well.
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.i386/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.i386/mem.4,v
> retrieving revision 1.12
> diff -u -p -r1.12 mem.4
> --- man4.i386/mem.4 12 Jan 2018 04:36:44 - 1.12
> +++ man4.i386/mem.4 17 Jan 2023 18:53:00 -
> @@ -63,7 +63,7 @@ long, and ends at virtual address
> .Li 0xfe00 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.landisk/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.landisk/mem.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 mem.4
> --- man4.landisk/mem.412 Jan 2018 04:36:44 - 1.4
> +++ man4.landisk/mem.417 Jan 2023 18:53:54 -
> @@ -58,7 +58,7 @@ The kernel virtual memory begins at addr
> .Li 0xc000 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.loongson/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.loongson/mem.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 mem.4
> --- man4.loongson/mem.4 12 Jan 2018 04:36:44 - 1.4
> +++ man4.loongson/mem.4 17 Jan 2023 18:54:33 -
> @@ -88,7 +88,7 @@ The kernel virtual memory begins at addr
> .Ad 0xc000 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.luna88k/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.luna88k/mem.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 mem.4
> --- man4.luna88k/mem.412 Jan 2018
Re: mem.4: be more accurate about securelevel
17.01.2023 20:37, Jan Klemkow пишет:
> Hi,
>
> This diff adjust the manpage of mem(4) to be more accurate. You can
> open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
securelevel(7) still says
1 Secure mode
...
- /dev/mem and /dev/kmem cannot be opened
"securelevel.7: Clarify mem(4) semantics" tried to fix it two years ago:
https://marc.info/?l=openbsd-tech=157945224915525=2
>
> kern/spec_vnops.c:
>
> if (ap->a_cred != FSCRED && (ap->a_mode & FWRITE)) {
> ...
> /*
>* When running in secure mode, do not allow opens
>* for writing of /dev/mem, /dev/kmem, or character
>* devices whose corresponding block devices are
>* currently mounted.
>*/
> if (securelevel >= 1) {
> ...
> if (iskmemdev(dev))
> return (EPERM);
> }
> }
>
> OK?
>
> bye,
> Jan
>
> Index: man4.alpha/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.alpha/mem.4,v
> retrieving revision 1.6
> diff -u -p -r1.6 mem.4
> --- man4.alpha/mem.4 12 Jan 2018 04:36:44 - 1.6
> +++ man4.alpha/mem.4 17 Jan 2023 18:51:10 -
> @@ -62,7 +62,7 @@ kernel virtual memory begins at
> .Li 0xfc23 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.amd64/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.amd64/mem.4,v
> retrieving revision 1.6
> diff -u -p -r1.6 mem.4
> --- man4.amd64/mem.4 12 Jan 2018 04:36:44 - 1.6
> +++ man4.amd64/mem.4 17 Jan 2023 18:48:23 -
> @@ -63,7 +63,7 @@ The kernel virtual memory begins at addr
> .Li 0x8000 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.hppa/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.hppa/mem.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 mem.4
> --- man4.hppa/mem.4 12 Jan 2018 04:36:44 - 1.4
> +++ man4.hppa/mem.4 17 Jan 2023 18:52:28 -
> @@ -51,7 +51,7 @@ On hppa, the physical memory range is al
> address 0; kernel virtual memory begins at address 0 as well.
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.i386/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.i386/mem.4,v
> retrieving revision 1.12
> diff -u -p -r1.12 mem.4
> --- man4.i386/mem.4 12 Jan 2018 04:36:44 - 1.12
> +++ man4.i386/mem.4 17 Jan 2023 18:53:00 -
> @@ -63,7 +63,7 @@ long, and ends at virtual address
> .Li 0xfe00 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.landisk/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.landisk/mem.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 mem.4
> --- man4.landisk/mem.412 Jan 2018 04:36:44 - 1.4
> +++ man4.landisk/mem.417 Jan 2023 18:53:54 -
> @@ -58,7 +58,7 @@ The kernel virtual memory begins at addr
> .Li 0xc000 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.loongson/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.loongson/mem.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 mem.4
> --- man4.loongson/mem.4 12 Jan 2018 04:36:44 - 1.4
> +++ man4.loongson/mem.4 17 Jan 2023 18:54:33 -
> @@ -88,7 +88,7 @@ The kernel virtual memory begins at addr
> .Ad 0xc000 .
> .Pp
> Even with sufficient file system permissions,
> -these devices can only be opened when the
> +these devices can only be opened writable when the
> .Xr securelevel 7
> is insecure or when the
> .Va kern.allowkmem
> Index: man4.luna88k/mem.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.luna88k/mem.4,v
>
Simplified strtonum(3)
Hi @tech,
The bottom of this email contains a simplified strtonum implementation.
It should behave exactly the same way as the existing strtonum, but it
doesn't call strtoll, which means we can drop some unnecessary
complexity:
- No base conversion
- No need to save and restore errno (which is a bigger deal than it
sounds like because of the weird mutable array-of-structures that's
used to recover errno in the existing strtonum.c)
- No complicated sign-dependent "cutoff/cutlim" tests like the ones we
see in strtoll.
That last point is most interesting. We're doing our 10*accumulator + d
arithmetic in a 64-bit register, but we can report overflow as soon as
we blow past 2^63 = -LLONG_MIN, which means that we have a bit of
headroom in which we have some wiggle room when we try to determine
whether 10*accumulator + d will cause an integer overflow in the
register itself.
Let "max = (-LLONG_MIN) / 10 + 1" be an unsigned compile-time constant,
let "acc" be an unsigned accumulator, and let 0 <= d <= 9 be a digit.
Then checking for overflow when computing 10*acc + d is easy because of
the following two theorems:
[1] If (acc <= max) then 10*acc + d <= ULLONG_MAX
[2] If (acc > max) then 10*acc + d > -LLONG_MIN > LLONG_MAX
Proof:
[1] Suppose acc <= max. Then:
10*acc + d <= 10*max + d
= 10*(floor(2^63/10) + 1) + d
<= 10*(2^63/10 + 1) + d
= 10*2^63/10 + 10 + d
= 2^63 + 10 + d
<= 2^63 + 19
<= ULLONG_MAX
[2] Suppose acc > max. Then:
-LLONG_MIN = 2^63
= 10*(2^63/10)
< 10*(floor(2^63/10) + 1)
= 10*max
< 10*acc
<= 10*acc + d
The meaning of [1] is that if (acc <= max) then 10*acc + d will not
overflow an unsigned buffer; the meaning of [2] is that if (acc > max)
then you're guaranteed to overflow the buffer so there's no need to
bother reading the digit. Thus we can loop through the digit-string "s"
with the following loop:
unsigned long long acc = 0;
do {
char c = *s++;
if (!isdigit(c))return ERROR_INVALID;
else if (acc > max) return ERROR_OVERFLOW;
acc = 10*acc + (c - '0');
} while (*++s);
puts("acc did not overflow");
There are five possibilities:
1. If the string is empty, this returns ERROR_INVALID.
2. If the string has non-digit characters, this returns ERROR_INVALID.
3. If the number > ULLONG_MAX, this returns ERROR_OVERFLOW.
4. If the number <= -LLONG_MIN, this prints "acc did not overflow."
5. If -LLONG_MIN <= number <= ULLONG_MAX then the loop may either
return ERROR_OVERFLOW or successfully print "acc did not overflow."
The underlying number should count as having overflowed because
neither it nor its negative can fit in a long long, but we will
handle this case in the next step.
The next thing we do is correct the sign. If "neg" is a boolean which
tells whether a minus sign preceded the digit string, the following
code will jam our unsigned quantity "acc" into the signed variable "ll"
and test for overflow. Note that -LLONG_MIN == LLONG_MIN but that this
code handles that case correctly whether neg is true or false:
unsigned long long acc =
long long ll;
if (neg) {
ll = -acc;
if (ll > 0) return ERROR_TOOSMALL;
} else {
ll = acc;
if (ll < 0) return ERROR_TOOLARGE;
}
puts("ll did not overflow!");
If we're still here, then ll has not been truncated, so we can compare
against the user-defined minval and maxval:
if (ll < minval)return ERROR_TOOSMALL;
else if (ll > maxval) return ERROR_TOOLARGE;
elsereturn SUCCESS;
That's basically it. I'll mention that similar logic can be used in
strtol and strtoll. If we redo the proofs of [1] and [2] with an
arbitrary base in place of the number 10 we find that the proof of
property [2] doesn't change, and the only questionable part of the
proof of property [1] is the last two steps, which rely on the
assumption that:
-INT_MIN + base + d <= UINT_MAX
We know that d < base, and on a two's complement machine (which I
believe is required by POSIX) this will hold whenever:
-INT_MIN + base + d <= UINT_MAX
-INT_MIN + base + (base-1) <= UINT_MAX
-INT_MIN + 2*base - 1 <= UINT_MAX
2*base <= (UINT_MAX + 1) + INT_MIN
2*base <= 2^w - 2^(w-1)
2*base <= 2^(w-1)
base <= 2^(w-2)
The strto* family of functions support only base <= 36, and the C
standard requires a word size of w >= 16 for integers, so we have
plenty of space between -INT_MIN and UINT_MAX:
base <= 36 <= 16384 = 2^(16 - 2) <= 2^(w-2)
That said, because this
mem.4: be more accurate about securelevel
Hi,
This diff adjust the manpage of mem(4) to be more accurate. You can
open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
kern/spec_vnops.c:
if (ap->a_cred != FSCRED && (ap->a_mode & FWRITE)) {
...
/*
* When running in secure mode, do not allow opens
* for writing of /dev/mem, /dev/kmem, or character
* devices whose corresponding block devices are
* currently mounted.
*/
if (securelevel >= 1) {
...
if (iskmemdev(dev))
return (EPERM);
}
}
OK?
bye,
Jan
Index: man4.alpha/mem.4
===
RCS file: /cvs/src/share/man/man4/man4.alpha/mem.4,v
retrieving revision 1.6
diff -u -p -r1.6 mem.4
--- man4.alpha/mem.412 Jan 2018 04:36:44 - 1.6
+++ man4.alpha/mem.417 Jan 2023 18:51:10 -
@@ -62,7 +62,7 @@ kernel virtual memory begins at
.Li 0xfc23 .
.Pp
Even with sufficient file system permissions,
-these devices can only be opened when the
+these devices can only be opened writable when the
.Xr securelevel 7
is insecure or when the
.Va kern.allowkmem
Index: man4.amd64/mem.4
===
RCS file: /cvs/src/share/man/man4/man4.amd64/mem.4,v
retrieving revision 1.6
diff -u -p -r1.6 mem.4
--- man4.amd64/mem.412 Jan 2018 04:36:44 - 1.6
+++ man4.amd64/mem.417 Jan 2023 18:48:23 -
@@ -63,7 +63,7 @@ The kernel virtual memory begins at addr
.Li 0x8000 .
.Pp
Even with sufficient file system permissions,
-these devices can only be opened when the
+these devices can only be opened writable when the
.Xr securelevel 7
is insecure or when the
.Va kern.allowkmem
Index: man4.hppa/mem.4
===
RCS file: /cvs/src/share/man/man4/man4.hppa/mem.4,v
retrieving revision 1.4
diff -u -p -r1.4 mem.4
--- man4.hppa/mem.4 12 Jan 2018 04:36:44 - 1.4
+++ man4.hppa/mem.4 17 Jan 2023 18:52:28 -
@@ -51,7 +51,7 @@ On hppa, the physical memory range is al
address 0; kernel virtual memory begins at address 0 as well.
.Pp
Even with sufficient file system permissions,
-these devices can only be opened when the
+these devices can only be opened writable when the
.Xr securelevel 7
is insecure or when the
.Va kern.allowkmem
Index: man4.i386/mem.4
===
RCS file: /cvs/src/share/man/man4/man4.i386/mem.4,v
retrieving revision 1.12
diff -u -p -r1.12 mem.4
--- man4.i386/mem.4 12 Jan 2018 04:36:44 - 1.12
+++ man4.i386/mem.4 17 Jan 2023 18:53:00 -
@@ -63,7 +63,7 @@ long, and ends at virtual address
.Li 0xfe00 .
.Pp
Even with sufficient file system permissions,
-these devices can only be opened when the
+these devices can only be opened writable when the
.Xr securelevel 7
is insecure or when the
.Va kern.allowkmem
Index: man4.landisk/mem.4
===
RCS file: /cvs/src/share/man/man4/man4.landisk/mem.4,v
retrieving revision 1.4
diff -u -p -r1.4 mem.4
--- man4.landisk/mem.4 12 Jan 2018 04:36:44 - 1.4
+++ man4.landisk/mem.4 17 Jan 2023 18:53:54 -
@@ -58,7 +58,7 @@ The kernel virtual memory begins at addr
.Li 0xc000 .
.Pp
Even with sufficient file system permissions,
-these devices can only be opened when the
+these devices can only be opened writable when the
.Xr securelevel 7
is insecure or when the
.Va kern.allowkmem
Index: man4.loongson/mem.4
===
RCS file: /cvs/src/share/man/man4/man4.loongson/mem.4,v
retrieving revision 1.4
diff -u -p -r1.4 mem.4
--- man4.loongson/mem.4 12 Jan 2018 04:36:44 - 1.4
+++ man4.loongson/mem.4 17 Jan 2023 18:54:33 -
@@ -88,7 +88,7 @@ The kernel virtual memory begins at addr
.Ad 0xc000 .
.Pp
Even with sufficient file system permissions,
-these devices can only be opened when the
+these devices can only be opened writable when the
.Xr securelevel 7
is insecure or when the
.Va kern.allowkmem
Index: man4.luna88k/mem.4
===
RCS file: /cvs/src/share/man/man4/man4.luna88k/mem.4,v
retrieving revision 1.4
diff -u -p -r1.4 mem.4
--- man4.luna88k/mem.4 12 Jan 2018 04:36:44 - 1.4
+++ man4.luna88k/mem.4 17 Jan 2023 18:54:47 -
@@ -62,7 +62,7 @@ kernel virtual memory begins at
.Ad 0x .
.Pp
Even with sufficient file system permissions,
-these devices can only be opened when the
+these devices can only be opened writable when the
.Xr securelevel 7
is insecure or when the
.Va kern.allowkmem
Index: man4.macppc/mem.4
Re: help wanted for a specific clang diff
On Tue, Jan 17, 2023 at 02:14:20PM +0100, Sebastien Marie wrote:
> On Mon, Jan 16, 2023 at 12:00:30PM -0700, Theo de Raadt wrote:
> > For this xonly work, we are having to one-by-one find .S files that
> > are putting data tables into the .text segment
> >
> > I am hoping to find someone who can do c++ well enough, and maybe
> > has some familiarity with the clang code, to add a warning message
> > for this
> >
> > if a .long, .quad, .byte are placed into a .text section, issue
> > a warning, then we'll be able to identify all these in a ports build
> > and decide which need manual fixing, and move the objects into .rodata
> > and apply __PIC__ handling as neccessary
> >
> > Yes, there are cases where people use .long to inject an instruction
> > they don't believe the assembler has. We can ignore those by inspect.
> >
> > Can anyone help? It doesn't need to be fancy, it just needs to get
> > us moving faster.
> >
> > Thanks
> >
>
> The following diff seems to work. It adds a warning inside assembler parsers.
>
New diff with warning message simpler to grep.
test.S:29:8: warning: directive value inside .text section: directive
'.byte', section '.text'
$ grep -F "directive value inside .text section:"
--
Sebastien Marie
diff /home/semarie/repos/openbsd/src
commit - b18ed08defc1c5e5b4be701ce5ef913bda8ae66a
path + /home/semarie/repos/openbsd/src
blob - 047ed1660a837e77561b1f2839ec9601f9582a7e
file + gnu/llvm/llvm/lib/MC/MCParser/AsmParser.cpp
--- gnu/llvm/llvm/lib/MC/MCParser/AsmParser.cpp
+++ gnu/llvm/llvm/lib/MC/MCParser/AsmParser.cpp
@@ -3168,6 +3168,12 @@ bool AsmParser::parseDirectiveValue(StringRef IDVal, u
SMLoc ExprLoc = getLexer().getLoc();
if (checkForValidSection() || parseExpression(Value))
return true;
+// Check for directive inside .text
+const MCSection *Section = getStreamer().getCurrentSectionOnly();
+const StringRef sectionName = Section->getName();
+if (sectionName.equals(".text") || sectionName.startswith(".text."))
+ Warning(ExprLoc, "directive value inside .text section: "
+"directive '" + Twine(IDVal) + "', section '" + Twine(sectionName) +
"'");
// Special case constant expressions to match code generator.
if (const MCConstantExpr *MCE = dyn_cast(Value)) {
assert(Size <= 8 && "Invalid size");
blob - 7b4d6e529cc2c3c4efce05f62f41620658d7a8e0
file + gnu/llvm/llvm/lib/MC/MCParser/MasmParser.cpp
--- gnu/llvm/llvm/lib/MC/MCParser/MasmParser.cpp
+++ gnu/llvm/llvm/lib/MC/MCParser/MasmParser.cpp
@@ -3809,6 +3809,14 @@ bool MasmParser::parseDirectiveValue(StringRef IDVal,
/// parseDirectiveValue
/// ::= (byte | word | ... ) [ expression (, expression)* ]
bool MasmParser::parseDirectiveValue(StringRef IDVal, unsigned Size) {
+ // Check for directive inside .text
+ const MCSection *Section = getStreamer().getCurrentSectionOnly();
+ if (Section != NULL) {
+const StringRef sectionName = Section->getName();
+if (sectionName.equals(".text") || sectionName.startswith(".text."))
+ Warning(getLexer().getLoc(), "directive value inside .text section: "
+"directive '" + Twine(IDVal) + "', section '" + Twine(sectionName) +
"'");
+ }
if (StructInProgress.empty()) {
// Initialize data value.
if (emitIntegralValues(Size))
@@ -3825,6 +3833,14 @@ bool MasmParser::parseDirectiveNamedValue(StringRef Ty
bool MasmParser::parseDirectiveNamedValue(StringRef TypeName, unsigned Size,
StringRef Name, SMLoc NameLoc) {
if (StructInProgress.empty()) {
+// Check for directive inside .text
+const MCSection *Section = getStreamer().getCurrentSectionOnly();
+if (Section != NULL) {
+ const StringRef sectionName = Section->getName();
+ if (sectionName.equals(".text") || sectionName.startswith(".text."))
+Warning(getLexer().getLoc(), "directive value inside .text section: "
+ "named directive '" + Twine(Name) + "', section '" +
Twine(sectionName) + "'");
+}
// Initialize named data value.
MCSymbol *Sym = getContext().getOrCreateSymbol(Name);
getStreamer().emitLabel(Sym);
OpenBSD Errata: January 17, 2023 (libxpm)
Errata patches for X11 libXpm library have been released for OpenBSD 7.1 and 7.2. Binary updates for the amd64, i386 and arm64 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata71.html https://www.openbsd.org/errata72.html
Re: bgpd load ASPA table into RDE
On Tue, Jan 17, 2023 at 04:48:06PM +0100, Theo Buehler wrote: > On Tue, Jan 17, 2023 at 03:11:26PM +0100, Claudio Jeker wrote: > > This diff adds all the plumbing to push the ASPA table from the RTR > > process into the RDE. It is still missing important bits but the table > > itself should load and `bgpctl show sets` will show what was loaded. > > > > After that the reload logic needs to be added and the filters need to > > be extended to check the ASPA validation state. > > Please commit the diff at the end to fix regress when you land this > (needed because of the new getmonotime() call in aspa_table_prep()). I will just add getmonotime() as stub function to the regress. > This generally reads fine. There is a crash in rde_aspa_reload(), > see comments inline. If you agree with my suggested fix, this is ok tb Yes, I agree with your fix. Will commit once I fixed all other issues as well. Thanks. -- :wq Claudio
Re: bgpd load ASPA table into RDE
On Tue, Jan 17, 2023 at 03:11:26PM +0100, Claudio Jeker wrote:
> This diff adds all the plumbing to push the ASPA table from the RTR
> process into the RDE. It is still missing important bits but the table
> itself should load and `bgpctl show sets` will show what was loaded.
>
> After that the reload logic needs to be added and the filters need to
> be extended to check the ASPA validation state.
Please commit the diff at the end to fix regress when you land this
(needed because of the new getmonotime() call in aspa_table_prep()).
This generally reads fine. There is a crash in rde_aspa_reload(),
see comments inline. If you agree with my suggested fix, this is ok tb
> Index: bgpd/rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.586
> diff -u -p -r1.586 rde.c
> --- bgpd/rde.c16 Jan 2023 10:37:08 - 1.586
> +++ bgpd/rde.c17 Jan 2023 10:35:14 -
> @@ -83,6 +83,7 @@ static void rde_softreconfig_sync_reeva
> static void rde_softreconfig_sync_fib(struct rib_entry *, void *);
> static void rde_softreconfig_sync_done(void *, uint8_t);
> static void rde_roa_reload(void);
> +static void rde_aspa_reload(void);
> int rde_update_queue_pending(void);
> void rde_update_queue_runner(void);
> void rde_update6_queue_runner(uint8_t);
> @@ -109,7 +110,7 @@ static struct imsgbuf *ibuf_rtr;
> static struct imsgbuf*ibuf_main;
> static struct bgpd_config*conf, *nconf;
> static struct rde_prefixset rde_roa, roa_new;
> -static struct rde_aspa *rde_aspa /* , *aspa_new */;
> +static struct rde_aspa *rde_aspa, *aspa_new;
>
> volatile sig_atomic_t rde_quit = 0;
> struct filter_head *out_rules, *out_rules_tmp;
> @@ -641,6 +642,15 @@ badnetdel:
> imsg_compose(ibuf_se_ctl, IMSG_CTL_SHOW_SET, 0,
> imsg.hdr.pid, -1, , sizeof(cset));
>
> + memset(, 0, sizeof(cset));
> + cset.type = ASPA_SET;
> + strlcpy(cset.name, "RPKI ASPA", sizeof(cset.name));
> + aspa_table_stats(rde_aspa, );
> +
> + imsg_compose(ibuf_se_ctl, IMSG_CTL_SHOW_SET, 0,
> + imsg.hdr.pid, -1, , sizeof(cset));
> +
The line above is extra and adds trailing tabs
> +
> SIMPLEQ_FOREACH(aset, >as_sets, entry) {
> memset(, 0, sizeof(cset));
> cset.type = ASNUM_SET;
> @@ -1065,9 +1075,11 @@ rde_dispatch_imsg_parent(struct imsgbuf
> void
> rde_dispatch_imsg_rtr(struct imsgbuf *ibuf)
> {
> - struct imsg imsg;
> - struct roa roa;
> - int n;
> + static struct aspa_set *aspa;
> + struct imsg imsg;
> + struct roa roa;
> + struct aspa_prep ap;
> + int n;
>
> while (ibuf) {
> if ((n = imsg_get(ibuf, )) == -1)
> @@ -1094,9 +1106,66 @@ rde_dispatch_imsg_rtr(struct imsgbuf *ib
> log_addr(), roa.prefixlen);
> }
> break;
> + case IMSG_RECONF_ASPA_PREP:
> + if (imsg.hdr.len - IMSG_HEADER_SIZE !=
> + sizeof(ap))
Could unwrap this line
[...]
> @@ -3972,6 +4042,32 @@ rde_roa_reload(void)
> rib_byid(RIB_ADJ_IN), rde_roa_softreload,
> rde_roa_softreload_done, NULL) == -1)
> fatal("%s: rib_dump_new", __func__);
> +}
> +
> +static void
> +rde_aspa_reload(void)
> +{
> + struct rde_aspa *aspa_old;
> +
> + if (aspa_update_pending) {
> + log_info("ASPA softreload skipped, old still running");
> + return;
> + }
> +
> + aspa_old = rde_aspa;
> + rde_aspa = aspa_new;
> + aspa_new = NULL;
> +
> + /* check if aspa changed */
> + if (aspa_table_equal(rde_aspa, aspa_old)) {
The integration test crashes because rde_aspa == NULL && aspa_old == NULL.
A possible fix is to add
if (ra == NULL || old == NULL)
return;
to aspa_table_unchanged().
> + aspa_table_unchanged(rde_aspa, aspa_old);
> + aspa_table_free(aspa_old); /* old aspa no longer needed */
> + return;
> + }
> +
Trailing tab
> + aspa_table_free(aspa_old); /* old aspa no longer needed */
> + log_debug("ASPA change: reloading Adj-RIB-In");
> + /* XXX MISSING */
> }
>
> /*
[...]
> Index: bgpd/rde_aspa.c
> ===
[...]
> +/*
> + * Return true if the two rde_aspa tables are contain the same data.
> + */
> +int
> +aspa_table_equal(const struct rde_aspa *ra, const struct rde_aspa *rb)
> +{
> + uint32_t i;
> +
> +/* allow
bgpd load ASPA table into RDE
This diff adds all the plumbing to push the ASPA table from the RTR
process into the RDE. It is still missing important bits but the table
itself should load and `bgpctl show sets` will show what was loaded.
After that the reload logic needs to be added and the filters need to
be extended to check the ASPA validation state.
--
:wq Claudio
Index: bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.287
diff -u -p -r1.287 bgpctl.c
--- bgpctl/bgpctl.c 18 Oct 2022 09:30:29 - 1.287
+++ bgpctl/bgpctl.c 16 Jan 2023 13:55:09 -
@@ -1062,6 +1062,8 @@ const char *
fmt_set_type(struct ctl_show_set *set)
{
switch (set->type) {
+ case ASPA_SET:
+ return "ASPA";
case ROA_SET:
return "ROA";
case PREFIX_SET:
Index: bgpctl/output.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/output.c,v
retrieving revision 1.32
diff -u -p -r1.32 output.c
--- bgpctl/output.c 9 Nov 2022 14:20:11 - 1.32
+++ bgpctl/output.c 16 Jan 2023 13:55:57 -
@@ -1039,7 +1039,7 @@ show_rib_set(struct ctl_show_set *set)
{
char buf[64];
- if (set->type == ASNUM_SET)
+ if (set->type == ASNUM_SET || set->type == ASPA_SET)
snprintf(buf, sizeof(buf), "%7s %7s %6zu",
"-", "-", set->as_cnt);
else
Index: bgpctl/output_json.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/output_json.c,v
retrieving revision 1.27
diff -u -p -r1.27 output_json.c
--- bgpctl/output_json.c28 Dec 2022 21:30:15 - 1.27
+++ bgpctl/output_json.c16 Jan 2023 13:56:48 -
@@ -981,7 +981,7 @@ json_rib_set(struct ctl_show_set *set)
json_do_printf("type", "%s", fmt_set_type(set));
json_do_printf("last_change", "%s", fmt_monotime(set->lastchange));
json_do_int("last_change_sec", get_monotime(set->lastchange));
- if (set->type == ASNUM_SET) {
+ if (set->type == ASNUM_SET || set->type == ASPA_SET) {
json_do_uint("num_ASnum", set->as_cnt);
} else {
json_do_uint("num_IPv4", set->v4_cnt);
Index: bgpd/bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.457
diff -u -p -r1.457 bgpd.h
--- bgpd/bgpd.h 11 Jan 2023 13:53:17 - 1.457
+++ bgpd/bgpd.h 16 Jan 2023 13:28:53 -
@@ -604,6 +604,7 @@ enum imsg_type {
IMSG_RECONF_ASPA_TAS,
IMSG_RECONF_ASPA_TAS_AID,
IMSG_RECONF_ASPA_DONE,
+ IMSG_RECONF_ASPA_PREP,
IMSG_RECONF_RTR_CONFIG,
IMSG_RECONF_DRAIN,
IMSG_RECONF_DONE,
@@ -801,6 +802,7 @@ struct ctl_show_set {
PREFIX_SET,
ORIGIN_SET,
ROA_SET,
+ ASPA_SET,
} type;
};
@@ -1178,6 +1180,11 @@ struct aspa_set {
uint32_t *tas;
uint8_t *tas_aid;
RB_ENTRY(aspa_set) entry;
+};
+
+struct aspa_prep {
+ size_t datasize;
+ uint32_tentries;
};
struct l3vpn {
Index: bgpd/rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.586
diff -u -p -r1.586 rde.c
--- bgpd/rde.c 16 Jan 2023 10:37:08 - 1.586
+++ bgpd/rde.c 17 Jan 2023 10:35:14 -
@@ -83,6 +83,7 @@ static voidrde_softreconfig_sync_reeva
static void rde_softreconfig_sync_fib(struct rib_entry *, void *);
static void rde_softreconfig_sync_done(void *, uint8_t);
static void rde_roa_reload(void);
+static void rde_aspa_reload(void);
int rde_update_queue_pending(void);
voidrde_update_queue_runner(void);
voidrde_update6_queue_runner(uint8_t);
@@ -109,7 +110,7 @@ static struct imsgbuf *ibuf_rtr;
static struct imsgbuf *ibuf_main;
static struct bgpd_config *conf, *nconf;
static struct rde_prefixset rde_roa, roa_new;
-static struct rde_aspa *rde_aspa /* , *aspa_new */;
+static struct rde_aspa *rde_aspa, *aspa_new;
volatile sig_atomic_t rde_quit = 0;
struct filter_head *out_rules, *out_rules_tmp;
@@ -641,6 +642,15 @@ badnetdel:
imsg_compose(ibuf_se_ctl, IMSG_CTL_SHOW_SET, 0,
imsg.hdr.pid, -1, , sizeof(cset));
+ memset(, 0, sizeof(cset));
+ cset.type = ASPA_SET;
+ strlcpy(cset.name, "RPKI ASPA", sizeof(cset.name));
+ aspa_table_stats(rde_aspa, );
+
+ imsg_compose(ibuf_se_ctl, IMSG_CTL_SHOW_SET, 0,
+ imsg.hdr.pid, -1, ,
Re: help wanted for a specific clang diff
On Mon, Jan 16, 2023 at 12:00:30PM -0700, Theo de Raadt wrote:
> For this xonly work, we are having to one-by-one find .S files that
> are putting data tables into the .text segment
>
> I am hoping to find someone who can do c++ well enough, and maybe
> has some familiarity with the clang code, to add a warning message
> for this
>
> if a .long, .quad, .byte are placed into a .text section, issue
> a warning, then we'll be able to identify all these in a ports build
> and decide which need manual fixing, and move the objects into .rodata
> and apply __PIC__ handling as neccessary
>
> Yes, there are cases where people use .long to inject an instruction
> they don't believe the assembler has. We can ignore those by inspect.
>
> Can anyone help? It doesn't need to be fancy, it just needs to get
> us moving faster.
>
> Thanks
>
The following diff seems to work. It adds a warning inside assembler parsers.
Please note that it is a warning at assembler level, so -Werror doesn't
influence it, whereas -Wa,--fatal-warnings will.
The check is done for "directive value" and "directive named value". It doesn't
cover ascii directives (like .asci{i,z}, .string) neither real directives
(.real{4,8,10}).
I checked it on somehow simple code:
$ clang -c test.S
test.S:1:10: warning: directive value '.long' inside '.text' section
a: .long 0x90909090
^
test.S:2:10: warning: directive value '.word' inside '.text' section
b: .word 0x9090
^
test.S:3:10: warning: directive value '.quad' inside '.text' section
c: .quad 0x90
^
test.S:4:10: warning: directive value '.byte' inside '.text' section
d: .byte 0x90
^
--
Sebastien Marie
diff /home/semarie/repos/openbsd/src
commit - b18ed08defc1c5e5b4be701ce5ef913bda8ae66a
path + /home/semarie/repos/openbsd/src
blob - 047ed1660a837e77561b1f2839ec9601f9582a7e
file + gnu/llvm/llvm/lib/MC/MCParser/AsmParser.cpp
--- gnu/llvm/llvm/lib/MC/MCParser/AsmParser.cpp
+++ gnu/llvm/llvm/lib/MC/MCParser/AsmParser.cpp
@@ -3168,6 +3168,12 @@ bool AsmParser::parseDirectiveValue(StringRef IDVal, u
SMLoc ExprLoc = getLexer().getLoc();
if (checkForValidSection() || parseExpression(Value))
return true;
+// Check for directive inside .text
+const MCSection *Section = getStreamer().getCurrentSectionOnly();
+const StringRef sectionName = Section->getName();
+if (sectionName.equals(".text") || sectionName.startswith(".text."))
+ Warning(ExprLoc, "directive value '" + Twine(IDVal) + "' inside '"
++ Twine(sectionName) + "' section");
// Special case constant expressions to match code generator.
if (const MCConstantExpr *MCE = dyn_cast(Value)) {
assert(Size <= 8 && "Invalid size");
blob - 7b4d6e529cc2c3c4efce05f62f41620658d7a8e0
file + gnu/llvm/llvm/lib/MC/MCParser/MasmParser.cpp
--- gnu/llvm/llvm/lib/MC/MCParser/MasmParser.cpp
+++ gnu/llvm/llvm/lib/MC/MCParser/MasmParser.cpp
@@ -3809,6 +3809,14 @@ bool MasmParser::parseDirectiveValue(StringRef IDVal,
/// parseDirectiveValue
/// ::= (byte | word | ... ) [ expression (, expression)* ]
bool MasmParser::parseDirectiveValue(StringRef IDVal, unsigned Size) {
+ // Check for directive inside .text
+ const MCSection *Section = getStreamer().getCurrentSectionOnly();
+ if (Section != NULL) {
+const StringRef sectionName = Section->getName();
+if (sectionName.equals(".text") || sectionName.startswith(".text."))
+ Warning(getLexer().getLoc(), "directive value '" + Twine(IDVal)
++ "' inside '" + Twine(sectionName) + "' section");
+ }
if (StructInProgress.empty()) {
// Initialize data value.
if (emitIntegralValues(Size))
@@ -3825,6 +3833,14 @@ bool MasmParser::parseDirectiveNamedValue(StringRef Ty
bool MasmParser::parseDirectiveNamedValue(StringRef TypeName, unsigned Size,
StringRef Name, SMLoc NameLoc) {
if (StructInProgress.empty()) {
+// Check for directive inside .text
+const MCSection *Section = getStreamer().getCurrentSectionOnly();
+if (Section != NULL) {
+ const StringRef sectionName = Section->getName();
+ if (sectionName.equals(".text") || sectionName.startswith(".text."))
+Warning(getLexer().getLoc(), "directive named value '" + Twine(Name)
+ + "' inside '" + Twine(sectionName) + "' section");
+}
// Initialize named data value.
MCSymbol *Sym = getContext().getOrCreateSymbol(Name);
getStreamer().emitLabel(Sym);
Re: make: arguments can have multiple variable assignments
yep, ok by me. jmc On 17 January 2023 12:03:58 GMT, Klemens Nanni wrote: >17.01.2023 06:44, Jason McIntyre пишет: >> seems correct. posix spec shows "..." too. > >Right, I didn't dig that up yet. > >In that case: OK? >
Re: make: arguments can have multiple variable assignments
17.01.2023 06:44, Jason McIntyre пишет: > seems correct. posix spec shows "..." too. Right, I didn't dig that up yet. In that case: OK?
rpki-client manpage diff
Since a few days rpki-client will not only output a roa-set but also include an aspa-set in the output file. I don't think we need to overcomplicate this and explain that the output has no duplicates and that it is a roa-set and aspa-set. Comments -- :wq Claudio Index: rpki-client.8 === RCS file: /cvs/src/usr.sbin/rpki-client/rpki-client.8,v retrieving revision 1.83 diff -u -p -r1.83 rpki-client.8 --- rpki-client.8 13 Jan 2023 08:58:36 - 1.83 +++ rpki-client.8 17 Jan 2023 11:10:01 - @@ -234,11 +234,9 @@ Defaults to .Pp By default .Nm -produces a list of unique -.Li roa-set -statements in +outputs validated payloads in .Fl o -(OpenBGPD compatible) output. +(OpenBGPD compatible) format. .Pp .Nm should be run hourly by
Re: remove elansc(4)
On Tue, Jan 17, 2023 at 06:47:29AM +, Jason McIntyre wrote: > On Tue, Jan 17, 2023 at 04:12:10PM +1100, Jonathan Gray wrote: > > AMD Elan SC520 (found on soekris net45xx) has a 486 class processor > > We require at least a 586/pentium class processor > > > > if you do, there's a little cleanup: > > /usr/src/share/man/man4/gpio.4:.Cd "gpio* at elansc?" Pq i386 > /usr/src/share/man/man4/pci.4:.It Xr elansc 4 > /usr/src/share/man/man9/tc_init.9:.Xr elansc 4 , > > jmc thanks, committed with those removed as well
