Re: Dell R7615 kernel protection fault
On 11.9.2023. 2:48, Mike Larkin wrote: > On Sun, Sep 10, 2023 at 01:36:33AM +0200, Hrvoje Popovski wrote: >> Hi all, >> >> I've installed latest snapshot with uefi on Dell R7615 with AMD EPYC >> 9554P, with some NVMe disks on BOSS-N1 adapter and with Samsung NVMe >> disks directly connected to backplane and installation was fast and >> without any problems. >> But after that machine panics with this message >> https://kosjenka.srce.hr/~hrvoje/openbsd/r7615-ddb1.jpg >> > > did it work before on an older snapshot? > this is brand new machine and I installed latest snapshot. will try older snapshot now ...
rpki-client: ensure X.509 Subject only contains commonName and serialNumber
This adds another compliance check for the X.509 subject name.
Only commonName, and optionally serialNumber, are permitted in the
certificate subject name. See RFC 6487 section 4.4 and 4.5.
It seems the one CA who was not compliant with this requirement got
their act together, so now is an opportune time to get this in.
OK?
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.114
diff -u -p -r1.114 cert.c
--- cert.c 29 Jun 2023 10:28:25 - 1.114
+++ cert.c 9 Jul 2023 13:38:02 -
@@ -595,14 +595,13 @@ certificate_policies(struct parse *p, X5
/*
* Lightweight version of cert_parse_pre() for ASPA, ROA, and RSC EE certs.
- * This only parses the RFC 3779 extensions since these are necessary for
- * validation.
* Returns cert on success and NULL on failure.
*/
struct cert *
cert_parse_ee_cert(const char *fn, X509 *x)
{
struct parse p;
+ X509_NAME *xn;
X509_EXTENSION *ext;
int index;
@@ -616,6 +615,13 @@ cert_parse_ee_cert(const char *fn, X509
goto out;
}
+ if ((xn = X509_get_subject_name(x)) == NULL) {
+ warnx("%s: X509_get_subject_name", fn);
+ goto out;
+ }
+ if (!x509_valid_subject(fn, xn))
+ goto out;
+
if (X509_get_key_usage(x) != KU_DIGITAL_SIGNATURE) {
warnx("%s: RFC 6487 section 4.8.4: KU must be digitalSignature",
fn);
@@ -669,6 +675,7 @@ cert_parse_pre(const char *fn, const uns
const X509_ALGOR*palg;
const ASN1_BIT_STRING *piuid = NULL, *psuid = NULL;
const ASN1_OBJECT *cobj;
+ const X509_NAME *xn;
ASN1_OBJECT *obj;
EVP_PKEY*pkey;
struct parse p;
@@ -726,6 +733,13 @@ cert_parse_pre(const char *fn, const uns
fn);
goto out;
}
+
+ if ((xn = X509_get_subject_name(x)) == NULL) {
+ warnx("%s: X509_get_subject_name", p.fn);
+ goto out;
+ }
+ if (!x509_valid_subject(p.fn, xn))
+ goto out;
/* Look for X509v3 extensions. */
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.188
diff -u -p -r1.188 extern.h
--- extern.h29 Jun 2023 14:33:35 - 1.188
+++ extern.h9 Jul 2023 13:38:02 -
@@ -839,6 +839,7 @@ int x509_location(const char *, const
GENERAL_NAME *, char **);
int x509_inherits(X509 *);
int x509_any_inherits(X509 *);
+int x509_valid_subject(const char *, const X509_NAME *);
time_t x509_find_expires(time_t, struct auth *, struct crl_tree *);
/* printers */
Index: x509.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/x509.c,v
retrieving revision 1.73
diff -u -p -r1.73 x509.c
--- x509.c 23 Jun 2023 15:32:15 - 1.73
+++ x509.c 9 Jul 2023 13:38:02 -
@@ -861,6 +861,80 @@ x509_location(const char *fn, const char
}
/*
+ * Check that the subject only contains commonName and serialNumber.
+ * Return 0 on failure.
+ */
+int
+x509_valid_subject(const char *fn, const X509_NAME *xn)
+{
+ X509_NAME_ENTRY *ne;
+ ASN1_OBJECT *ao;
+ ASN1_STRING *as;
+ int cn = 0, sn = 0;
+ int i, nid;
+
+ for (i = 0; i < X509_NAME_entry_count(xn); i++) {
+ if ((ne = X509_NAME_get_entry(xn, i)) == NULL) {
+ warnx("%s: X509_NAME_get_entry", fn);
+ return 0;
+ }
+ if ((ao = X509_NAME_ENTRY_get_object(ne)) == NULL) {
+ warnx("%s: X509_NAME_ENTRY_get_object", fn);
+ return 0;
+ }
+
+ nid = OBJ_obj2nid(ao);
+ switch (nid) {
+ case NID_commonName:
+ if (cn++ > 0) {
+ warnx("%s: duplicate commonName in subject",
+ fn);
+ return 0;
+ }
+ if ((as = X509_NAME_ENTRY_get_data(ne)) == NULL) {
+ warnx("%s: X509_NAME_ENTRY_get_data failed",
+ fn);
+ return 0;
+ }
+/*
+ * The following check can be enabled after AFRINIC re-issues CA certs.
+ * https://lists.afrinic.net/pipermail/dbwg/2023-March/000436.html
+ */
+#if 0
+ if (as->type != V_ASN1_PRINTABLESTRING) {
+ warnx("%s: RFC 6487 section 4.5: commonName is"
+ " not
Re: Dell R7615 kernel protection fault
On Sun, Sep 10, 2023 at 01:36:33AM +0200, Hrvoje Popovski wrote: > Hi all, > > I've installed latest snapshot with uefi on Dell R7615 with AMD EPYC > 9554P, with some NVMe disks on BOSS-N1 adapter and with Samsung NVMe > disks directly connected to backplane and installation was fast and > without any problems. > But after that machine panics with this message > https://kosjenka.srce.hr/~hrvoje/openbsd/r7615-ddb1.jpg > did it work before on an older snapshot? > I can't do anything with keyboard and I've tried over ipmi console but I > can't get it to work. > > > BOSS-N1 is in raid1 > https://kosjenka.srce.hr/~hrvoje/openbsd/r7615-ramdisk1.jpg > > Samsung NVMe connected to backplane > https://kosjenka.srce.hr/~hrvoje/openbsd/r7615-ramdisk2.jpg > > > I will try somehow to get console output >
fuse(4) device: replace selinfo with klist
Replace selinfo remnants with knote(9) API. Mechanical conversion
because `fuse_rd_filtops' left non MP safe. knote_locked(9) used because
the path covered by kernel lock.
We have some places where selinfo is still used. All of them could be
mechanically converted in this way and obsolete selwakeup() API could
go away. I don't want mix this code cleanup with making filterops MP
safe.
ok?
Index: sys/miscfs/fuse/fuse_device.c
===
RCS file: /cvs/src/sys/miscfs/fuse/fuse_device.c,v
retrieving revision 1.39
diff -u -p -r1.39 fuse_device.c
--- sys/miscfs/fuse/fuse_device.c 8 Sep 2023 20:00:28 - 1.39
+++ sys/miscfs/fuse/fuse_device.c 10 Sep 2023 12:58:28 -
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -25,7 +26,6 @@
#include
#include
#include
-#include
#include "fusefs_node.h"
#include "fusefs.h"
@@ -47,7 +47,7 @@ struct fuse_d {
struct fusebuf_head fd_fbufs_wait;
/* kq fields */
- struct selinfo fd_rsel;
+ struct klist fd_rklist;
LIST_ENTRY(fuse_d) fd_list;
};
@@ -184,7 +184,7 @@ fuse_device_queue_fbuf(dev_t dev, struct
SIMPLEQ_INSERT_TAIL(>fd_fbufs_in, fbuf, fb_next);
stat_fbufs_in++;
- selwakeup(>fd_rsel);
+ knote_locked(>fd_rklist, 0);
}
void
@@ -519,7 +519,7 @@ fusekqfilter(dev_t dev, struct knote *kn
switch (kn->kn_filter) {
case EVFILT_READ:
- klist = >fd_rsel.si_note;
+ klist = >fd_rklist;
kn->kn_fop = _rd_filtops;
break;
case EVFILT_WRITE:
@@ -539,9 +539,8 @@ void
filt_fuse_rdetach(struct knote *kn)
{
struct fuse_d *fd = kn->kn_hook;
- struct klist *klist = >fd_rsel.si_note;
- klist_remove_locked(klist, kn);
+ klist_remove_locked(>fd_rklist, kn);
}
int
Re: [OpenSMTPD] Setting personal mailserver
On 2023/09/09 13:49, Sagar Acharya wrote: > Thanks Peter, your comments were very helpful and I made some progress > > I have currently hosted server at 587. I have also set > > _submission._tcp.humaaraartha.in. SRV > > records which point to 587. However, I think such a thing is not implemented > by default to be detected by mailservers, perhaps, SMTPD. > > Is such a check on other ports in case 25 connection is not established > implemented? *nobody* does this. There was an opportunity to change how port lookups were done for email when MTA-STS was implemented reasonably recently (it would only help for the small number of senders actually using this, but it would still have been something) - but that just continued to use port 25. If you think about the scope of changes that would be involved across the internet, it's really just not possible to get everyone to change this, so you would still need to list a port 25 receiver at least as a backup MX (and honestly if you can do that, you might as well funnel all mail through that machine). Changes like: - everyone would need software that such a lookup - some firewalls would need changing (it would be reasonable to only permit an MTA to connect to random internet machines on ports needed for email/DNS) I would suggest getting a VPS or hosted server somewhere, and either bave that handle SMTP relay, or have a tunnel to your real mail server so that incoming connections are passed across directly.
