Recognize Kingston KC3000 NVME SSD
I put a Kingston KC3000 NVME SSD[1] in my new machine. This diff recognizes that device: Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2026 diff -u -p -r1.2026 pcidevs --- pcidevs 19 Mar 2023 09:38:06 - 1.2026 +++ pcidevs 19 Mar 2023 16:08:11 - @@ -7010,6 +7010,7 @@ product JMICRON XD_2 0x2394 xD /* Kingston */ product KINGSTON A2000 0x2263 A2000 +product KINGSTON KC30000x5013 KC3000 product KINGSTON NV2 0x5019 NV2 /* Kioxia */ dmesg goes from: nvme0 at pci15 dev 0 function 0 vendor "Kingston", unknown product 0x5013 rev 0x01: msix, NVMe 1.4 nvme0: KINGSTON SKC3000D2048G, firmware EIFK31.6, serial 50026B76863F2586 scsibus1 at nvme0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: sd0: 1953514MB, 512 bytes/sector, 4000797360 sectors to: nvme0 at pci15 dev 0 function 0 "Kingston KC3000" rev 0x01: msix, NVMe 1.4 nvme0: KINGSTON SKC3000D2048G, firmware EIFK31.6, serial 50026B76863F2586 scsibus1 at nvme0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: sd0: 1953514MB, 512 bytes/sector, 4000797360 sectors It already works fine, so I'm not sure it's worth the extra bytes added to the kernel. Paul [1]: https://www.kingston.com/en/ssd/kc3000-nvme-m2-solid-state-drive -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: smtpd: simplify token name extraction for %{name}
On 2023/03/19 08:11:27 -0600, Todd C. Miller wrote:
> The current code for extracting the token name from %{name} can be
> simplified by computing the token name length. The existing code
> copies "name}" to token[] using memcpy(), then strchr() to find the
> '}' and replace it with a NUL. Using strchr() here is fragile since
> token[] is not yet NUL-terminated. This is currently not a problem
> since there is an earlier check for '}' in the source string but
> it could be dangerous is the code changes further.
>
> I find it much simpler to compute the token name length, verify the
> length, copy the bytes and then explicitly NUL-terminate token.
> This results in less code and is more easily audited.
Agreed, I find it simpler too, and less fragile.
> I've also removed the duplicate check for *(pbuf+1) != '{'.
>
> OK?
(while I still have the details fresh in my mind) ok for me
add Aquantia AQC113CS to pcidevs
My new motherboard has a 10GB/s interface that doesn't work with
-current. It's this thing:
--- pcidump -v 7:0:0 -
7:0:0: Aquantia unknown
0x: Vendor ID: 1d6a, Product ID: 94c0
0x0004: Command: 0006, Status: 0010
0x0008: Class: 02 Network, Subclass: 00 Ethernet,
Interface: 00, Revision: 03
0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
Cache Line Size: 10
0x0010: BAR mem 64bit addr: 0xeb80/0x0008
0x0018: BAR mem 64bit addr: 0xeb8a/0x1000
0x0020: BAR mem 64bit addr: 0xeb40/0x0040
0x0028: Cardbus CIS:
0x002c: Subsystem Vendor ID: 1043 Product ID: 87f5
0x0030: Expansion ROM Base Address: eb88
0x0038:
0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
0x0040: Capability 0x01: Power Management
State: D0
0x0050: Capability 0x05: Message Signalled Interrupts (MSI)
Enabled: no
0x0070: Capability 0x10: PCI Express
Max Payload Size: 128 / 512 bytes
Max Read Request Size: 512 bytes
Link Speed: 8.0 / 8.0 GT/s
Link Width: x1 / x2
0x0100: Enhanced Capability 0x01: Advanced Error Reporting
0x0148: Enhanced Capability 0x02: Virtual Channel Capability
0x0168: Enhanced Capability 0x03: Device Serial Number
Serial Number:
0x0178: Enhanced Capability 0x19: Secondary PCIe Capability
0x0198: Enhanced Capability 0x26: Physical Layer 16.0 GT/s
0x01bc: Enhanced Capability 0x27: Lane Margining at the Receiver
0x01d4: Enhanced Capability 0x18: Latency Tolerance Reporting
0x01dc: Enhanced Capability 0x1e: L1 PM
0x01ec: Enhanced Capability 0x0b: Vendor-Specific
0x02ec: Enhanced Capability 0x25: Data Link Feature
0x02f8: Enhanced Capability 0x1f: Precision Time Measurement
0x0304: Enhanced Capability 0x0b: Vendor-Specific
0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
Enabled: yes; table size 32 (BAR 2:0)
--
Some googling led me to this page which suggests it's AQC113CS:
https://devicehunt.com/view/type/pci/vendor/1D6A/device/94C0
So, this adds Aquantia AQC113CS to pcidevs:
Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2026
diff -u -p -r1.2026 pcidevs
--- pcidevs 19 Mar 2023 09:38:06 - 1.2026
+++ pcidevs 19 Mar 2023 14:31:30 -
@@ -1134,6 +1134,7 @@ product AQUANTIA AQC108S 0x88b1 AQC108S
product AQUANTIA AQC109S 0x89b1 AQC109S
product AQUANTIA AQC111S 0x91b1 AQC111S
product AQUANTIA AQC112S 0x92b1 AQC112S
+product AQUANTIA AQC113CS 0x94c0 AQC113CS
product AQUANTIA D100 0xd100 D100
product AQUANTIA D107 0xd107 D107
product AQUANTIA D108 0xd108 D108
It doesn't work yet though:
Index: if_aq_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_aq_pci.c,v
retrieving revision 1.17
diff -u -p -r1.17 if_aq_pci.c
--- if_aq_pci.c 25 May 2022 09:49:17 - 1.17
+++ if_aq_pci.c 19 Mar 2023 14:32:51 -
@@ -798,6 +798,7 @@ const struct pci_matchid aq_devices[] =
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC109S },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC111S },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC112S },
+ { PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC113CS },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_D100 },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_D107 },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_D108 },
results in:
aq0 at pci7 dev 0 function 0 "Aquantia AQC113CS" rev 0x03: msix, 8 queuesaq0:
FLB> MAC kickstart failed: timed out
aq0: MAC reset failed: 60
And subsequently no interface is available to the OS after system
start up, so obviously more is needed.
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
smtpd: simplify token name extraction for %{name}
The current code for extracting the token name from %{name} can be
simplified by computing the token name length. The existing code
copies "name}" to token[] using memcpy(), then strchr() to find the
'}' and replace it with a NUL. Using strchr() here is fragile since
token[] is not yet NUL-terminated. This is currently not a problem
since there is an earlier check for '}' in the source string but
it could be dangerous is the code changes further.
I find it much simpler to compute the token name length, verify the
length, copy the bytes and then explicitly NUL-terminate token.
This results in less code and is more easily audited.
I've also removed the duplicate check for *(pbuf+1) != '{'.
OK?
- todd
Index: usr.sbin/smtpd/mda_variables.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mda_variables.c,v
retrieving revision 1.8
diff -u -p -U10 -u -r1.8 mda_variables.c
--- usr.sbin/smtpd/mda_variables.c 19 Mar 2023 01:43:11 - 1.8
+++ usr.sbin/smtpd/mda_variables.c 19 Mar 2023 13:59:01 -
@@ -236,21 +236,21 @@ mda_expand_token(char *dest, size_t len,
ssize_t
mda_expand_format(char *buf, size_t len, const struct deliver *dlv,
const struct userinfo *ui, const char *mda_command)
{
chartmpbuf[EXPAND_BUFFER], *ptmp, *pbuf, *ebuf;
charexptok[EXPAND_BUFFER];
ssize_t exptoklen;
chartoken[MAXTOKENLEN];
- size_t ret, tmpret;
+ size_t ret, tmpret, toklen;
if (len < sizeof tmpbuf) {
log_warnx("mda_expand_format: tmp buffer < rule buffer");
return -1;
}
memset(tmpbuf, 0, sizeof tmpbuf);
pbuf = buf;
ptmp = tmpbuf;
ret = tmpret = 0;
@@ -261,48 +261,46 @@ mda_expand_format(char *buf, size_t len,
if (tmpret >= sizeof tmpbuf) {
log_warnx("warn: user directory for %s too large",
ui->directory);
return 0;
}
ret += tmpret;
ptmp += tmpret;
pbuf += 2;
}
-
/* expansion loop */
for (; *pbuf && ret < sizeof tmpbuf; ret += tmpret) {
if (*pbuf == '%' && *(pbuf + 1) == '%') {
*ptmp++ = *pbuf++;
pbuf += 1;
tmpret = 1;
continue;
}
if (*pbuf != '%' || *(pbuf + 1) != '{') {
*ptmp++ = *pbuf++;
tmpret = 1;
continue;
}
/* %{...} otherwise fail */
- if (*(pbuf+1) != '{' || (ebuf = strchr(pbuf+1, '}')) == NULL)
+ if ((ebuf = strchr(pbuf+2, '}')) == NULL)
return 0;
/* extract token from %{token} */
- if ((size_t)(ebuf - pbuf) - 1 >= sizeof token)
+ toklen = ebuf - (pbuf+2);
+ if (toklen >= sizeof token)
return 0;
- memcpy(token, pbuf+2, ebuf-pbuf-1);
- if (strchr(token, '}') == NULL)
- return 0;
- *strchr(token, '}') = '\0';
+ memcpy(token, pbuf+2, toklen);
+ token[toklen] = '\0';
exptoklen = mda_expand_token(exptok, sizeof exptok, token, dlv,
ui, mda_command);
if (exptoklen == -1)
return -1;
/* writing expanded token at ptmp will overflow tmpbuf */
if (sizeof (tmpbuf) - (ptmp - tmpbuf) <= (size_t)exptoklen)
return -1;
rpki-client 8.3 released
rpki-client 8.3 has just been released and will be available in the
rpki-client directory of any OpenBSD mirror soon.
rpki-client is a FREE, easy-to-use implementation of the Resource
Public Key Infrastructure (RPKI) for Relying Parties (RP) to
facilitate validation of BGP announcements. The program queries the
global RPKI repository system and validates untrusted network inputs.
The program outputs validated ROA payloads, BGPsec Router keys, and
ASPA payloads in configuration formats suitable for OpenBGPD and BIRD,
and supports emitting CSV and JSON for consumption by other routing
stacks.
See RFC 6480 and RFC 6811 for a description of how RPKI and BGP Prefix
Origin Validation help secure the global Internet routing system.
rpki-client was primarily developed by Kristaps Dzonsons, Claudio
Jeker, Job Snijders, Theo Buehler, Theo de Raadt and Sebastian Benoit
as part of the OpenBSD Project.
This release includes the following changes to the previous release:
- The 'expires' key in the JSON/CSV/OpenBGPD output formats is now
calculated with more accuracy. The calculation takes into account the
nextUpdate value of all intermediate CRLs in the signature path
towards the trust anchor, in addition to the expiry moment of the
leaf-CRL and CAs.
- Handling of CRLs and Manifests in the face of inconsistent RRDP delta
publications has been improved. A copy of an alternative version of
the applicable CRL is kept in the staging area of the cache directory,
in order to increase the potential for establishing a complete
publication point, in cases where a single publication point update
was smeared across multiple RRDP delta files.
- The OpenBGPD configuration output now includes validated Autonomous
System Provider Authorization (ASPA) payloads as an 'aspa-set {}'
configuration block.
- When rpki-client is invoked with increased verbosity ('-v'), the
current RRDP Serial & Session ID are shown to aid debugging.
- Self-signed X.509 certificates (such as Trust Anchor certificates)
now are considered invalid if they contain an X.509
AuthorityInfoAccess extension.
- Signed Objects where the CMS signing-time attribute contains a
timestamp later then the X.509 certificate's notAfter timestamp are
considered invalid.
- Manifests where the CMS signing-time attribute contains a timestamp
later then the Manifest eContent nextUpdate timestamp are considered
invalid.
- Any objects whose CRL Distribution Points extension contains a
CRLIssuer, CRL Reasons, or nameRelativeToCRLIssuer field are
considered invalid in accordance with RFC 6487 section 4.8.6.
- For every X.509 certificate the SHA-1 of the Subject Public Key is
calculated and compared to the Subject Key Identifier (SKI), if a
mismatch is found the certificate is not trusted.
- Require the outside-TBS signature OID for every X.509 intermediate
CA certificate and CRL to be sha256WithRSAEncryption.
- Require the RSA key pair modulus and public exponent parameters to
strictly conform to the RFC 7935 profile.
- Ensure there is no trailing garbage present in Signed Objects beyond
the self-embedded length field.
- Require RRDP Session IDs to strictly be version 4 UUIDs.
- When decoding and validating an individual RPKI file using filemode
(rpki-client -f file), display the signature path towards the trust
anchor, and the timestamp when the signature path will expire.
- When decoding and validating an individual RPKI file using filemode
(rpki-client -f file), display the optional CMS signing-time, and
non-optional X.509 notBefore, and X.509 notAfter timestamps.
rpki-client works on all operating systems with a libcrypto library
based on OpenSSL 1.1 or LibreSSL 3.5, and a libtls library compatible
with LibreSSL 3.5 or later.
rpki-client is known to compile and run on at least the following
operating systems: Alpine, CentOS, Debian, Fedora, FreeBSD, Red Hat,
Rocky, Ubuntu, macOS, and of course OpenBSD!
It is our hope that packagers take interest and help adapt
rpki-client-portable to more distributions.
The mirrors where rpki-client can be found are on
https://www.rpki-client.org/portable.html
Reporting Bugs:
===
General bugs may be reported to tech@openbsd.org
Portable bugs may be filed at
https://github.com/rpki-client/rpki-client-portable
We welcome feedback and improvements from the broader community.
Thanks to all of the contributors who helped make this release
possible.
Assistance to coordinate security issues is available via
secur...@openbsd.org.
