On Thu, Dec 27, 2018 at 09:39:56AM +0100, Otto Moerbeek wrote:
>
> Very little feedback so far. This diff can only give me valid feedback
> if the coverage of systems and use cases is wide. If I do not get
> more feedback, I have to base my decisions on my own testing, which
> will benefit my sy
> unveil isn't really buying much if you pledge "rpath" immediately after,
> so if you want just add another pledge here instead, that is fine.
"rpath" is obviously cheaper than unveil of even 1 file.
On Thu, Jan 03, 2019 at 08:26:00PM -0500, Ted Unangst wrote:
> Ted Unangst wrote:
> > Bryan Steele wrote:
> > > It is not possible to unveil(2) all arguments passed to file(1), as this
> > > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > > readonly access to the entire
Ted Unangst wrote:
> Ted Unangst wrote:
> > Bryan Steele wrote:
> > > It is not possible to unveil(2) all arguments passed to file(1), as this
> > > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > > readonly access to the entire filesystem, while restricting all execut
Ted Unangst wrote:
> Bryan Steele wrote:
> > It is not possible to unveil(2) all arguments passed to file(1), as this
> > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > readonly access to the entire filesystem, while restricting all execute
> > write, and create opera
Ted Unangst wrote:
> Bryan Steele wrote:
> > It is not possible to unveil(2) all arguments passed to file(1), as this
> > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > readonly access to the entire filesystem, while restricting all execute
> > write, and create operati
Bryan Steele wrote:
> It is not possible to unveil(2) all arguments passed to file(1), as this
> would require walking *argv. Instead, we can unveil("/", "r") to permit
> readonly access to the entire filesystem, while restricting all execute
> write, and create operations.
Why not? Because of the
It is not possible to unveil(2) all arguments passed to file(1), as this
would require walking *argv. Instead, we can unveil("/", "r") to permit
readonly access to the entire filesystem, while restricting all execute
write, and create operations.
This only provides some additional early protection
ok by me.
> On 3 Jan 2019, at 21:47, Jonathan Gray wrote:
>
> On Wed, Jan 02, 2019 at 04:08:53PM +1000, David Gwynne wrote:
>> This makes it more obvious what interesting things there are to hack on.
>>
>> Thoughts? ok?
>>
>> For example, from an od1000:
>>
>> dlg@o1000 fdt$ dmesg | grep 'not
> On 3 Jan 2019, at 20:54, Mark Kettenis wrote:
>
>> Date: Thu, 3 Jan 2019 12:53:58 +1000
>> From: David Gwynne
>>
>> this adds support for the ohci controllers seen on the pine64.
>>
>> it is very quick and very dirty, but it works. i'm able to use a usb1
>> serial dongle now where it didn
Hello,
On Thu, Jan 03, 2019 at 08:22:52PM +0100, Klemens Nanni wrote:
> In pfctl_optimize.c r1.39 I removed the `af' parameter from `unmask()'
> but accidently zapped the macro's closing paranthese.
>
> Since DEBUG() is needlessly under an OPT_DEBUG guard here, this was not
> effecting normal bui
In pfctl_optimize.c r1.39 I removed the `af' parameter from `unmask()'
but accidently zapped the macro's closing paranthese.
Since DEBUG() is needlessly under an OPT_DEBUG guard here, this was not
effecting normal builds.
Add the missing ')' and remove the ifdef.
Relevant defines includede here
On Thu, Jan 03, 2019 at 04:06:25PM +0100, Janne Johansson wrote:
> Den tors 3 jan. 2019 kl 15:25 skrev Visa Hankala :
> >
> > On Thu, Jan 03, 2019 at 01:16:05PM +0300, Mikhael Skvortsov wrote:
> > > Tested by running GENERIC.MP built by
> > > make CC=clang COMPILER_VERSION=clang
> > > on a CN6120 d
Den tors 3 jan. 2019 kl 15:25 skrev Visa Hankala :
>
> On Thu, Jan 03, 2019 at 01:16:05PM +0300, Mikhael Skvortsov wrote:
> > Tested by running GENERIC.MP built by
> > make CC=clang COMPILER_VERSION=clang
> > on a CN6120 device.
[...]
> > Index: sys/arch/octeon/dev/octcrypto_asm.S
> > =
On Thu, Jan 03, 2019 at 01:16:05PM +0300, Mikhael Skvortsov wrote:
> Tested by running GENERIC.MP built by
> make CC=clang COMPILER_VERSION=clang
> on a CN6120 device.
Thank you. I have something similar pending and will commit soonish.
Certain things have to be done in concert with loongson and s
On 1/3/19 11:08 AM, leo_...@volny.cz wrote:
> Alright, these ones get rid of is_stdin altogether. Isn't it better this
> way?
>
Looks OK to me, anyone else want to OK this?
martijn@
>--zeurkous.
>
> Index: src/usr.bin/tail/extern.h
>
On Wed, Jan 02, 2019 at 04:08:53PM +1000, David Gwynne wrote:
> This makes it more obvious what interesting things there are to hack on.
>
> Thoughts? ok?
>
> For example, from an od1000:
>
> dlg@o1000 fdt$ dmesg | grep 'not configured'
The whitespace is wrong on 'return (UNCONF)'
The same dif
Alright, these ones get rid of is_stdin altogether. Isn't it better this
way?
--zeurkous.
Index: src/usr.bin/tail/extern.h
===
RCS file: /cvs/src/usr.bin/tail/extern.h,v
retrieving revision 1.12
diff -u -p -r1.12 extern.h
---
> Date: Thu, 3 Jan 2019 12:53:58 +1000
> From: David Gwynne
>
> this adds support for the ohci controllers seen on the pine64.
>
> it is very quick and very dirty, but it works. i'm able to use a usb1
> serial dongle now where it didnt even connect before.
Heh, I thought there would be some ehc
> From: David Gwynne
> Date: Thu, 3 Jan 2019 09:39:29 +1000
>
> > On 2 Jan 2019, at 21:16, Mark Kettenis wrote:
> >
> >> dlg@o1000 fdt$ dmesg | grep 'not configured'
> >> "v2m" at ampintc0 not configured
> >
> > Hmm, ampintcmsi(4) should attach to that one. Doesn't it attach
> > on your machi
Tested by running GENERIC.MP built by
make CC=clang COMPILER_VERSION=clang
on a CN6120 device.
Index: sys/arch/mips64/mips64/fp_emulate.c
===
RCS file: /cvs/src/sys/arch/mips64/mips64/fp_emulate.c,v
retrieving revision 1.20
diff -u -
21 matches
Mail list logo
