On Thu, Sep 04, 2008 at 11:37:43PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
> >>> I assume you talk about GRUB loading itself; what kind of information
> >>> would
> >>> you pass from one GRUB to the other?
> >> Boot device,
> >
>
On Thu, Sep 04, 2008 at 11:40:32PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
> >> Possibilites are there, but basically they are limited to something like:
> >>
> >> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
>
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
>> Possibilites are there, but basically they are limited to something like:
>>
>> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
>
> I think this is overkill, and doesn't really address the root o
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
>>> I assume you talk about GRUB loading itself; what kind of information would
>>> you pass from one GRUB to the other?
>> Boot device,
>
> Multiboot already handles that (although it's not reliable; I don't
> think
On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
>
> Possibilites are there, but basically they are limited to something like:
>
> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
I think this is overkill, and doesn't really address the root of the problem.
The real s
On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
> >
> > I assume you talk about GRUB loading itself; what kind of information would
> > you pass from one GRUB to the other?
> Boot device,
Multiboot already handles that (although it's not reliable; I don't
think this feature should be us
Vesa Jääskeläinen wrote:
> phcoder wrote:
>> Yes it is, but in my opinion price is too high (shame ubuntu uses this
>> solution). It's somewhat similar to some solutions found in windows when
>> for user convenience they open a big gate for the hackers (e.g. all
>> users by default are administra
phcoder wrote:
> Vesa Jääskeläinen wrote:
>> That is a valid point.
>>
>> Would you prefer to use hardware path to device or what you had in mind
>> then? Because this is something that we can left for expert people. Most
>> common problem is that user plugs in new drive to system and
>> bios/hardw
Vesa Jääskeläinen wrote:
> That is a valid point.
>
> Would you prefer to use hardware path to device or what you had in mind
> then? Because this is something that we can left for expert people. Most
> common problem is that user plugs in new drive to system and
> bios/hardware order gets changed
phcoder wrote:
> But consider a scenario when attacker can't overwrite the existing
> harddrive but can plug new one. Then the attacker can prepare a
> harddrive having a partition with the same UUID as our boot partition.
> Then he plugs it and depnding on factors like order of interfaces,
> devic
Vesa Jääskeläinen wrote:
> phcoder wrote:
>> I was thinking about the scenario when ide drives are trusted but not
>> USB or removable devices. Cryptographic checksums wouldn't bring much
>> because if attacker can modify harddrive he can also modify GRUB to skip
>> checksum check.
>
> Then you p
phcoder wrote:
> I was thinking about the scenario when ide drives are trusted but not
> USB or removable devices. Cryptographic checksums wouldn't bring much
> because if attacker can modify harddrive he can also modify GRUB to skip
> checksum check.
Then you password protect it :) Once that is
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote:
>> Hello, all.
>> Now when core image can be booted by multiple sources perhaps it would
>> be a good idea to recieve some boot arguments in case boot method (e.g.
>> multiboot) supports it. Probably the best way is to
On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote:
> Hello, all.
> Now when core image can be booted by multiple sources perhaps it would
> be a good idea to recieve some boot arguments in case boot method (e.g.
> multiboot) supports it. Probably the best way is to recieve pairs
> which can
Hello, all.
Now when core image can be booted by multiple sources perhaps it would
be a good idea to recieve some boot arguments in case boot method (e.g.
multiboot) supports it. Probably the best way is to recieve pairs
which can be easily imported to environment. Another
possibility of improving
15 matches
Mail list logo
