Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image generation.
Hi Javier, I went through this e-mail thread and I noted one possibly interesting thing: You sent debug output file ttyUSB0_new.txt at 27.10.2013. There is one very interesting part: the begin of this file - there are these lines: " Now booting the Boot with GNU GRUB2 Loading file: (wd0,0)/grub.elf (elf) 0x801ffb60/296284 + Entry address is 801ffb60 Boot with parameters: console=tty no_auto_cmd ..." followed by dump of CPU registers. This text is not part of GRUB debug output - it is probably console or debug output of pmon which you are using to load GRUB. It is interesting that this serial output is probably working also in time when GRUB is loaded and executed - I have such feeling from the lines " ... [H[J[1;1H[7mWelcome to GRUB! [merror: variable `prefix' isn't set. [m[merror: serial port `com0' isn't found. error: terminal `console' isn't found. " which probably mean that the GRUB serial driver is not properly loaded and working - but output to serial line was still working! So, I have maybe very stupid idea - try please: - keep the modification in misc.c suggested by Vladimir - modify your grub.cfg in this way: ... ### BEGIN /etc/grub.d/00_header ### #serial #terminal_output console serial debug=all insmod ehci insmod ohci insmod usb_keyboard ls ... i.e. disable the GRUB serial driver and console redirection. What will be serial debug output in this case? BR, Ales Dne 17.11.2013 19:31, Javier Vasquez napsal(a): > On 11/17/13, Aleš Nesrsta wrote: >> ... >> Did you change >> something else than misc.c? > > No, please see attached diff. > > Thanks, > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image generation.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Javier, I went through this e-mail thread and I noted one possibly interesting thing: You sent debug output file ttyUSB0_new.txt at 27.10.2013. There is one very interesting part: the begin of this file - there are these lines: " Now booting the Boot with GNU GRUB2 Loading file: (wd0,0)/grub.elf (elf) 0x801ffb60/296284 + Entry address is 801ffb60 Boot with parameters: console=tty no_auto_cmd ..." followed by dump of CPU registers. This text is not part of GRUB debug output - it is probably console or debug output of pmon which you are using to load GRUB. It is interesting that this serial output is probably working also in time when GRUB is loaded and executed - I have such feeling from the lines " ... [H[J[1;1H[7mWelcome to GRUB! [merror: variable `prefix' isn't set. [m[merror: serial port `com0' isn't found. error: terminal `console' isn't found. " which probably mean that the GRUB serial driver is not properly loaded and working - but output to serial line was still working! So, I have maybe very stupid idea - try please: - - keep the modification in misc.c suggested by Vladimir - - modify your grub.cfg in this way: ... ### BEGIN /etc/grub.d/00_header ### #serial #terminal_output console serial debug=all insmod ehci insmod ohci insmod usb_keyboard ls ... i.e. disable the GRUB serial driver and console redirection. What will be serial debug output in this case? BR, Ales P.S. Sorry if this e-mail will appear twice in ML - I had some problem with e-mail client... Dne 17.11.2013 19:31, Javier Vasquez napsal(a): > On 11/17/13, Aleš Nesrsta wrote: >> ... Did you change something else than misc.c? > > No, please see attached diff. > > Thanks, > > > > ___ Grub-devel mailing > list Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKg8YAACgkQT72HYprvCNFXmAD8C37giDj1iaRI5KRaJMrOWz+i +xOF5k9CZ2Z8OlYFQAYA+wd+Ow02LyzTge4bD5WeLid7ExLPMzMThg/Y83MNmo8g =L7CJ -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Restrictive file permissions
On 12/05/2013 04:20 PM, Jonathan McCune wrote: > On Thu, Dec 5, 2013 at 10:10 AM, Colin Watson wrote: > >> I think we should identify the call sites that really need restricted >> permissions, explicitly lock them down, and open things back up for >> everything else. > > I agree that this policy makes more sense. fwiw, i agree with Jonathan and Colin that the default should be readable, and that we should only lock down specific files when we know that there is a need. i've argued for locking down the initramfs when it contains secret key material in http://bugs.debian.org/536195 so i'm aware that there are legitimate read-sensitivity concerns for some bootloader-available data. I'm really glad that the issue is taken seriously by the GRUB team. i just don't think files should be unreadable by default, because i prefer the ease of collaborative maintenance (as highlighted by Colin) and the general principle of system transparency for users where it does not present a security risk. --dkg signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Restrictive file permissions
I learned from a conversation on IRC today that GRUB has started to set restrictive file permissions in a few places since 2.00. Notably: grub-core/osdep/unix/hostdisk.c:184: return open (os_dev, flags, S_IRUSR | S_IWUSR); grub-core/osdep/bsd/hostdisk.c:93: ret = open (os_dev, flags, S_IRUSR | S_IWUSR); grub-core/osdep/aros/hostdisk.c:183: ret->fd = open (dev, flg, S_IRUSR | S_IWUSR); grub-core/osdep/freebsd/hostdisk.c:109: ret = open (os_dev, flags, S_IRUSR | S_IWUSR); grub-core/osdep/apple/hostdisk.c:83: ret = open (os_dev, flags, S_IRUSR | S_IWUSR); grub-core/osdep/apple/hostdisk.c:87:ret = open (os_dev, flags | O_SHLOCK, S_IRUSR | S_IWUSR); include/grub/osdep/hostfile_unix.h:74:#define grub_util_mkdir(a) mkdir ((a), 0700) include/grub/osdep/hostfile_aros.h:71:#define grub_util_mkdir(a) mkdir (a, 0700) Vladimir said on IRC that this is because normal users shouldn't need to peek into the internals of a GRUB installation, and that therefore GRUB is paranoid by default and opens things up on an exceptional basis where needed. For a project that deals primarily with data that needs to be kept secret, I think this would be an entirely reasonable position. For GRUB, though, I disagree strongly. I'm surprised not to find anything in the GNU Standards about this, but Debian Policy has this which is somewhat related: http://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners """ Files should be owned by root:root, and made writable only by the owner and universally readable (and executable, if appropriate), that is mode 644 or 755. Directories should be mode 755 or (for group-writability) mode 2775. The ownership of the directory should be consistent with its mode: if a directory is mode 2775, it should be owned by the group that needs write access to it. Control information files should be owned by root:root and either mode 644 (for most files) or mode 755 (for executables such as maintainer scripts). Setuid and setgid executables should be mode 4755 or 2755 respectively, and owned by the appropriate user or group. They should not be made unreadable (modes like 4711 or 2711 or even 4111); doing so achieves no extra security, because anyone can find the binary in the freely available Debian package; it is merely inconvenient. For the same reason you should not restrict read or execute permissions on non-set-id executables. Some setuid programs need to be restricted to particular sets of users, using file permissions. In this case they should be owned by the uid to which they are set-id, and by the group which should be allowed to execute them. They should have mode 4754; again there is no point in making them unreadable to those users who must not be allowed to execute them. """ Although this is in terms of Debian packages, the general principle at work here is that it doesn't make sense to try to keep free software secret, as all this does is make things inconvenient for people trying to investigate problems. In some cases this may simply mean that a sysadmin has to use root privileges to look into a problem where they might otherwise be able to use their ordinary user account; this is only minimally inconvenient, but it encourages the approach of just doing everything in a root shell which makes it harder to keep audit logs of changes and makes it much easier to make destructive mistakes while investigating problems. I can imagine cases which are more problematic than that. For example, I am sometimes called upon as a boot expert to look into strange problems with servers at work. I might well be given a user account so that I can look around, but I certainly won't be given root access and I wouldn't want the liability of having it anyway. Unnecessarily restrictive permissions mean that rather than being able to look at files directly I may now have to try to teleoperate a sysadmin, which is much more cumbersome. In a project which is almost entirely dealing with well-known data, I think we should have to have active reasons to make things secret from ordinary users of the system, rather than making things secret as a default. Of things which are copied into /boot/grub/, the only thing I can really think of which needs to be secret is any (hashed or otherwise) passwords set by the administrator. I can *possibly* see an argument for also restricting .sig files (perhaps only if the file they're signing is also world-unreadable [1]), on the grounds that that makes it harder to attempt to generate a second preimage. Maybe I missed one or two small things. But for everything else, and surely for the vast majority of GRUB, locking down access seems to just get in the way of people investigating problems or honestly trying to learn about a system where they just have an ordinary user account, and I don't see that it gains us anything of value. I think we should identify the call sites that really need rest
Re: [PATCH] Replace print statement with sys.stdout.write for python3 compatibility
On Thu, Dec 05, 2013 at 04:31:55PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 04.12.2013 16:28, Mike Gilbert wrote: > > On Wed, Dec 4, 2013 at 5:12 AM, Colin Watson wrote: > >> On Tue, Dec 03, 2013 at 08:14:09PM -0500, Mike Gilbert wrote: > >>> Gmail likes to mangle patches, so I'm attaching it. > >> > >> Could we please use the clearer bilingual form of "from __future__ > >> import print_function" at the top followed by print(s, end="")? This > >> does require bumping our minimum required Python version to 2.6; but > >> that was released five years ago, so I would have thought that would be > >> an acceptable requirement by now. > > > > That's fine by me. I have attached a patch for that. > > If Colin is ok with this patch then so am I. Yeah, I am - thanks, Mike. Rebased and pushed. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
Il 05/12/2013 16:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 29.11.2013 12:28, Fabio Fantoni wrote: I updated git to commit 69ca97c820a623f85baf2db1627e19bef9c24e44 and the regression persist. I've just tested it here and it works perfectly. Are you sure you don't have a typo in variable name? The script for include the grub.cfg of domU works, was only my stupid error with cat, sorry. Below the actual version of the script that works on many common cases. Are there other modules to insert for other partitions or file systems, other grub cfg path for other distributions or other kernel type to search for that support xen pv domUs? I think is good to make and post complete pvgrub2 cfg that support all pv domUs cases. cat > boot/grub/grub.cfg <<'EOF' insmod lvm insmod ext2 insmod part_msdos insmod part_gpt insmod btrfs insmod xzio insmod regexp for dev in (*); do # $device: parenthesis removed from $dev regexp -s device '\((.*)\)' $dev set root=$device for file in /boot/vmlinuz-* /boot/linux-*; do if test -f $file; then set saved_root=$root fi done done set root=$saved_root if test -f /boot/grub2/grub.cfg ; then configfile /boot/grub2/grub.cfg elif test -f /boot/grub/grub.cfg ; then configfile /boot/grub/grub.cfg fi EOF About the other problem of stop/crash on domU kernel/initrd without any errors (also with serial and debug enabled) the problem persist, I'll do further test tomorrow. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
On 29.11.2013 12:28, Fabio Fantoni wrote: > I updated git to commit 69ca97c820a623f85baf2db1627e19bef9c24e44 and the > regression persist. I've just tested it here and it works perfectly. Are you sure you don't have a typo in variable name? signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Replace print statement with sys.stdout.write for python3 compatibility
On 04.12.2013 16:28, Mike Gilbert wrote: > On Wed, Dec 4, 2013 at 5:12 AM, Colin Watson wrote: >> On Tue, Dec 03, 2013 at 08:14:09PM -0500, Mike Gilbert wrote: >>> Gmail likes to mangle patches, so I'm attaching it. >> >> Could we please use the clearer bilingual form of "from __future__ >> import print_function" at the top followed by print(s, end="")? This >> does require bumping our minimum required Python version to 2.6; but >> that was released five years ago, so I would have thought that would be >> an acceptable requirement by now. >> > > That's fine by me. I have attached a patch for that. > If Colin is ok with this patch then so am I. > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] On Linux, read partition start offsets from sysfs if possible
Looks good. Go ahead.
On 05.12.2013 13:17, Colin Watson wrote:
> This lets us cope with block device drivers that don't implement
> HDIO_GETGEO. Fixes Ubuntu bug #1237519.
>
> * grub-core/osdep/linux/hostdisk.c (sysfs_partition_path): New
> function.
> (sysfs_partition_start): Likewise.
> (grub_util_find_partition_start_os): Try sysfs_partition_start
> before HDIO_GETGEO.
> ---
> ChangeLog| 12 ++
> grub-core/osdep/linux/hostdisk.c | 89
>
> 2 files changed, 101 insertions(+)
>
> diff --git a/ChangeLog b/ChangeLog
> index d60acab..d08d841 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,15 @@
> +2013-12-05 Colin Watson
> +
> + On Linux, read partition start offsets from sysfs if possible, to
> + cope with block device drivers that don't implement HDIO_GETGEO.
> + Fixes Ubuntu bug #1237519.
> +
> + * grub-core/osdep/linux/hostdisk.c (sysfs_partition_path): New
> + function.
> + (sysfs_partition_start): Likewise.
> + (grub_util_find_partition_start_os): Try sysfs_partition_start
> + before HDIO_GETGEO.
> +
> 2013-12-05 Vladimir Serbinenko
>
> Handle unaligned .bss on sparc64.
> diff --git a/grub-core/osdep/linux/hostdisk.c
> b/grub-core/osdep/linux/hostdisk.c
> index a2c80f3..74d87a4 100644
> --- a/grub-core/osdep/linux/hostdisk.c
> +++ b/grub-core/osdep/linux/hostdisk.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -39,6 +40,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -93,12 +95,99 @@ grub_util_get_fd_size_os (grub_util_fd_t fd, const char
> *name, unsigned *log_sec
>return nr;
> }
>
> +static char *
> +sysfs_partition_path (const char *dev, const char *entry)
> +{
> + const char *argv[7];
> + int fd;
> + pid_t pid;
> + FILE *udevadm;
> + char *buf = NULL;
> + size_t len = 0;
> + char *path = NULL;
> +
> + argv[0] = "udevadm";
> + argv[1] = "info";
> + argv[2] = "--query";
> + argv[3] = "path";
> + argv[4] = "--name";
> + argv[5] = dev;
> + argv[6] = NULL;
> +
> + pid = grub_util_exec_pipe (argv, &fd);
> +
> + if (!pid)
> +return NULL;
> +
> + /* Parent. Read udevadm's output. */
> + udevadm = fdopen (fd, "r");
> + if (!udevadm)
> +{
> + grub_util_warn (_("Unable to open stream from %s: %s"),
> + "udevadm", strerror (errno));
> + close (fd);
> + goto out;
> +}
> +
> + if (getline (&buf, &len, udevadm) > 0)
> +{
> + char *newline;
> +
> + newline = strchr (buf, '\n');
> + if (newline)
> + *newline = '\0';
> + path = xasprintf ("/sys%s/%s", buf, entry);
> +}
> +
> +out:
> + if (udevadm)
> +fclose (udevadm);
> + waitpid (pid, NULL, 0);
> + free (buf);
> +
> + return path;
> +}
> +
> +static int
> +sysfs_partition_start (const char *dev, grub_disk_addr_t *start)
> +{
> + char *path;
> + FILE *fp;
> + unsigned long long val;
> + int ret = 0;
> +
> + path = sysfs_partition_path (dev, "start");
> + if (!path)
> +return 0;
> +
> + fp = grub_util_fopen (path, "r");
> + if (!fp)
> +goto out;
> +
> + if (fscanf (fp, "%llu", &val) == 1)
> +{
> + *start = (grub_disk_addr_t) val;
> + ret = 1;
> +}
> +
> +out:
> + free (path);
> + if (fp)
> +fclose (fp);
> +
> + return ret;
> +}
> +
> grub_disk_addr_t
> grub_util_find_partition_start_os (const char *dev)
> {
> + grub_disk_addr_t start;
>grub_util_fd_t fd;
>struct hd_geometry hdg;
>
> + if (sysfs_partition_start (dev, &start))
> +return start;
> +
>fd = open (dev, O_RDONLY);
>if (fd == -1)
> {
>
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] On Linux, read partition start offsets from sysfs if possible
On Thu, Dec 05, 2013 at 12:17:23PM +, Colin Watson wrote: > This lets us cope with block device drivers that don't implement > HDIO_GETGEO. Fixes Ubuntu bug #1237519. Brandon Hansen also pointed out in this bug that hd_geometry.start is unsigned long rather than unsigned long long, and thus is not necessarily reliable on large disks, which is a good point I'd overlooked, and should be further support for this approach. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] On Linux, read partition start offsets from sysfs if possible
This lets us cope with block device drivers that don't implement
HDIO_GETGEO. Fixes Ubuntu bug #1237519.
* grub-core/osdep/linux/hostdisk.c (sysfs_partition_path): New
function.
(sysfs_partition_start): Likewise.
(grub_util_find_partition_start_os): Try sysfs_partition_start
before HDIO_GETGEO.
---
ChangeLog| 12 ++
grub-core/osdep/linux/hostdisk.c | 89
2 files changed, 101 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index d60acab..d08d841 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2013-12-05 Colin Watson
+
+ On Linux, read partition start offsets from sysfs if possible, to
+ cope with block device drivers that don't implement HDIO_GETGEO.
+ Fixes Ubuntu bug #1237519.
+
+ * grub-core/osdep/linux/hostdisk.c (sysfs_partition_path): New
+ function.
+ (sysfs_partition_start): Likewise.
+ (grub_util_find_partition_start_os): Try sysfs_partition_start
+ before HDIO_GETGEO.
+
2013-12-05 Vladimir Serbinenko
Handle unaligned .bss on sparc64.
diff --git a/grub-core/osdep/linux/hostdisk.c b/grub-core/osdep/linux/hostdisk.c
index a2c80f3..74d87a4 100644
--- a/grub-core/osdep/linux/hostdisk.c
+++ b/grub-core/osdep/linux/hostdisk.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -39,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -93,12 +95,99 @@ grub_util_get_fd_size_os (grub_util_fd_t fd, const char
*name, unsigned *log_sec
return nr;
}
+static char *
+sysfs_partition_path (const char *dev, const char *entry)
+{
+ const char *argv[7];
+ int fd;
+ pid_t pid;
+ FILE *udevadm;
+ char *buf = NULL;
+ size_t len = 0;
+ char *path = NULL;
+
+ argv[0] = "udevadm";
+ argv[1] = "info";
+ argv[2] = "--query";
+ argv[3] = "path";
+ argv[4] = "--name";
+ argv[5] = dev;
+ argv[6] = NULL;
+
+ pid = grub_util_exec_pipe (argv, &fd);
+
+ if (!pid)
+return NULL;
+
+ /* Parent. Read udevadm's output. */
+ udevadm = fdopen (fd, "r");
+ if (!udevadm)
+{
+ grub_util_warn (_("Unable to open stream from %s: %s"),
+ "udevadm", strerror (errno));
+ close (fd);
+ goto out;
+}
+
+ if (getline (&buf, &len, udevadm) > 0)
+{
+ char *newline;
+
+ newline = strchr (buf, '\n');
+ if (newline)
+ *newline = '\0';
+ path = xasprintf ("/sys%s/%s", buf, entry);
+}
+
+out:
+ if (udevadm)
+fclose (udevadm);
+ waitpid (pid, NULL, 0);
+ free (buf);
+
+ return path;
+}
+
+static int
+sysfs_partition_start (const char *dev, grub_disk_addr_t *start)
+{
+ char *path;
+ FILE *fp;
+ unsigned long long val;
+ int ret = 0;
+
+ path = sysfs_partition_path (dev, "start");
+ if (!path)
+return 0;
+
+ fp = grub_util_fopen (path, "r");
+ if (!fp)
+goto out;
+
+ if (fscanf (fp, "%llu", &val) == 1)
+{
+ *start = (grub_disk_addr_t) val;
+ ret = 1;
+}
+
+out:
+ free (path);
+ if (fp)
+fclose (fp);
+
+ return ret;
+}
+
grub_disk_addr_t
grub_util_find_partition_start_os (const char *dev)
{
+ grub_disk_addr_t start;
grub_util_fd_t fd;
struct hd_geometry hdg;
+ if (sysfs_partition_start (dev, &start))
+return start;
+
fd = open (dev, O_RDONLY);
if (fd == -1)
{
--
1.8.4.4
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: fdt: fix for add_subnode()
On 05.12.2013 10:11, Francesco Lavra wrote: > Hi, > > On 12/04/2013 04:28 PM, Leif Lindholm wrote: >> The current fdt support fails to update the size of the dt_struct after >> adding a new node. Attached is the suggested fix. > > Looks ok to me. > Looks ok to me as well, go ahead. > -- > Francesco > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: fdt: fix for add_subnode()
Hi, On 12/04/2013 04:28 PM, Leif Lindholm wrote: > The current fdt support fails to update the size of the dt_struct after > adding a new node. Attached is the suggested fix. Looks ok to me. -- Francesco ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
