Re: [PATCH] Pluggable disk formats for vmd (qcow2 preparation)
Updated version below. This change fixes a few things:
- Removes a 30 second sleep that I'd forgotten to remove
while debugging.
- Removes a dead seek() call.
---
usr.sbin/vmd/Makefile | 2 +-
usr.sbin/vmd/vioraw.c | 68 ++
usr.sbin/vmd/vioscsi.c | 7 +++--
usr.sbin/vmd/virtio.c | 55 +++---
usr.sbin/vmd/virtio.h | 23 --
5 files changed, 125 insertions(+), 30 deletions(-)
create mode 100644 usr.sbin/vmd/vioraw.c
diff --git usr.sbin/vmd/Makefile usr.sbin/vmd/Makefile
index 7ea090f8886..24c1d1b1d4a 100644
--- usr.sbin/vmd/Makefile
+++ usr.sbin/vmd/Makefile
@@ -6,7 +6,7 @@ PROG= vmd
SRCS= vmd.c control.c log.c priv.c proc.c config.c vmm.c
SRCS+= vm.c loadfile_elf.c pci.c virtio.c i8259.c mc146818.c
SRCS+= ns8250.c i8253.c vmboot.c ufs.c disklabel.c dhcp.c packet.c
-SRCS+= parse.y atomicio.c vioscsi.c
+SRCS+= parse.y atomicio.c vioscsi.c vioraw.c
CFLAGS+= -Wall -I${.CURDIR}
CFLAGS+= -Wstrict-prototypes -Wmissing-prototypes
diff --git usr.sbin/vmd/vioraw.c usr.sbin/vmd/vioraw.c
new file mode 100644
index 000..409974003f8
--- /dev/null
+++ usr.sbin/vmd/vioraw.c
@@ -0,0 +1,68 @@
+/* $OpenBSD: $ */
+/*
+ * Copyright (c) 2018 Ori Bernstein
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include "vmd.h"
+#include "vmm.h"
+#include "virtio.h"
+
+static ssize_t
+raw_pread(void *file, char *buf, size_t len, off_t off)
+{
+ return pread(*(int *)file, buf, len, off);
+}
+
+static ssize_t
+raw_pwrite(void *file, char *buf, size_t len, off_t off)
+{
+ return pwrite(*(int *)file, buf, len, off);
+}
+
+static void
+raw_close(void *file)
+{
+ close(*(int *)file);
+ free(file);
+}
+
+int
+virtio_init_raw(struct virtio_backing *file, off_t *szp, int fd)
+{
+ off_t sz;
+ int *fdp;
+
+ sz = lseek(fd, 0, SEEK_END);
+ if (sz == -1)
+ return -1;
+
+ fdp = malloc(sizeof(int*));
+ *fdp = fd;
+ file->p = fdp;
+ file->pread = raw_pread;
+ file->pwrite = raw_pwrite;
+ file->close = raw_close;
+ *szp = sz / 512;
+ return 0;
+}
+
diff --git usr.sbin/vmd/vioscsi.c usr.sbin/vmd/vioscsi.c
index 93867887598..af504f0550d 100644
--- usr.sbin/vmd/vioscsi.c
+++ usr.sbin/vmd/vioscsi.c
@@ -197,7 +197,7 @@ vioscsi_start_read(struct vioscsi_dev *dev, off_t block,
ssize_t n_blocks)
goto nomem;
info->len = n_blocks * VIOSCSI_BLOCK_SIZE_CDROM;
info->offset = block * VIOSCSI_BLOCK_SIZE_CDROM;
- info->fd = dev->fd;
+ info->file = >file;
return info;
@@ -210,7 +210,10 @@ nomem:
static const uint8_t *
vioscsi_finish_read(struct ioinfo *info)
{
- if (pread(info->fd, info->buf, info->len, info->offset) != info->len) {
+ struct virtio_backing *f;
+
+ f = info->file;
+ if (f->pread(f->p, info->buf, info->len, info->offset) != info->len) {
info->error = errno;
log_warn("vioscsi read error");
return NULL;
diff --git usr.sbin/vmd/virtio.c usr.sbin/vmd/virtio.c
index 4622ef4943f..4aa3d081041 100644
--- usr.sbin/vmd/virtio.c
+++ usr.sbin/vmd/virtio.c
@@ -361,7 +361,7 @@ vioblk_start_read(struct vioblk_dev *dev, off_t sector,
ssize_t sz)
goto nomem;
info->len = sz;
info->offset = sector * VIRTIO_BLK_SECTOR_SIZE;
- info->fd = dev->fd;
+ info->file = >file;
return info;
@@ -375,7 +375,10 @@ nomem:
static const uint8_t *
vioblk_finish_read(struct ioinfo *info)
{
- if (pread(info->fd, info->buf, info->len, info->offset) != info->len) {
+ struct virtio_backing *file;
+
+ file = info->file;
+ if (file->pread(file->p, info->buf, info->len, info->offset) !=
info->len) {
info->error = errno;
log_warn("vioblk read error");
return NULL;
@@ -398,7 +401,7 @@ vioblk_start_write(struct vioblk_dev *dev, off_t sector,
goto nomem;
info->len = len;
info->offset = sector * VIRTIO_BLK_SECTOR_SIZE;
- info->fd = dev->fd;
+
Re: nologin(8): write -> dprintf
On August 15, 2018 4:27:24 PM GMT+02:00, Scott Cheloha
wrote:
>Use dprintf for the DEFAULT_MESG string instead of the more awkward
>write+strlen combo.
>
>ok?
>
>--
>Scott Cheloha
>
>Index: sbin/nologin/nologin.c
>===
>RCS file: /cvs/src/sbin/nologin/nologin.c,v
>retrieving revision 1.7
>diff -u -p -r1.7 nologin.c
>--- sbin/nologin/nologin.c 14 Aug 2018 18:13:11 - 1.7
>+++ sbin/nologin/nologin.c 15 Aug 2018 14:07:28 -
>@@ -30,7 +30,6 @@
> #include
> #include
> #include
>-#include
> #include
>
> /* Distinctly different from _PATH_NOLOGIN. */
>@@ -52,8 +51,8 @@ main(int argc, char *argv[])
> err(1, "pledge");
>
> nfd = open(_PATH_NOLOGIN_TXT, O_RDONLY);
>- if (nfd < 0) {
>- write(STDOUT_FILENO, DEFAULT_MESG, strlen(DEFAULT_MESG));
>+ if (nfd == -1) {
>+ dprintf(STDOUT_FILENO, DEFAULT_MESG);
"%s" at the very least.
/Alexander
> exit (1);
> }
>
ubcmtp: fix multi-finger on type4 devices, pass in proper pressure
Type 4 devices like the MacBookPro12,1 have extra padding in between
each chunk of finger data that needs to be skipped, otherwise the
offset will be wrong and each additional finger will read as static
coordinates. This must have been overlooked when it was added to
the driver in 2015 since the first finger of data always read
properly.
Also, we can now pass in the actual pressure data instead of having
to use a constant value just to make the synaptics driver happy
since we now have wstpad. The per-type min/max pressure values can
also be passed in when calling wsmouse_configure.
Tested on the 2015 MacBook Pro. Tests on other Apple devices would
be appreciated.
Index: sys/dev/usb/ubcmtp.c
===
RCS file: /cvs/src/sys/dev/usb/ubcmtp.c,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 ubcmtp.c
--- sys/dev/usb/ubcmtp.c30 Jul 2018 15:56:30 - 1.18
+++ sys/dev/usb/ubcmtp.c16 Aug 2018 02:42:11 -
@@ -118,6 +118,7 @@ struct ubcmtp_finger {
#define UBCMTP_TYPE4_TPLEN UBCMTP_TYPE4_TPOFF + UBCMTP_ALL_FINGER_SIZE
#define UBCMTP_TYPE4_TPIFACE 2
#define UBCMTP_TYPE4_BTOFF 31
+#define UBCMTP_TYPE4_FINGERPAD (1 * sizeof(uint16_t))
#define UBCMTP_FINGER_ORIENT 16384
#define UBCMTP_SN_PRESSURE 45
@@ -128,9 +129,6 @@ struct ubcmtp_finger {
/* Identify clickpads in ubcmtp_configure. */
#define IS_CLICKPAD(ubcmtp_type) (ubcmtp_type != UBCMTP_TYPE1)
-/* Use a constant, synaptics-compatible pressure value for now. */
-#define DEFAULT_PRESSURE 40
-
struct ubcmtp_limit {
int limit;
int min;
@@ -337,6 +335,7 @@ struct ubcmtp_softc {
int sc_tp_epaddr; /* endpoint addr */
int tp_maxlen; /* max size of tp data */
int tp_offset; /* finger offset into data */
+ int tp_fingerpad; /* padding between finger data
*/
uint8_t *tp_pkt;
int bt_ifacenum;/* button interface number */
@@ -425,6 +424,7 @@ ubcmtp_attach(struct device *parent, str
sc->sc_udev = uaa->device;
sc->sc_status = 0;
+ sc->tp_fingerpad = 0;
if ((udd = usbd_get_device_descriptor(dev)) == NULL) {
printf("ubcmtp: failed getting device descriptor\n");
@@ -478,6 +478,7 @@ ubcmtp_attach(struct device *parent, str
sc->tp_maxlen = UBCMTP_TYPE4_TPLEN;
sc->tp_offset = UBCMTP_TYPE4_TPOFF;
sc->tp_ifacenum = UBCMTP_TYPE4_TPIFACE;
+ sc->tp_fingerpad = UBCMTP_TYPE4_FINGERPAD;
break;
}
@@ -520,6 +521,10 @@ int
ubcmtp_configure(struct ubcmtp_softc *sc)
{
struct wsmousehw *hw = wsmouse_get_hw(sc->sc_wsmousedev);
+ struct wsmouse_param params[] = {
+ { WSMOUSECFG_PRESSURE_LO, sc->dev_type->l_pressure.min },
+ { WSMOUSECFG_PRESSURE_HI, sc->dev_type->l_pressure.max },
+ };
hw->type = WSMOUSE_TYPE_TOUCHPAD;
hw->hw_type = (IS_CLICKPAD(sc->dev_type->type)
@@ -531,7 +536,7 @@ ubcmtp_configure(struct ubcmtp_softc *sc
hw->mt_slots = UBCMTP_MAX_FINGERS;
hw->flags = WSMOUSEHW_MT_TRACKING;
- return wsmouse_configure(sc->sc_wsmousedev, NULL, 0);
+ return wsmouse_configure(sc->sc_wsmousedev, params, 0);
}
int
@@ -793,9 +798,9 @@ void
ubcmtp_tp_intr(struct usbd_xfer *xfer, void *priv, usbd_status status)
{
struct ubcmtp_softc *sc = priv;
- struct ubcmtp_finger *pkt;
+ struct ubcmtp_finger *finger;
u_int32_t pktlen;
- int i, s, btn, contacts, fingers;
+ int off, s, btn, contacts = 0;
if (usbd_is_dying(sc->sc_udev) || !(sc->sc_status & UBCMTP_ENABLED))
return;
@@ -816,16 +821,19 @@ ubcmtp_tp_intr(struct usbd_xfer *xfer, v
if (sc->tp_pkt == NULL || pktlen < sc->tp_offset)
return;
- pkt = (struct ubcmtp_finger *)(sc->tp_pkt + sc->tp_offset);
- fingers = (pktlen - sc->tp_offset) / sizeof(struct ubcmtp_finger);
-
contacts = 0;
- for (i = 0; i < fingers; i++) {
- if ((int16_t)letoh16(pkt[i].touch_major) == 0)
+ for (off = sc->tp_offset; off < pktlen;
+ off += (sizeof(struct ubcmtp_finger) + sc->tp_fingerpad)) {
+ finger = (struct ubcmtp_finger *)(sc->tp_pkt + off);
+
+ if ((int16_t)letoh16(finger->touch_major) == 0)
continue; /* finger lifted */
- sc->frame[contacts].x = (int16_t)letoh16(pkt[i].abs_x);
- sc->frame[contacts].y = (int16_t)letoh16(pkt[i].abs_y);
- sc->frame[contacts].pressure = DEFAULT_PRESSURE;
+
+ sc->frame[contacts].x = (int16_t)letoh16(finger->abs_x);
+ sc->frame[contacts].y = (int16_t)letoh16(finger->abs_y);
+ sc->frame[contacts].pressure =
+
arm64 intruction cache flushing and gdb
ARMv8 (like ARMv7) does not guarantee coherence between the
instruction and data caches. After writing data to memory that
contains executable instructions, cache maintenance (flush,
invalidate) is needed. The arm64 pmap implements this, but only for
the case where the address space that needs flushing is currently
active on this CPU. However, that is not the case when a debugger
(e.g. GDB) writes a breakpoint into instruction memory using
ptrace(2). Diff below adds support for that case.
With this diff breakpoints in GDB seem to work reliably.
ok?
Index: arch/arm64/arm64/pmap.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/pmap.c,v
retrieving revision 1.55
diff -u -p -r1.55 pmap.c
--- arch/arm64/arm64/pmap.c 15 Aug 2018 20:18:31 - 1.55
+++ arch/arm64/arm64/pmap.c 15 Aug 2018 21:59:34 -
@@ -1537,9 +1537,44 @@ pmap_init(void)
void
pmap_proc_iflush(struct process *pr, vaddr_t va, vsize_t len)
{
- /* We only need to do anything if it is the current process. */
- if (pr == curproc->p_p)
+ struct pmap *pm = vm_map_pmap(>ps_vmspace->vm_map);
+ vaddr_t kva = zero_page + cpu_number() * PAGE_SIZE;
+ paddr_t pa;
+ vsize_t clen;
+ vsize_t off;
+
+ /*
+* If we're caled for the current processes, we can simply
+* flush the data cache to the point of point of unification
+* and invalidate the instruction cache.
+*/
+ if (pr == curproc->p_p) {
cpu_icache_sync_range(va, len);
+ return;
+ }
+
+ /*
+* Flush and invalidate through an aliased mapping. This
+* assumes the instruction cache is either VIPT or PIPT,
+* i.e. if the CPU implements the IVIPT extension. This is
+* true for all hardware we run on.
+*/
+ while (len > 0) {
+ /* add one to always round up to the next page */
+ clen = round_page(va + 1) - va;
+ if (clen > len)
+ clen = len;
+
+ off = va - trunc_page(va);
+ if (pmap_extract(pm, trunc_page(va), )) {
+ pmap_kenter_pa(kva, pa, PROT_READ|PROT_WRITE);
+ cpu_icache_sync_range(kva + off, clen);
+ pmap_kremove_pg(kva);
+ }
+
+ len -= clen;
+ va += clen;
+ }
}
void
Re: nologin(8): write -> dprintf
Todd C. Miller wrote: > > Use dprintf for the DEFAULT_MESG string instead of the more awkward > > write+strlen combo. > > I don't object to this but I also wouldn't object to rewriting > nologin.c to use stdio. I wonder if nologin was written in this ignore-errors-from-write style, such that if a tty stops behaving right nologin can reach termination reliably rather than getting stuck
Re: nologin(8): write -> dprintf
On Wed, 15 Aug 2018 09:27:24 -0500, Scott Cheloha wrote: > Use dprintf for the DEFAULT_MESG string instead of the more awkward > write+strlen combo. I don't object to this but I also wouldn't object to rewriting nologin.c to use stdio. - todd
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
> Date: Wed, 15 Aug 2018 09:56:50 +0100 > From: Stuart Henderson > > On 2018/08/14 18:43, Bryan Vyhmeister wrote: > > On Tue, Aug 14, 2018 at 05:53:43PM +0300, Denis wrote: > > > Most of modern modems have serial discipline ports and USB Mobile > > > Broadband Interface Model (MBIM) interface in some port compositions > > > simultaneously. It seems very useful to have different disciplines > > > supported by umsm(4) and umb(4) drivers on the same device. > > > > > > > > > > > Does it possible to have simultaneously operated AT + NMEA ports by > > > umsm(4)driver and MBIM interface by umb(4) driver on the same MC7304 > > > device in 6.3? > > > > What is the advantage in having a device attach to both umsm(4) and > > umb(4)? What are you trying to accomplish? The EM7455 worked perfectly > > with umb(4) until your previous umsm(4) diff and now it only attaches as > > umsm(4). Are you wanting to send SMS messages or something like that > > with your devices? > > > > Bryan > > > > Denis has a good point because umsm is needed for GPS and as you > suggest SMS. > > What determines which driver attaches when a device is supported by > multiple drivers? Perhaps the simplest option without more complex work > to support different interfaces on different drivers would be to have > the device attach to umb by default but attach to umsm instead if umb is > disabled in the kernel. Then at least a standard kernel could be used > with "disable umb" from boot config. The return value from the "match" function determines which driver attaches. The driver that returns the highest value wins. However, matching for USB devices is complicated. Drivers already use different return values (the UMATCH_* constants). On top of that drivers can claim a whole device or claim just a particular interface of a device. This requires some careful though to make sure the right driver attaches. What we really need is a full dump of the usb device descriptors, preferably in all the different UDUSBCOMP modes.
nologin(8): write -> dprintf
Use dprintf for the DEFAULT_MESG string instead of the more awkward
write+strlen combo.
ok?
--
Scott Cheloha
Index: sbin/nologin/nologin.c
===
RCS file: /cvs/src/sbin/nologin/nologin.c,v
retrieving revision 1.7
diff -u -p -r1.7 nologin.c
--- sbin/nologin/nologin.c 14 Aug 2018 18:13:11 - 1.7
+++ sbin/nologin/nologin.c 15 Aug 2018 14:07:28 -
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
#include
/* Distinctly different from _PATH_NOLOGIN. */
@@ -52,8 +51,8 @@ main(int argc, char *argv[])
err(1, "pledge");
nfd = open(_PATH_NOLOGIN_TXT, O_RDONLY);
- if (nfd < 0) {
- write(STDOUT_FILENO, DEFAULT_MESG, strlen(DEFAULT_MESG));
+ if (nfd == -1) {
+ dprintf(STDOUT_FILENO, DEFAULT_MESG);
exit (1);
}
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
umsm(4) patch is needed to recognize MC7304 by umsm(4) and to have both NMEA and AT ports enabled. Especially, I'm using MC7304's (MC7455 on another platform) NMEA port for NTP time corrections from GLO/GPS. AT port is needed for mode changes by AT commands. Very useful. umb(4) is a good one for modern fast data transmit over MBIM port. So the advantages of simultaneous running umsm(4) and umb(4) drivers for single physical device are: - having NMEA + AT serial discipline working by umsm(4); (any rather 'old' serial discipline functionality can be used like SMS, modem's mode changes by AT commands etc.) - MBIM for fast LTE Cat-3 / Cat-6 data connections by modern umb(4) driver. Denis On 8/15/2018 4:43 AM, Bryan Vyhmeister wrote: > On Tue, Aug 14, 2018 at 05:53:43PM +0300, Denis wrote: >> Most of modern modems have serial discipline ports and USB Mobile >> Broadband Interface Model (MBIM) interface in some port compositions >> simultaneously. It seems very useful to have different disciplines >> supported by umsm(4) and umb(4) drivers on the same device. >> > >> >> Does it possible to have simultaneously operated AT + NMEA ports by >> umsm(4)driver and MBIM interface by umb(4) driver on the same MC7304 >> device in 6.3? > > What is the advantage in having a device attach to both umsm(4) and > umb(4)? What are you trying to accomplish? The EM7455 worked perfectly > with umb(4) until your previous umsm(4) diff and now it only attaches as > umsm(4). Are you wanting to send SMS messages or something like that > with your devices? > > Bryan >
Re: CVE-2018-3615, CVE-2018-3620, CVE-2018-3646
On Wed, Aug 15, 2018 at 12:31:16AM -0600, Theo de Raadt wrote: > We had some idea this class of problem was coming, through hints we > received from others and an extremely cynical perspective that has > developed. We believe Intel cpus do almost no security checks up-front, > but defer checks until instruction retire. As a result we believe > similar issues will be coming in the future. > > We asked repeatedly, but Intel provided no advance notice. We did not > even receive replies to our requests for dialogue. HardenedBSD received no advanced notice, either. What's funny is that LWN, a Linux news outlet, might have: https://twitter.com/grsecurity/status/1029476228288454657 https://twitter.com/grsecurity/status/1029476820553539584 https://twitter.com/grsecurity/status/1029482062724648965 If true, a Linux news outlet, which carries no actual security responsibilities, received advanced notification, while certain operating systems vendors did not. But, again, this is just *speculation* at this point. ;) Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
vmd send nameserver only once
When running vmd with a local interface it sends the nameservers twice, which seems a bit redundant to me and always annoys me when editing resolv.conf manually inside the vm. Diff below removes one of the two instances. OK? martijn@ Index: dhcp.c === RCS file: /cvs/src/usr.sbin/vmd/dhcp.c,v retrieving revision 1.4 diff -u -p -r1.4 dhcp.c --- dhcp.c 5 Nov 2017 20:01:09 - 1.4 +++ dhcp.c 15 Aug 2018 13:41:24 - @@ -189,11 +189,6 @@ dhcp_request(struct vionet_dev *dev, cha o += sizeof(server_addr); } - resp.options[o++] = DHO_DOMAIN_NAME_SERVERS; - resp.options[o++] = sizeof(server_addr); - memcpy([o], _addr, sizeof(server_addr)); - o += sizeof(server_addr); - resp.options[o++] = DHO_SUBNET_MASK; resp.options[o++] = sizeof(mask); mask.s_addr = htonl(0xfffe);
Re: nsd 4.1.24
On Wed, Aug 15, 2018 at 03:12:19PM +0200, Florian Obser wrote: | When this goes in I think we should switch the default control socket | and stop listening on localhost. This makes a lot of sense to me, please make the UDS the default control socket. Thanks Florian! Paul | OK? | | diff --git etc/nsd.conf etc/nsd.conf | index 729a5f620ba..94710bfa5ae 100644 | --- etc/nsd.conf | +++ etc/nsd.conf | @@ -19,6 +19,7 @@ server: | | remote-control: | control-enable: yes | + control-interface: /var/run/nsd.sock | | ## tsig key example | #key: | | | -- | I'm not entirely sure you are real. | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: inteldrm(4) regression from 6.1 to 6.2: wrong console resolution
> Date: Wed, 15 Aug 2018 01:50:58 -0400
> From: Philippe Meunier
>
> Philippe Meunier wrote:
> >Mark Kettenis wrote:
> >>Does the diff below fix things?
> >
> >Yes, it fixes the console resolution problem, although a bunch of "vblank
> >wait timed out on crtc 0" messages now show up (see dmesg's output below).
>
> How about the patch below? It does essentially the same thing as yours but
> directly inside drm_wait_one_vblank where "cold" was already tested, and
> without testing "condition" in __wait_event_intr_timeout wich was never
> tested anyway when "cold" is 1.
No. We want to keep the modifications to the original Linux code as
small as possible. Otherwise jsg@ and I go insane the next time we
update this code to include support for new hardware. So I really
want to fix this in the compatibility layer in drm_linux.c.
Maybe you can add some printf's to figure out why the timeout is
happening? Is it actually doing a delay? Is the delay too long? Or
too short?
Thanks,
Mark
> Index: sys/dev/pci/drm/drm_irq.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_irq.c,v
> retrieving revision 1.70
> diff -u -p -u -p -r1.70 drm_irq.c
> --- sys/dev/pci/drm/drm_irq.c 28 Mar 2018 05:27:28 - 1.70
> +++ sys/dev/pci/drm/drm_irq.c 15 Aug 2018 05:45:18 -
> @@ -1316,10 +1316,17 @@ void drm_wait_one_vblank(struct drm_devi
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> int ret;
> u32 last;
> + int timo = msecs_to_jiffies(100);
>
> - if (WARN_ON(pipe >= dev->num_crtcs) || cold)
> + if (WARN_ON(pipe >= dev->num_crtcs))
> return;
>
> + if (cold) {
> + for (ret = timo; ret > 0; ret--)
> + delay(tick);
> + return;
> + }
> +
> ret = drm_vblank_get(dev, pipe);
> if (WARN(ret, "vblank not available on crtc %i, ret=%i\n", pipe, ret))
> return;
> @@ -1328,7 +1335,7 @@ void drm_wait_one_vblank(struct drm_devi
>
> ret = wait_event_timeout(vblank->queue,
>last != drm_vblank_count(dev, pipe),
> - msecs_to_jiffies(100));
> + timo);
>
> WARN(ret == 0, "vblank wait timed out on crtc %i\n", pipe);
>
>
Re: nsd 4.1.24
When this goes in I think we should switch the default control socket and stop listening on localhost. OK? diff --git etc/nsd.conf etc/nsd.conf index 729a5f620ba..94710bfa5ae 100644 --- etc/nsd.conf +++ etc/nsd.conf @@ -19,6 +19,7 @@ server: remote-control: control-enable: yes + control-interface: /var/run/nsd.sock ## tsig key example #key: -- I'm not entirely sure you are real.
nsd 4.1.24
Now with systemd support!
A more useful feature for us might be that nsd-control can now
commuicate over a unix domain socket.
OK?
diff --git config.h.in config.h.in
index d3470836f26..eded09dd6b3 100644
--- config.h.in
+++ config.h.in
@@ -317,6 +317,9 @@
/* Define to 1 if you have the `strtol' function. */
#undef HAVE_STRTOL
+/* Define to 1 if `sun_len' is a member of `struct sockaddr_un'. */
+#undef HAVE_STRUCT_SOCKADDR_UN_SUN_LEN
+
/* Define to 1 if `st_mtimensec' is a member of `struct stat'. */
#undef HAVE_STRUCT_STAT_ST_MTIMENSEC
@@ -350,6 +353,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_TYPES_H
+/* Define to 1 if you have the header file. */
+#undef HAVE_SYS_UN_H
+
/* Define to 1 if you have that is POSIX.1 compatible. */
#undef HAVE_SYS_WAIT_H
diff --git configlexer.lex configlexer.lex
index 1f2628d7695..7fd4f17363f 100644
--- configlexer.lex
+++ configlexer.lex
@@ -203,6 +203,7 @@ interface{COLON}{ LEXOUT(("v(%s) ", yytext)); return
VAR_IP_ADDRESS;}
ip-transparent{COLON} { LEXOUT(("v(%s) ", yytext)); return
VAR_IP_TRANSPARENT;}
ip-freebind{COLON} { LEXOUT(("v(%s) ", yytext)); return VAR_IP_FREEBIND;}
debug-mode{COLON} { LEXOUT(("v(%s) ", yytext)); return VAR_DEBUG_MODE;}
+use-systemd{COLON} { LEXOUT(("v(%s) ", yytext)); return VAR_USE_SYSTEMD;}
hide-version{COLON}{ LEXOUT(("v(%s) ", yytext)); return VAR_HIDE_VERSION;}
ip4-only{COLON}{ LEXOUT(("v(%s) ", yytext)); return
VAR_IP4_ONLY;}
ip6-only{COLON}{ LEXOUT(("v(%s) ", yytext)); return
VAR_IP6_ONLY;}
diff --git configparser.y configparser.y
index b9bf8200f99..547518f88c6 100644
--- configparser.y
+++ configparser.y
@@ -72,6 +72,7 @@ extern config_parser_state_type* cfg_parser;
%token VAR_MAX_REFRESH_TIME VAR_MIN_REFRESH_TIME
%token VAR_MAX_RETRY_TIME VAR_MIN_RETRY_TIME
%token VAR_MULTI_MASTER_CHECK VAR_MINIMAL_RESPONSES VAR_REFUSE_ANY
+%token VAR_USE_SYSTEMD
%%
toplevelvars: /* empty */ | toplevelvars toplevelvar ;
@@ -103,7 +104,7 @@ content_server: server_ip_address | server_ip_transparent |
server_debug_mode |
server_zonefiles_check | server_do_ip4 | server_do_ip6 |
server_zonefiles_write | server_log_time_ascii | server_round_robin |
server_reuseport | server_version | server_ip_freebind |
- server_minimal_responses | server_refuse_any;
+ server_minimal_responses | server_refuse_any | server_use_systemd;
server_ip_address: VAR_IP_ADDRESS STRING
{
OUTYY(("P(server_ip_address:%s)\n", $2));
@@ -150,6 +151,14 @@ server_debug_mode: VAR_DEBUG_MODE STRING
else cfg_parser->opt->debug_mode = (strcmp($2, "yes")==0);
}
;
+server_use_systemd: VAR_USE_SYSTEMD STRING
+ {
+ OUTYY(("P(server_use_systemd:%s)\n", $2));
+ if(strcmp($2, "yes") != 0 && strcmp($2, "no") != 0)
+ yyerror("expected yes or no.");
+ else cfg_parser->opt->use_systemd = (strcmp($2, "yes")==0);
+ }
+ ;
server_verbosity: VAR_VERBOSITY STRING
{
OUTYY(("P(server_verbosity:%s)\n", $2));
@@ -550,11 +559,18 @@ rc_control_port: VAR_CONTROL_PORT STRING
;
rc_control_interface: VAR_CONTROL_INTERFACE STRING
{
+ ip_address_option_type* last = NULL;
ip_address_option_type* o =
(ip_address_option_type*)region_alloc(
cfg_parser->opt->region,
sizeof(ip_address_option_type));
OUTYY(("P(control_interface:%s)\n", $2));
- o->next = cfg_parser->opt->control_interface;
- cfg_parser->opt->control_interface = o;
+ /* append at end */
+ last = cfg_parser->opt->control_interface;
+ while(last && last->next)
+ last = last->next;
+ if(last == NULL)
+ cfg_parser->opt->control_interface = o;
+ elselast->next = o;
+ o->next = NULL;
o->address = region_strdup(cfg_parser->opt->region, $2);
}
;
diff --git configure configure
index 79f500f50fd..13da401ab9b 100644
--- configure
+++ configure
@@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for NSD 4.1.23.
+# Generated by GNU Autoconf 2.69 for NSD 4.1.24.
#
# Report bugs to .
#
@@ -580,8 +580,8 @@ MAKEFLAGS=
# Identity of this package.
PACKAGE_NAME='NSD'
PACKAGE_TARNAME='nsd'
-PACKAGE_VERSION='4.1.23'
-PACKAGE_STRING='NSD 4.1.23'
+PACKAGE_VERSION='4.1.24'
+PACKAGE_STRING='NSD 4.1.24'
PACKAGE_BUGREPORT='nsd-b...@nlnetlabs.nl'
PACKAGE_URL=''
@@ -734,6 +734,7 @@ enable_minimal_responses
enable_mmap
enable_radix_tree
enable_packed
+enable_systemd
'
ac_precious_vars='build_alias
host_alias
@@ -1286,7 +1287,7 @@ if test "$ac_init_help" = "long"; then
# Omit some internal or
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
On 2018/08/15 09:56, Stuart Henderson wrote: > On 2018/08/14 18:43, Bryan Vyhmeister wrote: > > On Tue, Aug 14, 2018 at 05:53:43PM +0300, Denis wrote: > > > Most of modern modems have serial discipline ports and USB Mobile > > > Broadband Interface Model (MBIM) interface in some port compositions > > > simultaneously. It seems very useful to have different disciplines > > > supported by umsm(4) and umb(4) drivers on the same device. > > > > > > > > > > > Does it possible to have simultaneously operated AT + NMEA ports by > > > umsm(4)driver and MBIM interface by umb(4) driver on the same MC7304 > > > device in 6.3? > > > > What is the advantage in having a device attach to both umsm(4) and > > umb(4)? What are you trying to accomplish? The EM7455 worked perfectly > > with umb(4) until your previous umsm(4) diff and now it only attaches as > > umsm(4). Are you wanting to send SMS messages or something like that > > with your devices? > > > > Bryan > > > > Denis has a good point because umsm is needed for GPS and as you > suggest SMS. > > What determines which driver attaches when a device is supported by > multiple drivers? Perhaps the simplest option without more complex work > to support different interfaces on different drivers would be to have > the device attach to umb by default but attach to umsm instead if umb is > disabled in the kernel. Then at least a standard kernel could be used > with "disable umb" from boot config. > (In case it's not clear I definitely agree with backing out the change for now, the above is me considering ways forward because it definitely seems reasonable to want to use the GPS ..)
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
On 2018/08/14 18:43, Bryan Vyhmeister wrote: > On Tue, Aug 14, 2018 at 05:53:43PM +0300, Denis wrote: > > Most of modern modems have serial discipline ports and USB Mobile > > Broadband Interface Model (MBIM) interface in some port compositions > > simultaneously. It seems very useful to have different disciplines > > supported by umsm(4) and umb(4) drivers on the same device. > > > > > > > Does it possible to have simultaneously operated AT + NMEA ports by > > umsm(4)driver and MBIM interface by umb(4) driver on the same MC7304 > > device in 6.3? > > What is the advantage in having a device attach to both umsm(4) and > umb(4)? What are you trying to accomplish? The EM7455 worked perfectly > with umb(4) until your previous umsm(4) diff and now it only attaches as > umsm(4). Are you wanting to send SMS messages or something like that > with your devices? > > Bryan > Denis has a good point because umsm is needed for GPS and as you suggest SMS. What determines which driver attaches when a device is supported by multiple drivers? Perhaps the simplest option without more complex work to support different interfaces on different drivers would be to have the device attach to umb by default but attach to umsm instead if umb is disabled in the kernel. Then at least a standard kernel could be used with "disable umb" from boot config.
CVE-2018-3615, CVE-2018-3620, CVE-2018-3646
These 3 issues all relate to a bug in Intel cpus The cpu will speculatively honour invalid PTE against data in the on-core L1 cache. Memory disclosure occurs into the wrong context. These 3 issues (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646) together are the currently public artifacts of this one bug. There may be more artifacts of this on the way, perhaps combined with other past and not yet known mistakes. CVE-2018-3620 matters for the host OS. We have reviewed our pmap module and it appears like we never invalidate a PTE by clearing the 'valid' bit alone, we always clear the PTE to 0 entirely. Page 0 of physical memory is unused. As well, we don't support Wine (which has VA 0 / PA 0 issues); we don't support 32-bit emulation in 64-bit mode which makes things trickier, and we have SMT disabled by default which reduces the risk patterns further. CVE-2018-3646 relates to the same bug, but considers the cross-domain impact upon entering VMs, which obviously run in different security domains. A patch should arrive soon to flush the L1 cache before vmenter, so that an incorrectly accessed PTE can't read data from another domain. Another aspect of the risk in this area goes away if SMT is disabled, so keep it disabled! CVE-2018-3615 (Foreshadow) is by receiving the most press which is amazing considering it is by far the most boring of the 3, since very few few people give a rats ass about SGX -- who cares if SGX is broken when the cpu can't run your OS safely? Some convincing press agencies were hired I guess, and have performed a masterful job of distracting. We had some idea this class of problem was coming, through hints we received from others and an extremely cynical perspective that has developed. We believe Intel cpus do almost no security checks up-front, but defer checks until instruction retire. As a result we believe similar issues will be coming in the future. We asked repeatedly, but Intel provided no advance notice. We did not even receive replies to our requests for dialogue. On a side note, AMD cpus are not vulnerable to this problem. Currently it is believed their address translation layer works according to spec.
