Re: vmd: drive i8253 with monotonic clock

[Scott Cheloha]

1 month bump.

> On Mar 9, 2018, at 2:31 PM, Scott Cheloha  wrote:
> 
>> On Sun, Feb 18, 2018 at 09:34:50PM -0800, Mike Larkin wrote:
>>> On Sun, Feb 18, 2018 at 07:42:10PM -0600, Scott Cheloha wrote:
 On Sun, Feb 18, 2018 at 02:44:43PM -0800, Mike Larkin wrote:
> On Sun, Feb 18, 2018 at 12:00:01PM -0600, Scott Cheloha wrote:
> [...]
 
 Before I read through this, can you briefly explain what this is trying 
 to fix?
>>> 
>>> The i8253 is a down counter.  If we drive it with the system wall clock
>>> it could "count up" or make relatively big jumps if the superuser changes
>>> the host's wall clock with date(1).  Driving it with the monotonic clock
>>> should, in principle, ensure it always decrements and that it decrements
>>> relatively evenly.
>>> 
>>> I'm not sure what exactly the guest does if the output latch on the PIC
>>> increments or jumps between two readbacks, though.
>>> 
>>> Here's a diff without any refactoring.  But there's bugs in your timeval
>>> normalization code [1], so I think using the subtraction macros in 
>>> sys/time.h
>>> would be a good idea, eventually.
>>> 
>>> -Scott
>>> 
>>> [1]tv_usec > 100
>>> 
>>> should be
>>> 
>>>tv_usec >= 100
>>> 
>> 
>> Alright, seems like this is an improvement at least in readability. I don't 
>> believe that the jumping around of the PIT counter would cause serious issues
>> even if it went backwards (aside from perhaps keeping slightly less accurate
>> time but we know we have issues there with reading the PIT anyway, due to its
>> very small period).
>> 
>> Thanks for spotting the tv_usec thing also.
>> 
>> I'd like to get a few reports that this doesn't break anything before oks
>> though. I'll load it on my x230 where I run a bunch of VMs and see what
>> happens..
> 
> Did this work?
> 
> -Scott
> 
>> PS, I realize this is w/o refactoring, I like the other one more so that's
>> the one I'll use
>> 
>> -ml
>> 
>> 
>> 
>>> Index: usr.sbin/vmd/i8253.c
>>> ===
>>> RCS file: /cvs/src/usr.sbin/vmd/i8253.c,v
>>> retrieving revision 1.17
>>> diff -u -p -r1.17 i8253.c
>>> --- usr.sbin/vmd/i8253.c14 Aug 2017 19:46:44 -1.17
>>> +++ usr.sbin/vmd/i8253.c19 Feb 2018 01:36:44 -
>>> @@ -25,6 +25,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> 
>>> #include "i8253.h"
>>> @@ -53,7 +54,7 @@ void
>>> i8253_init(uint32_t vm_id)
>>> {
>>>memset(_channel, 0, sizeof(struct i8253_channel));
>>> -gettimeofday(_channel[0].tv, NULL);
>>> +clock_gettime(CLOCK_MONOTONIC, _channel[0].ts);
>>>i8253_channel[0].start = 0x;
>>>i8253_channel[0].mode = TIMER_INTTC;
>>>i8253_channel[0].last_r = 1;
>>> @@ -86,7 +87,7 @@ i8253_init(uint32_t vm_id)
>>> void
>>> i8253_do_readback(uint32_t data)
>>> {
>>> -struct timeval now, delta;
>>> +struct timespec now, delta;
>>>uint64_t ns, ticks;
>>> 
>>>/* bits are inverted here - !TIMER_RB_STATUS == enable chan readback */
>>> @@ -99,19 +100,19 @@ i8253_do_readback(uint32_t data)
>>>/* !TIMER_RB_COUNT == enable counter readback */
>>>if (data & ~TIMER_RB_COUNT) {
>>>if (data & TIMER_RB_C0) {
>>> -gettimeofday(, NULL);
>>> -delta.tv_sec = now.tv_sec - i8253_channel[0].tv.tv_sec;
>>> -delta.tv_usec = now.tv_usec -
>>> -i8253_channel[0].tv.tv_usec;
>>> -if (delta.tv_usec < 0) {
>>> +clock_gettime(CLOCK_MONOTONIC, );
>>> +delta.tv_sec = now.tv_sec - i8253_channel[0].ts.tv_sec;
>>> +delta.tv_nsec = now.tv_nsec -
>>> +i8253_channel[0].ts.tv_nsec;
>>> +if (delta.tv_nsec < 0) {
>>>delta.tv_sec--;
>>> -delta.tv_usec += 100;
>>> +delta.tv_nsec += 10;
>>>}
>>> -if (delta.tv_usec > 100) {
>>> +if (delta.tv_nsec >= 10) {
>>>delta.tv_sec++;
>>> -delta.tv_usec -= 100;
>>> +delta.tv_nsec -= 10;
>>>}
>>> -ns = delta.tv_usec * 1000 + delta.tv_sec * 10;
>>> +ns = delta.tv_nsec + delta.tv_sec * 10;
>>>ticks = ns / NS_PER_TICK;
>>>if (i8253_channel[0].start)
>>>i8253_channel[0].olatch =
>>> @@ -122,19 +123,19 @@ i8253_do_readback(uint32_t data)
>>>}
>>> 
>>>if (data & TIMER_RB_C1) {
>>> -gettimeofday(, NULL);
>>> -delta.tv_sec = now.tv_sec - i8253_channel[1].tv.tv_sec;
>>> -delta.tv_usec = now.tv_usec -
>>> -i8253_channel[1].tv.tv_usec;
>>> -if (delta.tv_usec < 0) {
>>> +clock_gettime(CLOCK_MONOTONIC, );
>>> +delta.tv_sec = now.tv_sec - i8253_channel[1].ts.tv_sec;
>>> +delta.tv_nsec = now.tv_nsec -
>>> +

video(1): measure with mono clock (tester wanted)

[Scott Cheloha]

So that your stats stay correct if the system clock is changed.

This is simple enough to suggest that it's correct at a glance,
but I have no hardware to test this with.  Can anyone confirm that
this works?

--
Scott Cheloha

Index: app/video/video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.23
diff -u -p -r1.23 video.c
--- app/video/video.c   26 Nov 2016 11:49:15 -  1.23
+++ app/video/video.c   6 Apr 2018 14:21:26 -
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1635,7 +1636,7 @@ int
 stream(struct video *vid)
 {
struct xdsp *x = >xdsp;
-   struct timeval tp_start, tp_now, tp_run;
+   struct timespec tp_start, tp_now, tp_run;
struct itimerval frit;
double run_time;
uint8_t *src;
@@ -1643,7 +1644,7 @@ stream(struct video *vid)
int sequence = 20, ret, err, todo, done;
 
/* Guard against uninitialized variable in case no frame is grabbed. */
-   gettimeofday(_start, NULL);
+   clock_gettime(CLOCK_MONOTONIC, _start);
 
if (vid->fps && !vid->nofps) {
fus = 100 / vid->fps;
@@ -1759,21 +1760,21 @@ stream(struct video *vid)
frames_played++;
 
if (frames_played == 0)
-   gettimeofday(_start, NULL);
+   clock_gettime(CLOCK_MONOTONIC, _start);
 
if (vid->verbose > 1 && frames_played > 0 &&
(frames_played) % sequence == 0) {
-   gettimeofday(_now, NULL);
-   timersub(_now, _start, _run);
+   clock_gettime(CLOCK_MONOTONIC, _now);
+   timespecsub(_now, _start, _run);
run_time = tp_run.tv_sec +
-   (double)tp_run.tv_usec / 100;
+   tp_run.tv_nsec / 10.0;
fprintf(stderr, "frames: %08ld, seconds: "
"%09.2f, fps: %08.5f\r", frames_played,
run_time, ((double)frames_played) / run_time);
fflush(stderr);
}
}
-   gettimeofday(_now, NULL);
+   clock_gettime(CLOCK_MONOTONIC, _now);
 
if (vid->fps) {
timerclear(_value);
@@ -1793,8 +1794,8 @@ stream(struct video *vid)
fprintf(stderr, "\n");
 
if (vid->verbose > 0) {
-   timersub(_now, _start, _run);
-   run_time = tp_run.tv_sec + (double)tp_run.tv_usec / 100;
+   timespecsub(_now, _start, _run);
+   run_time = tp_run.tv_sec + tp_run.tv_nsec / 10.0;
fprintf(stderr, "run time: %f seconds\n", run_time);
fprintf(stderr, "frames grabbed: %ld\n", frames_grabbed);
fprintf(stderr, "frames played: %ld\n", frames_played + 1);

Re: relayd http check fix

[Rivo Nurges]

Hi!

ping

Rivo

On Wed, 2018-03-28 at 16:56 +, Rivo Nurges wrote:
> Hi!
> 
> If relayd http check doesn't get any answer to its http check it
> marks
> backend host as up.
> 
> host x.y.z, check http code (2010ms,tcp read timeout), state down ->
> up, availability 14.29%
> 
> sample config:
> relay test {
>   listen on x.x.x.x port 
>   forward to  port  check http "/" code 200
> }
> 
> sample server:
> while :;do nc -l ;done
> 
> fix:
> Index: usr.sbin/relayd/check_tcp.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/check_tcp.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 check_tcp.c
> --- usr.sbin/relayd/check_tcp.c   4 Jul 2017 20:27:09 -   
> 1.55
> +++ usr.sbin/relayd/check_tcp.c   28 Mar 2018 16:45:38 -
> @@ -243,8 +243,10 @@ tcp_read_buf(int s, short event, void *a
>   if (event == EV_TIMEOUT) {
>   if (ibuf_size(cte->buf))
>   (void)cte->validate_close(cte);
> - else
> + else {
>   cte->host->he = HCE_TCP_READ_TIMEOUT;
> + cte->host->up = HOST_DOWN;
> + }   
>   tcp_close(cte, cte->host->up == HOST_UP ? 0 :
> HOST_DOWN);
>   hce_notify_done(cte->host, cte->host->he);
>   return;
> 

efi runtime services memory permissions

[Mark Kettenis]

Everything is crap.  That includes UEFI.  So apparently some UEFI
firmware thinks it is ok to write to the code segment.  And
technically the standard allows this unless the EFI_MEMORY_RO
attribute is set.  But of course nobody does.

Anyway, give in.  I'll still restrict setting PROT_EXEC a bit even if
it violates the standard.  At least until the first firmware shows up
that genuinly tries to execute code in the data segment.

ok?


Index: arch/arm64/dev/efi.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/efi.c,v
retrieving revision 1.3
diff -u -p -r1.3 efi.c
--- arch/arm64/dev/efi.c12 Jan 2018 14:52:55 -  1.3
+++ arch/arm64/dev/efi.c6 Apr 2018 10:19:41 -
@@ -125,7 +125,7 @@ efi_attach(struct device *parent, struct
vaddr_t va = desc->VirtualStart;
paddr_t pa = desc->PhysicalStart;
int npages = desc->NumberOfPages;
-   vm_prot_t prot = PROT_READ;
+   vm_prot_t prot = PROT_READ | PROT_WRITE;
 
 #ifdef EFI_DEBUG
printf("type 0x%x pa 0x%llx va 0x%llx pages 0x%llx attr 
0x%llx\n",
@@ -142,10 +142,20 @@ efi_attach(struct device *parent, struct
if ((desc->Attribute & EFI_MEMORY_WB) == 0)
pa |= PMAP_DEVICE;
 
+   /*
+* Only make pages marked as runtime service code
+* executable.  This violates the standard but it
+* seems we can get away with it.
+*/
if (desc->Type == EfiRuntimeServicesCode)
prot |= PROT_EXEC;
-   else
-   prot |= PROT_WRITE;
+
+   if (desc->Attribute & EFI_MEMORY_RP)
+   prot &= ~PROT_READ;
+   if (desc->Attribute & EFI_MEMORY_XP)
+   prot &= ~PROT_EXEC;
+   if (desc->Attribute & EFI_MEMORY_RO)
+   prot &= ~PROT_WRITE;
 
while (npages--) {
pmap_enter(sc->sc_pm, va, pa, prot,

Make ppb(4) initialize I/O window register

[Mark Kettenis]

When memory mapped I/O isn't enabled, we disable the associated
windows.  Do the same for "port" I/O.  Otherwise we will (incorrectly)
advertise that I/O space is available to devices downstream from the
bridge.

ok?


Index: dev/pci/ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.65
diff -u -p -r1.65 ppb.c
--- dev/pci/ppb.c   1 Dec 2015 21:02:04 -   1.65
+++ dev/pci/ppb.c   6 Apr 2018 09:07:24 -
@@ -620,14 +620,18 @@ ppb_alloc_resources(struct ppb_softc *sc
csr = pci_conf_read(pc, sc->sc_tag, PCI_COMMAND_STATUS_REG);
 
/*
-* Get the bridge in a consistent state.  If memory mapped I/O
-* is disabled, disabled the associated windows as well.  
+* Get the bridge in a consistent state.  If memory mapped I/O or
+* port I/O is disabled, disabled the associated windows as well.
 */
if ((csr & PCI_COMMAND_MEM_ENABLE) == 0) {
pci_conf_write(pc, sc->sc_tag, PPB_REG_MEM, 0x);
pci_conf_write(pc, sc->sc_tag, PPB_REG_PREFMEM, 0x);
pci_conf_write(pc, sc->sc_tag, PPB_REG_PREFBASE_HI32, 0);
pci_conf_write(pc, sc->sc_tag, PPB_REG_PREFLIM_HI32, 0);
+   }
+   if ((csr & PCI_COMMAND_IO_ENABLE) == 0) {
+   pci_conf_write(pc, sc->sc_tag, PPB_REG_IOSTATUS, 0x00ff);
+   pci_conf_write(pc, sc->sc_tag, PPB_REG_IO_HI, 0x);
}
 
/* Allocate I/O address space if necessary. */

Re: plug memory leak in ASN1_item_digest

[Brent Cook]

ok bcook@

On Thu, Apr 5, 2018 at 12:06 PM, Theo Buehler  wrote:

> If EVP_Digest() fails, str is leaked.
>
> This is part of the combo-diff 83b4049ab75e9da1815e9c854a9297bca3d4af6b
> some more of which may also apply to us, but I'm still disentangling it.
> See also https://github.com/openssl/openssl/issues/2111
>
> Index: lib/libcrypto/asn1/a_digest.c
> ===
> RCS file: /var/cvs/src/lib/libcrypto/asn1/a_digest.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 a_digest.c
> --- lib/libcrypto/asn1/a_digest.c   11 Jul 2014 08:44:47 -
> 1.15
> +++ lib/libcrypto/asn1/a_digest.c   5 Apr 2018 16:46:22 -
> @@ -77,8 +77,11 @@ ASN1_item_digest(const ASN1_ITEM *it, co
> if (!str)
> return (0);
>
> -   if (!EVP_Digest(str, i, md, len, type, NULL))
> -   return 0;
> +   if (!EVP_Digest(str, i, md, len, type, NULL)) {
> +   free(str);
> +   return (0);
> +   }
> +
> free(str);
> return (1);
>  }
>
>