Re: smtpd handling of \r in DATA part
September 19, 2019 7:26 PM, "Eric Faurot" wrote: > On Thu, Sep 19, 2019 at 05:46:47PM +0200, Gilles Chehade wrote: > >> Hello, >> >> The RFC for SMTP states the following (section 2.3.8): >> >> In addition, the appearance of "bare" "CR" or "LF" characters in text >> (i.e., either without the other) has a long history of causing >> problems in mail implementations and applications that use the mail >> system as a tool. SMTP client implementations MUST NOT transmit >> these characters except when they are intended as line terminators >> and then MUST, as indicated above, transmit them only as a >> sequence. >> >> As a result, OpenSMTPD rejects DATA containing with the following: >> >> 500 5.0.0 is only allowed before >> >> requiring that clients encode DATA if is part of it. >> >> My question is: are we too strict ? >> >> Not two MTA do the same thing. Some will leave '\r' in the body and then >> write it to the user mailbox or relay it. Other change it into a '\n' or >> skip it. The first ones take the risk of a MUA not handling '\r' well or >> an MTA rejecting later, the second ones break DKIM-signatures. >> >> The only good way to deal with this is to stick to the RFC ... BUT users >> then experience message rejections when using broken clients (semarie@'s >> printer is an example of one). >> >> So: >> >> a- do we leave '\r' in the body ? >> b- do we turn '\r' into '\n' > > I don't think it's a good solution. > What happens if there is a dot right after the '\r'? > It gets escaped, just like if '\n' had been sent in place of '\r'. foo\r.\rbar => foo\n..\nbar I don't think it's a good solution either but it's one used in real world, this is the approach Gmail (among others) took. >> c- do we keep strict behavior ? >> d- do we keep strict behavior + provide a knob for '\r' to work ? > > I'm not sure the RFC actually requires the server to reject mails with > "bare" '\r'. It just says the client must not transmit them. So maybe > we should just discard them at receive time... > The RFC doesn't require the server to reject mails with "bare" '\r' BUT since it states that we shouldn't transmit them, not rejecting them has the side-effect that we MUST alter DATA (and break DKIM for these). > To me, the only real problem with '\r' is at the end of lines. It's confusing > since you never really know whether it's part of the content or the protocol. > > So I suggest that we strip all '\r' found at the end of a line, > and retain the others. > I'm not sure the only problem is at the end of lines, but I don't think any solution that's graceful to bad clients will be correct so I'm okay with your suggestion.
Re: smtpd handling of \r in DATA part
On Thu, Sep 19, 2019 at 05:46:47PM +0200, Gilles Chehade wrote: > Hello, > > The RFC for SMTP states the following (section 2.3.8): > > In addition, the appearance of "bare" "CR" or "LF" characters in text > (i.e., either without the other) has a long history of causing > problems in mail implementations and applications that use the mail > system as a tool. SMTP client implementations MUST NOT transmit > these characters except when they are intended as line terminators > and then MUST, as indicated above, transmit them only as a > sequence. > > > As a result, OpenSMTPD rejects DATA containing with the following: > > 500 5.0.0 is only allowed before > > requiring that clients encode DATA if is part of it. > > My question is: are we too strict ? > > Not two MTA do the same thing. Some will leave '\r' in the body and then > write it to the user mailbox or relay it. Other change it into a '\n' or > skip it. The first ones take the risk of a MUA not handling '\r' well or > an MTA rejecting later, the second ones break DKIM-signatures. > > The only good way to deal with this is to stick to the RFC ... BUT users > then experience message rejections when using broken clients (semarie@'s > printer is an example of one). > > So: > > a- do we leave '\r' in the body ? > b- do we turn '\r' into '\n' I don't think it's a good solution. What happens if there is a dot right after the '\r'? > c- do we keep strict behavior ? > d- do we keep strict behavior + provide a knob for '\r' to work ? I'm not sure the RFC actually requires the server to reject mails with "bare" '\r'. It just says the client must not transmit them. So maybe we should just discard them at receive time... To me, the only real problem with '\r' is at the end of lines. It's confusing since you never really know whether it's part of the content or the protocol. So I suggest that we strip all '\r' found at the end of a line, and retain the others. Eric.
PATCH: ldpd: adjacency processing fix
If remote peer changes LSR ID, ldpd will not update adjacency. Because
ldpd looks up the adjacency only by source IP address and does not
consider LSR ID. You can see it in 'ldpctl show discovery'. This
patch fixes it.
diff --git usr.sbin/ldpd/adjacency.c usr.sbin/ldpd/adjacency.c
index a40027225ea..c33c77d7779 100644
--- usr.sbin/ldpd/adjacency.c
+++ usr.sbin/ldpd/adjacency.c
@@ -121,6 +121,9 @@ adj_find(struct hello_source *source)
if (adj->source.type != source->type)
continue;
+ if (adj->lsr_id.s_addr != source->lsr_id.s_addr)
+ continue;
+
switch (source->type) {
case HELLO_LINK:
if (ldp_addrcmp(source->link.ia->af,
diff --git usr.sbin/ldpd/hello.c usr.sbin/ldpd/hello.c
index f6d6245b3bd..3a16571d2fb 100644
--- usr.sbin/ldpd/hello.c
+++ usr.sbin/ldpd/hello.c
@@ -229,6 +229,7 @@ recv_hello(struct in_addr lsr_id, struct ldp_msg *msg, int
af,
}
memset(, 0, sizeof(source));
+ source.lsr_id = lsr_id;
if (flags & F_HELLO_TARGETED) {
/*
* RFC 7552 - Section 5.2:
diff --git usr.sbin/ldpd/ldpe.h usr.sbin/ldpd/ldpe.h
index a4ad7de0440..af0a4102fb5 100644
--- usr.sbin/ldpd/ldpe.h
+++ usr.sbin/ldpd/ldpe.h
@@ -33,6 +33,7 @@
struct hello_source {
enum hello_type type;
+ struct in_addr lsr_id;
struct {
struct iface_af *ia;
union ldpd_addr src_addr;
EFI frame buffer > 4GB
Hi,
I recently got a VAIO Pro PK. The diff below is required to boot.
Without the diff, it freezes during boot.
Its EFI framebuffer is located 0x40 (9 zeros). This is > 4GB
and higher than highest available memory of the machine. These
configuraions seem to cause the problem.
* * *
Call cninit() after pmap_bootstrap() is called. Since the EFI
framebuffer may be located > 4GB which is not initialized by locore,
but by pmap_bootstrap(). Also make the address parameter passed to
pmap_bootstrap() cover the framebuffer. Actually VAIO pro PK's
framebuffer is located higher than the highest available memory
region.
ok? comments?
Index: sys/arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.259
diff -u -p -r1.259 machdep.c
--- sys/arch/amd64/amd64/machdep.c 7 Sep 2019 19:05:44 - 1.259
+++ sys/arch/amd64/amd64/machdep.c 19 Sep 2019 15:55:18 -
@@ -193,6 +193,8 @@ int lid_action = 1;
int pwr_action = 1;
int forceukbd;
+int docninit;
+
/*
* safepri is a safe priority for sleep to set for a spin-wait
* during autoconfiguration or after a panic.
@@ -1371,6 +1373,7 @@ init_x86_64(paddr_t first_avail)
bios_memmap_t *bmp;
int x, ist;
uint64_t max_dm_size = ((uint64_t)512 * NUM_L4_SLOT_DIRECT) << 30;
+ paddr_t max_pa;
cpu_init_msrs(_info_primary);
@@ -1541,7 +1544,16 @@ init_x86_64(paddr_t first_avail)
* Call pmap initialization to make new kernel address space.
* We must do this before loading pages into the VM system.
*/
- first_avail = pmap_bootstrap(first_avail, trunc_page(avail_end));
+ max_pa = avail_end;
+ /* Make sure max_pa covers the EFI frame buffer */
+ if (bios_efiinfo->fb_addr != 0 &&
+ max_pa < bios_efiinfo->fb_addr + bios_efiinfo->fb_size)
+ max_pa = bios_efiinfo->fb_addr + bios_efiinfo->fb_size;
+ first_avail = pmap_bootstrap(first_avail, trunc_page(max_pa));
+
+ /* Call cninit after entire physical memory is available */
+ if (docninit > 0)
+ cninit();
/* Allocate these out of the 640KB base memory */
if (avail_start != PAGE_SIZE)
@@ -1914,7 +1926,6 @@ getbootinfo(char *bootinfo, int bootinfo
bios_ddb_t *bios_ddb;
bios_bootduid_t *bios_bootduid;
bios_bootsr_t *bios_bootsr;
- int docninit = 0;
#undef BOOTINFO_DEBUG
#ifdef BOOTINFO_DEBUG
@@ -2026,8 +2037,6 @@ getbootinfo(char *bootinfo, int bootinfo
break;
}
}
- if (docninit > 0)
- cninit();
#ifdef BOOTINFO_DEBUG
printf("\n");
#endif
smtpd handling of \r in DATA part
Hello, The RFC for SMTP states the following (section 2.3.8): In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a sequence. As a result, OpenSMTPD rejects DATA containing with the following: 500 5.0.0 is only allowed before requiring that clients encode DATA if is part of it. My question is: are we too strict ? Not two MTA do the same thing. Some will leave '\r' in the body and then write it to the user mailbox or relay it. Other change it into a '\n' or skip it. The first ones take the risk of a MUA not handling '\r' well or an MTA rejecting later, the second ones break DKIM-signatures. The only good way to deal with this is to stick to the RFC ... BUT users then experience message rejections when using broken clients (semarie@'s printer is an example of one). So: a- do we leave '\r' in the body ? b- do we turn '\r' into '\n' c- do we keep strict behavior ? d- do we keep strict behavior + provide a knob for '\r' to work ? -- Gilles Chehade @poolpOrg https://www.poolp.orgpatreon: https://www.patreon.com/gilles
Re: New driver for AMD CPU temperature sensor over SMN
On Tue, Sep 17, 2019 at 12:41:11PM -0400, Bryan Steele wrote:
> Unlike with previous generations of AMD processors, the on-die
> temperature sensor is only available from reading from the SMU
> co-processor over an internal network (SMN), this includes all
> Ryzen CPUs and some later Family 15h models (not supported here).
>
> This adds a new driver based on km(4) and info gleamed from Linux
> FreeBSD.
>
> High-TDP Zen/Zen+ parts have undocumented offsets from the control temp
> and need to be adjusted, low-TDP (mobile) and Zen2 have no offsets.
>
> I've tested this on a Ryzen 2700X desktop and a Ryzen 5 2500U (mobile)
> laptop (no offset). I would appreciate feedback on other models, and
> confirmation about Zen2.
>
> Thanks to @nte@bsd.network for the providing helpful information and
> much needed prodding.
>
> -Bryan.
>
This works on my Ryzen 2700U, thanks!
kmsmn0 at pci0 dev 0 function 0 "AMD AMD64 17h/1xh Root Complex" rev 0x00
kmsmn0.temp0 60.88 degC
-ml
> Index: arch/amd64/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.478
> diff -u -p -u -r1.478 GENERIC
> --- sys/arch/amd64/conf/GENERIC 7 Sep 2019 13:46:19 - 1.478
> +++ sys/arch/amd64/conf/GENERIC 17 Sep 2019 16:24:03 -
> @@ -103,6 +103,7 @@ amdpcib* at pci? # AMD 8111 LPC bridge
> tcpcib* at pci? # Intel Atom E600 LPC bridge
> kate*at pci? # AMD K8 temperature sensor
> km* at pci? # AMD K10 temperature sensor
> +kmsmn* at pci? # AMD F17 temperature sensor
> amas*at pci? disable # AMD memory configuration
> pchtemp* at pci? # Intel C610 termperature sensor
> ccp* at pci? # AMD Cryptographic Co-processor
> Index: dev/pci/files.pci
> ===
> RCS file: /cvs/src/sys/dev/pci/files.pci,v
> retrieving revision 1.338
> diff -u -p -u -r1.338 files.pci
> --- sys/dev/pci/files.pci 5 Aug 2019 08:33:38 - 1.338
> +++ sys/dev/pci/files.pci 17 Sep 2019 16:24:03 -
> @@ -774,6 +774,11 @@ device km
> attach km at pci
> file dev/pci/km.ckm
>
> +# AMD Family 15h/17h Temperature sensor over SMN
> +device kmsmn
> +attach kmsmn at pci
> +file dev/pci/kmsmn.c kmsmn
> +
> # Intel SOC GCU
> device gcu
> attach gcu at pci
> Index: dev/pci/kmsmn.c
> ===
> RCS file: dev/pci/kmsmn.c
> diff -N dev/pci/kmsmn.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ sys/dev/pci/kmsmn.c 17 Sep 2019 16:24:03 -
> @@ -0,0 +1,170 @@
> +/* $OpenBSD$ */
> +
> +/*
> + * Copyright (c) 2019 Bryan Steele
> + *
> + * 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
> +
> +/*
> + * AMD temperature sensors on Family 17h (and some 15h) must be
> + * read from the System Management Unit (SMU) co-processor over
> + * the System Management Network (SMN).
> + */
> +
> +#define SMN_17H_ADDR_R 0x60
> +#define SMN_17H_DATA_R 0x64
> +
> +/*
> + * AMD Family 17h SMU Thermal Registers (THM)
> + *
> + * 4.2.1, OSRR (Open-Source Register Reference) Guide for Family 17h
> + * [31:21] Current reported temperature.
> + */
> +#define SMU_17H_THM 0x59800
> +#define KM_GET_CURTMP(r) (((r) >> 21) & 0x7ff)
> +
> +/*
> + * Bit 19 set: "Report on -49C to 206C scale range."
> + * clear: "Report on 0C to 225C (255C?) scale range."
> + */
> +#define CURTMP_17H_RANGE_SEL (1 << 19)
> +#define CURTMP_17H_RANGE_ADJUST 490
> +
> +/*
> + * Undocumented tCTL offsets gleamed from Linux k10temp driver.
> + */
> +struct curtmp_offset {
> + const char *const cpu_model; /* partial match */
> + int tctl_offset;
> +} cpu_model_offsets[] = {
> + { "AMD Ryzen 5 1600X", 200 },
> + { "AMD Ryzen 7 1700X", 200 },
> + { "AMD Ryzen 7 1800X", 200 },
> + { "AMD Ryzen 7 2700X", 100 },
> + { "AMD Ryzen Threadripper 19", 270 }, /* many models */
> +
Re: bpf_mtap_hdr copy function is redundant
On Thu, Sep 19, 2019 at 09:02:09AM +0200, Klemens Nanni wrote: > On Thu, Sep 19, 2019 at 01:04:03PM +1000, David Gwynne wrote: > > this removes the cpfn argument from bpf_mtap_hdr since nothing uses it > > anymore. > OK kn if you update pbf_mtap(9) as well. Same here. OK claudio and please update man page. -- :wq Claudio
Re: bpf_mtap_hdr copy function is redundant
On Thu, Sep 19, 2019 at 01:04:03PM +1000, David Gwynne wrote: > this removes the cpfn argument from bpf_mtap_hdr since nothing uses it > anymore. OK kn if you update pbf_mtap(9) as well.
