Re: Another acpidump(4) fix
On Sat, Jun 30, 2018 at 08:43:18PM +0200, Mark Kettenis wrote: > The pointer to the DSDT may be 64-bit as well. In that case the > 32-bit field will be zero and we have to use the 64-bit field. > > ok? > > > Index: acpidump.c > === > RCS file: /cvs/src/usr.sbin/acpidump/acpidump.c,v > retrieving revision 1.18 > diff -u -p -r1.18 acpidump.c > --- acpidump.c24 Jun 2018 10:39:59 - 1.18 > +++ acpidump.c30 Jun 2018 18:41:51 - > @@ -532,7 +532,10 @@ acpi_handle_facp(struct FACPbody *facp) > struct ACPIsdt *dsdp; > > acpi_print_facp(facp); > - dsdp = (struct ACPIsdt *) acpi_map_sdt(facp->dsdt_ptr); > + if (facp->dsdt_ptr == 0) > + dsdp = (struct ACPIsdt *) acpi_map_sdt(facp->x_dsdt); > + else > + dsdp = (struct ACPIsdt *) acpi_map_sdt(facp->dsdt_ptr); > if (acpi_checksum(dsdp, dsdp->len)) > errx(1, "DSDT is corrupt"); > acpi_handle_dsdt(dsdp); > ok
errors in usage.c - libusbhid
> Note that your diff doesn't apply. You have tab vs spaces issues. Sorry about that, it seems like I need to setup a proper mail-client. > I don't understand what you're talking about. Can you give example of > the 3 scenarios you're talking about. If you look inside /usr/share/misc/usb_hid_usages you will find it in 9 Button, 10 Ordinal, 16 Unicode and 129 Monitor Enumerated Values. > There's also a similar fix in NetBSD's tree, did you look at it? I took a look now and it enlightened a potential problem. NetBSD is using fmtcheck to make sure a "correct" format string is used. I could perhaps make an effort on a patch adding that function into stdio in OpenBSD, as that solves uses of %u compatible format strings https://man.openbsd.org/NetBSD-7.1/fmtcheck.3 I do now also see what your concerns about scanf might of been. My proposed patch open up for a two step "attack". If a malicious user is able to alter the contents of usb_hid_usages and change the name to add something like %s and if a program then lets a user specify a name to be used by hid_parse_usage_in_page it could then perform a buffer overflow. My first solution of using a "static" format-string would not been affected by this potential attack or the version using strtonum(). but at the same time it would not be able to parse the 16 Unicode example. One middle way solution could be to write a "scanf" that only handles %u or %x format strings, in other words a simplified variant of fmtcheck. Would really love to get some advice before continuing working on this patch.
Another acpidump(4) fix
The pointer to the DSDT may be 64-bit as well. In that case the 32-bit field will be zero and we have to use the 64-bit field. ok? Index: acpidump.c === RCS file: /cvs/src/usr.sbin/acpidump/acpidump.c,v retrieving revision 1.18 diff -u -p -r1.18 acpidump.c --- acpidump.c 24 Jun 2018 10:39:59 - 1.18 +++ acpidump.c 30 Jun 2018 18:41:51 - @@ -532,7 +532,10 @@ acpi_handle_facp(struct FACPbody *facp) struct ACPIsdt *dsdp; acpi_print_facp(facp); - dsdp = (struct ACPIsdt *) acpi_map_sdt(facp->dsdt_ptr); + if (facp->dsdt_ptr == 0) + dsdp = (struct ACPIsdt *) acpi_map_sdt(facp->x_dsdt); + else + dsdp = (struct ACPIsdt *) acpi_map_sdt(facp->dsdt_ptr); if (acpi_checksum(dsdp, dsdp->len)) errx(1, "DSDT is corrupt"); acpi_handle_dsdt(dsdp);
bwfm: kernel panic with a LG AN-WF500 (BCM43242)
Hi, I bought a LG AN-WF500 wifi adapter and I'm trying to use it on OpenBSD with the driver bwfm. The driver supports the chipset BCM43242 but doesn't have the IDs for the adapter. I tried to add the IDs to the driver (patch at the end of the mail) but the kernel detects three devices and panics when tries to initialize the first one. Sorry, I only have a photo of the panic: https://juanfra.info/t/panic_bwfm_1.png I'm not sure what the problem is but maybe the driver is trying to initialize the wrong device. I don't know how to make the driver skips the first device and try the others, so if you can help with it or have a better idea... The adapter is fullmac and works on Linux with the broadcom driver. This is the output of "lsusb -v" from Linux and looks like the wifi chip is the third device: Bus 001 Device 003: ID 043e:3101 LG Electronics USA, Inc. AN-WF500 802.11abgn + BT Wireless Adapter [Broadcom BCM43242] Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x043e LG Electronics USA, Inc. idProduct 0x3101 AN-WF500 802.11abgn + BT Wireless Adapter [Broadcom BCM43242] bcdDevice0.01 iManufacturer 1 Broadcom iProduct4 Composite Wireless Adapter iSerial 3 13597 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x005d bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass224 Wireless bFunctionSubClass 1 Radio Frequency bFunctionProtocol 1 Bluetooth iFunction 5 Bluetooth MI Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 6 Bluetooth Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 6 Bluetooth Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0014 1x 20 bytes bInterval 8 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0014 1x 20 bytes bInterval 8 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass
call ber_read() from ber_getc() in ldap, ldapd, and ypldap
I recently committed a piece of BER code synchronizing in the wrong direction
(i.e. from the ldap instances to the snmpd instance). sthen@ noticed a break
in SNMPv3 authentication and reverted that part of the change. Thanks Stuart!
I just fixed some typos in the snmpd regression test which prevented me from
noticing the problem. I am also the author of those typos... arg.
I believe the diff below synchronizes this piece of BER code in the right
direction, from the snmpd instance to the ldap instances. I have done some
testing against ldap and ldapd, but not ypldap. If anyone out there could
perform further testing on and/or review the change to make sure it doesn't
break anything that would be much appreciated.
Thanks!
Rob
Index: usr.bin/ldap/ber.c
===
RCS file: /cvs/src/usr.bin/ldap/ber.c,v
retrieving revision 1.6
diff -u -p -r1.6 ber.c
--- usr.bin/ldap/ber.c 29 Jun 2018 18:28:41 - 1.6
+++ usr.bin/ldap/ber.c 30 Jun 2018 17:50:06 -
@@ -1240,7 +1240,7 @@ ber_free(struct ber *b)
static ssize_t
ber_getc(struct ber *b, u_char *c)
{
- return ber_readbuf(b, c, 1);
+ return ber_read(b, c, 1);
}
static ssize_t
Index: usr.sbin/ldapd/ber.c
===
RCS file: /cvs/src/usr.sbin/ldapd/ber.c,v
retrieving revision 1.16
diff -u -p -r1.16 ber.c
--- usr.sbin/ldapd/ber.c29 Jun 2018 18:28:42 - 1.16
+++ usr.sbin/ldapd/ber.c30 Jun 2018 17:50:06 -
@@ -1240,7 +1240,7 @@ ber_free(struct ber *b)
static ssize_t
ber_getc(struct ber *b, u_char *c)
{
- return ber_readbuf(b, c, 1);
+ return ber_read(b, c, 1);
}
static ssize_t
Index: usr.sbin/ypldap/ber.c
===
RCS file: /cvs/src/usr.sbin/ypldap/ber.c,v
retrieving revision 1.18
diff -u -p -r1.18 ber.c
--- usr.sbin/ypldap/ber.c 29 Jun 2018 18:28:42 - 1.18
+++ usr.sbin/ypldap/ber.c 30 Jun 2018 17:50:06 -
@@ -1240,7 +1240,7 @@ ber_free(struct ber *b)
static ssize_t
ber_getc(struct ber *b, u_char *c)
{
- return ber_readbuf(b, c, 1);
+ return ber_read(b, c, 1);
}
static ssize_t
Re: com@acpi
On Sat, Jun 30, 2018 at 02:41:02PM +0200, Mark Kettenis wrote:
> Diff below adds support for the com(4) driver to attach to acpi(4).
> This is needed to support serial console on arm64 ACPI machines. This
> diff is fairly complete. It looks at the SPCR table if present to
> determine if the serial port in question is the console. It also uses
> "Device Properties" to find out the clock frequencies and register
> access quirks. Note that this does deliberately not attach to the
> "classic" serial ports on amd64 and i386. Those continue to be attached
> to isa(4). But this driver could be used for the "low power" UART ports
> found on Intel SoCs as well.
>
> Personally I find this "Device Properties" stuff hilarious. ARM picked
> ACPI over device trees because it was so much more superior. So much
> more superior that they need to embed snippets of a device tree into the
> AML...
>
> Anyway, ok?
>
LGTM. go for it, ok mlarkin.
>
> Index: dev/acpi/acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.350
> diff -u -p -r1.350 acpi.c
> --- dev/acpi/acpi.c 30 Jun 2018 10:16:35 - 1.350
> +++ dev/acpi/acpi.c 30 Jun 2018 12:24:16 -
> @@ -2875,6 +2875,50 @@ acpi_foundsony(struct aml_node *node, vo
> return 0;
> }
>
> +/* Support for _DSD Device Properties. */
> +
> +uint32_t
> +acpi_getpropint(struct aml_node *node, const char *prop, uint32_t defval)
> +{
> + struct aml_value dsd;
> + int i;
> +
> + /* daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
> + static uint8_t prop_guid[] = {
> + 0x14, 0xd8, 0xff, 0xda, 0xba, 0x6e, 0x8c, 0x4d,
> + 0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01,
> + };
> +
> + if (aml_evalname(acpi_softc, node, "_DSD", 0, NULL, ))
> + return defval;
> +
> + if (dsd.type != AML_OBJTYPE_PACKAGE || dsd.length != 2 ||
> + dsd.v_package[0]->type != AML_OBJTYPE_BUFFER ||
> + dsd.v_package[1]->type != AML_OBJTYPE_PACKAGE)
> + return defval;
> +
> + /* Check UUID. */
> + if (dsd.v_package[0]->length != sizeof(prop_guid) ||
> + memcmp(dsd.v_package[0]->v_buffer, prop_guid,
> + sizeof(prop_guid)) != 0)
> + return defval;
> +
> + /* Check properties. */
> + for (i = 0; i < dsd.v_package[1]->length; i++) {
> + struct aml_value *res = dsd.v_package[1]->v_package[i];
> +
> + if (res->type != AML_OBJTYPE_PACKAGE || res->length != 2 ||
> + res->v_package[0]->type != AML_OBJTYPE_STRING ||
> + res->v_package[1]->type != AML_OBJTYPE_INTEGER)
> + continue;
> +
> + if (strcmp(res->v_package[0]->v_string, prop) == 0)
> + return res->v_package[1]->v_integer;
> + }
> +
> + return defval;
> +}
> +
> int
> acpi_parsehid(struct aml_node *node, void *arg, char *outcdev, char *outdev,
> size_t devlen)
> Index: dev/acpi/acpireg.h
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
> retrieving revision 1.41
> diff -u -p -r1.41 acpireg.h
> --- dev/acpi/acpireg.h29 Jun 2018 17:39:18 - 1.41
> +++ dev/acpi/acpireg.h30 Jun 2018 12:24:16 -
> @@ -417,6 +417,35 @@ struct acpi_mcfg {
> uint32_treserved1;
> } __packed;
>
> +struct acpi_spcr {
> + struct acpi_table_headerhdr;
> +#define SPCR_SIG "SPCR"
> + uint8_t interface_type;
> +#define SPCR_16550 0
> +#define SPCR_16450 1
> +#define SPCR_ARM_PL011 3
> +#define SPCR_ARM_SBSA14
> + uint8_t reserved1[3];
> + struct acpi_gas base_address;
> + uint8_t interrupt_type;
> + uint8_t irq;
> + uint32_tgsiv;
> + uint8_t baud_rate;
> + uint8_t parity;
> + uint8_t stop_bits;
> + uint8_t flow_control;
> + uint8_t terminal_type;
> + uint8_t reserved2;
> + uint16_tpci_device_id;
> + uint16_tpci_vendor_id;
> + uint8_t pci_bus;
> + uint8_t pci_device;
> + uint8_t pci_function;
> + uint32_tpci_flags;
> + uint8_t pci_segment;
> + uint32_treserved3;
> +};
> +
> struct acpi_facs {
> uint8_t signature[4];
> #define FACS_SIG"FACS"
> Index: dev/acpi/acpivar.h
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
> retrieving revision 1.93
> diff -u -p -r1.93 acpivar.h
> --- dev/acpi/acpivar.h29 Jun 2018 17:39:18 - 1.93
> +++ dev/acpi/acpivar.h30 Jun 2018 12:24:16 -
> @@ -365,6 +365,8 @@ void acpi_sleep(int, char *);
> int acpi_matchhids(struct acpi_attach_args *, const char *[], const char *);
> int acpi_parsehid(struct aml_node
com@acpi
Diff below adds support for the com(4) driver to attach to acpi(4).
This is needed to support serial console on arm64 ACPI machines. This
diff is fairly complete. It looks at the SPCR table if present to
determine if the serial port in question is the console. It also uses
"Device Properties" to find out the clock frequencies and register
access quirks. Note that this does deliberately not attach to the
"classic" serial ports on amd64 and i386. Those continue to be attached
to isa(4). But this driver could be used for the "low power" UART ports
found on Intel SoCs as well.
Personally I find this "Device Properties" stuff hilarious. ARM picked
ACPI over device trees because it was so much more superior. So much
more superior that they need to embed snippets of a device tree into the
AML...
Anyway, ok?
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.350
diff -u -p -r1.350 acpi.c
--- dev/acpi/acpi.c 30 Jun 2018 10:16:35 - 1.350
+++ dev/acpi/acpi.c 30 Jun 2018 12:24:16 -
@@ -2875,6 +2875,50 @@ acpi_foundsony(struct aml_node *node, vo
return 0;
}
+/* Support for _DSD Device Properties. */
+
+uint32_t
+acpi_getpropint(struct aml_node *node, const char *prop, uint32_t defval)
+{
+ struct aml_value dsd;
+ int i;
+
+ /* daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
+ static uint8_t prop_guid[] = {
+ 0x14, 0xd8, 0xff, 0xda, 0xba, 0x6e, 0x8c, 0x4d,
+ 0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01,
+ };
+
+ if (aml_evalname(acpi_softc, node, "_DSD", 0, NULL, ))
+ return defval;
+
+ if (dsd.type != AML_OBJTYPE_PACKAGE || dsd.length != 2 ||
+ dsd.v_package[0]->type != AML_OBJTYPE_BUFFER ||
+ dsd.v_package[1]->type != AML_OBJTYPE_PACKAGE)
+ return defval;
+
+ /* Check UUID. */
+ if (dsd.v_package[0]->length != sizeof(prop_guid) ||
+ memcmp(dsd.v_package[0]->v_buffer, prop_guid,
+ sizeof(prop_guid)) != 0)
+ return defval;
+
+ /* Check properties. */
+ for (i = 0; i < dsd.v_package[1]->length; i++) {
+ struct aml_value *res = dsd.v_package[1]->v_package[i];
+
+ if (res->type != AML_OBJTYPE_PACKAGE || res->length != 2 ||
+ res->v_package[0]->type != AML_OBJTYPE_STRING ||
+ res->v_package[1]->type != AML_OBJTYPE_INTEGER)
+ continue;
+
+ if (strcmp(res->v_package[0]->v_string, prop) == 0)
+ return res->v_package[1]->v_integer;
+ }
+
+ return defval;
+}
+
int
acpi_parsehid(struct aml_node *node, void *arg, char *outcdev, char *outdev,
size_t devlen)
Index: dev/acpi/acpireg.h
===
RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
retrieving revision 1.41
diff -u -p -r1.41 acpireg.h
--- dev/acpi/acpireg.h 29 Jun 2018 17:39:18 - 1.41
+++ dev/acpi/acpireg.h 30 Jun 2018 12:24:16 -
@@ -417,6 +417,35 @@ struct acpi_mcfg {
uint32_treserved1;
} __packed;
+struct acpi_spcr {
+ struct acpi_table_headerhdr;
+#define SPCR_SIG "SPCR"
+ uint8_t interface_type;
+#define SPCR_16550 0
+#define SPCR_16450 1
+#define SPCR_ARM_PL011 3
+#define SPCR_ARM_SBSA 14
+ uint8_t reserved1[3];
+ struct acpi_gas base_address;
+ uint8_t interrupt_type;
+ uint8_t irq;
+ uint32_tgsiv;
+ uint8_t baud_rate;
+ uint8_t parity;
+ uint8_t stop_bits;
+ uint8_t flow_control;
+ uint8_t terminal_type;
+ uint8_t reserved2;
+ uint16_tpci_device_id;
+ uint16_tpci_vendor_id;
+ uint8_t pci_bus;
+ uint8_t pci_device;
+ uint8_t pci_function;
+ uint32_tpci_flags;
+ uint8_t pci_segment;
+ uint32_treserved3;
+};
+
struct acpi_facs {
uint8_t signature[4];
#defineFACS_SIG"FACS"
Index: dev/acpi/acpivar.h
===
RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
retrieving revision 1.93
diff -u -p -r1.93 acpivar.h
--- dev/acpi/acpivar.h 29 Jun 2018 17:39:18 - 1.93
+++ dev/acpi/acpivar.h 30 Jun 2018 12:24:16 -
@@ -365,6 +365,8 @@ voidacpi_sleep(int, char *);
intacpi_matchhids(struct acpi_attach_args *, const char *[], const char *);
intacpi_parsehid(struct aml_node *, void *, char *, char *, size_t);
+uint32_t acpi_getpropint(struct aml_node *, const char *, uint32_t);
+
intacpi_record_event(struct acpi_softc *, u_int);
void acpi_addtask(struct acpi_softc *, void (*)(void *, int), void *, int);
Index:
Looking for logitech webcams testers/device info
Hi,
sending this to a wider audience on misc@, to fix the microphone (cf
https://marc.info/?t=15298427072=1=2) on a
variety of logitech webcams (mostly the Cxxx{,HD}?) i'd need the lsusb
-v output for the corresponding devices.
If you have a logitech webcam where the mic doesnt work (looking for
'uaudio0: audio descriptors make no sense, error=4' in dmesg) this is
your chance to help fix it.
Of course if you have a logitech webcam where the mic works out of the
box, this information is also valuable !
Install usbutils package, run lsusb to find the device ids
corresponding to the logitech device (starts with 046d:, per
https://usb-ids.gowdy.us/read/UD/046d) and send me privately the output
of:
lsusb -v -d 046d:
where matches your webcam.
if you receive directly this e-mail in bcc, it's because i've found
occurences of 'audio descriptors make no sense' corresponding to a
logitech webcam in our dmesg archive sent by you, this information is
definitely valuable so please keep sending dmesg per
https://www.openbsd.org/faq/faq4.html#SendDmesg :)
Landry
