date:20200929

PUBLISH YOUR BLOG POSTS

2020-09-29 Thread aliza david

PUBLISH YOUR BLOG POSTS - INCREASE YOUR WEBSITE / BLOGS / FORUMS TRAFFIC

We have skills to boost up your website, personal blogs. We are providing
strong backlinks via Blog Posts to Increase Your Website Traffic as well as
Your Website/Blog Ranking over Search Engines. I suggest you give us a
chance to provide our long-time services with quality backlinks.

Your Blog Posts Can be Published on Following Domains. Please let us know
where you need Your Written Blog Posts / My Written Blog Posts

Site DA Traffic
Techtimes.com

83 418k
https://www.imagup.com/

71 14.2k
https://www.africanexponent.com/

55 5.70k
https://techstory.in/

68 3.37k
https://optimisticmommy.com/

41 2.30k
https://positivewordsresearch.com/

42 33.0k
http://fooyoh.com/

33 1.73k
https://www.chartattack.com/

63 8.51k
https://www.computertechreviews.com/

51 2.59k
https://www.techindiatoday.com/

44 3.53k
https://www.atlnightspots.com/

57 2.69k
https://www.td.org/

62 87.8k
Natureworldnews.com

74 11.7k
https://parkingaccess.com/

32 93.9k
https://newsdio.com/

40 3.75k
https://fashionterest.com/

24 1.78k
https://marketbusinessnews.com/

63 138k


I'll  send more sites according to your requirements.
   YOUR SUCCESS IS OUR MAIN GOAL
I suggest you give us a chance to provide our long-time services with
quality backlinks. so Contact me before pleasing an ORDER. I'll provide you
different sites at lowest price.If you have  any QUESTION feel free to
contact us
 Have a Good Day

Re: pckbc: extend the PS/2 interface tests

2020-09-29 Thread Ulf Brosziewski

Meanwhile, I think this patch is not a good idea, at least not in this form.
While it may correctly establish whether there is an auxiliary interface or
not, it may lead to conflicts in cases where a touchpad isn't "meant" to be
run in the legacy PS/2 mode.

Until now, I have thought that the lack of support for the AUXECHO command
is just a flaw of the firmware, but maybe it's the manufacturer's idea of
"phasing out" the legacy interface?

Many modern touchpads have dual connections to the system.  And if they
are recognized and initialized on another bus, then pckbc shouldn't attach
pms in the aux slot.  (Perhaps it would be nice to have some mechanism to
control that, but I don't know what it should look like.)

Since this weekend, I have a Clevo laptop here, and with this commit from
yesterday - which adds support for newer i2c controllers - the touchpad
is recognized and works well with imt(4):
https://marc.info/?l=openbsd-cvs=160131811230169=2

My patch isn't necessary in this setup, on the contrary:  The PS/2 interface
of the touchpad is dead, and if we added that code to the kernel now, it
would lead to a void pms and wsmouse node (and to timeouts when attempts are
made to enable or disable pms).


On 9/13/20 13:14, Ulf Brosziewski wrote:
> Not all PS/2-like controllers accept the AUXECHO command, and the test that
> pckbc applies in order to check for the presence of the auxiliary interface
> may yield false negatives, even on newer hardware (see
> https://marc.info/?l=openbsd-misc=158413132831425=2
> ).
> 
> This patch adds an alternative test.  It is applied if AUXECHO fails, and
> attempts to toggle and reset the KC8_MDISABLE flag by issuing an AUXDISABLE
> and AUXENABLE command, which should only succeed if there's an AUX interface.
> 
> (The test has a branch which makes it work regardless of the initial state
> of the flag; that's unnecessary at present but might be useful in a future
> version.)
> 
> OK?
> 
> 
> Index: pckbc.c
> ===
> RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
> retrieving revision 1.53
> diff -u -p -r1.53 pckbc.c
> --- pckbc.c   30 Nov 2019 18:18:34 -  1.53
> +++ pckbc.c   13 Sep 2020 09:27:10 -
> @@ -295,6 +295,32 @@ pckbc_attach_slot(struct pckbc_softc *sc
>   return (found);
>  }
> 
> +int
> +pckbc_auxcheck(struct pckbc_internal *t)
> +{
> + bus_space_tag_t iot = t->t_iot;
> + bus_space_handle_t ioh_c = t->t_ioh_c;
> + int res = -1;
> +
> + if ((t->t_cmdbyte & KC8_MDISABLE) == 0) {
> + if (pckbc_send_cmd(iot, ioh_c, KBC_AUXDISABLE)
> + && pckbc_get8042cmd(t))
> + res = (t->t_cmdbyte & KC8_MDISABLE);
> + pckbc_send_cmd(iot, ioh_c, KBC_AUXENABLE);
> + } else {
> + if (pckbc_send_cmd(iot, ioh_c, KBC_AUXENABLE)
> + && pckbc_get8042cmd(t))
> + res = (~t->t_cmdbyte & KC8_MDISABLE);
> + pckbc_send_cmd(iot, ioh_c, KBC_AUXDISABLE);
> + }
> + if (res == -1)
> + printf("kbc: auxcheck: error\n");
> + else
> + printf("kbc: auxcheck: %d\n", (res > 0));
> + pckbc_get8042cmd(t);
> + return (res > 0);
> +}
> +
>  void
>  pckbc_attach(struct pckbc_softc *sc, int flags)
>  {
> @@ -410,13 +436,17 @@ pckbc_attach(struct pckbc_softc *sc, int
>*/
>   DPRINTF("kbc: aux echo: %x\n", res);
>   t->t_haveaux = 1;
> - if (pckbc_attach_slot(sc, PCKBC_AUX_SLOT, 0))
> - cmdbits |= KC8_MENABLE;
>   }
>  #ifdef PCKBCDEBUG
>   else
>   printf("kbc: aux echo test failed\n");
>  #endif
> +
> + if (res == -1)
> + t->t_haveaux = pckbc_auxcheck(t);
> +
> + if (t->t_haveaux && pckbc_attach_slot(sc, PCKBC_AUX_SLOT, 0))
> + cmdbits |= KC8_MENABLE;
> 
>  #if defined(__i386__) || defined(__amd64__)
>   if (haskbd == 0 && !ISSET(flags, PCKBCF_FORCE_KEYBOARD_PRESENT)) {
>

Re: A few questions regarding WG(4)

2020-09-29 Thread Sven F.

On Mon, Sep 28, 2020 at 6:35 PM Sven F.  wrote:

> Dear reader,
>
> i tested 6.8-beta and WG
>
> After going for behind NAT to behind NAT experiment ,
> i went for two 'clients' behind a NAT to an openBSD device with a public IP
> called here 'Server'
>
> First of all , a minor detail, unless I thought wgport was not
> optional because the
> ifconfig output will not tell you the 'random port' chosen.
> So you cannot configure wgpeer after, unless
> you up the interface (1)
>
> 'Server'
>
> # ifconfig wg1
> wg1: flags=80c3 mtu 1420
> index 5 priority 0 llprio 3
> wgport 
> wgpubkey XdbTdbNzEASSXvgwAHrBuuBNHpeDtS0CGH3KsT7TxzY=
> wgpeer XxILKSdZ3JJr7fhAqzVNhNE4wbxJGfFlb4EYijqnU1k=
> wgendpoint XX 
> tx: 13988, rx: 11164
> last handshake: 135 seconds ago
> wgaip 192.168.5.1/24
> wgpeer Xo6rmtAMkXhGIJOtulLhzCialGdzoPhDSHou+LWWfz8=
> wgendpoint XX 
> tx: 10164, rx: 5992
> last handshake: 9 seconds ago
> wgaip 192.168.0.0/16
> groups: wg
> inet 192.168.5.1 netmask 0x broadcast 192.168.255.255
>
> the wgaip filter is a bit confusing to me because i MAY want to
> allow 192.168.5.1
> on both but not having overlapping subnet , or maybe it's dedicated to
> routing.
> The man page of WG(4) or the faq could have a more fancy example to
> illustrate
> correct use of wgaip
>
> The main question is related to the fact that
> I was unable to ping the peers from the 'server'
> until I pinged 192.168.5.1 from the two 'clients'.
>
> # ping 192.168.6.1
> PING 192.168.6.1 (192.168.6.1): 56 data bytes
> ^C
> --- 192.168.6.1 ping statistics ---
> 5 packets transmitted, 0 packets received, 100.0% packet loss
> ## ping 192.168.5.1 or remote device here
> # ping 192.168.6.1
> PING 192.168.6.1 (192.168.6.1): 56 data bytes
> 64 bytes from 192.168.6.1: icmp_seq=0 ttl=255 time=12.564 ms
> 64 bytes from 192.168.6.1: icmp_seq=1 ttl=255 time=16.005 ms
>
> Is this expected and/or due to the fact 192.168.6.1 is behind a NAT ?
>
> Best
> ( one client is i386 the other amd64 , 6.8 beta is working so far !)
>
>
> (1)
> # ifconfig wg2 create wgkey `openssl rand -base64 32`
> # ifconfig wg2
> wg2: flags=8082 mtu 1420
> index 6 priority 0 llprio 3
> wgpubkey iKbEvJvgyyzcdRcefgXaC7BWkmfUTREtL5BWvFeKdHo=
> groups: wg
> vps105766# ifconfig wg2 up
> vps105766# ifconfig wg2
> wg2: flags=80c3 mtu 1420
> index 6 priority 0 llprio 3
> wgport 16326
> wgpubkey iKbEvJvgyyzcdRcefgXaC7BWkmfUTREtL5BWvFeKdHo=
> groups: wg
>
> man
> ```
>  wgport port
>  Set the UDP port that the tunnel operates on.  The interface
> will
>  bind to INADDR_ANY and IN6ADDR_ANY_INIT.  If no port is
>  configured, one will be chosen automatically.
> ```
> to
> ```
>  wgport port
>  Set the UDP port that the tunnel operates on.  The interface
> will
>  bind to INADDR_ANY and IN6ADDR_ANY_INIT.  If no port is
>  configured, one will be chosen automatically when the
> interface is up.
> ```
>
> ?
>


My tunnel did not survive a suspend mode on the crapbook laptop.
public IP  did not roam
nothing after a few minutes ( other device is working fine )

Am I supposed to do a down / up cycle on the wg interface after suspend ?

fvwm: remove osrelease from system.fvwmrc

2020-09-29 Thread Klemens Nanni

This is the version string that shows up as part of "OpenBSD 6.8" in the
bottom right window in a default installation.

But as this version stems from the build machine's kernel with which
fvwm was build, it can differ from the version you're running on your
machine which is what you'd expect as user.

I do not use fvwm but this is irritating enough that I'd like to remove
the version number completely;  users can still set the entire string
in their ~/.fvwmrc or so.

The diff could be better but not without changing more of the build
system, hence keep the `all' target and continue using cat(1) and
redirection instead of using cp(1) and or building fvwm in a smarter way
in the first place.

Feedback? Objections? OK?


Index: app/fvwm//sample.fvwmrc/Makefile
===
RCS file: /cvs/xenocara/app/fvwm/sample.fvwmrc/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- app/fvwm//sample.fvwmrc/Makefile6 Jan 2008 18:13:58 -   1.7
+++ app/fvwm//sample.fvwmrc/Makefile29 Sep 2020 18:23:16 -
@@ -2,14 +2,12 @@
 
 .include "../Makefile.inc"
 
-OSRELEASE=`/sbin/sysctl -n kern.osrelease 2>&1`
 RM?=rm
 
 depend:
 
 all:
-   @sed -e "s,__osrelease__,${OSRELEASE}," \
-   ${.CURDIR}/system.fvwmrc > .fvwmrc
+   @cat ${.CURDIR}/system.fvwmrc > .fvwmrc
 
 install:
${INSTALL_DATA} .fvwmrc \
Index: app/fvwm//sample.fvwmrc/system.fvwmrc
===
RCS file: /cvs/xenocara/app/fvwm/sample.fvwmrc/system.fvwmrc,v
retrieving revision 1.8
diff -u -p -r1.8 system.fvwmrc
--- app/fvwm//sample.fvwmrc/system.fvwmrc   10 Sep 2012 13:52:04 -  
1.8
+++ app/fvwm//sample.fvwmrc/system.fvwmrc   29 Sep 2020 18:21:42 -
@@ -352,7 +352,7 @@ Key F8  A   M   CirculateDown
 *FvwmPagerFore white
 *FvwmPagerHilight #2d2d2d
 *FvwmPagerGeometry 80x60-1-1
-*FvwmPagerLabel 0 "OpenBSD __osrelease__"
+*FvwmPagerLabel 0 "OpenBSD"
 *FvwmPagerLabel 1 Maker
 *FvwmPagerLabel 2 Mail
 *FvwmPagerLabel 3 Matlab

Quick trip report: Lenovo P1 Gen 3

2020-09-29 Thread Dana Koch

There's still a lot of unrecognized devices on the P1 Gen 3, and the
install process is not quite smooth yet, but it does eventually boot
once installed with a GENERIC* kernel from -current. (See
https://marc.info/?l=openbsd-bugs=160011933402270=2 for dmesg and
vitals from the unmodified kernel.)

The audio device seems compatible with azalia, but I haven't done a
lot of thorough testing: adding the device ID to be detected for the
driver means audio-out works.

The laptop comes with an AX201 card for networking, but the PCI device
ID is unrecognized. iwx has a TODO mentioning the 06f0 ID, which this
one has. Fudging iwx to accept it seems to work OK, but is a little
buggy. Specifically, noticed slowness to acquire DHCP lease and things
can get wedged in exceptional circumstances such that the iwx device
becomes undetectable unless a full power cycle is taken. I haven't yet
fully reproduced the latter issue, nor eliminated local effects for
the DHCP problem.

Ultimately, this all may not be correct, but it does make the devices
sort of usable. FWIW, here's the diff.

Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1932
diff -u -p -u -r1.1932 pcidevs
--- sys/dev/pci/pcidevs 23 Aug 2020 19:24:22 - 1.1932
+++ sys/dev/pci/pcidevs 24 Sep 2020 04:40:31 -
@@ -3248,6 +3248,8 @@ product INTEL 82426EX 0x0486 82426EX IS
 product INTEL PCMC 0x04a3 82434LX/NX
 product INTEL GDT_RAID1 0x0600 GDT RAID
 product INTEL GDT_RAID2 0x061f GDT RAID
+product INTEL COMETLAKE_CAVS 0x06c8  Comet Lake PCH cAVS
+product INTEL WL_22500_3 0x06f0 Wi-Fi 6 AX201
 product INTEL WL_6150_1 0x0885 Centrino Wireless-N 6150
 product INTEL WL_6150_2 0x0886 Centrino Wireless-N 6150
 product INTEL WL_2230_1 0x0887 Centrino Wireless-N 2230
Index: sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.257
diff -u -p -u -r1.257 azalia.c
--- sys/dev/pci/azalia.c 9 Jun 2020 03:36:05 - 1.257
+++ sys/dev/pci/azalia.c 24 Sep 2020 04:40:31 -
@@ -465,6 +465,7 @@ azalia_configure_pci(azalia_t *az)
  case PCI_PRODUCT_INTEL_C610_HDA:
  case PCI_PRODUCT_INTEL_BSW_HDA:
  case PCI_PRODUCT_INTEL_APOLLOLAKE_HDA:
+ case PCI_PRODUCT_INTEL_COMETLAKE_CAVS:
  reg = azalia_pci_read(az->pc, az->tag,
  INTEL_PCIE_NOSNOOP_REG);
  reg &= INTEL_PCIE_NOSNOOP_MASK;
@@ -476,7 +477,8 @@ azalia_configure_pci(azalia_t *az)

 const struct pci_matchid azalia_pci_devices[] = {
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_200SERIES_U_HDA },
- { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA }
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_COMETLAKE_CAVS }
 };

 int
Index: sys/dev/pci/if_iwx.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
retrieving revision 1.44
diff -u -p -u -r1.44 if_iwx.c
--- sys/dev/pci/if_iwx.c 26 Aug 2020 17:12:00 - 1.44
+++ sys/dev/pci/if_iwx.c 24 Sep 2020 04:40:31 -
@@ -7708,6 +7708,7 @@ typedef void *iwx_match_t;
 static const struct pci_matchid iwx_devices[] = {
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_1 },
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_2 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_3 },
 };

 static const struct pci_matchid iwx_subsystem_id_ax201[] = {
@@ -7746,6 +7747,7 @@ iwx_match(struct device *parent, iwx_mat
  case PCI_PRODUCT_INTEL_WL_22500_1: /* AX200 */
  return 1; /* match any device */
  case PCI_PRODUCT_INTEL_WL_22500_2: /* AX201 */
+ case PCI_PRODUCT_INTEL_WL_22500_3: /* AX201 */
  for (i = 0; i < nitems(iwx_subsystem_id_ax201); i++) {
  if (svid == iwx_subsystem_id_ax201[i].pm_vid &&
  spid == iwx_subsystem_id_ax201[i].pm_pid)
@@ -7922,6 +7924,7 @@ iwx_attach(struct device *parent, struct
  sc->sc_uhb_supported = 0;
  break;
  case PCI_PRODUCT_INTEL_WL_22500_2:
+ case PCI_PRODUCT_INTEL_WL_22500_3:
  sc->sc_fwname = "iwx-QuZ-a0-hr-b0-48";
  sc->sc_device_family = IWX_DEVICE_FAMILY_22000;
  sc->sc_fwdmasegsz = IWX_FWDMASEGSZ_8000;

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

2020-09-29 Thread Theo de Raadt

Patrick Wildt  wrote:

> On Tue, Sep 29, 2020 at 11:23:03AM -0600, Theo de Raadt wrote:
> > +   if (strcmp(ia->ia_name, "st,m41t83") == 0)
> > 
> > fine with me.  But in that case, why not call the driver i2c/m41t83.c
> 
> Because it's a series of chips, like m41t80, m41t81, m41t82.  Machines
> and their device trees encode the specific chip, because some versions
> might have a different feature set as others.  We do the same x-place-
> holder-notation for other drivers as well.
> 
> For now I only match on st,m41t83 since that is the version of the chip
> the driver was originally written for.  For every additional supported
> variant of that series, the code needs to be checked for correctness.
> 
> But the file is still supposed to cover more than this one specific
> variant of the series.

If it supports many chips, why are you only matching for one variation?
To save code bytes, I guess.  But later on, will there be any variation
handling in the driver?  Not having checked the vendor docs, I suspect
they are highly compatible.  In chips like this, the variation tends
to be electronics, or power connectivity or such, rather than register
or behaviour layout.

The other way this works, is the new chip has a very similar number
but totally different behaviour.

Which is it?

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

2020-09-29 Thread Patrick Wildt

On Tue, Sep 29, 2020 at 11:23:03AM -0600, Theo de Raadt wrote:
> +   if (strcmp(ia->ia_name, "st,m41t83") == 0)
> 
> fine with me.  But in that case, why not call the driver i2c/m41t83.c

Because it's a series of chips, like m41t80, m41t81, m41t82.  Machines
and their device trees encode the specific chip, because some versions
might have a different feature set as others.  We do the same x-place-
holder-notation for other drivers as well.

For now I only match on st,m41t83 since that is the version of the chip
the driver was originally written for.  For every additional supported
variant of that series, the code needs to be checked for correctness.

But the file is still supposed to cover more than this one specific
variant of the series.

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

2020-09-29 Thread Theo de Raadt

+   if (strcmp(ia->ia_name, "st,m41t83") == 0)

fine with me.  But in that case, why not call the driver i2c/m41t83.c

mfokclock(4) -> mfokrtc(4): loongson's hugging arm

2020-09-29 Thread Patrick Wildt

Hi,

some arm64 that I'd like to use as replacement server for the one that's
crashing all the time (probably HW-related) has a Microcrystal RV4162
RTC.  As it turns out, this is about the same as the ST M41T8x series.

For that one we already have mfokclock(4), but only for loongson.  After
talking to kettenis@, we think that first of all sys/arch/loongson/dev/
m41t8xclock.c should be moved to sys/dev/i2c/m41t8x.c so that the file
can be re-used by multiple architectures.  And usually we don't have the
type of device in the filename, so I removed that as well.

Usually we reserve clock for clock control subsystems, while we call
RTCs as they are.  That's why I renamed mfokclock(4) to mfokrtc(4),
and also renamed the code accordingly.

Instead of matching on the driver's name, let's match on st,m41t83, as
when the driver was imported that specific chip was the reason for the
driver.  This also means changing the iic controller to pass a different
string.

Can someone make sure this still works on their loongson devices?  Are
there any objections to this?

Thank you,
Patrick

diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile
index 4a3df6b33b1..8ba306f41ed 100644
--- a/share/man/man4/Makefile
+++ b/share/man/man4/Makefile
@@ -47,8 +47,8 @@ MAN=  aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \
kate.4 kcov.4 km.4 ksmn.4 ksyms.4 kubsan.4 kue.4 lc.4 lge.4 lii.4 \
lisa.4 lm.4 lmenv.4 lmn.4 lmtemp.4 lo.4 lpt.4 lxtphy.4 luphy.4 \
maestro.4 mainbus.4 malo.4 maxds.4 maxrtc.4 maxtmp.4 mbg.4 \
-   mcprtc.4 mcx.4 midi.4 mii.4 mfi.4 \
-   mfii.4 mlphy.4 moscom.4 mos.4 mpe.4 mpath.4 mpi.4 mpii.4 \
+   mcprtc.4 mcx.4 midi.4 mii.4 mfi.4 mfii.4 mfokrtc.4 \
+   mlphy.4 moscom.4 mos.4 mpe.4 mpath.4 mpi.4 mpii.4 \
mpip.4 mpu.4 msk.4 mpw.4 msts.4 mtd.4 mtdphy.4 mtio.4 mue.4 \
multicast.4 mvclock.4 mvdog.4 mvgicp.4 mvgpio.4 mvicu.4 mviic.4 \
mvneta.4 mvpinctrl.4 mvpp.4 mvrng.4 mvrtc.4 mvspi.4 mvtemp.4 mvuart.4 \
diff --git a/share/man/man4/man4.loongson/Makefile 
b/share/man/man4/man4.loongson/Makefile
index 6e133c04f62..b3d5b061c84 100644
--- a/share/man/man4/man4.loongson/Makefile
+++ b/share/man/man4/man4.loongson/Makefile
@@ -1,7 +1,7 @@
 #  $OpenBSD: Makefile,v 1.10 2016/11/17 15:06:16 visa Exp $
 
 MAN=   apm.4 autoconf.4 bonito.4 gdiumiic.4 glxclk.4 glxpcib.4 htb.4 intro.4 \
-   leioc.4 mem.4 mfokclock.4 sisfb.4 smfb.4 stsec.4 voyager.4 ykbec.4
+   leioc.4 mem.4 sisfb.4 smfb.4 stsec.4 voyager.4 ykbec.4
 MANSUBDIR=loongson
 
 .include 
diff --git a/share/man/man4/man4.loongson/mfokclock.4 
b/share/man/man4/man4.loongson/mfokclock.4
deleted file mode 100644
index 69d122dfdf2..000
--- a/share/man/man4/man4.loongson/mfokclock.4
+++ /dev/null
@@ -1,31 +0,0 @@
-.\"$OpenBSD: mfokclock.4,v 1.2 2018/06/18 06:06:52 jmc Exp $
-.\"
-.\" Copyright (c) 2010 Miodrag Vallat.
-.\"
-.\" 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.
-.\"
-.Dd $Mdocdate: June 18 2018 $
-.Dt MFOKCLOCK 4 loongson
-.Os
-.Sh NAME
-.Nm mfokclock
-.Nd M41T8x real-time clock
-.Sh SYNOPSIS
-.Cd "mfokclock* at iic? addr 0x68"
-.Sh DESCRIPTION
-The
-.Nm
-driver supports two-wire real-time clock chips of the M41T8x family.
-.Sh SEE ALSO
-.Xr iic 4 ,
-.Xr intro 4
diff --git a/share/man/man4/mfokrtc.4 b/share/man/man4/mfokrtc.4
new file mode 100644
index 000..487591817ec
--- /dev/null
+++ b/share/man/man4/mfokrtc.4
@@ -0,0 +1,31 @@
+.\"$OpenBSD: mfokclock.4,v 1.2 2018/06/18 06:06:52 jmc Exp $
+.\"
+.\" Copyright (c) 2010 Miodrag Vallat.
+.\"
+.\" 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.

iked(8): check ibuf_seek() return value

2020-09-29 Thread Tobias Heider

Hi,

the diff below adds a missing return value check for ibuf_seek() in IKEv2
fragment reassembly.

ok?

diff --git a/sbin/iked/ikev2_pld.c b/sbin/iked/ikev2_pld.c
index 7102cfff6fd..2475be07299 100644
--- a/sbin/iked/ikev2_pld.c
+++ b/sbin/iked/ikev2_pld.c
@@ -1793,6 +1793,7 @@ ikev2_frags_reassemble(struct iked *env, struct 
ikev2_payload *pld,
struct iked_frag*sa_frag = >msg_sa->sa_fragments;
struct ibuf *e = NULL;
struct iked_frag_entry  *el;
+   uint8_t *ptr;
size_t   offset;
size_t   i;
struct iked_message  emsg;
@@ -1809,7 +1810,12 @@ ikev2_frags_reassemble(struct iked *env, struct 
ikev2_payload *pld,
for (i = 0; i < sa_frag->frag_total; i++) {
if ((el = sa_frag->frag_arr[i]) == NULL)
fatalx("Tried to reassemble shallow frag_arr");
-   memcpy(ibuf_seek(e, offset, 0), el->frag_data, el->frag_size);
+   ptr = ibuf_seek(e, offset, el->frag_size);
+   if (ptr == NULL) {
+   log_info("%s: failed to reassemble fragments", 
__func__);
+   goto done;
+   }
+   memcpy(ptr, el->frag_data, el->frag_size);
offset += el->frag_size;
}

dump: better handling of large filesystems

2020-09-29 Thread Otto Moerbeek

Hi,

this fixes an overwrite of spcl.c_addr.  Taken form FreeBSD.

See https://marc.info/?l=openbsd-misc=160018252418088=2

-Otto


Index: tape.c
===
RCS file: /cvs/src/sbin/dump/tape.c,v
retrieving revision 1.45
diff -u -p -r1.45 tape.c
--- tape.c  28 Jun 2019 13:32:43 -  1.45
+++ tape.c  26 Sep 2020 06:30:37 -
@@ -330,7 +330,10 @@ flushtape(void)
}
 
blks = 0;
-   if (spcl.c_type != TS_END) {
+   if (spcl.c_type != TS_END && spcl.c_type != TS_CLRI &&
+   spcl.c_type != TS_BITS) {
+   if (spcl.c_count > TP_NINDIR)
+   quit("c_count too large\n");
for (i = 0; i < spcl.c_count; i++)
if (spcl.c_addr[i] != 0)
blks++;

random canary bytes for malloc

2020-09-29 Thread Otto Moerbeek

Hi,

until now, canary bytes (used by the C olption) were the same as the
bytes used to junk (0xfd).  This means that certain overwrites are not
detected, like setting the high bit. 

This makes the byte value used to write canaries random. I do not want
to complicate the code to handle all combinatuon of F and C, so 0xfd
is still acepted as a canary byte.

Please test with all your favourite combinations of malloc flags.

-Otto

Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.263
diff -u -p -r1.263 malloc.c
--- malloc.c6 Sep 2020 06:41:03 -   1.263
+++ malloc.c10 Sep 2020 10:53:18 -
@@ -193,7 +193,7 @@ struct malloc_readonly {
int def_malloc_junk;/* junk fill? */
int malloc_realloc; /* always realloc? */
int malloc_xmalloc; /* xmalloc behaviour? */
-   int chunk_canaries; /* use canaries after chunks? */
+   u_int   chunk_canaries; /* use canaries after chunks? */
int internal_funcs; /* use better recallocarray/freezero? */
u_int   def_malloc_cache;   /* free pages we cache */
size_t  malloc_guard;   /* use guard pages after allocations? */
@@ -468,6 +468,11 @@ omalloc_init(void)
 
while ((mopts.malloc_canary = arc4random()) == 0)
;
+   if (mopts.chunk_canaries)
+   do {
+   mopts.chunk_canaries = arc4random();
+   } while ((u_char)mopts.chunk_canaries == 0 ||
+   (u_char)mopts.chunk_canaries == SOME_FREEJUNK); 
 }
 
 static void
@@ -938,7 +943,7 @@ fill_canary(char *ptr, size_t sz, size_t
 
if (check_sz > CHUNK_CHECK_LENGTH)
check_sz = CHUNK_CHECK_LENGTH;
-   memset(ptr + sz, SOME_JUNK, check_sz);
+   memset(ptr + sz, mopts.chunk_canaries, check_sz);
 }
 
 /*
@@ -1039,7 +1044,7 @@ validate_canary(struct dir_info *d, u_ch
q = p + check_sz;
 
while (p < q) {
-   if (*p != SOME_JUNK) {
+   if (*p != (u_char)mopts.chunk_canaries && *p != SOME_JUNK) {
wrterror(d, "chunk canary corrupted %p %#tx@%#zx%s",
ptr, p - ptr, sz,
*p == SOME_FREEJUNK ? " (double free?)" : "");

PUBLISH YOUR BLOG POSTS

Re: pckbc: extend the PS/2 interface tests

Re: A few questions regarding WG(4)

fvwm: remove osrelease from system.fvwmrc

Quick trip report: Lenovo P1 Gen 3

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

mfokclock(4) -> mfokrtc(4): loongson's hugging arm

iked(8): check ibuf_seek() return value

dump: better handling of large filesystems

random canary bytes for malloc

12 matches

Site Navigation

Mail list logo

Footer information