Re: ksh tab completion bug
On Mon, Nov 09, 2020 at 11:15:36PM -0800, Michael Forney wrote: > I noticed some strange behavior of ksh in emacs mode when completing > file names that contain spaces (or other characters that need > escaping). > > To illustrate the problem, consider two files 'a b c test1' and > 'a b c test2'. ksh will correctly complete `a` and `a\ b\ c\ ` to > the common prefix `a\ b\ c\ test`. However, all of the following > do not get completed: > > * `a\ b\ c\ t` > * `a\ b\ c\ te` > * `a\ b\ c\ tes` > > I did some debugging, and I think this is due to emacs.c:do_complete() > using `end - start` for olen (which counts the backslashes), but > nlen (the longest prefix length) does not. So the completion only > occurs when the current word is shorter than the common prefix > length minus the number of backslashes in the word. > > I don't believe vi.c:complete_word() has this issue since it always > replaces the word with the longest prefix. > > I wrote a (only lightly tested) patch to make x_cf_glob return the > unescaped length as well as the start and end positions, and use > that for olen instead of `end - start`. This seems to fix the issue, > but it is longer than I had hoped. Perhaps there is a simpler patch > to make emacs.c:do_complete() use the same approach as vi completion. Been brought up before[1] and rejected[2][3]. [1] https://marc.info/?l=openbsd-bugs=149902839123905=2 [2] https://marc.info/?l=openbsd-bugs=149925960003395=2 [3] https://marc.info/?l=openbsd-bugs=149925991603581=2
ksh tab completion bug
I noticed some strange behavior of ksh in emacs mode when completing
file names that contain spaces (or other characters that need
escaping).
To illustrate the problem, consider two files 'a b c test1' and
'a b c test2'. ksh will correctly complete `a` and `a\ b\ c\ ` to
the common prefix `a\ b\ c\ test`. However, all of the following
do not get completed:
* `a\ b\ c\ t`
* `a\ b\ c\ te`
* `a\ b\ c\ tes`
I did some debugging, and I think this is due to emacs.c:do_complete()
using `end - start` for olen (which counts the backslashes), but
nlen (the longest prefix length) does not. So the completion only
occurs when the current word is shorter than the common prefix
length minus the number of backslashes in the word.
I don't believe vi.c:complete_word() has this issue since it always
replaces the word with the longest prefix.
I wrote a (only lightly tested) patch to make x_cf_glob return the
unescaped length as well as the start and end positions, and use
that for olen instead of `end - start`. This seems to fix the issue,
but it is longer than I had hoped. Perhaps there is a simpler patch
to make emacs.c:do_complete() use the same approach as vi completion.
diff --git a/bin/ksh/edit.c b/bin/ksh/edit.c
index 3089d195d20..d44afc258ba 100644
--- a/bin/ksh/edit.c
+++ b/bin/ksh/edit.c
@@ -29,7 +29,7 @@ static void check_sigwinch(void);
static int x_file_glob(int, const char *, int, char ***);
static int x_command_glob(int, const char *, int, char ***);
-static int x_locate_word(const char *, int, int, int *, int *);
+static int x_locate_word(const char *, int, int, int *, int *, int *);
/* Called from main */
@@ -524,15 +524,16 @@ x_command_glob(int flags, const char *str, int slen, char
***wordsp)
(c) == '`' || (c) == '=' || (c) == ':' )
static int
-x_locate_word(const char *buf, int buflen, int pos, int *startp,
+x_locate_word(const char *buf, int buflen, int pos, int *startp, int *endp,
int *is_commandp)
{
int p;
- int start, end;
+ int start, end, len;
/* Bad call? Probably should report error */
if (pos < 0 || pos > buflen) {
*startp = pos;
+ *endp = pos;
*is_commandp = 0;
return 0;
}
@@ -546,10 +547,13 @@ x_locate_word(const char *buf, int buflen, int pos, int
*startp,
(start > 1 && buf[start-2] == '\\'); start--)
;
/* Go forwards to end of word */
+ len = 0;
for (end = start; end < buflen && IS_WORDC(buf[end]); end++) {
if (buf[end] == '\\' && (end+1) < buflen)
end++;
+ len++;
}
+ *endp = end;
if (is_commandp) {
int iscmd;
@@ -574,7 +578,7 @@ x_locate_word(const char *buf, int buflen, int pos, int
*startp,
*startp = start;
- return end - start;
+ return len;
}
static int
@@ -654,14 +658,14 @@ x_try_array(const char *buf, int buflen, const char
*want, int wantlen,
int
x_cf_glob(int flags, const char *buf, int buflen, int pos, int *startp,
-int *endp, char ***wordsp, int *is_commandp)
+int *endp, int *lenp, char ***wordsp, int *is_commandp)
{
- int len;
+ int len, esclen;
int nwords;
char **words = NULL;
int is_command;
- len = x_locate_word(buf, buflen, pos, startp, _command);
+ len = x_locate_word(buf, buflen, pos, startp, endp, _command);
if (!(flags & XCF_COMMAND))
is_command = 0;
/* Don't do command globing on zero length strings - it takes too
@@ -671,10 +675,11 @@ x_cf_glob(int flags, const char *buf, int buflen, int
pos, int *startp,
if (len == 0 && is_command)
return 0;
+ esclen = *endp - *startp;
if (is_command)
- nwords = x_command_glob(flags, buf + *startp, len, );
- else if (!x_try_array(buf, buflen, buf + *startp, len, , ))
- nwords = x_file_glob(flags, buf + *startp, len, );
+ nwords = x_command_glob(flags, buf + *startp, esclen, );
+ else if (!x_try_array(buf, buflen, buf + *startp, esclen, ,
))
+ nwords = x_file_glob(flags, buf + *startp, esclen, );
if (nwords == 0) {
*wordsp = NULL;
return 0;
@@ -683,7 +688,7 @@ x_cf_glob(int flags, const char *buf, int buflen, int pos,
int *startp,
if (is_commandp)
*is_commandp = is_command;
*wordsp = words;
- *endp = *startp + len;
+ *lenp = len;
return nwords;
}
diff --git a/bin/ksh/edit.h b/bin/ksh/edit.h
index 0b604cd64fb..f988d92c4b2 100644
--- a/bin/ksh/edit.h
+++ b/bin/ksh/edit.h
@@ -43,7 +43,7 @@ bool x_mode(bool);
intpromptlen(const char *, const char **);
intx_do_comment(char *, int, int *);
void x_print_expansions(int, char *const *, int);
-intx_cf_glob(int, const char *, int, int, int
[PATCH] MacBookPro5,5 - onliner diff to swap 2 keys for ISO internal kbd
Hello, here a onliner diff against 6.8-current to swap two keys of a MacBook Pro internal keyboard (macbook5,5) at the right place. Thanks again ! Mathias mailto:s...@smat.ch Index: ukbd.c === RCS file: /cvs/src/sys/dev/usb/ukbd.c,v retrieving revision 1.81 diff -u -p -r1.81 ukbd.c --- ukbd.c 2 Nov 2020 19:45:18 - 1.81 +++ ukbd.c 9 Nov 2020 19:10:08 - @@ -258,6 +258,7 @@ ukbd_attach(struct device *parent, struc case USB_PRODUCT_APPLE_FOUNTAIN_ISO: case USB_PRODUCT_APPLE_GEYSER_ISO: case USB_PRODUCT_APPLE_GEYSER3_ISO: + case USB_PRODUCT_APPLE_WELLSPRING3_ISO: case USB_PRODUCT_APPLE_WELLSPRING6_ISO: case USB_PRODUCT_APPLE_WELLSPRING8_ISO: sc->sc_munge = ukbd_apple_iso_munge; <<>> OpenBSD 6.8-current (GENERIC.MP) #172: Sun Nov 8 14:01:38 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8278683648 (7895MB) avail mem = 8012484608 (7641MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (42 entries) bios0: vendor Apple Inc. version "MBP55.88Z.00AC.B03.0906151708" date 06/15/09 bios0: Apple Inc. MacBookPro5,5 acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT acpi0: wakeup devices ADP1(S3) LID0(S3) EC__(S3) OHC1(S3) EHC1(S3) OHC2(S3) EHC2(S3) GIGE(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2500 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz, 2521.10 MHz, 06-17-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 265MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz, 2520.67 MHz, 06-17-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-255 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (IXVE) acpisbs0 at acpi0: SBS0 model "bq20z451" serial 48 type LION oem "SMP" acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 abl0 at acpi0: PNLF (backlight) acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x0010 0x0011 0xmemory map conflict 0xffc0/0x40 asmc0 at acpi0: SMC_ (smc-mcp) addr 0x300/0x20: rev 1.47f547, 300 keys "ACPI0008" at acpi0 not configured "APP0003" at acpi0 not configured "ACPI0001" at acpi0 not configured acpicmos0 at acpi0 acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS cpu0: Enhanced SpeedStep 2521 MHz: speeds: 2527, 2394, 2128, 1862, 1596, 798 MHz pci0 at mainbus0 bus 0 0:3:5: mem address conflict 0xd340/0x8 pchb0 at pci0 dev 0 function 0 "NVIDIA MCP79 Host" rev 0xb1 "NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 0 function 1 not configured pcib0 at pci0 dev 3 function 0 "NVIDIA MCP79 ISA" rev 0xb3 "NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 3 function 1 not configured nviic0 at pci0 dev 3 function 2 "NVIDIA MCP79 SMBus" rev 0xb1 iic0 at nviic0 sdtemp0 at iic0 addr 0x18: stts2002 sdtemp1 at iic0 addr 0x19: stts2002 spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-8500 SO-DIMM with thermal sensor spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-8500 SO-DIMM with thermal sensor iic1 at nviic0 iic1: addr 0x2c 00=ff 02=08 03=f9 07=60 0d=6c 71=06 86=48 90=71 91=61 92=94 93=79 94=2a 95=3c 96=7a 97=91 9f=0c a0=3d a1=3d a2=3d a3=3d a4=3d a5=3d a6=3d a7=3d a8=3d a9=3d aa=3d ab=3d ac=3d ad=3d ae=7d af=3d b0=3d b1=3d b2=3d b3=3d b4=3d b5=3d b6=3d b7=3d b8=3d b9=3d ba=3d bb=3d bc=3d bd=3d be=2d bf=3d words 00=ff00 01=0008 02=08f9 03=f900 04= 05= 06=0060 07=6000 "NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 3 function 3 not configured vendor "NVIDIA", unknown product 0x0a98 (class memory subclass RAM, rev 0xb1) at pci0 dev 3 function 4
Update Windows getentropy implementation
This updates the getentropy implementation for Windows to use the newer
"Cryptography Next Generation APIs", replacing CryptGenRandom, which
already has been removed from applications built for the Windows Store.
Tested with libressl-portable, it passes all regression tests. Details
of the API are in the comment link below. Noted by Stephan Vedder
(feliwir on github) and others.
Any objections to gettin this in?
diff --git a/src/lib/libcrypto/arc4random/getentropy_win.c
b/src/lib/libcrypto/arc4random/getentropy_win.c
index 2abeb27bc..0a014f3b0 100644
--- a/src/lib/libcrypto/arc4random/getentropy_win.c
+++ b/src/lib/libcrypto/arc4random/getentropy_win.c
@@ -21,39 +21,30 @@
*/
#include
+#include
#include
#include
#include
-#include
-#include
intgetentropy(void *buf, size_t len);
/*
- * On Windows, CryptGenRandom is supposed to be a well-seeded
- * cryptographically strong random number generator.
+ * On Windows, BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is supposed
+ * to be a well-seeded, cryptographically strong random number generator.
+ *
https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom
*/
int
getentropy(void *buf, size_t len)
{
- HCRYPTPROV provider;
-
if (len > 256) {
errno = EIO;
return (-1);
}
- if (CryptAcquireContext(, NULL, NULL, PROV_RSA_FULL,
- CRYPT_VERIFYCONTEXT) == 0)
- goto fail;
- if (CryptGenRandom(provider, len, buf) == 0) {
- CryptReleaseContext(provider, 0);
- goto fail;
+ if (FAILED(BCryptGenRandom(NULL, buf, len,
BCRYPT_USE_SYSTEM_PREFERRED_RNG))) {
+ errno = EIO;
+ return (-1);
}
- CryptReleaseContext(provider, 0);
+
return (0);
-
-fail:
- errno = EIO;
- return (-1);
}
Re: Fw: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64 multiboot system
> Date: Mon, 9 Nov 2020 14:52:12 + > From: Stuart Henderson > > On 2020/11/09 15:28, Mark Kettenis wrote: > > > I think it would be correct to change our code to follow the spec, > > > but reading the manual of current versions of dmidecode it goes a bit > > > further; > > > > > > There is some ambiguity about how to interpret the UUID fields > > > prior to SMBIOS specification version 2.6. There was no mention > > > of byte swapping, and RFC 4122 says that no byte swapping should > > > be applied by default. However, SMBIOS specification version > > > 2.6 (and later) explicitly states that the first 3 fields of > > > the UUID should be read as little-endian numbers (byte-swapped). > > > Furthermore, it implies that the same was already true for older > > > versions of the specification, even though it was not mentioned. > > > In practice, many hardware vendors were not byte-swapping the > > > UUID. So, in order to preserve compatibility, it was decided > > > to interpret the UUID fields according to RFC 4122 (no byte > > > swapping) when the SMBIOS version is older than 2.6, and to > > > interpret the first 3 fields as little-endian (byte-swapped) > > > when the SMBIOS version is 2.6 or later. The Linux kernel follows > > > the same logic. > > > > > > It would seem sensible to follow that lead here I think? Diff for that > > > below. > > > > > > I don't think many people will be making existing use of hw.uuid but it > > > is possible, I don't think there's much we can do other than mention it > > > in upgrade notes. > > > > Given that explanation, I'd argue that we should leave things as-is. > > Folks interpreted the standard differently and in the end our > > interpretation won. Adding more code to "fix" this issue doesn't make > > Our interpretation only won for pre-2.6 SMBIOS versions.. > > > a lot of sense to me. Besides, where in the documentation is it > > spelled out that hw.uuid matches the SMBIOS UUID? > > I suppose this is true, it only says "The universal unique > identification number assigned to the machine". But we do also suggest > using it in pxeboot(8) and anyone doing this will need the id with the > standard interpretation. ok, fair enough, I don't really care all that much
Re: Fw: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64 multiboot system
On 2020/11/09 15:28, Mark Kettenis wrote: > > I think it would be correct to change our code to follow the spec, > > but reading the manual of current versions of dmidecode it goes a bit > > further; > > > > There is some ambiguity about how to interpret the UUID fields > > prior to SMBIOS specification version 2.6. There was no mention > > of byte swapping, and RFC 4122 says that no byte swapping should > > be applied by default. However, SMBIOS specification version > > 2.6 (and later) explicitly states that the first 3 fields of > > the UUID should be read as little-endian numbers (byte-swapped). > > Furthermore, it implies that the same was already true for older > > versions of the specification, even though it was not mentioned. > > In practice, many hardware vendors were not byte-swapping the > > UUID. So, in order to preserve compatibility, it was decided > > to interpret the UUID fields according to RFC 4122 (no byte > > swapping) when the SMBIOS version is older than 2.6, and to > > interpret the first 3 fields as little-endian (byte-swapped) > > when the SMBIOS version is 2.6 or later. The Linux kernel follows > > the same logic. > > > > It would seem sensible to follow that lead here I think? Diff for that > > below. > > > > I don't think many people will be making existing use of hw.uuid but it > > is possible, I don't think there's much we can do other than mention it > > in upgrade notes. > > Given that explanation, I'd argue that we should leave things as-is. > Folks interpreted the standard differently and in the end our > interpretation won. Adding more code to "fix" this issue doesn't make Our interpretation only won for pre-2.6 SMBIOS versions.. > a lot of sense to me. Besides, where in the documentation is it > spelled out that hw.uuid matches the SMBIOS UUID? I suppose this is true, it only says "The universal unique identification number assigned to the machine". But we do also suggest using it in pxeboot(8) and anyone doing this will need the id with the standard interpretation.
Re: Fw: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64 multiboot system
> Date: Mon, 9 Nov 2020 14:18:03 +
> From: Stuart Henderson
>
> On 2020/11/08 11:42, Benjamin Baier wrote:
> > Forwarding to tech@ by request from Stuart Henderson
> > This issue came up on misc@
> > https://marc.info/?l=openbsd-misc=160477082230840=2
> >
> > Begin forwarded message:
> >
> > Date: Sat, 7 Nov 2020 22:30:44 +0100
> > From: Benjamin Baier
> > To: Bruce Lilly
> > Cc: m...@openbsd.org
> > Subject: Re: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64
> > multiboot system
> >
> >
> > On Sat, 7 Nov 2020 12:36:42 -0500
> > Bruce Lilly wrote:
> >
> > > I have a multiboot system with several OSes on the same hardware.
> > >
> > > Summary: OpenBSD UUID reported by dmidecode and from sysctl differ
> > > significantly w.r.t. byte ordering. Multiple OSes report the same
> > > dmidecode
> > > UUID, and most other OSes provide one or more alternate ways of accessing
> > > the UUID which yields results consistent with dmidecode.
> > >
> > > Details:
> > > dmidecode (after fiddling with kern.allowkmem via /etc/sysctl.conf on
> > > OpenBSD)
> > > run on each OS that has a dmidecode utility reports the same hardware UUID
> > > (modulo hexadecimal digit case), viz.
> > >
> > > UUID: 484B1340-D7AA-81E5-3CED-9C5C8E3D6756
> > >
> > > OpenBSD (6.8) `sysctl hw.uuid` instead reports:
> > >
> > > hw.uuid=40134b48-aad7-e581-3ced-9c5c8e3d6756
> > >
> > > Note that the differences are:
> > > 1. case of hexadecimal digits (inconsequential)
> > > 2. byte ordering (but inconsistently so between the initial part
> > > and the last 64 bits (the latter part's byte ordering is consistent
> > > with dmidecode))
> > >
> > According to SMBIOS Reference Specification, you are correct.
> > 7.2.1
> > Although RFC 4122 recommends network byte order for all fields, the PC
> > industry (including the ACPI,
> > UEFI, and Microsoft specifications) has consistently used little-endian
> > byte encoding for the first three
> > fields: time_low, time_mid, time_hi_and_version. The same encoding, also
> > known as wire format, should
> > also be used for the SMBIOS representation of the UUID.
> > The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> > as:
> > 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
> >
> > What are the ramifications of a changed UUID?
> > What software depends on hw.uuid not changing?
> >
> > Greetings Ben
> >
> > ---
>
> I think it would be correct to change our code to follow the spec,
> but reading the manual of current versions of dmidecode it goes a bit
> further;
>
> There is some ambiguity about how to interpret the UUID fields
> prior to SMBIOS specification version 2.6. There was no mention
> of byte swapping, and RFC 4122 says that no byte swapping should
> be applied by default. However, SMBIOS specification version
> 2.6 (and later) explicitly states that the first 3 fields of
> the UUID should be read as little-endian numbers (byte-swapped).
> Furthermore, it implies that the same was already true for older
> versions of the specification, even though it was not mentioned.
> In practice, many hardware vendors were not byte-swapping the
> UUID. So, in order to preserve compatibility, it was decided
> to interpret the UUID fields according to RFC 4122 (no byte
> swapping) when the SMBIOS version is older than 2.6, and to
> interpret the first 3 fields as little-endian (byte-swapped)
> when the SMBIOS version is 2.6 or later. The Linux kernel follows
> the same logic.
>
> It would seem sensible to follow that lead here I think? Diff for that
> below.
>
> I don't think many people will be making existing use of hw.uuid but it
> is possible, I don't think there's much we can do other than mention it
> in upgrade notes.
Given that explanation, I'd argue that we should leave things as-is.
Folks interpreted the standard differently and in the end our
interpretation won. Adding more code to "fix" this issue doesn't make
a lot of sense to me. Besides, where in the documentation is it
spelled out that hw.uuid matches the SMBIOS UUID?
> Index: amd64/amd64/bios.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
> retrieving revision 1.43
> diff -u -p -u -2 -5 -r1.43 bios.c
> --- amd64/amd64/bios.c26 Aug 2020 03:29:05 - 1.43
> +++ amd64/amd64/bios.c9 Nov 2020 14:14:18 -
> @@ -476,30 +476,45 @@ smbios_info(char *str)
> strlcpy(hw_serial, sminfop, infolen);
> }
> if (smbios_entry.mjr > 2 || (smbios_entry.mjr == 2 &&
> smbios_entry.min >= 1)) {
> /*
>* If the uuid value is all 0xff the uuid is present but not
>* set, if its all 0 then the uuid isn't present at all.
>*/
> uuidf = SMBIOS_UUID_NPRESENT|SMBIOS_UUID_NSET;
> for (i = 0; i <
Re: Fw: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64 multiboot system
On 2020/11/08 11:42, Benjamin Baier wrote:
> Forwarding to tech@ by request from Stuart Henderson
> This issue came up on misc@
> https://marc.info/?l=openbsd-misc=160477082230840=2
>
> Begin forwarded message:
>
> Date: Sat, 7 Nov 2020 22:30:44 +0100
> From: Benjamin Baier
> To: Bruce Lilly
> Cc: m...@openbsd.org
> Subject: Re: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64
> multiboot system
>
>
> On Sat, 7 Nov 2020 12:36:42 -0500
> Bruce Lilly wrote:
>
> > I have a multiboot system with several OSes on the same hardware.
> >
> > Summary: OpenBSD UUID reported by dmidecode and from sysctl differ
> > significantly w.r.t. byte ordering. Multiple OSes report the same dmidecode
> > UUID, and most other OSes provide one or more alternate ways of accessing
> > the UUID which yields results consistent with dmidecode.
> >
> > Details:
> > dmidecode (after fiddling with kern.allowkmem via /etc/sysctl.conf on
> > OpenBSD)
> > run on each OS that has a dmidecode utility reports the same hardware UUID
> > (modulo hexadecimal digit case), viz.
> >
> > UUID: 484B1340-D7AA-81E5-3CED-9C5C8E3D6756
> >
> > OpenBSD (6.8) `sysctl hw.uuid` instead reports:
> >
> > hw.uuid=40134b48-aad7-e581-3ced-9c5c8e3d6756
> >
> > Note that the differences are:
> > 1. case of hexadecimal digits (inconsequential)
> > 2. byte ordering (but inconsistently so between the initial part
> > and the last 64 bits (the latter part's byte ordering is consistent
> > with dmidecode))
> >
> According to SMBIOS Reference Specification, you are correct.
> 7.2.1
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI,
> UEFI, and Microsoft specifications) has consistently used little-endian
> byte encoding for the first three
> fields: time_low, time_mid, time_hi_and_version. The same encoding, also
> known as wire format, should
> also be used for the SMBIOS representation of the UUID.
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as:
> 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
>
> What are the ramifications of a changed UUID?
> What software depends on hw.uuid not changing?
>
> Greetings Ben
>
> ---
I think it would be correct to change our code to follow the spec,
but reading the manual of current versions of dmidecode it goes a bit
further;
There is some ambiguity about how to interpret the UUID fields
prior to SMBIOS specification version 2.6. There was no mention
of byte swapping, and RFC 4122 says that no byte swapping should
be applied by default. However, SMBIOS specification version
2.6 (and later) explicitly states that the first 3 fields of
the UUID should be read as little-endian numbers (byte-swapped).
Furthermore, it implies that the same was already true for older
versions of the specification, even though it was not mentioned.
In practice, many hardware vendors were not byte-swapping the
UUID. So, in order to preserve compatibility, it was decided
to interpret the UUID fields according to RFC 4122 (no byte
swapping) when the SMBIOS version is older than 2.6, and to
interpret the first 3 fields as little-endian (byte-swapped)
when the SMBIOS version is 2.6 or later. The Linux kernel follows
the same logic.
It would seem sensible to follow that lead here I think? Diff for that
below.
I don't think many people will be making existing use of hw.uuid but it
is possible, I don't think there's much we can do other than mention it
in upgrade notes.
Index: amd64/amd64/bios.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
retrieving revision 1.43
diff -u -p -u -2 -5 -r1.43 bios.c
--- amd64/amd64/bios.c 26 Aug 2020 03:29:05 - 1.43
+++ amd64/amd64/bios.c 9 Nov 2020 14:14:18 -
@@ -476,30 +476,45 @@ smbios_info(char *str)
strlcpy(hw_serial, sminfop, infolen);
}
if (smbios_entry.mjr > 2 || (smbios_entry.mjr == 2 &&
smbios_entry.min >= 1)) {
/*
* If the uuid value is all 0xff the uuid is present but not
* set, if its all 0 then the uuid isn't present at all.
*/
uuidf = SMBIOS_UUID_NPRESENT|SMBIOS_UUID_NSET;
for (i = 0; i < sizeof(sys->uuid); i++) {
if (sys->uuid[i] != 0xff)
uuidf &= ~SMBIOS_UUID_NSET;
if (sys->uuid[i] != 0)
uuidf &= ~SMBIOS_UUID_NPRESENT;
}
if (uuidf & SMBIOS_UUID_NPRESENT)
hw_uuid = NULL;
else if (uuidf & SMBIOS_UUID_NSET)
hw_uuid = "Not Set";
else {
for (i = 0; i < sizeof(sys->uuid); i++)
pchgpio(4)
Here is the diff for the driver that James Hastings and I wrote to
support GPIO interrupts on the Intel 400-series integrated PCH. This
should help with (for example) the touchpad on the latest Lenovo X1.
The idea is that the driver will be extended in the future to support
other PCH variants as-needed. In fact I removed the Intel 100-series
support in this initial diff since it needs to be properly tested
first.
ok?
Index: arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.494
diff -u -p -r1.494 GENERIC
--- arch/amd64/conf/GENERIC 27 Oct 2020 02:39:07 - 1.494
+++ arch/amd64/conf/GENERIC 9 Nov 2020 12:01:05 -
@@ -66,6 +66,7 @@ aplgpio* at acpi?
bytgpio* at acpi?
chvgpio* at acpi?
glkgpio* at acpi?
+pchgpio* at acpi?
sdhc* at acpi?
acpicbkbd* at acpi?
acpials* at acpi?
Index: dev/acpi/files.acpi
===
RCS file: /cvs/src/sys/dev/acpi/files.acpi,v
retrieving revision 1.58
diff -u -p -r1.58 files.acpi
--- dev/acpi/files.acpi 27 Oct 2020 02:39:07 - 1.58
+++ dev/acpi/files.acpi 9 Nov 2020 12:01:06 -
@@ -151,6 +151,11 @@ device glkgpio
attach glkgpio at acpi
file dev/acpi/glkgpio.c glkgpio
+# Intel PCH GPIO
+device pchgpio
+attach pchgpio at acpi
+file dev/acpi/pchgpio.c pchgpio
+
# "Intel" Dollar Cove TI PMIC
device tipmic
attach tipmic at i2c
Index: dev/acpi/pchgpio.c
===
RCS file: dev/acpi/pchgpio.c
diff -N dev/acpi/pchgpio.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/acpi/pchgpio.c 9 Nov 2020 12:01:06 -
@@ -0,0 +1,363 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2020 Mark Kettenis
+ * Copyright (c) 2020 James Hastings
+ *
+ * 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
+
+#define PCHGPIO_MAXCOM 4
+
+#define PCHGPIO_CONF_TXSTATE 0x0001
+#define PCHGPIO_CONF_RXSTATE 0x0002
+#define PCHGPIO_CONF_RXINV 0x0080
+#define PCHGPIO_CONF_RXEV_EDGE 0x0200
+#define PCHGPIO_CONF_RXEV_ZERO 0x0400
+#define PCHGPIO_CONF_RXEV_MASK 0x0600
+
+#define PCHGPIO_PADBAR 0x00c
+
+struct pchgpio_group {
+ uint8_t bar;
+ uint8_t bank;
+ uint16_tbase;
+ uint16_tlimit;
+ uint16_toffset;
+ int16_t gpiobase;
+};
+
+struct pchgpio_device {
+ uint16_tpad_size;
+ uint16_tgpi_is;
+ uint16_tgpi_ie;
+ struct pchgpio_group *groups;
+ int ngroups;
+ int npins;
+};
+
+struct pchgpio_match {
+ const char *hid;
+ struct pchgpio_device *device;
+};
+
+struct pchgpio_intrhand {
+ int (*ih_func)(void *);
+ void *ih_arg;
+};
+
+struct pchgpio_softc {
+ struct device sc_dev;
+ struct acpi_softc *sc_acpi;
+ struct aml_node *sc_node;
+
+ bus_space_tag_t sc_memt[PCHGPIO_MAXCOM];
+ bus_space_handle_t sc_memh[PCHGPIO_MAXCOM];
+ void *sc_ih;
+ int sc_naddr;
+
+ struct pchgpio_device *sc_device;
+ uint16_t sc_padbar[PCHGPIO_MAXCOM];
+ int sc_padsize;
+
+ int sc_npins;
+ struct pchgpio_intrhand *sc_pin_ih;
+
+ struct acpi_gpio sc_gpio;
+};
+
+intpchgpio_match(struct device *, void *, void *);
+void pchgpio_attach(struct device *, struct device *, void *);
+
+struct cfattach pchgpio_ca = {
+ sizeof(struct pchgpio_softc), pchgpio_match, pchgpio_attach
+};
+
+struct cfdriver pchgpio_cd = {
+ NULL, "pchgpio", DV_DULL
+};
+
+const char *pchgpio_hids[] = {
+ "INT34BB",
+ NULL
+};
+
+struct pchgpio_group cnl_lp_groups[] =
+{
+ /* Community 0 */
+ { 0, 0, 0, 24, 0, 0 }, /* GPP_A */
+ { 0, 1, 25, 50, 25, 32 }, /* GPP_B */
+ { 0, 2, 51, 58, 51, 64 }, /* GPP_G */
+
+ /* Community 1 */
+ { 1, 0, 68, 92, 0, 96 },/* GPP_D */
+ { 1, 1, 93, 116, 24, 128 }, /* GPP_F */
+ { 1, 2, 117, 140, 48, 160 },
bgpd pftable change
Hi bgpd and esp. bgpd-spamd users,
Currently the pftable code does not keep track how often a prefix was
added to a pftable. Because of this using the same pftable for multiple
neighbor tables does not work well. If one neighbor withdraws a route the
pftable entry is removed from the table no matter if the prefix is still
available from the other neighbor.
This diff changes this behaviour and introduces proper reference counting.
A pftable entry will now remain in the table until the last neighbor
withdraws the prefix. This makes much more sense and should not break
working setups. It will fix configs where more than one neighbor feeds
into the bgpd pftable.
As a side-effect bgpd will no commit pftable updates on a more regular
basis and not wait until some operations (full table walk) finished. This
should result in better responsiveness of updates.
Please test :)
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.506
diff -u -p -r1.506 rde.c
--- rde.c 5 Nov 2020 14:44:59 - 1.506
+++ rde.c 9 Nov 2020 10:06:51 -
@@ -69,6 +69,7 @@ void rde_dump_ctx_terminate(pid_t);
voidrde_dump_mrt_new(struct mrt *, pid_t, int);
int rde_l3vpn_import(struct rde_community *, struct l3vpn *);
+static void rde_commit_pftable(void);
voidrde_reload_done(void);
static void rde_softreconfig_in_done(void *, u_int8_t);
static void rde_softreconfig_out_done(void *, u_int8_t);
@@ -296,6 +297,8 @@ rde_main(int debug, int verbose)
for (aid = AID_INET6; aid < AID_MAX; aid++)
rde_update6_queue_runner(aid);
}
+ /* commit pftable once per poll loop */
+ rde_commit_pftable();
}
/* do not clean up on shutdown on production, it takes ages. */
@@ -497,8 +500,6 @@ badnetdel:
RDE_RUNNER_ROUNDS, peerself, network_flush_upcall,
NULL, NULL) == -1)
log_warn("rde_dispatch: IMSG_NETWORK_FLUSH");
- /* Deletions were performed in network_flush_upcall */
- rde_send_pftable_commit();
break;
case IMSG_FILTER_SET:
if (imsg.hdr.len - IMSG_HEADER_SIZE !=
@@ -1389,7 +1390,6 @@ rde_update_dispatch(struct rde_peer *pee
done:
rde_filterstate_clean();
- rde_send_pftable_commit();
}
int
@@ -2950,10 +2950,31 @@ rde_update6_queue_runner(u_int8_t aid)
/*
* pf table specific functions
*/
+struct rde_pftable_node {
+ RB_ENTRY(rde_pftable_node) entry;
+ struct pt_entry *prefix;
+ int refcnt;
+ u_int16_tid;
+};
+RB_HEAD(rde_pftable_tree, rde_pftable_node);
+
+static inline int
+rde_pftable_cmp(struct rde_pftable_node *a, struct rde_pftable_node *b)
+{
+ if (a->prefix > b->prefix)
+ return 1;
+ if (a->prefix < b->prefix)
+ return -1;
+ return (a->id - b->id);
+}
+
+RB_GENERATE_STATIC(rde_pftable_tree, rde_pftable_node, entry, rde_pftable_cmp);
+
+struct rde_pftable_tree pftable_tree = RB_INITIALIZER(_tree);
int need_commit;
-void
-rde_send_pftable(u_int16_t id, struct bgpd_addr *addr,
-u_int8_t len, int del)
+
+static void
+rde_pftable_send(u_int16_t id, struct pt_entry *pt, int del)
{
struct pftable_msg pfm;
@@ -2966,8 +2987,8 @@ rde_send_pftable(u_int16_t id, struct bg
bzero(, sizeof(pfm));
strlcpy(pfm.pftable, pftable_id2name(id), sizeof(pfm.pftable));
- memcpy(, addr, sizeof(pfm.addr));
- pfm.len = len;
+ pt_getaddr(pt, );
+ pfm.len = pt->prefixlen;
if (imsg_compose(ibuf_main,
del ? IMSG_PFTABLE_REMOVE : IMSG_PFTABLE_ADD,
@@ -2978,7 +2999,55 @@ rde_send_pftable(u_int16_t id, struct bg
}
void
-rde_send_pftable_commit(void)
+rde_pftable_add(u_int16_t id, struct prefix *p)
+{
+ struct rde_pftable_node *pfn, node;
+
+ memset(, 0, sizeof(node));
+ node.prefix = p->pt;
+ node.id = id;
+
+ pfn = RB_FIND(rde_pftable_tree, _tree, );
+ if (pfn == NULL) {
+ if ((pfn = calloc(1, sizeof(*pfn))) == NULL)
+ fatal("%s", __func__);
+ pfn->prefix = pt_ref(p->pt);
+ pfn->id = id;
+
+ if (RB_INSERT(rde_pftable_tree, _tree, pfn) != NULL)
+ fatalx("%s: tree corrupt", __func__);
+
+ rde_pftable_send(id, p->pt, 0);
+ }
+ pfn->refcnt++;
+}
+
+void
+rde_pftable_del(u_int16_t id, struct prefix *p)
+{
+ struct rde_pftable_node *pfn, node;
+
+ memset(, 0, sizeof(node));
+ node.prefix = p->pt;
+ node.id = id;
+
+ pfn = RB_FIND(rde_pftable_tree, _tree,
