From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 17 18:06:30 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE8BAC43 for ; Sun, 17 Feb 2013 18:06:30 +0000 (UTC) (envelope-from prvs=17602818aa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id D5F33164 for ; Sun, 17 Feb 2013 18:06:29 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002265088.msg for ; Sun, 17 Feb 2013 18:06:28 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 17 Feb 2013 18:06:28 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17602818aa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: <49693195BAD841469129EE4B7523CABE@multiplay.co.uk> From: "Steven Hartland" To: Subject: Looking for reviewers for patch that adds foreign disk support mfiutil Date: Sun, 17 Feb 2013 18:06:40 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02FD_01CE0D39.88DA2DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 18:06:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02FD_01CE0D39.88DA2DE0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi all I'm looking for someone to review the attached patch to mfiutil which adds foreign disk support to mfiutil as per: http://www.freebsd.org/cgi/query-pr.cgi?pr=172091 Any and all feedback welcome :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_02FD_01CE0D39.88DA2DE0 Content-Type: application/octet-stream; name="z-mfi-foreign-timeout.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="z-mfi-foreign-timeout.patch" Add support for foreign disks / configs this implements the following new=0A= methods to mfiutil=0A= * foreign scan - lists the number of foreign configs=0A= * foreign drives - lists the drives which are flagged as foreign=0A= * foreign display - displays the specified foreign configuration=0A= * foreign preview - previews the specified foreign configuration (after = import)=0A= * foreign clear - clears the foreign configuration=0A= * foreign import - imports the foreign configuration=0A= =0A= mfiutil show drives - now identifies foreign drives=0A= =0A= It should be noted that although foreign import takes a configuration = option=0A= this currently fails with error code 0x03 (invalid argument). This also=0A= occurs with MegaCli so its currently thought this is a firmware bug.=0A= =0A= Adds hw.mfi.cmd_timeout loader / sysctl tuneable which controls the = default=0A= timeout used in the mfi driver. This is useful for long running commands=0A= such as secure erase.=0A= =0A= Additional debugging of DCMD commands has also been added which added=0A= identifying the DCMD's used by MegaCli to perform the various actions.=0A= --- usr.sbin/mfiutil/mfi_config.c.orig 2012-11-07 12:24:57.788834019 = +0000=0A= +++ usr.sbin/mfiutil/mfi_config.c 2012-11-07 14:31:31.462399216 +0000=0A= @@ -37,19 +37,13 @@=0A= #include =0A= #include =0A= #include =0A= -#ifdef DEBUG=0A= #include =0A= -#endif=0A= #include =0A= #include =0A= #include =0A= #include =0A= #include "mfiutil.h"=0A= =0A= -#ifdef DEBUG=0A= -static void dump_config(int fd, struct mfi_config_data *config);=0A= -#endif=0A= -=0A= static int add_spare(int ac, char **av);=0A= static int remove_spare(int ac, char **av);=0A= =0A= @@ -81,9 +75,17 @@=0A= }=0A= return (iv);=0A= }=0A= +=0A= int=0A= mfi_config_read(int fd, struct mfi_config_data **configp)=0A= {=0A= + return mfi_config_read_opcode(fd, MFI_DCMD_CFG_READ, configp, NULL, 0);=0A= +}=0A= +=0A= +int=0A= +mfi_config_read_opcode(int fd, uint32_t opcode, struct mfi_config_data = **configp,=0A= + uint8_t *mbox, size_t mboxlen)=0A= +{=0A= struct mfi_config_data *config;=0A= uint32_t config_size;=0A= int error;=0A= @@ -98,8 +100,8 @@=0A= config =3D reallocf(config, config_size);=0A= if (config =3D=3D NULL)=0A= return (-1);=0A= - if (mfi_dcmd_command(fd, MFI_DCMD_CFG_READ, config,=0A= - config_size, NULL, 0, NULL) < 0) {=0A= + if (mfi_dcmd_command(fd, opcode, config,=0A= + config_size, mbox, mboxlen, NULL) < 0) {=0A= error =3D errno;=0A= free(config);=0A= errno =3D error;=0A= @@ -366,6 +368,13 @@=0A= info->drives =3D NULL;=0A= return (EINVAL);=0A= }=0A= +=0A= + if (pinfo->state.ddf.v.pd_type.is_foreign) {=0A= + warnx("Drive %u is foreign", device_id);=0A= + free(info->drives);=0A= + info->drives =3D NULL;=0A= + return (EINVAL);=0A= + }=0A= }=0A= =0A= return (0);=0A= @@ -804,7 +813,7 @@=0A= =0A= #ifdef DEBUG=0A= if (dump)=0A= - dump_config(fd, config);=0A= + dump_config(fd, config, NULL);=0A= #endif=0A= =0A= /* Send the new config to the controller. */=0A= @@ -1093,10 +1102,9 @@=0A= }=0A= MFI_COMMAND(top, remove, remove_spare);=0A= =0A= -#ifdef DEBUG=0A= /* Display raw data about a config. */=0A= -static void=0A= -dump_config(int fd, struct mfi_config_data *config)=0A= +void=0A= +dump_config(int fd, struct mfi_config_data *config, const char = *msg_prefix)=0A= {=0A= struct mfi_array *ar;=0A= struct mfi_ld_config *ld;=0A= @@ -1106,9 +1114,12 @@=0A= char *p;=0A= int i, j;=0A= =0A= + if (NULL =3D=3D msg_prefix)=0A= + msg_prefix =3D "Configuration (Debug)";=0A= +=0A= printf(=0A= - "mfi%d Configuration (Debug): %d arrays, %d volumes, %d spares\n",=0A= - mfi_unit, config->array_count, config->log_drv_count,=0A= + "mfi%d %s: %d arrays, %d volumes, %d spares\n", mfi_unit,=0A= + msg_prefix, config->array_count, config->log_drv_count,=0A= config->spares_count);=0A= printf(" array size: %u\n", config->array_size);=0A= printf(" volume size: %u\n", config->log_drv_size);=0A= @@ -1186,6 +1197,7 @@=0A= }=0A= }=0A= =0A= +#ifdef DEBUG=0A= static int=0A= debug_config(int ac, char **av)=0A= {=0A= @@ -1213,7 +1225,7 @@=0A= }=0A= =0A= /* Dump out the configuration. */=0A= - dump_config(fd, config);=0A= + dump_config(fd, config, NULL);=0A= free(config);=0A= close(fd);=0A= =0A= @@ -1265,7 +1277,7 @@=0A= close(fd);=0A= return (error);=0A= }=0A= - dump_config(fd, config);=0A= + dump_config(fd, config, NULL);=0A= free(config);=0A= close(fd);=0A= =0A= --- usr.sbin/mfiutil/mfiutil.h.orig 2012-11-07 12:25:06.150119092 +0000=0A= +++ usr.sbin/mfiutil/mfiutil.h 2012-11-07 14:31:31.464398803 +0000=0A= @@ -136,6 +136,8 @@=0A= const char *mfi_volume_name(int fd, uint8_t target_id);=0A= int mfi_volume_busy(int fd, uint8_t target_id);=0A= int mfi_config_read(int fd, struct mfi_config_data **configp);=0A= +int mfi_config_read_opcode(int fd, uint32_t opcode,=0A= + struct mfi_config_data **configp, uint8_t *mbox, size_t mboxlen);=0A= int mfi_lookup_drive(int fd, char *drive, uint16_t *device_id);=0A= int mfi_lookup_volume(int fd, const char *name, uint8_t *target_id);=0A= int mfi_dcmd_command(int fd, uint32_t opcode, void *buf, size_t bufsize,=0A= @@ -152,6 +154,10 @@=0A= const char *mfi_status(u_int status_code);=0A= const char *mfi_drive_name(struct mfi_pd_info *pinfo, uint16_t = device_id,=0A= uint32_t def);=0A= +void format_stripe(char *buf, size_t buflen, uint8_t stripe);=0A= +void print_ld(struct mfi_ld_info *info, int state_len);=0A= +void print_pd(struct mfi_pd_info *info, int state_len);=0A= +void dump_config(int fd, struct mfi_config_data *config, const char* = msg_prefix);=0A= =0A= void scan_firmware(struct mfi_info_component *comp);=0A= void display_firmware(struct mfi_info_component *comp, const char *tag);=0A= --- usr.sbin/mfiutil/Makefile.orig 2012-11-07 12:24:55.880985046 +0000=0A= +++ usr.sbin/mfiutil/Makefile 2012-11-07 14:31:31.460399070 +0000=0A= @@ -2,7 +2,7 @@=0A= PROG=3D mfiutil=0A= =0A= SRCS=3D mfiutil.c mfi_cmd.c mfi_config.c mfi_drive.c mfi_evt.c = mfi_flash.c \=0A= - mfi_patrol.c mfi_show.c mfi_volume.c=0A= + mfi_patrol.c mfi_show.c mfi_volume.c mfi_foreign.c=0A= MAN8=3D mfiutil.8=0A= =0A= CFLAGS+=3D -fno-builtin-strftime=0A= --- usr.sbin/mfiutil/mfi_foreign.c.orig 2012-11-07 14:31:31.467398742 = +0000=0A= +++ usr.sbin/mfiutil/mfi_foreign.c 2012-11-07 14:31:31.470398682 +0000=0A= @@ -0,0 +1,405 @@=0A= +/*-=0A= + * Copyright (c) 2008, 2009 Yahoo!, Inc.=0A= + * All rights reserved.=0A= + *=0A= + * Redistribution and use in source and binary forms, with or without=0A= + * modification, are permitted provided that the following conditions=0A= + * are met:=0A= + * 1. Redistributions of source code must retain the above copyright=0A= + * notice, this list of conditions and the following disclaimer.=0A= + * 2. Redistributions in binary form must reproduce the above copyright=0A= + * notice, this list of conditions and the following disclaimer in = the=0A= + * documentation and/or other materials provided with the = distribution.=0A= + * 3. The names of the authors may not be used to endorse or promote=0A= + * products derived from this software without specific prior written=0A= + * permission.=0A= + *=0A= + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' = AND=0A= + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=0A= + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR = PURPOSE=0A= + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE = LIABLE=0A= + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL=0A= + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE = GOODS=0A= + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)=0A= + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, = STRICT=0A= + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN = ANY WAY=0A= + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY = OF=0A= + * SUCH DAMAGE.=0A= + *=0A= + * $FreeBSD$=0A= + */=0A= +=0A= +#include =0A= +#include =0A= +#include =0A= +#include =0A= +#include =0A= +#include =0A= +#include =0A= +#include =0A= +#include =0A= +#include "mfiutil.h"=0A= +=0A= +MFI_TABLE(top, foreign);=0A= +=0A= +/* We currently don't know the full details of the following struct */=0A= +struct mfi_foreign_scan_cfg {=0A= + char data[24];=0A= +};=0A= +=0A= +struct mfi_foreign_scan_info {=0A= + uint32_t count; /* Number of foreign configs found */=0A= + struct mfi_foreign_scan_cfg cfgs[8];=0A= +};=0A= +=0A= +static int=0A= +foreign_drives(int ac, char **av)=0A= +{=0A= + struct mfi_pd_info info;=0A= + struct mfi_pd_list *list;=0A= + int error, fd;=0A= + u_int i;=0A= + fd =3D mfi_open(mfi_unit, O_RDONLY);=0A= + if (fd < 0) {=0A= + error =3D errno;=0A= + warn("mfi_open");=0A= + return (error);=0A= + }=0A= +=0A= + list =3D NULL;=0A= + if (mfi_pd_get_list(fd, &list, NULL) < 0) {=0A= + error =3D errno;=0A= + warn("Failed to get drive list");=0A= + goto error;=0A= + }=0A= + /* List the drives. */=0A= + printf("mfi%d Foreign disks:\n", mfi_unit);=0A= + for (i =3D 0; i < list->count; i++) {=0A= + /* Skip non-hard disks. */=0A= + if (list->addr[i].scsi_dev_type !=3D 0)=0A= + continue;=0A= + /* Fetch details for this drive. */=0A= + if (mfi_pd_get_info(fd, list->addr[i].device_id, &info,=0A= + NULL) < 0) {=0A= + error =3D errno;=0A= + warn("Failed to fetch info for drive %u",=0A= + list->addr[i].device_id);=0A= + goto error;=0A= + }=0A= +=0A= + if (!info.state.ddf.v.pd_type.is_foreign)=0A= + continue;=0A= + =0A= + printf("%s ", mfi_drive_name(&info, list->addr[i].device_id,=0A= + MFI_DNAME_DEVICE_ID));=0A= + print_pd(&info, -1);=0A= + printf(" %s\n", mfi_drive_name(&info, list->addr[i].device_id,=0A= + MFI_DNAME_ES));=0A= + }=0A= +error:=0A= + if(list)=0A= + free(list);=0A= + close(fd);=0A= + error =3D 0;=0A= + return (0);=0A= +}=0A= +MFI_COMMAND(foreign, drives, foreign_drives);=0A= +=0A= +static int=0A= +foreign_clear(int ac, char **av)=0A= +{=0A= + int ch, error, fd;=0A= +=0A= + fd =3D mfi_open(mfi_unit, O_RDWR);=0A= + if (fd < 0) {=0A= + error =3D errno;=0A= + warn("mfi_open");=0A= + return (error);=0A= + }=0A= +=0A= + printf(=0A= + "Are you sure you wish to clear ALL foreign configurations"=0A= + " on mfi%u? [y/N] ", mfi_unit);=0A= +=0A= + ch =3D getchar();=0A= + if (ch !=3D 'y' && ch !=3D 'Y') {=0A= + printf("\nAborting\n");=0A= + close(fd);=0A= + return (0);=0A= + }=0A= +=0A= + if (mfi_dcmd_command(fd, MFI_DCMD_CFG_FOREIGN_CLEAR, NULL, 0, NULL,=0A= + 0, NULL) < 0) {=0A= + error =3D errno;=0A= + warn("Failed to clear foreign configuration");=0A= + close(fd);=0A= + return (error);=0A= + }=0A= +=0A= + printf("mfi%d: Foreign configuration cleared\n", mfi_unit);=0A= + close(fd);=0A= + return (0);=0A= +}=0A= +MFI_COMMAND(foreign, clear, foreign_clear);=0A= +=0A= +static int=0A= +foreign_scan(int ac, char **av)=0A= +{=0A= + struct mfi_foreign_scan_info info;=0A= + int error, fd;=0A= +=0A= + fd =3D mfi_open(mfi_unit, O_RDONLY);=0A= + if (fd < 0) {=0A= + error =3D errno;=0A= + warn("mfi_open");=0A= + return (error);=0A= + }=0A= +=0A= + if (mfi_dcmd_command(fd, MFI_DCMD_CFG_FOREIGN_SCAN, &info,=0A= + sizeof(info), NULL, 0, NULL) < 0) {=0A= + error =3D errno;=0A= + warn("Failed to scan foreign configuration");=0A= + close(fd);=0A= + return (error);=0A= + }=0A= +=0A= + printf("mfi%d: Found %d foreign configurations\n", mfi_unit,=0A= + info.count);=0A= + close(fd);=0A= + return (0);=0A= +}=0A= +MFI_COMMAND(foreign, scan, foreign_scan);=0A= +=0A= +static int=0A= +foreign_show_cfg(int fd, uint32_t opcode, uint8_t cfgidx)=0A= +{=0A= + struct mfi_config_data *config;=0A= + char prefix[26];=0A= + int error, i;=0A= + uint8_t mbox[4];=0A= +=0A= + bzero(mbox, sizeof(mbox));=0A= + mbox[0] =3D cfgidx;=0A= + if (mfi_config_read_opcode(fd, opcode, &config, mbox, sizeof(mbox))=0A= + < 0) {=0A= + error =3D errno;=0A= + warn("Failed to get foreign config %d", i);=0A= + close(fd);=0A= + return (error);=0A= + }=0A= +=0A= + if (opcode =3D=3D MFI_DCMD_CFG_FOREIGN_PREVIEW)=0A= + sprintf(prefix, "Foreign configuration preview %d", cfgidx);=0A= + else=0A= + sprintf(prefix, "Foreign configuration %d", cfgidx);=0A= + /*=0A= + * MegaCli uses DCMD opcodes: 0x03100200 (which fails) followed by=0A= + * 0x1a721880 which returns what looks to be drive / volume info=0A= + * but we have no real information on what these are or what they do=0A= + * so we're currently relying solely on the config returned above=0A= + */=0A= + dump_config(fd, config, prefix);=0A= + free(config);=0A= +=0A= + return (0);=0A= +}=0A= +=0A= +static int=0A= +foreign_display(int ac, char **av)=0A= +{=0A= + struct mfi_foreign_scan_info info;=0A= + uint8_t i;=0A= + int error, fd;=0A= +=0A= + if (2 < ac) {=0A= + warnx("foreign display: extra arguments");=0A= + return (EINVAL);=0A= + }=0A= +=0A= + fd =3D mfi_open(mfi_unit, O_RDONLY);=0A= + if (fd < 0) {=0A= + error =3D errno;=0A= + warn("mfi_open");=0A= + return (error);=0A= + }=0A= +=0A= + if (mfi_dcmd_command(fd, MFI_DCMD_CFG_FOREIGN_SCAN, &info,=0A= + sizeof(info), NULL, 0, NULL) < 0) {=0A= + error =3D errno;=0A= + warn("Failed to scan foreign configuration");=0A= + close(fd);=0A= + return (error);=0A= + }=0A= +=0A= + if (0 =3D=3D info.count) {=0A= + warnx("foreign display: no foreign configs found");=0A= + close(fd);=0A= + return (EINVAL);=0A= + }=0A= +=0A= + if (1 =3D=3D ac) {=0A= + for (i =3D 0; i < info.count; i++) {=0A= + error =3D foreign_show_cfg(fd,=0A= + MFI_DCMD_CFG_FOREIGN_DISPLAY, i);=0A= + if(0 !=3D error) {=0A= + close(fd);=0A= + return (error);=0A= + }=0A= + if (i < info.count - 1)=0A= + printf("\n");=0A= + }=0A= + } else if (2 =3D=3D ac) {=0A= + error =3D foreign_show_cfg(fd,=0A= + MFI_DCMD_CFG_FOREIGN_DISPLAY, atoi(av[1]));=0A= + if (0 !=3D error) {=0A= + close(fd);=0A= + return (error);=0A= + }=0A= + }=0A= + =0A= + close(fd);=0A= + return (0);=0A= +}=0A= +MFI_COMMAND(foreign, display, foreign_display);=0A= +=0A= +static int=0A= +foreign_preview(int ac, char **av)=0A= +{=0A= + struct mfi_foreign_scan_info info;=0A= + uint8_t i;=0A= + int error, fd;=0A= +=0A= + if (2 < ac) {=0A= + warnx("foreign preview: extra arguments");=0A= + return (EINVAL);=0A= + }=0A= +=0A= + fd =3D mfi_open(mfi_unit, O_RDONLY);=0A= + if (fd < 0) {=0A= + error =3D errno;=0A= + warn("mfi_open");=0A= + return (error);=0A= + }=0A= +=0A= + if (mfi_dcmd_command(fd, MFI_DCMD_CFG_FOREIGN_SCAN, &info,=0A= + sizeof(info), NULL, 0, NULL) < 0) {=0A= + error =3D errno;=0A= + warn("Failed to scan foreign configuration");=0A= + close(fd);=0A= + return (error);=0A= + }=0A= +=0A= + if (0 =3D=3D info.count) {=0A= + warnx("foreign preview: no foreign configs found");=0A= + close(fd);=0A= + return (EINVAL);=0A= + }=0A= +=0A= + if (1 =3D=3D ac) {=0A= + for (i =3D 0; i < info.count; i++) {=0A= + error =3D foreign_show_cfg(fd,=0A= + MFI_DCMD_CFG_FOREIGN_PREVIEW, i);=0A= + if(0 !=3D error) {=0A= + close(fd);=0A= + return (error);=0A= + }=0A= + if (i < info.count - 1)=0A= + printf("\n");=0A= + }=0A= + } else if (2 =3D=3D ac) {=0A= + error =3D foreign_show_cfg(fd,=0A= + MFI_DCMD_CFG_FOREIGN_PREVIEW, atoi(av[1]));=0A= + if (0 !=3D error) {=0A= + close(fd);=0A= + return (error);=0A= + }=0A= + }=0A= + =0A= + close(fd);=0A= + return (0);=0A= +}=0A= +MFI_COMMAND(foreign, preview, foreign_preview);=0A= +=0A= +static int=0A= +foreign_import(int ac, char **av)=0A= +{=0A= + struct mfi_foreign_scan_info info;=0A= + int ch, error, fd;=0A= + uint8_t cfgidx;=0A= + uint8_t mbox[4];=0A= +=0A= + if (2 < ac) {=0A= + warnx("foreign preview: extra arguments");=0A= + return (EINVAL);=0A= + }=0A= +=0A= + fd =3D mfi_open(mfi_unit, O_RDWR);=0A= + if (fd < 0) {=0A= + error =3D errno;=0A= + warn("mfi_open");=0A= + return (error);=0A= + }=0A= +=0A= + if (mfi_dcmd_command(fd, MFI_DCMD_CFG_FOREIGN_SCAN, &info,=0A= + sizeof(info), NULL, 0, NULL) < 0) {=0A= + error =3D errno;=0A= + warn("Failed to scan foreign configuration");=0A= + close(fd);=0A= + return (error);=0A= + }=0A= +=0A= + if (0 =3D=3D info.count) {=0A= + warnx("foreign import: no foreign configs found");=0A= + close(fd);=0A= + return (EINVAL);=0A= + }=0A= +=0A= + if (1 =3D=3D ac) {=0A= + cfgidx =3D 0xff;=0A= + printf("Are you sure you wish to import ALL foreign "=0A= + "configurations on mfi%u? [y/N] ", mfi_unit);=0A= + } else {=0A= + /*=0A= + * While this is docmmented for MegaCli this failed with=0A= + * exit code 0x03 on the test controller which was a Supermicro=0A= + * SMC2108 with firmware 12.12.0-0095 which is a LSI 2108 based=0A= + * controller.=0A= + */=0A= + cfgidx =3D atoi(av[1]);=0A= + if (cfgidx >=3D info.count) {=0A= + warnx("Invalid foreign config %d specified max is %d",=0A= + cfgidx, info.count - 1);=0A= + close(fd);=0A= + return (EINVAL);=0A= + }=0A= + printf("Are you sure you wish to import the foreign "=0A= + "configuration %d on mfi%u? [y/N] ", cfgidx, mfi_unit);=0A= + }=0A= +=0A= + ch =3D getchar();=0A= + if (ch !=3D 'y' && ch !=3D 'Y') {=0A= + printf("\nAborting\n");=0A= + close(fd);=0A= + return (0);=0A= + }=0A= +=0A= + bzero(mbox, sizeof(mbox));=0A= + mbox[0] =3D cfgidx;=0A= + if (mfi_dcmd_command(fd, MFI_DCMD_CFG_FOREIGN_IMPORT, NULL, 0, mbox,=0A= + sizeof(mbox), NULL) < 0) {=0A= + error =3D errno;=0A= + warn("Failed to import foreign configuration");=0A= + close(fd);=0A= + return (error);=0A= + }=0A= +=0A= + if (1 =3D=3D ac)=0A= + printf("mfi%d: All foreign configurations imported\n",=0A= + mfi_unit);=0A= + else=0A= + printf("mfi%d: Foreign configuration %d imported\n", mfi_unit,=0A= + cfgidx);=0A= + close(fd);=0A= + return (0);=0A= +}=0A= +MFI_COMMAND(foreign, import, foreign_import);=0A= --- usr.sbin/mfiutil/mfiutil.c.orig 2012-11-07 12:25:04.142289096 +0000=0A= +++ usr.sbin/mfiutil/mfiutil.c 2012-11-07 14:31:31.464398803 +0000=0A= @@ -83,6 +83,12 @@=0A= fprintf(stderr, " patrol [interval = [start]]\n");=0A= fprintf(stderr, " start patrol - start a patrol = read\n");=0A= fprintf(stderr, " stop patrol - stop a patrol = read\n");=0A= + fprintf(stderr, " foreign scan - scan for foreign = configurations\n");=0A= + fprintf(stderr, " foreign drives - list foreign = drives\n");=0A= + fprintf(stderr, " foreign clear [volume] - clear foreign = configurations (default all)\n");=0A= + fprintf(stderr, " foreign display [volume] - display foreign = configurations (default all)\n");=0A= + fprintf(stderr, " foreign preview [volume] - preview foreign = configurations (default all)\n");=0A= + fprintf(stderr, " foreign import [volume] - import foreign = configurations (default all)\n");=0A= fprintf(stderr, " flash \n");=0A= #ifdef DEBUG=0A= fprintf(stderr, " debug - debug 'show = config'\n");=0A= --- usr.sbin/mfiutil/mfiutil.8.orig 2012-11-07 12:24:54.871069332 +0000=0A= +++ usr.sbin/mfiutil/mfiutil.8 2012-11-07 14:31:31.471400151 +0000=0A= @@ -140,6 +140,24 @@=0A= .Cm patrol Ar command Op Ar interval Op Ar start=0A= .Nm=0A= .Op Fl u Ar unit=0A= +.Cm foreign scan=0A= +.Nm=0A= +.Op Fl u Ar unit=0A= +.Cm foreign drives=0A= +.Nm=0A= +.Op Fl u Ar unit=0A= +.Cm foreign clear Op Ar config=0A= +.Nm=0A= +.Op Fl u Ar unit=0A= +.Cm foreign display Op Ar config=0A= +.Nm=0A= +.Op Fl u Ar unit=0A= +.Cm foreign preview Op Ar config=0A= +.Nm=0A= +.Op Fl u Ar unit=0A= +.Cm foreign import Op Ar config=0A= +.Nm=0A= +.Op Fl u Ar unit=0A= .Cm flash Ar file=0A= .Sh DESCRIPTION=0A= The=0A= @@ -561,6 +579,37 @@=0A= Start a patrol read operation.=0A= .It Cm stop patrol=0A= Stop a currently running patrol read operation.=0A= +.It Cm foreign scan=0A= +Scan for foreign configurations and display the number found. The=0A= +.Ar config=0A= +argument for the commands below takes the form of a number from 0 to = the total=0A= +configurations found.=0A= +.It Cm foreign drives=0A= +Scan for drives flagged as foreign and display them.=0A= +.It Cm foreign clear Op config=0A= +Clear the specifed foreign=0A= +.Ar config=0A= +or all if no=0A= +.Ar config=0A= +argument is provided.=0A= +.It Cm foreign display Op config=0A= +Display the specifed foreign=0A= +.Ar config=0A= +or all if no=0A= +.Ar config=0A= +argument is provided.=0A= +.It Cm foreign preview Op config=0A= +Preview the specifed foreign=0A= +.Ar config=0A= +after import or all if no=0A= +.Ar config=0A= +argument is provided.=0A= +.It Cm foreign import Op config=0A= +Import the specifed foreign=0A= +.Ar config=0A= +or all if no=0A= +.Ar config=0A= +argument is provided.=0A= .It Cm flash Ar file=0A= Updates the flash on the controller with the firmware stored in=0A= .Ar file .=0A= --- usr.sbin/mfiutil/mfi_cmd.c.orig 2012-11-07 12:24:56.758910703 +0000=0A= +++ usr.sbin/mfiutil/mfi_cmd.c 2012-11-07 14:31:31.461399143 +0000=0A= @@ -284,7 +284,7 @@=0A= if (statusp !=3D NULL)=0A= *statusp =3D dcmd->header.cmd_status;=0A= else if (dcmd->header.cmd_status !=3D MFI_STAT_OK) {=0A= - warnx("Command failed: %s",=0A= + warnx("Command 0x%08x failed: %s", opcode,=0A= mfi_status(dcmd->header.cmd_status));=0A= errno =3D EIO;=0A= return (-1);=0A= --- usr.sbin/mfiutil/mfi_show.c.orig 2012-11-07 12:25:03.255363063 +0000=0A= +++ usr.sbin/mfiutil/mfi_show.c 2012-11-07 14:31:31.463398730 +0000=0A= @@ -40,9 +40,11 @@=0A= #include =0A= #include "mfiutil.h"=0A= =0A= +const char* foreign_state =3D " (FOREIGN)";=0A= +=0A= MFI_TABLE(top, show);=0A= =0A= -static void=0A= +void=0A= format_stripe(char *buf, size_t buflen, uint8_t stripe)=0A= {=0A= =0A= @@ -264,7 +266,7 @@=0A= }=0A= MFI_COMMAND(show, battery, show_battery);=0A= =0A= -static void=0A= +void=0A= print_ld(struct mfi_ld_info *info, int state_len)=0A= {=0A= struct mfi_ld_params *params =3D &info->ld_config.params;=0A= @@ -285,19 +287,24 @@=0A= mfi_ldstate(params->state));=0A= }=0A= =0A= -static void=0A= +void=0A= print_pd(struct mfi_pd_info *info, int state_len)=0A= {=0A= const char *s;=0A= - char buf[6];=0A= + char buf[256];=0A= =0A= humanize_number(buf, sizeof(buf), info->raw_size * 512, "",=0A= HN_AUTOSCALE, HN_B | HN_NOSPACE |HN_DECIMAL);=0A= printf("(%6s) ", buf);=0A= + if (info->state.ddf.v.pd_type.is_foreign) {=0A= + sprintf(buf, "%s%s", mfi_pdstate(info->fw_state), foreign_state);=0A= + s =3D buf;=0A= + } else=0A= + s =3D mfi_pdstate(info->fw_state);=0A= if (state_len > 0)=0A= - printf("%-*s", state_len, mfi_pdstate(info->fw_state));=0A= + printf("%-*s", state_len, s);=0A= else=0A= - printf("%s", mfi_pdstate(info->fw_state));=0A= + printf(s);=0A= s =3D mfi_pd_inq_string(info);=0A= if (s !=3D NULL)=0A= printf(" %s", s);=0A= @@ -533,6 +540,8 @@=0A= goto error;=0A= }=0A= len =3D strlen(mfi_pdstate(info.fw_state));=0A= + if (info.state.ddf.v.pd_type.is_foreign)=0A= + len +=3D strlen(foreign_state);=0A= if (len > state_len)=0A= state_len =3D len;=0A= }=0A= --- sys/dev/mfi/mfireg.h.orig 2012-11-07 12:21:50.437607341 +0000=0A= +++ sys/dev/mfi/mfireg.h 2012-11-07 14:31:31.466398669 +0000=0A= @@ -184,27 +184,31 @@=0A= MFI_CMD_STP=0A= } mfi_cmd_t;=0A= =0A= -/* Direct commands */=0A= +/*=0A= + * Direct commands=0A= + *=0A= + * NOTE: Keep mfi_op_codes in mfi_debug.c up to date when adding values=0A= + */=0A= typedef enum {=0A= MFI_DCMD_CTRL_GETINFO =3D 0x01010000,=0A= - MFI_DCMD_CTRL_MFI_HOST_MEM_ALLOC =3D0x0100e100,=0A= - MFI_DCMD_CTRL_MFC_DEFAULTS_GET =3D0x010e0201,=0A= - MFI_DCMD_CTRL_MFC_DEFAULTS_SET =3D0x010e0202,=0A= - MFI_DCMD_CTRL_FLUSHCACHE =3D 0x01101000,=0A= - MFI_DCMD_CTRL_SHUTDOWN =3D 0x01050000,=0A= MFI_DCMD_CTRL_EVENT_GETINFO =3D 0x01040100,=0A= MFI_DCMD_CTRL_EVENT_GET =3D 0x01040300,=0A= MFI_DCMD_CTRL_EVENT_WAIT =3D 0x01040500,=0A= + MFI_DCMD_CTRL_SHUTDOWN =3D 0x01050000,=0A= MFI_DCMD_PR_GET_STATUS =3D 0x01070100,=0A= MFI_DCMD_PR_GET_PROPERTIES =3D 0x01070200,=0A= MFI_DCMD_PR_SET_PROPERTIES =3D 0x01070300,=0A= MFI_DCMD_PR_START =3D 0x01070400,=0A= MFI_DCMD_PR_STOP =3D 0x01070500,=0A= MFI_DCMD_TIME_SECS_GET =3D 0x01080201,=0A= + MFI_DCMD_CTRL_MFI_HOST_MEM_ALLOC =3D0x0100e100,=0A= + MFI_DCMD_CTRL_MFC_DEFAULTS_GET =3D0x010e0201,=0A= + MFI_DCMD_CTRL_MFC_DEFAULTS_SET =3D0x010e0202,=0A= MFI_DCMD_FLASH_FW_OPEN =3D 0x010f0100,=0A= MFI_DCMD_FLASH_FW_DOWNLOAD =3D 0x010f0200,=0A= MFI_DCMD_FLASH_FW_FLASH =3D 0x010f0300,=0A= MFI_DCMD_FLASH_FW_CLOSE =3D 0x010f0400,=0A= + MFI_DCMD_CTRL_FLUSHCACHE =3D 0x01101000,=0A= MFI_DCMD_PD_GET_LIST =3D 0x02010000,=0A= MFI_DCMD_PD_LIST_QUERY =3D 0x02010100,=0A= MFI_DCMD_PD_GET_INFO =3D 0x02020000,=0A= @@ -229,7 +233,11 @@=0A= MFI_DCMD_CFG_CLEAR =3D 0x04030000,=0A= MFI_DCMD_CFG_MAKE_SPARE =3D 0x04040000,=0A= MFI_DCMD_CFG_REMOVE_SPARE =3D 0x04050000,=0A= + MFI_DCMD_CFG_FOREIGN_SCAN =3D 0x04060100,=0A= + MFI_DCMD_CFG_FOREIGN_DISPLAY =3D 0x04060200,=0A= + MFI_DCMD_CFG_FOREIGN_PREVIEW =3D 0x04060300,=0A= MFI_DCMD_CFG_FOREIGN_IMPORT =3D 0x04060400,=0A= + MFI_DCMD_CFG_FOREIGN_CLEAR =3D 0x04060500,=0A= MFI_DCMD_BBU_GET_STATUS =3D 0x05010000,=0A= MFI_DCMD_BBU_GET_CAPACITY_INFO =3D0x05020000,=0A= MFI_DCMD_BBU_GET_DESIGN_INFO =3D 0x05030000,=0A= --- sys/dev/mfi/mfivar.h.orig 2012-11-07 12:44:51.712248722 +0000=0A= +++ sys/dev/mfi/mfivar.h 2012-11-07 14:31:31.467398742 +0000=0A= @@ -589,6 +589,7 @@=0A= extern void mfi_print_cmd(struct mfi_command *cm);=0A= extern void mfi_dump_cmds(struct mfi_softc *sc);=0A= extern void mfi_validate_sg(struct mfi_softc *, struct mfi_command *, = const char *, int );=0A= +extern const char * mfi_op_desc(uint32_t opcode);=0A= #define MFI_PRINT_CMD(cm) mfi_print_cmd(cm)=0A= #define MFI_DUMP_CMDS(sc) mfi_dump_cmds(sc)=0A= #define MFI_VALIDATE_CMD(sc, cm) mfi_validate_sg(sc, cm, __FUNCTION__, = __LINE__)=0A= --- sys/dev/mfi/mfi_debug.c.orig 2012-11-07 12:21:44.533103108 +0000=0A= +++ sys/dev/mfi/mfi_debug.c 2012-11-07 14:31:31.465398876 +0000=0A= @@ -54,6 +54,88 @@=0A= #include =0A= #include =0A= =0A= +struct mfi_op_table_entry {=0A= + uint32_t opcode;=0A= + const char *desc;=0A= +};=0A= +=0A= +/* Keep in sync with mfi_dcmd_t in mfireg.h */=0A= +static struct mfi_op_table_entry mfi_op_codes[] =3D {=0A= + { MFI_DCMD_CTRL_GETINFO, "MFI_DCMD_CTRL_GETINFO" },=0A= + { MFI_DCMD_CTRL_MFI_HOST_MEM_ALLOC, "MFI_DCMD_CTRL_MFI_HOST_MEM_ALLOC" = },=0A= + { MFI_DCMD_CTRL_EVENT_GETINFO, "MFI_DCMD_CTRL_EVENT_GETINFO" },=0A= + { MFI_DCMD_CTRL_EVENT_GET, "MFI_DCMD_CTRL_EVENT_GET" },=0A= + { MFI_DCMD_CTRL_EVENT_WAIT, "MFI_DCMD_CTRL_EVENT_WAIT" },=0A= + { MFI_DCMD_CTRL_SHUTDOWN, "MFI_DCMD_CTRL_SHUTDOWN" },=0A= + { MFI_DCMD_PR_GET_STATUS, "MFI_DCMD_PR_GET_STATUS" },=0A= + { MFI_DCMD_PR_GET_PROPERTIES, "MFI_DCMD_PR_GET_PROPERTIES" },=0A= + { MFI_DCMD_PR_SET_PROPERTIES, "MFI_DCMD_PR_SET_PROPERTIES" },=0A= + { MFI_DCMD_PR_START, "MFI_DCMD_PR_START" },=0A= + { MFI_DCMD_PR_STOP, "MFI_DCMD_PR_STOP" },=0A= + { MFI_DCMD_TIME_SECS_GET, "MFI_DCMD_TIME_SECS_GET" },=0A= + { MFI_DCMD_CTRL_MFC_DEFAULTS_GET, "MFI_DCMD_CTRL_MFC_DEFAULTS_GET" },=0A= + { MFI_DCMD_CTRL_MFC_DEFAULTS_SET, "MFI_DCMD_CTRL_MFC_DEFAULTS_SET" },=0A= + { MFI_DCMD_FLASH_FW_OPEN, "MFI_DCMD_FLASH_FW_OPEN" },=0A= + { MFI_DCMD_FLASH_FW_DOWNLOAD, "MFI_DCMD_FLASH_FW_DOWNLOAD" },=0A= + { MFI_DCMD_FLASH_FW_FLASH, "MFI_DCMD_FLASH_FW_FLASH" },=0A= + { MFI_DCMD_FLASH_FW_CLOSE, "MFI_DCMD_FLASH_FW_CLOSE" },=0A= + { MFI_DCMD_CTRL_FLUSHCACHE, "MFI_DCMD_CTRL_FLUSHCACHE" },=0A= + { MFI_DCMD_PD_GET_LIST, "MFI_DCMD_PD_GET_LIST" },=0A= + { MFI_DCMD_PD_LIST_QUERY, "MFI_DCMD_PD_LIST_QUERY" },=0A= + { MFI_DCMD_PD_GET_INFO, "MFI_DCMD_PD_GET_INFO" },=0A= + { MFI_DCMD_PD_STATE_SET, "MFI_DCMD_PD_STATE_SET" },=0A= + { MFI_DCMD_PD_REBUILD_START, "MFI_DCMD_PD_REBUILD_START" },=0A= + { MFI_DCMD_PD_REBUILD_ABORT, "MFI_DCMD_PD_REBUILD_ABORT" },=0A= + { MFI_DCMD_PD_CLEAR_START, "MFI_DCMD_PD_CLEAR_START" },=0A= + { MFI_DCMD_PD_CLEAR_ABORT, "MFI_DCMD_PD_CLEAR_ABORT" },=0A= + { MFI_DCMD_PD_GET_PROGRESS, "MFI_DCMD_PD_GET_PROGRESS" },=0A= + { MFI_DCMD_PD_LOCATE_START, "MFI_DCMD_PD_LOCATE_START" },=0A= + { MFI_DCMD_PD_LOCATE_STOP, "MFI_DCMD_PD_LOCATE_STOP" },=0A= + { MFI_DCMD_LD_MAP_GET_INFO, "MFI_DCMD_LD_MAP_GET_INFO" },=0A= + { MFI_DCMD_LD_SYNC, "MFI_DCMD_LD_SYNC" },=0A= + { MFI_DCMD_LD_GET_LIST, "MFI_DCMD_LD_GET_LIST" },=0A= + { MFI_DCMD_LD_GET_INFO, "MFI_DCMD_LD_GET_INFO" },=0A= + { MFI_DCMD_LD_GET_PROP, "MFI_DCMD_LD_GET_PROP" },=0A= + { MFI_DCMD_LD_SET_PROP, "MFI_DCMD_LD_SET_PROP" },=0A= + { MFI_DCMD_LD_INIT_START, "MFI_DCMD_LD_INIT_START" },=0A= + { MFI_DCMD_LD_DELETE, "MFI_DCMD_LD_DELETE" },=0A= + { MFI_DCMD_CFG_READ, "MFI_DCMD_CFG_READ" },=0A= + { MFI_DCMD_CFG_ADD, "MFI_DCMD_CFG_ADD" },=0A= + { MFI_DCMD_CFG_CLEAR, "MFI_DCMD_CFG_CLEAR" },=0A= + { MFI_DCMD_CFG_MAKE_SPARE, "MFI_DCMD_CFG_MAKE_SPARE" },=0A= + { MFI_DCMD_CFG_REMOVE_SPARE, "MFI_DCMD_CFG_REMOVE_SPARE" },=0A= + { MFI_DCMD_CFG_FOREIGN_SCAN, "MFI_DCMD_CFG_FOREIGN_SCAN" },=0A= + { MFI_DCMD_CFG_FOREIGN_DISPLAY, "MFI_DCMD_CFG_FOREIGN_DISPLAY" },=0A= + { MFI_DCMD_CFG_FOREIGN_PREVIEW, "MFI_DCMD_CFG_FOREIGN_PREVIEW" },=0A= + { MFI_DCMD_CFG_FOREIGN_IMPORT, "MFI_DCMD_CFG_FOREIGN_IMPORT" },=0A= + { MFI_DCMD_CFG_FOREIGN_CLEAR, "MFI_DCMD_CFG_FOREIGN_CLEAR" },=0A= + { MFI_DCMD_BBU_GET_STATUS, "MFI_DCMD_BBU_GET_STATUS" },=0A= + { MFI_DCMD_BBU_GET_CAPACITY_INFO, "MFI_DCMD_BBU_GET_CAPACITY_INFO" },=0A= + { MFI_DCMD_BBU_GET_DESIGN_INFO, "MFI_DCMD_BBU_GET_DESIGN_INFO" },=0A= + { MFI_DCMD_CLUSTER, "MFI_DCMD_CLUSTER" },=0A= + { MFI_DCMD_CLUSTER_RESET_ALL, "MFI_DCMD_CLUSTER_RESET_ALL" },=0A= + { MFI_DCMD_CLUSTER_RESET_LD, "MFI_DCMD_CLUSTER_RESET_LD" }=0A= +};=0A= +=0A= +static void=0A= +mfi_dump_bytes(const char *prefix, unsigned char *p, int len)=0A= +{=0A= + int i, c =3D 1, j =3D 0;=0A= +=0A= + if (prefix)=0A= + printf("%s: ", prefix);=0A= + printf("[%d]\ndata[%d] ", len, j);=0A= + for (i =3D 0; i < len; ++i) {=0A= + printf(" %02x", p[i]);=0A= + c++;=0A= + if ( 32 =3D=3D c ) {=0A= + printf("\ndata[%d] ", j++);=0A= + c =3D 1;=0A= + }=0A= + }=0A= + printf("\n");=0A= +}=0A= +=0A= static void=0A= mfi_print_frame_flags(device_t dev, uint32_t flags)=0A= {=0A= @@ -127,64 +209,16 @@=0A= {=0A= struct mfi_dcmd_frame *dcmd;=0A= struct mfi_frame_header *hdr;=0A= - const char *opcode;=0A= =0A= dcmd =3D &cm->cm_frame->dcmd;=0A= hdr =3D &dcmd->header;=0A= =0A= - switch (dcmd->opcode) {=0A= - case MFI_DCMD_CTRL_GETINFO:=0A= - opcode =3D "CTRL_GETINFO";=0A= - break;=0A= - case MFI_DCMD_CTRL_FLUSHCACHE:=0A= - opcode =3D "CTRL_FLUSHCACHE";=0A= - break;=0A= - case MFI_DCMD_CTRL_SHUTDOWN:=0A= - opcode =3D "CTRL_SHUTDOWN";=0A= - break;=0A= - case MFI_DCMD_CTRL_EVENT_GETINFO:=0A= - opcode =3D "EVENT_GETINFO";=0A= - break;=0A= - case MFI_DCMD_CTRL_EVENT_GET:=0A= - opcode =3D "EVENT_GET";=0A= - break;=0A= - case MFI_DCMD_CTRL_EVENT_WAIT:=0A= - opcode =3D "EVENT_WAIT";=0A= - break;=0A= - case MFI_DCMD_LD_GET_LIST:=0A= - opcode =3D "LD_GET_LIST";=0A= - break;=0A= - case MFI_DCMD_LD_GET_INFO:=0A= - opcode =3D "LD_GET_INFO";=0A= - break;=0A= - case MFI_DCMD_LD_GET_PROP:=0A= - opcode =3D "LD_GET_PROP";=0A= - break;=0A= - case MFI_DCMD_LD_SET_PROP:=0A= - opcode =3D "LD_SET_PROP";=0A= - break;=0A= - case MFI_DCMD_CLUSTER:=0A= - opcode =3D "CLUSTER";=0A= - break;=0A= - case MFI_DCMD_CLUSTER_RESET_ALL:=0A= - opcode =3D "CLUSTER_RESET_ALL";=0A= - break;=0A= - case MFI_DCMD_CLUSTER_RESET_LD:=0A= - opcode =3D "CLUSTER_RESET_LD";=0A= - break;=0A= - case MFI_DCMD_LD_MAP_GET_INFO:=0A= - opcode =3D "LD_MAP_GET_INFO";=0A= - break;=0A= - default:=0A= - opcode =3D "UNKNOWN";=0A= - break;=0A= - }=0A= -=0A= - device_printf(dev, "cmd=3DMFI_CMD_DCMD opcode=3D%s data_len=3D%d\n",=0A= - opcode, hdr->data_len);=0A= + device_printf(dev, "cmd=3DMFI_CMD_DCMD opcode=3D%s (0x%08x) = data_len=3D%d\n",=0A= + mfi_op_desc(dcmd->opcode), dcmd->opcode, hdr->data_len);=0A= mfi_print_frame_flags(dev, hdr->flags);=0A= mfi_print_sgl(hdr, &dcmd->sgl, hdr->sg_count);=0A= -=0A= + if (NULL !=3D dcmd->mbox)=0A= + mfi_dump_bytes("dcmd->mbox", dcmd->mbox, MFI_MBOX_SIZE);=0A= }=0A= =0A= static void=0A= @@ -278,4 +312,19 @@=0A= }=0A= }=0A= =0A= +const char *=0A= +mfi_op_desc(uint32_t opcode)=0A= +{=0A= + int i;=0A= + int num_ops =3D sizeof(mfi_op_codes)/sizeof(mfi_op_codes[0]);=0A= + for (i =3D 0; i < num_ops; i++) {=0A= + if (mfi_op_codes[i].opcode =3D=3D opcode)=0A= + return(mfi_op_codes[i].desc);=0A= + else if (mfi_op_codes[i].opcode > opcode)=0A= + break;=0A= + }=0A= +=0A= + return ("UNKNOWN");=0A= +}=0A= +=0A= #endif=0A= --- sys/dev/mfi/mfi.c.orig 2012-11-07 12:49:16.123978018 +0000=0A= +++ sys/dev/mfi/mfi.c 2012-11-07 14:40:33.960774577 +0000=0A= @@ -150,6 +150,11 @@=0A= SYSCTL_INT(_hw_mfi, OID_AUTO, detect_jbod_change, CTLFLAG_RW,=0A= &mfi_detect_jbod_change, 0, "Detect a change to a JBOD");=0A= =0A= +static int mfi_cmd_timeout =3D MFI_CMD_TIMEOUT;=0A= +TUNABLE_INT("hw.mfi.cmd_timeout", &mfi_cmd_timeout);=0A= +SYSCTL_INT(_hw_mfi, OID_AUTO, cmd_timeout, CTLFLAG_RW, &mfi_cmd_timeout,=0A= + 0, "Command timeout (in seconds)");=0A= +=0A= /* Management interface */=0A= static d_open_t mfi_open;=0A= static d_close_t mfi_close;=0A= @@ -762,7 +767,7 @@=0A= =0A= /* Start the timeout watchdog */=0A= callout_init(&sc->mfi_watchdog_callout, CALLOUT_MPSAFE);=0A= - callout_reset(&sc->mfi_watchdog_callout, MFI_CMD_TIMEOUT * hz,=0A= + callout_reset(&sc->mfi_watchdog_callout, mfi_cmd_timeout * hz,=0A= mfi_timeout, sc);=0A= =0A= if (sc->mfi_flags & MFI_FLAGS_TBOLT) {=0A= @@ -899,6 +904,7 @@=0A= cm->cm_data =3D buf;=0A= cm->cm_private =3D buf;=0A= cm->cm_len =3D bufsize;=0A= + MFI_PRINT_CMD(cm);=0A= =0A= *cmp =3D cm;=0A= if ((bufp !=3D NULL) && (*bufp =3D=3D NULL) && (buf !=3D NULL))=0A= @@ -2673,6 +2679,7 @@=0A= =0A= mtx_assert(&sc->mfi_io_lock, MA_OWNED);=0A= error =3D 0;=0A= + MFI_PRINT_CMD(cm);=0A= switch (cm->cm_frame->dcmd.opcode) {=0A= case MFI_DCMD_LD_DELETE:=0A= TAILQ_FOREACH(ld, &sc->mfi_ld_tqh, ld_link) {=0A= @@ -2727,6 +2734,7 @@=0A= uint16_t syspd_id;=0A= uint16_t *mbox;=0A= =0A= + MFI_PRINT_CMD(cm);=0A= switch (cm->cm_frame->dcmd.opcode) {=0A= case MFI_DCMD_LD_DELETE:=0A= TAILQ_FOREACH(ld, &sc->mfi_ld_tqh, ld_link) {=0A= @@ -2758,9 +2766,8 @@=0A= }=0A= break;=0A= case MFI_DCMD_CFG_ADD:=0A= - mfi_ldprobe(sc);=0A= - break;=0A= case MFI_DCMD_CFG_FOREIGN_IMPORT:=0A= + if (cm->cm_frame->header.cmd_status =3D=3D MFI_STAT_OK)=0A= mfi_ldprobe(sc);=0A= break;=0A= case MFI_DCMD_PD_STATE_SET:=0A= @@ -3624,7 +3631,7 @@=0A= break;=0A= device_printf(sc->mfi_dev, "Dumping\n\n");=0A= timedout =3D 0;=0A= - deadline =3D time_uptime - MFI_CMD_TIMEOUT;=0A= + deadline =3D time_uptime - mfi_cmd_timeout;=0A= mtx_lock(&sc->mfi_io_lock);=0A= TAILQ_FOREACH(cm, &sc->mfi_busy, cm_link) {=0A= if (cm->cm_timestamp < deadline) {=0A= @@ -3655,10 +3662,11 @@=0A= time_t deadline;=0A= int timedout =3D 0;=0A= =0A= - deadline =3D time_uptime - MFI_CMD_TIMEOUT;=0A= + deadline =3D time_uptime - mfi_cmd_timeout;=0A= if (sc->adpreset =3D=3D 0) {=0A= if (!mfi_tbolt_reset(sc)) {=0A= - callout_reset(&sc->mfi_watchdog_callout, MFI_CMD_TIMEOUT * hz, = mfi_timeout, sc);=0A= + callout_reset(&sc->mfi_watchdog_callout,=0A= + mfi_cmd_timeout * hz, mfi_timeout, sc);=0A= return;=0A= }=0A= }=0A= @@ -3688,7 +3696,7 @@=0A= =0A= mtx_unlock(&sc->mfi_io_lock);=0A= =0A= - callout_reset(&sc->mfi_watchdog_callout, MFI_CMD_TIMEOUT * hz,=0A= + callout_reset(&sc->mfi_watchdog_callout, mfi_cmd_timeout * hz,=0A= mfi_timeout, sc);=0A= =0A= if (0)=0A= ------=_NextPart_000_02FD_01CE0D39.88DA2DE0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 00:39:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C9477E5 for ; Mon, 18 Feb 2013 00:39:59 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 51CF19D for ; Mon, 18 Feb 2013 00:39:59 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U7Elt-000Jdk-Jv; Sun, 17 Feb 2013 16:39:58 -0800 Message-ID: <51217854.8000508@freebsd.org> Date: Sun, 17 Feb 2013 16:39:48 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Phileas Fogg Subject: Re: Scrolling in framebuffer syscons References: <511F879C.3030801@mail.ru> In-Reply-To: <511F879C.3030801@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2/16/2013 5:20 AM, Phileas Fogg wrote: > Hi, > > i have a question about how the scrolling in a framebuffer syscons works. > I'm trying to speed up the syscons on the PS3 console which is a > simple framebuffer syscons. > It uses the renderer _gfbrndrsw_ (see dev/syscons/scgfbrndr.c) to draw > into the framebuffer of the PS3 console. > The _gfb_draw_ function implements a simple scrolling that moves data > from bottom to top with _vidd_copy_. > And that's where i have a problem because _vidd_copy_ calls the > function _ps3fb_copy_ (see powerpc/ps3/ps3_syscons.c). > But the function _ps3fb_copy_ is NOT implemented yet. So, the question > is how does the scrolling work then ? > I took a look at other syscons implementation based on a framebuffer, > and almost all of them do NOT implement _vidd_copy_ > function, e.g. XBOX syscons. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 00:39:59 -0000 On 2/16/2013 5:20 AM, Phileas Fogg wrote: > Hi, > > i have a question about how the scrolling in a framebuffer syscons works. > I'm trying to speed up the syscons on the PS3 console which is a > simple framebuffer syscons. > It uses the renderer _gfbrndrsw_ (see dev/syscons/scgfbrndr.c) to draw > into the framebuffer of the PS3 console. > The _gfb_draw_ function implements a simple scrolling that moves data > from bottom to top with _vidd_copy_. > And that's where i have a problem because _vidd_copy_ calls the > function _ps3fb_copy_ (see powerpc/ps3/ps3_syscons.c). > But the function _ps3fb_copy_ is NOT implemented yet. So, the question > is how does the scrolling work then ? > I took a look at other syscons implementation based on a framebuffer, > and almost all of them do NOT implement _vidd_copy_ > function, e.g. XBOX syscons. I think driver re-renders whole screen character by character. That's why no copy operation is invoked. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 09:09:01 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14C4B527 for ; Mon, 18 Feb 2013 09:09:01 +0000 (UTC) (envelope-from leres@ee.lbl.gov) Received: from fun.ee.lbl.gov (fun.ee.lbl.gov [IPv6:2620:83:8000:102::ca]) by mx1.freebsd.org (Postfix) with ESMTP id E0F1B6C1 for ; Mon, 18 Feb 2013 09:09:00 +0000 (UTC) Received: from ice.ee.lbl.gov (ice.ee.lbl.gov [131.243.2.213]) (authenticated bits=0) by fun.ee.lbl.gov (8.14.6/8.14.6) with ESMTP id r1I98u5A062959 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Feb 2013 01:08:59 -0800 (PST) Message-ID: <5121EFA8.1020902@ee.lbl.gov> Date: Mon, 18 Feb 2013 01:08:56 -0800 From: Craig Leres User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130123 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: "ndp -s" doesn't join the solicited node multicast group (9.1-RELEASE) X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 09:09:01 -0000 I've been using openvpn to tunnel IPv4 into work for a few years now. By using addresses from the same subnet as the endpoint at at work and "arp -s" I can work from home and access services as if I am on the subnet at work. I recently tried to add IPv6 to my openvpn setup. It wasn't difficult to get the endpoints configured so I could ping across the tunnel from one to the other (well, I think there are a couple of bugs in openvpn-2.3.0 with respect to ifconfig-ipv6 but I was able to "fix" them). But I'm not having much success using "ndp -s" to have my endpoint respond to neighbor solicitation requests from hosts on the subnet. I have systems using IPv6 interface aliases and using "route monitor" I see that in addition to the RTM_ADD that happens when you add an interface alias, there's also a RTM_NEWMADDR to join the solicited node multicast group so that the host will actually receive neighbor solicitations: got message of size 140 on Sun Feb 17 22:49:35 2013 RTM_NEWADDR: address being added to iface: len 140, metric 0, flags: sockaddrs: (0) 0 0 0 ffff ffff ffff ffff 0 0 0 0 0 0 em0:0.30.48.74.90.52 2620:83:8000:5502::1187 got message of size 272 on Sun Feb 17 22:49:35 2013 RTM_ADD: Add Route: len 272, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 2620:83:8000:5502::1187 0.30.48.74.90.52 (0) 0 0 0 ffff ffff ffff ffff 0 0 0 0 0 0 got message of size 160 on Sun Feb 17 22:49:35 2013 RTM_NEWMADDR: new multicast group membership on iface: len 160, sockaddrs: 33.33.ff.0.11.87 em0:0.30.48.74.90.52 ff02::1:ff00:1187%em0 But that does not happen when I add the IPv6 address to my ndp table using "ndp -s": got message of size 256 on Mon Feb 18 00:48:35 2013 RTM_GET: Report Metrics: len 256, pid: 24410, seq 1, errno 0, flags: locks: inits: sockaddrs: 2620:83:8000:5502:: (255) ffff ffff ffff ffff ffff ffff ffff got message of size 240 on Mon Feb 18 00:48:35 2013 RTM_ADD: Add Route: len 240, pid: 24410, seq 2, errno 0, flags: locks: inits: sockaddrs: 2620:83:8000:5502::d5 0.30.48.74.90.52 I can see my new address in ndp -an output: 2620:83:8000:5502::d5 00:30:48:74:90:52 em0 permanent R p but without joining the solicited node multicast group it's no surprise the host doesn't respond properly. Anybody know what I'm doing wrong? Craig From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 13:20:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6515281 for ; Tue, 19 Feb 2013 13:20:55 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03b.sare.net (proxypop03b.sare.net [194.30.0.251]) by mx1.freebsd.org (Postfix) with ESMTP id 93928CC3 for ; Tue, 19 Feb 2013 13:20:55 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 86FCE9DD70F for ; Tue, 19 Feb 2013 14:11:42 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Stupid question about integer sizes Date: Tue, 19 Feb 2013 14:11:39 +0100 Message-Id: <77B93E04-9254-4EF1-8BDB-ED9214CEC2BC@sarenet.es> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 13:20:55 -0000 Hello, I'm really sorry if this is a stupid question, but as far as I know, = u_int64_t defined in /usr/include/sys/types.h should *always* be a 64 bit unsigned integer, right?=20 Seems there's a bug (or I need more and stronger coffee). Compiling a = program on a 64 bit system with -m32 gets the 64 bit integer types = wrong. % cat tachin.c=20 #include #include main() { printf("sizeof uint64_t =3D %d\n", sizeof(uint64_t)); printf("sizeof u_int64_t =3D %d\n", sizeof(u_int64_t)); } uname -a FreeBSD splunk 9.1-RELEASE FreeBSD 9.1-RELEASE #14: Wed Jan 23 17:24:05 = CET 2013 root@splunk:/usr/obj/usr/src/sys/SPLUNK amd64 % gcc -o tachin tachin.c % ./tachin sizeof uint64_t =3D 8 sizeof u_int64_t =3D 8 % ./tachin sizeof uint64_t =3D 4 <=3D=3D=3D=3D=3D=3D=3D = WRONG!! sizeof u_int64_t =3D 4 <=3D=3D=3D=3D=3D=3D=3D WRONG!! The same happens with clang. % clang -m32 -o tachin tachin.c tachin.c:5:1: warning: type specifier missing, defaults to 'int' = [-Wimplicit-int] main() ^~~~ 1 warning generated. % ./tachin sizeof uint64_t =3D 4 <=3D=3D=3D=3D=3D=3D=3D WRONG!! sizeof u_int64_t =3D 4 <=3D=3D=3D=3D=3D=3D=3D WRONG!! if I do the same on a i386 system (8.2-RELEASE, but it should be = irrelevant) the u_int64 types have the correct size. %gcc -o tachin tachin.c %./tachin sizeof uint64_t =3D 8 sizeof u_int64_t =3D 8 Am I missing anything? Seems like a too stupid problem to be a real bug. = Sorry if I am wrong. Borja. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 14:52:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 63E56D64 for ; Tue, 19 Feb 2013 14:52:35 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7B3AD9 for ; Tue, 19 Feb 2013 14:52:34 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id j8so1863055qah.0 for ; Tue, 19 Feb 2013 06:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2jhdJ42H/K3SeYoCe+6gF4JAJ2wO1japTLtRDgQQcio=; b=h5lTdTfS8BajI/ZauIy571mvesOaDqjeZLwBe5UqvSD/m76lVVV0XGGF/jpL6E1yQQ QzGGl3CMEB8orx8rCiuNx1swW8igf5PsQdlwMcIWg0qcsF4jn6jUrP3kY05DLUUueMST M8/CghUpR+H0QvIAFKYdQi+6gBWS8kz8TIvj/iipPwwGbDuTPZzVTo/frKjOex2bMuav TME2F0Q925fu12pEFtue3BI470mSYLkS9++kVTkaneWaFEq3xCKm78+m6AR5RkG49REd tmShJarQMVlIk063ANrDpfPNVfbfHA6rUhThIgc7zCUNn6kwt1yThnl/gGaZA6/RWnin lX5A== MIME-Version: 1.0 X-Received: by 10.49.95.166 with SMTP id dl6mr7378314qeb.33.1361285554258; Tue, 19 Feb 2013 06:52:34 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.229.179.42 with HTTP; Tue, 19 Feb 2013 06:52:34 -0800 (PST) In-Reply-To: <77B93E04-9254-4EF1-8BDB-ED9214CEC2BC@sarenet.es> References: <77B93E04-9254-4EF1-8BDB-ED9214CEC2BC@sarenet.es> Date: Tue, 19 Feb 2013 06:52:34 -0800 X-Google-Sender-Auth: lSzbhH5hTqDK2CRuxr6xwvuBkPg Message-ID: Subject: Re: Stupid question about integer sizes From: mdf@FreeBSD.org To: Borja Marcos Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:52:35 -0000 On Tue, Feb 19, 2013 at 5:11 AM, Borja Marcos wrote: > > Hello, > > I'm really sorry if this is a stupid question, but as far as I know, u_int64_t defined in /usr/include/sys/types.h should *always* be > a 64 bit unsigned integer, right? > > Seems there's a bug (or I need more and stronger coffee). Compiling a program on a 64 bit system with -m32 gets the 64 bit integer types wrong. > > % cat tachin.c > #include > #include > > > main() > { > printf("sizeof uint64_t = %d\n", sizeof(uint64_t)); > printf("sizeof u_int64_t = %d\n", sizeof(u_int64_t)); > } > > > > uname -a > FreeBSD splunk 9.1-RELEASE FreeBSD 9.1-RELEASE #14: Wed Jan 23 17:24:05 CET 2013 root@splunk:/usr/obj/usr/src/sys/SPLUNK amd64 > > % gcc -o tachin tachin.c > % ./tachin > sizeof uint64_t = 8 > sizeof u_int64_t = 8 > > % ./tachin > sizeof uint64_t = 4 <======= WRONG!! > sizeof u_int64_t = 4 <======= WRONG!! > > The same happens with clang. > > % clang -m32 -o tachin tachin.c > tachin.c:5:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] > main() > ^~~~ > 1 warning generated. > % ./tachin > sizeof uint64_t = 4 <======= WRONG!! > sizeof u_int64_t = 4 <======= WRONG!! > > > if I do the same on a i386 system (8.2-RELEASE, but it should be irrelevant) the u_int64 types have the correct size. > > %gcc -o tachin tachin.c > %./tachin > sizeof uint64_t = 8 > sizeof u_int64_t = 8 > > > > > > Am I missing anything? Seems like a too stupid problem to be a real bug. Sorry if I am wrong. > Last I knew -m32 still wasn't quite supported on 9.1. This is fixed in CURRENT. The problem in in the machine-dependent headers. sys/types.h includes sys/_types.h which includes machine/_types.h. But the machine alias can only point to one place; it's the amd64 headers since you're running the amd64 kernel. sys/amd64/include/_types.h defines __uint64_t as unsigned long, which is correct in 64-bit mode but wrong in 32-bit mode. On CURRENT there is a merge x86/_types.h which uses #ifdef guards to define __uint64_t as unsigned long or unsigned long long, depending on __LP64__, so that the size is correct on a 32-bit compiler invocation. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 14:56:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 91F09E89; Tue, 19 Feb 2013 14:56:10 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 44B7BB0B; Tue, 19 Feb 2013 14:56:09 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id A14059DEFF3; Tue, 19 Feb 2013 15:56:02 +0100 (CET) Subject: Re: Stupid question about integer sizes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: Date: Tue, 19 Feb 2013 15:56:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <535EFAE7-F064-4B06-A692-62C3BF93780E@sarenet.es> References: <77B93E04-9254-4EF1-8BDB-ED9214CEC2BC@sarenet.es> To: mdf@FreeBSD.org X-Mailer: Apple Mail (2.1085) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:56:10 -0000 On Feb 19, 2013, at 3:52 PM, mdf@FreeBSD.org wrote: > Last I knew -m32 still wasn't quite supported on 9.1. This is fixed Ahh I see. It should print a warning, then. It's the typical thing that = can drive you nuts ;) Thanks, Borja. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 18:30:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D911FC85; Tue, 19 Feb 2013 18:30:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 24EBCCD0; Tue, 19 Feb 2013 18:30:06 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1JITwqu022827; Tue, 19 Feb 2013 20:29:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1JITwqu022827 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1JITwWr022826; Tue, 19 Feb 2013 20:29:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 19 Feb 2013 20:29:58 +0200 From: Konstantin Belousov To: mdf@FreeBSD.org Subject: Re: Stupid question about integer sizes Message-ID: <20130219182958.GA2598@kib.kiev.ua> References: <77B93E04-9254-4EF1-8BDB-ED9214CEC2BC@sarenet.es> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Gv4AD2GulCTyUAWX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, Borja Marcos X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:30:07 -0000 --Gv4AD2GulCTyUAWX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2013 at 06:52:34AM -0800, mdf@FreeBSD.org wrote: > On Tue, Feb 19, 2013 at 5:11 AM, Borja Marcos wrote: > > > > Hello, > > > > I'm really sorry if this is a stupid question, but as far as I know, u_= int64_t defined in /usr/include/sys/types.h should *always* be > > a 64 bit unsigned integer, right? > > > > Seems there's a bug (or I need more and stronger coffee). Compiling a p= rogram on a 64 bit system with -m32 gets the 64 bit integer types wrong. > > > > % cat tachin.c > > #include > > #include > > > > > > main() > > { > > printf("sizeof uint64_t =3D %d\n", sizeof(uint64_t)); > > printf("sizeof u_int64_t =3D %d\n", sizeof(u_int64_t)); > > } > > > > > > > > uname -a > > FreeBSD splunk 9.1-RELEASE FreeBSD 9.1-RELEASE #14: Wed Jan 23 17:24:05= CET 2013 root@splunk:/usr/obj/usr/src/sys/SPLUNK amd64 > > > > % gcc -o tachin tachin.c > > % ./tachin > > sizeof uint64_t =3D 8 > > sizeof u_int64_t =3D 8 > > > > % ./tachin > > sizeof uint64_t =3D 4 <=3D=3D=3D=3D=3D=3D=3D WRON= G!! > > sizeof u_int64_t =3D 4 <=3D=3D=3D=3D=3D=3D=3D WRONG!! > > > > The same happens with clang. > > > > % clang -m32 -o tachin tachin.c > > tachin.c:5:1: warning: type specifier missing, defaults to 'int' [-Wimp= licit-int] > > main() > > ^~~~ > > 1 warning generated. > > % ./tachin > > sizeof uint64_t =3D 4 <=3D=3D=3D=3D=3D=3D=3D WRONG!! > > sizeof u_int64_t =3D 4 <=3D=3D=3D=3D=3D=3D=3D WRONG!! > > > > > > if I do the same on a i386 system (8.2-RELEASE, but it should be irrele= vant) the u_int64 types have the correct size. > > > > %gcc -o tachin tachin.c > > %./tachin > > sizeof uint64_t =3D 8 > > sizeof u_int64_t =3D 8 > > > > > > > > > > > > Am I missing anything? Seems like a too stupid problem to be a real bug= =2E Sorry if I am wrong. > > >=20 > Last I knew -m32 still wasn't quite supported on 9.1. This is fixed > in CURRENT. The problem in in the machine-dependent headers. > sys/types.h includes sys/_types.h which includes machine/_types.h. > But the machine alias can only point to one place; it's the amd64 > headers since you're running the amd64 kernel. > sys/amd64/include/_types.h defines __uint64_t as unsigned long, which > is correct in 64-bit mode but wrong in 32-bit mode. >=20 > On CURRENT there is a merge x86/_types.h which uses #ifdef guards to > define __uint64_t as unsigned long or unsigned long long, depending on > __LP64__, so that the size is correct on a 32-bit compiler invocation. Yes, but there are still some unconverted headers, mostly related to the machine context and signal handlers. Quick look: machine/sigframe.h (probably not much useful for usermode) machine/ucontext.h machine/frame.h (again, usermode most likely does not need it) machine/signal.h machine/elf.h libm machdep headers. --Gv4AD2GulCTyUAWX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRI8SlAAoJEJDCuSvBvK1BIycP/2WSzY6Rmm6DHDbB2hNk6JO/ LukeoIigKcNjrUCvhlaroiz5GrqW4lmLk23z2M0YZVrXdkmOL2HBmXcu2ce78+Oi K+BtxI4uG6h+q4eTUntWVuCTPfb2Xe7TKzF16pfYzBfKZMZpZk+8H5jlSBjJ5cGO uKacLVkn9adhD8Icoswt+9caDX+a34Zg7mOxkiDJ90xUL8yIXOSfJn6gwSzNihSa SBE/xhw0QRI+CdZdatxqz7t+YR9NIv2xnw13/CV1UKZB6OTz3i49MuMHuCKPnHiZ vlCm0v5nG1Fr3S0Hd56IrbUyvNfqlh2iXZNEeQcjLskXMJ7ZfYxt1uvKBdGm14rE 51MEG5EwxWF09z+RKJ032+6NmosajL7guFM//xd02+xu54sEf+Z8TMBdV7kHF1Js EHEb6kzXiqkJg+qHBrKLx/4y+50O7WyPCABnPBkzJwBxDSz9LOsuXApLZXBUwWaN /mSE8aKMGIWvt+LmqhnS45u4MPXnPtNwi7Z9u4w7jOE4wpgh2+ZiTlDGL/XChPQk KEiF8MPTbQ9lhhCgxiFpMLHD1N7Jjc6EDJpBcDGOn8NVF0/c+fcCw3S05o/8OGX4 3wbP8OHsasFN59emn09ShX2kAjcWBN5IfPbTnc8RI28ApJtU5QuuFrKi/+zk754Q FT0H4PYQPEtlHIOGs7W3 =02kY -----END PGP SIGNATURE----- --Gv4AD2GulCTyUAWX-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 18:57:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA92795E; Tue, 19 Feb 2013 18:57:59 +0000 (UTC) (envelope-from phileas-fogg@mail.ru) Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110]) by mx1.freebsd.org (Postfix) with ESMTP id 51641EE8; Tue, 19 Feb 2013 18:57:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DtTmWatqmGwu4v4j6aqrKyaAnVSLmnQfNuwERIectYs=; b=E1ZPrl7iP8LSDaMZyh7UsMjQcLORluWgEG5oFo6Hgwnfh3wWPrft2/IerskXzw4DjmRVzYhmKff+2gUKApnNt5RRZs14CiZmo//nOoHN6/rvoBlIslXMRF2jJkOEDU72; Received: from [46.5.21.251] (port=65531 helo=[192.168.1.76]) by smtp50.i.mail.ru with esmtpa (envelope-from ) id 1U7sNz-0005L6-Pi; Tue, 19 Feb 2013 22:57:52 +0400 Message-ID: <5123D941.2050906@mail.ru> Date: Tue, 19 Feb 2013 20:57:53 +0100 From: Phileas Fogg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.2 MIME-Version: 1.0 To: Oleksandr Tymoshenko Subject: Re: Scrolling in framebuffer syscons References: <511F879C.3030801@mail.ru> <51217854.8000508@freebsd.org> In-Reply-To: <51217854.8000508@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:58:00 -0000 Oleksandr Tymoshenko wrote: > On 2/16/2013 5:20 AM, Phileas Fogg wrote: >> Hi, >> >> i have a question about how the scrolling in a framebuffer syscons works. >> I'm trying to speed up the syscons on the PS3 console which is a simple >> framebuffer syscons. >> It uses the renderer _gfbrndrsw_ (see dev/syscons/scgfbrndr.c) to draw into >> the framebuffer of the PS3 console. >> The _gfb_draw_ function implements a simple scrolling that moves data from >> bottom to top with _vidd_copy_. >> And that's where i have a problem because _vidd_copy_ calls the function >> _ps3fb_copy_ (see powerpc/ps3/ps3_syscons.c). >> But the function _ps3fb_copy_ is NOT implemented yet. So, the question is how >> does the scrolling work then ? >> I took a look at other syscons implementation based on a framebuffer, and >> almost all of them do NOT implement _vidd_copy_ >> function, e.g. XBOX syscons. > > I think driver re-renders whole screen character by character. That's why no > copy operation is invoked. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" You are right, syscons is using the teken terminal emulator which implements scrolling in software. The vidd_copy callback is never called. To optimize the PS3 syscons driver, i have to speed up vidd_puts and vidd_putc callbacks. regards From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 19:02:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A0EA0E32 for ; Tue, 19 Feb 2013 19:02:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 802F6F6D for ; Tue, 19 Feb 2013 19:02:51 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E6BDCB9BA; Tue, 19 Feb 2013 14:02:50 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Looking for reviewers for patch that adds foreign disk support mfiutil Date: Tue, 19 Feb 2013 13:46:33 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <49693195BAD841469129EE4B7523CABE@multiplay.co.uk> In-Reply-To: <49693195BAD841469129EE4B7523CABE@multiplay.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302191346.33415.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 19 Feb 2013 14:02:51 -0500 (EST) Cc: Steven Hartland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:02:51 -0000 On Sunday, February 17, 2013 1:06:40 pm Steven Hartland wrote: > Hi all I'm looking for someone to review the attached patch > to mfiutil which adds foreign disk support to mfiutil as > per: > http://www.freebsd.org/cgi/query-pr.cgi?pr=172091 > > Any and all feedback welcome :) Some suggestions: - Please stick with FreeBSD style, e.g. please use: if (foo == NULL) rather than: if (NULL == foo) I understand the reasons for the latter style (turn accidental assignments into compile errors) but I don't buy them because 1) modern compilers can already catch such things, but most importantly 2) it doesn't read correctly. Above all else code should be readable, and one doesn't say "if NULL the pointer is" (unless one is Yoda), but "if the pointer is NULL". - Don't make dump_config() use a default prefix, just fix the existing call to dump_config() to pass in a prefix. - Is dump_config() really the right choice for 'foreign config'? It doesn't attempt to output things very pretty, and I think mfiutil's non-debug commands should aim to be human readable. - This (human readable) is also why it doesn't include the opcode in the error message by default. Sysadmins don't really care which opcode fails. Maybe put that under '#ifdef DEBUG'? - mfireg.h should be kept in sync with the driver's version of that header, so don't reorder the enum's unless you are changing it to match what is in the device driver's mfireg.h. In fact, mfiutil should probably be using the mfireg.h from sys/dev/mfi directly now that it is in the tree. (mfiutil was originally developed outside of the tree as a standalone app) - Leaving out the 'MFI_DCMD_' prefix from the opcode description was intentional. If you are ever fortunate enough to examine the manuals from LSI, they refer to the firmware commands as 'LD_CONFIG', etc. (Maybe it's 'MR_LD_CONFIG'?) The MFI_DCMD_ prefix is specific to the FreeBSD driver. - Please don't do assignments in declarations and leave a blank line between declarations and the bode of code. Thus: mfi_op_desc(...) { int i, num_ops; num_ops = nitems(mfi_op_codes); ... (nitems() is nice to use when it is available as well) - Reindent the call to mfi_ldprobe() if CFG_ADD or CFG_FOREIGN_IMPORT succeeds. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 23:49:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB2A080F; Tue, 19 Feb 2013 23:49:45 +0000 (UTC) (envelope-from smh@freebsd.org) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 449E0193; Tue, 19 Feb 2013 23:49:44 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Tue, 19 Feb 2013 23:49:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002303041.msg; Tue, 19 Feb 2013 23:49:36 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: smh@freebsd.org X-Envelope-From: smh@freebsd.org Message-ID: <70A4A7995FBD430EA37B56C0C8B32B34@multiplay.co.uk> From: "Steven Hartland" To: "John Baldwin" , References: <49693195BAD841469129EE4B7523CABE@multiplay.co.uk> <201302191346.33415.jhb@freebsd.org> Subject: Re: Looking for reviewers for patch that adds foreign disk support mfiutil Date: Tue, 19 Feb 2013 23:49:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:49:45 -0000 ----- Original Message ----- From: "John Baldwin" Thanks for the feedback John appreciated, a couple of questions inline below if you would be so kind. > On Sunday, February 17, 2013 1:06:40 pm Steven Hartland wrote: >> Hi all I'm looking for someone to review the attached patch >> to mfiutil which adds foreign disk support to mfiutil as >> per: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=172091 >> >> Any and all feedback welcome :) > > Some suggestions: > > - Please stick with FreeBSD style, e.g. please use: > > if (foo == NULL) > > rather than: > > if (NULL == foo) > > I understand the reasons for the latter style (turn accidental assignments > into compile errors) but I don't buy them because 1) modern compilers can > already catch such things, but most importantly 2) it doesn't read > correctly. Above all else code should be readable, and one doesn't say > "if NULL the pointer is" (unless one is Yoda), but "if the pointer is NULL". Acknowledged, I'm working through some old patches so need to bring them in line, will check for others like this. > - Don't make dump_config() use a default prefix, just fix the existing call > to dump_config() to pass in a prefix. Done. > - Is dump_config() really the right choice for 'foreign config'? It doesn't > attempt to output things very pretty, and I think mfiutil's non-debug > commands should aim to be human readable. Will check this, just didn't want to re-invent the wheel ;-) > - This (human readable) is also why it doesn't include the opcode in the error > message by default. Sysadmins don't really care which opcode fails. Maybe > put that under '#ifdef DEBUG'? Previously there was no information about what command failed, which made the failure message kinda useless, so while debugging I added the opcode to help me trace things. In order to keep it more user friendly I'm thinking of using mfi_op_desc, but this is currently only available under MFI_DEBUG from mfi_debug.c. Would it be better to move this else where e.g. mfireg.h so human readable command information is always available? > - mfireg.h should be kept in sync with the driver's version of that header, so > don't reorder the enum's unless you are changing it to match what is in the > device driver's mfireg.h. In fact, mfiutil should probably be using the > mfireg.h from sys/dev/mfi directly now that it is in the tree. (mfiutil > was originally developed outside of the tree as a standalone app) There is only one mfireg.h and that is already in sys/dev/mfi :) > - Leaving out the 'MFI_DCMD_' prefix from the opcode description was > intentional. If you are ever fortunate enough to examine the manuals from > LSI, they refer to the firmware commands as 'LD_CONFIG', etc. (Maybe it's > 'MR_LD_CONFIG'?) The MFI_DCMD_ prefix is specific to the FreeBSD driver. Thanks for the info, changed. > - Please don't do assignments in declarations and leave a blank line between > declarations and the bode of code. Thus: > > mfi_op_desc(...) > { > int i, num_ops; > > num_ops = nitems(mfi_op_codes); > ... > > (nitems() is nice to use when it is available as well) Changed, this the case for constant initialisers too? e.g. is the following incorrect or acceptable? myfunc(...) { int i = 0, j = 1; ... > - Reindent the call to mfi_ldprobe() if CFG_ADD or CFG_FOREIGN_IMPORT > succeeds. Nice spot, sorted. Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 00:03:27 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 84B56D0A for ; Wed, 20 Feb 2013 00:03:27 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 43721215 for ; Wed, 20 Feb 2013 00:03:26 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r1K039AT088878 for ; Tue, 19 Feb 2013 16:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1361318590; bh=A/ifCaJRF3u23wWaiYCzhZlChzV0hRhJ+D7j3bYQexo=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=UKr2ABuIpl6GflrnM0PJOv/ylV2ylsKPpbWeVPyF9hHuztBdu2o7q1jZ9EicTfVqq OCYgFkSdApXNrUdXfmUBfb4Sehw8UgwA2nyTlcNLIjUnNnMcBVeunM888yUlPeEfTQ AoFvA1v4bPBfnnEhEidEN13TQUcMiq9aCwEZl7yU= Subject: sparc64 zfsroot/gmirror? From: Sean Bruno To: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Feb 2013 16:03:09 -0800 Message-ID: <1361318589.3815.12.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 318589004 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:03:27 -0000 I'm restoring some of the sparc64 machines for freebsd.org and had a question with regards to what to do about the / Since it wasn't obvious how to setup zfs root things I setup something that looks like this: => 0 71087625 da0 VTOC8 (33G) 0 385560 1 freebsd-ufs (188M) 385560 70702065 2 freebsd-zfs (33G) => 0 71087625 da1 VTOC8 (33G) 0 385560 1 freebsd-ufs (188M) 385560 70702065 2 freebsd-zfs (33G) Where everything *except* /boot is in the mirrored zpool. I can reinstall the system trivially, and am looking for suggestions. Sean From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 03:59:37 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D3B817B5; Wed, 20 Feb 2013 03:59:37 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id AEFC6DFC; Wed, 20 Feb 2013 03:59:37 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r1K3xauW062442; Tue, 19 Feb 2013 22:59:36 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id r1K3xaoB062441; Tue, 19 Feb 2013 22:59:36 -0500 (EST) (envelope-from lidl) Date: Tue, 19 Feb 2013 22:59:36 -0500 From: Kurt Lidl To: sbruno@freebsd.org Subject: Re: sparc64 zfsroot/gmirror? Message-ID: <20130220035936.GA62301@pix.net> References: <1361318589.3815.12.camel@powernoodle.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1361318589.3815.12.camel@powernoodle.corp.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:59:37 -0000 On Tue, Feb 19, 2013 at 04:03:09PM -0800, Sean Bruno wrote: > I'm restoring some of the sparc64 machines for freebsd.org and had a > question with regards to what to do about the / > > Since it wasn't obvious how to setup zfs root things I setup something > that looks like this: > > => 0 71087625 da0 VTOC8 (33G) > 0 385560 1 freebsd-ufs (188M) > 385560 70702065 2 freebsd-zfs (33G) > > => 0 71087625 da1 VTOC8 (33G) > 0 385560 1 freebsd-ufs (188M) > 385560 70702065 2 freebsd-zfs (33G) > > > Where everything *except* /boot is in the mirrored zpool. > > I can reinstall the system trivially, and am looking for suggestions. I wrote up a script to do the heavy lifting for installing a completely zfs system on a sparc64 machine. http://www.pix.net/ftp/pub/freebsd/sparc_zfs_setup.txt The 12GB space for zfs is appropriate for a 18Gb disk, and allows the remainder of the disk space to accommodate a 4Gb-ish swap space, for crash dumps. The swap is placed at the end of the disk, since that's the slowest part to access. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 04:52:55 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9DE982F5 for ; Wed, 20 Feb 2013 04:52:55 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 77139FD8 for ; Wed, 20 Feb 2013 04:52:55 +0000 (UTC) Received: by mail-da0-f45.google.com with SMTP id w4so3347186dam.32 for ; Tue, 19 Feb 2013 20:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer; bh=Z5qAMfrmmGaNTG96rgOLSxOQthMt1LtvnoGy+nmTdfg=; b=1GpkMuk3+MljAtf3SH/KiX036gtuzxAYjF/9l9ySXia10gKzO1JpEEbdsEE82h9D19 IMKZoVT3jHCkcYcnbY8aQD7TDBSU90wA5TyiQbZFowBSbDx7Smlaphg865wiyS7YK6nD mYjR4TmxYnzCH9z9QB8KW3CYAzkvKEe0ddl9jgpfvBVywVaDsDXbjzpyaVMJ5DkTvy1r 1AIgm40nZFdJ6Nibt/C6O3Fls/pYFVyqqbaxsooXeybbTyjptFqshpSRq4i/uLFTXN/y KnibsBOFBZT7/pR8/JVqJ6Gs09OZny0s16VdIWllH3uwjXk8kNB8q6UNX6Z/rDZ5a6qI saVQ== X-Received: by 10.68.224.169 with SMTP id rd9mr448437pbc.199.1361335974978; Tue, 19 Feb 2013 20:52:54 -0800 (PST) Received: from [192.168.1.210] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id i6sm109802670paw.19.2013.02.19.20.52.52 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 20:52:53 -0800 (PST) Subject: Re: sparc64 zfsroot/gmirror? From: Sean Bruno To: Kurt Lidl In-Reply-To: <20130220035936.GA62301@pix.net> References: <1361318589.3815.12.camel@powernoodle.corp.yahoo.com> <20130220035936.GA62301@pix.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-maQmYNqessROBPEk0Q5h" Date: Tue, 19 Feb 2013 20:52:51 -0800 Message-ID: <1361335971.2816.3.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 04:52:55 -0000 --=-maQmYNqessROBPEk0Q5h Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2013-02-19 at 22:59 -0500, Kurt Lidl wrote: > On Tue, Feb 19, 2013 at 04:03:09PM -0800, Sean Bruno wrote: > > I'm restoring some of the sparc64 machines for freebsd.org and had a > > question with regards to what to do about the / > >=20 > > Since it wasn't obvious how to setup zfs root things I setup something > > that looks like this: > >=20 > > =3D> 0 71087625 da0 VTOC8 (33G) > > 0 385560 1 freebsd-ufs (188M) > > 385560 70702065 2 freebsd-zfs (33G) > >=20 > > =3D> 0 71087625 da1 VTOC8 (33G) > > 0 385560 1 freebsd-ufs (188M) > > 385560 70702065 2 freebsd-zfs (33G) > >=20 > >=20 > > Where everything *except* /boot is in the mirrored zpool. > >=20 > > I can reinstall the system trivially, and am looking for suggestions. >=20 > I wrote up a script to do the heavy lifting for installing > a completely zfs system on a sparc64 machine. >=20 > http://www.pix.net/ftp/pub/freebsd/sparc_zfs_setup.txt >=20 > The 12GB space for zfs is appropriate for a 18Gb disk, and allows > the remainder of the disk space to accommodate a 4Gb-ish swap space, > for crash dumps. The swap is placed at the end of the disk, since > that's the slowest part to access. >=20 > -Kurt >=20 Ah, I see I'm completely overthinking it. =46rom your script: gpart bootcode -p /boot/zfsboot ${disk} dd if=3D/boot/zfsloader of=3D/dev/${disk}a bs=3D512 oseek1024 conv=3Dnotrunc,sync That's what I was missing hence my silly layout. Sean --=-maQmYNqessROBPEk0Q5h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJRJFajAAoJEBkJRdwI6BaHAKUH+wSn714n9/zEMLrFQ78AYiNH HpF+IPYThNp9E0/llLZTf5QAGYFiHPLZnok5/F5SBIbPeSNJVwnquRiiWmTld23E rohiyVaQgcrtrLDvTs2hthrY+jaF1+KCTRKPf+DlFjKKII8nXdsEe0VY7Z/wTAxZ O/eHmm+ttmaMReCL96mF3mvvRfTgiyOdF7YQ6A5pmpijqq/8fBHmPNOVbVdbXDTi hKgxEYllw8uk/4M2exLVmojj1LbRlS1/d1OsGYlrcn5VBTijZWaacQvwF+HuyWr0 UmeOfMX9aF1jSLYMSZbiAFv9gSG6qYxeMrTg8ns3gJAkL72B/77OWRzZJ/7OIKU= =V48Q -----END PGP SIGNATURE----- --=-maQmYNqessROBPEk0Q5h-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 06:58:18 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DEE7A60F for ; Wed, 20 Feb 2013 06:58:18 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 96A2467E for ; Wed, 20 Feb 2013 06:58:18 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r1K6wANo025057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 07:58:15 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r1K6wAox025056 for hackers@freebsd.org; Wed, 20 Feb 2013 07:58:10 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Wed, 20 Feb 2013 07:58:10 +0100 From: Paul Schenkeveld To: hackers@freebsd.org Subject: Chicken and egg, encrypted root FS on remote server Message-ID: <20130220065810.GA25027@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 06:58:18 -0000 Hi, I've been trying to find a solution for this chicken and egg problem, how to have an encrypted root filesystem on a remote server. Geli can ask for a root password at the console to unlock the root fs but that of course won't work for a remote server. Ideally I'd like the server to start, do minimal network config, run a minimal ssh client (dropbear?) and wait for someone to log in, provide the passphrase to unlock the root filesystem and then mount the root filesystem and do a normal startup. I read about a pivotroot call in other OS-es, that would allow for a very small unencrypted root filesystem to be mounted temporarily until the passphrase has been entered and then swap that for a real, encrypted root filesystem. But AFAIK we don't have pivotroot. The problem could also be solved if the real root fs could be union mounted over the small unencrypted one but unionfs won't mount over /. I found out that a ZFS pool where a specific dataset has the mountpoint=/ option set can be used to 'buri' the unencrypted root under the real root but that would render the unencrypted one unchangable after the real one is mounted (prohibiting sysadmin to change the ssh credentials or network config there). It would also make maintenance a bit more difficult because an import of the zpool would automatically remount /, even when running from a cd-rom or USB stick. And of course this approach would not work in non-zfs environments (like very small systems). Looking at sys/kern/init_main.c and sys/kern/vfs_mount.c I could imagine having a kind of "pre root environment", an unencrypted root that gets mounted first (along with a devfs) and a /sbin/init that sets up minimal networking and runs sshd. Aftre that one dies the unencrypted root and devfs would be unmounted, the real root mounted and the real /sbin/init started. But this may be a considered a dirty approach. Did I miss the obvious and easy solution? Any ideas? With kind regards, Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 07:14:24 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A68BA8A8 for ; Wed, 20 Feb 2013 07:14:24 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 174E66FD for ; Wed, 20 Feb 2013 07:14:23 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id o1so5797429wic.5 for ; Tue, 19 Feb 2013 23:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TmzhucmgjKb+IYeSigBBfO9YOK2i4D3XZwBMq9V8jic=; b=YHTRykmQCPSefNVHwLC60obVDeyHOkiVCWCe8kCPQ1uERc/wNARiTKac4mpb2ObgMJ is+j05jrLG4J3huBAv2zDZrhYRqsv0ReXQkoYSATaJI+OYy37Xq6TlZ5cDmz9iJMz7Wb lgdPGYBgXcnSVJ4jTtsrYmuE+tLYJpEHIWxYKeWp/Oc/jooCa0OpHmYvJq7Tgdvbuexc RTOmizs4s/rijUhzHccCuBtPJEgot1wm5nvJU97fQaJql/emhAxZvxbo2LRgY4Vnfgj+ ozBXKSP34Qsm0GBiy/LtmMmJG0CetAYDsLdSB1VnHr8quNv/qsLIAU5jL448p59ilv37 vpdQ== MIME-Version: 1.0 X-Received: by 10.194.172.197 with SMTP id be5mr31348690wjc.20.1361344462662; Tue, 19 Feb 2013 23:14:22 -0800 (PST) Received: by 10.194.85.116 with HTTP; Tue, 19 Feb 2013 23:14:22 -0800 (PST) In-Reply-To: <20130220065810.GA25027@psconsult.nl> References: <20130220065810.GA25027@psconsult.nl> Date: Wed, 20 Feb 2013 09:14:22 +0200 Message-ID: Subject: Re: Chicken and egg, encrypted root FS on remote server From: Alexander Yerenkow To: Paul Schenkeveld Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:14:24 -0000 2013/2/20 Paul Schenkeveld > Hi, > > I've been trying to find a solution for this chicken and egg problem, > how to have an encrypted root filesystem on a remote server. > > Geli can ask for a root password at the console to unlock the root fs > but that of course won't work for a remote server. > > Ideally I'd like the server to start, do minimal network config, run > a minimal ssh client (dropbear?) and wait for someone to log in, > provide the passphrase to unlock the root filesystem and then mount > the root filesystem and do a normal startup. > > I read about a pivotroot call in other OS-es, that would allow for a > very small unencrypted root filesystem to be mounted temporarily until > the passphrase has been entered and then swap that for a real, encrypted > root filesystem. But AFAIK we don't have pivotroot. > > The problem could also be solved if the real root fs could be union > mounted over the small unencrypted one but unionfs won't mount over /. > > I found out that a ZFS pool where a specific dataset has the > mountpoint=/ option set can be used to 'buri' the unencrypted root under > the real root but that would render the unencrypted one unchangable > after the real one is mounted (prohibiting sysadmin to change the ssh > credentials or network config there). It would also make maintenance > a bit more difficult because an import of the zpool would automatically > remount /, even when running from a cd-rom or USB stick. And of course > this approach would not work in non-zfs environments (like very small > systems). > > Looking at sys/kern/init_main.c and sys/kern/vfs_mount.c I could > imagine having a kind of "pre root environment", an unencrypted root > that gets mounted first (along with a devfs) and a /sbin/init that > sets up minimal networking and runs sshd. Aftre that one dies the > unencrypted root and devfs would be unmounted, the real root mounted > and the real /sbin/init started. But this may be a considered a dirty > approach. > > Did I miss the obvious and easy solution? Any ideas? > I'd like to propose you to see my similar setup - it's used for VMs. Idea is to have base OS in little partition, and use it only in RO. All data, and configs goes in different partitions, which could be connected manually or automatically. What you need is to specify in loader.conf init_script="/etc/find-rwfs.sh" My example: https://github.com/yerenkow/freebsd-vm-image/blob/master/freebsd-firmware/find-rwfs.sh In this way, you can get RO booted OS, just waited for you to login and mount all required data. Also, you could contact Andriy Gapon, he managed to do other trick - boot from RO media such as CD, and run all OS as chroot, all transparently. Hope this helps! > With kind regards, > > Paul Schenkeveld > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Regards, Alexander Yerenkow From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 07:20:23 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2F02BEB for ; Wed, 20 Feb 2013 07:20:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id A0CE0743 for ; Wed, 20 Feb 2013 07:20:23 +0000 (UTC) Received: from Xins-MacBook-Pro-2.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0A1AB24CA4; Tue, 19 Feb 2013 23:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361344823; bh=fNoZykkzuybG9vaLkoxTBUE3mAXlgg2sDndIodSkSs8=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=xRaAkNEo22noq0UM6OsQ5pKF0EJUCTBoR1gJlsHqqy2IaB43GVvVN84BKp5VktK2N Ch8rIscqIa48ydiCB8mj+XYVsja8qo0ffsF7FRwPwM7ud1VRNxaQq0oJWvPXIYdKJY B6w53YUmvRs73l1mvM6b4knmPHyIk/AiVkvY1olc= Message-ID: <51247936.8050801@delphij.net> Date: Tue, 19 Feb 2013 23:20:22 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Paul Schenkeveld Subject: Re: Chicken and egg, encrypted root FS on remote server References: <20130220065810.GA25027@psconsult.nl> In-Reply-To: <20130220065810.GA25027@psconsult.nl> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:20:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/19/13 10:58 PM, Paul Schenkeveld wrote: > Ideally I'd like the server to start, do minimal network config, > run a minimal ssh client (dropbear?) and wait for someone to log > in, provide the passphrase to unlock the root filesystem and then > mount the root filesystem and do a normal startup. At work I have something like this, basically the setup have a small / that is not encrypted, and I have a script called 'geli0' that starts network, sshd and waits for the GELI provider be unlocked or someone hit enter on console (and then unlock from console, of course). I'm not sure if this is even near your requirement nor it's intended for use by general public. Be sure to change ada0s1d to match your system by the way. ==== #!/bin/sh # # PROVIDE: geli0 # BEFORE: disks # REQUIRE: initrandom # KEYWORD: nojail . /etc/rc.subr name="geli0" start_cmd="geli0_start" stop_cmd=":" required_modules="geom_eli:g_eli" geli0_start() { fsck -py / || fsck -fy / mount -uw / /etc/rc.d/hostid start /etc/rc.d/hostname start /etc/rc.d/devd start /etc/rc.d/netif start /etc/rc.d/routing start /etc/rc.d/sshd start echo -n "Waiting ada0s1d to be available, press enter to continue..." while true; do if [ -e /dev/ada0s1d.eli ]; then break fi read -t 5 dummy && break done /etc/rc.d/sshd stop /etc/rc.d/routing stop /etc/rc.d/netif stop /etc/rc.d/devd stop } load_rc_config $name run_rc_command "$1" ===== Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJRJHk2AAoJEG80Jeu8UPuz1mgH/Rjsk0NgHn6r/mNB+G00OizR BOprd4wuctvNn/zr/syjM/UqixWI1WIXBDQAICZWTml938i5Mg65bi+qdszmRwbS zzlSRUJ/N6oYQvUPnuCxjtIU3gvCKplt0bBz/RxRVNSzqMEgOTuta9Kd0IVU2MZW zVZ0rmClScTA2zgGGFmQCZc1ot5CZfa66psSkdQIwLOvxp2o1ZHzMh5+owG8R0ys 8DE+aQ4d57Vt/JoRQW2W1OIfestOmf1uqL7HsnELL1nF0BTtG8GThfy+RzGAA3mm vUKXFwiLwon+gJath2eIT2s/tCz5rKPisiXeBqAYUSWUNTqTWf2CXmfMXeL4+TM= =gcTR -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 07:39:37 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4BE3E2EB for ; Wed, 20 Feb 2013 07:39:37 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 97C3F826 for ; Wed, 20 Feb 2013 07:39:36 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r1K7dUXs059834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 08:39:35 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r1K7dUkN059833; Wed, 20 Feb 2013 08:39:30 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Wed, 20 Feb 2013 08:39:30 +0100 From: Paul Schenkeveld To: Alexander Yerenkow Subject: Re: Chicken and egg, encrypted root FS on remote server Message-ID: <20130220073930.GA59518@psconsult.nl> References: <20130220065810.GA25027@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:39:37 -0000 On Wed, Feb 20, 2013 at 09:14:22AM +0200, Alexander Yerenkow wrote: > 2013/2/20 Paul Schenkeveld > > > Hi, > > > > I've been trying to find a solution for this chicken and egg problem, > > how to have an encrypted root filesystem on a remote server. > > > > Geli can ask for a root password at the console to unlock the root fs > > but that of course won't work for a remote server. > > > > Ideally I'd like the server to start, do minimal network config, run > > a minimal ssh client (dropbear?) and wait for someone to log in, > > provide the passphrase to unlock the root filesystem and then mount > > the root filesystem and do a normal startup. > > > > I read about a pivotroot call in other OS-es, that would allow for a > > very small unencrypted root filesystem to be mounted temporarily until > > the passphrase has been entered and then swap that for a real, encrypted > > root filesystem. But AFAIK we don't have pivotroot. > > > > The problem could also be solved if the real root fs could be union > > mounted over the small unencrypted one but unionfs won't mount over /. > > > > I found out that a ZFS pool where a specific dataset has the > > mountpoint=/ option set can be used to 'buri' the unencrypted root under > > the real root but that would render the unencrypted one unchangable > > after the real one is mounted (prohibiting sysadmin to change the ssh > > credentials or network config there). It would also make maintenance > > a bit more difficult because an import of the zpool would automatically > > remount /, even when running from a cd-rom or USB stick. And of course > > this approach would not work in non-zfs environments (like very small > > systems). > > > > Looking at sys/kern/init_main.c and sys/kern/vfs_mount.c I could > > imagine having a kind of "pre root environment", an unencrypted root > > that gets mounted first (along with a devfs) and a /sbin/init that > > sets up minimal networking and runs sshd. Aftre that one dies the > > unencrypted root and devfs would be unmounted, the real root mounted > > and the real /sbin/init started. But this may be a considered a dirty > > approach. > > > > Did I miss the obvious and easy solution? Any ideas? > > > > I'd like to propose you to see my similar setup - it's used for VMs. > Idea is to have base OS in little partition, and use it only in RO. > All data, and configs goes in different partitions, which could be > connected manually or automatically. So far, I've done something similar using the nanobsd(8) framework. Disadvantage is that usually /etc is either part of the root filesystem or a md(4) filesystem (like the diskless framework and nanobsd use). Another disadvantage is that upgrades to the root filesystem (installworld, installkernel) do not work out of the box. I was hoping to get closer to a 'normal' installation for certain servers I maintain. My ramblings about using nanobsd for servers can be found here: http://www.psconsult.nl/talks/AsiaBSDcon2010-Servers/ > What you need is to specify in loader.conf > init_script="/etc/find-rwfs.sh" Hey, this one is new to me. Very interesting, won't solve this problem but would allow things like having /etc on a separate filesystem and things like that. > My example: > https://github.com/yerenkow/freebsd-vm-image/blob/master/freebsd-firmware/find-rwfs.sh Interesting. > In this way, you can get RO booted OS, just waited for you to login and > mount all required data. > > Also, you could contact Andriy Gapon, he managed to do other trick - boot > from RO media such as CD, and run all OS as chroot, all transparently. Thought about the chroot trick too but prefer to stay away from chroot if possible. > Hope this helps! With kind regards, Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 07:45:00 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36176445 for ; Wed, 20 Feb 2013 07:45:00 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gg0-x234.google.com (mail-gg0-x234.google.com [IPv6:2607:f8b0:4002:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id E97B586E for ; Wed, 20 Feb 2013 07:44:59 +0000 (UTC) Received: by mail-gg0-f180.google.com with SMTP id e5so965356ggk.11 for ; Tue, 19 Feb 2013 23:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:subject:references:from:content-transfer-encoding :content-type:x-mailer:message-id:date:cc:to:mime-version; bh=0KkeGh2h03BnSMXN8++bw5p2Te6hHkksgddaASTUCUw=; b=xZdmEMWS7pMVtBjYrkBp3yfWkF5Kt9Gb88JHqkWQFhCtnhOysRHxhTyo0yArUxbzuh 5xTKJIETkx/gyCUx6suDbJZ1+NaFt8KChLs9n7HyBQC53BxuQqZIuir4GbvBAvAo9VzQ OsPlKFI0hWMn10VtKZhWG8EQmbrO3DsBcD/m8h/zstGXwgjy4QKvVd1RmpeBfatKxTa8 sXNq1uYMQbniW/glDL3+bRDXklp2WzDCYWuz/MvtPmzSwytRlcBHex/ax1gJQFnpRsy1 RNQOR8UR01Xp/PEzrXPOgPHYAYnGNX1/N9dOKsVlETVxn5ztL93rzFbV7l26dk7ZS2jw vfzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=x-received:sender:subject:references:from:content-transfer-encoding :content-type:x-mailer:message-id:date:cc:to:mime-version; bh=0KkeGh2h03BnSMXN8++bw5p2Te6hHkksgddaASTUCUw=; b=bMHqVql+oP81hx2TO9PB+m6SzSVrl3btB0kCR4TmA/oKArMSK/FSg22ono2j6tJy7L 1TTO6oXZ63/9qJpRc73LwJD5nenF/SkNlDd9qNxlB1d8sb1LiKeI1k/57h2pI4S9iDaH 6S+JNx6l5+XRR9UT4qEe0Kqh/U+xzOCes8F1M= X-Received: by 10.236.128.42 with SMTP id e30mr35538524yhi.7.1361346298355; Tue, 19 Feb 2013 23:44:58 -0800 (PST) Received: from DataIX.net (24-231-147-188.dhcp.aldl.mi.charter.com. [24.231.147.188]) by mx.google.com with ESMTPS id t5sm6912619anl.22.2013.02.19.23.44.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 23:44:57 -0800 (PST) Sender: Jason Hellenthal Received: from [192.168.32.64] (wifall.wlan.DataIX.local [192.168.32.64]) (authenticated bits=0) by DataIX.net (8.14.6/8.14.6) with ESMTP id r1K7iprq008497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 02:44:55 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Subject: Fwd: Chicken and egg, encrypted root FS on remote server References: From: Jason Hellenthal X-Mailer: iPhone Mail (8C148) Message-Id: <204C42A2-6381-4601-BEE7-D2AB56822468@DataIX.net> Date: Wed, 20 Feb 2013 02:44:41 -0500 To: "hackers@freebsd.org" Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Paul Schenkeveld X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:45:00 -0000 Meant to also reply all... Reply elsewhere... --=20 Jason Hellenthal JJH48-ARIN - (2^(N-1)) Begin forwarded message: > From: Jason Hellenthal > Date: February 20, 2013 2:42:57 EST > To: Paul Schenkeveld > Subject: Re: Chicken and egg, encrypted root FS on remote server >=20 > Just a thought with no working example but=E2=80=A6 >=20 > bootp / tftp - from a remote secured management frame to TX a key filesyte= m to unlock your rootfs. >=20 > Could be something as simple as a remote wireless adhoc server with a 64GB= thumbdrive to hold your data or just enough to tell the system where to get= it. >=20 > Considering a key can be any length string of a sort just to say but... Se= rve the rootfs key directly from a TXT out of a secured DNS zone only visibl= e to so said machines.=20 >=20 > Just a thought. >=20 > --=20 > Jason Hellenthal > JJH48-ARIN > - (2^(N-1)) >=20 >=20 > On Feb 20, 2013, at 1:58, Paul Schenkeveld wrote: >=20 >> Hi, >>=20 >> I've been trying to find a solution for this chicken and egg problem, >> how to have an encrypted root filesystem on a remote server. >>=20 >> Geli can ask for a root password at the console to unlock the root fs >> but that of course won't work for a remote server. >>=20 >> Ideally I'd like the server to start, do minimal network config, run >> a minimal ssh client (dropbear?) and wait for someone to log in, >> provide the passphrase to unlock the root filesystem and then mount >> the root filesystem and do a normal startup. >>=20 >> I read about a pivotroot call in other OS-es, that would allow for a >> very small unencrypted root filesystem to be mounted temporarily until >> the passphrase has been entered and then swap that for a real, encrypted >> root filesystem. But AFAIK we don't have pivotroot. >>=20 >> The problem could also be solved if the real root fs could be union >> mounted over the small unencrypted one but unionfs won't mount over /. >>=20 >> I found out that a ZFS pool where a specific dataset has the >> mountpoint=3D/ option set can be used to 'buri' the unencrypted root unde= r >> the real root but that would render the unencrypted one unchangable >> after the real one is mounted (prohibiting sysadmin to change the ssh >> credentials or network config there). It would also make maintenance >> a bit more difficult because an import of the zpool would automatically >> remount /, even when running from a cd-rom or USB stick. And of course >> this approach would not work in non-zfs environments (like very small >> systems). >>=20 >> Looking at sys/kern/init_main.c and sys/kern/vfs_mount.c I could >> imagine having a kind of "pre root environment", an unencrypted root >> that gets mounted first (along with a devfs) and a /sbin/init that >> sets up minimal networking and runs sshd. Aftre that one dies the >> unencrypted root and devfs would be unmounted, the real root mounted >> and the real /sbin/init started. But this may be a considered a dirty >> approach. >>=20 >> Did I miss the obvious and easy solution? Any ideas? >>=20 >> With kind regards, >>=20 >> Paul Schenkeveld >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 07:47:02 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6EE2B55F for ; Wed, 20 Feb 2013 07:47:02 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 00A5D894 for ; Wed, 20 Feb 2013 07:47:01 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r1K7ktV5060121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 08:47:00 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r1K7kthX060120; Wed, 20 Feb 2013 08:46:55 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Wed, 20 Feb 2013 08:46:55 +0100 From: Paul Schenkeveld To: Jason Hellenthal Subject: Re: Chicken and egg, encrypted root FS on remote server Message-ID: <20130220074655.GA59952@psconsult.nl> References: <20130220065810.GA25027@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:47:02 -0000 On Wed, Feb 20, 2013 at 02:42:57AM -0500, Jason Hellenthal wrote: > Just a thought with no working example but… > > bootp / tftp - from a remote secured management frame to TX a key filesytem to unlock your rootfs. > > Could be something as simple as a remote wireless adhoc server with a 64GB thumbdrive to hold your data or just enough to tell the system where to get it. > > Considering a key can be any length string of a sort just to say but... Serve the rootfs key directly from a TXT out of a secured DNS zone only visible to so said machines. Thank you but manual entry of the passprase is a prerequisite here so serving the key automatically is not an option. With kind regards, Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 07:48:26 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E950764D for ; Wed, 20 Feb 2013 07:48:26 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 716E08A4 for ; Wed, 20 Feb 2013 07:48:26 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so6282556wgb.5 for ; Tue, 19 Feb 2013 23:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fHUgcWPr0Moz9nGM/yvTQ5rlajb/7gQ6teRgdr0K4Ew=; b=Qi60gwHS91OSZpVLoGvBQiCajzm9lBJAaF/tM6JljSeMQPJs2WTPjrMJzhtTDSlOtZ OJYijTOaeCKSSR0qIskffagqFVL5J4mqnqWOkqN0APak02qlFBORXgpYJTiZuVP77Rnu ePrvXY2NuVPIvj3TKEcFV93G4q2HjjNMIWK99xK0l4VSD7ca3nVj61foAPT35hfpBHH/ iBzrfcxLd9cVHiwBvAblinuWdeyFHPBD07m5TDefNvUv1PGv1gpVazq3br2R9jUamnDO VG0l71tTJZRycupfutKB4VNBEwvWhfgJYi4yASE56xn6jZnbgi1mYaaiZ7KZvpOK4OcD 3pPw== MIME-Version: 1.0 X-Received: by 10.194.172.197 with SMTP id be5mr31501281wjc.20.1361346505406; Tue, 19 Feb 2013 23:48:25 -0800 (PST) Received: by 10.194.85.116 with HTTP; Tue, 19 Feb 2013 23:48:25 -0800 (PST) Received: by 10.194.85.116 with HTTP; Tue, 19 Feb 2013 23:48:25 -0800 (PST) In-Reply-To: <20130220073930.GA59518@psconsult.nl> References: <20130220065810.GA25027@psconsult.nl> <20130220073930.GA59518@psconsult.nl> Date: Wed, 20 Feb 2013 09:48:25 +0200 Message-ID: Subject: Re: Chicken and egg, encrypted root FS on remote server From: Alexander Yerenkow To: Paul Schenkeveld Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:48:27 -0000 As you may notice, I go way readonly freebsd, the upgrade is simply replace disk A with disk B, and all stays working. In my home setup there's no Vm, but SD card with base system, also in RO mode. This setup succesfully survived two upgrade-by-replace. And you always can keep old Os as backup. Regards, Alexander Yerenkow From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 08:19:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7BCFFCA; Wed, 20 Feb 2013 08:19:37 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE8EA64; Wed, 20 Feb 2013 08:19:36 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r1K8JUGn094304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 09:19:35 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r1K8JUOk094303; Wed, 20 Feb 2013 09:19:30 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Wed, 20 Feb 2013 09:19:30 +0100 From: Paul Schenkeveld To: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Chicken and egg, encrypted root FS on remote server Message-ID: <20130220081930.GB59952@psconsult.nl> References: <20130220065810.GA25027@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130220065810.GA25027@psconsult.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 08:19:37 -0000 On Wed, Feb 20, 2013 at 07:58:10AM +0100, Paul Schenkeveld wrote: > Hi, > > I've been trying to find a solution for this chicken and egg problem, > how to have an encrypted root filesystem on a remote server. > > Geli can ask for a root password at the console to unlock the root fs > but that of course won't work for a remote server. > > Ideally I'd like the server to start, do minimal network config, run > a minimal ssh client (dropbear?) and wait for someone to log in, > provide the passphrase to unlock the root filesystem and then mount > the root filesystem and do a normal startup. > > I read about a pivotroot call in other OS-es, that would allow for a > very small unencrypted root filesystem to be mounted temporarily until > the passphrase has been entered and then swap that for a real, encrypted > root filesystem. But AFAIK we don't have pivotroot. > > The problem could also be solved if the real root fs could be union > mounted over the small unencrypted one but unionfs won't mount over /. Why is it that I cannot union mount anything over /, is there a technical reason for that or is it because of security concerns? From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 08:33:04 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7DD2441F for ; Wed, 20 Feb 2013 08:33:04 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 061A5B08 for ; Wed, 20 Feb 2013 08:33:03 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1K8WwaQ027121; Wed, 20 Feb 2013 09:32:58 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1K8Wwwh027118; Wed, 20 Feb 2013 09:32:58 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 20 Feb 2013 09:32:58 +0100 (CET) From: Wojciech Puchar To: Paul Schenkeveld Subject: Re: Chicken and egg, encrypted root FS on remote server In-Reply-To: <20130220065810.GA25027@psconsult.nl> Message-ID: References: <20130220065810.GA25027@psconsult.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 20 Feb 2013 09:32:58 +0100 (CET) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 08:33:04 -0000 > Geli can ask for a root password at the console to unlock the root fs > but that of course won't work for a remote server. > > Ideally I'd like the server to start, do minimal network config, run > a minimal ssh client (dropbear?) and wait for someone to log in, > provide the passphrase to unlock the root filesystem and then mount > the root filesystem and do a normal startup. > I read about a pivotroot call in other OS-es, that would allow for a too much complexity. just make simple small partition with OS installed, and just sshd and maybe few (not requiring security) things services running, then log in, geli attach main partition, fsck and mount and then run other services. make script for it. that's all From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 08:55:33 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 012F0A94 for ; Wed, 20 Feb 2013 08:55:33 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE4BD04 for ; Wed, 20 Feb 2013 08:55:32 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id d7so6312521wer.36 for ; Wed, 20 Feb 2013 00:55:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=bQRjlJOiSZYYg0yr+LiR9w9INYdCw8dD0WwKgPlNyXI=; b=OzMHqpCqYSvunqH6TsTpuYUoPzTI1del0dWWZgZO+McSS5NHA07fMG529GXJ6w3Myt hZexzKADOD+bcPFmM0zi0vzkUw44ek8x+dS0DTNYRIighXcgZKjxjlwUhMkPgCwXs7eS g8MOASyoEr2/itBqyi5SJ204IZcwRi4tX0OR40JbgunLcdCiEsQjvA7o59djTLYmnYwO XfNnoEvOs1TczOJMuTnmAWPQ+E0Ugn08dvH26bJsGp1veWTVqVfk0UyF2GIeNMfqfshk yvdMKtR7zdgTUp2K+m9sHgWQPbhJbx/zNrvAFr4xWNtaoTbz3Tx1z4awgg7BU2HkDJQl xAWA== X-Received: by 10.180.24.229 with SMTP id x5mr30871699wif.17.1361350066592; Wed, 20 Feb 2013 00:47:46 -0800 (PST) Received: from ?IPv6:2a01:e35:8a58:2600:9c:7ea9:f5cd:dd15? ([2a01:e35:8a58:2600:9c:7ea9:f5cd:dd15]) by mx.google.com with ESMTPS id ay10sm7014939wib.3.2013.02.20.00.47.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 00:47:45 -0800 (PST) References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> Mime-Version: 1.0 (1.0) In-Reply-To: <20130220074655.GA59952@psconsult.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: Chicken and egg, encrypted root FS on remote server Date: Wed, 20 Feb 2013 09:47:36 +0100 To: Paul Schenkeveld X-Gm-Message-State: ALoCoQkGqdke/dEApTwAZhK13qQIkxd0IrEQz0kNur1S+8bI85tkwZwhjNm2zhyX1IRBuwqqOpVK Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 08:55:33 -0000 On 20 Feb 2013, at 08:46, Paul Schenkeveld wrote: > On Wed, Feb 20, 2013 at 02:42:57AM -0500, Jason Hellenthal wrote: >> Just a thought with no working example but=E2=80=A6 >>=20 >> bootp / tftp - from a remote secured management frame to TX a key filesyt= em to unlock your rootfs. >>=20 >> Could be something as simple as a remote wireless adhoc server with a 64G= B thumbdrive to hold your data or just enough to tell the system where to ge= t it. >>=20 >> Considering a key can be any length string of a sort just to say but... S= erve the rootfs key directly from a TXT out of a secured DNS zone only visib= le to so said machines. >=20 > Thank you but manual entry of the passprase is a prerequisite here so > serving the key automatically is not an option. >=20 > With kind regards, >=20 > Paul Schenkeveld >=20 What about getting a remote console like HP's ILO or Dell's DRAC ? You get to login remotely, you can use some degree of access control... you c= an even remote boot.= From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 10:48:09 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA4C664B for ; Wed, 20 Feb 2013 10:48:09 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by mx1.freebsd.org (Postfix) with ESMTP id 768C662F for ; Wed, 20 Feb 2013 10:48:09 +0000 (UTC) Received: by mail-bk0-f46.google.com with SMTP id j5so3579560bkw.19 for ; Wed, 20 Feb 2013 02:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=aVHxmGbSJx6aGNTsL4JmUJm457MoRCtuT0QlrruwySE=; b=qWbU9cD9UuHp5OLy/LhUl4AQrujt0+2qrvlkqdJR1qY5vxlGmwSCVtEUtBJgnjt4Zq gP2xyMkMWxiBJy4IfwHqN5OnUAijfMRffO8B6u9iSjMLRxJ9wjb8eCE7wcXy2gdpgj0z yKXhGXT7J1V8JQ1EZkEPwrfNG56HeDS4i//fy/dPpt5Y2WuZgd/jpf3/BrWZKGSlkLGv VNEsQZUt7E7/vZFBPap1pZsaSA45uhly4UqEUn8EfXlM3cfCpeA+kL5EtfS+nb+Yqp1o RQxbF3wJi3d/K6ACZqhNyQT1jiF7zM/S99Byylfu0vo7VQDyr8uuajDVCNlW4aB/1JwA kPAg== X-Received: by 10.204.8.71 with SMTP id g7mr8155905bkg.118.1361357288396; Wed, 20 Feb 2013 02:48:08 -0800 (PST) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPS id z6sm4634710bkv.11.2013.02.20.02.48.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Feb 2013 02:48:07 -0800 (PST) Message-ID: <20130220.104806.647.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: gpart autofill Date: Wed, 20 Feb 2013 11:48:06 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 10:48:09 -0000 On target provider I had 20971440 free sectors, each of 512 B.=0D=0AThat = would be 10485720 kB, for a last slice.=0D=0A=0D=0AThis number is valid, = as it is splitable with 63, 8, 4 and 2, without any = residue.=0D=0A=0D=0ASo, upon attempt to add that slice, I = get:=0D=0A--=0D=0Agpart: autofill: No space left on device = =0D=0A--=0D=0A=0D=0ATried both '-s 10485720k' and '-s = 20971440'=0D=0AFinally, ommiting -s flag, just to see what gpart wants to = do, worked.=0D=0AIt added slice by leaving last 63 sectors = free.=0D=0A=0D=0AThose were supposed to be a part of a = slice.=0D=0A=0D=0AI.e; If provider had 20971455 free sectors, then slice = would be 20971440 of sector size and last 15 sectors would be left = free.=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 11:13:46 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0E162E2 for ; Wed, 20 Feb 2013 11:13:46 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB78806 for ; Wed, 20 Feb 2013 11:13:46 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r1KBDeUK099683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 12:13:45 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r1KBDefw099682; Wed, 20 Feb 2013 12:13:40 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Wed, 20 Feb 2013 12:13:39 +0100 From: Paul Schenkeveld To: Damien Fleuriot Subject: Re: Chicken and egg, encrypted root FS on remote server Message-ID: <20130220111339.GA65661@psconsult.nl> References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 11:13:46 -0000 On Wed, Feb 20, 2013 at 09:47:36AM +0100, Damien Fleuriot wrote: > > On 20 Feb 2013, at 08:46, Paul Schenkeveld wrote: > > > On Wed, Feb 20, 2013 at 02:42:57AM -0500, Jason Hellenthal wrote: > >> Just a thought with no working example but… > >> > >> bootp / tftp - from a remote secured management frame to TX a key filesytem to unlock your rootfs. > >> > >> Could be something as simple as a remote wireless adhoc server with a 64GB thumbdrive to hold your data or just enough to tell the system where to get it. > >> > >> Considering a key can be any length string of a sort just to say but... Serve the rootfs key directly from a TXT out of a secured DNS zone only visible to so said machines. > > > > Thank you but manual entry of the passprase is a prerequisite here so > > serving the key automatically is not an option. > > > > With kind regards, > > > > Paul Schenkeveld > > > > What about getting a remote console like HP's ILO or Dell's DRAC ? > > You get to login remotely, you can use some degree of access control... you can even remote boot. For new hardware I could indeed use this, the current hardware does not support remote console. I don't have experience with ILO nor DRAC but I do have experience with SuperMicro's KVM over LAN which does need a java client to run. If I can enter the passphrase over ssh that would be better as I can use any device including a smartphone to dial in and enter the passphrase. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 12:26:08 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 56B1C5DC for ; Wed, 20 Feb 2013 12:26:08 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id BD657DD9 for ; Wed, 20 Feb 2013 12:26:07 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-241-76.lns20.adl6.internode.on.net [118.210.241.76]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r1KCPL0h062123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 22:55:48 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Chicken and egg, encrypted root FS on remote server Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <20130220111339.GA65661@psconsult.nl> Date: Wed, 20 Feb 2013 22:55:47 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <8C2980B2-3B2C-4081-9287-39EFB47ABC3D@gsoft.com.au> References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> <20130220111339.GA65661@psconsult.nl> To: Paul Schenkeveld X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 12:26:08 -0000 On 20/02/2013, at 21:43, Paul Schenkeveld wrote: >> What about getting a remote console like HP's ILO or Dell's DRAC ? >>=20 >> You get to login remotely, you can use some degree of access = control... you can even remote boot. >=20 > For new hardware I could indeed use this, the current hardware does = not > support remote console. >=20 > I don't have experience with ILO nor DRAC but I do have experience = with > SuperMicro's KVM over LAN which does need a java client to run. If I = can > enter the passphrase over ssh that would be better as I can use any = device > including a smartphone to dial in and enter the passphrase. If you setup a serial console you don't need Java if you use ipmitool, = eg ipmitool -H remoteip -U ADMIN -I lanplus sol activate The way IPMI graphical console stuff _stinks_ - I spent several hours = trying to help a customer and I was stymied at every level trying to = work out how to use SSH port forwarding to have the console Java client = connect to the remote server (for example, it ignores system wide SOCKS = proxy settings). In the end I used tun forwarding which was just stupid - it really is = written assuming everyone uses a VPN. There is no logic behind the use = of the VNC protocol but bastardised enough that normal clients can = connect. That inspired me to send a longer rant to Supermicro about it, maybe = nothing will come of it but I feel better ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 15:29:31 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 229CE4F5; Wed, 20 Feb 2013 15:29:31 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5D8B09; Wed, 20 Feb 2013 15:29:30 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gw10so7837897lab.27 for ; Wed, 20 Feb 2013 07:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=kO0eY0Gk6ar4U8aOuGdt2/NWOuuIQgHW/sX9L6XU9xI=; b=BkTreC7J+0e38JhQKY/g7QBahmXwIq9ODUztvXRAHF75zn27sicncRrUtnZXH1yG1D gO1KEjEe1c4rlDxub0agfI6AS19ocxWbZLb5RVP0PfAbIqpUp2cUCjemY9M64INUD/2f Q41lR0sGHStpkCtQD4w81WNPxvjwZEt7gpNIhal5+RTPg2eG16c+zD05idobvNJnxsL4 9TLeS3f4a2JZHCNVB/OQUOUwLFt1ZE4UUqa+XENdBugvA/TsnAKGRHkzMiaI+p4NBk3d qceEV9sf7uwdvSLwyZP62aQQcirxGGiS964likqXbQO7Xq0sV5TXYChp7EMH5UYN+ngF APPA== X-Received: by 10.152.104.80 with SMTP id gc16mr18087997lab.49.1361374161894; Wed, 20 Feb 2013 07:29:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.20.138 with HTTP; Wed, 20 Feb 2013 07:29:01 -0800 (PST) From: Damjan Jovanovic Date: Wed, 20 Feb 2013 17:29:01 +0200 Message-ID: Subject: [patch] Wine DLL base address patches To: freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org, tijl@coosemans.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:29:31 -0000 Hi Wine needs some of its libraries to be loaded at specific base addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently lacks. I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that loads libraries at their preferred base addresses (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port of Prelink to FreeBSD which Wine uses to set base addresses (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-), the changed dynamic loader doesn't show any problems in a few days of testing, and prelink works with the --reloc-only option as used by Wine. Please review/test/comment/commit. Thank you Damjan Jovanovic From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 15:49:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 740E2B7; Wed, 20 Feb 2013 15:49:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 17050D75; Wed, 20 Feb 2013 15:49:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1KFmui7070158; Wed, 20 Feb 2013 17:48:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1KFmui7070158 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1KFmtgP070157; Wed, 20 Feb 2013 17:48:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Feb 2013 17:48:55 +0200 From: Konstantin Belousov To: Damjan Jovanovic Subject: Re: [patch] Wine DLL base address patches Message-ID: <20130220154855.GF2598@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L2zmpNdaDxUzilj2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, tijl@coosemans.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:49:08 -0000 --L2zmpNdaDxUzilj2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: > Hi >=20 > Wine needs some of its libraries to be loaded at specific base > addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently > lacks. >=20 > I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that > loads libraries at their preferred base addresses > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176216), as well as a port > of Prelink to FreeBSD which Wine uses to set base addresses > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176283). Both work :-), > the changed dynamic loader doesn't show any problems in a few days of > testing, and prelink works with the --reloc-only option as used by > Wine. >=20 > Please review/test/comment/commit. Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings which could exist at the specified address. What you could do, is - either specify the desired base without MAP_FIXED. Kernel takes the base as the hint, but only uses it if the request completely fits into the hinted area without overriding any existing mapping. Also, the heap is explicitely avoided. The code would need to check if kernel honored hint by comparing the actual map address with the desired address, and act accordingly. - or add a new mmap(2) flag, which would specify that mapping should be done at that address, if possible to not overlap with existing mapping, otherwise the mapping should fail. --L2zmpNdaDxUzilj2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJPBnAAoJEJDCuSvBvK1B6RgP/14vXBpPuyAVre0mJ3Dh3TMl zYVmheN9j5Un2a0LTq1U9UcD6FADWwY0G+0J2eSZHVSFOXA3YFxHq73+H9XNawOF U+AHH0+4qQ/27jTJjr4vThjfiFuvN0ArkUrj+haAPMZlhQdr0y1FZl7stuyLo+gb YYkYnZOu/tqvvT5MHVPNjgl9vWMANGcm41BzrGRK40NZ24kOhXwr5I1h5uCGFR7/ gxD5SUtKHVhT1ZF5pMVvObOcTAQrz/nlb6gI2sxhpdU7AnOLpCCGm0+ThNI3tmA8 fmqGze92fU0TFdAWMootevLVuOwgfZwlyUno++RG56zdtFJHBsHCCqvMlsywcRHD 4U15XSmFFDU5+WA4xjbPou/JVOQBUnyRQ6oYYQR8sdt7/tF77pYSvVcR9/V+eujU cI/Zma512iwIW6uwHh9bI1dC1Os3Zqi+OBMelXFdF6zLqZfaMVtygS+E6comvj6j 7EvkzhGNJbByD8+3BD1huHPC7dP0E7f7sYIFLK72WQNLGm68RNl55IjB5EuhcBXP nzgyMyCKCr8XhtB5Kzzwjs9rAVS14WljX00+WJUH4JhF24ddPs/huLDzM9wAb554 zDMTvicHFZSjG+uX7F9/3cgzm6X6Wbw1f5Tnip46FVkUyMfWs+7lq6uUn18oaR3w GHjLcqV1zuKbcFyUUvuY =j2JC -----END PGP SIGNATURE----- --L2zmpNdaDxUzilj2-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 15:49:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A95E21D3; Wed, 20 Feb 2013 15:49:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4553DD7D; Wed, 20 Feb 2013 15:49:14 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9B02FB9B9; Wed, 20 Feb 2013 10:49:13 -0500 (EST) From: John Baldwin To: "Steven Hartland" Subject: Re: Looking for reviewers for patch that adds foreign disk support mfiutil Date: Wed, 20 Feb 2013 08:40:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <49693195BAD841469129EE4B7523CABE@multiplay.co.uk> <201302191346.33415.jhb@freebsd.org> <70A4A7995FBD430EA37B56C0C8B32B34@multiplay.co.uk> In-Reply-To: <70A4A7995FBD430EA37B56C0C8B32B34@multiplay.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302200840.32641.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Feb 2013 10:49:13 -0500 (EST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:49:14 -0000 On Tuesday, February 19, 2013 6:49:52 pm Steven Hartland wrote: > ----- Original Message ----- > From: "John Baldwin" > > Thanks for the feedback John appreciated, a couple of questions inline > below if you would be so kind. Certainly. > > - Is dump_config() really the right choice for 'foreign config'? It doesn't > > attempt to output things very pretty, and I think mfiutil's non-debug > > commands should aim to be human readable. > > Will check this, just didn't want to re-invent the wheel ;-) Heh, can you reuse the show_config code instead perhaps? It might be useful if you could provide an example of the current 'foreign config' output? > > - This (human readable) is also why it doesn't include the opcode in the error > > message by default. Sysadmins don't really care which opcode fails. Maybe > > put that under '#ifdef DEBUG'? > > Previously there was no information about what command failed, which made > the failure message kinda useless, so while debugging I added the opcode > to help me trace things. In general my goal had been to make the caller provide that level of detail if it is useful. While developing a command it can indeed be useful which is why I suggested moving it under #ifdef DEBUG. This provides the extra detail while working on a command while keeping the UI for users clean. If it is under DEBUG you can just print the raw opcode in hex as you are doing now. > > - mfireg.h should be kept in sync with the driver's version of that header, so > > don't reorder the enum's unless you are changing it to match what is in the > > device driver's mfireg.h. In fact, mfiutil should probably be using the > > mfireg.h from sys/dev/mfi directly now that it is in the tree. (mfiutil > > was originally developed outside of the tree as a standalone app) > > There is only one mfireg.h and that is already in sys/dev/mfi :) Oh, bah. I misread the diff. Reordering the commands looks good to me in that case. > > - Please don't do assignments in declarations and leave a blank line between > > declarations and the bode of code. Thus: > > > > mfi_op_desc(...) > > { > > int i, num_ops; > > > > num_ops = nitems(mfi_op_codes); > > ... > > > > (nitems() is nice to use when it is available as well) > > Changed, this the case for constant initialisers too? e.g. is the > following incorrect or acceptable? > myfunc(...) > { > int i = 0, j = 1; > ... style(9) forbids those as well (and I generally avoid them myself), but you will find code in the tree that does use initializers for simple expressions. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 15:49:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0EDC1222; Wed, 20 Feb 2013 15:49:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AFB1AD80; Wed, 20 Feb 2013 15:49:16 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 08955B98D; Wed, 20 Feb 2013 10:49:16 -0500 (EST) From: John Baldwin To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Date: Wed, 20 Feb 2013 09:04:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130119151253.GB88025@gmail.com> <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> In-Reply-To: <20130212215054.GA9839@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302200904.15324.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Feb 2013 10:49:16 -0500 (EST) Cc: Stanislav Sedov , Kostik Belousov , "Robert N. M. Watson" , Attilio Rao , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:49:17 -0000 On Tuesday, February 12, 2013 4:50:54 pm Mikolaj Golub wrote: > On Fri, Jan 25, 2013 at 03:31:43PM -0500, John Baldwin wrote: > > > BTW, one off-ball thought I have is that I would like to have a mode where > > libprocstat operates on a core file (of a process, not a kernel crash dump), > > so it could list the threads from a core dump, and possibly file descriptor > > info (if PR kern/173723 is implemented). > > > > We certainly could have a 'raw' mode where it spat out name: value or XML > > of the entire kinfo_proc perhaps. > > > > It looks very interesting! Do you mean something like this? Yes, exactly like this! Very nice indeed. > root@lisa:/root # sh -c 'kill -5 $$' > Trace/BPT trap (core dumped) > root@lisa:/root # ls -l sh.core > -rw------- 1 root wheel 8790016 Feb 12 21:17 sh.core > root@lisa:/root # procstat sh.core > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > 674 657 674 657 657 1 root - FreeBSD ELF32 sh > root@lisa:/root # procstat -f sh.core > PID COMM FD T V FLAGS REF OFFSET PRO NAME > 674 sh text v r r-------- - - - /bin/sh > 674 sh ctty v c rw------- - - - /dev/pts/0 > 674 sh cwd v d r-------- - - - /root > 674 sh root v d r-------- - - - / > 674 sh 0 v c rw------- 8 2537 - /dev/pts/0 > 674 sh 1 v c rw------- 8 2537 - /dev/pts/0 > 674 sh 2 v c rw------- 8 2537 - /dev/pts/0 > root@lisa:/root # procstat -v sh.core > PID START END PRT RES PRES REF SHD FL TP PATH > 674 0x8048000 0x8064000 r-x 28 0 1 0 CN-- vn /bin/sh > 674 0x8064000 0x8066000 rw- 2 0 1 0 ---- df > 674 0x28064000 0x2807a000 r-x 22 0 17 0 CN-- vn /libexec/ld-elf.so.1 > 674 0x2807a000 0x28083000 rw- 9 0 1 0 ---- df > 674 0x28084000 0x280a3000 r-x 31 32 2 1 CN-- vn /lib/libedit.so.7 > 674 0x280a3000 0x280a5000 rw- 2 0 1 0 C--- vn /lib/libedit.so.7 > 674 0x280a5000 0x280a7000 rw- 0 0 0 0 ---- -- > 674 0x280a7000 0x280e0000 r-x 57 0 4 2 CN-- vn /lib/libncurses.so.8 > 674 0x280e0000 0x280e3000 rw- 3 0 1 0 C--- vn /lib/libncurses.so.8 > 674 0x280e3000 0x28213000 r-x 304 0 34 17 CN-- vn /lib/libc.so.7 > 674 0x28213000 0x2821a000 rw- 7 0 1 0 C--- vn /lib/libc.so.7 > 674 0x2821a000 0x28243000 rw- 16 0 2 0 ---- df > 674 0x28400000 0x28c00000 rw- 24 0 2 0 ---- df > 674 0xbfbdf000 0xbfbff000 rwx 3 0 1 0 ---D df > 674 0xbfbff000 0xbfc00000 r-x 0 0 20 0 CN-- ph > > Here is my attempt to implement it: > > http://people.freebsd.org/~trociny/procstat_core.1.patch > > The patch needs much work yet, especially the userland part, but looks > like it is good enough for demonstration purposes to discuss how this > should be done properly. > > So, procstat data is stored in a core as note sections with name > "FreeBSD" and types NT_PROCSTAT_PROC, NT_PROCSTAT_FILES, ... > > The current format of notes is a header of sizeof(int) and data in the > format as it is returned by a related sysctl call. I think the > header should provide some versioning and for the cases I implemented > (kinfo_proc, kinfo_file, kinfo_vmentry) it contains a value of the > corresponding kinfo struct size (e.g. KINFO_VMENTRY_SIZE). It might be > not the best solution and I would be glad for suggestions. I think including the size is good and is probably sufficient for versioning. > (BTW, why don't we have constants like KINFO_VMENTRY_SIZE defined for > all archs?) I cannot speak to that. > To avoid code duplication I changed the code of kinfo sysctl handlers > to output kinfo data to sbuf instead of calling SYSCTL_OUT directly so > these functions could be used by both sysctl handlers and the coredump > routine. Ok. > Another thing I am not sure about is writing procstat data in the > coredump routine. The coredump routine on the first pass calculates > core sizes and on the second pass does actual writing. I added > procstat in that way that procstat data is collected on the first run > to internal buffers and on the second pass is copied from the buffers > to the core. I could do this another way, e.g running kern_proc_*out() > twice, on the fist pass with tiny buffer and a drain routine that > would calculate data length, but this looks less efficient, > complicates things and currently I am not sure that procstat sizes are > not changeable between the passes. The issue with my approach I see is > that after the first pass, before actually doing allocations we check > corefile limits. I do allocations before checking the limit, so > potentially using some kernel space when it might not be allowed by > limits. Is this a problem I should worry and try another approach? The process should be stopped by the time we dump a core, so running it multiple times should be ok in that the sizes should not change. I would say that you should try to implement a "determine sizes" pass that doesn't allocate anything, but others should comment on that. > I do nothing yet for freebsd32 compat case. I suppose I should check > if the dumping process is running 32 binary and store procstat data in > freebsd32 format? Hmmmmm, that would allow you to use a 32-bit procstat to examine it, but then you'd also need to extend libprocstat to support 32-bit structures so that the native 64-bit procstat can still examine the structures. Also, this information is nice to have for Linux binaries as well. I'm not sure it is worth doing this since usually you want to examine a core dump on the machine that generated the core (that has all the same libraries, etc.). > As I said there is much to do in userland, and I would like to > concentrate on the kernel part and the format first, but I would be > glad if somebody helps me with the problem I faced linking libelf to > libprocstat. With the modifications to the libprocstat makefile: > > -DPADD= ${LIBKVM} ${LIBUTIL} > -LDADD= -lkvm -lutil > +DPADD= ${LIBELF} ${LIBKVM} ${LIBUTIL} > +LDADD= -lelf -lkvm -lutil > > buildworld fails with the error: > > make: don't know how to make /scratch2/tmp/trociny/obj/i386.i386/home/trociny/svn/base/head/tmp/usr/lib/libelf.a. Stop This I have no idea on. One other thing to consider is if gcore needs to be updated to output these records as well. It could use the sysctls to fetch the data and then write out appropriate notes I think, so perhaps it wouldn't be too difficult to add this as a followup commit once the kernel version has settled and the file format is set? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 17:29:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C2D9C828 for ; Wed, 20 Feb 2013 17:29:10 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-we0-x232.google.com (we-in-x0232.1e100.net [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 63D563CF for ; Wed, 20 Feb 2013 17:29:10 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id x48so6806966wey.37 for ; Wed, 20 Feb 2013 09:29:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=P3DadbY/cd/9e/48FxCxjr0awFf4755iBgBhJw5toRM=; b=h3JQYwrHGZsmnCKRuZlSxviOrOzVQQFv+tIt5cSR6ylF3qmmO0s/TA8Qy3RtNah/pH VR8jRiiWcBeSHXJmA5hXX7qKlcv4Twd0+mYWpjTs7Q/MnZ7hzpi0ViTwkOC6TSjCFvlM Hx2Wv6jpfS69A9UVlfTexbcX5rlbyk/sbs3ByOXCPtmwWkhTi+aV0GyghG8rj0UJjiyv gQ/71yui18kSJrR8k0ePx4Kx13L7PGgr4wOYZ5MFXiA4iFapD9p8JmJbLZrrbkc6TEE3 yb898MoJ14MdoR+Cq1brPYh0ff15ccg9vsKI2+keDrfGQNiOf/9KMJVZQkQJ31yG0s1w P7Xw== MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr36257458wiz.6.1361381349284; Wed, 20 Feb 2013 09:29:09 -0800 (PST) Received: by 10.216.105.1 with HTTP; Wed, 20 Feb 2013 09:29:09 -0800 (PST) X-Originating-IP: [216.223.13.196] Date: Wed, 20 Feb 2013 12:29:09 -0500 Message-ID: Subject: SA-13:02/libc and FreeBSD 6 From: Mark Saad To: "freebsd-hackers@freebsd.org" X-Gm-Message-State: ALoCoQl5HKFR9mPRl88R3RjNzshAPYWoKc6xRmBbEMKXxGSQufoNrSJQkQzmZWoVzDoOotQf3EOZ Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:29:10 -0000 All I was wondering if anyone knows, off hand if SA-13:02/libc applies to FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ? -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 17:31:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0030AAC for ; Wed, 20 Feb 2013 17:31:24 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 46BDD619 for ; Wed, 20 Feb 2013 17:31:23 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hi8so6487000wib.13 for ; Wed, 20 Feb 2013 09:31:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ChVoME+C/sPrpBMDH7GvVxJKvMH64AaZoGnkjOWMC0o=; b=XWRSo/HgTt/BB+OfMJaXc2GmW4CSDIlWBA1aUCaNfM+swt58ZgMppVkF+uLaAXlr5z JeSBWZ6uvyWbusBXwt1GoOn63qJQXcwkgPqSJb0iXbz+0Kf8i1TQe0NSsa3HqA68Y6VC Uh+a3xUOtwS8CkP8jmr8+seY6qlEgj13V33+VLincK8w4zqZzdNSZYga7ld9DtsiH5yx M/UjYXC/9mWjNRS4YFchESIiKKSjAwmm5PIn1LNkwoke8Wp3Hxk/gM68CfdKlDF7zw+p zG3vXZIgG6lq9uuZWAwvitfQ+EB38EbpFLfqEQozbuuCBHrTViOqB/A8NJmV72XkRJsK U67A== X-Received: by 10.194.5.196 with SMTP id u4mr30539568wju.47.1361381476881; Wed, 20 Feb 2013 09:31:16 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id fg6sm35194490wib.10.2013.02.20.09.31.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 09:31:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: SA-13:02/libc and FreeBSD 6 From: Fleuriot Damien In-Reply-To: Date: Wed, 20 Feb 2013 18:31:14 +0100 Content-Transfer-Encoding: 7bit Message-Id: <8C59311F-0E2B-4803-9277-1FE753615BCB@my.gd> References: To: Mark Saad X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkdJI3j46iiY+qsdnvfPENzrWvi/64TIVUNPza3ro7M50memDXuVjS0bl5SBRbv257dMooi Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:31:24 -0000 http://www.freebsd.org/security/#sup 6 has been EOL for a looong time. So hmmm, guessing you won't see a patch. On Feb 20, 2013, at 6:29 PM, Mark Saad wrote: > All > I was wondering if anyone knows, off hand if SA-13:02/libc applies to > FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ? > > -- > mark saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 17:32:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF1FBC94 for ; Wed, 20 Feb 2013 17:32:59 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7D8647 for ; Wed, 20 Feb 2013 17:32:59 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi8so6544151wib.1 for ; Wed, 20 Feb 2013 09:32:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=/FhM6BPRz0A/gfplIVFrh1eBhHUr5vOFBL8IT1Dw8Wo=; b=Oiqe4S2ztwGy2gaC7HYB3SXUrXugv/k4dWI8SrM6qmb0FxZjzWs7b+GzwX7HC/qpJY CxBG4qbMb7tROeMmK6+K/XvR7Zbkg19yeHw3T6YZystywVdviul3zqAEbxaFUDmlncuU UicA7xwbZ2SPnodnLkT6wNoClkozkbktj+tpYbiQhZEb7fW2YAGeVUQSYn46kNmKiCvO WfV4fSQRrBluwcXO5Ai2S0hJCLOIQPxEPpRG8qAwoCeeG8fYGeDb4IQKND4xHdDYDe4J 9aiAGRSr2hIIK1wa5HwW3gPqK68THdBqXxoLx9WksuX0vF78BngVC9VioQj/CHEOHGZl R9/Q== MIME-Version: 1.0 X-Received: by 10.194.77.129 with SMTP id s1mr35709707wjw.17.1361381578136; Wed, 20 Feb 2013 09:32:58 -0800 (PST) Received: by 10.216.105.1 with HTTP; Wed, 20 Feb 2013 09:32:57 -0800 (PST) X-Originating-IP: [216.223.13.196] In-Reply-To: <8C59311F-0E2B-4803-9277-1FE753615BCB@my.gd> References: <8C59311F-0E2B-4803-9277-1FE753615BCB@my.gd> Date: Wed, 20 Feb 2013 12:32:57 -0500 Message-ID: Subject: Re: SA-13:02/libc and FreeBSD 6 From: Mark Saad To: "freebsd-hackers@freebsd.org" X-Gm-Message-State: ALoCoQnVBJRh9lk1W93YzgcPClnoAJxHIn3eg2vu7uP1i63jXAX27BYW8W2GJMN9bss+lHUMlgYp Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:32:59 -0000 I am aware its EOL'd but there are still a number of us stuck with 6-STABLE . On Wed, Feb 20, 2013 at 12:31 PM, Fleuriot Damien wrote: > http://www.freebsd.org/security/#sup > > 6 has been EOL for a looong time. > > So hmmm, guessing you won't see a patch. > > > > On Feb 20, 2013, at 6:29 PM, Mark Saad wrote: > > > All > > I was wondering if anyone knows, off hand if SA-13:02/libc applies to > > FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ? > > > > -- > > mark saad | nonesuch@longcount.org > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 17:36:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4292FF4F for ; Wed, 20 Feb 2013 17:36:37 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id D3E74698 for ; Wed, 20 Feb 2013 17:36:36 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id p43so4951567wea.38 for ; Wed, 20 Feb 2013 09:36:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=HNPOHzjL7l4A0sEVKU+Zwzd5NR+y4cQAm7G16C+mlEo=; b=iW3MQoug/yBnnLXILysjs/Z0ZDkamaFES8Yby9rDkqfrFfsmhk3Zgrke+0+L6WIxAW E3DTUZ39lzM5+fxqL0TVBQE5M1JxRVf5f/auChWevjtvjr6UcjO9NyoDVDIXZe2a1SVS 4lleImGszL7fpCsgStOEypsk/rtfeHazP07X+Fm78P/Iuh3ZNfSA+k9LdACaonVn/cIP gMj2uWDerkSM8ftdRn/JwrOoZ8z9mXxBd95XrO38ciivm6O8/x8n0G8fTs9z+/Fnf6Qa X51jugm2OEeASNEmtwrsoMEdhTxSnWc0iDoIWl0s3VbfZ1Jrz9B7Jf6d5eOfQOERjrXx OjsQ== X-Received: by 10.180.83.227 with SMTP id t3mr34437636wiy.2.1361381795786; Wed, 20 Feb 2013 09:36:35 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id du2sm32507853wib.0.2013.02.20.09.36.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 09:36:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: SA-13:02/libc and FreeBSD 6 From: Fleuriot Damien In-Reply-To: Date: Wed, 20 Feb 2013 18:36:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C59311F-0E2B-4803-9277-1FE753615BCB@my.gd> To: Mark Saad X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlvUbaVv/P14Ik4CpSTSll4wgr5Osk62Rj131MxkdiZKLjl8HlWba/G0g1FdP0/WkMzkRKZ Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:36:37 -0000 My point was, unless someone ports the patch back to 6 , if 6 is indeed = affected, I think you're out of luck. I hope you get your answer and, possibly, a patch. On Feb 20, 2013, at 6:32 PM, Mark Saad wrote: > I am aware its EOL'd but there are still a number of us stuck with = 6-STABLE > . >=20 >=20 > On Wed, Feb 20, 2013 at 12:31 PM, Fleuriot Damien wrote: >=20 >> http://www.freebsd.org/security/#sup >>=20 >> 6 has been EOL for a looong time. >>=20 >> So hmmm, guessing you won't see a patch. >>=20 >>=20 >>=20 >> On Feb 20, 2013, at 6:29 PM, Mark Saad = wrote: >>=20 >>> All >>> I was wondering if anyone knows, off hand if SA-13:02/libc applies = to >>> FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch = ? >>>=20 >>> -- >>> mark saad | nonesuch@longcount.org >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >>=20 >>=20 >=20 >=20 > --=20 > mark saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 18:32:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77E07661 for ; Wed, 20 Feb 2013 18:32:08 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 59D0AA5D for ; Wed, 20 Feb 2013 18:32:08 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 8F53D24E74; Wed, 20 Feb 2013 10:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361385127; bh=OBmXq8brMjLQuOXwdLc4whskgcFF86Xl0ECUcDARy4c=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=XOOYRlR4LITNcUFK0KEs69c6bqQ1zhxjH5EdPb1HXfprqo/jznJmZ7dpW2Q/vH2uB 4q4BY/NYjP7X0QgvWAFt5uT8da3gvaSc7AHrNAzA4z4irO5Awv9rb4YTJUGBDRBsc/ sSHabmkoewDEdDOqm+QOhbweyBr4nOqf8mcp/EQg= Message-ID: <512516A7.2060604@delphij.net> Date: Wed, 20 Feb 2013 10:32:07 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Mark Saad Subject: Re: SA-13:02/libc and FreeBSD 6 References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------020403030703040107090209" Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:32:08 -0000 This is a multi-part message in MIME format. --------------020403030703040107090209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/20/13 09:29, Mark Saad wrote: > All I was wondering if anyone knows, off hand if SA-13:02/libc > applies to FreeBSD 6-STABLE and if it would be committed to the > 6-STABLE branch ? The patch itself won't apply, there were many changes after the last 6-STABLE branch. Here is a patch backported for stable/6 but I do not have time to set up a testing environment for it, if you do, please let me know if the patch worked or not, thanks! Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRJRanAAoJEG80Jeu8UPuzyf0H/AyoNHoCSoXxTRl4tu0NOFsR lZ/5O7h+YMK6LejwQxEfbb9vnNkRYmP5FtM4Ja7cQjqvFM24tL4RXtoazdYQcgid /X+ExMIghF+/5fbEDt8x03lKQB8G5Ua3HTIqQfZoM5LREdzlXsyxREep4VspgT+y GTofcvwReT7LJZyYqeYmLq+tJLOy/gWkl95MJPz/0E58+H/xqCwTEol8vDhUqTYh WuBfRzNpY2OLnc5RStKZ+Vj+vkNIFHeHrOmwcYby+MGYl8V89pb+MjKP/mEITxcv 8NF8Ti52yY8ZtG7aS8tvAoY6qeAqWknv1yiHg+IZrgvtkXSBefExUSCAzS2z1G8= =m/h0 -----END PGP SIGNATURE----- --------------020403030703040107090209 Content-Type: text/plain; charset=UTF-8; name="SA-13:02-stable-6.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="SA-13:02-stable-6.diff" diff --git a/lib/libc/gen/glob.c b/lib/libc/gen/glob.c index 8e5ee69..5549311 100644 --- a/lib/libc/gen/glob.c +++ b/lib/libc/gen/glob.c @@ -93,6 +93,25 @@ __FBSDID("$FreeBSD$"); #include "collate.h" +/* + * glob(3) expansion limits. Stop the expansion if any of these limits + * is reached. This caps the runtime in the face of DoS attacks. See + * also CVE-2010-2632 + */ +#define GLOB_LIMIT_BRACE 128 /* number of brace calls */ +#define GLOB_LIMIT_PATH 65536 /* number of path elements */ +#define GLOB_LIMIT_READDIR 16384 /* number of readdirs */ +#define GLOB_LIMIT_STAT 1024 /* number of stat system calls */ +#define GLOB_LIMIT_STRING ARG_MAX /* maximum total size for paths */ + +struct glob_limit { + size_t l_brace_cnt; + size_t l_path_lim; + size_t l_readdir_cnt; + size_t l_stat_cnt; + size_t l_string_cnt; +}; + #define DOLLAR '$' #define DOT '.' #define EOS '\0' @@ -144,7 +163,7 @@ typedef char Char; static int compare(const void *, const void *); -static int g_Ctoc(const Char *, char *, u_int); +static int g_Ctoc(const Char *, char *, size_t); static int g_lstat(Char *, struct stat *, glob_t *); static DIR *g_opendir(Char *, glob_t *); static Char *g_strchr(Char *, wchar_t); @@ -152,34 +171,34 @@ static Char *g_strchr(Char *, wchar_t); static Char *g_strcat(Char *, const Char *); #endif static int g_stat(Char *, struct stat *, glob_t *); -static int glob0(const Char *, glob_t *, int *); -static int glob1(Char *, glob_t *, int *); -static int glob2(Char *, Char *, Char *, Char *, glob_t *, int *); -static int glob3(Char *, Char *, Char *, Char *, Char *, glob_t *, int *); -static int globextend(const Char *, glob_t *, int *); -static const Char * +static int glob0(const Char *, glob_t *, struct glob_limit *); +static int glob1(Char *, glob_t *, struct glob_limit *); +static int glob2(Char *, Char *, Char *, Char *, glob_t *, + struct glob_limit *); +static int glob3(Char *, Char *, Char *, Char *, Char *, glob_t *, + struct glob_limit *); +static int globextend(const Char *, glob_t *, struct glob_limit *); +static const Char * globtilde(const Char *, Char *, size_t, glob_t *); -static int globexp1(const Char *, glob_t *, int *); -static int globexp2(const Char *, const Char *, glob_t *, int *, int *); +static int globexp1(const Char *, glob_t *, struct glob_limit *); +static int globexp2(const Char *, const Char *, glob_t *, int *, + struct glob_limit *); static int match(Char *, Char *, Char *); #ifdef DEBUG static void qprintf(const char *, Char *); #endif int -glob(pattern, flags, errfunc, pglob) - const char *pattern; - int flags, (*errfunc)(const char *, int); - glob_t *pglob; +glob(const char *pattern, int flags, int (*errfunc)(const char *, int), glob_t *pglob) { - const u_char *patnext; - int limit; + struct glob_limit limit = { 0, 0, 0, 0, 0 }; + const char *patnext; Char *bufnext, *bufend, patbuf[MAXPATHLEN], prot; mbstate_t mbs; wchar_t wc; size_t clen; - patnext = (u_char *) pattern; + patnext = pattern; if (!(flags & GLOB_APPEND)) { pglob->gl_pathc = 0; pglob->gl_pathv = NULL; @@ -187,11 +206,10 @@ glob(pattern, flags, errfunc, pglob) pglob->gl_offs = 0; } if (flags & GLOB_LIMIT) { - limit = pglob->gl_matchc; - if (limit == 0) - limit = ARG_MAX; - } else - limit = 0; + limit.l_path_lim = pglob->gl_matchc; + if (limit.l_path_lim == 0) + limit.l_path_lim = GLOB_LIMIT_PATH; + } pglob->gl_flags = flags & ~GLOB_MAGCHAR; pglob->gl_errfunc = errfunc; pglob->gl_matchc = 0; @@ -244,14 +262,17 @@ glob(pattern, flags, errfunc, pglob) * characters */ static int -globexp1(pattern, pglob, limit) - const Char *pattern; - glob_t *pglob; - int *limit; +globexp1(const Char *pattern, glob_t *pglob, struct glob_limit *limit) { const Char* ptr = pattern; int rv; + if ((pglob->gl_flags & GLOB_LIMIT) && + limit->l_brace_cnt++ >= GLOB_LIMIT_BRACE) { + errno = 0; + return (GLOB_NOSPACE); + } + /* Protect a single {}, for find(1), like csh */ if (pattern[0] == LBRACE && pattern[1] == RBRACE && pattern[2] == EOS) return glob0(pattern, pglob, limit); @@ -270,10 +291,8 @@ globexp1(pattern, pglob, limit) * If it fails then it tries to glob the rest of the pattern and returns. */ static int -globexp2(ptr, pattern, pglob, rv, limit) - const Char *ptr, *pattern; - glob_t *pglob; - int *rv, *limit; +globexp2(const Char *ptr, const Char *pattern, glob_t *pglob, int *rv, + struct glob_limit *limit) { int i; Char *lm, *ls; @@ -377,11 +396,7 @@ globexp2(ptr, pattern, pglob, rv, limit) * expand tilde from the passwd file. */ static const Char * -globtilde(pattern, patbuf, patbuf_len, pglob) - const Char *pattern; - Char *patbuf; - size_t patbuf_len; - glob_t *pglob; +globtilde(const Char *pattern, Char *patbuf, size_t patbuf_len, glob_t *pglob) { struct passwd *pwd; char *h; @@ -447,13 +462,11 @@ globtilde(pattern, patbuf, patbuf_len, pglob) * if things went well, nonzero if errors occurred. */ static int -glob0(pattern, pglob, limit) - const Char *pattern; - glob_t *pglob; - int *limit; +glob0(const Char *pattern, glob_t *pglob, struct glob_limit *limit) { const Char *qpatnext; - int c, err, oldpathc; + int c, err; + size_t oldpathc; Char *bufnext, patbuf[MAXPATHLEN]; qpatnext = globtilde(pattern, patbuf, MAXPATHLEN, pglob); @@ -536,17 +549,13 @@ glob0(pattern, pglob, limit) } static int -compare(p, q) - const void *p, *q; +compare(const void *p, const void *q) { return(strcmp(*(char **)p, *(char **)q)); } static int -glob1(pattern, pglob, limit) - Char *pattern; - glob_t *pglob; - int *limit; +glob1(Char *pattern, glob_t *pglob, struct glob_limit *limit) { Char pathbuf[MAXPATHLEN]; @@ -563,10 +572,8 @@ glob1(pattern, pglob, limit) * meta characters. */ static int -glob2(pathbuf, pathend, pathend_last, pattern, pglob, limit) - Char *pathbuf, *pathend, *pathend_last, *pattern; - glob_t *pglob; - int *limit; +glob2(Char *pathbuf, Char *pathend, Char *pathend_last, Char *pattern, + glob_t *pglob, struct glob_limit *limit) { struct stat sb; Char *p, *q; @@ -582,6 +589,15 @@ glob2(pathbuf, pathend, pathend_last, pattern, pglob, limit) if (g_lstat(pathbuf, &sb, pglob)) return(0); + if ((pglob->gl_flags & GLOB_LIMIT) && + limit->l_stat_cnt++ >= GLOB_LIMIT_STAT) { + errno = 0; + if (pathend + 1 > pathend_last) + return (GLOB_ABORTED); + *pathend++ = SEP; + *pathend = EOS; + return (GLOB_NOSPACE); + } if (((pglob->gl_flags & GLOB_MARK) && pathend[-1] != SEP) && (S_ISDIR(sb.st_mode) || (S_ISLNK(sb.st_mode) && @@ -623,10 +639,9 @@ glob2(pathbuf, pathend, pathend_last, pattern, pglob, limit) } static int -glob3(pathbuf, pathend, pathend_last, pattern, restpattern, pglob, limit) - Char *pathbuf, *pathend, *pathend_last, *pattern, *restpattern; - glob_t *pglob; - int *limit; +glob3(Char *pathbuf, Char *pathend, Char *pathend_last, + Char *pattern, Char *restpattern, + glob_t *pglob, struct glob_limit *limit) { struct dirent *dp; DIR *dirp; @@ -666,18 +681,31 @@ glob3(pathbuf, pathend, pathend_last, pattern, restpattern, pglob, limit) else readdirfunc = readdir; while ((dp = (*readdirfunc)(dirp))) { - u_char *sc; + char *sc; Char *dc; wchar_t wc; size_t clen; mbstate_t mbs; + if ((pglob->gl_flags & GLOB_LIMIT) && + limit->l_readdir_cnt++ >= GLOB_LIMIT_READDIR) { + errno = 0; + if (pathend + 1 > pathend_last) + err = GLOB_ABORTED; + else { + *pathend++ = SEP; + *pathend = EOS; + err = GLOB_NOSPACE; + } + break; + } + /* Initial DOT must be matched literally. */ if (dp->d_name[0] == DOT && *pattern != DOT) continue; memset(&mbs, 0, sizeof(mbs)); dc = pathend; - sc = (u_char *) dp->d_name; + sc = dp->d_name; while (dc < pathend_last) { clen = mbrtowc(&wc, sc, MB_LEN_MAX, &mbs); if (clen == (size_t)-1 || clen == (size_t)-2) { @@ -722,18 +750,15 @@ glob3(pathbuf, pathend, pathend_last, pattern, restpattern, pglob, limit) * gl_pathv points to (gl_offs + gl_pathc + 1) items. */ static int -globextend(path, pglob, limit) - const Char *path; - glob_t *pglob; - int *limit; +globextend(const Char *path, glob_t *pglob, struct glob_limit *limit) { char **pathv; - int i; - u_int newsize, len; + size_t i, newsize, len; char *copy; const Char *p; - if (*limit && pglob->gl_pathc > *limit) { + if ((pglob->gl_flags & GLOB_LIMIT) && + pglob->gl_matchc > limit->l_path_lim) { errno = 0; return (GLOB_NOSPACE); } @@ -753,7 +778,7 @@ globextend(path, pglob, limit) if (pglob->gl_pathv == NULL && pglob->gl_offs > 0) { /* first time around -- clear initial gl_offs items */ pathv += pglob->gl_offs; - for (i = pglob->gl_offs; --i >= 0; ) + for (i = pglob->gl_offs + 1; --i > 0; ) *--pathv = NULL; } pglob->gl_pathv = pathv; @@ -761,6 +786,12 @@ globextend(path, pglob, limit) for (p = path; *p++;) continue; len = MB_CUR_MAX * (size_t)(p - path); /* XXX overallocation */ + limit->l_string_cnt += len; + if ((pglob->gl_flags & GLOB_LIMIT) && + limit->l_string_cnt >= GLOB_LIMIT_STRING) { + errno = 0; + return (GLOB_NOSPACE); + } if ((copy = malloc(len)) != NULL) { if (g_Ctoc(path, copy, len)) { free(copy); @@ -777,8 +808,7 @@ globextend(path, pglob, limit) * pattern causes a recursion level. */ static int -match(name, pat, patend) - Char *name, *pat, *patend; +match(Char *name, Char *pat, Char *patend) { int ok, negate_range; Char c, k; @@ -829,10 +859,9 @@ match(name, pat, patend) /* Free allocated data belonging to a glob_t structure. */ void -globfree(pglob) - glob_t *pglob; +globfree(glob_t *pglob) { - int i; + size_t i; char **pp; if (pglob->gl_pathv != NULL) { @@ -846,9 +875,7 @@ globfree(pglob) } static DIR * -g_opendir(str, pglob) - Char *str; - glob_t *pglob; +g_opendir(Char *str, glob_t *pglob) { char buf[MAXPATHLEN]; @@ -866,10 +893,7 @@ g_opendir(str, pglob) } static int -g_lstat(fn, sb, pglob) - Char *fn; - struct stat *sb; - glob_t *pglob; +g_lstat(Char *fn, struct stat *sb, glob_t *pglob) { char buf[MAXPATHLEN]; @@ -883,10 +907,7 @@ g_lstat(fn, sb, pglob) } static int -g_stat(fn, sb, pglob) - Char *fn; - struct stat *sb; - glob_t *pglob; +g_stat(Char *fn, struct stat *sb, glob_t *pglob) { char buf[MAXPATHLEN]; @@ -900,10 +921,9 @@ g_stat(fn, sb, pglob) } static Char * -g_strchr(str, ch) - Char *str; - wchar_t ch; +g_strchr(Char *str, wchar_t ch) { + do { if (*str == ch) return (str); @@ -912,10 +932,7 @@ g_strchr(str, ch) } static int -g_Ctoc(str, buf, len) - const Char *str; - char *buf; - u_int len; +g_Ctoc(const Char *str, char *buf, size_t len) { mbstate_t mbs; size_t clen; @@ -936,9 +953,7 @@ g_Ctoc(str, buf, len) #ifdef DEBUG static void -qprintf(str, s) - const char *str; - Char *s; +qprintf(const char *str, Char *s) { Char *p; --------------020403030703040107090209-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 19:58:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 986832B6; Wed, 20 Feb 2013 19:58:08 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 2DDB9AE; Wed, 20 Feb 2013 19:58:07 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id r6so6973396wey.5 for ; Wed, 20 Feb 2013 11:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=/9pYxqQ0ObQHe7L3/gTadKg22yepKNR25ZiUNP/IWH8=; b=NBK1GqcNV4y28gIveIMK9snpx7CWALXGasttg74136U1NFDsjOu5t64CrboQpVR3cY mrAyutEvThhVpJerigKJiOW82pyCvHTu06C0S0sxvzcmH+fAsut4MJQ/QamFX/vRxRuR GQv0YrJrBNVaSRKs8TsjOMg8edHcLg3MLjZ/KC7VJVoRF9vyWF6vtzz1t0UBUFHzyRR7 wlK2+W8j9clH/z372IDDvmH9v3o0WE7tSlUDnWDKqASajiiKcSemNOQjE43hTelsyM9q vKhe/VXdtpVBNdnFVMG27adN3NyCeb5FBoBPnKkJ6Re/jw0GW/B1+vDegO8LS6h8FnQj B/ww== X-Received: by 10.194.19.97 with SMTP id d1mr36281752wje.52.1361390286278; Wed, 20 Feb 2013 11:58:06 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id bj9sm33176224wib.4.2013.02.20.11.58.04 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 20 Feb 2013 11:58:05 -0800 (PST) Sender: Mikolaj Golub Date: Wed, 20 Feb 2013 21:58:02 +0200 From: Mikolaj Golub To: John Baldwin Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130220195801.GA8679@gmail.com> References: <20130119151253.GB88025@gmail.com> <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302200904.15324.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Kostik Belousov , "Robert N. M. Watson" , Attilio Rao , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:58:08 -0000 On Wed, Feb 20, 2013 at 09:04:14AM -0500, John Baldwin wrote: > The process should be stopped by the time we dump a core, so running it > multiple times should be ok in that the sizes should not change. I would > say that you should try to implement a "determine sizes" pass that doesn't > allocate anything, but others should comment on that. I had a little talk with kib about this recently. Kib's main concern looked to be that a process with many threads/open files might require considerable amount of kernel memory if the procstat notes are prepared in memory before writing. So currently I am working on another approach, when on the first pass the sizes are found, and on the second pass procstat notes are written to coredump without preliminarily storing all notes in memory buffer. Hope, the code won't look very ugly... > One other thing to consider is if gcore needs to be updated to output these > records as well. It could use the sysctls to fetch the data and then write > out appropriate notes I think, so perhaps it wouldn't be too difficult to add > this as a followup commit once the kernel version has settled and the file > format is set? Looks like very interesting idea! Thank you for all your comments and suggestions. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 20:01:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4BEA64E7 for ; Wed, 20 Feb 2013 20:01:35 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id DA04AEA for ; Wed, 20 Feb 2013 20:01:34 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id r5so6895447wey.18 for ; Wed, 20 Feb 2013 12:01:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=+6O/KyXiR2V29Mq3Key1HjSPoPoWpDw8K20n/LXkoCU=; b=F5TfubyW3D3M8CnRVZeAE2k4ECXC/2Ub/S/W0jNPhY4GBnKOK97rwsvw1cIfASm3xz 9zxOZste1WxVH80A0qzow7YGeRlpD9mmo7S8v74BtA6DwTi3fka+XD5IZfi9+Mygy2bO v/trRA4lgp1xlr4GOqBaj1Arx8aCagyUMQBLnuepAiyCl6CBjmuxphmPR1JZdW2s+Uy1 diMga7gRiOMDhdYg1kzUHiFLYYUIMBgFlRnWWdEVi1G/NyShFBfcuEXpKNuwl8MCgcu0 B2F7dx1sFuJo8sN+a1tYjKxQHv+wqMHTbubR42J3Noo2FzSKh5WX9iO9Y+wpK4AoP0QS S9vQ== MIME-Version: 1.0 X-Received: by 10.194.242.69 with SMTP id wo5mr36512712wjc.10.1361390494040; Wed, 20 Feb 2013 12:01:34 -0800 (PST) Received: by 10.216.105.1 with HTTP; Wed, 20 Feb 2013 12:01:33 -0800 (PST) X-Originating-IP: [216.223.13.196] In-Reply-To: <512516A7.2060604@delphij.net> References: <512516A7.2060604@delphij.net> Date: Wed, 20 Feb 2013 15:01:33 -0500 Message-ID: Subject: Re: SA-13:02/libc and FreeBSD 6 From: Mark Saad To: "freebsd-hackers@freebsd.org" X-Gm-Message-State: ALoCoQk1r8gw1GLduzdY0JL/b2B393PfI1YdCMQDacR1rKsq71VUL/kQQNKgAbIVSGMmsVfJ0l8S Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:01:35 -0000 Xin I am rebuilding now, I'll let you know how it works. On Wed, Feb 20, 2013 at 1:32 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02/20/13 09:29, Mark Saad wrote: > > All I was wondering if anyone knows, off hand if SA-13:02/libc > > applies to FreeBSD 6-STABLE and if it would be committed to the > > 6-STABLE branch ? > > The patch itself won't apply, there were many changes after the last > 6-STABLE branch. > > Here is a patch backported for stable/6 but I do not have time to set > up a testing environment for it, if you do, please let me know if the > patch worked or not, thanks! > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBCgAGBQJRJRanAAoJEG80Jeu8UPuzyf0H/AyoNHoCSoXxTRl4tu0NOFsR > lZ/5O7h+YMK6LejwQxEfbb9vnNkRYmP5FtM4Ja7cQjqvFM24tL4RXtoazdYQcgid > /X+ExMIghF+/5fbEDt8x03lKQB8G5Ua3HTIqQfZoM5LREdzlXsyxREep4VspgT+y > GTofcvwReT7LJZyYqeYmLq+tJLOy/gWkl95MJPz/0E58+H/xqCwTEol8vDhUqTYh > WuBfRzNpY2OLnc5RStKZ+Vj+vkNIFHeHrOmwcYby+MGYl8V89pb+MjKP/mEITxcv > 8NF8Ti52yY8ZtG7aS8tvAoY6qeAqWknv1yiHg+IZrgvtkXSBefExUSCAzS2z1G8= > =m/h0 > -----END PGP SIGNATURE----- > -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 20:31:59 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01EED4DA for ; Wed, 20 Feb 2013 20:31:59 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id AF9492C3 for ; Wed, 20 Feb 2013 20:31:58 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r1KKVpbd015687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 21:31:56 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r1KKVmmU015686; Wed, 20 Feb 2013 21:31:48 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Wed, 20 Feb 2013 21:31:48 +0100 From: Paul Schenkeveld To: "Daniel O'Connor" Subject: IPMI console [Re: Chicken and egg, encrypted root FS on remote server] Message-ID: <20130220203148.GA1803@psconsult.nl> References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> <20130220111339.GA65661@psconsult.nl> <8C2980B2-3B2C-4081-9287-39EFB47ABC3D@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C2980B2-3B2C-4081-9287-39EFB47ABC3D@gsoft.com.au> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:31:59 -0000 Hi Daniel, On Wed, Feb 20, 2013 at 10:55:47PM +1030, Daniel O'Connor wrote: > > On 20/02/2013, at 21:43, Paul Schenkeveld wrote: > >> What about getting a remote console like HP's ILO or Dell's DRAC ? > >> > >> You get to login remotely, you can use some degree of access control... you can even remote boot. > > > > For new hardware I could indeed use this, the current hardware does not > > support remote console. > > > > I don't have experience with ILO nor DRAC but I do have experience with > > SuperMicro's KVM over LAN which does need a java client to run. If I can > > enter the passphrase over ssh that would be better as I can use any device > > including a smartphone to dial in and enter the passphrase. > > > If you setup a serial console you don't need Java if you use ipmitool, eg > ipmitool -H remoteip -U ADMIN -I lanplus sol activate Tried that with some Supermicro servers, the serial console allows me to get into BIOS config and shows boot messages up to starting the kernel, once the kernel starts output stops. In the BIOS setup, console redirect defaults to com2 port which explains why output stops after the loader passes control to the kernel. BTW, ipmitool always gives me "Info: cannot activate SOL payload with encryption" but ipmi-console (sysutils/freeipmi) works. If I change the console redirect to com1, my screen stays blank. Would you perhaps know how to use com1 for redirect and connect to it using ipmi-console (or ipmi-tool)? Thanks, Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 20:51:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE5E7E4C; Wed, 20 Feb 2013 20:51:55 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id EE1053F4; Wed, 20 Feb 2013 20:51:54 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGw2JVFbs5l5/2dsb2JhbABFwF+BARdzgh8BAQUnLyMQCw4KBQQlDwIoHgYBDAEHAQEFiA0IwE6PDgeDQAOPGIElAZZJgwg Received: from 121.153-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.153.121]) by relay.skynet.be with ESMTP; 20 Feb 2013 21:51:46 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.6/8.14.6) with ESMTP id r1KKpj4e088264; Wed, 20 Feb 2013 21:51:46 +0100 (CET) (envelope-from tijl@coosemans.org) Message-ID: <51253759.70508@coosemans.org> Date: Wed, 20 Feb 2013 21:51:37 +0100 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: Konstantin Belousov , Damjan Jovanovic Subject: Re: [patch] Wine DLL base address patches References: <20130220154855.GF2598@kib.kiev.ua> In-Reply-To: <20130220154855.GF2598@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4D62C2023304E37962419127" Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:51:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D62C2023304E37962419127 Content-Type: multipart/mixed; boundary="------------080104070008010904010603" This is a multi-part message in MIME format. --------------080104070008010904010603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20-02-2013 16:48, Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: >> Hi >> >> Wine needs some of its libraries to be loaded at specific base >> addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently= >> lacks. >> >> I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that= >> loads libraries at their preferred base addresses >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176216), as well as a po= rt >> of Prelink to FreeBSD which Wine uses to set base addresses >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176283). Both work :-), >> the changed dynamic loader doesn't show any problems in a few days of >> testing, and prelink works with the --reloc-only option as used by >> Wine. >> >> Please review/test/comment/commit. >=20 > Unfortunately, it is not safe. MAP_FIXED overrides any previous mapping= s > which could exist at the specified address. I've simplified the rtld patch to a single line. The second patch makes Wine use -Ttext-segment linker flag instead of prelink. This requires binutils from ports, but it's easier than porting prelink. --------------080104070008010904010603 Content-Type: text/plain; charset=ISO-8859-15; name="rtld-wine.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rtld-wine.diff" Index: libexec/rtld-elf/map_object.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- libexec/rtld-elf/map_object.c (revision 246986) +++ libexec/rtld-elf/map_object.c (working copy) @@ -175,7 +175,7 @@ map_object(int fd, const char *path, const struct base_vaddr =3D trunc_page(segs[0]->p_vaddr); base_vlimit =3D round_page(segs[nsegs]->p_vaddr + segs[nsegs]->p_mem= sz); mapsize =3D base_vlimit - base_vaddr; - base_addr =3D hdr->e_type =3D=3D ET_EXEC ? (caddr_t) base_vaddr : NU= LL; + base_addr =3D (caddr_t) base_vaddr; =20 mapbase =3D mmap(base_addr, mapsize, PROT_NONE, MAP_ANON | MAP_PRIVA= TE | MAP_NOCORE, -1, 0); --------------080104070008010904010603 Content-Type: text/plain; charset=ISO-8859-15; name="wine-devel-image-base.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="wine-devel-image-base.diff" Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile (revision 312556) +++ Makefile (working copy) @@ -28,7 +28,7 @@ LATEST_LINK=3D wine-devel CPPFLAGS+=3D -I${LOCALBASE}/include LDFLAGS+=3D -L${LOCALBASE}/lib -USE_GCC=3D any +USE_GCC=3D 4.7 GNU_CONFIGURE=3D yes CONFIGURE_ARGS+=3D--verbose --disable-tests \ --without-alsa --without-capi --without-dbus \ Index: files/patch-tools-winegcc-utils.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- files/patch-tools-winegcc-utils.h (revision 0) +++ files/patch-tools-winegcc-utils.h (working copy) @@ -0,0 +1,12 @@ +--- tools/winegcc/utils.h.orig ++++ tools/winegcc/utils.h +@@ -42,7 +42,8 @@ +=20 + enum target_platform + { +- PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_WI= NDOWS, PLATFORM_CYGWIN ++ PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_FREEBSD, PLATFORM_SO= LARIS, ++ PLATFORM_WINDOWS, PLATFORM_CYGWIN + }; +=20 + void error(const char* s, ...) DECLSPEC_NORETURN; Index: files/patch-tools-winegcc-winegcc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- files/patch-tools-winegcc-winegcc.c (revision 0) +++ files/patch-tools-winegcc-winegcc.c (working copy) @@ -0,0 +1,32 @@ +--- tools/winegcc/winegcc.c.orig ++++ tools/winegcc/winegcc.c +@@ -172,6 +172,7 @@ + { + { "macos", PLATFORM_APPLE }, + { "darwin", PLATFORM_APPLE }, ++ { "freebsd", PLATFORM_FREEBSD }, + { "solaris", PLATFORM_SOLARIS }, + { "cygwin", PLATFORM_CYGWIN }, + { "mingw32", PLATFORM_WINDOWS }, +@@ -232,6 +233,8 @@ +=20 + #ifdef __APPLE__ + static enum target_platform build_platform =3D PLATFORM_APPLE; ++#elif defined(__FreeBSD__) ++static enum target_platform build_platform =3D PLATFORM_FREEBSD; + #elif defined(__sun) + static enum target_platform build_platform =3D PLATFORM_SOLARIS; + #elif defined(__CYGWIN__) +@@ -1020,6 +1023,12 @@ + if (opts->strip) + strarray_add(link_args, "-Wl,-x"); + break; ++ case PLATFORM_FREEBSD: ++ if (opts->image_base) ++ { ++ strarray_add(link_args, strmake("-Wl,-Ttext-segment=3D%s", = opts->image_base)); ++ } ++ break; + case PLATFORM_SOLARIS: + { + char *mapfile =3D get_temp_file( output_name, ".map" ); --------------080104070008010904010603-- --------------enig4D62C2023304E37962419127 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iF4EAREIAAYFAlElN2EACgkQfoCS2CCgtisDnAD9GONXdn6WPP8p/XyoBD88blqC ddZpmexN7gZj7nGrtGoA/0Khh2ETumbLDXjIkXceVf2xxzOwJSinzMXEAr+3X6LR =0GBW -----END PGP SIGNATURE----- --------------enig4D62C2023304E37962419127-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 21:16:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1172C8D; Wed, 20 Feb 2013 21:16:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4C5787; Wed, 20 Feb 2013 21:16:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1KLGTQe014828; Wed, 20 Feb 2013 23:16:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1KLGTQe014828 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1KLGTYu014827; Wed, 20 Feb 2013 23:16:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Feb 2013 23:16:29 +0200 From: Konstantin Belousov To: Tijl Coosemans Subject: Re: [patch] Wine DLL base address patches Message-ID: <20130220211629.GR2598@kib.kiev.ua> References: <20130220154855.GF2598@kib.kiev.ua> <51253759.70508@coosemans.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3VJSuQsIgdmXj2/q" Content-Disposition: inline In-Reply-To: <51253759.70508@coosemans.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Damjan Jovanovic , freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:16:36 -0000 --3VJSuQsIgdmXj2/q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 09:51:37PM +0100, Tijl Coosemans wrote: > On 20-02-2013 16:48, Konstantin Belousov wrote: > > On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: > >> Hi > >> > >> Wine needs some of its libraries to be loaded at specific base > >> addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently > >> lacks. > >> > >> I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that > >> loads libraries at their preferred base addresses > >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176216), as well as a po= rt > >> of Prelink to FreeBSD which Wine uses to set base addresses > >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176283). Both work :-), > >> the changed dynamic loader doesn't show any problems in a few days of > >> testing, and prelink works with the --reloc-only option as used by > >> Wine. > >> > >> Please review/test/comment/commit. > >=20 > > Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings > > which could exist at the specified address. >=20 > I've simplified the rtld patch to a single line. The second patch makes > Wine use -Ttext-segment linker flag instead of prelink. This requires > binutils from ports, but it's easier than porting prelink. >=20 > Index: libexec/rtld-elf/map_object.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- libexec/rtld-elf/map_object.c (revision 246986) > +++ libexec/rtld-elf/map_object.c (working copy) > @@ -175,7 +175,7 @@ map_object(int fd, const char *path, const struct > base_vaddr =3D trunc_page(segs[0]->p_vaddr); > base_vlimit =3D round_page(segs[nsegs]->p_vaddr + segs[nsegs]->p_mem= sz); > mapsize =3D base_vlimit - base_vaddr; > - base_addr =3D hdr->e_type =3D=3D ET_EXEC ? (caddr_t) base_vaddr : NU= LL; > + base_addr =3D (caddr_t) base_vaddr; > =20 > mapbase =3D mmap(base_addr, mapsize, PROT_NONE, MAP_ANON | MAP_PRIVA= TE | > MAP_NOCORE, -1, 0); If this is enough for wine, I definitely have no objection. The typical dso has zero virtual base for the first segment, so the patch should change nothing for dso built without special map file. > Index: Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile (revision 312556) > +++ Makefile (working copy) > @@ -28,7 +28,7 @@ > LATEST_LINK=3D wine-devel > CPPFLAGS+=3D -I${LOCALBASE}/include > LDFLAGS+=3D -L${LOCALBASE}/lib > -USE_GCC=3D any > +USE_GCC=3D 4.7 > GNU_CONFIGURE=3D yes > CONFIGURE_ARGS+=3D--verbose --disable-tests \ > --without-alsa --without-capi --without-dbus \ > Index: files/patch-tools-winegcc-utils.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- files/patch-tools-winegcc-utils.h (revision 0) > +++ files/patch-tools-winegcc-utils.h (working copy) > @@ -0,0 +1,12 @@ > +--- tools/winegcc/utils.h.orig > ++++ tools/winegcc/utils.h > +@@ -42,7 +42,8 @@ > +=20 > + enum target_platform > + { > +- PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_WI= NDOWS, PLATFORM_CYGWIN > ++ PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_FREEBSD, PLATFORM_SO= LARIS, > ++ PLATFORM_WINDOWS, PLATFORM_CYGWIN > + }; > +=20 > + void error(const char* s, ...) DECLSPEC_NORETURN; > Index: files/patch-tools-winegcc-winegcc.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- files/patch-tools-winegcc-winegcc.c (revision 0) > +++ files/patch-tools-winegcc-winegcc.c (working copy) > @@ -0,0 +1,32 @@ > +--- tools/winegcc/winegcc.c.orig > ++++ tools/winegcc/winegcc.c > +@@ -172,6 +172,7 @@ > + { > + { "macos", PLATFORM_APPLE }, > + { "darwin", PLATFORM_APPLE }, > ++ { "freebsd", PLATFORM_FREEBSD }, > + { "solaris", PLATFORM_SOLARIS }, > + { "cygwin", PLATFORM_CYGWIN }, > + { "mingw32", PLATFORM_WINDOWS }, > +@@ -232,6 +233,8 @@ > +=20 > + #ifdef __APPLE__ > + static enum target_platform build_platform =3D PLATFORM_APPLE; > ++#elif defined(__FreeBSD__) > ++static enum target_platform build_platform =3D PLATFORM_FREEBSD; > + #elif defined(__sun) > + static enum target_platform build_platform =3D PLATFORM_SOLARIS; > + #elif defined(__CYGWIN__) > +@@ -1020,6 +1023,12 @@ > + if (opts->strip) > + strarray_add(link_args, "-Wl,-x"); > + break; > ++ case PLATFORM_FREEBSD: > ++ if (opts->image_base) > ++ { > ++ strarray_add(link_args, strmake("-Wl,-Ttext-segment=3D%s", = opts->image_base)); > ++ } > ++ break; > + case PLATFORM_SOLARIS: > + { > + char *mapfile =3D get_temp_file( output_name, ".map" ); --3VJSuQsIgdmXj2/q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJT0tAAoJEJDCuSvBvK1BOjwQAIwDtkAYTikXCeL6vsrst7hz 6+VKPQm2wZLO0/VBhpKqYgzhjcynxSTYrmf+DWu3iq4i8S7z37nO0UFNozBCCZhh iHVdXWJ/+NhpBGMVy4b3V88Z6BVvW8i7hZVsX35eiKKLq87hhC9R4rpjEQK9eKgK 10AFW5uNYpmR8IN/qLOXTgMOQ76x8lHrcLdvsw5Pe7WhKX9VGO47CanBm9Ux3cA1 cvmlx8V36W/cATH+dkZ1NgNFtWB2rjL7jp1FR6WOU4K02Jl22ggVVrc6l6E/owdh DTwrkptrL+Fca0vaN+0xYQbJiRcCZ2Z2m4uTaEH3/6bzFnr7s10lRRA5KHElgzps MSoery+hPL2YzfTvaYGIBbA+cciguiwFBVavi8BjrmIwLuRnwznN8JTJNjG4UV0v Wu+BYju5n3jdBlxE+0adZVChioP3f9A0c6xnEoxps4D2ekan9L8Ly1KcjqzHlaJH y2qTCS4xxBLF6JAdX/pQGVaG5a0NfPDyPnK/TPq9dKPLE4uuzBAPq5nscpGpbfh8 9WlFffV4DYuispAcr9ojeOrfikp5yo0WNwRJS34vdw4h/a2jKwbq/qcNOZsbjGS0 8fUIqoQN1ljhW+8fDRxMPrCAyVUYvqZHmHP8mrhCHbzvbPfrZYoA6wTS3l8JoblE b8xJHdk5Lb7jGag5YkLI =kx1j -----END PGP SIGNATURE----- --3VJSuQsIgdmXj2/q-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 21:34:01 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 823773AD for ; Wed, 20 Feb 2013 21:34:01 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F104860 for ; Wed, 20 Feb 2013 21:34:00 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.6/8.14.6) with ESMTP id r1KLXw4p022829 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 21:33:58 GMT (envelope-from vince@unsane.co.uk) Message-ID: <51254145.6090101@unsane.co.uk> Date: Wed, 20 Feb 2013 21:33:57 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Schenkeveld Subject: Re: IPMI console [Re: Chicken and egg, encrypted root FS on remote server] References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> <20130220111339.GA65661@psconsult.nl> <8C2980B2-3B2C-4081-9287-39EFB47ABC3D@gsoft.com.au> <20130220203148.GA1803@psconsult.nl> In-Reply-To: <20130220203148.GA1803@psconsult.nl> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:34:01 -0000 On 20/02/2013 20:31, Paul Schenkeveld wrote: > Hi Daniel, > > On Wed, Feb 20, 2013 at 10:55:47PM +1030, Daniel O'Connor wrote: >> On 20/02/2013, at 21:43, Paul Schenkeveld wrote: >>>> What about getting a remote console like HP's ILO or Dell's DRAC ? >>>> >>>> You get to login remotely, you can use some degree of access control... you can even remote boot. >>> For new hardware I could indeed use this, the current hardware does not >>> support remote console. >>> >>> I don't have experience with ILO nor DRAC but I do have experience with >>> SuperMicro's KVM over LAN which does need a java client to run. If I can >>> enter the passphrase over ssh that would be better as I can use any device >>> including a smartphone to dial in and enter the passphrase. >> >> If you setup a serial console you don't need Java if you use ipmitool, eg >> ipmitool -H remoteip -U ADMIN -I lanplus sol activate > Tried that with some Supermicro servers, the serial console allows me to > get into BIOS config and shows boot messages up to starting the kernel, > once the kernel starts output stops. > > In the BIOS setup, console redirect defaults to com2 port which explains > why output stops after the loader passes control to the kernel. > > BTW, ipmitool always gives me "Info: cannot activate SOL payload with > encryption" but ipmi-console (sysutils/freeipmi) works. > > If I change the console redirect to com1, my screen stays blank. Would > you perhaps know how to use com1 for redirect and connect to it using > ipmi-console (or ipmi-tool)? I have a supermicro using ipmi sol running happily using com2 my notes were ahem,less than through however hopefully they are enough? (FreeBSD 9.1-RELEASE) For Serial over lan (ipmi) edit /boot.config to contain -Dh edit /boot/loader.conf to add ipmi_load="YES" hint.uart.0.flags="" hint.uart.1.flags="0x10" console="comconsole vidconsole" comconsole_speed="19200" boot_multicons="yes" edit /etc/ttys change line for ttyu1 ttyu1 "/usr/libexec/getty std.19200" vt100 on secure -- root@kyanite london]# ipmitool -I lanplus -U admin -E -H 192.168.22.118 sol activate Unable to read password from environment Password: [SOL Session operational. Use ~? for help] FreeBSD/amd64 (copia.namesco.net) (ttyu1) login: Hope thats helpful Vince > Thanks, > > Paul Schenkeveld > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 22:36:19 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 457CC277 for ; Wed, 20 Feb 2013 22:36:19 +0000 (UTC) (envelope-from prvs=1763e08c5b=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id DDE0CE52 for ; Wed, 20 Feb 2013 22:36:18 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002317345.msg for ; Wed, 20 Feb 2013 22:36:16 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 20 Feb 2013 22:36:16 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1763e08c5b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: hackers@freebsd.org Message-ID: <1BC5F51A18464B83BA79890CC349128C@multiplay.co.uk> From: "Steven Hartland" To: "Paul Schenkeveld" , "Daniel O'Connor" References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> <20130220111339.GA65661@psconsult.nl> <8C2980B2-3B2C-4081-9287-39EFB47ABC3D@gsoft.com.au> <20130220203148.GA1803@psconsult.nl> Subject: Re: IPMI console [Re: Chicken and egg, encrypted root FS on remote server] Date: Wed, 20 Feb 2013 22:36:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:36:19 -0000 ----- Original Message ----- From: "Paul Schenkeveld" To: "Daniel O'Connor" Cc: Sent: Wednesday, February 20, 2013 8:31 PM Subject: IPMI console [Re: Chicken and egg, encrypted root FS on remote server] > Hi Daniel, > > On Wed, Feb 20, 2013 at 10:55:47PM +1030, Daniel O'Connor wrote: >> >> On 20/02/2013, at 21:43, Paul Schenkeveld wrote: >> >> What about getting a remote console like HP's ILO or Dell's DRAC ? >> >> >> >> You get to login remotely, you can use some degree of access control... you can even remote boot. >> > >> > For new hardware I could indeed use this, the current hardware does not >> > support remote console. >> > >> > I don't have experience with ILO nor DRAC but I do have experience with >> > SuperMicro's KVM over LAN which does need a java client to run. If I can >> > enter the passphrase over ssh that would be better as I can use any device >> > including a smartphone to dial in and enter the passphrase. >> >> >> If you setup a serial console you don't need Java if you use ipmitool, eg >> ipmitool -H remoteip -U ADMIN -I lanplus sol activate > > Tried that with some Supermicro servers, the serial console allows me to > get into BIOS config and shows boot messages up to starting the kernel, > once the kernel starts output stops. > > In the BIOS setup, console redirect defaults to com2 port which explains > why output stops after the loader passes control to the kernel. > > BTW, ipmitool always gives me "Info: cannot activate SOL payload with > encryption" but ipmi-console (sysutils/freeipmi) works. > > If I change the console redirect to com1, my screen stays blank. Would > you perhaps know how to use com1 for redirect and connect to it using > ipmi-console (or ipmi-tool)? We use the following on Supermicro servers works fine:- http://blog.multiplay.co.uk/2012/12/freebsd-serial-over-lan/ Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 22:58:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 698E12D8; Wed, 20 Feb 2013 22:58:13 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by mx1.freebsd.org (Postfix) with ESMTP id B6828AF; Wed, 20 Feb 2013 22:58:12 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id l12so6395197lbo.19 for ; Wed, 20 Feb 2013 14:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/V8kj3eFgSTjSq5Fy7prqZbw8GKmpMM1yOOo59+XPoA=; b=mB6ZzmtwR/IRBhdexuhSfb9NRMeS1uOTsxEbPcHXr3si7tBP39RejNbregbhkHWKUc wQDmRSsVZWgw/zkVYvg51c/BEyStpi+jcUZMY88hwx3ANtXFF1yReOgomHiIfPqUCP5C touga4jvIR3KplJdXtFFT8QzRo96tQpCQlqZSaswOeXa5ng/hOmAXmkHsDSSgEcEPku9 0T3MCOVmS5x5Xa+fsWsmNdauiQ8qXSKY3Ru8s3crfvYbPjkgwHpWW30fMhn7F/6qYWFN KJkDPUiEmWEgFqJtU4MkDKah4BpPNhEnu1FoIhPNNQ3pRNATozuZCd5OM3wTgYPTk4Bm yyXw== X-Received: by 10.152.111.67 with SMTP id ig3mr12427873lab.41.1361401085666; Wed, 20 Feb 2013 14:58:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.20.138 with HTTP; Wed, 20 Feb 2013 14:57:45 -0800 (PST) In-Reply-To: <51253759.70508@coosemans.org> References: <20130220154855.GF2598@kib.kiev.ua> <51253759.70508@coosemans.org> From: Damjan Jovanovic Date: Thu, 21 Feb 2013 00:57:45 +0200 Message-ID: Subject: Re: [patch] Wine DLL base address patches To: Tijl Coosemans Content-Type: multipart/mixed; boundary=f46d04088f171ba4d104d62fe4f9 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:58:13 -0000 --f46d04088f171ba4d104d62fe4f9 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans wrote: > On 20-02-2013 16:48, Konstantin Belousov wrote: >> On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: >>> Hi >>> >>> Wine needs some of its libraries to be loaded at specific base >>> addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently >>> lacks. >>> >>> I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that >>> loads libraries at their preferred base addresses >>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port >>> of Prelink to FreeBSD which Wine uses to set base addresses >>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-), >>> the changed dynamic loader doesn't show any problems in a few days of >>> testing, and prelink works with the --reloc-only option as used by >>> Wine. >>> >>> Please review/test/comment/commit. >> >> Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings >> which could exist at the specified address. > > I've simplified the rtld patch to a single line. The second patch makes > Wine use -Ttext-segment linker flag instead of prelink. This requires > binutils from ports, but it's easier than porting prelink. > All of that occurred to me as well. The problem with that one-line rtld patch is that loading an application will now fail if any of its libraries cannot be loaded at their requested address. The problem with -Ttext-segment (and isn't it just -Ttext?) is that it doesn't seem to work: the base_vaddr seen by rtld will remain 0, and the address listed in /proc/.../map is different from what it should be. Also run "readelf -l" on a library compiled that way and compare with the output of one run through "prelink --reloc-only", you'll see the lowest VirtAddr and PhysAddr in LOAD headers change only with prelink. I really ported prelink because there was no other choice. See my attached test cases, and examine the contents of /proc/.../map while they run. --f46d04088f171ba4d104d62fe4f9-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 23:18:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0609FEFB for ; Wed, 20 Feb 2013 23:18:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x229.google.com (we-in-x0229.1e100.net [IPv6:2a00:1450:400c:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 961221CA for ; Wed, 20 Feb 2013 23:18:50 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t11so7231627wey.14 for ; Wed, 20 Feb 2013 15:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DLUxnzX/6AiImy8g58yKeaJsmBZoA9roOeuVlflmWBY=; b=gp79cZxatsn/QHMQkuxElnt2uFUIOjMuszw6V92/8OqQrsEdDEMm2PEIoIte3294EC s4ZX0SyiOxMM1Mzto7LoTz8u4EniwYPUu7TUZklU71pSgvWQFQGsoEZxDVlnJjcFKr7i H3XD5Bi6qblZk+9xJOGS9Eq70Uk8IJHvIQLPQUl/sV7UMX4pvRCMk7/pialhZv4VJZ4O b/h4VfCRVAgiCHzq+FFy4pGcqszDMybjWoeSet9nf/zjZd0LdXoZDnJ+Ngp6UBb4cq0y 8E2/BqGyAR1ZicNmS4kWfDcweSamYXmMhPBqLXjn0J7doIpO5oTWwVvS7asjrp3lyBRd BPtw== MIME-Version: 1.0 X-Received: by 10.194.108.101 with SMTP id hj5mr37407547wjb.6.1361402329648; Wed, 20 Feb 2013 15:18:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Wed, 20 Feb 2013 15:18:49 -0800 (PST) In-Reply-To: References: <512516A7.2060604@delphij.net> Date: Wed, 20 Feb 2013 15:18:49 -0800 X-Google-Sender-Auth: 5zZxfJpthC2GqWpm01_TKSM7BVU Message-ID: Subject: Re: SA-13:02/libc and FreeBSD 6 From: Adrian Chadd To: Mark Saad Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 23:18:51 -0000 On 20 February 2013 12:01, Mark Saad wrote: > Xin > I am rebuilding now, I'll let you know how it works. As I've said before, if someone wants to take ownership of 6.x and backport changes / push them into STABLE_6, be my guest. Yahoo was doing that for some unsupported old releases for a while. They'd still stay unsupported.. well, as long as there's not a big group of 6.x users standing up and taking ownership. (Same can be said of what's going to happen to 7.x soon.) Adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 00:01:49 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C4A5DC5F for ; Thu, 21 Feb 2013 00:01:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4631A655 for ; Thu, 21 Feb 2013 00:01:49 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.55]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r1L01W6V001618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 10:31:38 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: IPMI console [Re: Chicken and egg, encrypted root FS on remote server] Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" X-Priority: 3 In-Reply-To: <1BC5F51A18464B83BA79890CC349128C@multiplay.co.uk> Date: Thu, 21 Feb 2013 10:31:32 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> <20130220111339.GA65661@psconsult.nl> <8C2980B2-3B2C-4081-9287-39EFB47ABC3D@gsoft.com.au> <20130220203148.GA1803@psconsult.nl> <1BC5F51A18464B83BA79890CC349128C@multiplay.co.uk> To: "Steven Hartland" X-Mailer: Apple Mail (2.1499) X-Spam-Score: -3.051 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: hackers@freebsd.org, Paul Schenkeveld X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:01:49 -0000 On 21/02/2013, at 9:06, "Steven Hartland" = wrote: >> If I change the console redirect to com1, my screen stays blank. = Would >> you perhaps know how to use com1 for redirect and connect to it using >> ipmi-console (or ipmi-tool)? >=20 > We use the following on Supermicro servers works fine:- > http://blog.multiplay.co.uk/2012/12/freebsd-serial-over-lan/ Nice! BTW do you know what flag 0x20 does for UART? 0x10 is documented but = 0x20 is not. I had a quick look at the code and AFAIK it doesn't do anything (on 9.1 = anyway). Actually at a guess I would say it's a hangover from sio(4) where 0x20 = forced the device in question to be the console. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 12:14:04 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 26ECA160A for ; Thu, 21 Feb 2013 12:14:04 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD5E34E for ; Thu, 21 Feb 2013 12:14:01 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-85-105.lns20.adl2.internode.on.net [118.210.85.105]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r1L9cxxq084990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 20:09:04 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: IPMI console [Re: Chicken and egg, encrypted root FS on remote server] Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" X-Priority: 3 In-Reply-To: Date: Thu, 21 Feb 2013 20:08:57 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <4DAC976A-FAC4-4B8A-A1A7-DB58387D8D53@gsoft.com.au> References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> <20130220111339.GA65661@psconsult.nl> <8C2980B2-3B2C-4081-9287-39EFB47ABC3D@gsoft.com.au> <20130220203148.GA1803@psconsult.nl> <1BC5F51A18464B83BA79890CC349128C@multiplay.co.uk> To: "Steven Hartland" X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: hackers@freebsd.org, Paul Schenkeveld X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:14:04 -0000 On 21/02/2013, at 19:33, "Steven Hartland" = wrote: >> I had a quick look at the code and AFAIK it doesn't do anything (on = 9.1 anyway). >> Actually at a guess I would say it's a hangover from sio(4) where = 0x20 forced the >> device in question to be the console. >=20 > According to the handbook, where I got the settings from, 0x20: > "Forces this unit to be the console (unless there is another higher = priority console), > regardless of the -h option discussed below. The flag 0x20 must be = used together with > the 0x10 flag." Yes but that is about sio, not uart. sio(4) has.. 0x00010 device is potential system console 0x00020 device is forced to become system console but uart(4) just has.. 0x00010 device is potential system console -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 12:42:38 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC514DA2 for ; Thu, 21 Feb 2013 12:42:38 +0000 (UTC) (envelope-from prvs=176432f767=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4F439D07 for ; Thu, 21 Feb 2013 12:42:37 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002324026.msg for ; Thu, 21 Feb 2013 09:03:28 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 21 Feb 2013 09:03:28 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=176432f767=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: hackers@freebsd.org Message-ID: From: "Steven Hartland" To: "Daniel O'Connor" References: <20130220065810.GA25027@psconsult.nl> <20130220074655.GA59952@psconsult.nl> <20130220111339.GA65661@psconsult.nl> <8C2980B2-3B2C-4081-9287-39EFB47ABC3D@gsoft.com.au> <20130220203148.GA1803@psconsult.nl> <1BC5F51A18464B83BA79890CC349128C@multiplay.co.uk> Subject: Re: IPMI console [Re: Chicken and egg, encrypted root FS on remote server] Date: Thu, 21 Feb 2013 09:03:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: hackers@freebsd.org, Paul Schenkeveld X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:42:38 -0000 ----- Original Message ----- From: "Daniel O'Connor" > On 21/02/2013, at 9:06, "Steven Hartland" wrote: >>> If I change the console redirect to com1, my screen stays blank. Would >>> you perhaps know how to use com1 for redirect and connect to it using >>> ipmi-console (or ipmi-tool)? >> >> We use the following on Supermicro servers works fine:- >> http://blog.multiplay.co.uk/2012/12/freebsd-serial-over-lan/ > > > Nice! > > BTW do you know what flag 0x20 does for UART? 0x10 is documented but 0x20 is not. > > I had a quick look at the code and AFAIK it doesn't do anything (on 9.1 anyway). > > Actually at a guess I would say it's a hangover from sio(4) where 0x20 forced the > device in question to be the console. According to the handbook, where I got the settings from, 0x20: "Forces this unit to be the console (unless there is another higher priority console), regardless of the -h option discussed below. The flag 0x20 must be used together with the 0x10 flag." Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 14:08:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C0C3B199 for ; Thu, 21 Feb 2013 14:08:12 +0000 (UTC) (envelope-from nicholas@nickcwilson.co.uk) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BEF670C for ; Thu, 21 Feb 2013 14:08:11 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so5772852vba.27 for ; Thu, 21 Feb 2013 06:08:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:x-originating-ip:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=bq1yLWBXe4Ofujga+BDXOQzn2c+N3h4F9qmAySGNJrg=; b=SrQdfotP0kef9cVa79XSxKtvvbARDTy/AfUpCEA0yLPPaO7Lc/4XfTqxaOnkS5Q5TX 46UdY11R3nXAWfxaBu3nSYV/IksV7T7WhsIeMs4eRyh3m5aZohxA5KJa/lXTP4sxfYp9 90RysAfQUmeEtUMcba1Nw9aZhIQIkXYE07+psCx0Jq0S3hj3YhDrOViAfgIDe07Moksh kXOpAWyiihseuAX6wQS22xhbZY6X2gkssBrdYaxUB1+08ZKyqNkkdrLqgLhv/CdoMPnX VfDB8ximuFyO+VA8M2/++HQp2LokO55yJvSrp4OcwbGRAYyFvQJU7mpjQ9JrK9mS6Nra F11Q== X-Received: by 10.58.40.9 with SMTP id t9mr32344100vek.10.1361455248481; Thu, 21 Feb 2013 06:00:48 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by mx.google.com with ESMTPS id q5sm84070234vdj.5.2013.02.21.06.00.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 06:00:48 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db10so7971076veb.9 for ; Thu, 21 Feb 2013 06:00:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.24.98 with SMTP id t2mr27232876vdf.69.1361455247732; Thu, 21 Feb 2013 06:00:47 -0800 (PST) Received: by 10.58.200.226 with HTTP; Thu, 21 Feb 2013 06:00:47 -0800 (PST) X-Originating-IP: [2a02:390:a001:192:2010:aa2a:75ed:be50] Date: Thu, 21 Feb 2013 14:00:47 +0000 Message-ID: Subject: LOCAL_PEERCRED with socketpair From: Nicholas Wilson To: freebsd-hackers@freebsd.org X-Gm-Message-State: ALoCoQnA84aYQZ3rOgeJHKSWDL56R8fNXtSN3xkw3d6H0pBGZp2OPc7/VZa+VBJBoSC64k80gH5W Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:08:12 -0000 Hello, I've noticed that getpeereid/LOCAL_PEERCRED doesn't work with sockets created through socketpair, but only through actual listen/connect calls. I notice that in unp_connect, we stash the peercred of the thread, then call on to unp_connect2. In kern_socketpair, we call straight through to unp_connect2 (through pr_usrreqs->pru_connect2), so this makes sense from the code. I'd like to suggest we support peercred for socketpair-created sockets. Motivation: 1. All unix-domain STREAM sockets should be created equal. We can support it, so why shouldn't we? 2. getpeerucred on Solaris, SO_PEERCRED on Linux, and of most relevance MacOS's implementation of LOCAL_PEERCRED all work fine on socketpair sockets. (A point against is that AIX's getpeereid follows the BSD behaviour of requiring a connect/listen call.) Programmers are therefore more likely to expect it to work than not. Apart from AIX, we're the only people not providing this capability. 3. Real-world uses. I was actually trying to sandbox a daemon with capsicum when I ran into this, which requires a certain amount of mucking around with file descriptor passing. Being able to establish a channel with a socketpair, hand it to a secure daemon, and be able to check the peer's credentials in the daemon, is a reasonable use-case. 4. Compatibility. It's not going to break old applications to make the change. Patch: --- sys/kern/uipc_syscalls.c.RELEASE-9.1-243808 2013-02-21 13:37:31.778270145 +0000 +++ sys/kern/uipc_syscalls.c 2013-02-21 13:45:58.747896673 +0000 @@ -642,6 +642,19 @@ error =3D soconnect2(so2, so1); if (error) goto free4; + } else if (type =3D=3D SOCK_STREAM) { + struct unpcb *unp, *unp2; + unp =3D sotounpcb(so1); + unp2 =3D sotounpcb(so2); + UNP_PCB_LOCK(unp); + UNP_PCB_LOCK(unp2); + cru2x(td->td_ucred, &unp->unp_peercred); + memcpy(&unp2->unp_peercred, &unp->unp_peercred, + sizeof(unp2->unp_peercred)); + unp->unp_flags |=3D UNP_HAVEPC; + unp2->unp_flags |=3D UNP_HAVEPC; + UNP_PCB_UNLOCK(unp); + UNP_PCB_UNLOCK(unp2); } finit(fp1, FREAD | FWRITE, DTYPE_SOCKET, fp1->f_data, &socketops); finit(fp2, FREAD | FWRITE, DTYPE_SOCKET, fp2->f_data, &socketops); I've not looked into the FreeBSD kernel before, so the patch may be useless! I think conceptually it's the right place to put it though. unix.4.man and getpeereid.3.man would have to be updated also. Best wishes, Nicholas ----- Nicholas Wilson: nicholas@nicholaswilson.me.uk Site and blog: www.nicholaswilson.me.uk 6 Tribune Court, CB4 2TU 07845=E2=80=AF182898 From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 15:44:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01C7D854; Thu, 21 Feb 2013 15:44:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 50442EA1; Thu, 21 Feb 2013 15:44:45 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1LFiYXN039698; Thu, 21 Feb 2013 17:44:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1LFiYXN039698 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1LFiXAl039697; Thu, 21 Feb 2013 17:44:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Feb 2013 17:44:33 +0200 From: Konstantin Belousov To: Damjan Jovanovic Subject: Re: [patch] Wine DLL base address patches Message-ID: <20130221154433.GY2598@kib.kiev.ua> References: <20130220154855.GF2598@kib.kiev.ua> <51253759.70508@coosemans.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/TIhMU+9tW3Jkwla" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Tijl Coosemans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:44:46 -0000 --/TIhMU+9tW3Jkwla Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2013 at 12:57:45AM +0200, Damjan Jovanovic wrote: > On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans wro= te: > > On 20-02-2013 16:48, Konstantin Belousov wrote: > >> On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: > >>> Hi > >>> > >>> Wine needs some of its libraries to be loaded at specific base > >>> addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently > >>> lacks. > >>> > >>> I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that > >>> loads libraries at their preferred base addresses > >>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176216), as well as a p= ort > >>> of Prelink to FreeBSD which Wine uses to set base addresses > >>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176283). Both work :-), > >>> the changed dynamic loader doesn't show any problems in a few days of > >>> testing, and prelink works with the --reloc-only option as used by > >>> Wine. > >>> > >>> Please review/test/comment/commit. > >> > >> Unfortunately, it is not safe. MAP_FIXED overrides any previous mappin= gs > >> which could exist at the specified address. > > > > I've simplified the rtld patch to a single line. The second patch makes > > Wine use -Ttext-segment linker flag instead of prelink. This requires > > binutils from ports, but it's easier than porting prelink. > > >=20 > All of that occurred to me as well. >=20 > The problem with that one-line rtld patch is that loading an > application will now fail if any of its libraries cannot be loaded at > their requested address. But this is intended behaviour. Also, the default virtaddr base for the shared libraries is 0, so the existing binaries should be not affected. >=20 > The problem with -Ttext-segment (and isn't it just -Ttext?) is that it > doesn't seem to work: the base_vaddr seen by rtld will remain 0, and > the address listed in /proc/.../map is different from what it should > be. Also run "readelf -l" on a library compiled that way and compare > with the output of one run through "prelink --reloc-only", you'll see > the lowest VirtAddr and PhysAddr in LOAD headers change only with > prelink. I really ported prelink because there was no other choice. The -Ttext-segment does work. As indicated by Tijl, you need recent binutils. I just verified that ld 2.32.1 obeys -Ttext-segment. You can also take a look at the default linker script to see how -Ttext-segment is used, look for SEGMENT_START("text-segment"). >=20 > See my attached test cases, and examine the contents of /proc/.../map > while they run. --/TIhMU+9tW3Jkwla Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJkDhAAoJEJDCuSvBvK1BKgcQAJAGi3YIrhLO5X1hPmFxn5Ju NpRg/BqS3HHb1U3r5DaR1Vr3M/6ACmx6ZQIySHpTysADdwqPw3b3k+mtSl8bOfmW 45XQWn1jgiYJ22PiCoVTYF8DJFWZ+2onLJuevJ+xRielZx2Pz1KTztc+IhXY6PUv NXZ+1/zINvt0e8bFwVt9WLdazAj15/FRmDkKSRf+oKlq5YMsbqAppv7UZRDqUhsI AdsbVEbilLIfuqPuR+M9+iJMaIt5oF3InHwX6msy15dEnn/xdI6d3fMcyhdkp+nP rC+LT1ggD+TQaAXH1LqZTZfPCSS9mv7NhqCYaUemKjZbeVsIZU+P4p+tWWqjdBQd qEyEctToB6ONkptqZ2tqiPaN3OopVEdJzrab4Ovgfy0a62lBfiXcTKEQZgL2ezGW UpLItTHWt+lwcG+dLCECKPnzH4v79Kz9sIYcDn1J3gJ0rx1l2jobwaMQymspUK6z 70V5aVZ4OE2xFPTYabl6YAVDzRvtO7bhOubM11GHlv1+WVwPRQwb4dpebGKzASd3 oe/Uuy4GJCr0ZwGEMovtSP3XowVDCJ69o/G3MJCAhL4ztd4+6hQgnN+ytNDvdzVA EsOT+WKf/USCUA5CXsdaExnDPeY5AtryQ6E0g0cr/5phJbizEmVqT5VQs7FhZEi4 2L9nvFIcKb185sYmMtb+ =76XR -----END PGP SIGNATURE----- --/TIhMU+9tW3Jkwla-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 16:22:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C02611BA for ; Thu, 21 Feb 2013 16:22:14 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3250B254 for ; Thu, 21 Feb 2013 16:22:13 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1LGM2Pe067902 for ; Thu, 21 Feb 2013 17:22:02 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1LGM2XE067899 for ; Thu, 21 Feb 2013 17:22:02 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 21 Feb 2013 17:22:02 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: blocking teamviewer trojan Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 21 Feb 2013 17:22:02 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:22:14 -0000 anyone have tested method on doing this? tried blocking port 5938 as well as teamviewer.com domain in squid (and all port 80 traffic is already forwarded to squid). Still doesn't work. thanks for any help. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 17:08:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 63C777BD for ; Thu, 21 Feb 2013 17:08:28 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 320BB7AA for ; Thu, 21 Feb 2013 17:08:28 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 10so11643913ied.30 for ; Thu, 21 Feb 2013 09:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sLeI+9cB4gEAwLFR+OtvP/W3y7ro+EUZRbcadN/2ThE=; b=HGQ8WDlTFJmlDLroghw4GClI+sXFbaNGGB5dYCFkegg8CP909SRgeV25mAW/EjB6qN E34SoP6Cfk+hSip1RaV8jfT0RUKiEyoXUWVUwYlS6omnBQtUo4mt9+2hCIs14rB8rIur 1fRfRKnAULAHgtwUBbFVXojjWi9lR3H/OC8zu32JZQ01g/qwa7qrnUtFjTyhN0sVAN59 22No9PyrzbW9+Frq6AG0pDpVsWq5Vfmgv++4esfVGY807XM/jNMEEO+39kWGFYcD2hNk mQ7qQpkbXyfwxvWP4c6hIMn1Hsg5OvovzXJOUrIYrbJ5rI/tuittQuvwLzEnsY+TsLHs iZBw== MIME-Version: 1.0 X-Received: by 10.42.121.14 with SMTP id h14mr11202615icr.27.1361466507833; Thu, 21 Feb 2013 09:08:27 -0800 (PST) Received: by 10.64.63.12 with HTTP; Thu, 21 Feb 2013 09:08:27 -0800 (PST) Received: by 10.64.63.12 with HTTP; Thu, 21 Feb 2013 09:08:27 -0800 (PST) In-Reply-To: References: Date: Thu, 21 Feb 2013 17:08:27 +0000 Message-ID: Subject: Re: blocking teamviewer trojan From: Chris Rees To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:08:28 -0000 On 21 Feb 2013 16:22, "Wojciech Puchar" wrote: > > anyone have tested method on doing this? > > tried blocking port 5938 as well as teamviewer.com domain in squid (and all port 80 traffic is already forwarded to squid). > > Still doesn't work. > > thanks for any help. You would have better luck on a Windows security list. This list is for development of FreeBSD. Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 18:04:40 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BE2C41E for ; Thu, 21 Feb 2013 18:04:40 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-we0-x234.google.com (we-in-x0234.1e100.net [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 3CC3FCD2 for ; Thu, 21 Feb 2013 18:04:40 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id k14so7638991wer.39 for ; Thu, 21 Feb 2013 10:04:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=jPHmJec2uLU7IHAAGwb3se68jQK7qGk/UIAc7sCnJvc=; b=In8tETLEon+rzqVDa5wRVAXIlCF4r6MnTxgllIWvYmFFAK7O/7NTySM9CCHStxu+x4 7yuZzkLlYWJgDYfxAB5+h4Hsri2ibxaqg1mghNddqnFKicGrz3ziLBK15xRdIPUmhei3 hcFVzttx7Me9ZbN418Y7n2slb6JFaRrSMUPe3TFBW/pXY+N7v6XeseMAUtsemOwRjieR kuwkGILDGOyCvxOByxXFalyPSmbm4iehpIpyRie1Qw5TxhjrB8Te7+++hOn5GpacYPrx U16nNT4yYFLBPzRuLAq7oG+lkroK//K4FuSBDKvqw97Rp2FJG9rCf1Jh10i+vuNIglqX 7x6w== MIME-Version: 1.0 X-Received: by 10.180.103.65 with SMTP id fu1mr24480066wib.4.1361469879343; Thu, 21 Feb 2013 10:04:39 -0800 (PST) Received: by 10.216.105.1 with HTTP; Thu, 21 Feb 2013 10:04:39 -0800 (PST) X-Originating-IP: [209.66.78.50] Date: Thu, 21 Feb 2013 13:04:39 -0500 Message-ID: Subject: Question on timecounter hardware / What cpu flag is constant_tsc From: Mark Saad To: "freebsd-hackers@freebsd.org" X-Gm-Message-State: ALoCoQmasV3lj0EcIc972xdrUmreRLdsVk/eX/Dns0t437MvOq68yatxZDZMFCk6oegypq8skMzX Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 18:04:40 -0000 All I am looking into an issue with timecounter hardware on a number of HP DL165 G7's They all run FreeBSD 9.1-RELEASE and all have the same CPU and firmware. However they report strange results when you probe kern.timecounter.choice and kern.timecounter.hardware Take this example ssh root@ssr4 "sysctl kern.timecounter.choice" kern.timecounter.choice: TSC-low(-100) ACPI-safe(850) HPET(950) i8254(0) dummy(-1000000) ssh root@ssr4 "sysctl kern.timecounter.hardware" kern.timecounter.hardware: HPET dmidecode -s processor-version AMD Opteron(TM) Processor 6212 dmidecode -s processor-frequency 2600 MHz Unknown from dmesg.boot CPU: AMD Opteron(TM) Processor 6212 (2600.06-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 15 Model = 1 Stepping = 2 Features=0x178bfbff Features2=0x1e98220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> vs ssh root@ssr3 "sysctl kern.timecounter.choice" kern.timecounter.choice: TSC-low(1000) ACPI-safe(850) HPET(950) i8254(0) dummy(-1000000) ssh root@ssr3 "sysctl kern.timecounter.hardware" kern.timecounter.hardware: TSC-low dmidecode -s processor-version AMD Opteron(TM) Processor 6212 dmidecode -s processor-frequency 2600 MHz Unknown from dmesg.boot CPU: AMD Opteron(TM) Processor 6212 (2600.06-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 15 Model = 1 Stepping = 2 Features=0x178bfbff Features2=0x1e98220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> So my questions, what is the preferred time counter here ? In linux using TSC is preferred over hpet and to tell if you have a trusted TSC your cpu needs to support feature constant_tsc . Does anyone know what cpu feature this is; is it listed in my a fore mentioned dmesg.boot feature lists ? TIA -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 18:34:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2217DDB for ; Thu, 21 Feb 2013 18:34:19 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 98890F40 for ; Thu, 21 Feb 2013 18:34:19 +0000 (UTC) Received: from [89.204.139.185] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U8ayB-0005Ya-Ba for freebsd-hackers@freebsd.org; Thu, 21 Feb 2013 19:34:11 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id r1LIY9De001359 for ; Thu, 21 Feb 2013 19:34:10 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id r1LIY9Mx001358 for freebsd-hackers@freebsd.org; Thu, 21 Feb 2013 19:34:09 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Thu, 21 Feb 2013 19:34:08 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: Re: blocking teamviewer trojan Message-ID: <20130221183408.GA1161@tiny.Sisis.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.139.185 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 18:34:19 -0000 El día Thursday, February 21, 2013 a las 05:22:02PM +0100, Wojciech Puchar escribió: > anyone have tested method on doing this? > > tried blocking port 5938 as well as teamviewer.com domain in squid (and > all port 80 traffic is already forwarded to squid). > > Still doesn't work. What the h... is a teamviewer troyan and how it is related to our beloved FreeBSD? matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: guru@unixarea.de | - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | - No proprietary attachments phone: +49-170-4527211 | - Respect for open standards From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 18:53:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 571D6921 for ; Thu, 21 Feb 2013 18:53:46 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id E825C13D for ; Thu, 21 Feb 2013 18:53:45 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t44so7779950wey.26 for ; Thu, 21 Feb 2013 10:53:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=r4KVZFYpSQre9MkIM6LRfsFHdiC5BDU2m3/Em6X0YEo=; b=DVg7wwK+08pSh814zpnp6dC5EcFj4M1Me7WHJ2vsn/+3HYB/gK7USUTFOsVXfZtNTa gafYsXSDnkoCOqET/1nHC2wICNBBlyNFelRJa8OSL9P2r+ZD+0zbuhh7pq38VWlRdxNb Viv/a+nOZp47EWyFPyzmlr4E9aJe4cFSV0fJcm8HkAspX/SNDaJte7QRvSqjNm4oGDI7 M0dUC8DilFDdCXJn90eFQBigviud2+bfVHbwfqMgQJxEHQ6GqDCs8S/ZR+jUQ6Z+fwHj VCiu0fiKhVD0dvJF4NBDOg9o8k3F6Dajzo3oUDZ4DU/jCSyA8uDD/Ssz4CgvO88GQqlT Noig== MIME-Version: 1.0 X-Received: by 10.180.91.106 with SMTP id cd10mr25219587wib.6.1361472825086; Thu, 21 Feb 2013 10:53:45 -0800 (PST) Received: by 10.216.105.1 with HTTP; Thu, 21 Feb 2013 10:53:44 -0800 (PST) X-Originating-IP: [209.66.78.50] In-Reply-To: References: <512516A7.2060604@delphij.net> Date: Thu, 21 Feb 2013 13:53:44 -0500 Message-ID: Subject: Re: SA-13:02/libc and FreeBSD 6 From: Mark Saad To: "freebsd-hackers@freebsd.org" X-Gm-Message-State: ALoCoQnk5SmNSYhsZRvKks9kHWwetBkkbCX2f2UFfvbhifEghdBwgFpz/gT+nw/CDPdKnyhzKbPI Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 18:53:46 -0000 All So Xin's patch works so far I see no unexpected issues; can I get a MFC ? Also on a unrelated MFC request would someone be willing to merge stable/7/sys/netinet/tcp_input.c r246999 into 6-STABLE . This cleanly applied and I saw no issues. On Wed, Feb 20, 2013 at 6:18 PM, Adrian Chadd wrote: > On 20 February 2013 12:01, Mark Saad wrote: > > Xin > > I am rebuilding now, I'll let you know how it works. > > As I've said before, if someone wants to take ownership of 6.x and > backport changes / push them into STABLE_6, be my guest. Yahoo was > doing that for some unsupported old releases for a while. > > They'd still stay unsupported.. well, as long as there's not a big > group of 6.x users standing up and taking ownership. > > (Same can be said of what's going to happen to 7.x soon.) > > > > Adrian > -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 19:59:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A95C85D for ; Thu, 21 Feb 2013 19:59:09 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id D8C82789 for ; Thu, 21 Feb 2013 19:59:08 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1LJx6uo046124; Thu, 21 Feb 2013 20:59:06 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1LJx6gE046121; Thu, 21 Feb 2013 20:59:06 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 21 Feb 2013 20:59:06 +0100 (CET) From: Wojciech Puchar To: Chris Rees Subject: Re: blocking teamviewer trojan In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 21 Feb 2013 20:59:06 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:59:09 -0000 sorry for polluting a list. i've got somewhat worried about general human stupidity. On Thu, 21 Feb 2013, Chris Rees wrote: > > > On 21 Feb 2013 16:22, "Wojciech Puchar" wrote: > > > > anyone have tested method on doing this? > > > > tried blocking port 5938 as well as teamviewer.com domain in squid (and all port 80 traffic is already forwarded to squid). > > > > Still doesn't work. > > > > thanks for any help. > > You would have better luck on a Windows security list. > > This list is for development of FreeBSD. > > Chris > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 20:00:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B891294F for ; Thu, 21 Feb 2013 20:00:05 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ia0-x230.google.com (ia-in-x0230.1e100.net [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 8BE1279E for ; Thu, 21 Feb 2013 20:00:05 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so8349188iac.7 for ; Thu, 21 Feb 2013 12:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=NtJfz8r2EI0ahYkoIYjMHJUhE/wvKn9Weak8SH6AOJU=; b=Y7hPal66Pb7HNqph5m0IAnqDXyruVNie9ix7qc2bNUHUm2sGalIo8tG9pafoFA8IeQ EkPBYqF7oCqTQi5JB7f0QnXzOcT/p00DmI9xY2oQWf/uHZdiEelOemaAPJtBvHsdWwE2 zRAdslCcwUS1SaFFPnCVa0oKtVH8PeN1TqJ8dz9YJsxdJkTc3ivNRAqG48gFZwnXXjnE xDmEraYc2oKBxjJtfO4/t7P64ReXYMosSLphDsVqMFRbC2iwc+Tj2ZR4lkIcNk6nWozW KVnJsSPKAttwHEPR6XVkK3OY6lP4ALTPuJvu0tTbmiDeHaCGAupa5O5FZhsb3fqwene2 qfTg== X-Received: by 10.50.42.129 with SMTP id o1mr8207824igl.32.1361476804513; Thu, 21 Feb 2013 12:00:04 -0800 (PST) Received: from oddish.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPS id 3sm252107igp.9.2013.02.21.12.00.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 12:00:03 -0800 (PST) Sender: Mark Johnston Date: Thu, 21 Feb 2013 14:59:48 -0500 From: Mark Johnston To: Mark Saad Subject: Re: SA-13:02/libc and FreeBSD 6 Message-ID: <20130221194847.GA4825@oddish.sandvine.com> References: <512516A7.2060604@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:00:05 -0000 On Thu, Feb 21, 2013 at 01:53:44PM -0500, Mark Saad wrote: > All > So Xin's patch works so far I see no unexpected issues; can I get a MFC ? > Also on a unrelated MFC request would someone be willing to merge > stable/7/sys/netinet/tcp_input.c r246999 into 6-STABLE . This cleanly > applied and I saw no issues. > I can do the latter MFC later today if no one has any objections. > > > On Wed, Feb 20, 2013 at 6:18 PM, Adrian Chadd wrote: > > > On 20 February 2013 12:01, Mark Saad wrote: > > > Xin > > > I am rebuilding now, I'll let you know how it works. > > > > As I've said before, if someone wants to take ownership of 6.x and > > backport changes / push them into STABLE_6, be my guest. Yahoo was > > doing that for some unsupported old releases for a while. > > > > They'd still stay unsupported.. well, as long as there's not a big > > group of 6.x users standing up and taking ownership. > > > > (Same can be said of what's going to happen to 7.x soon.) > > > > > > > > Adrian > > > > > > -- > mark saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 20:22:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6AA22322 for ; Thu, 21 Feb 2013 20:22:06 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 559998D0 for ; Thu, 21 Feb 2013 20:22:06 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id A2C1C24C92; Thu, 21 Feb 2013 12:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361478120; bh=9kWlpQ39HU2jbgaMY10TyuAGde9C8ecURyrPyiUbtP4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=CqmZ+vGHtswiee6rEavLXXuSjPIRWzq8zmOvbWE7Unpg34gYwE7Z8kZeX9geBmiz+ mdyKMMrRwy545nb2lmMxi3TMmS51AvQsviI2Wvwz/20txQwzkEQeTqie0aUCUbkgVJ FWbkjx5Xd12F0WQXFNHAcylXgRbu/zIdqrL/Fz2k= Message-ID: <512681E6.6010900@delphij.net> Date: Thu, 21 Feb 2013 12:21:58 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Mark Saad Subject: Re: SA-13:02/libc and FreeBSD 6 References: <512516A7.2060604@delphij.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:22:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/21/13 10:53, Mark Saad wrote: > All So Xin's patch works so far I see no unexpected issues; can I > get a MFC ? Also on a unrelated MFC request would someone be > willing to merge stable/7/sys/netinet/tcp_input.c r246999 into > 6-STABLE . This cleanly applied and I saw no issues. Thanks for confirming, I'll MFC the changes asap. > > On Wed, Feb 20, 2013 at 6:18 PM, Adrian Chadd > wrote: > >> On 20 February 2013 12:01, Mark Saad >> wrote: >>> Xin I am rebuilding now, I'll let you know how it works. >> >> As I've said before, if someone wants to take ownership of 6.x >> and backport changes / push them into STABLE_6, be my guest. >> Yahoo was doing that for some unsupported old releases for a >> while. >> >> They'd still stay unsupported.. well, as long as there's not a >> big group of 6.x users standing up and taking ownership. >> >> (Same can be said of what's going to happen to 7.x soon.) >> >> >> >> Adrian >> > > > - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRJoHmAAoJEG80Jeu8UPuzxhoIALGAOjkBM5zSiHrvY8QNos+9 CgGOA4TVldVl6uru3ZmJhxXmHuiBc5RGnnY8tJ8wzh9QfBhIRmcj7uEhBPj29P+Y WkaUkyvCfNc1Eg2tLV+RkQWR6mWvJs1thSZ/sOllAEMrvPvniFJrlzE3marGHXvK D6zHtKRc2LORiwa0MkuUa49HjZyTspgEfz73VRwXur8ERdJqjCGZLFOOmgIyQ+rW 3bRXry0MnUN/hHnrs0jAN2OB69gEhpQb/rJnYT4WeR0tAzPxvVLgTzkf6LILmBw9 BIXOCIwWMPZJTKTsSc/2R09rK3Cur2ZhIpUDw2gNqiSZXBFyEmQDqWp5V4wd4M4= =WSgz -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 21:35:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C50AB679; Thu, 21 Feb 2013 21:35:38 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id CFDE7D98; Thu, 21 Feb 2013 21:35:36 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 54179D48047; Thu, 21 Feb 2013 22:35:29 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 3F7199F7; Thu, 21 Feb 2013 22:35:28 +0100 (CET) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 3A09F13AA9; Thu, 21 Feb 2013 21:35:28 +0000 (UTC) Date: Thu, 21 Feb 2013 22:35:28 +0100 From: Jeremie Le Hen To: Damjan Jovanovic Subject: Re: [patch] Wine DLL base address patches Message-ID: <20130221213528.GD92116@felucia.tataz.chchile.org> Mail-Followup-To: Damjan Jovanovic , freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org, tijl@coosemans.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, tijl@coosemans.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 21:35:38 -0000 Hi Damjan, On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: > > Wine needs some of its libraries to be loaded at specific base > addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently > lacks. > > I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that > loads libraries at their preferred base addresses > (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port > of Prelink to FreeBSD which Wine uses to set base addresses > (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-), > the changed dynamic loader doesn't show any problems in a few days of > testing, and prelink works with the --reloc-only option as used by > Wine. Thanks for this work. Out of curiosity, did you try to run prelink on the whole base system? If yes, did you make any measurement of the performance improvement? Thank you! -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 22:00:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 433B2941 for ; Thu, 21 Feb 2013 22:00:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id F327AF23 for ; Thu, 21 Feb 2013 22:00:50 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 10so21652ied.2 for ; Thu, 21 Feb 2013 14:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=SVLaCLFGGxRIN3zGPl13b/gztfW0vgE+0Z3d3qlOq6w=; b=ZcjChBnfOOhZIv8FYJ+UrQglv0HxzxF0s4Pzk+tYClo4KzpaDf0rO3GY5eAybjX6x9 2PLQ9Jg9+RIVgvgIO/GFiWm+o5VZ+X4+z3VVtW4D06owYdEHqvQ4JTHpNhyF7+WD9BBn jhL8kNjmD6HgU/nNHdvqMyYqN4MNNz0m3kH1XAibCTRp42Jy0HnqhwphWa+PvzW7YGbU xWCtupksq5iwWm8jtNcJHmeUzYw05SOGqTQ86F/jE4Mes5a4TLiPIDfXorCF82EV/9YG +DTPoaQFFgP3IIZ1vTvQyrTu2o8pClMetM+86GVeZawIqcBTPf9Knq8UsbG3XcRAVIPI FQSw== X-Received: by 10.50.76.168 with SMTP id l8mr13627370igw.97.1361484050707; Thu, 21 Feb 2013 14:00:50 -0800 (PST) Received: from oddish.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPS id ww6sm674805igb.2.2013.02.21.14.00.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 14:00:49 -0800 (PST) Sender: Mark Johnston Date: Thu, 21 Feb 2013 17:00:34 -0500 From: Mark Johnston To: Mark Saad Subject: Re: SA-13:02/libc and FreeBSD 6 Message-ID: <20130221220034.GA73878@oddish.sandvine.com> References: <512516A7.2060604@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:00:51 -0000 On Thu, Feb 21, 2013 at 01:53:44PM -0500, Mark Saad wrote: > All > So Xin's patch works so far I see no unexpected issues; can I get a MFC ? > Also on a unrelated MFC request would someone be willing to merge > stable/7/sys/netinet/tcp_input.c r246999 into 6-STABLE . This cleanly > applied and I saw no issues. The tcp_input.c change was merged as r247136. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 22:15:59 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2CDF5FC9 for ; Thu, 21 Feb 2013 22:15:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id F3BC7FF0 for ; Thu, 21 Feb 2013 22:15:58 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n12so23632oag.27 for ; Thu, 21 Feb 2013 14:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=agMl34Dirz7VgnCG+iQVaCWBSuC87j1lzPkjEML/HCo=; b=onJTY+o0ov0UJZ789q5j30jxDhBt+6pIVGmlzK+SW+pVkz2tGf9K5vv6ubLQzUlING uL/ByqMSLPPv5wvibgppcgL4FtUT3DEN3fy8YLWE+qf5rOHkIwLnSa4Zz3bfy4bs3GT2 HVpNYXnRWqYxe+NlpOjxvAksKh+9TMHut5jUSBYbwp26cIoqWA08Pws/8YG15lPpWt6Y xQLR7wE6NdTLwZrG2FZ3VgQDOCvrM2pJlU2ENmQWmE3BuPAWwGn1z0IPLRwqzDTL12mt E79qd3x6ZoDm1Qby+u/bN+CO3VZN8va0y0GdggBwcP9kgQVqRrQ0gtvhS3L+sPKuXOaO QZ2Q== MIME-Version: 1.0 X-Received: by 10.182.112.34 with SMTP id in2mr11700378obb.80.1361484644876; Thu, 21 Feb 2013 14:10:44 -0800 (PST) Received: by 10.76.109.236 with HTTP; Thu, 21 Feb 2013 14:10:44 -0800 (PST) Date: Thu, 21 Feb 2013 17:10:44 -0500 Message-ID: Subject: intr_event_handle never sends EOI if we fail to schedule ithread From: Ryan Stone To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:15:59 -0000 I recently saw an issue where all interrupts from a particular interrupt vector were never raised. After investigating it appears that I ran into the bug fixed in r239095[1], where an interrupt handler that uses an ithread was added to the list of interrupt handlers for a particular event before the ithread was allocated. If an interrupt for this event (presumably for a different device sharing the same interrupt line) comes in after the handler is added to the list but before the ithread has been allocated we hit the following code: if (thread) { if (ie->ie_pre_ithread != NULL) ie->ie_pre_ithread(ie->ie_source); } else { if (ie->ie_post_filter != NULL) ie->ie_post_filter(ie->ie_source); } /* Schedule the ithread if needed. */ if (thread) { error = intr_event_schedule_thread(ie); #ifndef XEN KASSERT(error == 0, ("bad stray interrupt")); #else if (error != 0) log(LOG_WARNING, "bad stray interrupt"); #endif } thread is true, so we will not run ie_post_filter (which would send the EOI). However because the ithread has not been allocated intr_event_schedule_thread will return an error. If INVARIANTS is not defined we skip the KASSERT and return. Now, r239095 fixes this scenario, but I think that we should call ie_post_filter whenever intr_event_schedule_thread fails to ensure that we don't block an interrupt vector indefinitely. Any comments? [1] http://svnweb.freebsd.org/base?view=revision&revision=239095 From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 22:22:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AC76403; Thu, 21 Feb 2013 22:22:14 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay003.isp.belgacom.be (mailrelay003.isp.belgacom.be [195.238.6.53]) by mx1.freebsd.org (Postfix) with ESMTP id BEFFFE2; Thu, 21 Feb 2013 22:22:13 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAG2dJlFbs5l5/2dsb2JhbABFwRKBBRdzgh8BAQVWGAoBEAsOCgkWDwkDAgECASceBgEMAQUCAQEFiA0IvyGPDgeDQAOPHoElllGDCA Received: from 121.153-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.153.121]) by relay.skynet.be with ESMTP; 21 Feb 2013 23:20:43 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.6/8.14.6) with ESMTP id r1LMKg9M006426; Thu, 21 Feb 2013 23:20:42 +0100 (CET) (envelope-from tijl@coosemans.org) Message-ID: <51269DB3.2070603@coosemans.org> Date: Thu, 21 Feb 2013 23:20:35 +0100 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: Konstantin Belousov , Damjan Jovanovic Subject: Re: [patch] Wine DLL base address patches References: <20130220154855.GF2598@kib.kiev.ua> <51253759.70508@coosemans.org> <20130221154433.GY2598@kib.kiev.ua> In-Reply-To: <20130221154433.GY2598@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF08F74E68299AB2CD11F700A" Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:22:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF08F74E68299AB2CD11F700A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21-02-2013 16:44, Konstantin Belousov wrote: > On Thu, Feb 21, 2013 at 12:57:45AM +0200, Damjan Jovanovic wrote: >> On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans = wrote: >>> On 20-02-2013 16:48, Konstantin Belousov wrote: >>>> On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: >>>>> Hi >>>>> >>>>> Wine needs some of its libraries to be loaded at specific base >>>>> addresses (https://wiki.freebsd.org/Wine), something FreeBSD curren= tly >>>>> lacks. >>>>> >>>>> I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) t= hat >>>>> loads libraries at their preferred base addresses >>>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176216), as well as a= port >>>>> of Prelink to FreeBSD which Wine uses to set base addresses >>>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D176283). Both work :-= ), >>>>> the changed dynamic loader doesn't show any problems in a few days = of >>>>> testing, and prelink works with the --reloc-only option as used by >>>>> Wine. >>>>> >>>>> Please review/test/comment/commit. >>>> >>>> Unfortunately, it is not safe. MAP_FIXED overrides any previous mapp= ings >>>> which could exist at the specified address. >>> >>> I've simplified the rtld patch to a single line. The second patch mak= es >>> Wine use -Ttext-segment linker flag instead of prelink. This requires= >>> binutils from ports, but it's easier than porting prelink. >>> >> >> All of that occurred to me as well. >> >> The problem with that one-line rtld patch is that loading an >> application will now fail if any of its libraries cannot be loaded at >> their requested address. > But this is intended behaviour. Also, the default virtaddr base for the= > shared libraries is 0, so the existing binaries should be not affected.= >=20 >> >> The problem with -Ttext-segment (and isn't it just -Ttext?) is that it= >> doesn't seem to work: the base_vaddr seen by rtld will remain 0, and >> the address listed in /proc/.../map is different from what it should >> be. Also run "readelf -l" on a library compiled that way and compare >> with the output of one run through "prelink --reloc-only", you'll see >> the lowest VirtAddr and PhysAddr in LOAD headers change only with >> prelink. I really ported prelink because there was no other choice. > The -Ttext-segment does work. As indicated by Tijl, you need recent > binutils. I just verified that ld 2.32.1 obeys -Ttext-segment. >=20 > You can also take a look at the default linker script to see how > -Ttext-segment is used, look for SEGMENT_START("text-segment"). Yes, -Ttext sets the address of the .text section and -Ttext-segment that of the text segment. It does work for me. The output of /proc/.../ma= p looks correct as does the output of "info share" in winedbg, but to be sure I've asked on wine-devel mailing list if they see any problem with this approach. --------------enigF08F74E68299AB2CD11F700A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iF4EAREIAAYFAlEmnbkACgkQfoCS2CCgtiuqEgD8CK7u+iaYSadNZnZE7cQSc87a YvdFZnnS/TY6Ny+j40oA/3AREjS15QyntDDo+E+1v2sxuqkYhBCzteaRtAJnyeNV =KKZp -----END PGP SIGNATURE----- --------------enigF08F74E68299AB2CD11F700A-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 03:19:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E0D496C; Fri, 22 Feb 2013 03:19:58 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-la0-x22d.google.com (la-in-x022d.1e100.net [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 515AE164; Fri, 22 Feb 2013 03:19:57 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id er20so194404lab.4 for ; Thu, 21 Feb 2013 19:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=JlLvC+nxR8zbR2y3F7fyMqF8yQ1IOKkZvdEr8S0v5H8=; b=S9DUfDlrMIcbxw1FpwNY09qqzz4nvq3eRK5MVA7bsQj19wTXiVKuRkui1azXYp6xU/ W4CO8wWZ1sSPSj+xmggDn8jR/JvaUSxtCLTz7CD3BzII79hilWDGmbsJTzsEjmepig+d sPh8KqPiujd7166x+94VoSkARkKoRLNHgUjczsrnJZ14/clH2341628Bg427GVM7GC01 1F99qrDK2/HgAei58Q/ZpuJBjTeopSvSTm6XMprmpxLVh5GIghTXd4HoBX3mKN4iTec7 cgMGMHwZ/zc5LwbjVQZYAu6YoS29J0kjjTas9PWEZpPheW3uR9aYSXBhcLtUc5r8ku2B 2QRQ== X-Received: by 10.152.108.203 with SMTP id hm11mr376132lab.4.1361503195441; Thu, 21 Feb 2013 19:19:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.20.138 with HTTP; Thu, 21 Feb 2013 19:19:35 -0800 (PST) In-Reply-To: <20130221154433.GY2598@kib.kiev.ua> References: <20130220154855.GF2598@kib.kiev.ua> <51253759.70508@coosemans.org> <20130221154433.GY2598@kib.kiev.ua> From: Damjan Jovanovic Date: Fri, 22 Feb 2013 05:19:35 +0200 Message-ID: Subject: Re: [patch] Wine DLL base address patches To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Tijl Coosemans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:19:58 -0000 On Thu, Feb 21, 2013 at 5:44 PM, Konstantin Belousov wrote: > On Thu, Feb 21, 2013 at 12:57:45AM +0200, Damjan Jovanovic wrote: >> On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans wrote: >> > On 20-02-2013 16:48, Konstantin Belousov wrote: >> >> On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote: >> >>> Hi >> >>> >> >>> Wine needs some of its libraries to be loaded at specific base >> >>> addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently >> >>> lacks. >> >>> >> >>> I've written a patch to the dynamic loader (/libexec/ld-elf.so.1) that >> >>> loads libraries at their preferred base addresses >> >>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=176216), as well as a port >> >>> of Prelink to FreeBSD which Wine uses to set base addresses >> >>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=176283). Both work :-), >> >>> the changed dynamic loader doesn't show any problems in a few days of >> >>> testing, and prelink works with the --reloc-only option as used by >> >>> Wine. >> >>> >> >>> Please review/test/comment/commit. >> >> >> >> Unfortunately, it is not safe. MAP_FIXED overrides any previous mappings >> >> which could exist at the specified address. >> > >> > I've simplified the rtld patch to a single line. The second patch makes >> > Wine use -Ttext-segment linker flag instead of prelink. This requires >> > binutils from ports, but it's easier than porting prelink. >> > >> >> All of that occurred to me as well. >> >> The problem with that one-line rtld patch is that loading an >> application will now fail if any of its libraries cannot be loaded at >> their requested address. > But this is intended behaviour. Also, the default virtaddr base for the > shared libraries is 0, so the existing binaries should be not affected. In that case, and since failing to load a library only causes the process to exit when starting up and not when it calls dlopen(), I approve. >> >> The problem with -Ttext-segment (and isn't it just -Ttext?) is that it >> doesn't seem to work: the base_vaddr seen by rtld will remain 0, and >> the address listed in /proc/.../map is different from what it should >> be. Also run "readelf -l" on a library compiled that way and compare >> with the output of one run through "prelink --reloc-only", you'll see >> the lowest VirtAddr and PhysAddr in LOAD headers change only with >> prelink. I really ported prelink because there was no other choice. > The -Ttext-segment does work. As indicated by Tijl, you need recent > binutils. I just verified that ld 2.32.1 obeys -Ttext-segment. > > You can also take a look at the default linker script to see how > -Ttext-segment is used, look for SEGMENT_START("text-segment"). > My apologies: I confused -Ttext which is documented but doesn't work, with -Ttext-segment which is undocumented in FreeBSD 9.1 and might work. I would test it further, but -CURRENT doesn't installworld (ERROR: Required auditdistd user is missing, see /usr/src/UPDATING.) and I am away until next week. Prelink is now in Ports. What I'd recommend is checking if the binaries are the same, and if not, doing a diff between "readelf -a" outputs of the prelinked binary vs -Ttext-segmented binary. Also run this a few times and make sure the address is what's expected: #include #include int main(int argc, char **argv) { printf("%p\n", LoadLibrary("KERNEL32")); return 0; } mingw32-gcc hello.c -o hello.exe wine hello.exe From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 13:36:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B3B8D15 for ; Fri, 22 Feb 2013 13:36:45 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 46999FC1 for ; Fri, 22 Feb 2013 13:36:45 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8snq-0000La-8Q for freebsd-hackers@freebsd.org; Fri, 22 Feb 2013 14:36:44 +0100 Message-ID: <5127746A.6060702@dumbbell.fr> Date: Fri, 22 Feb 2013 14:36:42 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Building a program to be used only during make buildkernel X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QQGCMJQIJUMDJOLBLCUK" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:36:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QQGCMJQIJUMDJOLBLCUK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, During the build of the "radeon" DRM driver in Linux, a C program is first built to generate headers included by the driver. The program is not meant to be installed. In FreeBSD, how would one build and use such a program during the build of a kernel module? And what if the driver is built into the kernel inste= ad? --=20 Jean-S=E9bastien P=E9dron ------enig2QQGCMJQIJUMDJOLBLCUK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEndGoACgkQa+xGJsFYOlMB9ACfUByhwPdqtj5lZpfXpFOWuwRo QLIAnjqs2dSg6aaLaGvtjwakN08gTVyw =BvOB -----END PGP SIGNATURE----- ------enig2QQGCMJQIJUMDJOLBLCUK-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 16:55:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9431A1DE for ; Fri, 22 Feb 2013 16:55:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5C5B60 for ; Fri, 22 Feb 2013 16:55:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1MGtmos018847; Fri, 22 Feb 2013 18:55:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1MGtmos018847 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1MGtm0A018846; Fri, 22 Feb 2013 18:55:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Feb 2013 18:55:48 +0200 From: Konstantin Belousov To: Jean-S?bastien P?dron Subject: Re: Building a program to be used only during make buildkernel Message-ID: <20130222165548.GM2598@kib.kiev.ua> References: <5127746A.6060702@dumbbell.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PCv3LdRyJ68gHPUM" Content-Disposition: inline In-Reply-To: <5127746A.6060702@dumbbell.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:55:57 -0000 --PCv3LdRyJ68gHPUM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2013 at 02:36:42PM +0100, Jean-S?bastien P?dron wrote: > Hello, >=20 > During the build of the "radeon" DRM driver in Linux, a C program is > first built to generate headers included by the driver. The program is > not meant to be installed. >=20 > In FreeBSD, how would one build and use such a program during the build > of a kernel module? And what if the driver is built into the kernel inste= ad? Look at the genasssym program, used by the kernel and several ABI modules for exactly this use. --PCv3LdRyJ68gHPUM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJ6MTAAoJEJDCuSvBvK1BPTUP/3EB3DlTuDomVGkUegsqqREI zoQKQQ8b2K4OQaSOxU8mcwmvGn64/lbQ5cwjTDEWCUa+XsUz1EI+3qGBhA1rhWEi W+mjCCzKxkgZTcKjGCUJKvw01v17822uDbwUxXC6kkSR+pKmshOxqhaKllqKKsZh +vleTqOIdt0gjZ552t4AfG1+28zdB88QeeFCaiLbA4F3ZEw9mKYBvIrXCmw85qw+ 8KjR9eyDo3E+LRl1ttmRLgiIGWi48GjEYPHj2mtQcBCiPuJvXL+J90P0ehpq7iHf s21wpqhAyhjvLp6I18WuufG1/YHX7z+YH89fdNjuSEkuXfWVKksr/0Kv9WF2Bj++ DtUjAcCAXtECQkKw45xZFN/SRSfji/fKUG7YGeD19GwRMtF4kliXl8jLzbcNDrPA 3xEi0/qkvKVGYTUeG08gdl9TUg9+vBRr1DBTGxSCsQuD68m/+fUVhUbgqnB3Qbda 82uKge3+AhY44nsL6B89G3vX4MbVSohOe4iHNMbu8vuZ+PpMF6owGYTfxoBgRCgP kODf0e0CrnXpSfmYwogEZ3EgnLGzClSphunFuE9tgcsHRaWbh3NSC9K47ZUQrOpB 3V7HamKpZuwrfqPT3EiMD8Cbnr4XQ7U+nEVdT0MeImwet4IiSF3a5y44OGgpnnuU uQIy3LsBEo9I4htD95rL =Afsk -----END PGP SIGNATURE----- --PCv3LdRyJ68gHPUM-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 19:06:11 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65920F8C for ; Fri, 22 Feb 2013 19:06:11 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2E45B35B for ; Fri, 22 Feb 2013 19:06:10 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1MJ62Rp064165 for ; Fri, 22 Feb 2013 12:06:02 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1MJ60eW054816 for ; Fri, 22 Feb 2013 12:06:00 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: rtprio_thread trouble From: Ian Lepore To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Feb 2013 12:06:00 -0700 Message-ID: <1361559960.1185.81.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:06:11 -0000 I ran into some trouble with rtprio_thread() today. I have a worker thread that I want to run at idle priority most of the time, but if it falls too far behind I'd like to bump it back up to regular timeshare priority until it catches up. In a worst case, the system is continuously busy and something scheduled at idle priority is never going to run (for some definition of 'never'). What I found is that in this worst case, even after my main thread has used rtprio_thread() to change the worker thread back to RTP_PRIO_NORMAL, the worker thread never gets scheduled. This is with the 4BSD scheduler but it appears that the same would be the case with ULE, based on code inspection. I find that this fixes it for 4BSD, and I think the same would be true for ULE... --- a/sys/kern/sched_4bsd.c Wed Feb 13 12:54:36 2013 -0700 +++ b/sys/kern/sched_4bsd.c Fri Feb 22 11:55:35 2013 -0700 @@ -881,6 +881,9 @@ sched_user_prio(struct thread *td, u_cha return; oldprio = td->td_user_pri; td->td_user_pri = prio; + if (td->td_flags & TDF_BORROWING && td->td_priority <= prio) + return; + sched_priority(td, prio); } void But I'm not sure if this would have any negative side effects, especially since in the ULE case there's a comment on this function that specifically notes that it changes the the user priority without changing the current priority (but it doesn't say why that matters). Is this a reasonable way to fix this problem, or is there a better way? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 19:12:57 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98BBA3D0 for ; Fri, 22 Feb 2013 19:12:57 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 596273FA for ; Fri, 22 Feb 2013 19:12:57 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1MJCuUp064241 for ; Fri, 22 Feb 2013 12:12:56 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1MJCsli054826 for ; Fri, 22 Feb 2013 12:12:54 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: why no per-thread scheduling niceness? From: Ian Lepore To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Feb 2013 12:12:54 -0700 Message-ID: <1361560374.1185.85.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:12:57 -0000 I'm curious why the concept of scheduling niceness applies only to an entire process, and it's not possible to have nice threads within a process. Is there any fundamental reason why it couldn't be supported with some extra bookkeeping to track niceness per thread? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 05:08:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF14A1BB for ; Sat, 23 Feb 2013 05:08:24 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7F126CD3 for ; Sat, 23 Feb 2013 05:08:24 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id bg4so830969pad.12 for ; Fri, 22 Feb 2013 21:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=BglyAsAWbnPnA7oXFnp5zhXeHlTIvDSgBtv0AB2BAVM=; b=cJjwZ9dYUmZyJF5szo+bgkAEZF61pCATAESuJPlm31rl161UFlTeNXMo8hR1km3ou2 FL2bmOc9BrGSYt/kqOqPbQoTKIFyPzKN4HcBG3hA8HNFt3s0cdx/f75FAei3DGkpnpp+ lbx1s9zdA/j4HlxKi8zFN4YZW5/5guKHC1xmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=BglyAsAWbnPnA7oXFnp5zhXeHlTIvDSgBtv0AB2BAVM=; b=YLVZNJDgCOQq/VyUs7lWVNrU1l9z0L6KKQTQldfofi5rvUpwI2OgMpKCLFtW89n+2I tK83sSlSWOrOqWIE812dAvYXroA9PInOTuuhB94QDySeCvDH7S2M0F6HXr7Z2S1YsYY1 6w1K/C1L4s9MFFIaeLca3u4vfRAGMTgCY92UYE95a1FEmt2ldmtu7wov3bNBL6bCnjaw vIX9q8zMnaWLPtt+LcVXFSV9zaePHHstczffM3SpX5F8kM8SbRYPLZyWtOIuO+mh3cO+ yyw7vw1ttLuKhWF0dLYVwOwbP2QXAZdrD3tNmTdE6ximWpDUL8f9M8Ha4ZaSypyDFMZw y+dQ== X-Received: by 10.66.155.226 with SMTP id vz2mr7840881pab.90.1361596098201; Fri, 22 Feb 2013 21:08:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.245.65 with HTTP; Fri, 22 Feb 2013 21:07:48 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Sat, 23 Feb 2013 00:07:48 -0500 Message-ID: Subject: Re: sched_ule developers handbook To: Sarthak Sarathi Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmJAeoYgZPxHa5/893ma5x0Hk/OmjkBc7kdO45DD3gjk/swQUbVDri8z4A7QebJvVUg5Ww2 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 05:08:24 -0000 I think this list might be better suited for the request below: On 19 February 2013 15:33, Sarthak Sarathi wrote: > I am a student studying my masters at International Institute of > Information Technology, Bangalore. We are working on a project called > "Temperature Aware variant of FreeBSD" in which scheduling algorithm has to > be changed. Could u please provide the developers manual for sched_ule.c > file explaining the structures, variables and functions? -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 10:53:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5288C8E8 for ; Sat, 23 Feb 2013 10:53:07 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9D430850 for ; Sat, 23 Feb 2013 10:53:06 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1NAqusU008779 for ; Sat, 23 Feb 2013 11:52:56 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1NAqutq008751 for ; Sat, 23 Feb 2013 11:52:56 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 23 Feb 2013 11:52:56 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: attaching iscsi (or ggate) disk before mounting root Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 23 Feb 2013 11:52:56 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 10:53:07 -0000 how to do it? From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 15:28:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF8A7EA2 for ; Sat, 23 Feb 2013 15:28:23 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2DDE71B0 for ; Sat, 23 Feb 2013 15:28:22 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1NFSESn042317 for ; Sat, 23 Feb 2013 16:28:14 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1NFSEvZ042314 for ; Sat, 23 Feb 2013 16:28:14 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 23 Feb 2013 16:28:13 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: TFTP single file kernel load Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 23 Feb 2013 16:28:14 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 15:28:23 -0000 can it be done? converting ELF kernel (i don't use kld modules) to format that can be loaded directly over TFTP - without intermediate stages like loader(8)? just to have SINGLE FILE that tftp would load and run. no loader(8) etc. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 16:43:05 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B38BA1E for ; Sat, 23 Feb 2013 16:43:05 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF4D800 for ; Sat, 23 Feb 2013 16:42:57 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1NGgukX082512 for ; Sat, 23 Feb 2013 09:42:57 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1NGgXf5056042; Sat, 23 Feb 2013 09:42:33 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: TFTP single file kernel load From: Ian Lepore To: Wojciech Puchar In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sat, 23 Feb 2013 09:42:32 -0700 Message-ID: <1361637752.1185.99.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 16:43:05 -0000 On Sat, 2013-02-23 at 16:28 +0100, Wojciech Puchar wrote: > can it be done? > > converting ELF kernel (i don't use kld modules) to format that can be > loaded directly over TFTP - without intermediate stages like loader(8)? > > just to have SINGLE FILE that tftp would load and run. no loader(8) etc. The kernel build process for arm and mips create such a kernel as one of the standard outputs from buildkernel. That doesn't appear to be the case for x86 kernels, but you could use sys/conf/makefile.arm as a guide. Basically what needs doing is to link the kernel with a modified ldscript that doesn't add space for the program headers, and then run the output of that link through "objcopy -S -O binary" to create a kernel.bin file. That file can be directly loaded to the address it was linked for, and a jump to the load address launches the kernel. Whether the kernel runs properly when launched that way is a different question. An arm kernel will run that way because we haven't had the luxury of loader(8) in the arm world until recently. The x86 kernel may expect values in the environment that the loader obtained from the bios. Without a loader you may need to modify the kernel to get that information in some other way early in startup. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 16:57:53 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 130F3F5D; Sat, 23 Feb 2013 16:57:53 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 92907878; Sat, 23 Feb 2013 16:57:51 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1NGviTG004392; Sat, 23 Feb 2013 17:57:44 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1NGviON004389; Sat, 23 Feb 2013 17:57:44 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 23 Feb 2013 17:57:44 +0100 (CET) From: Wojciech Puchar To: Ian Lepore Subject: Re: TFTP single file kernel load In-Reply-To: <1361637752.1185.99.camel@revolution.hippie.lan> Message-ID: References: <1361637752.1185.99.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 23 Feb 2013 17:57:44 +0100 (CET) Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 16:57:53 -0000 > > Basically what needs doing is to link the kernel with a modified > ldscript that doesn't add space for the program headers, and then run > the output of that link through "objcopy -S -O binary" to create a > kernel.bin file. That file can be directly loaded to the address it was > linked for, and a jump to the load address launches the kernel. is btxld(8) a tool i have to use after making kernel.bin file? what should i use for -b and -l > Whether the kernel runs properly when launched that way is a different > question. An arm kernel will run that way because we haven't had the > luxury of loader(8) in the arm world until recently. The x86 kernel may > expect values in the environment that the loader obtained from the bios. it can be loaded without loader for now - if you press a key before loader(8) is loaded and enter kernel image. at least it was like that. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 17:05:04 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D2655364 for ; Sat, 23 Feb 2013 17:05:04 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7D88A933 for ; Sat, 23 Feb 2013 17:05:04 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1NH53R5082820 for ; Sat, 23 Feb 2013 10:05:04 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1NH4f5n056070; Sat, 23 Feb 2013 10:04:41 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: TFTP single file kernel load From: Ian Lepore To: Wojciech Puchar In-Reply-To: References: <1361637752.1185.99.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 23 Feb 2013 10:04:41 -0700 Message-ID: <1361639081.1185.104.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 17:05:04 -0000 On Sat, 2013-02-23 at 17:57 +0100, Wojciech Puchar wrote: > > > > Basically what needs doing is to link the kernel with a modified > > ldscript that doesn't add space for the program headers, and then run > > the output of that link through "objcopy -S -O binary" to create a > > kernel.bin file. That file can be directly loaded to the address it was > > linked for, and a jump to the load address launches the kernel. > > is btxld(8) a tool i have to use after making kernel.bin file? > > what should i use for -b and -l > I've never heard of btxld before now, and from a quick look at its manpage its not clear to me what it does. It may be a part of the x86 build process I've never noticed before. > > > > Whether the kernel runs properly when launched that way is a different > > question. An arm kernel will run that way because we haven't had the > > luxury of loader(8) in the arm world until recently. The x86 kernel may > > expect values in the environment that the loader obtained from the bios. > > it can be loaded without loader for now - if you press a key before > loader(8) is loaded and enter kernel image. > > at least it was like that. Oh, good point, maybe it'll just work fine (although it's been years since I last loaded an x86 kernel directly from boot2, way back before the days of acpi and smap data and all of that modern stuff). -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:40:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5EFFA88D for ; Sat, 23 Feb 2013 19:40:24 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id C61EFEFD for ; Sat, 23 Feb 2013 19:40:23 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1NJeB10008480 for ; Sat, 23 Feb 2013 20:40:11 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1NJeA7w008477 for ; Sat, 23 Feb 2013 20:40:11 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 23 Feb 2013 20:40:10 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: Sound driver for Wyse S50 Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 23 Feb 2013 20:40:11 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 19:40:24 -0000 with Geode CS5535 processor. any idea? tried kldload every driver from generic kernel - nothing attaches. no support or is there a support just not in base system? From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 20:39:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E10192C for ; Sat, 23 Feb 2013 20:39:32 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id DA3A01CF for ; Sat, 23 Feb 2013 20:39:31 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.6/8.14.6) with ESMTP id r1NKdTMs053721 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 23 Feb 2013 20:39:30 GMT (envelope-from vince@unsane.co.uk) Message-ID: <51292900.6010400@unsane.co.uk> Date: Sat, 23 Feb 2013 20:39:28 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Wojciech Puchar Subject: Re: attaching iscsi (or ggate) disk before mounting root References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 20:39:32 -0000 On 23/02/2013 10:52, Wojciech Puchar wrote: > how to do it? Only way I know to get iscsi that early would be to use http://freebsd.1045724.n5.nabble.com/iSCSI-boot-driver-0-2-5-isboot-ko-has-been-released-td5736301.html I never did get round to trying it myself though Vince > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 21:30:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AB823590; Sat, 23 Feb 2013 21:30:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2F3652; Sat, 23 Feb 2013 21:30:44 +0000 (UTC) Received: from JRE-MBP-2.local (c-98-210-232-101.hsd1.ca.comcast.net [98.210.232.101]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r1NLUgSM049140 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 23 Feb 2013 13:30:43 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <51293505.1030706@freebsd.org> Date: Sat, 23 Feb 2013 13:30:45 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Phileas Fogg Subject: Re: Scrolling in framebuffer syscons References: <511F879C.3030801@mail.ru> <51217854.8000508@freebsd.org> <5123D941.2050906@mail.ru> In-Reply-To: <5123D941.2050906@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Oleksandr Tymoshenko , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 21:30:44 -0000 On 2/19/13 11:57 AM, Phileas Fogg wrote: > Oleksandr Tymoshenko wrote: >> On 2/16/2013 5:20 AM, Phileas Fogg wrote: >>> Hi, >>> >>> i have a question about how the scrolling in a framebuffer syscons >>> works. >>> I'm trying to speed up the syscons on the PS3 console which is a >>> simple >>> framebuffer syscons. >>> It uses the renderer _gfbrndrsw_ (see dev/syscons/scgfbrndr.c) to >>> draw into >>> the framebuffer of the PS3 console. >>> The _gfb_draw_ function implements a simple scrolling that moves >>> data from >>> bottom to top with _vidd_copy_. >>> And that's where i have a problem because _vidd_copy_ calls the >>> function >>> _ps3fb_copy_ (see powerpc/ps3/ps3_syscons.c). >>> But the function _ps3fb_copy_ is NOT implemented yet. So, the >>> question is how >>> does the scrolling work then ? >>> I took a look at other syscons implementation based on a >>> framebuffer, and >>> almost all of them do NOT implement _vidd_copy_ >>> function, e.g. XBOX syscons. >> >> I think driver re-renders whole screen character by character. >> That's why no >> copy operation is invoked. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" > > You are right, syscons is using the teken terminal emulator which > implements scrolling in software. The vidd_copy callback is never > called. To optimize the PS3 syscons driver, i have to speed up > vidd_puts and vidd_putc callbacks. not sure if it's relevent, but remember that updating the screen mor ethan 50 times a second is pointless. I'm not sure if the curent video console does it but having the final copy only done on 50Hz ticks can save a lot of copying. > > regards > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" >