On Tue, 9 Jul 2019 08:46:32 +0200
Martin Hundebøll wrote:
> Make it obvious how the gsm mux number relates to the virtual tty lines
> by using helper function instead of shifting 6 bits.
>
> Signed-off-by: Martin Hundebøll
> ---
> drivers/tty/n_gsm.c | 16 +---
> 1 file changed,
On Mon, 8 Jul 2019 21:02:52 +0200
Martin Hundebøll wrote:
> Guessing the base tty for a gsm0710 multiplexed serial device is not
> currently possible, which makes it racy to use with multiple modems.
>
> Add a way to map the physical serial tty to its related mux devices
> using a ioctl.
That
On Fri, 21 Jun 2019 15:16:04 +0530
Puranjay Mohan wrote:
> This patch series removes the private duplicates of PCI definitions in
> favour of generic definitions defined in pci_regs.h.
Why bother ? It's an ancient obsolete card ?
Do you even have one to test ?
>
> This driver only uses some
> +static int rpmsg_tty_data_handler(struct rpmsg_device *rpdev, void *data,
> + int len, void *priv, u32 src)
> +{
> + struct rpmsg_tty_port *cport = dev_get_drvdata(>dev);
> + u8 *cbuf;
> + int space;
> +
> + dev_dbg(>dev, "msg(<- src 0x%x) len
O
> +static void mlb_usio_set_termios(struct uart_port *port,
> + struct ktermios *termios, struct ktermios *old)
> +{
> + unsigned int escr, smr = MLB_USIO_SMR_SOE;
> + unsigned long flags, baud, quot;
> +
> + switch (termios->c_cflag & CSIZE) {
> + case CS5:
>
> > If the virtual Sparc emulator is using it does that also mean actual
> > Sparc hardware has it. In which case presumably it needs fixing, or at
> > least moving to the generic driver assuming the firmware sets it up ?
> >
>
> The qemu works perfectly with the new Linux driver.
For some
On Sat, 16 Mar 2019 10:35:43 +0100
Samuel Thibault wrote:
> Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > Okash Khawaja writes:
> > > Finally there is an issue where text in output buffer sometimes gets
> > > garbled on SMP systems, but we can continue working on it after
> Suse have a solution for this that I'd like to see pushed again, but
> from a practical perspective enterprise distributions have been
> shipping this for some time without significant obvious customer
> complaint.
Probably because their IT department hasn't noticed 8)
Alan
On Tue, 12 Mar 2019 11:41:02 +0100
LABBE Corentin wrote:
> On Mon, Dec 10, 2018 at 05:52:35PM +0300, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 12/10/2018 04:46 PM, Corentin Labbe wrote:
> >
> > > When playing with a virtual SPARC machine with qemu, I found that the
> > > IDE emulated
On Wed, 6 Mar 2019 15:58:55 -0800
Matthew Garrett wrote:
> From: Josh Boyer
>
> There is currently no way to verify the resume image when returning
> from hibernate. This might compromise the signed modules trust model,
> so until we can work with signed hibernate images we disable it when
On Wed, 6 Mar 2019 09:11:44 -0500
"Theodore Y. Ts'o" wrote:
> On Wed, Mar 06, 2019 at 01:25:17PM +0100, Thomas Gleixner wrote:
> > > It's been 25 years since Linux added support for ELF. Can we just
> > > delete the a.out support entirely now? According to the Linux-ELF HOWTO,
> > > support
> It's been 25 years since Linux added support for ELF. Can we just
> delete the a.out support entirely now? According to the Linux-ELF HOWTO,
> support was added in 1.1.52 (August 1994). It's pretty much necromancy
> at this point.
In the unlikely event that someone actually has an a.out
On Wed, 30 Jan 2019 15:31:20 +1030
Rusty Russell wrote:
> Thanks taking on such a thankless task Thomas,
>
> Might have been overzealous in assuming a verionless GPL string meant
> "or later" (I'm happy for that for my own code, FWIW). My memory is
> fuzzy, but I don't think anyone cared at
> > > +"GPL and additional rights" Historical variant of expressing that
> > > the
> > > + module source is dual licensed under a
> > > + GPL v2 variant and MIT license. Please do
> > > + not use in new code.
> This is going to be a mammoth task. The alternatives are to continue
> as things are, which is a mess that cannot be cleaned up by either of
> (mutually exclusive) hardware or software alone.
>
> Thoughts and feedback appreciated.
You need to be talking to the JIT developers not asking here I
> I think the issue is a bit more complex :
> - linux doesn't support a single libc
> - glibc doesn't support a single OS
>
> In practice we all know (believe?) that both statements above are
> true but in practice 99% of the time there's a 1:1 relation between
> these two components.
The
> I think the issue is a bit more complex :
> - linux doesn't support a single libc
> - glibc doesn't support a single OS
>
> In practice we all know (believe?) that both statements above are
> true but in practice 99% of the time there's a 1:1 relation between
> these two components.
The
On Mon, 12 Nov 2018 17:09:56 +0100
Oleg Nesterov wrote:
> Large enterprise clients often times run applications out of networked
> file systems where the IT mandated layout of project volumes can end up
> leading to paths that are longer than 128 characters. Bumping this up to
> the next order
On Mon, 12 Nov 2018 17:09:56 +0100
Oleg Nesterov wrote:
> Large enterprise clients often times run applications out of networked
> file systems where the IT mandated layout of project volumes can end up
> leading to paths that are longer than 128 characters. Bumping this up to
> the next order
On Mon, 22 Oct 2018 09:56:42 +0200
Joerg Roedel wrote:
> On Sun, Oct 21, 2018 at 02:37:45PM +0200, Pavel Machek wrote:
> > On Tue 2018-09-18 14:00:30, Alan Cox wrote:
> > > There are pretty much no machines that don't support PAE and are still
> > > even vaguely
On Mon, 22 Oct 2018 09:56:42 +0200
Joerg Roedel wrote:
> On Sun, Oct 21, 2018 at 02:37:45PM +0200, Pavel Machek wrote:
> > On Tue 2018-09-18 14:00:30, Alan Cox wrote:
> > > There are pretty much no machines that don't support PAE and are still
> > > even vaguely
> > Data protection law, reporting laws in some
> > countries and the like mean that anyone expecting an incident to remain
> > confidential from the person it was reported against is living in
> > dreamland and are going to get a nasty shock.
>
> OK - you seem to be talking about keeping the
> > Data protection law, reporting laws in some
> > countries and the like mean that anyone expecting an incident to remain
> > confidential from the person it was reported against is living in
> > dreamland and are going to get a nasty shock.
>
> OK - you seem to be talking about keeping the
> +to the circumstances. The Code of Conduct Committee is obligated to
> +maintain confidentiality with regard to the reporter of an incident.
> +Further details of specific enforcement policies may be posted
> +separately.
Unfortunately by ignoring the other suggestions on this you've left
> +to the circumstances. The Code of Conduct Committee is obligated to
> +maintain confidentiality with regard to the reporter of an incident.
> +Further details of specific enforcement policies may be posted
> +separately.
Unfortunately by ignoring the other suggestions on this you've left
On Tue, 16 Oct 2018 20:12:43 +0200
"Gustavo A. R. Silva" wrote:
> On 10/16/18 8:09 PM, Dmitry Torokhov wrote:
>
> >
> > /dev/uinput
>
> I've got it. This explains it all. :)
>
> > must be 0600, or accessible to equally privileged user, or you'll be
> > opening your system to much
On Tue, 16 Oct 2018 20:12:43 +0200
"Gustavo A. R. Silva" wrote:
> On 10/16/18 8:09 PM, Dmitry Torokhov wrote:
>
> >
> > /dev/uinput
>
> I've got it. This explains it all. :)
>
> > must be 0600, or accessible to equally privileged user, or you'll be
> > opening your system to much
> +/*
> + * Returns true if current's euid is same as p's uid or euid,
> + * or has CAP_SYS_ADMIN.
> + *
> + * Called with rcu_read_lock, creds are safe.
> + *
> + * Adapted from set_one_prio_perm().
> + */
> +static bool set_predump_signal_perm(struct task_struct *p)
> +{
> + const struct
> +/*
> + * Returns true if current's euid is same as p's uid or euid,
> + * or has CAP_SYS_ADMIN.
> + *
> + * Called with rcu_read_lock, creds are safe.
> + *
> + * Adapted from set_one_prio_perm().
> + */
> +static bool set_predump_signal_perm(struct task_struct *p)
> +{
> + const struct
s allows S0ix modes to
> be entered on e.g. a Chuwi Hi8 Pro and a HP x2 210.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196915
> Signed-off-by: Hans de Goede
Reviewed-by: Alan Cox
Thanks
s allows S0ix modes to
> be entered on e.g. a Chuwi Hi8 Pro and a HP x2 210.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196915
> Signed-off-by: Hans de Goede
Reviewed-by: Alan Cox
Thanks
> > It should be.
>
> You mean that the problem should be purely academic, IOW that registers
> touched
> by the P-Unit are never touched through ACPI Opregions / power-resources?
As far as I am aware. Holding the lock over both is definitely better
regardless
> >> 2) To safely access the
> > It should be.
>
> You mean that the problem should be purely academic, IOW that registers
> touched
> by the P-Unit are never touched through ACPI Opregions / power-resources?
As far as I am aware. Holding the lock over both is definitely better
regardless
> >> 2) To safely access the
> My understanding is that the standard “breadcrumb” is that a cache line is
> fetched into L1D, and that the cacheline in question will go into L1D even if
> it was previously not cached at all. So flushing L1D will cause the timing
> from a probe to be different, but the breadcrumb is still
> My understanding is that the standard “breadcrumb” is that a cache line is
> fetched into L1D, and that the cacheline in question will go into L1D even if
> it was previously not cached at all. So flushing L1D will cause the timing
> from a probe to be different, but the breadcrumb is still
> But this really needs to be clarified. Alan said that a bunch of the
> "yet another Spectre variant" attacks would have been mitigated by
> this patch. An explanation of *how* would be in order.
Today you have the situation where something creates a speculative
disclosure gadget. So we run
> But this really needs to be clarified. Alan said that a bunch of the
> "yet another Spectre variant" attacks would have been mitigated by
> this patch. An explanation of *how* would be in order.
Today you have the situation where something creates a speculative
disclosure gadget. So we run
> 1) PMIC accesses often come in the form of a read-modify-write on one of
> the PMIC registers, we currently release the P-Unit's PMIC bus semaphore
> between the read and the write. If the P-Unit modifies the register during
> this window?, then we end up overwriting the P-Unit's changes.
> I
> 1) PMIC accesses often come in the form of a read-modify-write on one of
> the PMIC registers, we currently release the P-Unit's PMIC bus semaphore
> between the read and the write. If the P-Unit modifies the register during
> this window?, then we end up overwriting the P-Unit's changes.
> I
> Ugh.
>
> What exactly is this trying to protect against? And how many cycles
Most attacks by speculation rely upon leaving footprints in the L1 cache.
They also almost inevitably resolve non speculatively to errors. If you
look through all the 'yet another potential spectre case' patches
> Ugh.
>
> What exactly is this trying to protect against? And how many cycles
Most attacks by speculation rely upon leaving footprints in the L1 cache.
They also almost inevitably resolve non speculatively to errors. If you
look through all the 'yet another potential spectre case' patches
> I'm mostly wondering if it is worth future-proofing for new transports. It
> sounds like we can have a consensus on leaving the upper 4 bits of the speed
> fields reserved, but leave the details of implementation for the future?
It seems reasonable, although I think the reality is that any
> I'm mostly wondering if it is worth future-proofing for new transports. It
> sounds like we can have a consensus on leaving the upper 4 bits of the speed
> fields reserved, but leave the details of implementation for the future?
It seems reasonable, although I think the reality is that any
On Tue, 9 Oct 2018 12:19:04 -0700
"H. Peter Anvin" wrote:
> [Resending to a wider audience]
>
> In trying to get the termios2 interface actually implemented in glibc,
> the question came up if we will ever care about baud rates in excess of
> 4 Gbps, even in the relatively remote future.
Even
On Tue, 9 Oct 2018 12:19:04 -0700
"H. Peter Anvin" wrote:
> [Resending to a wider audience]
>
> In trying to get the termios2 interface actually implemented in glibc,
> the question came up if we will ever care about baud rates in excess of
> 4 Gbps, even in the relatively remote future.
Even
On Wed, 10 Oct 2018 13:10:30 -0700
> +appropriate to the circumstances. The TAB is obligated to maintain
> +confidentiality with regard to the reporter of an incident.
I would add (except where required by law.)
Alan
On Wed, 10 Oct 2018 13:10:30 -0700
> +appropriate to the circumstances. The TAB is obligated to maintain
> +confidentiality with regard to the reporter of an incident.
I would add (except where required by law.)
Alan
On Wed, 10 Oct 2018 14:19:17 -0300
Mauro Carvalho Chehab wrote:
> Em Wed, 10 Oct 2018 16:53:08 +0100
> Alan Cox escreveu:
>
> > > -Maintainers have the right and responsibility to remove, edit, or reject
> > > +Maintainers may remove, edit, or reject
> > >
On Wed, 10 Oct 2018 14:19:17 -0300
Mauro Carvalho Chehab wrote:
> Em Wed, 10 Oct 2018 16:53:08 +0100
> Alan Cox escreveu:
>
> > > -Maintainers have the right and responsibility to remove, edit, or reject
> > > +Maintainers may remove, edit, or reject
> > >
> -Maintainers have the right and responsibility to remove, edit, or reject
> +Maintainers may remove, edit, or reject
> comments, commits, code, wiki edits, issues, and other contributions that are
> not aligned to this Code of Conduct, or to ban temporarily or permanently any
> contributor
> -Maintainers have the right and responsibility to remove, edit, or reject
> +Maintainers may remove, edit, or reject
> comments, commits, code, wiki edits, issues, and other contributions that are
> not aligned to this Code of Conduct, or to ban temporarily or permanently any
> contributor
> In any case, this is not the appropriate place for such patches, any
> more than it's the place for patches to the GPL.
I disagree. We had the GPLv2 or GPLv3 discussion on the kernel mailing
list. The syscall clarification was discussed on the list. The
EXPORT_SYMBOL and EXPORT_SYMBOL_GPL stuff
> In any case, this is not the appropriate place for such patches, any
> more than it's the place for patches to the GPL.
I disagree. We had the GPLv2 or GPLv3 discussion on the kernel mailing
list. The syscall clarification was discussed on the list. The
EXPORT_SYMBOL and EXPORT_SYMBOL_GPL stuff
e what can they do ?
So both patches:
Reviewed-by: Alan Cox
e what can they do ?
So both patches:
Reviewed-by: Alan Cox
> /* only root can play with this */
> if (!capable(CAP_SYS_ADMIN))
> return -EACCES;
>
> Think about it - if DM control ioctls only require CAP_SYS_ADMIN,
> then if have that cap you can use DM to remap any block in a block
> device to any other block. You don't
> /* only root can play with this */
> if (!capable(CAP_SYS_ADMIN))
> return -EACCES;
>
> Think about it - if DM control ioctls only require CAP_SYS_ADMIN,
> then if have that cap you can use DM to remap any block in a block
> device to any other block. You don't
> > CAP_SYS_ADMIN is also a bit weird because low level access usually
> > implies you can bypass access controls so you should also check
> > CAP_SYS_DAC ?
>
> Do you mean CAP_DAC_READ_SEARCH as per the newer handle syscalls?
> But that only allows bypassing directory search operations, so
> > CAP_SYS_ADMIN is also a bit weird because low level access usually
> > implies you can bypass access controls so you should also check
> > CAP_SYS_DAC ?
>
> Do you mean CAP_DAC_READ_SEARCH as per the newer handle syscalls?
> But that only allows bypassing directory search operations, so
> > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview
There is no such product as Valleyview. Some things talk about
Valleyview 2 but shouldn't as that is Baytrail.
> /* "Small Core" Processors (Atom) */
>
> #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview
> */
> > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview
There is no such product as Valleyview. Some things talk about
Valleyview 2 but shouldn't as that is Baytrail.
> /* "Small Core" Processors (Atom) */
>
> #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview
> */
> Well, then I have to repeat myself: Signed-off source code (in form of
> patches) in a well-known programming language for a (nowadays)
> well-known GPLv2 licensed project mailed on "everyone can subscribe"
> mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> mailinglist
> Well, then I have to repeat myself: Signed-off source code (in form of
> patches) in a well-known programming language for a (nowadays)
> well-known GPLv2 licensed project mailed on "everyone can subscribe"
> mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> mailinglist
On Wed, 22 Aug 2018 11:25:35 +0200
Marcus Linsner wrote:
> Hi. How to make the kernel keep(lock?) all code pages in RAM so that
> kswapd0 won't evict them when the system is under low memory
> conditions ?
>
> The purpose of this is to prevent the kernel from causing lots of disk
>
On Wed, 22 Aug 2018 11:25:35 +0200
Marcus Linsner wrote:
> Hi. How to make the kernel keep(lock?) all code pages in RAM so that
> kswapd0 won't evict them when the system is under low memory
> conditions ?
>
> The purpose of this is to prevent the kernel from causing lots of disk
>
> Trying to depend on task name for anything security sensitive is at
> _really_ bad idea, so it seems unlikely that a LSM would want to
> protect the process name. (And if they did, the first thing I would
> ask is "Why? What are you trying to do? Do you realize how many
> *other* ways the
> Trying to depend on task name for anything security sensitive is at
> _really_ bad idea, so it seems unlikely that a LSM would want to
> protect the process name. (And if they did, the first thing I would
> ask is "Why? What are you trying to do? Do you realize how many
> *other* ways the
On Wed, 26 Sep 2018 17:49:09 -0400
"Theodore Y. Ts'o" wrote:
> On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote:
> > In almost all cases you don't care so you wouldn't use it. In those cases
> > where it might matter it's almost always the case that a reader wo
On Wed, 26 Sep 2018 17:49:09 -0400
"Theodore Y. Ts'o" wrote:
> On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote:
> > In almost all cases you don't care so you wouldn't use it. In those cases
> > where it might matter it's almost always the case that a reader wo
On Wed, 26 Sep 2018 11:33:29 +1000
Dave Chinner wrote:
> On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote:
> > Hi,
> >
> > I'm bringing up this issue again to let of LSM developers know the
> > situation, and would like to know your thoughts.
> > Several weeks ago I sent an email to
On Wed, 26 Sep 2018 11:33:29 +1000
Dave Chinner wrote:
> On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote:
> > Hi,
> >
> > I'm bringing up this issue again to let of LSM developers know the
> > situation, and would like to know your thoughts.
> > Several weeks ago I sent an email to
> And I think that's fine. The only way we can make any guarantees is
> if we do what Alan suggested, which is to imply that a read on a dirty
> page *block* until the the page is successfully written back. This
> would destroy performance.
In almost all cases you don't care so you wouldn't use
> And I think that's fine. The only way we can make any guarantees is
> if we do what Alan suggested, which is to imply that a read on a dirty
> page *block* until the the page is successfully written back. This
> would destroy performance.
In almost all cases you don't care so you wouldn't use
> Unlike O_TMPFILE, this would require file system changes to support,
> so maybe it's not worth having something which automatically cleans up
> files that were in the middle of being written at the time of a system
> crash.
Would it. If you open a file unlink it and write to it and then have a
> Unlike O_TMPFILE, this would require file system changes to support,
> so maybe it's not worth having something which automatically cleans up
> files that were in the middle of being written at the time of a system
> crash.
Would it. If you open a file unlink it and write to it and then have a
> write()
> kernel attempts to write back page and fails
> page is marked clean and evicted from the cache
> read()
>
> Now your write is gone and there were no calls between the write and
> read.
>
> The question we still need to answer is this:
>
> When we attempt to write back some data from
> write()
> kernel attempts to write back page and fails
> page is marked clean and evicted from the cache
> read()
>
> Now your write is gone and there were no calls between the write and
> read.
>
> The question we still need to answer is this:
>
> When we attempt to write back some data from
> The other thing which you seem to be assuming is that applications
> which care about precious data won't use fsync(2). And in general,
> it's been fairly well known for decades that if you care about your
> data, you have to use fsync(2) or O_DIRECT writes; and you *must*
> check the error
> The other thing which you seem to be assuming is that applications
> which care about precious data won't use fsync(2). And in general,
> it's been fairly well known for decades that if you care about your
> data, you have to use fsync(2) or O_DIRECT writes; and you *must*
> check the error
On Thu, 6 Sep 2018 11:17:18 +0200
Rogier Wolff wrote:
> On Thu, Sep 06, 2018 at 12:57:09PM +1000, Dave Chinner wrote:
> > On Wed, Sep 05, 2018 at 02:07:46PM +0200, Rogier Wolff wrote:
>
> > > And this has worked for years because
> > > the kernel caches stuff from inodes and data-blocks. If
On Thu, 6 Sep 2018 11:17:18 +0200
Rogier Wolff wrote:
> On Thu, Sep 06, 2018 at 12:57:09PM +1000, Dave Chinner wrote:
> > On Wed, Sep 05, 2018 at 02:07:46PM +0200, Rogier Wolff wrote:
>
> > > And this has worked for years because
> > > the kernel caches stuff from inodes and data-blocks. If
On Tue, 18 Sep 2018 21:05:20 -0400
Brian Dodge wrote:
> Hi,
>
> In the linux kernel commit 91ab076e3a2f092254fe5231bbfa92b37fd52e38 the
> vendor prefix "arctic" was added to vendor-prefixes.txt.
>
> The original change I authored used "arc" not "arctic", and the device
> tree bindings were
On Tue, 18 Sep 2018 21:05:20 -0400
Brian Dodge wrote:
> Hi,
>
> In the linux kernel commit 91ab076e3a2f092254fe5231bbfa92b37fd52e38 the
> vendor prefix "arctic" was added to vendor-prefixes.txt.
>
> The original change I authored used "arc" not "arctic", and the device
> tree bindings were
On Tue, 11 Sep 2018 14:12:22 +0200
Joerg Roedel wrote:
> On Tue, Sep 11, 2018 at 02:58:10PM +0300, Meelis Roos wrote:
> > The machines where I have PAE off are the ones that have less memory.
> > PAE is off just for performance reasons, not lack of PAE. PAE should be
> > present on all of my
On Tue, 11 Sep 2018 14:12:22 +0200
Joerg Roedel wrote:
> On Tue, Sep 11, 2018 at 02:58:10PM +0300, Meelis Roos wrote:
> > The machines where I have PAE off are the ones that have less memory.
> > PAE is off just for performance reasons, not lack of PAE. PAE should be
> > present on all of my
On Tue, 11 Sep 2018 22:23:55 +0200
Remi Pommarel wrote:
> This patchset adds a way to have a specific keyboard config (i.e.
> keycode to keysym map) for a vt attached input.
Who actually needs this given that you can't even render most
international symbols in text mode and X and friends
On Tue, 11 Sep 2018 22:23:55 +0200
Remi Pommarel wrote:
> This patchset adds a way to have a specific keyboard config (i.e.
> keycode to keysym map) for a vt attached input.
Who actually needs this given that you can't even render most
international symbols in text mode and X and friends
On Mon, 3 Sep 2018 19:16:39 +0200
Rogier Wolff wrote:
> Hi,
>
> I'm writing a kernel driver. It is not going to be widely used, so I'm
> not motivated to make things nice enough for inclusion in the standard
> kernel.
>
> But lspci shows my device:
>
> 03:01.0 Serial bus controller [0c80]:
On Mon, 3 Sep 2018 19:16:39 +0200
Rogier Wolff wrote:
> Hi,
>
> I'm writing a kernel driver. It is not going to be widely used, so I'm
> not motivated to make things nice enough for inclusion in the standard
> kernel.
>
> But lspci shows my device:
>
> 03:01.0 Serial bus controller [0c80]:
> b) IOMMU can solve this problem for me by providing a device-specific
> contiguous view of a fragmented physical memory allocation
> c) In order to enable IOMMU do the above, I need to allocate DRHDs and
> DMARs in BIOS initialization (I build my own BIOS)
Yes. The EDK2 firmware toolkit has all
> b) IOMMU can solve this problem for me by providing a device-specific
> contiguous view of a fragmented physical memory allocation
> c) In order to enable IOMMU do the above, I need to allocate DRHDs and
> DMARs in BIOS initialization (I build my own BIOS)
Yes. The EDK2 firmware toolkit has all
> I'm actually not talking about UEFI storage, just the UEFI secure boot
> database. I think we might come up with a viable model for adding keys
> from a UEFI variable that isn't part of the secure boot database.
You also need to be able to remove or not trust the existing ones
including the
> I'm actually not talking about UEFI storage, just the UEFI secure boot
> database. I think we might come up with a viable model for adding keys
> from a UEFI variable that isn't part of the secure boot database.
You also need to be able to remove or not trust the existing ones
including the
orry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Alan Cox
Alan
orry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Alan Cox
Alan
On Fri, 27 Jul 2018 16:39:31 +0300
Anton Vasilyev wrote:
> If number of isa and pci boards exceed NUM_BOARDS on the path
> rp_init()->init_PCI()->register_PCI() then buffer overwrite occurs
> in register_PCI() on assign rcktpt_io_addr[i].
>
> The patch adds check on upper bound for index of
On Fri, 27 Jul 2018 16:39:31 +0300
Anton Vasilyev wrote:
> If number of isa and pci boards exceed NUM_BOARDS on the path
> rp_init()->init_PCI()->register_PCI() then buffer overwrite occurs
> in register_PCI() on assign rcktpt_io_addr[i].
>
> The patch adds check on upper bound for index of
> # hdparm --user-master u --security-erase p /dev/sda
> (returns immediately and does nothing).
>
> I've tried hdparm on an SSD connected via USB3 and it secure-erased ok.
>
> Anyone working on this?
Sounds to me like you need to contact the vendor of the interface in
question. If it accepted
> # hdparm --user-master u --security-erase p /dev/sda
> (returns immediately and does nothing).
>
> I've tried hdparm on an SSD connected via USB3 and it secure-erased ok.
>
> Anyone working on this?
Sounds to me like you need to contact the vendor of the interface in
question. If it accepted
On Tue, 24 Jul 2018 17:51:33 -0700
r...@google.com wrote:
> From: Roman Kiryanov
>
> The driver never mutates this variable - no benefits of
> keeping it mutable.
>
> Signed-off-by: Roman Kiryanov
> ---
> Changes in v2:
> - Replaced "const u32" with "#define".
v1 was IMHO definitely better.
1 - 100 of 11107 matches
Mail list logo
