Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

[Thor Lancelot Simon]

On Wed, Mar 29, 2017 at 11:53:55AM +0200, Edgar Fu? wrote:
> > It needs to do this [flush disc cache after committing journal] because 
> > it needs to make sure that journal data are saved before we save the 
> > journal commit block.
> So the point is to force an order (data before commit block).
> 
> > Implicitly, the pre-commit flush also makes sure that all asynchronously 
> > written metadata updates are written to the media, before the commit makes
> > them impossible to replay.
> So the point is do force an order (metadata before journal).
> 
> > Even SCSI ORDERED tags wouldn't help to avoid the need for cache flushes.
> So why that if the point of the cache flushes is to ensure an order?

It doesn't make sense to me either.  ORDERED tags are required not to complete
until all previously submitted SIMPLE and ORDERED tags have been committed to
stable storage; and if that's not enough, you can, I believe, use a HEAD tag.
Why isn't that good enough?

If the answer is that you're running with WCE on in the mode pages, then
don't do that: use SIMPLE tags for all writes except when you intend a
barrier, and ORDERED when you do.  I must be missing something.

-- 
 Thor Lancelot Simon  t...@panix.com

Cry, the beloved country, for the unborn child that is the
inheritor of our fear.  -Alan Paton

Re: Add a mountlist iterator

[Christos Zoulas]

In article <534552fb-af29-4219-8390-7514a2665...@eis.cs.tu-bs.de>,
J. Hannken-Illjes  wrote:
>Currently vfs_busy() / vfs_unbusy() get used to
>
>- Enter/leave a critical section against unmounting
>
>- Add a reference to the mount
>
>- return the next mount from the mountlist on error
>
>Plan is to untangle the mountlist processing from vfs_busy() / vfs_unbusy()
>and add an iterator for the mountlist:
>
>- void mountlist_iterator_init(mount_iterator_t **)
>  to initialize an iterator in mounted order.
>
>- void mountlist_iterator_init_reverse(mount_iterator_t **)
>  to initialize an iterator in reverse mounted order.
>
>- void mountlist_iterator_destroy(mount_iterator_t *)
>  to destroy an iterator aquired with one of the above.
>
>- struct mount *mountlist_iterator_next(mount_iterator_t *, int)
>  to retrieve the next mount from an iterator or NULL if done.
>  The mount is returned vfs_busy'd, caller has to vfs_unbusy.
>  Accepts a flag MNT_NOWAIT to skip mounts whose unmount is in progress.
>
>- struct mount *_mountlist_next(struct mount *)
>  a lockless variant to be used from DDB only.
>
>Diffs are here: https://www.netbsd.org/~hannken/ml_iterator/
>
>Comments or objections anyone?

LGTM, but can't all the copies of the dostatvfs iteration be merged
together and utilize a converter function to handle the data massaging?

christos

Re: PCI BAR's prefetchable bit and pci_mapreg_map()

[Mouse]

> The plan E is OK, but it makes code duplication and the [code] won't
> be simple.  To make code simple,

How does it lead to code duplication?

Also, it seems to me correctness has higher priority tha simplicity.
And plan A

>>  A) modify pci_mapreg_map().  Stop setting
>>  BUS_SPACE_MAP_PREFETCHABLE by defalut when prefetchable bit is set.
>>  If a driver really know[s] the whole area of the BAR is
>>  prefetchable, set BUS_SPACE_MAP_PREFETCHABLE in the 4th
>>  argument(busflags) of pci_mapreg_map().  pci_mapreg_map() check[s]
>>  for both the 4th argument and the prefetchable bit, it sets
>>  BUS_SPACE_MAP_PREFETCHABLE only when both bits are set.

doesn't sound correct to me, in view of the devices mentioned upthread
that actually are prefetchable but which don't set the prefetchable BAR
bit: they won't get prefetch under plan A.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Add a mountlist iterator

[J. Hannken-Illjes]

Currently vfs_busy() / vfs_unbusy() get used to

- Enter/leave a critical section against unmounting

- Add a reference to the mount

- return the next mount from the mountlist on error

Plan is to untangle the mountlist processing from vfs_busy() / vfs_unbusy()
and add an iterator for the mountlist:

- void mountlist_iterator_init(mount_iterator_t **)
  to initialize an iterator in mounted order.

- void mountlist_iterator_init_reverse(mount_iterator_t **)
  to initialize an iterator in reverse mounted order.

- void mountlist_iterator_destroy(mount_iterator_t *)
  to destroy an iterator aquired with one of the above.

- struct mount *mountlist_iterator_next(mount_iterator_t *, int)
  to retrieve the next mount from an iterator or NULL if done.
  The mount is returned vfs_busy'd, caller has to vfs_unbusy.
  Accepts a flag MNT_NOWAIT to skip mounts whose unmount is in progress.

- struct mount *_mountlist_next(struct mount *)
  a lockless variant to be used from DDB only.

Diffs are here: https://www.netbsd.org/~hannken/ml_iterator/

Comments or objections anyone?

--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: Restricting rdtsc [was: kernel aslr]

[Steffen Nurpmeso]

Maxime Villard  wrote:
 |Having read several papers on the exploitation of cache latency to defeat
 |aslr (kernel or not), it appears that disabling the rdtsc instruction is a
 |good mitigation on x86. However, some applications can legitimately use it,
 |so I would rather suggest restricting it to root instead.

I have used it for random noise in user space.  I don't want to
paste it, it is so ridiculous…, but then again a nice example of
user space horror – you may skip the rest at your will.

 |The idea is simple: we set CR4_TSD in %cr4, the first time an application
 |uses rdtsc it faults, we look at the creds of the lwp, if it is root we

I used it to add noise to my ARC4 random generator upon ()()/call()
time, as in

// strong (noisy) generator?
if(m_d.flags & f_strong) {
#if(__HAVE_RAND_CRYPTOHW)
if(__RAND_CRYPTOHW_OK) {
ret = ::__sf_sys_misc_rand_Strong();
goto jout;
} else
#endif
addNoise();
}


where this was

#if(__HAVE_RAND_CRYPTOHW)
if(!m_d.enpy)
goto jout;
#endif
#if(!__HAVE_RAND_NOISE)
ep.now().setSecond(ep.second() ^ ep.microsecond())
.setMicrosecond(_WEAK(ep.microsecond()));
addNoise(ep.tv(), szof(Epoch::TimeVal));
#else   
x = ::__sf_sys_misc_rand_Noise();
stack[0] = x;
x = _WEAK(x);
stack[1] = x;
addNoise(stack, szof(stack));
#endif
#if(__HAVE_RAND_CRYPTOHW)
jout:
#endif  

and that with args did a loop that used "random" bytes of the
given "stack" as noise additions to the internal entropy (and
doing one ARC4 stir after each addition).

 |What about this?

No longer of any value, it seems to me.

--steffen