update magic file for qcow
Attached is patch from netbsd for updated qcow definitions. Comments? Ok? +--+ Carlos Index: msdos === RCS file: /home/los/cvs/src/usr.bin/file/magdir/msdos,v retrieving revision 1.6 diff -u -p -r1.6 msdos --- msdos 29 Jan 2016 11:50:40 - 1.6 +++ msdos 3 Oct 2018 05:25:21 - @@ -641,43 +641,77 @@ # # Qemu Emulator Images # Lines written by Friedrich Schwittay (f.schwit...@yousable.de) -# Made by reading sources and doing trial and error on existing -# qcow files -0 string QFI Qemu Image, Format: Qcow +# Updated by Adam Buchbinder (adam.buchbin...@gmail.com) +# Made by reading sources, reading documentation, and doing trial and error +# on existing QCOW files +0 string/bQFI\xFB QEMU QCOW Image # Uncomment the following line to display Magic (only used for debugging # this magic number) -#>0 string x , Magic: %s +#>0string/bx , Magic: %s -# There are currently 2 Versions: "1" and "2" -# I do not use Version 2 and therefore branch here -# but can assure: it works (tested on both versions) -# Also my Qemu 0.9.0 which uses this Version 2 refuses -# to start in its bios ->0x04 belong 2 , Version: 2 ->0x04 belong 1 , Version: 1 +# There are currently 2 Versions: "1" and "2". +# http://www.gnome.org/~markmc/qcow-image-format-version-1.html +>4 belong 1 (v1) -# Using the existence of the Backing File Offset to Branch or not +# Using the existence of the Backing File Offset to determine whether # to read Backing File Information ->>0xcbelong >0 , Backing File( Offset: %lu ->>>(0xc.L) string >\0 , Path: %s - -# Didn't get the trick here how qemu stores the "Size" at this Position -# There is actually something stored but nothing makes sense -# The header in the sources talks about it -#>>>16 lelong x , Size: %lu +>>12 belong >0 \b, has backing file ( +# Note that this isn't a null-terminated string; the length is actually +# (16.L). Assuming a null-terminated string happens to work usually, but it +# may spew junk until it reaches a \0 in some cases. +>>>(12.L) string >\0 \bpath %s # Modification time of the Backing File # Really useful if you want to know if your backing # file is still usable together with this image ->>>20bedate x , Mtime: %s ) +20 bedate >0 \b, mtime %s) +20 default x \b) + +# Size is stored in bytes in a big-endian u64. +>>24 bequad x\b, %lld bytes -# Don't know how to calculate in Magicfiles -# Also: this Information is not reliably -# stored in image-files ->>24 lelong x , Disk Size could be: %d * 256 bytes +# 1 for AES encryption, 0 for none. +>>36 belong 1 \b, AES-encrypted -0 string QEVMQEMU's suspend to disk image +# http://www.gnome.org/~markmc/qcow-image-format.html +>4 belong 2 (v2) +# Using the existence of the Backing File Offset to determine whether +# to read Backing File Information +>>8bequad >0 \b, has backing file +# Note that this isn't a null-terminated string; the length is actually +# (16.L). Assuming a null-terminated string happens to work usually, but it +# may spew junk until it reaches a \0 in some cases. Also, since there's no +# .Q modifier, we just use the bottom four bytes as an offset. Note that if +# the file is over 4G, and the backing file path is stored after the first 4G, +# the wrong filename will be printed. (This should be (8.Q), when that syntax +# is introduced.) +>>>(12.L) string >\0 (path %s) +>>24 bequad x \b, %lld bytes +>>32 belong 1 \b, AES-encrypted + +>4 belong 3 (v3) +# Using the existence of the Backing File Offset to determine whether +# to read Backing File Information +>>8bequad >0 \b, has backing file +# Note that this isn't a null-terminated string; the length is actually +# (16.L). Assuming a null-terminated string happens to work usually, but it +# may spew junk until it reaches a \0 in some cases. Also, since there's no +# .Q modifier, we just use the bottom four bytes as an offset. Note that if +# the file is over 4G, and the backing file path is stored after the first 4G, +# the wrong filename will be printed. (This should be (8.Q), when that syntax +# is introduced.) +>>>(12.L) string >\0 (path %s) +>>24 bequad x \b, %lld bytes +>>32 belong 1 \b, AES-encrypted + +>4 default x (unknown version) + +0 string/bQEVMQEMU suspend to disk image + +# QEMU QED Image +# http://wiki.qemu.org/Features/QED/Specification +0 string/bQED\0 QEMU QED Image 0 string Bochs\ Virtual\ HD\ Image Bochs disk image, >32string x type %s,
bwfm device not always available on boot
Every few boots my bwfm device is not available. dmesg says: bwfm0: timeout waiting for ioctl response bwfm0: could not read io type When this happens I reboot until the device is recognized again. dmesg says: bwfm0 at pci10 dev 0 function 0 "Broadcom BCM43602" rev 0x01: msi Is there a fix for this or any other info I can provide? Thanks! -- Phil Eaton
pf: honor quick on anchor rules
On Sat, Sep 29, 2018 at 10:44:41PM +0200, Klemens Nanni wrote:
> On Sat, Sep 29, 2018 at 06:17:05PM +0200, Fabian Mueller-Knapp wrote:
> > I have the following pf.conf:
> >
> > anchor quick {
> > pass
> > }
> > block
> >
> > # pfctl -sr
> > anchor quick all {
> > pass all flags S/SA
> > }
> > block drop all
> >
> > Because of the 'quick' i assumed, that 'block' is never reached, but it
> > is since 6.2.
> Indeed, `pfctl -s rules -v' clearly shows how every packet goes through
> all three rules.
>
> > man pf.conf(5) states:
> >
> > "If the anchor itself is marked with the quick option, ruleset
> > evaluation will terminate when the anchor is exited if the packet is
> > matched by any rule within the anchor."
> >
> > I tested with fresh installs of 6.1, 6.2, 6.3 and current via vmd and
> > 6.1 does in fact behave as i would accept (that is, all packets
> > pass). From 6.2 on however, all packets are dropped.
> Thanks for your report.
>
> > Do i misread the manpage somehow?
> No, this is a bug.
Allow me a bit of rubber ducking to explain this bug and ease review:
The kernel evaluates the ruleset pretty much like we read it: Down to
bottom until quick appears or an error occurs in which case we stop
evaluating. That is, packets are tested against each rule which yields
either of OK, QUICK, FAIL.
`anchor quick' means "evaluate the rules inside but stop after that".
According to the procedure explained above, an anchor rule's test status
is the result of its contained ruleset:
sys/net/pf.c
3130rv = pf_match_rule(ctx, >anchor->ruleset);
While this approach is valid for other type of rules, it overwrites the
anchor rule's *own* QUICK test result such that it has no effect at all.
To fix this, simply pass it along except when there was an error so we
do not clobber it (and make the same mistake again).
Feedback? OK?
Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1075
diff -u -p -r1.1075 pf.c
--- net/pf.c13 Sep 2018 19:53:58 - 1.1075
+++ net/pf.c3 Oct 2018 22:22:32 -
@@ -3128,6 +3128,12 @@ pf_step_into_anchor(struct pf_test_ctx *
}
} else {
rv = pf_match_rule(ctx, >anchor->ruleset);
+ /*
+* Unless there was an error inside the anchor,
+* retain its quick state.
+*/
+ if (rv != PF_TEST_FAIL && r->quick == PF_TEST_QUICK)
+ rv = PF_TEST_QUICK;
}
ctx->depth--;
Re: vmd: division by zero in vcpu_process_com_data
* Mike Larkin [2018-10-03 12:19:09 -0700]: How about this? pd, thoughts? This code is just the rate limiter code. Today the code says "have I reached the number of characters output based on my baud rate that indicates I need to pause a bit?". And pausing after 0 characters has been output makes no sense, so only engage the limiter if we are pausing between each "1 character or more". -ml I like it ok pd@
Re: vmd: division by zero in vcpu_process_com_data
On Wed, Oct 03, 2018 at 12:19:09PM -0700, Mike Larkin wrote:
> On Wed, Oct 03, 2018 at 12:13:05PM -0700, Mike Larkin wrote:
> > On Wed, Oct 03, 2018 at 12:06:47PM -0700, Pratik Vyas wrote:
> > > * Greg Steuck [2018-10-03 11:40:22 -0700]:
> > >
> > > > $ egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/38082.core
> > > > Core was generated by `vmd'.
> > > > Program terminated with signal SIGFPE, Arithmetic exception.
> > > > #0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
> > > > vm_id=, vcpu_id=)
> > > >at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
> > > > 240 if (com1_dev.byte_out %
> > > > com1_dev.pause_ct
> > > > == 0) {
> > > > [Current thread is 1 (process 259192)]
> > > > (gdb) p com1_dev.pause_ct
> > > > $1 = 0
> > > > $1 = {mutex = 0xc0a4b1242c0, regs = {lcr = 5 '\005', fcr = 6 '\006',
> > > > iir =
> > > > 3 '\003', ier = 15 '\017', divlo = 64 '@', divhi = 56 '8',
> > > >msr = 0 '\000', lsr = 0 '\000', mcr = 11 '\v', scr = 0 '\000', data
> > > > = 0
> > > > '\000'}, event = {ev_next = {tqe_next = 0xc0a4b120808,
> > > > tqe_prev = 0xc09e1428848}, ev_active_next = {tqe_next = 0x0,
> > > > tqe_prev
> > > > = 0x0}, ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x0},
> > > >min_heap_idx = 4294967295, ev_base = 0xc0a52c3bc00, ev_fd = 9,
> > > > ev_events = 18, ev_ncalls = 0, ev_pncalls = 0x0, ev_timeout = {tv_sec =
> > > > 0,
> > > > tv_usec = 0}, ev_pri = 0, ev_callback = 0xc07a6417340
> > > > , ev_arg = 0x6, ev_res = 0, ev_flags = 4226}, rate =
> > > > {ev_next = {
> > > > tqe_next = 0x0, tqe_prev = 0x0}, ev_active_next = {tqe_next =
> > > > 0xc07a66b65c8 , tqe_prev = 0xc0a4b121f40}, ev_signal_next = {
> > > > tqe_next = 0x0, tqe_prev = 0x0}, min_heap_idx = 4294967295,
> > > > ev_base =
> > > > 0xc0a52c3bc00, ev_fd = -1, ev_events = 0, ev_ncalls = 0,
> > > >ev_pncalls = 0xc0a4b8f3f68, ev_timeout = {tv_sec = 2745, tv_usec =
> > > > 969355}, ev_pri = 0, ev_callback = 0xc07a64173c0 , ev_arg =
> > > > 0x0,
> > > >ev_res = 1, ev_flags = 128}, rate_tv = {tv_sec = 0, tv_usec = 1},
> > > > fd = 9, irq = 4, rcv_pending = 0, vmid = 6, byte_out = 56924,
> > > > baudrate = 8, pause_ct = 0}
> > > >
> > >
> > > Nice :)
> > >
> > > Easy to repro, boot cd and stty com0 4800 in boot>
> > > and continue
> > >
> > > crude diff attached.
> > >
> > >
> > > --
> > > Pratik
> > >
> > > Index: usr.sbin/vmd/ns8250.c
> > > ===
> > > RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/ns8250.c,v
> > > retrieving revision 1.17
> > > diff -u -p -a -u -r1.17 ns8250.c
> > > --- usr.sbin/vmd/ns8250.c 12 Jul 2018 10:15:44 - 1.17
> > > +++ usr.sbin/vmd/ns8250.c 3 Oct 2018 19:03:08 -
> > > @@ -312,13 +312,13 @@ vcpu_process_com_lcr(struct vm_exit *vei
> > > if (vei->vei.vei_dir == VEI_DIR_OUT) {
> > > if (com1_dev.regs.lcr & LCR_DLAB) {
> > > if (!(data & LCR_DLAB)) {
> > > - if (com1_dev.regs.divlo == 0 &&
> > > - com1_dev.regs.divhi == 0) {
> > > + divisor = com1_dev.regs.divlo |
> > > + com1_dev.regs.divhi << 8;
> > > + /* can't set baud < 9600 */
> > > + if (divisor == 0 || (divisor > (115200/9600))) {
> > > log_warnx("%s: ignoring invalid "
> > > "baudrate", __func__);
> > > } else {
> > > - divisor = com1_dev.regs.divlo |
> > > - com1_dev.regs.divhi << 8;
> > > com1_dev.baudrate = 115200 / divisor;
> > > com1_dev.pause_ct =
> > > (com1_dev.baudrate / 8) / 1000 * 10;
> >
> > I have a better diff, stay tuned.
> >
> > -ml
>
> How about this? pd, thoughts?
>
> This code is just the rate limiter code.
>
> Today the code says "have I reached the number of characters output based on
> my baud rate that indicates I need to pause a bit?". And pausing after 0
> characters has been output makes no sense, so only engage the limiter if
> we are pausing between each "1 character or more".
>
> -ml
>
I just noticed that this will effectively remove rate limiting for low
baud rates (like pd's example of 4800 baud). Since this is only used for
the console, I don't think this is a big deal. The rate is only simulated
anyway.
-ml
> Index: ns8250.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/ns8250.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 ns8250.c
> --- ns8250.c 12 Jul 2018 10:15:44 - 1.17
> +++ ns8250.c 3 Oct 2018 19:09:37 -
> @@ -237,8 +237,9 @@ vcpu_process_com_data(struct vm_exit *ve
>
>
Re: vmd: division by zero in vcpu_process_com_data
Thanks Pratik. I reverted my hack and applied your patch instead.
Re: vmd: division by zero in vcpu_process_com_data
On Wed, Oct 03, 2018 at 12:13:05PM -0700, Mike Larkin wrote:
> On Wed, Oct 03, 2018 at 12:06:47PM -0700, Pratik Vyas wrote:
> > * Greg Steuck [2018-10-03 11:40:22 -0700]:
> >
> > > $ egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/38082.core
> > > Core was generated by `vmd'.
> > > Program terminated with signal SIGFPE, Arithmetic exception.
> > > #0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
> > > vm_id=, vcpu_id=)
> > >at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
> > > 240 if (com1_dev.byte_out % com1_dev.pause_ct
> > > == 0) {
> > > [Current thread is 1 (process 259192)]
> > > (gdb) p com1_dev.pause_ct
> > > $1 = 0
> > > $1 = {mutex = 0xc0a4b1242c0, regs = {lcr = 5 '\005', fcr = 6 '\006', iir =
> > > 3 '\003', ier = 15 '\017', divlo = 64 '@', divhi = 56 '8',
> > >msr = 0 '\000', lsr = 0 '\000', mcr = 11 '\v', scr = 0 '\000', data = 0
> > > '\000'}, event = {ev_next = {tqe_next = 0xc0a4b120808,
> > > tqe_prev = 0xc09e1428848}, ev_active_next = {tqe_next = 0x0, tqe_prev
> > > = 0x0}, ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x0},
> > >min_heap_idx = 4294967295, ev_base = 0xc0a52c3bc00, ev_fd = 9,
> > > ev_events = 18, ev_ncalls = 0, ev_pncalls = 0x0, ev_timeout = {tv_sec = 0,
> > > tv_usec = 0}, ev_pri = 0, ev_callback = 0xc07a6417340
> > > , ev_arg = 0x6, ev_res = 0, ev_flags = 4226}, rate =
> > > {ev_next = {
> > > tqe_next = 0x0, tqe_prev = 0x0}, ev_active_next = {tqe_next =
> > > 0xc07a66b65c8 , tqe_prev = 0xc0a4b121f40}, ev_signal_next = {
> > > tqe_next = 0x0, tqe_prev = 0x0}, min_heap_idx = 4294967295, ev_base =
> > > 0xc0a52c3bc00, ev_fd = -1, ev_events = 0, ev_ncalls = 0,
> > >ev_pncalls = 0xc0a4b8f3f68, ev_timeout = {tv_sec = 2745, tv_usec =
> > > 969355}, ev_pri = 0, ev_callback = 0xc07a64173c0 , ev_arg =
> > > 0x0,
> > >ev_res = 1, ev_flags = 128}, rate_tv = {tv_sec = 0, tv_usec = 1},
> > > fd = 9, irq = 4, rcv_pending = 0, vmid = 6, byte_out = 56924,
> > > baudrate = 8, pause_ct = 0}
> > >
> >
> > Nice :)
> >
> > Easy to repro, boot cd and stty com0 4800 in boot>
> > and continue
> >
> > crude diff attached.
> >
> >
> > --
> > Pratik
> >
> > Index: usr.sbin/vmd/ns8250.c
> > ===
> > RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/ns8250.c,v
> > retrieving revision 1.17
> > diff -u -p -a -u -r1.17 ns8250.c
> > --- usr.sbin/vmd/ns8250.c 12 Jul 2018 10:15:44 - 1.17
> > +++ usr.sbin/vmd/ns8250.c 3 Oct 2018 19:03:08 -
> > @@ -312,13 +312,13 @@ vcpu_process_com_lcr(struct vm_exit *vei
> > if (vei->vei.vei_dir == VEI_DIR_OUT) {
> > if (com1_dev.regs.lcr & LCR_DLAB) {
> > if (!(data & LCR_DLAB)) {
> > - if (com1_dev.regs.divlo == 0 &&
> > - com1_dev.regs.divhi == 0) {
> > + divisor = com1_dev.regs.divlo |
> > +com1_dev.regs.divhi << 8;
> > + /* can't set baud < 9600 */
> > + if (divisor == 0 || (divisor > (115200/9600))) {
> > log_warnx("%s: ignoring invalid "
> > "baudrate", __func__);
> > } else {
> > - divisor = com1_dev.regs.divlo |
> > -com1_dev.regs.divhi << 8;
> > com1_dev.baudrate = 115200 / divisor;
> > com1_dev.pause_ct =
> > (com1_dev.baudrate / 8) / 1000 * 10;
>
> I have a better diff, stay tuned.
>
> -ml
How about this? pd, thoughts?
This code is just the rate limiter code.
Today the code says "have I reached the number of characters output based on
my baud rate that indicates I need to pause a bit?". And pausing after 0
characters has been output makes no sense, so only engage the limiter if
we are pausing between each "1 character or more".
-ml
Index: ns8250.c
===
RCS file: /cvs/src/usr.sbin/vmd/ns8250.c,v
retrieving revision 1.17
diff -u -p -r1.17 ns8250.c
--- ns8250.c12 Jul 2018 10:15:44 - 1.17
+++ ns8250.c3 Oct 2018 19:09:37 -
@@ -237,8 +237,9 @@ vcpu_process_com_data(struct vm_exit *ve
if (com1_dev.regs.ier & IER_ETXRDY) {
/* Limit output rate if needed */
- if (com1_dev.byte_out % com1_dev.pause_ct == 0) {
- evtimer_add(_dev.rate, _dev.rate_tv);
+ if (com1_dev.pause_ct > 0) {
+ if (com1_dev.byte_out % com1_dev.pause_ct == 0)
+ evtimer_add(_dev.rate,
_dev.rate_tv);
} else {
Re: vmd: division by zero in vcpu_process_com_data
On Wed, Oct 03, 2018 at 12:06:47PM -0700, Pratik Vyas wrote:
> * Greg Steuck [2018-10-03 11:40:22 -0700]:
>
> > $ egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/38082.core
> > Core was generated by `vmd'.
> > Program terminated with signal SIGFPE, Arithmetic exception.
> > #0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
> > vm_id=, vcpu_id=)
> >at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
> > 240 if (com1_dev.byte_out % com1_dev.pause_ct
> > == 0) {
> > [Current thread is 1 (process 259192)]
> > (gdb) p com1_dev.pause_ct
> > $1 = 0
> > $1 = {mutex = 0xc0a4b1242c0, regs = {lcr = 5 '\005', fcr = 6 '\006', iir =
> > 3 '\003', ier = 15 '\017', divlo = 64 '@', divhi = 56 '8',
> >msr = 0 '\000', lsr = 0 '\000', mcr = 11 '\v', scr = 0 '\000', data = 0
> > '\000'}, event = {ev_next = {tqe_next = 0xc0a4b120808,
> > tqe_prev = 0xc09e1428848}, ev_active_next = {tqe_next = 0x0, tqe_prev
> > = 0x0}, ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x0},
> >min_heap_idx = 4294967295, ev_base = 0xc0a52c3bc00, ev_fd = 9,
> > ev_events = 18, ev_ncalls = 0, ev_pncalls = 0x0, ev_timeout = {tv_sec = 0,
> > tv_usec = 0}, ev_pri = 0, ev_callback = 0xc07a6417340
> > , ev_arg = 0x6, ev_res = 0, ev_flags = 4226}, rate =
> > {ev_next = {
> > tqe_next = 0x0, tqe_prev = 0x0}, ev_active_next = {tqe_next =
> > 0xc07a66b65c8 , tqe_prev = 0xc0a4b121f40}, ev_signal_next = {
> > tqe_next = 0x0, tqe_prev = 0x0}, min_heap_idx = 4294967295, ev_base =
> > 0xc0a52c3bc00, ev_fd = -1, ev_events = 0, ev_ncalls = 0,
> >ev_pncalls = 0xc0a4b8f3f68, ev_timeout = {tv_sec = 2745, tv_usec =
> > 969355}, ev_pri = 0, ev_callback = 0xc07a64173c0 , ev_arg = 0x0,
> >ev_res = 1, ev_flags = 128}, rate_tv = {tv_sec = 0, tv_usec = 1},
> > fd = 9, irq = 4, rcv_pending = 0, vmid = 6, byte_out = 56924,
> > baudrate = 8, pause_ct = 0}
> >
>
> Nice :)
>
> Easy to repro, boot cd and stty com0 4800 in boot>
> and continue
>
> crude diff attached.
>
>
> --
> Pratik
>
> Index: usr.sbin/vmd/ns8250.c
> ===
> RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/ns8250.c,v
> retrieving revision 1.17
> diff -u -p -a -u -r1.17 ns8250.c
> --- usr.sbin/vmd/ns8250.c 12 Jul 2018 10:15:44 - 1.17
> +++ usr.sbin/vmd/ns8250.c 3 Oct 2018 19:03:08 -
> @@ -312,13 +312,13 @@ vcpu_process_com_lcr(struct vm_exit *vei
> if (vei->vei.vei_dir == VEI_DIR_OUT) {
> if (com1_dev.regs.lcr & LCR_DLAB) {
> if (!(data & LCR_DLAB)) {
> - if (com1_dev.regs.divlo == 0 &&
> - com1_dev.regs.divhi == 0) {
> + divisor = com1_dev.regs.divlo |
> + com1_dev.regs.divhi << 8;
> + /* can't set baud < 9600 */
> + if (divisor == 0 || (divisor > (115200/9600))) {
> log_warnx("%s: ignoring invalid "
> "baudrate", __func__);
> } else {
> - divisor = com1_dev.regs.divlo |
> - com1_dev.regs.divhi << 8;
> com1_dev.baudrate = 115200 / divisor;
> com1_dev.pause_ct =
> (com1_dev.baudrate / 8) / 1000 * 10;
I have a better diff, stay tuned.
-ml
Re: vmd: division by zero in vcpu_process_com_data
* Greg Steuck [2018-10-03 11:40:22 -0700]:
$ egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/38082.core
Core was generated by `vmd'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
vm_id=, vcpu_id=)
at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
240 if (com1_dev.byte_out % com1_dev.pause_ct
== 0) {
[Current thread is 1 (process 259192)]
(gdb) p com1_dev.pause_ct
$1 = 0
$1 = {mutex = 0xc0a4b1242c0, regs = {lcr = 5 '\005', fcr = 6 '\006', iir =
3 '\003', ier = 15 '\017', divlo = 64 '@', divhi = 56 '8',
msr = 0 '\000', lsr = 0 '\000', mcr = 11 '\v', scr = 0 '\000', data = 0
'\000'}, event = {ev_next = {tqe_next = 0xc0a4b120808,
tqe_prev = 0xc09e1428848}, ev_active_next = {tqe_next = 0x0, tqe_prev
= 0x0}, ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x0},
min_heap_idx = 4294967295, ev_base = 0xc0a52c3bc00, ev_fd = 9,
ev_events = 18, ev_ncalls = 0, ev_pncalls = 0x0, ev_timeout = {tv_sec = 0,
tv_usec = 0}, ev_pri = 0, ev_callback = 0xc07a6417340
, ev_arg = 0x6, ev_res = 0, ev_flags = 4226}, rate =
{ev_next = {
tqe_next = 0x0, tqe_prev = 0x0}, ev_active_next = {tqe_next =
0xc07a66b65c8 , tqe_prev = 0xc0a4b121f40}, ev_signal_next = {
tqe_next = 0x0, tqe_prev = 0x0}, min_heap_idx = 4294967295, ev_base =
0xc0a52c3bc00, ev_fd = -1, ev_events = 0, ev_ncalls = 0,
ev_pncalls = 0xc0a4b8f3f68, ev_timeout = {tv_sec = 2745, tv_usec =
969355}, ev_pri = 0, ev_callback = 0xc07a64173c0 , ev_arg = 0x0,
ev_res = 1, ev_flags = 128}, rate_tv = {tv_sec = 0, tv_usec = 1},
fd = 9, irq = 4, rcv_pending = 0, vmid = 6, byte_out = 56924,
baudrate = 8, pause_ct = 0}
Nice :)
Easy to repro, boot cd and stty com0 4800 in boot>
and continue
crude diff attached.
--
Pratik
Index: usr.sbin/vmd/ns8250.c
===
RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/ns8250.c,v
retrieving revision 1.17
diff -u -p -a -u -r1.17 ns8250.c
--- usr.sbin/vmd/ns8250.c 12 Jul 2018 10:15:44 - 1.17
+++ usr.sbin/vmd/ns8250.c 3 Oct 2018 19:03:08 -
@@ -312,13 +312,13 @@ vcpu_process_com_lcr(struct vm_exit *vei
if (vei->vei.vei_dir == VEI_DIR_OUT) {
if (com1_dev.regs.lcr & LCR_DLAB) {
if (!(data & LCR_DLAB)) {
- if (com1_dev.regs.divlo == 0 &&
- com1_dev.regs.divhi == 0) {
+ divisor = com1_dev.regs.divlo |
+com1_dev.regs.divhi << 8;
+ /* can't set baud < 9600 */
+ if (divisor == 0 || (divisor > (115200/9600))) {
log_warnx("%s: ignoring invalid "
"baudrate", __func__);
} else {
- divisor = com1_dev.regs.divlo |
-com1_dev.regs.divhi << 8;
com1_dev.baudrate = 115200 / divisor;
com1_dev.pause_ct =
(com1_dev.baudrate / 8) / 1000 * 10;
Re: vmd: division by zero in vcpu_process_com_data
Since I don't understand how com1_dev.pause_ct can be zero, I'll hack
around the problem to keep the runs stable:
diff --git a/usr.sbin/vmd/ns8250.c b/usr.sbin/vmd/ns8250.c
index 74e86a92954..69957e38cce 100644
--- a/usr.sbin/vmd/ns8250.c
+++ b/usr.sbin/vmd/ns8250.c
@@ -237,7 +237,7 @@ vcpu_process_com_data(struct vm_exit *vei, uint32_t
vm_id, uint32_t vcpu_id)
if (com1_dev.regs.ier & IER_ETXRDY) {
/* Limit output rate if needed */
- if (com1_dev.byte_out % com1_dev.pause_ct == 0) {
+ if (com1_dev.pause_ct > 0 && com1_dev.byte_out % com1_dev.pause_ct == 0) {
evtimer_add(_dev.rate, _dev.rate_tv);
} else {
/* Set TXRDY and clear "no pending interrupt" */
On Wed, Oct 3, 2018 at 11:40 AM Greg Steuck wrote:
> $ egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/38082.core
> Core was generated by `vmd'.
> Program terminated with signal SIGFPE, Arithmetic exception.
> #0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
> vm_id=, vcpu_id=)
> at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
> 240 if (com1_dev.byte_out % com1_dev.pause_ct
> == 0) {
> [Current thread is 1 (process 259192)]
> (gdb) p com1_dev.pause_ct
> $1 = 0
> $1 = {mutex = 0xc0a4b1242c0, regs = {lcr = 5 '\005', fcr = 6 '\006', iir =
> 3 '\003', ier = 15 '\017', divlo = 64 '@', divhi = 56 '8',
> msr = 0 '\000', lsr = 0 '\000', mcr = 11 '\v', scr = 0 '\000', data =
> 0 '\000'}, event = {ev_next = {tqe_next = 0xc0a4b120808,
> tqe_prev = 0xc09e1428848}, ev_active_next = {tqe_next = 0x0,
> tqe_prev = 0x0}, ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x0},
> min_heap_idx = 4294967295, ev_base = 0xc0a52c3bc00, ev_fd = 9,
> ev_events = 18, ev_ncalls = 0, ev_pncalls = 0x0, ev_timeout = {tv_sec = 0,
> tv_usec = 0}, ev_pri = 0, ev_callback = 0xc07a6417340
> , ev_arg = 0x6, ev_res = 0, ev_flags = 4226}, rate =
> {ev_next = {
> tqe_next = 0x0, tqe_prev = 0x0}, ev_active_next = {tqe_next =
> 0xc07a66b65c8 , tqe_prev = 0xc0a4b121f40}, ev_signal_next = {
> tqe_next = 0x0, tqe_prev = 0x0}, min_heap_idx = 4294967295, ev_base
> = 0xc0a52c3bc00, ev_fd = -1, ev_events = 0, ev_ncalls = 0,
> ev_pncalls = 0xc0a4b8f3f68, ev_timeout = {tv_sec = 2745, tv_usec =
> 969355}, ev_pri = 0, ev_callback = 0xc07a64173c0 , ev_arg = 0x0,
> ev_res = 1, ev_flags = 128}, rate_tv = {tv_sec = 0, tv_usec = 1},
> fd = 9, irq = 4, rcv_pending = 0, vmid = 6, byte_out = 56924,
> baudrate = 8, pause_ct = 0}
>
> (gdb) bt
> #0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
> vm_id=, vcpu_id=)
> at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
> #1 0x0c07a6417985 in vcpu_exit_com (vrp=) at
> /syzkaller/src/usr.sbin/vmd/ns8250.c:590
> #2 0x0c07a640f0ec in vcpu_exit_inout (vrp=) at
> /syzkaller/src/usr.sbin/vmd/vm.c:1444
> #3 vcpu_exit (vrp=0xc0a4b047e60) at /syzkaller/src/usr.sbin/vmd/vm.c:1496
> #4 0x0c07a640ed36 in vcpu_run_loop (arg=0xc0a4b047e60) at
> /syzkaller/src/usr.sbin/vmd/vm.c:1355
> #5 0x0c0a6307adce in _rthread_start (v=0xde5c) at
> /usr/src/lib/librthread/rthread.c:96
> #6 0x0c09f2abdf4b in __tfork_thread () at
> /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
> #7 0x in ?? ()
>
> --
> nest.cx is Gmail hosted, use PGP for anything private. Key:
> http://goo.gl/6dMsr
> Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
>
>
--
nest.cx is Gmail hosted, use PGP for anything private. Key:
http://goo.gl/6dMsr
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: vmd: division by zero in vcpu_process_com_data
On Wed, Oct 03, 2018 at 12:00:07PM -0700, Mike Larkin wrote:
> On Wed, Oct 03, 2018 at 11:40:22AM -0700, Greg Steuck wrote:
> > $ egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/38082.core
> > Core was generated by `vmd'.
> > Program terminated with signal SIGFPE, Arithmetic exception.
> > #0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
> > vm_id=, vcpu_id=)
> > at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
> > 240 if (com1_dev.byte_out % com1_dev.pause_ct
> > == 0) {
> > [Current thread is 1 (process 259192)]
> > (gdb) p com1_dev.pause_ct
> > $1 = 0
>
> Did you set com0 to 0 baud?
>
> -ml
>
NM, I can see how this can be triggered for other values. Thanks for the
report.
-ml
Re: vmd cores
Great minds think alike :) Thanks Carlos & Pratik. I just applied the patch and will restart the fuzzer. On Wed, Oct 3, 2018 at 11:37 AM Pratik Vyas wrote: > * Greg Steuck [2018-10-03 10:56:28 -0700]: > > >Hi Mike, > > > >I'm getting core files from vmds. Here's the most recent one. Should I > >start collecting more stack traces and sending them to you? > > > >ci-openbsd$ doas /usr/local/bin/egdb /syzkaller/src/usr.sbin/vmd/obj/vmd > >/var/crash/vmd/89501.core > >Reading symbols from /syzkaller/src/usr.sbin/vmd/obj/vmd...done. > >[New process 178128] > >[New process 294426] > >[New process 350865] > >Core was generated by `vmd'. > >Program terminated with signal SIGSEGV, Segmentation fault. > >#0 0x0c07a64148bd in virtio_shutdown (vm=0xc09e1418000) at > >/syzkaller/src/usr.sbin/vmd/virtio.c:2018 > >2018vioscsi->file.close(vioscsi->file.p, 0); > > Hi Greg, > > this is interesting. Are you using the cdrom? I guess not. There > seems to be no if condition around that statement. > > This diff should prevent that segfault. > > -- > Pratik > > > Index: usr.sbin/vmd/virtio.c > === > RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/virtio.c,v > retrieving revision 1.70 > diff -u -p -a -u -r1.70 virtio.c > --- usr.sbin/vmd/virtio.c 28 Sep 2018 12:35:32 - 1.70 > +++ usr.sbin/vmd/virtio.c 3 Oct 2018 18:35:40 - > @@ -2015,7 +2015,8 @@ virtio_shutdown(struct vmd_vm *vm) > int i; > > /* ensure that our disks are synced */ > - vioscsi->file.close(vioscsi->file.p, 0); > + if (vioscsi != NULL) > + vioscsi->file.close(vioscsi->file.p, 0); > for (i = 0; i < nr_vioblk; i++) > vioblk[i].file.close(vioblk[i].file.p, 0); > } > -- nest.cx is Gmail hosted, use PGP for anything private. Key: http://goo.gl/6dMsr Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
vmd: division by zero in vcpu_process_com_data
$ egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/38082.core
Core was generated by `vmd'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
vm_id=, vcpu_id=)
at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
240 if (com1_dev.byte_out % com1_dev.pause_ct
== 0) {
[Current thread is 1 (process 259192)]
(gdb) p com1_dev.pause_ct
$1 = 0
$1 = {mutex = 0xc0a4b1242c0, regs = {lcr = 5 '\005', fcr = 6 '\006', iir =
3 '\003', ier = 15 '\017', divlo = 64 '@', divhi = 56 '8',
msr = 0 '\000', lsr = 0 '\000', mcr = 11 '\v', scr = 0 '\000', data = 0
'\000'}, event = {ev_next = {tqe_next = 0xc0a4b120808,
tqe_prev = 0xc09e1428848}, ev_active_next = {tqe_next = 0x0, tqe_prev
= 0x0}, ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x0},
min_heap_idx = 4294967295, ev_base = 0xc0a52c3bc00, ev_fd = 9,
ev_events = 18, ev_ncalls = 0, ev_pncalls = 0x0, ev_timeout = {tv_sec = 0,
tv_usec = 0}, ev_pri = 0, ev_callback = 0xc07a6417340
, ev_arg = 0x6, ev_res = 0, ev_flags = 4226}, rate =
{ev_next = {
tqe_next = 0x0, tqe_prev = 0x0}, ev_active_next = {tqe_next =
0xc07a66b65c8 , tqe_prev = 0xc0a4b121f40}, ev_signal_next = {
tqe_next = 0x0, tqe_prev = 0x0}, min_heap_idx = 4294967295, ev_base =
0xc0a52c3bc00, ev_fd = -1, ev_events = 0, ev_ncalls = 0,
ev_pncalls = 0xc0a4b8f3f68, ev_timeout = {tv_sec = 2745, tv_usec =
969355}, ev_pri = 0, ev_callback = 0xc07a64173c0 , ev_arg = 0x0,
ev_res = 1, ev_flags = 128}, rate_tv = {tv_sec = 0, tv_usec = 1},
fd = 9, irq = 4, rcv_pending = 0, vmid = 6, byte_out = 56924,
baudrate = 8, pause_ct = 0}
(gdb) bt
#0 0x0c07a64174a0 in vcpu_process_com_data (vei=,
vm_id=, vcpu_id=)
at /syzkaller/src/usr.sbin/vmd/ns8250.c:240
#1 0x0c07a6417985 in vcpu_exit_com (vrp=) at
/syzkaller/src/usr.sbin/vmd/ns8250.c:590
#2 0x0c07a640f0ec in vcpu_exit_inout (vrp=) at
/syzkaller/src/usr.sbin/vmd/vm.c:1444
#3 vcpu_exit (vrp=0xc0a4b047e60) at /syzkaller/src/usr.sbin/vmd/vm.c:1496
#4 0x0c07a640ed36 in vcpu_run_loop (arg=0xc0a4b047e60) at
/syzkaller/src/usr.sbin/vmd/vm.c:1355
#5 0x0c0a6307adce in _rthread_start (v=0xde5c) at
/usr/src/lib/librthread/rthread.c:96
#6 0x0c09f2abdf4b in __tfork_thread () at
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#7 0x in ?? ()
--
nest.cx is Gmail hosted, use PGP for anything private. Key:
http://goo.gl/6dMsr
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: vmd cores
* Greg Steuck [2018-10-03 10:56:28 -0700]: Hi Mike, I'm getting core files from vmds. Here's the most recent one. Should I start collecting more stack traces and sending them to you? ci-openbsd$ doas /usr/local/bin/egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/89501.core Reading symbols from /syzkaller/src/usr.sbin/vmd/obj/vmd...done. [New process 178128] [New process 294426] [New process 350865] Core was generated by `vmd'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0c07a64148bd in virtio_shutdown (vm=0xc09e1418000) at /syzkaller/src/usr.sbin/vmd/virtio.c:2018 2018vioscsi->file.close(vioscsi->file.p, 0); Hi Greg, this is interesting. Are you using the cdrom? I guess not. There seems to be no if condition around that statement. This diff should prevent that segfault. -- Pratik Index: usr.sbin/vmd/virtio.c === RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/virtio.c,v retrieving revision 1.70 diff -u -p -a -u -r1.70 virtio.c --- usr.sbin/vmd/virtio.c 28 Sep 2018 12:35:32 - 1.70 +++ usr.sbin/vmd/virtio.c 3 Oct 2018 18:35:40 - @@ -2015,7 +2015,8 @@ virtio_shutdown(struct vmd_vm *vm) int i; /* ensure that our disks are synced */ - vioscsi->file.close(vioscsi->file.p, 0); + if (vioscsi != NULL) + vioscsi->file.close(vioscsi->file.p, 0); for (i = 0; i < nr_vioblk; i++) vioblk[i].file.close(vioblk[i].file.p, 0); }
Re: vmd cores
On Wed, Oct 03, 2018 at 10:56:28AM -0700, Greg Steuck wrote: > Hi Mike, > > I'm getting core files from vmds. Here's the most recent one. Should I > start collecting more stack traces and sending them to you? > > ci-openbsd$ doas /usr/local/bin/egdb /syzkaller/src/usr.sbin/vmd/obj/vmd > /var/crash/vmd/89501.core > Reading symbols from /syzkaller/src/usr.sbin/vmd/obj/vmd...done. > [New process 178128] > [New process 294426] > [New process 350865] > Core was generated by `vmd'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x0c07a64148bd in virtio_shutdown (vm=0xc09e1418000) at > /syzkaller/src/usr.sbin/vmd/virtio.c:2018 > 2018vioscsi->file.close(vioscsi->file.p, 0); Greg, Can you test out the patch attached? +--+ Carlos > [Current thread is 1 (process 178128)] > (gdb) where > #0 0x0c07a64148bd in virtio_shutdown (vm=0xc09e1418000) at > /syzkaller/src/usr.sbin/vmd/virtio.c:2018 > #1 0x0c07a640cb0a in start_vm (vm=0xc09e1418000, fd=) > at /syzkaller/src/usr.sbin/vmd/vm.c:376 > #2 0x0c07a640c09e in vmm_start_vm (imsg=, > id=0x7f7e75e4, pid=0x7f7e75e0) at > /syzkaller/src/usr.sbin/vmd/vmm.c:686 > #3 0x0c07a640b7eb in vmm_dispatch_parent (fd=, > p=, imsg=0x7f7e7d58) at > /syzkaller/src/usr.sbin/vmd/vmm.c:299 > #4 0x0c07a6408b2f in proc_dispatch (fd=3, event=, > arg=0xc09d0d61000) at /syzkaller/src/usr.sbin/vmd/proc.c:660 > #5 0x0c09f915c64d in event_process_active (base=) at > /usr/src/lib/libevent/event.c:350 > #6 event_base_loop (base=0xc0a4b11e800, flags=0) at > /usr/src/lib/libevent/event.c:502 > #7 0x0c07a6409538 in proc_run (ps=0xc0a4b11a000, p=0xc07a6633080 > , procs=0xc07a6633160 , nproc=1, > run=0xc07a640af80 , arg=0x0) at > /syzkaller/src/usr.sbin/vmd/proc.c:602 > #8 0x0c07a640850b in proc_init (ps=0xc09e1418000, procs=0xc07a6633000 > , nproc=3, debug=-538846004, argc=1258557984, argv=0x0, > proc_id=PROC_VMM) at /syzkaller/src/usr.sbin/vmd/proc.c:260 > #9 0x0c07a6403a1d in main (argc=, argv=0x7f7e8008) > at /syzkaller/src/usr.sbin/vmd/vmd.c:812 > > Thanks > Greg > -- > nest.cx is Gmail hosted, use PGP for anything private. Key: > http://goo.gl/6dMsr > Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 Index: virtio.c === RCS file: /home/los/cvs/src/usr.sbin/vmd/virtio.c,v retrieving revision 1.70 diff -u -p -r1.70 virtio.c --- virtio.c28 Sep 2018 12:35:32 - 1.70 +++ virtio.c3 Oct 2018 18:28:05 - @@ -2015,7 +2015,9 @@ virtio_shutdown(struct vmd_vm *vm) int i; /* ensure that our disks are synced */ - vioscsi->file.close(vioscsi->file.p, 0); + if (vioscsi != NULL) + vioscsi->file.close(vioscsi->file.p, 0); + for (i = 0; i < nr_vioblk; i++) vioblk[i].file.close(vioblk[i].file.p, 0); }
vmd cores
Hi Mike, I'm getting core files from vmds. Here's the most recent one. Should I start collecting more stack traces and sending them to you? ci-openbsd$ doas /usr/local/bin/egdb /syzkaller/src/usr.sbin/vmd/obj/vmd /var/crash/vmd/89501.core Reading symbols from /syzkaller/src/usr.sbin/vmd/obj/vmd...done. [New process 178128] [New process 294426] [New process 350865] Core was generated by `vmd'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0c07a64148bd in virtio_shutdown (vm=0xc09e1418000) at /syzkaller/src/usr.sbin/vmd/virtio.c:2018 2018vioscsi->file.close(vioscsi->file.p, 0); [Current thread is 1 (process 178128)] (gdb) where #0 0x0c07a64148bd in virtio_shutdown (vm=0xc09e1418000) at /syzkaller/src/usr.sbin/vmd/virtio.c:2018 #1 0x0c07a640cb0a in start_vm (vm=0xc09e1418000, fd=) at /syzkaller/src/usr.sbin/vmd/vm.c:376 #2 0x0c07a640c09e in vmm_start_vm (imsg=, id=0x7f7e75e4, pid=0x7f7e75e0) at /syzkaller/src/usr.sbin/vmd/vmm.c:686 #3 0x0c07a640b7eb in vmm_dispatch_parent (fd=, p=, imsg=0x7f7e7d58) at /syzkaller/src/usr.sbin/vmd/vmm.c:299 #4 0x0c07a6408b2f in proc_dispatch (fd=3, event=, arg=0xc09d0d61000) at /syzkaller/src/usr.sbin/vmd/proc.c:660 #5 0x0c09f915c64d in event_process_active (base=) at /usr/src/lib/libevent/event.c:350 #6 event_base_loop (base=0xc0a4b11e800, flags=0) at /usr/src/lib/libevent/event.c:502 #7 0x0c07a6409538 in proc_run (ps=0xc0a4b11a000, p=0xc07a6633080 , procs=0xc07a6633160 , nproc=1, run=0xc07a640af80 , arg=0x0) at /syzkaller/src/usr.sbin/vmd/proc.c:602 #8 0x0c07a640850b in proc_init (ps=0xc09e1418000, procs=0xc07a6633000 , nproc=3, debug=-538846004, argc=1258557984, argv=0x0, proc_id=PROC_VMM) at /syzkaller/src/usr.sbin/vmd/proc.c:260 #9 0x0c07a6403a1d in main (argc=, argv=0x7f7e8008) at /syzkaller/src/usr.sbin/vmd/vmd.c:812 Thanks Greg -- nest.cx is Gmail hosted, use PGP for anything private. Key: http://goo.gl/6dMsr Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: rework bgpd.conf.5 a bit
On Wed, Oct 03, 2018 at 04:19:31PM +0200, Claudio Jeker wrote:
> I don't like how a lot of things got pushed into the global configuration
> section in bgpd.conf.5 especially since some bits should be their own
> sections. I see this for example for sets and for network statements.
>
> My proposal is to add two new sections which gives us the following
> structure:
> Macros
> Global Configuration
> Set Configuration
> Network Announcements
> MPLS VPN Configuration
> Neighbors and Groups
> Filter
>
> This allows also to write a bit more about sets and network statements
> which is in my opinion a good thing. This is not perfect but IMO better
> and a starting point for making this page even better.
> --
> :wq Claudio
>
hi.
just push ahead, i say.
jmc
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.179
> diff -u -p -r1.179 bgpd.conf.5
> --- bgpd.conf.5 3 Oct 2018 06:57:36 - 1.179
> +++ bgpd.conf.5 3 Oct 2018 13:56:48 -
> @@ -38,6 +38,12 @@ configuration file.
> .It Sy Global Configuration
> Global settings for
> .Xr bgpd 8 .
> +.It Sy Set Configuration
> +The definition of various lookup tables are done in this section.
> +.It Sy Network Announcements
> +Networks which should be announced by
> +.Xr bgpd 8
> +are set in this section.
> .It Sy MPLS VPN Configuration
> The definition and properties for BGP MPLS VPNs are set in this section.
> .It Sy Neighbors and Groups
> @@ -144,19 +150,6 @@ or as a large number (ASPLAIN format), f
> AS 196618
> .Ed
> .Pp
> -.It Xo
> -.Ic as-set Ar name
> -.Ic { Ar as-number ... Ic }
> -.Xc
> -An
> -.Ic as-set
> -holds a collection of AS numbers and can be used with the AS specific
> -parameter in
> -.Sx FILTER
> -rules.
> -Lookups against as-sets are more efficient than a large number of rules
> -which differ only in the AS number.
> -.Pp
> .It Ic connect-retry Ar seconds
> Set the number of seconds before retrying to open a connection.
> This timer should be sufficiently large in EBGP configurations.
> @@ -267,73 +260,6 @@ listen on 127.0.0.1
> Log received and sent updates.
> .Pp
> .It Xo
> -.Ic network
> -.Ar address Ns Li / Ns Ar prefix
> -.Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic static Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic connected Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic rtlabel Ar label Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic priority Ar number Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network prefix-set
> -.Ar name
> -.Op Ic set ...\&
> -.Xc
> -Announce the specified network as belonging to our AS.
> -If set to
> -.Ic connected ,
> -routes to directly attached networks will be announced.
> -If set to
> -.Ic static ,
> -all static routes will be announced.
> -If set to
> -.Ic rtlabel ,
> -routes with the specified
> -.Ar label
> -will be announced.
> -If set to
> -.Ic priority ,
> -routes with the specified
> -.Ar priority
> -will be announced.
> -If a prefix-set
> -.Ar name
> -is specified, all networks in the prefix-set will be announced.
> -.Bd -literal -offset indent
> -network 192.168.7.0/24
> -.Ed
> -.Pp
> -It is possible to set default
> -.Em AS path attributes
> -per
> -.Ic network
> -statement:
> -.Bd -literal -offset indent
> -network 192.168.7.0/24 set localpref 220
> -.Ed
> -.Pp
> -See also the
> -.Sx ATTRIBUTE SET
> -section.
> -.Pp
> -.It Xo
> .Ic nexthop
> .Ic qualify
> .Ic via
> @@ -351,42 +277,6 @@ daemons like
> .Xr ospfd 8 .
> .Pp
> .It Xo
> -.Ic prefix-set Ar name
> -.Ic { Ar address Ns Li / Ns Ar len ... Ic }
> -.Xc
> -A
> -.Ic prefix-set
> -holds a collection of prefixes and can be used in place
> -of the
> -.Ic prefix
> -parameter in
> -.Sx FILTER
> -rules.
> -.\" XXX not implemented
> -.\" and
> -.\".Ic network
> -.\" statements.
> -Lookups against prefix-sets are more efficient than a large number of rules
> -which differ only in prefix.
> -.Pp
> -A prefix can be followed by the prefixlen operators listed for the
> -.Ic prefix
> -parameter in the
> -.Sx PARAMETERS
> -section.
> -.Pp
> -The first example creates a set of prefixes called
> -.Dq private ,
> -to hold a number of RFC 1918 private network blocks.
> -The second example shows the use of prefixlen operators.
> -.Bd -literal -offset indent
> -prefix-set private { 10.0.0.0/8, 172.16.0.0/12,
> - 192.168.0.0/16, fc00::/7 }
> -prefix-set as64496set { 192.0.2.0/24 prefixlen >= 26,
> - 2001:db8::/32 or-longer }
> -.Ed
> -.Pp
> -.It Xo
> .Ic rde
> .Ic med
> .Ic compare
> @@ -445,21 +335,6 @@ The default is
> .Ic ignore .
> .Pp
> .It Xo
> -.Ic roa-set
> -.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn ...
> Ic }
> -.Xc
> -An
> -.Ic
Re: rework bgpd.conf.5 a bit
On Wed, Oct 03, 2018 at 03:40:47PM +0100, Stuart Henderson wrote:
> On 2018/10/03 16:19, Claudio Jeker wrote:
> > I don't like how a lot of things got pushed into the global configuration
> > section in bgpd.conf.5 especially since some bits should be their own
> > sections. I see this for example for sets and for network statements.
> >
> > My proposal is to add two new sections which gives us the following
> > structure:
> > Macros
> > Global Configuration
> > Set Configuration
> > Network Announcements
> > MPLS VPN Configuration
> > Neighbors and Groups
> > Filter
> >
> > This allows also to write a bit more about sets and network statements
> > which is in my opinion a good thing. This is not perfect but IMO better
> > and a starting point for making this page even better.
>
> I think that's a lot better. OK with a few comments inline
Thanks, changes applied.
> > +.Ic roa-set
> > +holds a collection of Validated ROA Payloads (VRP).
> > +Each received prefix is checked against the
> > +.Ic roa-set
> > +and the Origin Validation State (OVS) is set.
> > +.Bd -literal -offset indent
> > +roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
> > + 203.0.113.0/24 source-as 64496 }
> > +.Ed
> > +.El
>
> We should talk more about where these come from, but I think that's
> something to change later.
>
Indeed this section should be extended. I did not want to add too much to
this diff but I will look into adding more text for ROA validation.
Will commit tonight or tomorrow morning unless somebody objects.
--
:wq Claudio
Re: rework bgpd.conf.5 a bit
On 2018/10/03 16:19, Claudio Jeker wrote:
> I don't like how a lot of things got pushed into the global configuration
> section in bgpd.conf.5 especially since some bits should be their own
> sections. I see this for example for sets and for network statements.
>
> My proposal is to add two new sections which gives us the following
> structure:
> Macros
> Global Configuration
> Set Configuration
> Network Announcements
> MPLS VPN Configuration
> Neighbors and Groups
> Filter
>
> This allows also to write a bit more about sets and network statements
> which is in my opinion a good thing. This is not perfect but IMO better
> and a starting point for making this page even better.
I think that's a lot better. OK with a few comments inline
> --
> :wq Claudio
>
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.179
> diff -u -p -r1.179 bgpd.conf.5
> --- bgpd.conf.5 3 Oct 2018 06:57:36 - 1.179
> +++ bgpd.conf.5 3 Oct 2018 13:56:48 -
> @@ -38,6 +38,12 @@ configuration file.
> .It Sy Global Configuration
> Global settings for
> .Xr bgpd 8 .
> +.It Sy Set Configuration
> +The definition of various lookup tables are done in this section.
this could be simplified to "Various lookup tables are defined in this section"
> +.It Sy Network Announcements
> +Networks which should be announced by
> +.Xr bgpd 8
> +are set in this section.
> .It Sy MPLS VPN Configuration
> The definition and properties for BGP MPLS VPNs are set in this section.
> .It Sy Neighbors and Groups
> @@ -144,19 +150,6 @@ or as a large number (ASPLAIN format), f
> AS 196618
> .Ed
> .Pp
> -.It Xo
> -.Ic as-set Ar name
> -.Ic { Ar as-number ... Ic }
> -.Xc
> -An
> -.Ic as-set
> -holds a collection of AS numbers and can be used with the AS specific
> -parameter in
> -.Sx FILTER
> -rules.
> -Lookups against as-sets are more efficient than a large number of rules
> -which differ only in the AS number.
> -.Pp
> .It Ic connect-retry Ar seconds
> Set the number of seconds before retrying to open a connection.
> This timer should be sufficiently large in EBGP configurations.
> @@ -267,73 +260,6 @@ listen on 127.0.0.1
> Log received and sent updates.
> .Pp
> .It Xo
> -.Ic network
> -.Ar address Ns Li / Ns Ar prefix
> -.Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic static Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic connected Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic rtlabel Ar label Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic priority Ar number Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network prefix-set
> -.Ar name
> -.Op Ic set ...\&
> -.Xc
> -Announce the specified network as belonging to our AS.
> -If set to
> -.Ic connected ,
> -routes to directly attached networks will be announced.
> -If set to
> -.Ic static ,
> -all static routes will be announced.
> -If set to
> -.Ic rtlabel ,
> -routes with the specified
> -.Ar label
> -will be announced.
> -If set to
> -.Ic priority ,
> -routes with the specified
> -.Ar priority
> -will be announced.
> -If a prefix-set
> -.Ar name
> -is specified, all networks in the prefix-set will be announced.
> -.Bd -literal -offset indent
> -network 192.168.7.0/24
> -.Ed
> -.Pp
> -It is possible to set default
> -.Em AS path attributes
> -per
> -.Ic network
> -statement:
> -.Bd -literal -offset indent
> -network 192.168.7.0/24 set localpref 220
> -.Ed
> -.Pp
> -See also the
> -.Sx ATTRIBUTE SET
> -section.
> -.Pp
> -.It Xo
> .Ic nexthop
> .Ic qualify
> .Ic via
> @@ -351,42 +277,6 @@ daemons like
> .Xr ospfd 8 .
> .Pp
> .It Xo
> -.Ic prefix-set Ar name
> -.Ic { Ar address Ns Li / Ns Ar len ... Ic }
> -.Xc
> -A
> -.Ic prefix-set
> -holds a collection of prefixes and can be used in place
> -of the
> -.Ic prefix
> -parameter in
> -.Sx FILTER
> -rules.
> -.\" XXX not implemented
> -.\" and
> -.\".Ic network
> -.\" statements.
> -Lookups against prefix-sets are more efficient than a large number of rules
> -which differ only in prefix.
> -.Pp
> -A prefix can be followed by the prefixlen operators listed for the
> -.Ic prefix
> -parameter in the
> -.Sx PARAMETERS
> -section.
> -.Pp
> -The first example creates a set of prefixes called
> -.Dq private ,
> -to hold a number of RFC 1918 private network blocks.
> -The second example shows the use of prefixlen operators.
> -.Bd -literal -offset indent
> -prefix-set private { 10.0.0.0/8, 172.16.0.0/12,
> - 192.168.0.0/16, fc00::/7 }
> -prefix-set as64496set { 192.0.2.0/24 prefixlen >= 26,
> - 2001:db8::/32 or-longer }
> -.Ed
> -.Pp
> -.It Xo
> .Ic rde
> .Ic med
> .Ic compare
> @@ -445,21 +335,6 @@ The default is
> .Ic ignore .
> .Pp
> .It Xo
> -.Ic roa-set
> -.Ic { Ar address Ns Li /
rework bgpd.conf.5 a bit
I don't like how a lot of things got pushed into the global configuration
section in bgpd.conf.5 especially since some bits should be their own
sections. I see this for example for sets and for network statements.
My proposal is to add two new sections which gives us the following
structure:
Macros
Global Configuration
Set Configuration
Network Announcements
MPLS VPN Configuration
Neighbors and Groups
Filter
This allows also to write a bit more about sets and network statements
which is in my opinion a good thing. This is not perfect but IMO better
and a starting point for making this page even better.
--
:wq Claudio
Index: bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.179
diff -u -p -r1.179 bgpd.conf.5
--- bgpd.conf.5 3 Oct 2018 06:57:36 - 1.179
+++ bgpd.conf.5 3 Oct 2018 13:56:48 -
@@ -38,6 +38,12 @@ configuration file.
.It Sy Global Configuration
Global settings for
.Xr bgpd 8 .
+.It Sy Set Configuration
+The definition of various lookup tables are done in this section.
+.It Sy Network Announcements
+Networks which should be announced by
+.Xr bgpd 8
+are set in this section.
.It Sy MPLS VPN Configuration
The definition and properties for BGP MPLS VPNs are set in this section.
.It Sy Neighbors and Groups
@@ -144,19 +150,6 @@ or as a large number (ASPLAIN format), f
AS 196618
.Ed
.Pp
-.It Xo
-.Ic as-set Ar name
-.Ic { Ar as-number ... Ic }
-.Xc
-An
-.Ic as-set
-holds a collection of AS numbers and can be used with the AS specific
-parameter in
-.Sx FILTER
-rules.
-Lookups against as-sets are more efficient than a large number of rules
-which differ only in the AS number.
-.Pp
.It Ic connect-retry Ar seconds
Set the number of seconds before retrying to open a connection.
This timer should be sufficiently large in EBGP configurations.
@@ -267,73 +260,6 @@ listen on 127.0.0.1
Log received and sent updates.
.Pp
.It Xo
-.Ic network
-.Ar address Ns Li / Ns Ar prefix
-.Op Ic set ...\&
-.Xc
-.It Xo
-.Ic network
-.Pq Ic inet Ns | Ns Ic inet6
-.Ic static Op Ic set ...\&
-.Xc
-.It Xo
-.Ic network
-.Pq Ic inet Ns | Ns Ic inet6
-.Ic connected Op Ic set ...\&
-.Xc
-.It Xo
-.Ic network
-.Pq Ic inet Ns | Ns Ic inet6
-.Ic rtlabel Ar label Op Ic set ...\&
-.Xc
-.It Xo
-.Ic network
-.Pq Ic inet Ns | Ns Ic inet6
-.Ic priority Ar number Op Ic set ...\&
-.Xc
-.It Xo
-.Ic network prefix-set
-.Ar name
-.Op Ic set ...\&
-.Xc
-Announce the specified network as belonging to our AS.
-If set to
-.Ic connected ,
-routes to directly attached networks will be announced.
-If set to
-.Ic static ,
-all static routes will be announced.
-If set to
-.Ic rtlabel ,
-routes with the specified
-.Ar label
-will be announced.
-If set to
-.Ic priority ,
-routes with the specified
-.Ar priority
-will be announced.
-If a prefix-set
-.Ar name
-is specified, all networks in the prefix-set will be announced.
-.Bd -literal -offset indent
-network 192.168.7.0/24
-.Ed
-.Pp
-It is possible to set default
-.Em AS path attributes
-per
-.Ic network
-statement:
-.Bd -literal -offset indent
-network 192.168.7.0/24 set localpref 220
-.Ed
-.Pp
-See also the
-.Sx ATTRIBUTE SET
-section.
-.Pp
-.It Xo
.Ic nexthop
.Ic qualify
.Ic via
@@ -351,42 +277,6 @@ daemons like
.Xr ospfd 8 .
.Pp
.It Xo
-.Ic prefix-set Ar name
-.Ic { Ar address Ns Li / Ns Ar len ... Ic }
-.Xc
-A
-.Ic prefix-set
-holds a collection of prefixes and can be used in place
-of the
-.Ic prefix
-parameter in
-.Sx FILTER
-rules.
-.\" XXX not implemented
-.\" and
-.\".Ic network
-.\" statements.
-Lookups against prefix-sets are more efficient than a large number of rules
-which differ only in prefix.
-.Pp
-A prefix can be followed by the prefixlen operators listed for the
-.Ic prefix
-parameter in the
-.Sx PARAMETERS
-section.
-.Pp
-The first example creates a set of prefixes called
-.Dq private ,
-to hold a number of RFC 1918 private network blocks.
-The second example shows the use of prefixlen operators.
-.Bd -literal -offset indent
-prefix-set private { 10.0.0.0/8, 172.16.0.0/12,
- 192.168.0.0/16, fc00::/7 }
-prefix-set as64496set { 192.0.2.0/24 prefixlen >= 26,
- 2001:db8::/32 or-longer }
-.Ed
-.Pp
-.It Xo
.Ic rde
.Ic med
.Ic compare
@@ -445,21 +335,6 @@ The default is
.Ic ignore .
.Pp
.It Xo
-.Ic roa-set
-.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn ... Ic
}
-.Xc
-An
-.Ic roa-set
-holds a collection of Validated ROA Payloads (VRP).
-Each received prefix is checked against the
-.Ic roa-set
-and the Origin Validation State (OVS) is set.
-.Bd -literal -offset indent
-roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
- 203.0.113.0/24 source-as 64496 }
-.Ed
-.Pp
-.It Xo
.Ic route-collector
.Pq Ic yes Ns | Ns Ic no
.Xc
@@ -516,6 +391,171 @@ to EBGP neighbors are not prepended with
The default is
.Ic no .
.El
+.Sh SET CONFIGURATION
+.Xr bgpd 8
Re: lldb: build and install
> Date: Wed, 3 Oct 2018 14:28:41 +0200 > From: Patrick Wildt > > On Tue, Oct 02, 2018 at 06:07:22PM +0200, Mark Kettenis wrote: > > > Date: Tue, 2 Oct 2018 17:24:42 +0200 > > > From: Patrick Wildt > > > > > > Hi, > > > > > > we already do have the sources for LLDB, the only thing left to do is > > > add the build infrastructure so that we actually compile all the > > > independent pieces and link them together. Aparently LLDB also makes > > > use of some of the clang libraries, so those are part of LLDB linking > > > dependencies as well. > > > > > > Since we have no Python in base we have to explicitly disable Python, > > > otherwise it will try to use Python headers and probably also link > > > against it. > > > > > > According to kettenis@, debugging core files should work, actually > > > running stuff probably won't. Still, having lldb is a first step. > > > > > > Compiled on amd64, tests on other clang architectures would be nice. > > > > > > Feedback? ok? > > > > I would like to get this in. That said, I'm not sure lldb in its > > current state is useful enough to ship in 6.4. > > Even then I'd still like to put this in so that we can have a go at > making it useful. We can still disable it for the release if we see > that it wouldn't be reasonable shipping it. Yes, we can simply drop installing the lldb binary. > So I'd go ahead and commit tomorrow or so if there are no further > objections. Building on armv7 and arm64 right now. Will take a while...
bgpd refactor code to withdraw all prefixes
In one case (when a peer changes RIB) the RDE needs to withdraw all
prefixes of that peer and then during softreconfig it will load the
prefixes freshly form the new RIB. Since we now have a list of all
prefixes that have been sent to the peer use that one instead of doing a
full table walk over the old RIB.
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.433
diff -u -p -r1.433 rde.c
--- rde.c 3 Oct 2018 11:36:39 - 1.433
+++ rde.c 3 Oct 2018 12:37:28 -
@@ -96,7 +96,6 @@ static voidrde_softreconfig_out_done(v
static void rde_softreconfig_done(void);
static void rde_softreconfig_out(struct rib_entry *, void *);
static void rde_softreconfig_in(struct rib_entry *, void *);
-static void rde_softreconfig_unload_peer(struct rib_entry *, void *);
voidrde_up_dump_upcall(struct rib_entry *, void *);
voidrde_update_queue_runner(void);
voidrde_update6_queue_runner(u_int8_t);
@@ -2929,8 +2928,7 @@ rde_reload_done(void)
peer->reconf_out = 0;
peer->reconf_rib = 0;
if (peer->rib != rib_find(peer->conf.rib)) {
- rib_dump(peer->rib, rde_softreconfig_unload_peer, peer,
- AID_UNSPEC);
+ up_withdraw_all(peer);
peer->rib = rib_find(peer->conf.rib);
if (peer->rib == NULL)
fatalx("King Bula's peer met an unknown RIB");
@@ -3226,32 +3224,6 @@ rde_softreconfig_out(struct rib_entry *r
if (peer->rib == re_rib(re) && peer->reconf_out)
rde_softreconfig_out_peer(re, peer);
}
-}
-
-static void
-rde_softreconfig_unload_peer(struct rib_entry *re, void *ptr)
-{
- struct filterstate ostate;
- struct rde_peer *peer = ptr;
- struct prefix *p = re->active;
- struct pt_entry *pt;
- struct bgpd_addr addr;
-
- pt = re->prefix;
- pt_getaddr(pt, );
-
- /* check if prefix was announced */
- if (up_test_update(peer, p) != 1)
- return;
-
- rde_filterstate_prep(, prefix_aspath(p), prefix_nexthop(p),
- prefix_nhflags(p));
- if (rde_filter(out_rules_tmp, peer, p, ) != ACTION_DENY) {
- /* send withdraw */
- up_rib_remove(peer, re);
- up_generate(peer, NULL, , pt->prefixlen);
- }
- rde_filterstate_clean();
}
/*
Index: rde.h
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
retrieving revision 1.196
diff -u -p -r1.196 rde.h
--- rde.h 1 Oct 2018 23:09:53 - 1.196
+++ rde.h 3 Oct 2018 12:37:15 -
@@ -555,6 +555,7 @@ void up_init(struct rde_peer *);
voidup_down(struct rde_peer *);
int up_rib_remove(struct rde_peer *, struct rib_entry *);
voidup_rib_add(struct rde_peer *, struct rib_entry *);
+voidup_withdraw_all(struct rde_peer *);
int up_test_update(struct rde_peer *, struct prefix *);
int up_generate(struct rde_peer *, struct filterstate *,
struct bgpd_addr *, u_int8_t);
Index: rde_update.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_update.c,v
retrieving revision 1.100
diff -u -p -r1.100 rde_update.c
--- rde_update.c29 Sep 2018 07:43:36 - 1.100
+++ rde_update.c3 Oct 2018 12:38:28 -
@@ -245,6 +245,22 @@ up_rib_add(struct rde_peer *peer, struct
free(ur);
}
+void
+up_withdraw_all(struct rde_peer *peer)
+{
+ struct bgpd_addr addr;
+ struct update_rib *ur, *nur;
+
+ RB_FOREACH_SAFE(ur, uptree_rib, >up_rib, nur) {
+ RB_REMOVE(uptree_rib, >up_rib, ur);
+
+ /* withdraw prefix */
+ pt_getaddr(ur->re->prefix, );
+ up_generate(peer, NULL, , ur->re->prefix->prefixlen);
+ free(ur);
+ }
+}
+
int
up_add(struct rde_peer *peer, struct update_prefix *p, struct update_attr *a)
{
Re: lldb: build and install
On Tue, Oct 02, 2018 at 06:07:22PM +0200, Mark Kettenis wrote: > > Date: Tue, 2 Oct 2018 17:24:42 +0200 > > From: Patrick Wildt > > > > Hi, > > > > we already do have the sources for LLDB, the only thing left to do is > > add the build infrastructure so that we actually compile all the > > independent pieces and link them together. Aparently LLDB also makes > > use of some of the clang libraries, so those are part of LLDB linking > > dependencies as well. > > > > Since we have no Python in base we have to explicitly disable Python, > > otherwise it will try to use Python headers and probably also link > > against it. > > > > According to kettenis@, debugging core files should work, actually > > running stuff probably won't. Still, having lldb is a first step. > > > > Compiled on amd64, tests on other clang architectures would be nice. > > > > Feedback? ok? > > I would like to get this in. That said, I'm not sure lldb in its > current state is useful enough to ship in 6.4. Even then I'd still like to put this in so that we can have a go at making it useful. We can still disable it for the release if we see that it wouldn't be reasonable shipping it. So I'd go ahead and commit tomorrow or so if there are no further objections.
Re: bgpctl(8): filter based on origin validation state
On Wed, Oct 03, 2018 at 01:17:59PM +0200, Claudio Jeker wrote:
> On Wed, Oct 03, 2018 at 01:08:19PM +0200, Denis Fondras wrote:
> > Add a 'ovs' command to filter on Origin Validation State.
> >
> > 'bgpctl show rib ovs invalid' returns only prefixes that failed route origin
> > validation.
> >
> >
> > Index: bgpctl/bgpctl.8
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.8,v
> > retrieving revision 1.82
> > diff -u -p -r1.82 bgpctl.8
> > --- bgpctl/bgpctl.8 9 Sep 2018 12:53:00 - 1.82
> > +++ bgpctl/bgpctl.8 3 Oct 2018 10:53:08 -
> > @@ -357,6 +357,8 @@ Show only entries from the specified RIB
> > Show all entries with
> > .Ar as
> > anywhere but rightmost.
> > +.It Cm ovs Pq Ic valid | not-found | invalid
> > +Show all entries with matching Origin Validation State (OVS).
> > .El
> > .Pp
> > Additionally, the following
> > Index: bgpctl/parser.c
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
> > retrieving revision 1.85
> > diff -u -p -r1.85 parser.c
> > --- bgpctl/parser.c 7 Sep 2018 05:47:02 - 1.85
> > +++ bgpctl/parser.c 3 Oct 2018 10:53:08 -
> > @@ -81,6 +81,7 @@ static const struct token t_show[];
> > static const struct token t_show_summary[];
> > static const struct token t_show_fib[];
> > static const struct token t_show_rib[];
> > +static const struct token t_show_ovs[];
> > static const struct token t_show_mrt[];
> > static const struct token t_show_mrt_file[];
> > static const struct token t_show_rib_neigh[];
> > @@ -185,11 +186,18 @@ static const struct token t_show_rib[] =
> > { KEYWORD, "table",NONE, t_show_rib_rib},
> > { KEYWORD, "summary", SHOW_SUMMARY, t_show_summary},
> > { KEYWORD, "memory", SHOW_RIB_MEM, NULL},
> > + { KEYWORD, "ovs", NONE, t_show_ovs},
> > { FAMILY, "", NONE, t_show_rib},
> > { PREFIX, "", NONE, t_show_prefix},
> > { ENDTOKEN, "", NONE, NULL}
> > };
> >
> > +static const struct token t_show_ovs[] = {
> > + { FLAG, "valid" , F_CTL_OVS_VALID,t_show_rib},
> > + { FLAG, "invalid", F_CTL_OVS_INVALID, t_show_rib},
> > + { FLAG, "not-found",F_CTL_OVS_NOTFOUND, t_show_rib},
> > + { ENDTOKEN, "", NONE, NULL}
> > +};
> >
> > static const struct token t_show_mrt[] = {
> > { NOTOKEN, "", NONE, NULL},
> > Index: bgpd/bgpd.h
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
> > retrieving revision 1.348
> > diff -u -p -r1.348 bgpd.h
> > --- bgpd/bgpd.h 1 Oct 2018 23:09:53 - 1.348
> > +++ bgpd/bgpd.h 3 Oct 2018 10:53:08 -
> > @@ -88,6 +88,10 @@
> > #defineF_RTLABEL 0x1
> > #defineF_CTL_SSV 0x2 /* only used by bgpctl */
> > #defineF_CTL_INVALID 0x4 /* only used by bgpctl */
> > +#defineF_CTL_OVS_VALID 0x8
> > +#defineF_CTL_OVS_INVALID 0x10
> > +#defineF_CTL_OVS_NOTFOUND 0x20
> > +
>
> Extra newline.
>
> >
> > /*
> > * Note that these numeric assignments differ from the numbers commonly
> > Index: bgpd/rde.c
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> > retrieving revision 1.432
> > diff -u -p -r1.432 rde.c
> > --- bgpd/rde.c 1 Oct 2018 23:09:53 - 1.432
> > +++ bgpd/rde.c 3 Oct 2018 10:53:08 -
> > @@ -126,6 +126,7 @@ void network_dump_upcall(struct rib_en
> >
> > voidrde_shutdown(void);
> > int sa_cmp(struct bgpd_addr *, struct sockaddr *);
> > +int ovs_match(struct prefix *, u_int32_t);
> >
> > volatile sig_atomic_t rde_quit = 0;
> > struct bgpd_config *conf, *nconf;
> > @@ -2286,6 +2287,8 @@ rde_dump_filter(struct prefix *p, struct
> > !community_large_match(asp, req->large_community.as,
> > req->large_community.ld1, req->large_community.ld2))
> > return;
> > + if (!ovs_match(p, req->flags))
> > + return;
> > rde_dump_rib_as(p, asp, req->pid, req->flags);
> > }
> > }
> > @@ -3958,4 +3961,30 @@ rde_roa_validity(struct rde_prefixset *p
> >
> > r = trie_roa_check(>th, prefix, plen, as);
> > return (r & ROA_MASK);
> > +}
> > +
> > +int
> > +ovs_match(struct prefix *p, u_int32_t flag)
> > +{
> > + if (flag & F_CTL_OVS_VALID || flag & F_CTL_OVS_INVALID ||
> > + flag & F_CTL_OVS_NOTFOUND) {
>
> I would write this as:
> if (flag & (F_CTL_OVS_VALID|F_CTL_OVS_INVALID|F_CTL_OVS_NOTFOUND)) {
>
Thank you.
> > +
Re: bgpctl(8): filter based on origin validation state
On Wed, Oct 03, 2018 at 01:08:19PM +0200, Denis Fondras wrote:
> Add a 'ovs' command to filter on Origin Validation State.
>
> 'bgpctl show rib ovs invalid' returns only prefixes that failed route origin
> validation.
>
>
> Index: bgpctl/bgpctl.8
> ===
> RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.8,v
> retrieving revision 1.82
> diff -u -p -r1.82 bgpctl.8
> --- bgpctl/bgpctl.8 9 Sep 2018 12:53:00 - 1.82
> +++ bgpctl/bgpctl.8 3 Oct 2018 10:53:08 -
> @@ -357,6 +357,8 @@ Show only entries from the specified RIB
> Show all entries with
> .Ar as
> anywhere but rightmost.
> +.It Cm ovs Pq Ic valid | not-found | invalid
> +Show all entries with matching Origin Validation State (OVS).
> .El
> .Pp
> Additionally, the following
> Index: bgpctl/parser.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
> retrieving revision 1.85
> diff -u -p -r1.85 parser.c
> --- bgpctl/parser.c 7 Sep 2018 05:47:02 - 1.85
> +++ bgpctl/parser.c 3 Oct 2018 10:53:08 -
> @@ -81,6 +81,7 @@ static const struct token t_show[];
> static const struct token t_show_summary[];
> static const struct token t_show_fib[];
> static const struct token t_show_rib[];
> +static const struct token t_show_ovs[];
> static const struct token t_show_mrt[];
> static const struct token t_show_mrt_file[];
> static const struct token t_show_rib_neigh[];
> @@ -185,11 +186,18 @@ static const struct token t_show_rib[] =
> { KEYWORD, "table",NONE, t_show_rib_rib},
> { KEYWORD, "summary", SHOW_SUMMARY, t_show_summary},
> { KEYWORD, "memory", SHOW_RIB_MEM, NULL},
> + { KEYWORD, "ovs", NONE, t_show_ovs},
> { FAMILY, "", NONE, t_show_rib},
> { PREFIX, "", NONE, t_show_prefix},
> { ENDTOKEN, "", NONE, NULL}
> };
>
> +static const struct token t_show_ovs[] = {
> + { FLAG, "valid" , F_CTL_OVS_VALID,t_show_rib},
> + { FLAG, "invalid", F_CTL_OVS_INVALID, t_show_rib},
> + { FLAG, "not-found",F_CTL_OVS_NOTFOUND, t_show_rib},
> + { ENDTOKEN, "", NONE, NULL}
> +};
>
> static const struct token t_show_mrt[] = {
> { NOTOKEN, "", NONE, NULL},
> Index: bgpd/bgpd.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
> retrieving revision 1.348
> diff -u -p -r1.348 bgpd.h
> --- bgpd/bgpd.h 1 Oct 2018 23:09:53 - 1.348
> +++ bgpd/bgpd.h 3 Oct 2018 10:53:08 -
> @@ -88,6 +88,10 @@
> #define F_RTLABEL 0x1
> #define F_CTL_SSV 0x2 /* only used by bgpctl */
> #define F_CTL_INVALID 0x4 /* only used by bgpctl */
> +#define F_CTL_OVS_VALID 0x8
> +#define F_CTL_OVS_INVALID 0x10
> +#define F_CTL_OVS_NOTFOUND 0x20
> +
Extra newline.
>
> /*
> * Note that these numeric assignments differ from the numbers commonly
> Index: bgpd/rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.432
> diff -u -p -r1.432 rde.c
> --- bgpd/rde.c1 Oct 2018 23:09:53 - 1.432
> +++ bgpd/rde.c3 Oct 2018 10:53:08 -
> @@ -126,6 +126,7 @@ void network_dump_upcall(struct rib_en
>
> void rde_shutdown(void);
> int sa_cmp(struct bgpd_addr *, struct sockaddr *);
> +int ovs_match(struct prefix *, u_int32_t);
>
> volatile sig_atomic_t rde_quit = 0;
> struct bgpd_config *conf, *nconf;
> @@ -2286,6 +2287,8 @@ rde_dump_filter(struct prefix *p, struct
> !community_large_match(asp, req->large_community.as,
> req->large_community.ld1, req->large_community.ld2))
> return;
> + if (!ovs_match(p, req->flags))
> + return;
> rde_dump_rib_as(p, asp, req->pid, req->flags);
> }
> }
> @@ -3958,4 +3961,30 @@ rde_roa_validity(struct rde_prefixset *p
>
> r = trie_roa_check(>th, prefix, plen, as);
> return (r & ROA_MASK);
> +}
> +
> +int
> +ovs_match(struct prefix *p, u_int32_t flag)
> +{
> + if (flag & F_CTL_OVS_VALID || flag & F_CTL_OVS_INVALID ||
> + flag & F_CTL_OVS_NOTFOUND) {
I would write this as:
if (flag & (F_CTL_OVS_VALID|F_CTL_OVS_INVALID|F_CTL_OVS_NOTFOUND)) {
> + switch (prefix_vstate(p)) {
> + case ROA_VALID:
> + if (!(flag & F_CTL_OVS_VALID))
> + return 0;
> + break;
> + case ROA_INVALID:
> +
bgpctl(8): filter based on origin validation state
Add a 'ovs' command to filter on Origin Validation State.
'bgpctl show rib ovs invalid' returns only prefixes that failed route origin
validation.
Index: bgpctl/bgpctl.8
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.8,v
retrieving revision 1.82
diff -u -p -r1.82 bgpctl.8
--- bgpctl/bgpctl.8 9 Sep 2018 12:53:00 - 1.82
+++ bgpctl/bgpctl.8 3 Oct 2018 10:53:08 -
@@ -357,6 +357,8 @@ Show only entries from the specified RIB
Show all entries with
.Ar as
anywhere but rightmost.
+.It Cm ovs Pq Ic valid | not-found | invalid
+Show all entries with matching Origin Validation State (OVS).
.El
.Pp
Additionally, the following
Index: bgpctl/parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.85
diff -u -p -r1.85 parser.c
--- bgpctl/parser.c 7 Sep 2018 05:47:02 - 1.85
+++ bgpctl/parser.c 3 Oct 2018 10:53:08 -
@@ -81,6 +81,7 @@ static const struct token t_show[];
static const struct token t_show_summary[];
static const struct token t_show_fib[];
static const struct token t_show_rib[];
+static const struct token t_show_ovs[];
static const struct token t_show_mrt[];
static const struct token t_show_mrt_file[];
static const struct token t_show_rib_neigh[];
@@ -185,11 +186,18 @@ static const struct token t_show_rib[] =
{ KEYWORD, "table",NONE, t_show_rib_rib},
{ KEYWORD, "summary", SHOW_SUMMARY, t_show_summary},
{ KEYWORD, "memory", SHOW_RIB_MEM, NULL},
+ { KEYWORD, "ovs", NONE, t_show_ovs},
{ FAMILY, "", NONE, t_show_rib},
{ PREFIX, "", NONE, t_show_prefix},
{ ENDTOKEN, "", NONE, NULL}
};
+static const struct token t_show_ovs[] = {
+ { FLAG, "valid" , F_CTL_OVS_VALID,t_show_rib},
+ { FLAG, "invalid", F_CTL_OVS_INVALID, t_show_rib},
+ { FLAG, "not-found",F_CTL_OVS_NOTFOUND, t_show_rib},
+ { ENDTOKEN, "", NONE, NULL}
+};
static const struct token t_show_mrt[] = {
{ NOTOKEN, "", NONE, NULL},
Index: bgpd/bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.348
diff -u -p -r1.348 bgpd.h
--- bgpd/bgpd.h 1 Oct 2018 23:09:53 - 1.348
+++ bgpd/bgpd.h 3 Oct 2018 10:53:08 -
@@ -88,6 +88,10 @@
#defineF_RTLABEL 0x1
#defineF_CTL_SSV 0x2 /* only used by bgpctl */
#defineF_CTL_INVALID 0x4 /* only used by bgpctl */
+#defineF_CTL_OVS_VALID 0x8
+#defineF_CTL_OVS_INVALID 0x10
+#defineF_CTL_OVS_NOTFOUND 0x20
+
/*
* Note that these numeric assignments differ from the numbers commonly
Index: bgpd/rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.432
diff -u -p -r1.432 rde.c
--- bgpd/rde.c 1 Oct 2018 23:09:53 - 1.432
+++ bgpd/rde.c 3 Oct 2018 10:53:08 -
@@ -126,6 +126,7 @@ void network_dump_upcall(struct rib_en
voidrde_shutdown(void);
int sa_cmp(struct bgpd_addr *, struct sockaddr *);
+int ovs_match(struct prefix *, u_int32_t);
volatile sig_atomic_t rde_quit = 0;
struct bgpd_config *conf, *nconf;
@@ -2286,6 +2287,8 @@ rde_dump_filter(struct prefix *p, struct
!community_large_match(asp, req->large_community.as,
req->large_community.ld1, req->large_community.ld2))
return;
+ if (!ovs_match(p, req->flags))
+ return;
rde_dump_rib_as(p, asp, req->pid, req->flags);
}
}
@@ -3958,4 +3961,30 @@ rde_roa_validity(struct rde_prefixset *p
r = trie_roa_check(>th, prefix, plen, as);
return (r & ROA_MASK);
+}
+
+int
+ovs_match(struct prefix *p, u_int32_t flag)
+{
+ if (flag & F_CTL_OVS_VALID || flag & F_CTL_OVS_INVALID ||
+ flag & F_CTL_OVS_NOTFOUND) {
+ switch (prefix_vstate(p)) {
+ case ROA_VALID:
+ if (!(flag & F_CTL_OVS_VALID))
+ return 0;
+ break;
+ case ROA_INVALID:
+ if (!(flag & F_CTL_OVS_INVALID))
+ return 0;
+ break;
+ case ROA_NOTFOUND:
+ if (!(flag & F_CTL_OVS_NOTFOUND))
+ return 0;
+ break;
+ default:
+ break;
+ }
+
Re: Qcow2: External snapshots
On Tue, Oct 02, 2018 at 11:13:35PM -0700, Ori Bernstein wrote:
> On Mon, 1 Oct 2018 11:24:01 -0700, Ori Bernstein wrote:
>
> > On Mon, 1 Oct 2018 12:55:12 +0200
> > Reyk Floeter wrote:
> >
> > > Hi Ori,
> > >
> > > On Sun, Sep 30, 2018 at 12:27:00PM -0700, Ori Bernstein wrote:
> > > > I've added support to vmd for external snapshots. That is,
> > > > snapshots that are derived from a base image. Data lookups
> > > > start in the derived image, and if the derived image does not
> > > > contain some data, the search proceeds ot the base image.
> > > > Multiple derived images may exist off of a single base image.
> > > >
> > >
> > > Nice work! This will be quite useful, thanks.
> > >
> > > I think I broke your diff as my last commit to derive the raw/qcow2
> > > format introduced some conflicts. I had posted it on hackers@ and
> > > forgot that your aren't on the internal list yet - sorry for that.
>
> Updated version. Changes from the last diff:
>
> - Merge in syntax changes.
> - Don't over-read when getting the base images.
> - Fix relative paths in base images.
> - Allow multiple derived images to use a single base image, and allow a user
> with only read permisssions to base their images on top of it.
> - Probe the base image size, use/validate it when craeting disk images.
> - Fix style a bit (long lines, changing from sizeof foo to sizeof(foo).
> - Move a define out of vmmvar.h
You're still using VMM_MAX_BASE_PER_DISK instead of
VM_MAX_BASE_PER_DISK in the code. I patched the diff to make it
compile without the vmmvar.h change here.
> - And update the manpage with these changes.
> - Improve error checking around creating/resolving base disk paths.
>
Light testing works except of an issue with read-only base images; the
required fix is in the comments below.
Other than that, it is really cool to run many VMs from a single base
image. In my tests, I installed OpenBSD once and started a few VMs
using the installed disk as a base.
More comments below.
Reyk
>
> diff --git regress/usr.sbin/vmd/diskfmt/Makefile
> regress/usr.sbin/vmd/diskfmt/Makefile
> index c2a5f42d5f6..1f8673e0e26 100644
> --- regress/usr.sbin/vmd/diskfmt/Makefile
> +++ regress/usr.sbin/vmd/diskfmt/Makefile
> @@ -11,7 +11,7 @@
> VMD_DIR=$(BSDSRCDIR)/usr.sbin/vmd/
>
> PROG=vioscribble
> -SRCS=vioscribble.c $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c
> +SRCS=vioscribble.c vioqcow2.c vioraw.c
> CFLAGS+=-I$(VMD_DIR) -pthread
> LDFLAGS+=-pthread
>
> @@ -26,3 +26,6 @@ scribble-images:
> .PHONY: ${REGRESS_TARGETS} scribble-images
>
> .include
> +
> +vioqcow2.c vioraw.c: $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c
> + cp $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c .
> diff --git regress/usr.sbin/vmd/diskfmt/vioscribble.c
> regress/usr.sbin/vmd/diskfmt/vioscribble.c
> index 14d720db652..1da8efedac7 100644
> --- regress/usr.sbin/vmd/diskfmt/vioscribble.c
> +++ regress/usr.sbin/vmd/diskfmt/vioscribble.c
> @@ -122,16 +122,18 @@ main(int argc, char **argv)
> verbose = !!getenv("VERBOSE");
> qcfd = open("scribble.qc2", O_RDWR);
> rawfd = open("scribble.raw", O_RDWR);
> - if (qcfd == -1 || virtio_init_qcow2(, , qcfd) == -1)
> + if (qcfd == -1)
> err(1, "unable to open qcow");
> - if (rawfd == -1 || virtio_init_raw(, , rawfd) == -1)
> + if (virtio_init_qcow2(, , , 1) == -1)
> + err(1, "unable to init qcow");
> + if (rawfd == -1 || virtio_init_raw(, , , 1) == -1)
> err(1, "unable to open raw");
>
> srandom_deterministic(123);
>
> /* scribble to both disks */
> printf("scribbling...\n");
> - for (i = 0; i < 16; i++) {
> + for (i = 0; i < 1024*16; i++) {
> off = (random() % DISKSZ);
> len = random() % sizeof buf + 1;
> fill(off, buf, sizeof buf);
> diff --git usr.sbin/vmctl/main.c usr.sbin/vmctl/main.c
> index 8748ecfdedc..4637256452b 100644
> --- usr.sbin/vmctl/main.c
> +++ usr.sbin/vmctl/main.c
> @@ -67,7 +67,8 @@ int ctl_receive(struct parse_result *, int, char
> *[]);
>
> struct ctl_command ctl_commands[] = {
> { "console",CMD_CONSOLE,ctl_console,"id" },
> - { "create", CMD_CREATE, ctl_create, "\"path\" -s size", 1 },
> + { "create", CMD_CREATE, ctl_create,
> + "\"path\" [-s size] [-b base]", 1 },
> { "load", CMD_LOAD, ctl_load, "\"path\"" },
> { "log",CMD_LOG,ctl_log,"[verbose|brief]" },
> { "reload", CMD_RELOAD, ctl_reload, "" },
> @@ -538,47 +539,54 @@ int
> ctl_create(struct parse_result *res, int argc, char *argv[])
> {
> int ch, ret, type;
> - const char *paths[2], *disk, *format;
> + const char *disk, *format, *base;
>
> if (argc < 2)
> ctl_usage(res->ctl);
>
> + base = NULL;
> type = parse_disktype(argv[1], );
>
> - paths[0] = disk;
> -
Re: Update bgpd.conf man to reflect ROA changes
On Wed, Oct 03, 2018 at 08:19:26AM +0200, Denis Fondras wrote:
> On Tue, Oct 02, 2018 at 09:13:47PM +0100, Jason McIntyre wrote:
> > On Tue, Oct 02, 2018 at 08:26:02PM +0200, Denis Fondras wrote:
> > > Reorder text and be more precise.
> > >
> > > Index: bgpd.conf.5
> > > ===
> > > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> > > retrieving revision 1.178
> > > diff -u -p -r1.178 bgpd.conf.5
> > > --- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
> > > +++ bgpd.conf.5 2 Oct 2018 18:25:17 -
> > > @@ -445,6 +445,21 @@ The default is
> > > .Ic ignore .
> > > .Pp
> > > .It Xo
> > > +.Ic roa-set
> > > +.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn
> > > ... Ic }
> > > +.Xc
> > > +A
> > > +.Ic roa-set
> > > +holds a collection of Validated ROA Payload (VRP).
> >
> > hi.
> >
> > i'm unsure about the terminology exactly. but can you have a "collection
> > of payload"? doesn;t it have to be "payload data" or something?
> >
> > i think at least it needs to be plural (payloads). like, you wouldn;t
> > have a collection of bent umbrella. er, that's as an example..
> >
> > or you could remove "collection of".
> >
>
> Reading RFC6811 (page 4&5), I understand that Validated ROA Payload is one
> prefix in the list. Am I wrong ?
> Ok to make it plural though.
I think we should not use technical terms that are not self explanatory
but lets put this in now as a start. I agree with jmc@ that it should be
payloads (plural). Lets start with this.
OK claudio@
--
:wq Claudio
> > jmc
> >
> > > +Each received prefix is checked against the
> > > +.Ic roa-set
> > > +and the Origin Validation Status (OVS) is set.
> > > +.Bd -literal -offset indent
> > > +roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
> > > + 203.0.113.0/24 source-as 64496 }
> > > +.Ed
> > > +.Pp
> > > +.It Xo
> > > .Ic route-collector
> > > .Pq Ic yes Ns | Ns Ic no
> > > .Xc
> > > @@ -1386,6 +1401,14 @@ can be set to
> > > in which case the nexthop is compared against the address of the
> > > neighbor.
> > > Nexthop filtering is not supported on locally announced networks and one
> > > must
> > > take into consideration previous rules overwriting nexthops.
> > > +.Pp
> > > +.It Xo
> > > +.Ic ovs
> > > +.Pq Ic valid | not-found | invalid
> > > +.Xc
> > > +This rule applies only to
> > > +.Em UPDATES
> > > +where the Origin Validation Status (OVS) matches.
> > > .Pp
> > > .It Ic prefix Ar address Ns Li / Ns Ar len
> > > .It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
> > >
> >
>
Re: Update bgpd.conf man to reflect ROA changes
On Wed, Oct 03, 2018 at 08:19:26AM +0200, Denis Fondras wrote:
> On Tue, Oct 02, 2018 at 09:13:47PM +0100, Jason McIntyre wrote:
> > On Tue, Oct 02, 2018 at 08:26:02PM +0200, Denis Fondras wrote:
> > > Reorder text and be more precise.
> > >
> > > Index: bgpd.conf.5
> > > ===
> > > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> > > retrieving revision 1.178
> > > diff -u -p -r1.178 bgpd.conf.5
> > > --- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
> > > +++ bgpd.conf.5 2 Oct 2018 18:25:17 -
> > > @@ -445,6 +445,21 @@ The default is
> > > .Ic ignore .
> > > .Pp
> > > .It Xo
> > > +.Ic roa-set
> > > +.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn
> > > ... Ic }
> > > +.Xc
> > > +A
> > > +.Ic roa-set
> > > +holds a collection of Validated ROA Payload (VRP).
> >
> > hi.
> >
> > i'm unsure about the terminology exactly. but can you have a "collection
> > of payload"? doesn;t it have to be "payload data" or something?
> >
> > i think at least it needs to be plural (payloads). like, you wouldn;t
> > have a collection of bent umbrella. er, that's as an example..
> >
> > or you could remove "collection of".
> >
>
> Reading RFC6811 (page 4&5), I understand that Validated ROA Payload is one
> prefix in the list. Am I wrong ?
> Ok to make it plural though.
>
it reads fine as plural.
jmc
> > jmc
> >
> > > +Each received prefix is checked against the
> > > +.Ic roa-set
> > > +and the Origin Validation Status (OVS) is set.
> > > +.Bd -literal -offset indent
> > > +roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
> > > + 203.0.113.0/24 source-as 64496 }
> > > +.Ed
> > > +.Pp
> > > +.It Xo
> > > .Ic route-collector
> > > .Pq Ic yes Ns | Ns Ic no
> > > .Xc
> > > @@ -1386,6 +1401,14 @@ can be set to
> > > in which case the nexthop is compared against the address of the
> > > neighbor.
> > > Nexthop filtering is not supported on locally announced networks and one
> > > must
> > > take into consideration previous rules overwriting nexthops.
> > > +.Pp
> > > +.It Xo
> > > +.Ic ovs
> > > +.Pq Ic valid | not-found | invalid
> > > +.Xc
> > > +This rule applies only to
> > > +.Em UPDATES
> > > +where the Origin Validation Status (OVS) matches.
> > > .Pp
> > > .It Ic prefix Ar address Ns Li / Ns Ar len
> > > .It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
> > >
> >
>
Re: Qcow2: External snapshots
On Tue, Oct 02, 2018 at 11:13:35PM -0700, Ori Bernstein wrote: > > Updated version. Changes from the last diff: > > - Merge in syntax changes. > - Don't over-read when getting the base images. > - Fix relative paths in base images. > - Allow multiple derived images to use a single base image, and allow a user > with only read permisssions to base their images on top of it. > - Probe the base image size, use/validate it when craeting disk images. > - Fix style a bit (long lines, changing from sizeof foo to sizeof(foo). > - Move a define out of vmmvar.h > - And update the manpage with these changes. > - Improve error checking around creating/resolving base disk paths. > morning. you should start new sentences on new lines - it forces a double spacing between sentences that all man pages have. if you run your proposed changes to man pages through "mandoc -Tlint", it will pick up on silly things like that. note there is also a double space in "Op Fl b" jmc > > diff --git usr.sbin/vmctl/vmctl.8 usr.sbin/vmctl/vmctl.8 > index f7890ac99f8..7a02452789c 100644 > --- usr.sbin/vmctl/vmctl.8 > +++ usr.sbin/vmctl/vmctl.8 > @@ -50,7 +50,7 @@ Using > .Xr cu 1 > connect to the console of the VM with the specified > .Ar id . > -.It Cm create Ar path Fl s Ar size > +.It Cm create Ar path Fl s Op Ar size Op Fl b Ar base > Creates a VM disk image file with the specified > .Ar path > and > @@ -65,7 +65,14 @@ or > in order to specify the disk format. > If left unspecified, the format defaults to > .Pa raw > -if it cannot be derived automatically. > +if it cannot be derived automatically. For qcow2, a > +.Ar base > +image may be specified. The base image is not modified. The derived image > +contains only the changes written by the VM. When creating a derived image, > +the > +.Ar size > +may be omitted, and probed from the base image. If it is provided, it must > +match the base image size. > .It Cm load Ar filename > Load additional configuration from the specified file. > .It Cm log brief
Re: Update bgpd.conf man to reflect ROA changes
On Tue, Oct 02, 2018 at 09:13:47PM +0100, Jason McIntyre wrote:
> On Tue, Oct 02, 2018 at 08:26:02PM +0200, Denis Fondras wrote:
> > Reorder text and be more precise.
> >
> > Index: bgpd.conf.5
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> > retrieving revision 1.178
> > diff -u -p -r1.178 bgpd.conf.5
> > --- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
> > +++ bgpd.conf.5 2 Oct 2018 18:25:17 -
> > @@ -445,6 +445,21 @@ The default is
> > .Ic ignore .
> > .Pp
> > .It Xo
> > +.Ic roa-set
> > +.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn
> > ... Ic }
> > +.Xc
> > +A
> > +.Ic roa-set
> > +holds a collection of Validated ROA Payload (VRP).
>
> hi.
>
> i'm unsure about the terminology exactly. but can you have a "collection
> of payload"? doesn;t it have to be "payload data" or something?
>
> i think at least it needs to be plural (payloads). like, you wouldn;t
> have a collection of bent umbrella. er, that's as an example..
>
> or you could remove "collection of".
>
Reading RFC6811 (page 4&5), I understand that Validated ROA Payload is one
prefix in the list. Am I wrong ?
Ok to make it plural though.
> jmc
>
> > +Each received prefix is checked against the
> > +.Ic roa-set
> > +and the Origin Validation Status (OVS) is set.
> > +.Bd -literal -offset indent
> > +roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
> > + 203.0.113.0/24 source-as 64496 }
> > +.Ed
> > +.Pp
> > +.It Xo
> > .Ic route-collector
> > .Pq Ic yes Ns | Ns Ic no
> > .Xc
> > @@ -1386,6 +1401,14 @@ can be set to
> > in which case the nexthop is compared against the address of the neighbor.
> > Nexthop filtering is not supported on locally announced networks and one
> > must
> > take into consideration previous rules overwriting nexthops.
> > +.Pp
> > +.It Xo
> > +.Ic ovs
> > +.Pq Ic valid | not-found | invalid
> > +.Xc
> > +This rule applies only to
> > +.Em UPDATES
> > +where the Origin Validation Status (OVS) matches.
> > .Pp
> > .It Ic prefix Ar address Ns Li / Ns Ar len
> > .It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
> >
>
Re: Qcow2: External snapshots
On Mon, 1 Oct 2018 11:24:01 -0700, Ori Bernstein wrote:
> On Mon, 1 Oct 2018 12:55:12 +0200
> Reyk Floeter wrote:
>
> > Hi Ori,
> >
> > On Sun, Sep 30, 2018 at 12:27:00PM -0700, Ori Bernstein wrote:
> > > I've added support to vmd for external snapshots. That is,
> > > snapshots that are derived from a base image. Data lookups
> > > start in the derived image, and if the derived image does not
> > > contain some data, the search proceeds ot the base image.
> > > Multiple derived images may exist off of a single base image.
> > >
> >
> > Nice work! This will be quite useful, thanks.
> >
> > I think I broke your diff as my last commit to derive the raw/qcow2
> > format introduced some conflicts. I had posted it on hackers@ and
> > forgot that your aren't on the internal list yet - sorry for that.
Updated version. Changes from the last diff:
- Merge in syntax changes.
- Don't over-read when getting the base images.
- Fix relative paths in base images.
- Allow multiple derived images to use a single base image, and allow a user
with only read permisssions to base their images on top of it.
- Probe the base image size, use/validate it when craeting disk images.
- Fix style a bit (long lines, changing from sizeof foo to sizeof(foo).
- Move a define out of vmmvar.h
- And update the manpage with these changes.
- Improve error checking around creating/resolving base disk paths.
diff --git regress/usr.sbin/vmd/diskfmt/Makefile
regress/usr.sbin/vmd/diskfmt/Makefile
index c2a5f42d5f6..1f8673e0e26 100644
--- regress/usr.sbin/vmd/diskfmt/Makefile
+++ regress/usr.sbin/vmd/diskfmt/Makefile
@@ -11,7 +11,7 @@
VMD_DIR=$(BSDSRCDIR)/usr.sbin/vmd/
PROG=vioscribble
-SRCS=vioscribble.c $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c
+SRCS=vioscribble.c vioqcow2.c vioraw.c
CFLAGS+=-I$(VMD_DIR) -pthread
LDFLAGS+=-pthread
@@ -26,3 +26,6 @@ scribble-images:
.PHONY: ${REGRESS_TARGETS} scribble-images
.include
+
+vioqcow2.c vioraw.c: $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c
+ cp $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c .
diff --git regress/usr.sbin/vmd/diskfmt/vioscribble.c
regress/usr.sbin/vmd/diskfmt/vioscribble.c
index 14d720db652..1da8efedac7 100644
--- regress/usr.sbin/vmd/diskfmt/vioscribble.c
+++ regress/usr.sbin/vmd/diskfmt/vioscribble.c
@@ -122,16 +122,18 @@ main(int argc, char **argv)
verbose = !!getenv("VERBOSE");
qcfd = open("scribble.qc2", O_RDWR);
rawfd = open("scribble.raw", O_RDWR);
- if (qcfd == -1 || virtio_init_qcow2(, , qcfd) == -1)
+ if (qcfd == -1)
err(1, "unable to open qcow");
- if (rawfd == -1 || virtio_init_raw(, , rawfd) == -1)
+ if (virtio_init_qcow2(, , , 1) == -1)
+ err(1, "unable to init qcow");
+ if (rawfd == -1 || virtio_init_raw(, , , 1) == -1)
err(1, "unable to open raw");
srandom_deterministic(123);
/* scribble to both disks */
printf("scribbling...\n");
- for (i = 0; i < 16; i++) {
+ for (i = 0; i < 1024*16; i++) {
off = (random() % DISKSZ);
len = random() % sizeof buf + 1;
fill(off, buf, sizeof buf);
diff --git usr.sbin/vmctl/main.c usr.sbin/vmctl/main.c
index 8748ecfdedc..4637256452b 100644
--- usr.sbin/vmctl/main.c
+++ usr.sbin/vmctl/main.c
@@ -67,7 +67,8 @@ intctl_receive(struct parse_result *, int, char
*[]);
struct ctl_command ctl_commands[] = {
{ "console",CMD_CONSOLE,ctl_console,"id" },
- { "create", CMD_CREATE, ctl_create, "\"path\" -s size", 1 },
+ { "create", CMD_CREATE, ctl_create,
+ "\"path\" [-s size] [-b base]", 1 },
{ "load", CMD_LOAD, ctl_load, "\"path\"" },
{ "log",CMD_LOG,ctl_log,"[verbose|brief]" },
{ "reload", CMD_RELOAD, ctl_reload, "" },
@@ -538,47 +539,54 @@ int
ctl_create(struct parse_result *res, int argc, char *argv[])
{
int ch, ret, type;
- const char *paths[2], *disk, *format;
+ const char *disk, *format, *base;
if (argc < 2)
ctl_usage(res->ctl);
+ base = NULL;
type = parse_disktype(argv[1], );
- paths[0] = disk;
- paths[1] = NULL;
-
- if (unveil(paths[0], "rwc") == -1)
+ if (unveil(disk, "rwc") == -1)
err(1, "unveil");
- if (pledge("stdio rpath wpath cpath", NULL) == -1)
- err(1, "pledge");
argc--;
argv++;
- while ((ch = getopt(argc, argv, "s:")) != -1) {
+ while ((ch = getopt(argc, argv, "s:b:")) != -1) {
switch (ch) {
case 's':
if (parse_size(res, optarg, 0) != 0)
errx(1, "invalid size: %s", optarg);
break;
+ case 'b':
+ base = optarg;
+ if
