Re: autoinstall(8): using multiple set sources?
On August 7, 2015 9:10:06 PM GMT+02:00, Philipp wrote: >While heavy playing with autoinstall(8), I came across that I cannot >make it happen to >install the usual sets from CD/ISO and additional ones like site58.tgz >from a webserver. > >install.conf snips: >root disk = wd0 >Use (W)hole disk = W >Location of sets = cd >Set name(s) = all Try adding Set name(s) = done Here, like you would manually do (albeit likely implicit by just pressing enter). /Alexander >Location of sets = http >HTTP Server = 192.168.2.101 >Server directory = / >Set = all >site58.tgz = yes > >The problem is the way the answers are popped; if I ctrl-c the >installer >after the first >set selection, both 'Set' and 'Set name(s)' are already removed from >/ai.conf. > >The site58.tgz will be shown as available, but wont be selected. > >Actually one will see that 'all' is being used twice on the first >selection - and that comes >from: select_sets() > for resp in $resp; do > >Cannot provide a diff to deal with it.. only idea I had so far is >including the install-method >into the 'ask' for sets.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Christian Schulte schulte.it> writes: > > Now, I believe that this effort is too much for my spare time. > > Then why not release that scanner? That effort could be shared. What's > so secret about it? You have been asked several times already. Start sharing right now. Brainy OpenBSD page contains info about lot of bugs already found. There is no secret to start writing diffs and pushing them.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Am 08/07/15 um 21:55 schrieb Maxime Villard: Developing, improving and maintaining Brainy takes time and energy, as well as investigating and packaging the bugs and vulnerabilities it finds. I've so far sent some reports here just because I'm "friendly" enough, and because modifying a few things for Brainy to properly understand the OpenBSD code does not require a Herculean work. Now, I believe that this effort is too much for my spare time. Then why not release that scanner? That effort could be shared. What's so secret about it? You have been asked several times already. Regards, -- Christian Schulte
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Hi Maxime, Hi Sam, I have been following this thread (and others) for some time. On Fri, Aug 07, 2015 at 09:55:21PM +0200, Maxime Villard wrote: > Well, I guess I'll have to admit that I find your attitude extremely > disrespectful. I have to agree that the emails are rather short and tend to lack the subtle cues of human face-to-face interaction. They can easily get out of hand. > Le 21/07/2015 12:31, sam a écrit : > >On Tue, 21 Jul 2015 11:31:44 +0200 > >Maxime Villard wrote: > > > >>Found by The Brainy Code Scanner. > >> > >>It is not the last bug Brainy has found, but it is the last one I > >>report. I don't have time for that. > >> > > > >How about you release the Brainy Code Scanner then? Maxime, I have to agree with Sam here. I did check your website, but have not found any code there. It would be of great help if you would release it. > >"I have so many bugs; in fact, there are so many, I don't even have the > >time to report them! My scanner is so good!" > > > >Or perhaps you should report 'just' the relatively important ones? > > I think my work does (or used to) benefit to a lot of users, developers > and vendors here; a lot of people, including you. Sam, I think Maxime has done good work so far. There is no reason to mock the work or the person. I thought the motto is "Shut Up and Hack!" and not "Ridicule and Hack!". > Nobody supports my work, and I've never asked for anything here about > that. Even though I almost never receive a simple "thank you" for all > the bugs and vulnerabilities I've so far reported, I still expect a > "spiritual thank you" for my work. Yes, this is a common problem. Hence: Thank you Maxime! Thank you for all the bugs you (and Brainy) have found so far. > Developing, improving and maintaining Brainy takes time and energy, as > well as investigating and packaging the bugs and vulnerabilities it > finds. You could share that burden. I am willing to give it a shot. shun
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Maxime Villard [m...@m00nbsd.net] wrote: > > Now, I believe that this effort is too much for my spare time. If you > want to say "thanks" to me for reporting this vulnerability, dear Sam, > it's never too late. > I put here a thanks among others: Thank you for your effort to help improve the OpenBSD operating system, to the benefit of its users, developers, and the many others who are using the code in their own systems. Your work is appreciated, each commit fixing a bug that you found is perhaps the spiritual thank-you of which you have detected the subtle presence :) Chris
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Well, I guess I'll have to admit that I find your attitude extremely disrespectful. But I don't tend to feel particularly offended by this kind of things, so it probably does not matter. Le 21/07/2015 12:31, sam a écrit : On Tue, 21 Jul 2015 11:31:44 +0200 Maxime Villard wrote: Found by The Brainy Code Scanner. It is not the last bug Brainy has found, but it is the last one I report. I don't have time for that. How about you release the Brainy Code Scanner then? "I have so many bugs; in fact, there are so many, I don't even have the time to report them! My scanner is so good!" Or perhaps you should report 'just' the relatively important ones? I think my work does (or used to) benefit to a lot of users, developers and vendors here; a lot of people, including you. Nobody supports my work, and I've never asked for anything here about that. Even though I almost never receive a simple "thank you" for all the bugs and vulnerabilities I've so far reported, I still expect a "spiritual thank you" for my work. But I certainly do not expect that kind of emails you just sent, somehow trying to either make fun of me or disregard what I'm willing to spend my spare time on for you. Developing, improving and maintaining Brainy takes time and energy, as well as investigating and packaging the bugs and vulnerabilities it finds. I've so far sent some reports here just because I'm "friendly" enough, and because modifying a few things for Brainy to properly understand the OpenBSD code does not require a Herculean work. Now, I believe that this effort is too much for my spare time. If you want to say "thanks" to me for reporting this vulnerability, dear Sam, it's never too late. Maxime
autoinstall(8): using multiple set sources?
While heavy playing with autoinstall(8), I came across that I cannot make it happen to install the usual sets from CD/ISO and additional ones like site58.tgz from a webserver. install.conf snips: root disk = wd0 Use (W)hole disk = W Location of sets = cd Set name(s) = all Location of sets = http HTTP Server = 192.168.2.101 Server directory = / Set = all site58.tgz = yes The problem is the way the answers are popped; if I ctrl-c the installer after the first set selection, both 'Set' and 'Set name(s)' are already removed from /ai.conf. The site58.tgz will be shown as available, but wont be selected. Actually one will see that 'all' is being used twice on the first selection - and that comes from: select_sets() for resp in $resp; do Cannot provide a diff to deal with it.. only idea I had so far is including the install-method into the 'ask' for sets.
Octeon opcode extensions for binutils
Hi,
the following diff adds Octeon specific opcodes support to our binutils.
For now I just added the sync opcodes which are needed for the bus
barrier routines. (From what I read this will be useful not only for SMP
but also for DMA.)
I've tested it on my Octeon machines with the syncw instruction and
everything seems fine.
Is this acceptable?
Index: bfd/archures.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/archures.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 archures.c
--- bfd/archures.c 24 Apr 2011 20:14:41 - 1.1.1.1
+++ bfd/archures.c 7 Aug 2015 15:44:40 -
@@ -160,6 +160,7 @@ DESCRIPTION
.#define bfd_mach_mips16 16
.#define bfd_mach_mips5 5
.#define bfd_mach_mips_sb1 12310201 {* octal 'SB', 01 *}
+.#define bfd_mach_mips_octeon 6501
.#define bfd_mach_mipsisa32 32
.#define bfd_mach_mipsisa32r2 33
.#define bfd_mach_mipsisa64 64
Index: bfd/bfd-in2.h
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/bfd-in2.h,v
retrieving revision 1.4
diff -u -p -r1.4 bfd-in2.h
--- bfd/bfd-in2.h 25 May 2015 14:56:26 - 1.4
+++ bfd/bfd-in2.h 7 Aug 2015 15:44:41 -
@@ -1758,6 +1758,7 @@ enum bfd_architecture
#define bfd_mach_mips1616
#define bfd_mach_mips5 5
#define bfd_mach_mips_sb1 12310201 /* octal 'SB', 01 */
+#define bfd_mach_mips_octeon 6501
#define bfd_mach_mipsisa32 32
#define bfd_mach_mipsisa32r2 33
#define bfd_mach_mipsisa64 64
Index: bfd/cpu-mips.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/cpu-mips.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 cpu-mips.c
--- bfd/cpu-mips.c 24 Apr 2011 20:14:41 - 1.1.1.1
+++ bfd/cpu-mips.c 7 Aug 2015 15:44:41 -
@@ -86,6 +86,7 @@ enum
I_mipsisa64,
I_mipsisa64r2,
I_sb1,
+ I_mipsocteon,
};
#define NN(index) (&arch_info_struct[(index) + 1])
@@ -118,7 +119,8 @@ static const bfd_arch_info_type arch_inf
N (32, 32, bfd_mach_mipsisa32r2,"mips:isa32r2", FALSE, NN(I_mipsisa32r2)),
N (64, 64, bfd_mach_mipsisa64, "mips:isa64", FALSE, NN(I_mipsisa64)),
N (64, 64, bfd_mach_mipsisa64r2,"mips:isa64r2", FALSE, NN(I_mipsisa64r2)),
- N (64, 64, bfd_mach_mips_sb1, "mips:sb1", FALSE, 0),
+ N (64, 64, bfd_mach_mips_sb1, "mips:sb1", FALSE, NN(I_sb1)),
+ N (64, 64, bfd_mach_mips_octeon,"mips:octeon", FALSE, 0),
};
/* The default architecture is mips:3000, but with a machine number of
Index: bfd/elfxx-mips.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/elfxx-mips.c,v
retrieving revision 1.4
diff -u -p -r1.4 elfxx-mips.c
--- bfd/elfxx-mips.c22 Dec 2014 14:17:22 - 1.4
+++ bfd/elfxx-mips.c7 Aug 2015 15:44:42 -
@@ -4967,6 +4967,9 @@ _bfd_elf_mips_mach (flagword flags)
case E_MIPS_MACH_SB1:
return bfd_mach_mips_sb1;
+case E_MIPS_MACH_OCTEON:
+ return bfd_mach_mips_octeon;
+
default:
switch (flags & EF_MIPS_ARCH)
{
@@ -9033,6 +9036,10 @@ mips_set_isa_flags (bfd *abfd)
val = E_MIPS_ARCH_64 | E_MIPS_MACH_SB1;
break;
+case bfd_mach_mips_octeon:
+ val = E_MIPS_ARCH_64R2 | E_MIPS_MACH_OCTEON;
+ break;
+
case bfd_mach_mipsisa32:
val = E_MIPS_ARCH_32;
break;
@@ -10714,6 +10721,9 @@ struct mips_mach_extension {
are ordered topologically with MIPS I extensions listed last. */
static const struct mips_mach_extension mips_mach_extensions[] = {
+ /* MIPS64r2 extensions. */
+ { bfd_mach_mips_octeon, bfd_mach_mipsisa64r2 },
+
/* MIPS64 extensions. */
{ bfd_mach_mipsisa64r2, bfd_mach_mipsisa64 },
{ bfd_mach_mips_sb1, bfd_mach_mipsisa64 },
Index: gas/config/tc-mips.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/gas/config/tc-mips.c,v
retrieving revision 1.3
diff -u -p -r1.3 tc-mips.c
--- gas/config/tc-mips.c7 Jan 2013 22:23:05 - 1.3
+++ gas/config/tc-mips.c7 Aug 2015 15:44:43 -
@@ -14402,6 +14402,9 @@ static const struct mips_cpu_info mips_c
{ "loongson2f", 0, ISA_L2F,CPU_L2F },
*/
+ /* Cavium Networks Octeon CPU core */
+ { "octeon", 0, ISA_MIPS64R2, CPU_OCTEON },
+
/* MIPS IV */
{ "r8000", 0, ISA_MIPS4, CPU_R8000 },
{ "r1", 0, ISA_MIPS4, CPU_R1 },
Index: include/elf/mips.h
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/include/elf/mips.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 mips.h
--- include/elf/mips.h 24 Apr 2011 20:14:48 -000
Re: [PATCH] tftpd, rdomain
2015-08-07 4:40 GMT-04:00 Peter Hessler : > Thank you for the submission, but we prefer using "route -T [rdomain] > exec [program]" for programs that do not modify routes. I didn't know this command, thank you. 2015-08-07 4:40 GMT-04:00 Peter Hessler : > Additionally, your mailer ate the whitespace from the diff, and messed > up style(9). Sorry for this, I don't have much options on gmail for this, that's why I added a link to it on pastebin, but I thought this was good, I'll try to find a solution. -- Bertrand PROVOST
Re: [PATCH] tftpd, rdomain
Hi Betrand
Thank you for the submission, but we prefer using "route -T [rdomain]
exec [program]" for programs that do not modify routes.
Additionally, your mailer ate the whitespace from the diff, and messed
up style(9).
On 2015 Aug 06 (Thu) at 12:26:19 -0400 (-0400), Bertrand PROVOST wrote:
:Hi,
:
:this diff add rdomain support to tftpd.
:It used setsockopt/SO_RTABLE like in ping program.
:
:Alternatively I could use `setrtable` once instead of multiple setsockopt.
:
:I don't know which method is the best in this case.
:
:http://pastebin.com/7jBU78fc
:
:
:Index: tftpd.8
:===
:RCS file: /cvs/src/usr.sbin/tftpd/tftpd.8,v
:retrieving revision 1.4
:diff -u -p -r1.4 tftpd.8
:--- tftpd.8 4 Mar 2012 07:26:51 - 1.4
:+++ tftpd.8 6 Aug 2015 16:10:19 -
:@@ -41,6 +41,7 @@
: .Op Fl l Ar address
: .Op Fl p Ar port
: .Op Fl r Ar socket
:+.Op Fl V Ar rtable
: .Ar directory
: .Sh DESCRIPTION
: .Nm
:@@ -119,6 +120,8 @@ By default
: does not use filename rewriting.
: .It Fl v
: Log the client IP, type of request, and filename.
:+.It Fl V Ar rtable
:+Set the routing table to be used for listening connections.
: .It Ar directory
: .Xr chroot 2
: to
:Index: tftpd.c
:===
:RCS file: /cvs/src/usr.sbin/tftpd/tftpd.c,v
:retrieving revision 1.26
:diff -u -p -r1.26 tftpd.c
:--- tftpd.c 16 Jan 2015 06:40:22 - 1.26
:+++ tftpd.c 6 Aug 2015 16:10:19 -
:@@ -260,13 +260,14 @@ __dead void
: usage(void)
: {
: extern char *__progname;
:- fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]"
:+ fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]
:[-V rtable]"
: " directory\n", __progname);
: exit(1);
: }
:
: int cancreate = 0;
: int verbose = 0;
:+int rtableid = -1;
:
: int
: main(int argc, char *argv[])
:@@ -283,8 +284,9 @@ main(int argc, char *argv[])
: char *addr = NULL;
: char *port = "tftp";
: int family = AF_UNSPEC;
:+ const char *errstr;
:
:- while ((c = getopt(argc, argv, "46cdl:p:r:v")) != -1) {
:+ while ((c = getopt(argc, argv, "46cdl:p:r:vV:")) != -1) {
: switch (c) {
: case '4':
: family = AF_INET;
:@@ -310,6 +312,13 @@ main(int argc, char *argv[])
: case 'v':
: verbose = 1;
: break;
:+ case 'V':
:+ rtableid = (unsigned int)strtonum(optarg, 0,
:+RT_TABLEID_MAX, &errstr);
:+ if (errstr)
:+ errx(1, "rtable value is %s: %s",
:+errstr, optarg);
:+ break;
: default:
: usage();
: /* NOTREACHED */
:@@ -537,6 +546,15 @@ tftpd_listen(const char *addr, const cha
: continue;
: }
:
:+ if (rtableid != -1) {
:+ if (setsockopt(s, SOL_SOCKET, SO_RTABLE, &rtableid,
:+sizeof(rtableid)) == -1) {
:+ cause = "setsockopt SO_RTABLE";
:+ cerrno = errno;
:+ continue;
:+ }
:+ }
:+
: if (bind(s, res->ai_addr, res->ai_addrlen) == -1) {
: cause = "bind";
: cerrno = errno;
:@@ -674,6 +692,15 @@ tftpd_recv(int fd, short events, void *a
: lwarn("socket");
: goto err;
: }
:+
:+ if (rtableid != -1) {
:+ if (setsockopt(client->sock, SOL_SOCKET, SO_RTABLE, &rtableid,
:+sizeof(rtableid)) == -1) {
:+ lwarn("setsockopt SO_RTABLE");
:+ goto err;
:+ }
:+ }
:+
: memset(&s_in, 0, sizeof(s_in));
: s_in.ss_family = client->ss.ss_family;
: s_in.ss_len = client->ss.ss_len;
:
:--
:Bertrand PROVOST
:
--
The camel has a single hump;
The dromedary two;
Or else the other way around.
I'm never sure. Are you?
-- Ogden Nash
Re: [PATCH] tftpd, rdomain
you cant get the same functionality with route exec?
> On 7 Aug 2015, at 2:26 am, Bertrand PROVOST
> wrote:
>
> Hi,
>
> this diff add rdomain support to tftpd.
> It used setsockopt/SO_RTABLE like in ping program.
>
> Alternatively I could use `setrtable` once instead of multiple setsockopt.
>
> I don't know which method is the best in this case.
>
> http://pastebin.com/7jBU78fc
>
>
> Index: tftpd.8
> ===
> RCS file: /cvs/src/usr.sbin/tftpd/tftpd.8,v
> retrieving revision 1.4
> diff -u -p -r1.4 tftpd.8
> --- tftpd.8 4 Mar 2012 07:26:51 - 1.4
> +++ tftpd.8 6 Aug 2015 16:10:19 -
> @@ -41,6 +41,7 @@
> .Op Fl l Ar address
> .Op Fl p Ar port
> .Op Fl r Ar socket
> +.Op Fl V Ar rtable
> .Ar directory
> .Sh DESCRIPTION
> .Nm
> @@ -119,6 +120,8 @@ By default
> does not use filename rewriting.
> .It Fl v
> Log the client IP, type of request, and filename.
> +.It Fl V Ar rtable
> +Set the routing table to be used for listening connections.
> .It Ar directory
> .Xr chroot 2
> to
> Index: tftpd.c
> ===
> RCS file: /cvs/src/usr.sbin/tftpd/tftpd.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 tftpd.c
> --- tftpd.c 16 Jan 2015 06:40:22 - 1.26
> +++ tftpd.c 6 Aug 2015 16:10:19 -
> @@ -260,13 +260,14 @@ __dead void
> usage(void)
> {
> extern char *__progname;
> - fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]"
> + fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]
> [-V rtable]"
> " directory\n", __progname);
> exit(1);
> }
>
> int cancreate = 0;
> int verbose = 0;
> +int rtableid = -1;
>
> int
> main(int argc, char *argv[])
> @@ -283,8 +284,9 @@ main(int argc, char *argv[])
> char *addr = NULL;
> char *port = "tftp";
> int family = AF_UNSPEC;
> + const char *errstr;
>
> - while ((c = getopt(argc, argv, "46cdl:p:r:v")) != -1) {
> + while ((c = getopt(argc, argv, "46cdl:p:r:vV:")) != -1) {
> switch (c) {
> case '4':
> family = AF_INET;
> @@ -310,6 +312,13 @@ main(int argc, char *argv[])
> case 'v':
> verbose = 1;
> break;
> + case 'V':
> + rtableid = (unsigned int)strtonum(optarg, 0,
> +RT_TABLEID_MAX, &errstr);
> + if (errstr)
> + errx(1, "rtable value is %s: %s",
> +errstr, optarg);
> + break;
> default:
> usage();
> /* NOTREACHED */
> @@ -537,6 +546,15 @@ tftpd_listen(const char *addr, const cha
> continue;
> }
>
> + if (rtableid != -1) {
> + if (setsockopt(s, SOL_SOCKET, SO_RTABLE, &rtableid,
> +sizeof(rtableid)) == -1) {
> + cause = "setsockopt SO_RTABLE";
> + cerrno = errno;
> + continue;
> + }
> + }
> +
> if (bind(s, res->ai_addr, res->ai_addrlen) == -1) {
> cause = "bind";
> cerrno = errno;
> @@ -674,6 +692,15 @@ tftpd_recv(int fd, short events, void *a
> lwarn("socket");
> goto err;
> }
> +
> + if (rtableid != -1) {
> + if (setsockopt(client->sock, SOL_SOCKET, SO_RTABLE, &rtableid,
> +sizeof(rtableid)) == -1) {
> + lwarn("setsockopt SO_RTABLE");
> + goto err;
> + }
> + }
> +
> memset(&s_in, 0, sizeof(s_in));
> s_in.ss_family = client->ss.ss_family;
> s_in.ss_len = client->ss.ss_len;
>
> --
> Bertrand PROVOST
small mv patch
Hello tech@,
I was reading mv.c and found two minor things in fastcopy:
1) fd leak on seldom reached code
2) At the end of the function utimes is called, while the rest of the
code calls the f* variant. Consistency fix.
Index: mv.c
===
RCS file: /cvs/src/bin/mv/mv.c,v
retrieving revision 1.38
diff -u -p -r1.38 mv.c
--- mv.c16 Jan 2015 06:39:32 - 1.38
+++ mv.c7 Aug 2015 07:16:54 -
@@ -281,6 +281,8 @@ fastcopy(char *from, char *to, struct st
if ((bp = malloc(blen)) == NULL) {
warn(NULL);
blen = 0;
+ (void)close(from_fd);
+ (void)close(to_fd);
return (1);
}
}
@@ -325,7 +327,7 @@ err:if (unlink(to))
TIMESPEC_TO_TIMEVAL(&tval[0], &sbp->st_atimespec);
TIMESPEC_TO_TIMEVAL(&tval[1], &sbp->st_mtimespec);
- if (utimes(to, tval))
+ if (futimes(to_fd, tval))
warn("%s: set times", to);
if (close(to_fd)) {
