Re: vmd(8) i8042 device implementation questions
Okay, here’s the first pass of my 8042 device - I wasn’t able to figure out how
to tie the reset line to the guest VM reset, so I was hoping someone could give
me a hand with that. Other than that, it attaches to i386 and amd64 OpenBSD
guests. There’s no input yet as I mentioned, but the 8042 commands execute
according to specs.
diff --git a/sys/arch/amd64/amd64/vmm.c b/sys/arch/amd64/amd64/vmm.c
index 4ffb2ff899f..7de38facc78 100644
--- a/sys/arch/amd64/amd64/vmm.c
+++ b/sys/arch/amd64/amd64/vmm.c
@@ -5359,6 +5359,8 @@ svm_handle_inout(struct vcpu *vcpu)
case IO_ICU1 ... IO_ICU1 + 1:
case 0x40 ... 0x43:
case PCKBC_AUX:
+ case 0x60:
+ case 0x64:
case IO_RTC ... IO_RTC + 1:
case IO_ICU2 ... IO_ICU2 + 1:
case 0x3f8 ... 0x3ff:
diff --git a/usr.sbin/vmd/Makefile b/usr.sbin/vmd/Makefile
index 8645df7aecf..f39d85b1b14 100644
--- a/usr.sbin/vmd/Makefile
+++ b/usr.sbin/vmd/Makefile
@@ -4,7 +4,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+= vm.c loadfile_elf.c pci.c virtio.c i8259.c mc146818.c i8042.c
SRCS+= ns8250.c i8253.c vmboot.c ufs.c disklabel.c dhcp.c packet.c
SRCS+= parse.y atomicio.c vioscsi.c vioraw.c vioqcow2.c fw_cfg.c
diff --git a/usr.sbin/vmd/i8042.c b/usr.sbin/vmd/i8042.c
new file mode 100644
index 000..b57139368cf
--- /dev/null
+++ b/usr.sbin/vmd/i8042.c
@@ -0,0 +1,439 @@
+/* $OpenBSD: i8042.c,v 1.00 2019/05/25 18:18:00 rohl Exp $ */
+/*
+ * Copyright (c) 2019 Katherine Rohl
+ *
+ * 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
+#include
+#include
+
+#include "i8042.h"
+#include "proc.h"
+#include "vmm.h"
+#include "atomicio.h"
+#include "vmd.h"
+
+struct i8042 {
+ uint8_t data;
+ uint8_t command;
+ uint8_t status;
+ uint8_t internal_ram[16];
+
+ uint8_t input_port;
+ uint8_t output_port;
+
+ // Port 0 is keyboard, Port 1 is mouse
+ uint8_t ps2_enabled[2];
+
+ uint32_t vm_id;
+
+ // Is the 8042 awaiting a command argument byte?
+ uint8_t awaiting_argbyte;
+};
+
+struct i8042 kbc;
+pthread_mutex_t kbc_mtx;
+
+/*
+ * i8042_init
+ *
+ * Initialize the emulated i8042 KBC.
+ *
+ * Parameters:
+ * vm_id: vmm(4) assigned ID of the VM
+ */
+void
+i8042_init(uint32_t vm_id)
+{
+ memset(&kbc, 0, sizeof(kbc));
+
+ if(pthread_mutex_init(&kbc_mtx, NULL) != 0)
+ fatalx("unable to create kbc mutex");
+
+ kbc.vm_id = vm_id;
+
+ // Always initialize the reset bit to 1 for proper operation.
+ kbc.output_port = KBC_DEFOUTPORT;
+ kbc.input_port = KBC_DEFINPORT;
+}
+
+/*
+ * i8042_set_output_port
+ *
+ * Set the output port of the KBC.
+ * Many bits have side effects, so handle their on/off
+ * transition effects as required.
+ */
+static void
+i8042_set_output_port(uint8_t byte)
+{
+ /* 0x01: reset line
+* 0x02: A20 gate (not implemented)
+* 0x04: aux port clock
+* 0x08: aux port data
+* 0x10: data in output buffer is from kb port (IRQ1)
+* 0x20: data in output buffer is from aux port (IRQ12)
+* 0x40: kb port clock
+* 0x80: kb port data
+*/
+
+ uint8_t old_output_port = kbc.output_port;
+ kbc.output_port = byte;
+
+ // 0 -> 1 transition
+ if(((old_output_port & 0x10) == 0) &&
+ ((kbc.output_port & 0x10) == 1))
+ {
+ vcpu_assert_pic_irq(kbc.vm_id, 0, KBC_KBDIRQ);
+ }
+ if(((old_output_port & 0x20) == 0) &&
+ ((kbc.output_port & 0x20) == 1))
+ {
+ vcpu_assert_pic_irq(kbc.vm_id, 0, KBC_AUXIRQ);
+ }
+
+ // 1 -> 0 transition
+ if(((old_output_port & 0x10) == 1) &&
+ ((kbc.output_port & 0x10) == 0))
+ {
+ vcpu_deassert_pic_irq(kbc.vm_id, 0, KBC_KBDIRQ);
+ }
+ if(((old_output_port & 0x20) == 1) &&
+ ((kbc.output_port & 0x20) == 0))
+ {
+ vcpu_deassert_pic_irq(kbc.vm_id, 0, KBC_AUXIRQ);
+ }
+}
+
+/*
+ * i8042_perform_twobyte_co
Re: [Patch] Driver for Keyspan USA-19HS
Thank you for your comments, Joshua. I'll send an updated patch shortly.
j...@openbsd.org (joshua stein) - Tue, May 28, 2019 at 07:51:08PM -0500
> Hi,
>
> Some feedback inline:
>
> On Tue, 28 May 2019 at 18:42:51 -0400, Cody Cutler wrote:
> > Hello tech, I'm submitting the following patch for inclusion. The patch
> > implements a driver for the Keyspan USA-19HS USB-to-serial dongle.
> >
> > I've used it for a few months now without any problems. Please let me know
> > if
> > you spot any problems.
> >
> > Thanks!
> >
> > diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC
> > index ad192f4ea1d..052915d10e0 100644
> > --- sys/arch/amd64/conf/GENERIC
> > +++ sys/arch/amd64/conf/GENERIC
> > @@ -224,6 +224,8 @@ uvscom* at uhub?# SUNTAC Slipper U
> > VS-10U serial
> > ucom* at uvscom?
> > ubsa* at uhub?# Belkin serial adapter
> > ucom* at ubsa?
> > +ukspan* at uhub? # Keyspan USA19HS
>
> Nit: maybe add "serial adapter" at the end
>
> > +ucom* at ukspan?
> > uftdi* at uhub?# FTDI FT8U100AX serial adapter
> > ucom* at uftdi?
> > uplcom* at uhub? # I/O DATA USB-RSAQ2 serial adapter
> > diff --git sys/dev/usb/files.usb sys/dev/usb/files.usb
> > index 1036cf36232..29bc1205540 100644
> > --- sys/dev/usb/files.usb
> > +++ sys/dev/usb/files.usb
> > @@ -317,6 +317,11 @@ device ubsa: ucombus
> > attach ubsa at uhub
> > file dev/usb/ubsa.c ubsa
> >
> > +# Keyspan USA19HS serial
> > +device ukspan: ucombus
> > +attach ukspan at uhub
> > +file dev/usb/ukspan.cukspan
> > +
> > # Silicon Laboratories CP210x serial
> > device uslcom: ucombus
> > attach uslcom at uhub
> > diff --git sys/dev/usb/ukspan.c sys/dev/usb/ukspan.c
> > new file mode 100644
> > index 000..749144058a0
> > --- /dev/null
> > +++ sys/dev/usb/ukspan.c
> > @@ -0,0 +1,567 @@
> > +#include
>
> Please add a copyright and license at the top of the file.
> /usr/share/misc/license.template is a good one to use.
>
> Also, is there any documentation for the device that you used? A
> URL to it is always useful to include in the header.
>
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#if 0
> > + #define DBG(...) do { printf("ukspan " __VA_ARGS__); } while (0)
> > +#else
> > + #define DBG(...)
> > +#endif
>
> Can you put that behind an ifdef UKSPAN_DEBUG and leave a commented
> out example? That is usually how drivers do it.
>
> /* #define UKSPAN_DEBUG */
>
> #ifdef UKSPAN_DEBUG
> #define DPRINTF(x...) do { printf(x); } while (0);
> #else
> #define DPRINTF(x...)
> #endif
>
> > +#define UKSPAN_PARITY_NONE 0x0
> > +#define UKSPAN_PARITY_ODD 0x08
> > +#define UKSPAN_PARITY_EVEN 0x18
> > +
> > +#define UKSPAN_DATA_5 0x0
> > +#define UKSPAN_DATA_6 0x1
> > +#define UKSPAN_DATA_7 0x2
> > +#define UKSPAN_DATA_8 0x3
> > +
> > +#define UKSPAN_STOP_1 0x0
> > +#define UKSPAN_STOP_2 0x4
> > +
> > +#define UKSPAN_MAGIC 0x2
> > +
> > +#define UKSPAN_CLOCK 14769231
> > +
> > +/*
> > + * The following USB endpoint addresses may be specific to the Keyspan
> > USA19HS
> > + * device
> > + */
> > +#define UKSPAN_CONFIG_IDX 1
> > +#define UKSPAN_IFACE_IDX 0
> > +
> > +#define UKSPAN_EA_BULKIN (UE_DIR_IN | 1)
> > +#define UKSPAN_EA_BULKOUT (UE_DIR_OUT | 1)
> > +#define UKSPAN_EA_CONFIGIN (UE_DIR_IN | 2)
> > +#define UKSPAN_EA_CONFIGOUT(UE_DIR_OUT | 2)
> > +
> > +/* Sent to device on control out endpoint */
> > +struct ukspan_cmsg {
> > + uint8_t setclock;
> > + uint8_t baudlo;
> > + uint8_t baudhi;
> > + uint8_t setlcr;
> > + uint8_t lcr;
> > + uint8_t setrxmode;
> > + uint8_t rxmode;
> > + uint8_t settxmode;
> > + uint8_t txmode;
> > + uint8_t settxflowcontrol;
> > + uint8_t txflowcontrol;
> > + uint8_t setrxflowcontrol;
> > + uint8_t rxflowcontrol;
> > + uint8_t sendxoff;
> > + uint8_t sendxon;
> > + uint8_t xonchar;
> > + uint8_t xoffchar;
> > + uint8_t sendchar;
> > + uint8_t txchar;
> > + uint8_t setrts;
> > + uint8_t rts;
> > + uint8_t setdtr;
> > + uint8_t dtr;
> > +
> > + uint8_t rxforwardingchars;
> > + uint8_t rxforwardingtimeoutms;
> > + uint8_t txacksetting;
> > +
> > + uint8_t portenabled;
> > + uint8_t txflush;
> > + uint8_t txbreak;
> > + uint8_t loopbackmode;
> > +
> > + uint8_t rxflush;
> > + uint8_t rxforward;
> > + uint8_t cancelrxoff;
> > + uint8_t returnstatus;
> > +};
> > +
> > +/* Received from device on control in endpoint */
> > +struct ukspan_smsg {
> > + uint8_t msr;
> > + uint8_t cts;
> > + uint8_t dcd;
> > + uint8_t dsr;
> > + uint8_t ri;
> > + uint8_t txxoff;
> > + uint8_t rxbreak;
> > + uint8_t rxoverrun;
> > + uint8_t rxparity
Re: [Patch] Driver for Keyspan USA-19HS
> > The routine for adding USB devices is to just add them to > /usr/src/sys/dev/usb/usbdevs, then run 'make' in > /usr/src/sys/dev/usb/. That will automatically regenerate usbdevs.h > and usbdevs_data.h. I'm happy to test when the new diff is submitted. I have a USA19HS sitting in my desk. Tracey
Re: smtpd.conf(5) small wording patch
Sorry, this reads correctly as it is. Eddie Thieda wrote: > --- smtpd.conf.5.orig Wed May 29 13:25:37 2019 > +++ smtpd.conf.5 Wed May 29 13:25:54 2019 > @@ -33,7 +33,7 @@ each > .Dq RCPT TO: > command generates a mail envelope. > If an envelope matches > -any of a pre-designated set of criteria > +any pre-designated set of criteria > (using the > .Ic match > directive), >
smtpd.conf(5) small wording patch
--- smtpd.conf.5.orig Wed May 29 13:25:37 2019 +++ smtpd.conf.5 Wed May 29 13:25:54 2019 @@ -33,7 +33,7 @@ each .Dq RCPT TO: command generates a mail envelope. If an envelope matches -any of a pre-designated set of criteria +any pre-designated set of criteria (using the .Ic match directive),
Re: bgpd set nexthop 198.51.100.42 clarifications
On Tue, May 28, 2019 at 07:09:00PM +0200, Job Snijders wrote:
> On Tue, May 28, 2019 at 05:17:08PM +0200, Claudio Jeker wrote:
> > On Tue, May 28, 2019 at 01:28:32PM +0200, Job Snijders wrote:
> > > On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote:
> > > > When using a rule forcing the nexthop to a specific address bgpd
> > > > currently does not mark that nexthop as no-modify. In other words
> > > > the default rules for nexthop propagation applies. This means that
> > > > for ebgp it only sends out the set nexthop when this nexthop is
> > > > connected
> > > > and on the same network as the peer. So while the Adj-RIB-Out shows the
> > > > right nexthop it is actually not on the wire.
> > > >
> > > > This diff changes set nexthop 198.51.100.42 to also imply set nexthop
> > > > no-modify. This way the set nexthop is always on the wire.
> > > > The problem with that is that it will hand you a nice footgun ready to
> > > > blow of your big toe (but in the end the current behaviour is doing the
> > > > same just with a different angle of attack) .
> > > >
> > > > The set nexthop section in bgpd.conf.5 needs to be adjusted once a
> > > > decision is made on how to handle this.
> > >
> > > I think I'm not a big fan of this change.
> > >
> > > Section 5.1.3 of RFC 4271 (the core BGP spec) is very explicit on
> > > what NEXT_HOPs are valid to send over a non-multihop BGP session.
> > > Only addresses that are part of the linknet between the two routers
> > > are valid NEXT_HOP addresses on the wire. This changes makes it
> > > trivial to send not-valid NEXT_HOPs to a neighbor, this may result
> > > in very hard to debug troublecases. Feels like we'll be handing way
> > > too much rope to users, especially since it facilitates protocol
> > > violations.
> > >
> > > I am not aware of a real world BGP implementation that would allow
> > > you to send completely arbitrary NEXT_HOPs.
> >
> > I came to a similar conclusion and will send out a better diff. The
> > idea is that for the non-multihop BGP sessions we should require the
> > nexthop to be in the same network.
>
> With 'same network', you mean the NEXT_HOP IP address must be part of
> the router-to-router linknet, right?
>
> > The ebgp multihop case is currently always sticking to the local
> > address and should probably respect the nexthop if set explicitly
> > (that is also what the RFC suggests).
>
> Right.
>
> > ibgp seems to do the right thing.
>
> yup, in IBGP the NEXT_HOP can be anything.
>
> > The same rules need to be applied to "set nexthop no-modify" since
> > that is currently on massive hammer.
>
> Right.
>
So here is the diff for this change. In short nexthop no-modify has only
relevance for ebgp multihop links now (for the other cases it is either
the default or ignored). set nexthop self is still overriding all
decisions. ebgp just does the same net check and decides based on that
data. I refactored up_get_nexthop in a way that allows it to be used
for all AFI/SAFI cases and so 3 of the 4 almost identical code versions
did go away and the resulting up_get_nexthop() is a lot nicer now.
I decided to drop the implied NEXTHOP_NOMODIFY on set nexthop 198.51.100.42.
It makes more sense to set this on a per ebgp multihop session if that is
requested. The reason is that a NEXTHOP_NOMODIFY can not be toggled off
again and so it may cause nasty config hacks in complex setups. People
should just use 'set nexthop no-modify' on the ebgp multihop neighbor
block or in the filters.
Tested with IPv4 and IPv6. OK?
--
:wq Claudio
Index: rde_update.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_update.c,v
retrieving revision 1.111
diff -u -p -r1.111 rde_update.c
--- rde_update.c13 May 2019 21:13:04 - 1.111
+++ rde_update.c29 May 2019 13:07:31 -
@@ -238,59 +238,84 @@ up_generate_default(struct filter_head *
}
/* only for IPv4 */
-static in_addr_t
-up_get_nexthop(struct rde_peer *peer, struct filterstate *state)
+static struct bgpd_addr *
+up_get_nexthop(struct rde_peer *peer, struct filterstate *state, u_int8_t aid)
{
- in_addr_t mask;
+ struct bgpd_addr *peer_local;
- /* nexthop, already network byte order */
- if (state->nhflags & NEXTHOP_NOMODIFY) {
- /* no modify flag set */
- if (state->nexthop == NULL)
- return (peer->local_v4_addr.v4.s_addr);
- else
- return (state->nexthop->exit_nexthop.v4.s_addr);
- } else if (state->nhflags & NEXTHOP_SELF)
- return (peer->local_v4_addr.v4.s_addr);
- else if (!peer->conf.ebgp) {
+ switch (aid) {
+ case AID_INET:
+ case AID_VPN_IPv4:
+ peer_local = &peer->local_v4_addr;
+ break;
+ case AID_INET6:
+ case AID_VPN_IPv6:
+ peer_local = &peer->local_v6_addr;
+ break;
+
Re: Mount point just for W|X packages?
Stuart Henderson wrote: > On 2019/05/28 17:48, ops...@firemail.cc wrote: > > So, following the new advancements in W^X from Theo, I was thinking about > > this idea: ports maintainers cannot make every single package be W^X, this > > is obvious. > > But they could test each package without wxallowed and, if it is not > > working, make > > the package go to other specified filesystem with wxallowed. > > For example: all packages I need can work without wxallowed on > > /usr/local/bin, > > except for some shitty python scripts that I unfortunately need. > > So, in order to make it work, I need to put wxallowed in all this mount > > point. > > Wouldn't it be better to just create, lets say, /usr/local/wxallowedbin/ > > on the installation procedure? Of course this would require some effors from > > ports > > maintainers, but should be doable. > > > > > > > > Regards. > > > > A binary doesn't *just* need to be on a wxallowed filesystem, it must also > be marked with the wxneeded flag. So even if you mount /usr/local with > wxallowed the vast majority of programs installed there are still denied > W|X maps, there's no need for a separate filesystem to do that. And since only root can place binaries in that filesystem, the situation is safe.
Re: Mount point just for W|X packages?
On 2019/05/28 17:48, ops...@firemail.cc wrote: > So, following the new advancements in W^X from Theo, I was thinking about > this idea: ports maintainers cannot make every single package be W^X, this > is obvious. > But they could test each package without wxallowed and, if it is not > working, make > the package go to other specified filesystem with wxallowed. > For example: all packages I need can work without wxallowed on > /usr/local/bin, > except for some shitty python scripts that I unfortunately need. > So, in order to make it work, I need to put wxallowed in all this mount > point. > Wouldn't it be better to just create, lets say, /usr/local/wxallowedbin/ > on the installation procedure? Of course this would require some effors from > ports > maintainers, but should be doable. > > > > Regards. > A binary doesn't *just* need to be on a wxallowed filesystem, it must also be marked with the wxneeded flag. So even if you mount /usr/local with wxallowed the vast majority of programs installed there are still denied W|X maps, there's no need for a separate filesystem to do that.
Re: bgpd "export default-route" [Re: CVS: cvs.openbsd.org: src]
Thanks for a couple of offlist replies .. I had a partial src checkout and "make install" was installing the new binaries to / rather than /usr/sbin. I thought I had accounted for that and copied them into place but I guess with the late hour I must have missed something, as I've done a full src checkout from -current now and it's working as expected. On 2019/05/29 02:53, Stuart Henderson wrote: > On 2019/05/13 07:47, Denis Fondras wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: de...@cvs.openbsd.org 2019/05/13 07:47:36 > > > > Modified files: > > usr.sbin/bgpd : rde_update.c > > > > Log message: > > fix export default-route. > > > > OK claudio@ > > > > I've just been updating some remaining 6.3-ish boxes and running into > problems with this.. Does anyone have a config with "export default-route" > that works OK on -current that I could take a look at and see if I can > figure out what I've missed? > > I started with a working 6.3 config that has several peer groups (all > ibgp in this case). For one group it passes a full table, for another > (a couple of firewalls/VPN boxes etc) it uses "announce default-route" > to just feed a default route. > > In preparation for the update I made sure I have explicit default "deny > from/to any" rules at the top of the ruleset, "allow to group XX" for > that peer group, and no other rules that should deny the default route > being sent to them. > > After updating to 6.5, 0 routes are received at the peer. > > After spotting the above commit I updated bgpd to -current, same > again - no routes received at the peer. > > -current$ bgpctl sh rib out > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, >S = Stale, E = Error > origin validation state: N = not-found, V = valid, ! = invalid > origin: i = IGP, e = EGP, ? = Incomplete > > flags ovs destination gateway lpref med aspath origin > I* N 0.0.0.0/00.0.0.0100 0 i > * N 0.0.0.0/00.0.0.0100 0 i > * N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N ::/0 :: 100 0 i > > -current$ bgpctl sh rib out nei somepeer > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, >S = Stale, E = Error > origin validation state: N = not-found, V = valid, ! = invalid > origin: i = IGP, e = EGP, ? = Incomplete > > flags ovs destination gateway lpref med aspath origin > I* N 0.0.0.0/00.0.0.0100 0 i > > ... I'm not sure about the 0.0.0.0 for gateway, it doesn't feel right, > but I can't compare with 6.3 because I don't see anything from "sh rib out > nei XX" > and a plain "sh rib out" isn't available there. > > somepeer$ bgpctl sh > Neighbor ASMsgRcvdMsgSent OutQ Up/Down > State/PrfRcvd > (-current) x 386398 386395 0 00:53:13 0 > (6.3) x 386382 386368 0 00:00:02 1 > > .. > > I've backed out to 2018/06/12 so I can remove my hastily-added static > defaults ;) but would be grateful for any clues .. >
Mount point just for W|X packages?
So, following the new advancements in W^X from Theo, I was thinking about this idea: ports maintainers cannot make every single package be W^X, this is obvious. But they could test each package without wxallowed and, if it is not working, make the package go to other specified filesystem with wxallowed. For example: all packages I need can work without wxallowed on /usr/local/bin, except for some shitty python scripts that I unfortunately need. So, in order to make it work, I need to put wxallowed in all this mount point. Wouldn't it be better to just create, lets say, /usr/local/wxallowedbin/ on the installation procedure? Of course this would require some effors from ports maintainers, but should be doable. Regards.
Re: vmd(8) i8042 device implementation questions
I did a little more looking and the only practical use is $F0 to pulse the reset line rather than setting it directly (and thus locking up the system forever). I’ll treat it as a reset. $F1 would pulse Gate A20 (which is a useless operation in a PC) and $F2 and $F3 pulse reserved bits. > On May 29, 2019, at 3:16 AM, Mike Larkin wrote: > We don't have very precise timing, so I'm not sure how you're going to get a > 6uS pulse. What does an attached device do with such a pulse in a normal > scenario?
Re: [patch] use acme-client to sign certificated with ecdsa keys
On 5/29/19 9:58 AM, Florian Obser wrote: On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote: Hello, First, sorry for double posting to misc@. This is a short patch to let acme-client accept ECDSA keys now that letsencrypt accepts signing certificates with those keys. This functionality is present in certbot, so it might be a good idea to let acme-client accept that too. thanks The key needs to be generated manually i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem why not let acme-client generate the key? I prefer to first enable testing for everyone to be able to spot the eventual problems with those certs. For example, opensmtpd and relayd still don't support ecdsa certs because they to don't have a privsep engine for that yet, so you certainly don't want ecdsa to be the default at the moment. But, yes, I plan to make a patch to enable generating ecdsa keys. It will mainly be useful when Letsencrypt will allow signing with ecdsa too. smime.p7s Description: S/MIME Cryptographic Signature
Re: vmd(8) i8042 device implementation questions
On Tue, May 28, 2019 at 09:57:02PM -0500, Katherine Rohl wrote: > I have my i8042 device for vmd(8) mostly implemented. It’s only missing a few > commands, but since there are no PS/2 input devices yet, there isn’t very > much in the way of testing I can do beyond ensuring that commands act as they > should. > > I have a couple questions about expected behavior, mostly related to the 8042 > output port. > > * The 8042 controls the CPU reset line, but I’m not sure what the behavior > should be in terms of vmm/vmd. Send a reset command if the reset line gets > pulled low? The reset line being asserted (deasserted?) can be shunted to the same code in vmd that processes triple faults, thus resetting the CPU. > * The 8042 controls Gate A20, which doesn’t seem to exist in the VM. I just > have the output line not hooked up to anything. That OK? Ignore for now. > * There is nothing hooked up to the PS/2 ports since adding input devices is > out of scope for my current diff. > * Commands F0-F3 pulse 8042 output port bits low for 6uS. How should such > timing be implemented in a vmd device? > We don't have very precise timing, so I'm not sure how you're going to get a 6uS pulse. What does an attached device do with such a pulse in a normal scenario? > Once I get these cleared up, I should have a diff ready by the weekend. The > 8042 already gets detected in the OpenBSD boot process! > > Katherine >
Re: [patch] use acme-client to sign certificated with ecdsa keys
On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote: > Hello, > > First, sorry for double posting to misc@. > > This is a short patch to let acme-client accept ECDSA keys now that > letsencrypt accepts signing certificates with those keys. This functionality > is present in certbot, so it might be a good idea to let acme-client accept > that too. thanks > The key needs to be generated manually > i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem why not let acme-client generate the key? > > Best Regards > -- I'm not entirely sure you are real.
