other usermount bugs

[Ted Unangst]

In addition to the patched bugs, several panics were discovered by NCC that
can be triggered by root or users with the usermount option set. These bugs
are not getting patched because we believe they are only the tip of the
iceberg. The mount system call exposes too much code to userland to be
considered secure.

As remediation, it's recommended to disable usermount. For the forthcoming 6.0
release, the usermount option will be removed.

multiple patches available

[Ted Unangst]

Several patches are available to fix kernel errata.

Please refer to http://www.openbsd.org/errata59.html and errata58.html for
details and patches.

Patches for 5.9 include:

 013: RELIABILITY FIX: July 14, 2016   All architectures
 Splicing sockets in a loop could cause a kernel spin.

 014: RELIABILITY FIX: July 14, 2016   All architectures
 Multiple processes exiting with a fd-passing control message on a shared
 socket could crash the system.

 015: RELIABILITY FIX: July 14, 2016   All architectures
 ufs_readdir failed to limit size of memory allocation, leading to panics.

 016: SECURITY FIX: July 14, 2016   All architectures
 The mmap extension __MAP_NOFAULT could overcommit resources and crash the
 system.

 017: RELIABILITY FIX: July 14, 2016   All architectures
 A race occuring in the unlocked ARP input path can lead to a kernel NULL
 dereference.

 018: RELIABILITY FIX: July 14, 2016   All architectures
 Tick counting overflows could cause a kernel crash.

 019: RELIABILITY FIX: July 14, 2016   All architectures
 Invalid file descriptor use with kevent(2) could lead to a kernel crash.

 020: RELIABILITY FIX: July 14, 2016   All architectures
 Unchecked parameters and integer overflows in the amap allocation routines
 could cause malloc(9) to either not allocate enough memory, leading to memory
 corruption, or to trigger a "malloc: allocation too large" panic.

Re: acpiec: handle burst mode failure

[Mark Kettenis]

> Date: Thu, 14 Jul 2016 16:41:10 -0500
> From: joshua stein 
> 
> On Thu, 14 Jul 2016 at 16:31:32 -0500, joshua stein wrote:
> > Also, I just checked FreeBSD and they appear to do something similar
> > to my patch, where they check that the EC burst mode flag is set in
> > the status after trying to enable it:
> > 
> > https://github.com/freebsd/freebsd/blob/master/sys/dev/acpica/acpi_ec.c#L933
> > 
> > before actually trying to read the ACK:
> > 
> > https://github.com/freebsd/freebsd/blob/master/sys/dev/acpica/acpi_ec.c#L775
> 
> Interestingly it looks like FreeBSD used to have burst mode off by
> default because of problems with certain machines, then enabled it
> after adding that check for the status being on:
> 
> https://github.com/freebsd/freebsd/commit/7eb821d885e98115ff7a592adc00c4dbc05109cc
> 
> but then went back to disabling it by default in 2007 because of
> continued problems with certain hardware, and it remains off by
> default:
> 
> https://github.com/freebsd/freebsd/commit/a8ba35fb0023bb456954993d3c55712666b50d13
> 
> I wonder why we haven't seen (m)any problems with it being on by
> default.

We have seen many problems.

Re: jot(1) changed behavior

[Edgar Pettijohn]

On 16-07-14 12:00:21, Philippe Meunier wrote:
> Hello,
> 
> According to jot(1)'s man page:
> 
> "$ jot -w %d -r 10 1 4 | sort -n | uniq -c
> 33306 1
> 33473 2
> 33221 3
> 
> Note that with random sequences, all numbers generated will be smaller
> than the upper bound.  The largest value generated will be a tiny bit
> smaller than the upper bound.  For floating point formats, the value
> is rounded as described before being printed.  For integer formats,
> the highest value printed will be one less than the requested upper
> bound, because the generated value will be truncated."
> 
> The "smaller than the upper bound" part used to be correct but not
> anymore:
> 
> $ uname -a
> OpenBSD something.somewhere 5.9 GENERIC#1561 i386
> $ jot -w %d -r 10 1 4 | sort -n | uniq -c
> 24729 1
> 25035 2
> 25106 3
> 25130 4
> 
> Looking at the cvs log for jot.c, this seems to be a known change:
> 
> "revision 1.27 [...] Internally, jot -r now uses arc4random_uniform()
> whenever this is clearly possible.  In particular `jot -r 1 10 20'
> yields an unbiased random number between 10 and 20 (both ends
> inclusive) from the shell."
> 
> I only discovered this change today after noticing that one of my
> shell scripts that used to work fine had started to fail with a low
> probability: the script uses jot(1) to generate a sequence of random
> array indexes, and with this change an index can now be out of bounds
> with a probability of about 1/1700.  Fortunately it isn't an important
> script but given the low probability of failure it wasn't exactly fun
> to debug.  Anyway, I don't know which one of jot or jot's man page is
> going to be fixed but I'd advocate for reverting to the previous
> behavior to preserve the semantics of scripts that rely on it.
> 
> Cheers,
> 
> Philippe
> 
Try this patch.  I don't use jot, but in my simple testing I think this is
what you are looking for.
-- 
Edgar Pettijohn
Index: jot.c
===
RCS file: /cvs/src/usr.bin/jot/jot.c,v
retrieving revision 1.27
diff -u -p -u -r1.27 jot.c
--- jot.c   10 Jan 2016 01:15:52 -  1.27
+++ jot.c   14 Jul 2016 22:53:41 -
@@ -296,7 +296,6 @@ main(int argc, char *argv[])
uintx = pow10 * (ender - begin);
if (uintx >= UINT32_MAX)
errx(1, "requested range too large");
-   uintx++;
}
 
for (i = 1; i <= reps || infinity; i++) {

Re: acpiec: handle burst mode failure

[joshua stein]

On Thu, 14 Jul 2016 at 16:31:32 -0500, joshua stein wrote:
> Also, I just checked FreeBSD and they appear to do something similar
> to my patch, where they check that the EC burst mode flag is set in
> the status after trying to enable it:
> 
> https://github.com/freebsd/freebsd/blob/master/sys/dev/acpica/acpi_ec.c#L933
> 
> before actually trying to read the ACK:
> 
> https://github.com/freebsd/freebsd/blob/master/sys/dev/acpica/acpi_ec.c#L775

Interestingly it looks like FreeBSD used to have burst mode off by
default because of problems with certain machines, then enabled it
after adding that check for the status being on:

https://github.com/freebsd/freebsd/commit/7eb821d885e98115ff7a592adc00c4dbc05109cc

but then went back to disabling it by default in 2007 because of
continued problems with certain hardware, and it remains off by
default:

https://github.com/freebsd/freebsd/commit/a8ba35fb0023bb456954993d3c55712666b50d13

I wonder why we haven't seen (m)any problems with it being on by
default.

Re: acpiec: handle burst mode failure

[joshua stein]

On Sat, 09 Jul 2016 at 16:32:15 -0700, Philip Guenther wrote:
> No newer bios for this thing?  :-(

It is actually the open-source Chrome EC found on the Chromebook
Pixel (among others), and according to the source code for the
version on this machine, it did not implement burst mode in its ACPI
interface.

They eventually added support for it later, but for any EC that does
not support burst mode, I think this patch does the right thing by
checking that burst mode actually turns on before waiting for the
ack byte.

> > That's why the diff also includes the change to acpiec_write_cmd to
> > wait until IBF is 0, so it won't get to that new status check until
> > the controller has processed the EC_CMD_BE fully.
> 
> I don't think the spec guarantees that implication, though it may be
> true in practice.
> 
> 
> 
> Wonder what Windows and Linux do on this thing.

Linux doesn't even enable burst mode unless busy polling is enabled
(which is only turned on when passed as a kernel boot flag), or when
the read/write length is more than 8.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/ec.c#n1195

(I think this is why they didn't bother implementing burst mode in
the ACPI interface of the Chrome EC, since it usually just runs
Linux and Linux doesn't usually try burst mode (and most other
device interfaces for this machine use direct I2C/LPC interfaces to
the EC instead of through ACPI.))

Also, I just checked FreeBSD and they appear to do something similar
to my patch, where they check that the EC burst mode flag is set in
the status after trying to enable it:

https://github.com/freebsd/freebsd/blob/master/sys/dev/acpica/acpi_ec.c#L933

before actually trying to read the ACK:

https://github.com/freebsd/freebsd/blob/master/sys/dev/acpica/acpi_ec.c#L775

> Anyway, this diff would need to be tested broadly on *unaffected*
> hardware to gain confidence it doesn't hurt some box that doesn't have
> this brokeness.

Yeah, I'll probably just disable acpicbkbd for the 6.0 release
because it requires talking to the EC and will just hang the kernel
on Chromebooks with a Chrome EC.

Re: armv7/imx: imxpcie(4) driver & device tree problem

[Mark Kettenis]

> Date: Thu, 14 Jul 2016 11:56:47 +0200 (CEST)
> From: Mark Kettenis 
>
> > > Time to investigate the
> > > 
> > >   sdmmc0: can't enable card
> > > 
> > > message I see on my CuBox-i4Pro once more.
> > 
> > I'd look at the no-1-8v property to start with (ommmc should be looking
> > at ti,dual-volt before using 3.0v as well).
> > 
> > Documented as:
> > 
> > - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
> >   this system, even if the controller claims it is.
> 
> I'll look at it, but I think the 1.8v thing doesn't apply to SDIO and
> was only handled to work around an issue in the Linux sdhc code.

And indeed, after doing all the mmc-pwrseq and vmmc-supply magic, I
now get a response from the SDIO card:

(manufacturer 0x2d0, product 0x4330)at sdmmc0 function 1 not configured
(manufacturer 0x2d0, product 0x4330)at sdmmc0 function 2 not configured

which indicates that we're dealing with a BCM4330 (or at least one of
its family members) here.

Re: Add hotkey support for Asus Zenbook UX31A

[Frank Groeneveld]

On Thu, Jul 14, 2016 at 07:42:28PM +0200, Mark Kettenis wrote:
> Please send the acpidump output for that machine; "pnp0c14" for an
> ASUS-specific device looks wrong.

Thanks for reviewing. This the only ACPI device that works when
attaching (volume buttons start working). I've added the dumps
below.

Frank


zenbook_ux31a.APIC.3
Description: Binary data


zenbook_ux31a.BGRT.17
Description: Binary data


zenbook_ux31a.DMAR.16
Description: Binary data


zenbook_ux31a.DSDT.2
Description: Binary data


zenbook_ux31a.ECDT.5
Description: Binary data


zenbook_ux31a.FACP.1
Description: Binary data


zenbook_ux31a.FPDT.4
Description: Binary data


zenbook_ux31a.HPET.11
Description: Binary data


zenbook_ux31a.MCFG.6
Description: Binary data


zenbook_ux31a.SSDT.10
Description: Binary data


zenbook_ux31a.SSDT.12
Description: Binary data


zenbook_ux31a.SSDT.13
Description: Binary data


zenbook_ux31a.SSDT.14
Description: Binary data


zenbook_ux31a.SSDT.14
Description: Binary data


zenbook_ux31a.SSDT.15
Description: Binary data


zenbook_ux31a.SSDT.7
Description: Binary data


zenbook_ux31a.SSDT.8
Description: Binary data


zenbook_ux31a.SSDT.9
Description: Binary data

RSD PTR: Checksum=106, OEMID=_ASUS_, RsdtAddress=0xda89f028


RSDT: Length=104, Revision=1, Checksum=177,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=MSFT, Creator Revision=0x10013


Entries={ 0xda89f148, 0xda8b13d0, 0xda8b1448, 0xda8b1490, 0xda8b1558, 
0xda8b1598, 0xda8b1fd8, 0xda8b2c80, 0xda8b2d18, 0xda8b3638, 0xda8b3670, 
0xda8b3ad0, 0xda8b3f70, 0xda8b4940, 0xda8b5458, 0xda8b5508, 0xda64ce18 }


DSDT=0xda89f1d0
INT_MODEL=APIC
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xb0, ACPI_DISABLE=0xb1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x400-0x403
PM1a_CNT_BLK=0x404-0x405
PM2_CNT_BLK=0x450-0x450
PM2_TMR_BLK=0x408-0x40b
PM2_GPE0_BLK=0x420-0x42f
P_LVL2_LAT=101ms, P_LVL3_LAT=57ms
FLUSH_SIZE=1024, FLUSH_STRIDE=16
DUTY_OFFSET=0, DUTY_WIDTH=0
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
Flags={WBINVD,PROC_C1,PWR_BUTTON,SLP_BUTTON,RTC_S4,DCK_CAP}


DSDT: Length=73964, Revision=2, Checksum=176,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x13,
Creator ID=INTL, Creator Revision=0x20091112


APIC: Length=114, Revision=3, Checksum=207,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=AMI, Creator Revision=0x10013


FPDT: Length=68, Revision=1, Checksum=41,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=AMI, Creator Revision=0x10013


ECDT: Length=193, Revision=1, Checksum=246,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=AMI., Creator Revision=0x5


MCFG: Length=60, Revision=1, Checksum=50,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=MSFT, Creator Revision=0x97


SSDT: Length=2620, Revision=1, Checksum=131,
OEMID=DptfTa, OEM Table ID=DptfTab, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112


SSDT: Length=3237, Revision=1, Checksum=213,
OEMID=SADptf, OEM Table ID=SADptf_, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112


SSDT: Length=152, Revision=1, Checksum=179,
OEMID=PchDpt, OEM Table ID=PchDptf, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112


SSDT: Length=2332, Revision=1, Checksum=238,
OEMID=CfgTDP, OEM Table ID=CfgTDP_, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112


HPET: Length=56, Revision=1, Checksum=63,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=AMI., Creator Revision=0x5


SSDT: Length=1118, Revision=1, Checksum=194,
OEMID=AhciR1, OEM Table ID=AhciTab1, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112


SSDT: Length=1182, Revision=1, Checksum=231,
OEMID=AhciR2, OEM Table ID=AhciTab2, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112


SSDT: Length=2512, Revision=1, Checksum=95,
OEMID=PmRef, OEM Table ID=Cpu0Ist, OEM Revision=0x3000,
Creator ID=INTL, Creator Revision=0x20051117


SSDT: Length=2840, Revision=1, Checksum=147,
OEMID=PmRef, OEM Table ID=CpuPm, OEM Revision=0x3000,
Creator ID=INTL, Creator Revision=0x20051117


DMAR: Length=176, Revision=1, Checksum=82,
OEMID=INTEL, OEM Table ID=SNB, OEM Revision=0x1,
Creator ID=INTL, Creator Revision=0x1


BGRT: Length=56, Revision=0, Checksum=106,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=ASUS, Creator Revision=0x10013


MSDM: Length=85, Revision=3, Checksum=131,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x0,
Creator ID=ASUS, Creator Revision=0x1



zenbook_ux31a.MSDM.18
Description: Binary data

Re: Add hotkey support for Asus Zenbook UX31A

[Mark Kettenis]

> Date: Thu, 14 Jul 2016 19:15:46 +0200
> From: Frank Groeneveld 
> 
> Attached patch adds hotkey support for the Zenbook UX31A. I wasn't sure
> what to name the magic string, so please rename to whatever you find
> more suitable.
> 
> Next step in getting the Zenbook UX31A to work better is finding a neat
> way to prevent acpivideo from attaching. After the recent refactoring it
> seems I need to define ws_get_param and ws_set_param in acpiasus to do
> that, right?

Please send the acpidump output for that machine; "pnp0c14" for an
ASUS-specific device looks wrong.

Add hotkey support for Asus Zenbook UX31A

[Frank Groeneveld]

Attached patch adds hotkey support for the Zenbook UX31A. I wasn't sure
what to name the magic string, so please rename to whatever you find
more suitable.

Next step in getting the Zenbook UX31A to work better is finding a neat
way to prevent acpivideo from attaching. After the recent refactoring it
seems I need to define ws_get_param and ws_set_param in acpiasus to do
that, right?

Frank
Index: dev/acpi/acpiasus.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiasus.c,v
retrieving revision 1.17
diff -u -p -r1.17 acpiasus.c
--- dev/acpi/acpiasus.c 21 Feb 2014 18:49:06 -  1.17
+++ dev/acpi/acpiasus.c 14 Jul 2016 17:10:20 -
@@ -95,7 +95,7 @@ struct cfdriver acpiasus_cd = {
NULL, "acpiasus", DV_DULL
 };
 
-const char *acpiasus_hids[] = { ACPI_DEV_ASUS, 0 };
+const char *acpiasus_hids[] = { ACPI_DEV_ASUS, ACPI_DEV_ASUS2, 0 };
 
 int
 acpiasus_match(struct device *parent, void *match, void *aux)
Index: dev/acpi/acpireg.h
===
RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
retrieving revision 1.36
diff -u -p -r1.36 acpireg.h
--- dev/acpi/acpireg.h  10 Jul 2016 20:36:41 -  1.36
+++ dev/acpi/acpireg.h  14 Jul 2016 17:10:20 -
@@ -764,6 +764,7 @@ struct acpi_ivrs {
 #define ACPI_DEV_FFB   "FIXEDBUTTON"   /* Fixed Feature Button */
 #define ACPI_DEV_ASUS  "ASUS010"   /* ASUS Hotkeys */
 #define ACPI_DEV_ASUS1 "ATK0100"   /* ASUS Special Device */
+#define ACPI_DEV_ASUS2 "pnp0c14"   /* ASUS Zenbook UX31A Hotkeys */
 #define ACPI_DEV_IBM   "IBM0068"   /* IBM ThinkPad support */
 #define ACPI_DEV_LENOVO"LEN0068"   /* Lenovo ThinkPad support */
 #define ACPI_DEV_ASUSAIBOOSTER "ATK0110"   /* ASUSTeK AI Booster */

Re: A patch for allowing IPv6-only or IPv4-only bridges

[Martin Pieuchot]

On 13/07/16(Wed) 18:28, Quentin Rameau wrote:
> > Hello there,
> Hi,
> 
> > Here is my patch that adds support for creating IPv6-only or
> >IPv4-only bridges. This is different from simply blocking one of the
> >protocols via PF - it allows you to create a setup where IPv4 is routed
> >and IPv6 is bridged (or vice versa). Both of them being filtered by the
> >same set of PF rules. It adds two new bridge port options to ifconfig -
> >BLOCKIPV4 and BLOCKIPV6. BLOCKIPV4 also stops ARPs requests from
> >"leaking" across the bridge - something I couldn't accomplish by PF alone.
> > The patch breaks the binary compatibility of ifconfig - it must be
> >rebuilt with the new kernel.
> > I don't know if anyone will find any use for it. For sure it is
> >very useful with the second-biggest FTTH/ADSL operator in France who
> >offers consumer-grade IPv6 access with an indivisible /64 network that
> >must be bridged for firewalling (and a single IPv4/32 address that must
> >be NATted).
> > Patch is against -current, any comments are welcome.
> Thank you for that, I just found it and applyed a few hours ago.
> This is indeed handy for that situation.
> It's working fine ATM, I'll let you know if I stumble upon problems.
> That'd be nice to see that merged!

As discussed with landry@ and sthen@ this won't be merged.  Your problem
could also be solved by using a NDP proxy, that's a solution we would
recommend if your ISP cannot fix his setup.

Re: initialize variables patch for bn_nist.c

[Bob Beck]

I'm ok with this.


On Thu, Jul 14, 2016 at 4:57 AM, Kinichiro Inoguchi <
kinichiro.inogu...@gmail.com> wrote:

> Hi,
>
> When I build LibreSSL portable on HP-UX 11.3 with HP C/aC++ compiler,
> this warning is detected.
>
> ...
> "bn/bn_nist.c", line 611: warning #2549-D: variable "buf" is used before
> its value is set
> nist_set_224(buf.bn, c_d, 14, 13, 12, 11, 10, 9, 8);
> ^
> ...
>
> To initialize these variables before using, I would like to apply the
> patch.
> OK ?
>
> Here is original topic on GitHub.
> https://github.com/libressl-portable/openbsd/pull/19
>
> Best Regards,
>
> kinichiro inoguchi
>
>

initialize variables patch for bn_nist.c

[Kinichiro Inoguchi]

Hi,

When I build LibreSSL portable on HP-UX 11.3 with HP C/aC++ compiler,
this warning is detected.

...
"bn/bn_nist.c", line 611: warning #2549-D: variable "buf" is used before its 
value is set
nist_set_224(buf.bn, c_d, 14, 13, 12, 11, 10, 9, 8);
^
...

To initialize these variables before using, I would like to apply the patch.
OK ?

Here is original topic on GitHub.
https://github.com/libressl-portable/openbsd/pull/19

Best Regards,

kinichiro inoguchi

diff --git src/lib/libssl/src/crypto/bn/bn_nist.c 
src/lib/libssl/src/crypto/bn/bn_nist.c
index 4d3a612..a87309b 100644
--- src/lib/libssl/src/crypto/bn/bn_nist.c
+++ src/lib/libssl/src/crypto/bn/bn_nist.c
@@ -510,7 +510,7 @@ BN_nist_mod_192(BIGNUM *r, const BIGNUM *a, const BIGNUM 
*field, BN_CTX *ctx)
}
 #else
{
-   BN_ULONG t_d[BN_NIST_192_TOP];
+   BN_ULONG t_d[BN_NIST_192_TOP] = {0};
 
nist_set_192(t_d, buf.bn, 0, 3, 3);
carry = (int)bn_add_words(r_d, r_d, t_d, BN_NIST_192_TOP);
@@ -568,7 +568,7 @@ BN_nist_mod_224(BIGNUM *r, const BIGNUM *a, const BIGNUM 
*field, BN_CTX *ctx)
BN_ULONG bn[BN_NIST_224_TOP];
unsigned int ui[BN_NIST_224_TOP *
sizeof(BN_ULONG) / sizeof(unsigned int)];
-   } buf;
+   } buf = {0};
BN_ULONG c_d[BN_NIST_224_TOP], *res;
uintptr_t mask;
union {
@@ -673,7 +673,7 @@ BN_nist_mod_224(BIGNUM *r, const BIGNUM *a, const BIGNUM 
*field, BN_CTX *ctx)
}
 #else
{
-   BN_ULONG t_d[BN_NIST_224_TOP];
+   BN_ULONG t_d[BN_NIST_224_TOP] = {0};
 
nist_set_224(t_d, buf.bn, 10, 9, 8, 7, 0, 0, 0);
carry = (int)bn_add_words(r_d, r_d, t_d, BN_NIST_224_TOP);
@@ -746,7 +746,7 @@ BN_nist_mod_256(BIGNUM *r, const BIGNUM *a, const BIGNUM 
*field, BN_CTX *ctx)
unsigned int ui[BN_NIST_256_TOP *
sizeof(BN_ULONG) / sizeof(unsigned int)];
} buf;
-   BN_ULONG c_d[BN_NIST_256_TOP], *res;
+   BN_ULONG c_d[BN_NIST_256_TOP] = {0}, *res;
uintptr_t mask;
union {
bn_addsub_f f;
@@ -879,7 +879,7 @@ BN_nist_mod_256(BIGNUM *r, const BIGNUM *a, const BIGNUM 
*field, BN_CTX *ctx)
}
 #else
{
-   BN_ULONG t_d[BN_NIST_256_TOP];
+   BN_ULONG t_d[BN_NIST_256_TOP] = {0};
 
/*S1*/
nist_set_256(t_d, buf.bn, 15, 14, 13, 12, 11, 0, 0, 0);
@@ -1133,7 +1133,7 @@ BN_nist_mod_384(BIGNUM *r, const BIGNUM *a, const BIGNUM 
*field, BN_CTX *ctx)
}
 #else
{
-   BN_ULONG t_d[BN_NIST_384_TOP];
+   BN_ULONG t_d[BN_NIST_384_TOP] = {0};
 
/*S1*/
nist_set_256(t_d, buf.bn, 0, 0, 0, 0, 0, 23 - 4, 22 - 4,

Re: armv7/imx: imxpcie(4) driver & device tree problem

[Patrick Wildt]

On Thu, Jul 14, 2016 at 11:34:05AM +0200, Mark Kettenis wrote:
> > Date: Thu, 14 Jul 2016 17:53:22 +1000
> > From: Jonathan Gray 
> > 
> > On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote:
> > > I am working on a MD PCI-E driver for the armv7/imx platform. It
> > > attaches via FDT/simplebus, ascertaining its physical memory addresses
> > > from the fdt structure originating from the dtb files present on the
> > > msdos bootloader partition. The dtb files we're using now have the
> > > cubox's 'pcie' nodes disabled via a "status=disabled" property. The
> > > following patches fix this in the decompiled dtb outfiles:
> > 
> > I thought the wlan was attached to pcie but it seems it is
> > actually an sdio device.
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-microsom.dtsi
> > 
> > /* USDHC1 - Connected to optional BRCM Wifi/BT/FM */
> >  {
> > pinctrl-names = "default";
> > pinctrl-0 = <_microsom_brcm_wifi _microsom_usdhc1>;
> > bus-width = <4>;
> > mmc-pwrseq = <_pwrseq>;
> > keep-power-in-suspend;
> > no-1-8-v;
> > non-removable;
> > vmmc-supply = <_brcm>;
> > status = "okay";
> > };
> 
> WiFi over SDIO is quite common for these SoC-type systems.  The Bay
> Trail-based ASUS EeeBook I have has a similar setup.  I suppose PCIe
> sucks quite a bit of power even if you do proper link management.  I
> actually believe that Broadcom's PCIe solutions are essentially SDIO
> with a PCIe to SDIO bridge on front of them.
> 
> Time to investigate the
> 
>   sdmmc0: can't enable card
> 
> message I see on my CuBox-i4Pro once more.
> 

I stumbled over quite a lot SDIO-connected Broadcom FullMACs lately.
The raspberry Pi 3 contains a BCM43438, some Intel HW I have has
some BCM4334.  I have a USB dongle with a similar chip and now the
CuBox-i also contains one...  I'm sure I forgot at least one other
device that features that chip.

I had started with some simple device attachment and firmware
uploading for SDIO and USB, using the dual-licensed brcmfmac driver
as reference:

https://github.com/Bluerise/openbsd/compare/aecf6dba489bdcb0237695815df519e17b88a850...bcm

Patrick

Re: armv7/imx: imxpcie(4) driver & device tree problem

[Mark Kettenis]

> Date: Thu, 14 Jul 2016 19:45:32 +1000
> From: Jonathan Gray 
> 
> On Thu, Jul 14, 2016 at 11:34:05AM +0200, Mark Kettenis wrote:
> > > Date: Thu, 14 Jul 2016 17:53:22 +1000
> > > From: Jonathan Gray 
> > > 
> > > On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote:
> > > > I am working on a MD PCI-E driver for the armv7/imx platform. It
> > > > attaches via FDT/simplebus, ascertaining its physical memory addresses
> > > > from the fdt structure originating from the dtb files present on the
> > > > msdos bootloader partition. The dtb files we're using now have the
> > > > cubox's 'pcie' nodes disabled via a "status=disabled" property. The
> > > > following patches fix this in the decompiled dtb outfiles:
> > > 
> > > I thought the wlan was attached to pcie but it seems it is
> > > actually an sdio device.
> > > 
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-microsom.dtsi
> > > 
> > > /* USDHC1 - Connected to optional BRCM Wifi/BT/FM */
> > >  {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <_microsom_brcm_wifi 
> > > _microsom_usdhc1>;
> > > bus-width = <4>;
> > > mmc-pwrseq = <_pwrseq>;
> > > keep-power-in-suspend;
> > > no-1-8-v;
> > > non-removable;
> > > vmmc-supply = <_brcm>;
> > > status = "okay";
> > > };
> > 
> > WiFi over SDIO is quite common for these SoC-type systems.  The Bay
> > Trail-based ASUS EeeBook I have has a similar setup.  I suppose PCIe
> > sucks quite a bit of power even if you do proper link management.  I
> > actually believe that Broadcom's PCIe solutions are essentially SDIO
> > with a PCIe to SDIO bridge on front of them.
> > 
> > Time to investigate the
> > 
> >   sdmmc0: can't enable card
> > 
> > message I see on my CuBox-i4Pro once more.
> 
> I'd look at the no-1-8v property to start with (ommmc should be looking
> at ti,dual-volt before using 3.0v as well).
> 
> Documented as:
> 
> - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
>   this system, even if the controller claims it is.

I'll look at it, but I think the 1.8v thing doesn't apply to SDIO and
was only handled to work around an issue in the Linux sdhc code.

Re: armv7/imx: imxpcie(4) driver & device tree problem

[Jonathan Gray]

On Thu, Jul 14, 2016 at 11:34:05AM +0200, Mark Kettenis wrote:
> > Date: Thu, 14 Jul 2016 17:53:22 +1000
> > From: Jonathan Gray 
> > 
> > On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote:
> > > I am working on a MD PCI-E driver for the armv7/imx platform. It
> > > attaches via FDT/simplebus, ascertaining its physical memory addresses
> > > from the fdt structure originating from the dtb files present on the
> > > msdos bootloader partition. The dtb files we're using now have the
> > > cubox's 'pcie' nodes disabled via a "status=disabled" property. The
> > > following patches fix this in the decompiled dtb outfiles:
> > 
> > I thought the wlan was attached to pcie but it seems it is
> > actually an sdio device.
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-microsom.dtsi
> > 
> > /* USDHC1 - Connected to optional BRCM Wifi/BT/FM */
> >  {
> > pinctrl-names = "default";
> > pinctrl-0 = <_microsom_brcm_wifi _microsom_usdhc1>;
> > bus-width = <4>;
> > mmc-pwrseq = <_pwrseq>;
> > keep-power-in-suspend;
> > no-1-8-v;
> > non-removable;
> > vmmc-supply = <_brcm>;
> > status = "okay";
> > };
> 
> WiFi over SDIO is quite common for these SoC-type systems.  The Bay
> Trail-based ASUS EeeBook I have has a similar setup.  I suppose PCIe
> sucks quite a bit of power even if you do proper link management.  I
> actually believe that Broadcom's PCIe solutions are essentially SDIO
> with a PCIe to SDIO bridge on front of them.
> 
> Time to investigate the
> 
>   sdmmc0: can't enable card
> 
> message I see on my CuBox-i4Pro once more.

I'd look at the no-1-8v property to start with (ommmc should be looking
at ti,dual-volt before using 3.0v as well).

Documented as:

- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
  this system, even if the controller claims it is.

Re: armv7/imx: imxpcie(4) driver & device tree problem

[Mark Kettenis]

> Date: Thu, 14 Jul 2016 17:53:22 +1000
> From: Jonathan Gray 
> 
> On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote:
> > I am working on a MD PCI-E driver for the armv7/imx platform. It
> > attaches via FDT/simplebus, ascertaining its physical memory addresses
> > from the fdt structure originating from the dtb files present on the
> > msdos bootloader partition. The dtb files we're using now have the
> > cubox's 'pcie' nodes disabled via a "status=disabled" property. The
> > following patches fix this in the decompiled dtb outfiles:
> 
> I thought the wlan was attached to pcie but it seems it is
> actually an sdio device.
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-microsom.dtsi
> 
> /* USDHC1 - Connected to optional BRCM Wifi/BT/FM */
>  {
> pinctrl-names = "default";
> pinctrl-0 = <_microsom_brcm_wifi _microsom_usdhc1>;
> bus-width = <4>;
> mmc-pwrseq = <_pwrseq>;
> keep-power-in-suspend;
> no-1-8-v;
> non-removable;
> vmmc-supply = <_brcm>;
> status = "okay";
> };

WiFi over SDIO is quite common for these SoC-type systems.  The Bay
Trail-based ASUS EeeBook I have has a similar setup.  I suppose PCIe
sucks quite a bit of power even if you do proper link management.  I
actually believe that Broadcom's PCIe solutions are essentially SDIO
with a PCIe to SDIO bridge on front of them.

Time to investigate the

  sdmmc0: can't enable card

message I see on my CuBox-i4Pro once more.

Re: armv7/imx: imxpcie(4) driver & device tree problem

[Mark Kettenis]

> From: Ian Sutton 
> Date: Thu, 14 Jul 2016 03:20:34 -0400 (EDT)
> 
> I am working on a MD PCI-E driver for the armv7/imx platform.

Before you continue you should talk to patrick@.  I believe he had
some working code already.

Re: armv7/imx: imxpcie(4) driver & device tree problem

[Jonathan Gray]

On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote:
> I am working on a MD PCI-E driver for the armv7/imx platform. It
> attaches via FDT/simplebus, ascertaining its physical memory addresses
> from the fdt structure originating from the dtb files present on the
> msdos bootloader partition. The dtb files we're using now have the
> cubox's 'pcie' nodes disabled via a "status=disabled" property. The
> following patches fix this in the decompiled dtb outfiles:

I thought the wlan was attached to pcie but it seems it is
actually an sdio device.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-microsom.dtsi

/* USDHC1 - Connected to optional BRCM Wifi/BT/FM */
 {
pinctrl-names = "default";
pinctrl-0 = <_microsom_brcm_wifi _microsom_usdhc1>;
bus-width = <4>;
mmc-pwrseq = <_pwrseq>;
keep-power-in-suspend;
no-1-8-v;
non-removable;
vmmc-supply = <_brcm>;
status = "okay";
};

http://wiki.solid-run.com/doku.php?id=products:imx6:microsom:quad
Wifi: 802.1 b/g/n - 2.4 Ghz / Bluetooth: V 4.0 (BCM4330)

So it looks like there isn't anything attached to pcie.

armv7/imx: imxpcie(4) driver & device tree problem

[Ian Sutton]

I am working on a MD PCI-E driver for the armv7/imx platform. It
attaches via FDT/simplebus, ascertaining its physical memory addresses
from the fdt structure originating from the dtb files present on the
msdos bootloader partition. The dtb files we're using now have the
cubox's 'pcie' nodes disabled via a "status=disabled" property. The
following patches fix this in the decompiled dtb outfiles:

--- imx6q-cubox-i.dts   Thu Jul 14 01:26:57 2016
+++ imx6q-cubox-i.post.dts  Thu Jul 14 01:27:35 2016
@@ -212,7 +212,7 @@
phandle = <0x46>;
};
 
-   pcie@0x0100 {
+   pcie@0100 {
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
reg = <0x1ffc000 0x4000 0x1f0 0x8>;
reg-names = "dbi", "config";
@@ -228,7 +228,6 @@
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x7b 0x4 0x0 
0x0 0x0 0x2 0x1 0x0 0x7a 0x4 0x0 0x0 0x0 0x3 0x1 0x0 0x79 0x4 0x0 0x0 0x0 0x4 
0x1 0x0 0x78 0x4>;
clocks = <0x2 0x90 0x2 0xce 0x2 0xbd>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
-   status = "disabled";
};
 
pmu {

--- imx6dl-cubox-i.dts  Thu Jul 14 02:04:27 2016
+++ imx6dl-cubox-i.post.dts Thu Jul 14 02:05:04 2016
@@ -191,7 +191,7 @@
phandle = <0x36>;
};
 
-   pcie@0x0100 {
+   pcie@0100 {
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
reg = <0x1ffc000 0x4000 0x1f0 0x8>;
reg-names = "dbi", "config";
@@ -207,7 +207,6 @@
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x7b 0x4 0x0 
0x0 0x0 0x2 0x1 0x0 0x7a 0x4 0x0 0x0 0x0 0x3 0x1 0x0 0x79 0x4 0x0 0x0 0x0 0x4 
0x1 0x0 0x78 0x4>;
clocks = <0x2 0x90 0x2 0xce 0x2 0xbd>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
-   status = "disabled";
};
 
pmu {

Here are the resultant binaries you can copy to your bootloader
partition, for convenience:

http://ce.gl/imx6q-cubox-i.dtb
http://ce.gl/imx6dl-cubox-i.dtb

Replacing these dtbs indeed causes my _match() function to succeed where
it hadn't before.

Finally, here is the (very much in-progress) driver:

Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.31
diff -u -p -r1.31 GENERIC
--- sys/arch/armv7/conf/GENERIC 12 Jul 2016 19:17:49 -  1.31
+++ sys/arch/armv7/conf/GENERIC 14 Jul 2016 06:53:44 -
@@ -53,6 +53,7 @@ imxesdhc* at fdt? # SDHC controller
 sdmmc* at imxesdhc?# SD/MMC bus
 imxahci*   at fdt? # AHCI/SATA
 imxehci*   at fdt? # EHCI
+imxpcie*   at fdt? # PCI-E
 usb*   at imxehci?
 
 # OMAP3xxx/OMAP4xxx SoC
Index: sys/arch/armv7/imx/files.imx
===
RCS file: /cvs/src/sys/arch/armv7/imx/files.imx,v
retrieving revision 1.15
diff -u -p -r1.15 files.imx
--- sys/arch/armv7/imx/files.imx12 Jul 2016 19:17:49 -  1.15
+++ sys/arch/armv7/imx/files.imx14 Jul 2016 06:53:44 -
@@ -51,3 +51,7 @@ file  arch/armv7/imx/imxesdhc.c   imxesdhc
 device imxahci: scsi, atascsi
 attach imxahci at fdt
 file   arch/armv7/imx/imxahci.cimxahci
+
+device imxpcie
+attach imxpcie at fdt
+file   arch/armv7/imx/imxpcie.cimxpcie
Index: sys/arch/armv7/imx/imxpcie.c
===
RCS file: sys/arch/armv7/imx/imxpcie.c
diff -N sys/arch/armv7/imx/imxpcie.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/imx/imxpcie.c14 Jul 2016 06:53:44 -
@@ -0,0 +1,77 @@
+/*
+ * Copyright (c) 2016 Ian Sutton 
+ *
+ * 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 "imxpcievar.h"
+
+int  imxpcie_match(struct device *, void *, void *);
+void